From fujie at loongson.cn Fri Nov 1 04:08:12 2019 From: fujie at loongson.cn (Jie Fu) Date: Fri, 1 Nov 2019 12:08:12 +0800 Subject: RFR: 8233291: [TESTBUG] tools/jlink/plugins/VendorInfoPluginsTest.java fails with debug VMs In-Reply-To: <8d61987f-3134-00ab-613e-a25b03e4981f@oracle.com> References: <0ecd3720-e576-f9ff-b9ac-5c7ab432af00@loongson.cn> <8d61987f-3134-00ab-613e-a25b03e4981f@oracle.com> Message-ID: <5ceba018-7dcd-7ed5-0202-0e7d582052fe@loongson.cn> Hi Mandy, Thanks for your review and nice suggestion. Updated: http://cr.openjdk.java.net/~jiefu/8233291/webrev.01/ I had added '@requires vm.flavor == "server"' since the test is only suitable for server VMs. Testing: ? ---------------------------------- ??? Ben="tools/jlink/plugins/VendorInfoPluginsTest.java" ??? make test TEST="${Ben}"? CONF=server-release ??? make test TEST="${Ben}"? CONF=fastdebug ??? make test TEST="${Ben}"? CONF=slowdebug ??? make test TEST="${Ben}"? CONF=minimal ??? make test TEST="${Ben}"? CONF=zero ? ---------------------------------- Please review it and give me some advice. Thanks a lot. Best regards, Jie On 2019/11/1 ??2:09, Mandy Chung wrote: > Hi Jie, > > On 10/30/19 11:13 PM, Jie Fu wrote: >> Hi all, >> >> May I get reviews for the small fix for the failure of >> VendorInfoPluginsTest.java in debug VMs? >> >> JBS:??? https://bugs.openjdk.java.net/browse/JDK-8233291 >> Webrev: http://cr.openjdk.java.net/~jiefu/8233291/webrev.00/ > > Thanks for fixing this. > > Changing the regex to ".*build.*$" is okay.? Perhaps checking if > "jdk.debug" system property is present and prepend to the regex? > > Mandy From huaming.li at oracle.com Fri Nov 1 04:47:49 2019 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 1 Nov 2019 12:47:49 +0800 Subject: RFR of JDK-8233313: server socket created by LocateRegistry.createRegistry(0) can not be closed Message-ID: <941b62df-c7b0-c413-c008-3037febfa02b@oracle.com> Would you please to review the following patch? bug: https://bugs.openjdk.java.net/browse/JDK-8233313 webrev: http://cr.openjdk.java.net/~mli/8233313/webrev.00/ With following code, port used behind is not closed after unexportObject /Registry registry = LocateRegistry.createRegistry(0);// //boolean b = UnicastRemoteObject.unexportObject(registry, true);/ But, the port can be closed if pass in an explicit port number to createRegistry. I think is not right and is a resource leak. Thank you -Hamlin From huaming.li at oracle.com Fri Nov 1 05:41:37 2019 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 1 Nov 2019 13:41:37 +0800 Subject: RFR of JDK-8233313: server socket created by LocateRegistry.createRegistry(0) can not be closed In-Reply-To: <941b62df-c7b0-c413-c008-3037febfa02b@oracle.com> References: <941b62df-c7b0-c413-c008-3037febfa02b@oracle.com> Message-ID: This is found during fixing JDK-8233105 , so please consider test scenario in JDK-8233105 On 2019/11/1 12:47 PM, Hamlin Li wrote: > Would you please to review the following patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8233313, > https://bugs.openjdk.java.net/browse/JDK-8233105 > > webrev: http://cr.openjdk.java.net/~mli/8233313/webrev.00/ > > With following code, port used behind is not closed after unexportObject > > /Registry registry = LocateRegistry.createRegistry(0);// > //boolean b = UnicastRemoteObject.unexportObject(registry, true);/ > > But, the port can be closed if pass in an explicit port number to > createRegistry. > > I think is not right and is a resource leak. > > > Thank you > > -Hamlin > From Alan.Bateman at oracle.com Fri Nov 1 06:50:53 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 1 Nov 2019 06:50:53 +0000 Subject: RFR 8233091 : Backout JDK-8212117: Class.forName loads a class but not linked if class is not initialized In-Reply-To: <6643000b-9bd2-5b3a-8321-9fbc716a23f3@oracle.com> References: <6643000b-9bd2-5b3a-8321-9fbc716a23f3@oracle.com> Message-ID: On 31/10/2019 22:50, Brent Christian wrote: > Hi, > > Please review my change to backout JDK-8212117: > http://cr.openjdk.java.net/~bchristi/8233091/webrev-revert-01/ The backout looks right. -Alan From sergei.tsypanov at yandex.ru Fri Nov 1 06:57:59 2019 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Fri, 01 Nov 2019 08:57:59 +0200 Subject: Question about String.toUpperCase behaviour In-Reply-To: References: <32507691572282872@sas2-a74be5364cfb.qloud-c.yandex.net> <878sp46231.fsf@mid.deneb.enyo.de> Message-ID: <55669631572591479@vla1-c477e3898c96.qloud-c.yandex.net> > That doesn't remove the performance difference when the string is NOT upper > case. When the code is C2 compiler there is no significant difference, but in interpreter mode it's noticeable. @OutputTimeUnit(TimeUnit.NANOSECONDS) @BenchmarkMode(value = Mode.AverageTime) public class StringEqualityBenchmark { @Benchmark public boolean equals(Data data) { return data.getStr1().equals(data.getStr2()); } @Benchmark public boolean reference(Data data) { return data.getStr1() == data.getStr2(); } @State(Scope.Thread) public static class Data { @Param({"true", "false"}) private boolean latin; private final String latinStr1 = "AZ"; private final String latinStr2 = latinStr1; private final String russianStr1 = "??"; private final String russianStr2 = russianStr1; String getStr1() { return latin ? latinStr1 : russianStr1; } String getStr2() { return latin ? latinStr2 : russianStr2; } } } This benchmark run in interpreter mode yields following results: Benchmark (latin) Mode Cnt Score Error Units StringEqualityBenchmark.equals true avgt 50 212,916 ? 24,065 ns/op StringEqualityBenchmark.reference true avgt 50 160,699 ? 8,948 ns/op StringEqualityBenchmark.equals false avgt 50 178,818 ? 13,223 ns/op StringEqualityBenchmark.reference false avgt 50 158,227 ? 8,704 ns/op Regards, Sergey Tsypanov From takiguc at linux.vnet.ibm.com Fri Nov 1 13:56:34 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Fri, 01 Nov 2019 22:56:34 +0900 Subject: RFR: 8232161 Unexpected 1-way trip conversion entries on MS950 charset In-Reply-To: <928774f8-9d20-bf75-fbc3-36c8a37b273c@oracle.com> References: <15742fda1558e881ca62792241b90d68@linux.vnet.ibm.com> <7182bb24-7e9d-c3e3-2246-a435c706fc60@oracle.com> <93bc5929-3995-764d-a39e-bafc7d82503a@oracle.com> <4573ea1e76d12d4a48f71c2536c18e62@linux.vnet.ibm.com> <928774f8-9d20-bf75-fbc3-36c8a37b273c@oracle.com> Message-ID: <74fc2a0ee9fb0de5284b727b2b68a64c@linux.vnet.ibm.com> Hello Sato-san. I could not find any specific reason for this issue. I said "1-way trip conversion", I should say "round trip conversion". bestfit950.txt has many 1-way trip entries for Unicode to MS950 conversion. At least, I think round trip conversion needs to be consistent between Windows and Java. Thanks, Ichiroh Takiguchi On 2019-10-31 01:25, naoto.sato at oracle.com wrote: > Takiguchi-san, > > Personally I am reluctant to make this change. If we were to introduce > this, it will be a different encoding from the existing MS950, so > either 1) we need a new encoding, or 2) make some switch between the > encoding, possibly a system property. But neither seems worth doing, > as :- > > 1) JDK's conversion is not a bug per se. > 2) Seems that Unicode.org's "best fit" was introduced around 2006? > (From the date on the unicode.org > (https://unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit950.txt), > so JDK's mapping predates it. > 3) Those code points are not a common ones (BOX DRAWINGS), and no > customer had a complaint about it. > > Please let me know if there are some rationale for fixing it. > > BTW, as to the CSR, I don't see it was created. > > Naoto > > > On 10/29/19 11:35 AM, Ichiroh Takiguchi wrote: >> Thanks, Sato-san. >> >> There is no special meaning to the word "until now". >> I rewrote charset related testcases, then I found this issue. >> >> I read "Frequently Asked Questions about the CSR" [1], >> I tried "Create CSR" operation, but I could not determine it worked or >> not... >> (Select "Create CSR" from "More" menu) >> It worked ? >> >> [1] https://wiki.openjdk.java.net/display/csr/CSR+FAQs >> >> Thanks, >> Ichiroh Takiguchi >> >> On 2019-10-29 03:03, naoto.sato at oracle.com wrote: >>> Hi Takiguchi-san, >>> >>> On 10/28/19 9:51 AM, Ichiroh Takiguchi wrote: >>>> Hello. >>>> >>>> I have no idea about compatibility impact. >>>> >>>> But according to >>>> ftp://ftp.unicode.org/Public/12.1.0/ucd/UnicodeData.txt >>>> These are BOX DRAWINGS characters. >>>> >>>> 2550;BOX DRAWINGS DOUBLE HORIZONTAL;So;0;ON;;;;;N;FORMS DOUBLE >>>> HORIZONTAL;;;; >>>> 255E;BOX DRAWINGS VERTICAL SINGLE AND RIGHT >>>> DOUBLE;So;0;ON;;;;;N;FORMS VERTICAL SINGLE AND RIGHT DOUBLE;;;; >>>> 2561;BOX DRAWINGS VERTICAL SINGLE AND LEFT >>>> DOUBLE;So;0;ON;;;;;N;FORMS VERTICAL SINGLE AND LEFT DOUBLE;;;; >>>> 256A;BOX DRAWINGS VERTICAL SINGLE AND HORIZONTAL >>>> DOUBLE;So;0;ON;;;;;N;FORMS VERTICAL SINGLE AND HORIZONTAL DOUBLE;;;; >>>> >>>> I don't think it was used as valuable data until now. >>>> I think it's necessary to evaluate compatibility. >>> >>> What do you mean by "until now"? Are there customers claiming that it >>> should be corrected? Since the current JDK's mapping is not incorrect >>> per se (not just "best match"), I would like to know why this needs >>> to >>> be fixed now. >>> >>> Naoto >>> >>>> >>>> To Sato-san, >>>> if you have any question and suggestion, please let me know. >>>> >>>> To other reviewers, >>>> please let me know if you have any question and concern. >>>> >>>> Thanks, >>>> Ichiroh Takiguchi >>>> >>>> On 2019-10-19 16:36, Alan Bateman wrote: >>>>> On 14/10/2019 16:53, Ichiroh Takiguchi wrote: >>>>>> Hello. >>>>>> >>>>>> Could you review the fix ? >>>>>> >>>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8232161 >>>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8232161/webrev.00/ >>>>>> >>>>>> I have a concern about 1-way trip conversion entries (4 entries) >>>>>> on MS950 charset. >>>>>> The detail information is in JDK-8232161 [1] >>>>>> >>>>> Do you know any sense on the compatibility impact of changing this? >>>>> I >>>>> think Naoto has the same question and we aren't sure if this one >>>>> with >>>>> need a compatibility property. I think it will need a CSR. >>>>> >>>>> -Alan From Matthew.Carter at microsoft.com Fri Nov 1 14:06:46 2019 From: Matthew.Carter at microsoft.com (Mat Carter) Date: Fri, 1 Nov 2019 14:06:46 +0000 Subject: JDK-8231863 bug fix candidate Message-ID: Hello core-libs-dev I'm a VM engineer at Microsoft, now that we've signed the OCA (news of which was shared by Bruno Borges in the discuss mailing list) I wanted to pick up an issue in order to gain familiarity with the change process After reproducing the error reported in "JDK-8231863: Crash if classpath is read from @argument file and the main gets option argument" (https://bugs.openjdk.java.net/browse/JDK-8231863), I've identified the root cause and a candidate fix. As such I'd like to pick this issue up, assuming its current state of unassigned still holds what's the process of having it assigned to me or having it somehow reserved as I don't want to cause unnecessary duplicated work. As well as validating the fix in the debugger on WIndows and Linux, I've run the AdoptOpenJDK sanity tests on Mac, Windows and Linux for both tip and 11u. I'm currently figuring out where/how to write regression tests for this case; input from this mailing list would be welcomed (examples of tests for similar bugs etc) This error occurs on all platforms (tip + 11u) but only results in a crash on Windows in java_md.c due to that platforms dependency on JLI_GetAppArgIndex().? Note that while the error is 100% reproducible, the crash only occurs <10%.? The following change fixes that problem by passing in the final token fragment from the argument file into the state machine via checkArg() --- a/src/java.base/share/native/libjli/args.c +++ b/src/java.base/share/native/libjli/args.c @@ -337,7 +337,9 @@ static JLI_List readArgFile(FILE *file) { ???? // remaining partial token ???? if (ctx.state == IN_TOKEN || ctx.state == IN_QUOTE) { ???????? if (ctx.parts->size != 0) { -??????????? JLI_List_add(rv, JLI_List_combine(ctx.parts)); +??????????? token = JLI_List_combine(ctx.parts); +??????????? checkArg(token); +??????????? JLI_List_add(rv, token); ???????? } ???? } ???? JLI_List_free(ctx.parts); The fix tackles the memory corruption indirectly.? Further preventative changes could be made in java_md.c/CreateApplicationArgs to avoid future memory corruptions (caused by JLI_GetAppArgIndex() returning -1 in this case) ; but I felt that that handling those error cases ran secondary to addressing the bug in the argument file parsing code. Cheers Mat From Roger.Riggs at oracle.com Fri Nov 1 15:14:44 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 1 Nov 2019 11:14:44 -0400 Subject: RFR of JDK-8233313: server socket created by LocateRegistry.createRegistry(0) can not be closed In-Reply-To: <941b62df-c7b0-c413-c008-3037febfa02b@oracle.com> References: <941b62df-c7b0-c413-c008-3037febfa02b@oracle.com> Message-ID: <7aa3c446-84b0-928f-fea4-598421467cba@oracle.com> Hi Hamlin, I would expect endPoint().getPort() to be non-zero except during the narrow window of the initialization before the server socket is opened. See TCPEndPoint.listen(). If that's true, then either there is no server socket to close or that part of the condition is always true and could be removed. So I think we'd need to understand if it was intentional to leave an application specified port open, while closing one that the application has no (specific) knowledge of. $.02, Roger BTW, verifyPortFree() would easier to understand and code with if it returned a boolean instead throwing an exception.? The non-local exception handling makes the code harder to follow. On 11/1/19 12:47 AM, Hamlin Li wrote: > Would you please to review the following patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8233313 > > webrev: http://cr.openjdk.java.net/~mli/8233313/webrev.00/ > > With following code, port used behind is not closed after unexportObject > > /Registry registry = LocateRegistry.createRegistry(0);// > //boolean b = UnicastRemoteObject.unexportObject(registry, true);/ > > But, the port can be closed if pass in an explicit port number to > createRegistry. > > I think is not right and is a resource leak. > > > Thank you > > -Hamlin > From mandy.chung at oracle.com Fri Nov 1 17:15:40 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 1 Nov 2019 10:15:40 -0700 Subject: RFR: 8233291: [TESTBUG] tools/jlink/plugins/VendorInfoPluginsTest.java fails with debug VMs In-Reply-To: <5ceba018-7dcd-7ed5-0202-0e7d582052fe@loongson.cn> References: <0ecd3720-e576-f9ff-b9ac-5c7ab432af00@loongson.cn> <8d61987f-3134-00ab-613e-a25b03e4981f@oracle.com> <5ceba018-7dcd-7ed5-0202-0e7d582052fe@loongson.cn> Message-ID: On 10/31/19 9:08 PM, Jie Fu wrote: > Hi Mandy, > > Thanks for your review and nice suggestion. > Updated: http://cr.openjdk.java.net/~jiefu/8233291/webrev.01/ > Why do you need to check if it contains "debug"?? I would expect it's simply empty string or the "jdk.debug" system property value appended with a space. In any case, I'm okay with the generic pattern ".*build.*$" (webrev.00) if preferred. > I had added '@requires vm.flavor == "server"' since the test is only > suitable for server VMs. > I think the test is not restricted for server VM.?? Is it because of the "Server VM" check?? Should that check be fixed instead? [1] http://hg.openjdk.java.net/jdk/jdk/file/tip/src/java.base/share/classes/java/lang/VersionProps.java.template#l217 Mandy From vlv.spb.ru at mail.ru Fri Nov 1 19:23:55 2019 From: vlv.spb.ru at mail.ru (=?UTF-8?B?VmxhZGltaXIgWWFyb3NsYXZza2l5?=) Date: Fri, 01 Nov 2019 22:23:55 +0300 Subject: =?UTF-8?B?UmVbMl06IENoZWNraW5nIGluc3RhbmNlb2YgaW4gRHVhbFBpdm90UXVpY2tz?= =?UTF-8?B?b3J0?= In-Reply-To: <2eb27ec4-92fe-1e89-4886-ead25e9974b1@oracle.com> References: <1571919081.256114976@f562.i.mail.ru> <2eb27ec4-92fe-1e89-4886-ead25e9974b1@oracle.com> Message-ID: <1572636235.881461803@f455.i.mail.ru> Hi Brent, I agree with you, IllegalArgumentExceptions will help to catch invalid cases if we change the source in future. Please go ahead with integration. Thank you, Vladimir >25? Oct 2019, 8:28 +03:00 ?? Brent Christian : > >Hi, Vladimir > >I'd prefer to keep the code as is. Perhaps the exception could help >some other future maintainer to pinpoint a problem with a potential change. > >-Brent > >On 10/24/19 5:11 AM, Vladimir Yaroslavskiy wrote: >> Hi Brent, >> >> Looking at coverage of DualPivotQuicksort class, I found that >> cases of unexpected type of given array are not invoked at all >> (mentioned in my previous email). >> >> I think that these "else" can be removed, because method >> compute() of private classes are invoked from DualPivotQuicksort >> class only and we can guarantee valid array types (int[], .. , double[]). >> >> If you agree, could you please, remove such cases? >> >> Replace lines 4147-4148: >> >> throw new IllegalArgumentException( >> "Unknown type of array: " + a.getClass().getName()); >> >> by return null; >> >> remove lines 4099-4101: >> >> } else { >> throw new IllegalArgumentException( >> "Unknown type of array: " + dst.getClass().getName()); >> >> and remove lines 4030-4033: >> >> } else { >> throw new IllegalArgumentException( >> "Unknown type of array: " + a.getClass().getName()); >> >> ----- >> >> And doe the same for Sorting class: remove 12 cases >> fail("Unknown type of array: " + .... >> >> Thank you, >> Vladimir >> -- Vladimir Yaroslavskiy From alexey.semenyuk at oracle.com Sat Nov 2 00:06:07 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Fri, 1 Nov 2019 20:06:07 -0400 Subject: RFR: JDK-8232919: If user installs msi and exe, two installations are found in Add/Remove In-Reply-To: <86bca240-6272-1576-2110-3816e5d7f7c7@oracle.com> References: <86bca240-6272-1576-2110-3816e5d7f7c7@oracle.com> Message-ID: <2754f1df-901a-049e-7bc7-74cd25596fa5@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). Additionally: - added support for `overrides.wxi` WiX source file in resource dir. Custom overrides.wxi can be used as a placeholder for overrides of default WiX variables defined by jpackage that control output msi. - Alexey [1] https://bugs.openjdk.java.net/browse/JDK-8232919 [2] http://cr.openjdk.java.net/~asemenyuk/8232919/webrev.00 From brian.burkhalter at oracle.com Sat Nov 2 00:13:28 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 1 Nov 2019 17:13:28 -0700 Subject: 8179320: File.getUsableSpace() returns a negative number on very large file system Message-ID: <674F3B84-3737-4F55-8D2B-B1777F91203E@oracle.com> For this issue [1], please review this patch [2] and the corresponding CSR [3]. Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8179320 [2] http://cr.openjdk.java.net/~bpb/8179320/webrev.00/ [3] https://bugs.openjdk.java.net/browse/JDK-8233426 From brian.burkhalter at oracle.com Sat Nov 2 00:18:16 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 1 Nov 2019 17:18:16 -0700 Subject: 8232271: java.io.File.get*Space() should be aligned to updated FileStore analog methods In-Reply-To: References: Message-ID: <5AAAF24D-2618-4AD5-AD26-A3071B60AD6E@oracle.com> This topic is now moved to the thread [1] which corresponds to the pre-existing bug ID I overlooked [2]. Brian [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-November/063243.html [2] https://bugs.openjdk.java.net/browse/JDK-8179320 > On Oct 30, 2019, at 8:20 AM, Brian Burkhalter wrote: > > Ping ! > >> Begin forwarded message: >> >> From: Brian Burkhalter > >> Subject: 8232271: java.io.File.get*Space() should be aligned to updated FileStore analog methods >> Date: October 17, 2019 at 10:35:46 AM PDT >> To: Core-Libs-Dev > >> >> For issue [1], please review the patch [2]. This change aligns the specifications of the File.get*Space() methods with their equivalents in java.nio.file.FileStore. This issue is related to [3] which is discussed in this thread [4]. >> >> Naturally a CSR would eventually be required. >> >> Thanks, >> >> Brian >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8232271 >> [2] http://cr.openjdk.java.net/~bpb/8232271/webrev.00/ >> [3] https://bugs.openjdk.java.net/browse/JDK-8162520 >> [4] http://mail.openjdk.java.net/pipermail/nio-dev/2019-October/006644.html From alexander.matveev at oracle.com Sat Nov 2 01:45:11 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Fri, 1 Nov 2019 18:45:11 -0700 Subject: RFR: JDK-8232919: If user installs msi and exe, two installations are found in Add/Remove In-Reply-To: <2754f1df-901a-049e-7bc7-74cd25596fa5@oracle.com> References: <86bca240-6272-1576-2110-3816e5d7f7c7@oracle.com> <2754f1df-901a-049e-7bc7-74cd25596fa5@oracle.com> Message-ID: <249ce5eb-147d-a1f8-69ec-7742172c383f@oracle.com> Hi Alexey, http://cr.openjdk.java.net/~asemenyuk/8232919/webrev.00/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/main.wxs.frames.html This file refers to JpAllowDowngrades and JpAllowUpgrades. Code sets JpAllowUpgrades to yes always and never sets JpAllowDowngrades. Maybe I am missing something, but why we need these defs in .wxs file if they do nothing. Also, I think we should allow downgrades by default. Thanks, Alexander On 11/1/2019 5:06 PM, Alexey Semenyuk 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). > > Additionally: > - added support for `overrides.wxi` WiX source file in resource dir. > Custom overrides.wxi can be used as a placeholder for overrides of > default WiX variables defined by jpackage that control output msi. > > - Alexey > > [1] https://bugs.openjdk.java.net/browse/JDK-8232919 > > [2] http://cr.openjdk.java.net/~asemenyuk/8232919/webrev.00 > From alexey.semenyuk at oracle.com Sat Nov 2 04:00:06 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Sat, 2 Nov 2019 00:00:06 -0400 Subject: RFR: JDK-8232919: If user installs msi and exe, two installations are found in Add/Remove In-Reply-To: <249ce5eb-147d-a1f8-69ec-7742172c383f@oracle.com> References: <86bca240-6272-1576-2110-3816e5d7f7c7@oracle.com> <2754f1df-901a-049e-7bc7-74cd25596fa5@oracle.com> <249ce5eb-147d-a1f8-69ec-7742172c383f@oracle.com> Message-ID: On 11/1/2019 9:45 PM, Alexander Matveev wrote: > Hi Alexey, > > http://cr.openjdk.java.net/~asemenyuk/8232919/webrev.00/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/main.wxs.frames.html > > This file refers to JpAllowDowngrades and JpAllowUpgrades. Code sets > JpAllowUpgrades to yes always and never sets JpAllowDowngrades. Maybe > I am missing something, but why we need these defs in .wxs file if > they do nothing. We need these defs so that if people would like to customize update rules of their msi installer they can set only WiX variables instead of replacing the whole default main.wxs. Say, they would like to enable downgrades in their installers and the other defaults would work for them. Then they would need to put only overrides.wxi in resource directory with the following contents: ? > Also, I think we should allow downgrades by default. I don't have any particular preferences on the matter. However there are other options, like allow side-by-side installation of different versions of the same application. Should we allow this by default? Whatever defaults we would pick up, they wouldn't work for all people and we need convenient way to adjust them without the need to replace the whole main.wxs. - Alexey > > Thanks, > Alexander > > On 11/1/2019 5:06 PM, Alexey Semenyuk 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). >> >> Additionally: >> - added support for `overrides.wxi` WiX source file in resource dir. >> Custom overrides.wxi can be used as a placeholder for overrides of >> default WiX variables defined by jpackage that control output msi. >> >> - Alexey >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8232919 >> >> [2] http://cr.openjdk.java.net/~asemenyuk/8232919/webrev.00 >> > From alexander.matveev at oracle.com Sat Nov 2 05:26:06 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Fri, 1 Nov 2019 22:26:06 -0700 Subject: RFR: JDK-8232919: If user installs msi and exe, two installations are found in Add/Remove In-Reply-To: References: <86bca240-6272-1576-2110-3816e5d7f7c7@oracle.com> <2754f1df-901a-049e-7bc7-74cd25596fa5@oracle.com> <249ce5eb-147d-a1f8-69ec-7742172c383f@oracle.com> Message-ID: <35fe3109-9d9e-4af4-22e2-d3762f1b6f8b@oracle.com> Hi Alexey, On 11/1/2019 9:00 PM, Alexey Semenyuk wrote: > > > On 11/1/2019 9:45 PM, Alexander Matveev wrote: >> Hi Alexey, >> >> http://cr.openjdk.java.net/~asemenyuk/8232919/webrev.00/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/main.wxs.frames.html >> >> This file refers to JpAllowDowngrades and JpAllowUpgrades. Code sets >> JpAllowUpgrades to yes always and never sets JpAllowDowngrades. Maybe >> I am missing something, but why we need these defs in .wxs file if >> they do nothing. > We need these defs so that if people would like to customize update > rules of their msi installer they can set only WiX variables instead > of replacing the whole default main.wxs. > Say, they would like to enable downgrades in their installers and the > other defaults would work for them. Then they would need to put only > overrides.wxi in resource directory with the following contents: > > > ? > Should we put help into overrides.wxi to show what can be changed. For example: ? > >> Also, I think we should allow downgrades by default. > I don't have any particular preferences on the matter. However there > are other options, like allow side-by-side installation of different > versions of the same application. Should we allow this by default? > Whatever defaults we would pick up, they wouldn't work for all people > and we need convenient way to adjust them without the need to replace > the whole main.wxs. Agree. I think it might be good idea to keep defaults same or close as possible to other platforms. macOS should allow downgrades by default as far as I know. Not sure about Linux. Thanks, Alexander > > - Alexey >> >> Thanks, >> Alexander >> >> On 11/1/2019 5:06 PM, Alexey Semenyuk 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). >>> >>> Additionally: >>> - added support for `overrides.wxi` WiX source file in resource dir. >>> Custom overrides.wxi can be used as a placeholder for overrides of >>> default WiX variables defined by jpackage that control output msi. >>> >>> - Alexey >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8232919 >>> >>> [2] http://cr.openjdk.java.net/~asemenyuk/8232919/webrev.00 >>> >> > From fujie at loongson.cn Sat Nov 2 11:46:36 2019 From: fujie at loongson.cn (Jie Fu) Date: Sat, 2 Nov 2019 19:46:36 +0800 Subject: RFR: 8233291: [TESTBUG] tools/jlink/plugins/VendorInfoPluginsTest.java fails with debug VMs In-Reply-To: References: <0ecd3720-e576-f9ff-b9ac-5c7ab432af00@loongson.cn> <8d61987f-3134-00ab-613e-a25b03e4981f@oracle.com> <5ceba018-7dcd-7ed5-0202-0e7d582052fe@loongson.cn> Message-ID: <7fdb43ab-8b03-c6aa-c2fe-5406a8125efa@loongson.cn> Hi Mandy, Thanks for your review and valuable comments. Updated: http://cr.openjdk.java.net/~jiefu/8233291/webrev.02/ Testing: ? ---------------------------------- ??? Ben="tools/jlink/plugins/VendorInfoPluginsTest.java" ??? make test TEST="${Ben}"? CONF=server-release ??? make test TEST="${Ben}"? CONF=fastdebug ??? make test TEST="${Ben}"? CONF=slowdebug ??? make test TEST="${Ben}"? CONF=minimal ??? make test TEST="${Ben}"? CONF=zero ? ---------------------------------- Please review it and give me some advice. Thanks a lot. Best regards, Jie On 2019/11/2 ??1:15, Mandy Chung wrote: > Why do you need to check if it contains "debug"? Because System.getProperty("jdk.debug") will return "release" for release VMs and "{fast/slow}debug" for debug VMs. > I think the test is not restricted for server VM.?? Is it because of > the "Server VM" check? Yes. > Should that check be fixed instead? Fixed. Thanks. From huaming.li at oracle.com Mon Nov 4 02:27:48 2019 From: huaming.li at oracle.com (Hamlin Li) Date: Mon, 4 Nov 2019 10:27:48 +0800 Subject: RFR of JDK-8233313: server socket created by LocateRegistry.createRegistry(0) can not be closed In-Reply-To: <7aa3c446-84b0-928f-fea4-598421467cba@oracle.com> References: <941b62df-c7b0-c413-c008-3037febfa02b@oracle.com> <7aa3c446-84b0-928f-fea4-598421467cba@oracle.com> Message-ID: Thanks Roger. On 2019/11/1 11:14 PM, Roger Riggs wrote: > Hi Hamlin, > > I would expect endPoint().getPort() to be non-zero except during the > narrow window of the initialization before the server socket is opened. > See TCPEndPoint.listen(). I assumed you mean TCPTransport.listen(). > > If that's true, then either there is no server socket to close or > that part of the condition is always true and could be removed. TCPTransport.listen() is synced against TCPTransport instance, and decrementExportCount() is also synced against TCPTransport instance, so I agree we could just remove getListenPort()/getPort() check. > > So I think we'd need to understand if it was intentional to leave > an application specified port open, while closing one that > the application has no (specific) knowledge of. I think it was intentional, reasons are: 1. check TCPTransport.setDefaultPort(...) ). 2. in code "r1 = LocateRegistry.createRegistry(0); UnicastRemoteObject.unexportObject(r1, true); r2 = LocateRegistry.createRegistry(0);", r1 and r1 use the same server socket port. But I think we can/should change this behavior, reasons are: 1. it's not necessary, it's still a resource leak if I don't use port 0 anymore. 2. it's not stated in the API doc. 3. if it's not stated in the API doc, then this behavior lead to inconsistency between 0 and other ports. 4. more important, this implementation makes some test scenarios hard to be stable (like JDK-8233105 ). Thank you -Hamlin > > $.02, Roger > > BTW, verifyPortFree() would easier to understand and code with if it > returned a boolean > instead throwing an exception.? The non-local exception handling makes > the code harder to follow. > > > > On 11/1/19 12:47 AM, Hamlin Li wrote: >> Would you please to review the following patch? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8233313 >> >> webrev: http://cr.openjdk.java.net/~mli/8233313/webrev.00/ >> >> With following code, port used behind is not closed after unexportObject >> >> /Registry registry = LocateRegistry.createRegistry(0);// >> //boolean b = UnicastRemoteObject.unexportObject(registry, true);/ >> >> But, the port can be closed if pass in an explicit port number to >> createRegistry. >> >> I think is not right and is a resource leak. >> >> >> Thank you >> >> -Hamlin >> > From mandy.chung at oracle.com Mon Nov 4 03:49:04 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Sun, 3 Nov 2019 19:49:04 -0800 Subject: RFR: 8233291: [TESTBUG] tools/jlink/plugins/VendorInfoPluginsTest.java fails with debug VMs In-Reply-To: <7fdb43ab-8b03-c6aa-c2fe-5406a8125efa@loongson.cn> References: <0ecd3720-e576-f9ff-b9ac-5c7ab432af00@loongson.cn> <8d61987f-3134-00ab-613e-a25b03e4981f@oracle.com> <5ceba018-7dcd-7ed5-0202-0e7d582052fe@loongson.cn> <7fdb43ab-8b03-c6aa-c2fe-5406a8125efa@loongson.cn> Message-ID: Hi Jie, On 11/2/19 4:46 AM, Jie Fu wrote: > > Hi Mandy, > > Thanks for your review and valuable comments. > Updated: http://cr.openjdk.java.net/~jiefu/8233291/webrev.02/ > Looks good.? I'll sponsor it. Mandy > Testing: > ? ---------------------------------- > ??? Ben="tools/jlink/plugins/VendorInfoPluginsTest.java" > ??? make test TEST="${Ben}"? CONF=server-release > ??? make test TEST="${Ben}"? CONF=fastdebug > ??? make test TEST="${Ben}"? CONF=slowdebug > ??? make test TEST="${Ben}"? CONF=minimal > ??? make test TEST="${Ben}"? CONF=zero > ? ---------------------------------- > > Please review it and give me some advice. > > Thanks a lot. > Best regards, > Jie > > On 2019/11/2 ??1:15, Mandy Chung wrote: >> Why do you need to check if it contains "debug"? > Because System.getProperty("jdk.debug") will return "release" for > release VMs and "{fast/slow}debug" for debug VMs. > >> I think the test is not restricted for server VM.?? Is it because of >> the "Server VM" check? > > Yes. > > >> Should that check be fixed instead? > Fixed. Thanks. From fujie at loongson.cn Mon Nov 4 03:51:47 2019 From: fujie at loongson.cn (Jie Fu) Date: Mon, 4 Nov 2019 11:51:47 +0800 Subject: RFR: 8233291: [TESTBUG] tools/jlink/plugins/VendorInfoPluginsTest.java fails with debug VMs In-Reply-To: References: <0ecd3720-e576-f9ff-b9ac-5c7ab432af00@loongson.cn> <8d61987f-3134-00ab-613e-a25b03e4981f@oracle.com> <5ceba018-7dcd-7ed5-0202-0e7d582052fe@loongson.cn> <7fdb43ab-8b03-c6aa-c2fe-5406a8125efa@loongson.cn> Message-ID: Thank you so much, Mandy. On 2019/11/4 ??11:49, Mandy Chung wrote: > Looks good.? I'll sponsor it. From philipp.kunz at paratix.ch Mon Nov 4 06:38:33 2019 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Mon, 04 Nov 2019 07:38:33 +0100 Subject: Jar manifest and EOF character (code 26) In-Reply-To: <7BF64E28-35AA-40A5-9093-0BF086BB51C1@oracle.com> References: <9930f76c594c2feee98d6be5db73265536f9861a.camel@paratix.ch> <7BF64E28-35AA-40A5-9093-0BF086BB51C1@oracle.com> Message-ID: <1665721717567c2835e51fa1e3fc6e29b0ee4026.camel@paratix.ch> Hi Max, Even if it was easy to implement, I don't think we actually would want it. Hopefully not put too much to the point, it sound like last century operating with punch cards. The discussed portion of the specification refers to "EOF character (code 26)" and also I am not talking about an end of a file or input stream. Nowadays I don't see fit. However easy or difficult to implement, in either case, I'd opt for removing that sentence about EOF characters in manifests. I doubt that changing the reading of manifests, particularly at their ends, is a promising prospect at the moment. I tried to make this point already with references [3] through [14] in the previous mail below and I added one new reference [1] of that sort. It would be easy to implement only if it was not for compatibility, I figure. If a consensus or an agreement can be found for removing the discussed sentence from the specification we are kind of lucky that the code does not have to be changed. No way I'd want to jump to conclusions here but changing the specification around the EOF character only and not the code is possible without waiting for the other issues related to parsing an insufficiently terminated last line of a manifest which have been stuck for a while now. Regards,Philipp [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058774.html On Mon, 2019-10-14 at 09:41 +0800, Weijun Wang wrote: > Hi Philipp, > Although I also think this feature might be useless, I feel hesitated > to just remove it. How about implement it and let it stay useless? I > assume this will not break any existing test or app if no one is > actually using the character. Hopefully it's easy to implement. > On the other hand, if there is really a EOF char at the end, there > will be a behavior change. If that EOF is at the end an attribute > line, that line is ignored now, and it should be visible after the > change and this looks like a good thing. If that EOF is after a > newline, it will be useless anyway. > Also, my understanding is that hash/signature in a signed jar file > are calculated on raw bytes and old signed jars can still be > verified. We should take care to use the original raw bytes and not > the result of Manifest::write, but I think your previous fixes in > this area had already handled this correctly. > Just my $0.02. > Thanks,Max > > On Oct 11, 2019, at 2:11 PM, Philipp Kunz > > wrote: > > Hi, > > The Jar File Specification [1] states that, > > > If the last character of the file is an EOF character (code 26), > > > the > > EOF is treated as whitespace. Two newlines are appended (one > > foreditors that don't put a newline at the end of the last line, > > and oneso that the grammar doesn't have to special-case the last > > entry, whichmay not have a blank line after it). > > But I can't see that this is actually the case. See the attached > > simpletest that indicates that this statement is not implemented. > > See also potentially remotely related bugs [2] and [3] which both > > referin my opinion to EOF as the end of the byte stream as opposed > > to theEOF character 26. > > After nobody has fixed this point inside of many years I tend to > > assumethat it is not at all necessary or useful. However, I cannot > > understandthe intention behind it or how that statement got there > > in the firstplace and hence might not be aware of the full context. > > Considering the activity about the last line of a manifest > > notterminated by a line break resulting in that line ignored > > unexpectedly (see [3] through [14]) I doubt that it is promising to > > attempt toimplement the EOF according to the specs. > > Instead I'd rather like to propose to update the specification > > byremoving the quoted statement. > > I'm not sure if the specification [1] has changed since 13 or where > > themost up to date one is. > > Regards,Philipp > > > > > > [1] > > https://docs.oracle.com/en/java/javase/13/docs/specs/jar/jar.html#notes-on-manifest-and-signature-files > > > > EOF-related:[2] https://bugs.openjdk.java.net/browse/JDK-7148584 > > [3] https://bugs.openjdk.java.net/browse/JDK-4639129 > > > > Last line break required or missing related:[4] > > https://bugs.openjdk.java.net/browse/JDK-4274235 > > [5] https://bugs.openjdk.java.net/browse/JDK-4894998 > > [6] https://bugs.openjdk.java.net/browse/JDK-4333854 > > [7] https://bugs.openjdk.java.net/browse/JDK-6594305 > > [8] > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058774.html > > [9] https://bugs.openjdk.java.net/browse/JDK-4489716 > > [10] https://bugs.openjdk.java.net/browse/JDK-4639129 > > [11] https://bugs.openjdk.java.net/browse/JDK-4625822 > > [12] > > https://stackoverflow.com/questions/21859417/header-must-be-terminated-by-a-line-break-eclipse-manifest-mf > > [13] https://bugs.eclipse.org/bugs/show_bug.cgi?id=377249 > > [14] https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4274235 > > > > <20191011-manifest-eof.patch> From kiran.sidhartha.ravikumar at oracle.com Mon Nov 4 10:04:55 2019 From: kiran.sidhartha.ravikumar at oracle.com (Kiran Ravikumar) Date: Mon, 4 Nov 2019 10:04:55 +0000 Subject: RFR: 8232984: Upgrading Joni License version to 2.1.16 Message-ID: Hi, Please review this patch to update the joni version to 2.1.16. JBS: https://bugs.openjdk.java.net/browse/JDK-8232984 License File: https://github.com/jruby/joni/blob/joni-2.1.16/LICENSE Patch File: diff -r ab4db38ed085 src/jdk.scripting.nashorn/share/legal/joni.md --- a/src/jdk.scripting.nashorn/share/legal/joni.md???? Fri Nov 01 16:16:05 2019 +0100 +++ b/src/jdk.scripting.nashorn/share/legal/joni.md???? Mon Nov 04 09:57:41 2019 +0000 @@ -1,9 +1,9 @@ -## JRuby Joni v1.1.9 +## JRuby Joni v2.1.16 -### JRuby License +### MIT License ?

-Jruby 2012
+Copyright (c) 2017 JRuby Team

 ?Permission is hereby granted, free of charge, to any person obtaining a
 ?copy of this software and associated documentation files (the "Software"),


Thanks,

Kiran


From sean.coffey at oracle.com  Mon Nov  4 12:08:09 2019
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Mon, 4 Nov 2019 12:08:09 +0000
Subject: RFR: 8232984: Upgrading Joni License version to 2.1.16
In-Reply-To: 
References: 
Message-ID: <75d26b88-6179-5ec1-53ea-0f84b0d91db5@oracle.com>

Looks fine to me. I can push this for you.

Regards,
Sean.

On 04/11/19 10:04, Kiran Ravikumar wrote:
> Hi,
>
> Please review this patch to update the joni version to 2.1.16.
>
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8232984
>
> License File: https://github.com/jruby/joni/blob/joni-2.1.16/LICENSE
>
> Patch File:
>
> diff -r ab4db38ed085 src/jdk.scripting.nashorn/share/legal/joni.md
> --- a/src/jdk.scripting.nashorn/share/legal/joni.md     Fri Nov 01 
> 16:16:05 2019 +0100
> +++ b/src/jdk.scripting.nashorn/share/legal/joni.md     Mon Nov 04 
> 09:57:41 2019 +0000
> @@ -1,9 +1,9 @@
> -## JRuby Joni v1.1.9
> +## JRuby Joni v2.1.16
>
> -### JRuby License
> +### MIT License
>  
>
> -Jruby 2012
> +Copyright (c) 2017 JRuby Team
>
>  Permission is hereby granted, free of charge, to any person obtaining a
>  copy of this software and associated documentation files (the 
> "Software"),
>
>
> Thanks,
>
> Kiran
>


From andy.herrick at oracle.com  Mon Nov  4 14:36:41 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Mon, 4 Nov 2019 09:36:41 -0500
Subject: RFR: JDK-8232919: If user installs msi and exe, two installations
 are found in Add/Remove
In-Reply-To: <35fe3109-9d9e-4af4-22e2-d3762f1b6f8b@oracle.com>
References: <86bca240-6272-1576-2110-3816e5d7f7c7@oracle.com>
 <2754f1df-901a-049e-7bc7-74cd25596fa5@oracle.com>
 <249ce5eb-147d-a1f8-69ec-7742172c383f@oracle.com>
 
 <35fe3109-9d9e-4af4-22e2-d3762f1b6f8b@oracle.com>
Message-ID: <9cd5f863-4197-a9cb-8ad3-7d75f3195c2f@oracle.com>

technically - even this minuscule change in CompileJavaModules should be 
reviewed by build team.

overall this looks good.? I might agree that the variables that can be 
overridden in overrides.wxi need to be documented, possibly in a comment 
in the default overrides.wxi.

/Andy

On 11/2/2019 1:26 AM, Alexander Matveev wrote:
> Hi Alexey,
>
> On 11/1/2019 9:00 PM, Alexey Semenyuk wrote:
>>
>>
>> On 11/1/2019 9:45 PM, Alexander Matveev wrote:
>>> Hi Alexey,
>>>
>>> http://cr.openjdk.java.net/~asemenyuk/8232919/webrev.00/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/main.wxs.frames.html 
>>>
>>> This file refers to JpAllowDowngrades and JpAllowUpgrades. Code sets 
>>> JpAllowUpgrades to yes always and never sets JpAllowDowngrades. 
>>> Maybe I am missing something, but why we need these defs in .wxs 
>>> file if they do nothing.
>> We need these defs so that if people would like to customize update 
>> rules of their msi installer they can set only WiX variables instead 
>> of replacing the whole default main.wxs.
>> Say, they would like to enable downgrades in their installers and the 
>> other defaults would work for them. Then they would need to put only 
>> overrides.wxi in resource directory with the following contents:
>> 
>> 
>> ? 
>> 
> Should we put help into overrides.wxi to show what can be changed. For 
> example:
> 
> ?
> 
> 
> 
>>
>>> Also, I think we should allow downgrades by default.
>> I don't have any particular preferences on the matter. However there 
>> are other options, like allow side-by-side installation of different 
>> versions of the same application. Should we allow this by default?
>> Whatever defaults we would pick up, they wouldn't work for all people 
>> and we need convenient way to adjust them without the need to replace 
>> the whole main.wxs.
> Agree. I think it might be good idea to keep defaults same or close as 
> possible to other platforms. macOS should allow downgrades by default 
> as far as I know. Not sure about Linux.
>
> Thanks,
> Alexander
>>
>> - Alexey
>>>
>>> Thanks,
>>> Alexander
>>>
>>> On 11/1/2019 5:06 PM, Alexey Semenyuk 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).
>>>>
>>>> Additionally:
>>>> - added support for `overrides.wxi` WiX source file in resource 
>>>> dir. Custom overrides.wxi can be used as a placeholder for 
>>>> overrides of default WiX variables defined by jpackage that control 
>>>> output msi.
>>>>
>>>> - Alexey
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8232919
>>>>
>>>> [2] http://cr.openjdk.java.net/~asemenyuk/8232919/webrev.00
>>>>
>>>
>>
>

From henry.jen at oracle.com  Mon Nov  4 17:21:39 2019
From: henry.jen at oracle.com (Henry Jen)
Date: Mon, 4 Nov 2019 09:21:39 -0800
Subject: JDK-8231863 bug fix candidate
In-Reply-To: 
References: 
Message-ID: <6788F903-A838-4D86-B511-DD7E64E9CE2B@oracle.com>

The fix is on the spot, good catch.

As the test, test/jdk/tools/launcher/ArgsFileTest.java is testing the file expansions, we can add a test case there to have an argument file not have newline at the end, and check that we get correct arguments.

Cheers,
Henry


> On Nov 1, 2019, at 7:06 AM, Mat Carter  wrote:
> 
> Hello core-libs-dev
> 
> I'm a VM engineer at Microsoft, now that we've signed the OCA (news of which was shared by Bruno Borges in the discuss mailing list) I wanted to pick up an issue in order to gain familiarity with the change process
> 
> After reproducing the error reported in "JDK-8231863: Crash if classpath is read from @argument file and the main gets option argument" (https://bugs.openjdk.java.net/browse/JDK-8231863), I've identified the root cause and a candidate fix.
> 
> As such I'd like to pick this issue up, assuming its current state of unassigned still holds what's the process of having it assigned to me or having it somehow reserved as I don't want to cause unnecessary duplicated work.
> 
> As well as validating the fix in the debugger on WIndows and Linux, I've run the AdoptOpenJDK sanity tests on Mac, Windows and Linux for both tip and 11u.
> 
> I'm currently figuring out where/how to write regression tests for this case; input from this mailing list would be welcomed (examples of tests for similar bugs etc)
> 
> This error occurs on all platforms (tip + 11u) but only results in a crash on Windows in java_md.c due to that platforms dependency on JLI_GetAppArgIndex().  Note that while the error is 100% reproducible, the crash only occurs <10%.  The following change fixes that problem by passing in the final token fragment from the argument file into the state machine via checkArg()
> 
> --- a/src/java.base/share/native/libjli/args.c
> +++ b/src/java.base/share/native/libjli/args.c
> @@ -337,7 +337,9 @@ static JLI_List readArgFile(FILE *file) {
>      // remaining partial token
>      if (ctx.state == IN_TOKEN || ctx.state == IN_QUOTE) {
>          if (ctx.parts->size != 0) {
> -            JLI_List_add(rv, JLI_List_combine(ctx.parts));
> +            token = JLI_List_combine(ctx.parts);
> +            checkArg(token);
> +            JLI_List_add(rv, token);
>          }
>      }
>      JLI_List_free(ctx.parts);
> 
> The fix tackles the memory corruption indirectly.  Further preventative changes could be made in java_md.c/CreateApplicationArgs to avoid future memory corruptions (caused by JLI_GetAppArgIndex() returning -1 in this case) ; but I felt that that handling those error cases ran secondary to addressing the bug in the argument file parsing code.
> 
> Cheers
> Mat


From henry.jen at oracle.com  Mon Nov  4 20:47:08 2019
From: henry.jen at oracle.com (Henry Jen)
Date: Mon, 4 Nov 2019 12:47:08 -0800
Subject: JDK-8231863 bug fix candidate
In-Reply-To: <6788F903-A838-4D86-B511-DD7E64E9CE2B@oracle.com>
References: 
 <6788F903-A838-4D86-B511-DD7E64E9CE2B@oracle.com>
Message-ID: <8EC6F4F1-EAF6-4EB3-9F7F-F7A37A759E84@oracle.com>

Hi Mat,

I?ll sponsor this fix, let me know if you are coming up with test and I?ll work with you to get your patch committed.

Cheers,
Henry


> On Nov 4, 2019, at 9:21 AM, Henry Jen  wrote:
> 
> The fix is on the spot, good catch.
> 
> As the test, test/jdk/tools/launcher/ArgsFileTest.java is testing the file expansions, we can add a test case there to have an argument file not have newline at the end, and check that we get correct arguments.
> 
> Cheers,
> Henry
> 
> 
>> On Nov 1, 2019, at 7:06 AM, Mat Carter  wrote:
>> 
>> Hello core-libs-dev
>> 
>> I'm a VM engineer at Microsoft, now that we've signed the OCA (news of which was shared by Bruno Borges in the discuss mailing list) I wanted to pick up an issue in order to gain familiarity with the change process
>> 
>> After reproducing the error reported in "JDK-8231863: Crash if classpath is read from @argument file and the main gets option argument" (https://bugs.openjdk.java.net/browse/JDK-8231863), I've identified the root cause and a candidate fix.
>> 
>> As such I'd like to pick this issue up, assuming its current state of unassigned still holds what's the process of having it assigned to me or having it somehow reserved as I don't want to cause unnecessary duplicated work.
>> 
>> As well as validating the fix in the debugger on WIndows and Linux, I've run the AdoptOpenJDK sanity tests on Mac, Windows and Linux for both tip and 11u.
>> 
>> I'm currently figuring out where/how to write regression tests for this case; input from this mailing list would be welcomed (examples of tests for similar bugs etc)
>> 
>> This error occurs on all platforms (tip + 11u) but only results in a crash on Windows in java_md.c due to that platforms dependency on JLI_GetAppArgIndex().  Note that while the error is 100% reproducible, the crash only occurs <10%.  The following change fixes that problem by passing in the final token fragment from the argument file into the state machine via checkArg()
>> 
>> --- a/src/java.base/share/native/libjli/args.c
>> +++ b/src/java.base/share/native/libjli/args.c
>> @@ -337,7 +337,9 @@ static JLI_List readArgFile(FILE *file) {
>>     // remaining partial token
>>     if (ctx.state == IN_TOKEN || ctx.state == IN_QUOTE) {
>>         if (ctx.parts->size != 0) {
>> -            JLI_List_add(rv, JLI_List_combine(ctx.parts));
>> +            token = JLI_List_combine(ctx.parts);
>> +            checkArg(token);
>> +            JLI_List_add(rv, token);
>>         }
>>     }
>>     JLI_List_free(ctx.parts);
>> 
>> The fix tackles the memory corruption indirectly.  Further preventative changes could be made in java_md.c/CreateApplicationArgs to avoid future memory corruptions (caused by JLI_GetAppArgIndex() returning -1 in this case) ; but I felt that that handling those error cases ran secondary to addressing the bug in the argument file parsing code.
>> 
>> Cheers
>> Mat
> 


From vicente.romero at oracle.com  Mon Nov  4 20:54:59 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Mon, 4 Nov 2019 15:54:59 -0500
Subject: RFR: CSR Core-libs support for records
Message-ID: <4228cc74-7c04-5001-1998-3f7012e02775@oracle.com>

Hi,

Please review the draft of the CSR for Core-libs support for records at [1]

Thanks,
Vicente

[1] https://bugs.openjdk.java.net/browse/JDK-8233436

From fw at deneb.enyo.de  Mon Nov  4 21:27:57 2019
From: fw at deneb.enyo.de (Florian Weimer)
Date: Mon, 04 Nov 2019 22:27:57 +0100
Subject: RFR: CSR Core-libs support for records
In-Reply-To: <4228cc74-7c04-5001-1998-3f7012e02775@oracle.com> (Vicente
 Romero's message of "Mon, 4 Nov 2019 15:54:59 -0500")
References: <4228cc74-7c04-5001-1998-3f7012e02775@oracle.com>
Message-ID: <878sovgwma.fsf@mid.deneb.enyo.de>

* Vicente Romero:

> Please review the draft of the CSR for Core-libs support for records at [1]
>
> Thanks,
> Vicente
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8233436

I would have expected something regarding serialization in the
description of java.lang.Record.

Right now, it appears to be possible to have a record implement
java.io.Serializable, and serialization will appear to work, but
because the names of the implicitly generated private fields are not
specified, it is not portable across compilers and even compiler
versions.

From Matthew.Carter at microsoft.com  Mon Nov  4 21:30:49 2019
From: Matthew.Carter at microsoft.com (Mat Carter)
Date: Mon, 4 Nov 2019 21:30:49 +0000
Subject: JDK-8231863 bug fix candidate
In-Reply-To: <6788F903-A838-4D86-B511-DD7E64E9CE2B@oracle.com>
References: ,
 <6788F903-A838-4D86-B511-DD7E64E9CE2B@oracle.com>
Message-ID: 

Thanks for confirmation and for updating the bug Henry.

Please let me know if there's anything else related to this issue I can help with; tests and/or verification etc.

In the meantime, I'll take a look at the existing ArgsFile tests for my own education.

Cheers
Mat
________________________________
From: Henry Jen 
Sent: Monday, November 4, 2019 9:21 AM
To: Mat Carter 
Cc: core-libs-dev at openjdk.java.net 
Subject: Re: JDK-8231863 bug fix candidate

The fix is on the spot, good catch.

As the test, test/jdk/tools/launcher/ArgsFileTest.java is testing the file expansions, we can add a test case there to have an argument file not have newline at the end, and check that we get correct arguments.

Cheers,
Henry


> On Nov 1, 2019, at 7:06 AM, Mat Carter  wrote:
>
> Hello core-libs-dev
>
> I'm a VM engineer at Microsoft, now that we've signed the OCA (news of which was shared by Bruno Borges in the discuss mailing list) I wanted to pick up an issue in order to gain familiarity with the change process
>
> After reproducing the error reported in "JDK-8231863: Crash if classpath is read from @argument file and the main gets option argument" (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8231863&data=02%7C01%7CMatthew.Carter%40microsoft.com%7C9b5c79a7e6554d6ee8ac08d7614b7614%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637084959537829868&sdata=Phjbn2LibUnrnkg%2BsJhciIIXCIFi086pK0dBoleXJr8%3D&reserved=0), I've identified the root cause and a candidate fix.
>
> As such I'd like to pick this issue up, assuming its current state of unassigned still holds what's the process of having it assigned to me or having it somehow reserved as I don't want to cause unnecessary duplicated work.
>
> As well as validating the fix in the debugger on WIndows and Linux, I've run the AdoptOpenJDK sanity tests on Mac, Windows and Linux for both tip and 11u.
>
> I'm currently figuring out where/how to write regression tests for this case; input from this mailing list would be welcomed (examples of tests for similar bugs etc)
>
> This error occurs on all platforms (tip + 11u) but only results in a crash on Windows in java_md.c due to that platforms dependency on JLI_GetAppArgIndex().  Note that while the error is 100% reproducible, the crash only occurs <10%.  The following change fixes that problem by passing in the final token fragment from the argument file into the state machine via checkArg()
>
> --- a/src/java.base/share/native/libjli/args.c
> +++ b/src/java.base/share/native/libjli/args.c
> @@ -337,7 +337,9 @@ static JLI_List readArgFile(FILE *file) {
>      // remaining partial token
>      if (ctx.state == IN_TOKEN || ctx.state == IN_QUOTE) {
>          if (ctx.parts->size != 0) {
> -            JLI_List_add(rv, JLI_List_combine(ctx.parts));
> +            token = JLI_List_combine(ctx.parts);
> +            checkArg(token);
> +            JLI_List_add(rv, token);
>          }
>      }
>      JLI_List_free(ctx.parts);
>
> The fix tackles the memory corruption indirectly.  Further preventative changes could be made in java_md.c/CreateApplicationArgs to avoid future memory corruptions (caused by JLI_GetAppArgIndex() returning -1 in this case) ; but I felt that that handling those error cases ran secondary to addressing the bug in the argument file parsing code.
>
> Cheers
> Mat


From joe.darcy at oracle.com  Mon Nov  4 23:22:22 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 4 Nov 2019 15:22:22 -0800
Subject: RFR: CSR Core-libs support for records
In-Reply-To: <878sovgwma.fsf@mid.deneb.enyo.de>
References: <4228cc74-7c04-5001-1998-3f7012e02775@oracle.com>
 <878sovgwma.fsf@mid.deneb.enyo.de>
Message-ID: <2436079e-7047-675d-5eb1-e0723d3f94a9@oracle.com>

Hello,

On 11/4/2019 1:27 PM, Florian Weimer wrote:
> * Vicente Romero:
>
>> Please review the draft of the CSR for Core-libs support for records at [1]
>>
>> Thanks,
>> Vicente
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8233436
> I would have expected something regarding serialization in the
> description of java.lang.Record.
>
> Right now, it appears to be possible to have a record implement
> java.io.Serializable, and serialization will appear to work, but
> because the names of the implicitly generated private fields are not
> specified, it is not portable across compilers and even compiler
> versions.

There is a separate serialization spec update for records that has been 
discussed on the amber lists.

It isn't unreasonable for java.lang.Record to make some mention of the 
special treatment by serialization. (As a point of reference, 
java.lang.Enum does *not* reference the special handling of enums of 
serialization.)

I think a reference to the serialization spec in java.lang.Record would 
suffice.

Cheers,

-Joe


From Matthew.Carter at microsoft.com  Mon Nov  4 23:40:33 2019
From: Matthew.Carter at microsoft.com (Mat Carter)
Date: Mon, 4 Nov 2019 23:40:33 +0000
Subject: JDK-8231863 bug fix candidate
In-Reply-To: <8EC6F4F1-EAF6-4EB3-9F7F-F7A37A759E84@oracle.com>
References: 
 <6788F903-A838-4D86-B511-DD7E64E9CE2B@oracle.com>,
 <8EC6F4F1-EAF6-4EB3-9F7F-F7A37A759E84@oracle.com>
Message-ID: 

Thanks Henry

I'm working on a test, do you want me to share directly with you (incl. questions) or continue with comms through the mailing list

Cheers
Mat

________________________________
From: Henry Jen 
Sent: Monday, November 4, 2019 12:47 PM
To: Mat Carter 
Cc: core-libs-dev at openjdk.java.net 
Subject: Re: JDK-8231863 bug fix candidate

Hi Mat,

I?ll sponsor this fix, let me know if you are coming up with test and I?ll work with you to get your patch committed.

Cheers,
Henry


> On Nov 4, 2019, at 9:21 AM, Henry Jen  wrote:
>
> The fix is on the spot, good catch.
>
> As the test, test/jdk/tools/launcher/ArgsFileTest.java is testing the file expansions, we can add a test case there to have an argument file not have newline at the end, and check that we get correct arguments.
>
> Cheers,
> Henry
>
>
>> On Nov 1, 2019, at 7:06 AM, Mat Carter  wrote:
>>
>> Hello core-libs-dev
>>
>> I'm a VM engineer at Microsoft, now that we've signed the OCA (news of which was shared by Bruno Borges in the discuss mailing list) I wanted to pick up an issue in order to gain familiarity with the change process
>>
>> After reproducing the error reported in "JDK-8231863: Crash if classpath is read from @argument file and the main gets option argument" (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8231863&data=02%7C01%7CMatthew.Carter%40microsoft.com%7C657f0afad82b4d31670a08d761682b0b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637085026486748197&sdata=19S%2BLGCPaoy0h2YmbKrKfsC21d6B43rITkZhnAKyuHw%3D&reserved=0), I've identified the root cause and a candidate fix.
>>
>> As such I'd like to pick this issue up, assuming its current state of unassigned still holds what's the process of having it assigned to me or having it somehow reserved as I don't want to cause unnecessary duplicated work.
>>
>> As well as validating the fix in the debugger on WIndows and Linux, I've run the AdoptOpenJDK sanity tests on Mac, Windows and Linux for both tip and 11u.
>>
>> I'm currently figuring out where/how to write regression tests for this case; input from this mailing list would be welcomed (examples of tests for similar bugs etc)
>>
>> This error occurs on all platforms (tip + 11u) but only results in a crash on Windows in java_md.c due to that platforms dependency on JLI_GetAppArgIndex().  Note that while the error is 100% reproducible, the crash only occurs <10%.  The following change fixes that problem by passing in the final token fragment from the argument file into the state machine via checkArg()
>>
>> --- a/src/java.base/share/native/libjli/args.c
>> +++ b/src/java.base/share/native/libjli/args.c
>> @@ -337,7 +337,9 @@ static JLI_List readArgFile(FILE *file) {
>>     // remaining partial token
>>     if (ctx.state == IN_TOKEN || ctx.state == IN_QUOTE) {
>>         if (ctx.parts->size != 0) {
>> -            JLI_List_add(rv, JLI_List_combine(ctx.parts));
>> +            token = JLI_List_combine(ctx.parts);
>> +            checkArg(token);
>> +            JLI_List_add(rv, token);
>>         }
>>     }
>>     JLI_List_free(ctx.parts);
>>
>> The fix tackles the memory corruption indirectly.  Further preventative changes could be made in java_md.c/CreateApplicationArgs to avoid future memory corruptions (caused by JLI_GetAppArgIndex() returning -1 in this case) ; but I felt that that handling those error cases ran secondary to addressing the bug in the argument file parsing code.
>>
>> Cheers
>> Mat
>


From mark.reinhold at oracle.com  Tue Nov  5 00:25:06 2019
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon, 04 Nov 2019 16:25:06 -0800
Subject: Further comments on jpackage (JEP 343)
Message-ID: <20191104162506.890432047@eggemoggin.niobe.net>

Today I took the jpackage tool for another spin, using build
14-jpackage+1-64 from https://jdk.java.net/jpackage.

This looks much better!  The simple command line

  $ jpackage -p lib -m org.openjdk.hello -n hello

did exactly what I expected, and the resulting package installed (and
uninstalled) cleanly on an Ubuntu 18.04 machine.

A few suggestions:

  - The image for the above example is large for such a trivial
    application (122MB).  That?s because you invoke the jlink tool with
    the `--bind-services` option.  To avoid surprise I suggest that you
    not do that by default, and add a `--bind-services` option to
    jpackage that?s just passed through to jlink (like `--add-modules`).
    That will make jpackage work in the same way as jlink in this regard,
    further reducing confusion.

  - The sample usages in the help output are overly focused on
    application images.  I suspect that most developers will want to
    start by creating actual packages, so consider reordering the
    examples to put application packages first, followed by application
    images and then runtime images.  You could simplify these first
    examples further by removing the `--package-type ` and
    describing them as ?Generate an application package suitable for
    the host system?.

  - Consider renaming the `--package-type` option to `--type`, with a
    short-form option `-t`.

- Mark

From vicente.romero at oracle.com  Tue Nov  5 02:10:51 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Mon, 4 Nov 2019 21:10:51 -0500
Subject: RFR: CSR javax.lang.model support for records
Message-ID: 

Hi,

Please review the draft of the CSR for javax.lang.model support for 
records at [1]

Thanks,
Vicente

[1]https://bugs.openjdk.java.net/browse/JDK-8233546

From henry.jen at oracle.com  Tue Nov  5 03:35:01 2019
From: henry.jen at oracle.com (Henry Jen)
Date: Mon, 4 Nov 2019 19:35:01 -0800
Subject: JDK-8231863 bug fix candidate
In-Reply-To: 
References: 
 <6788F903-A838-4D86-B511-DD7E64E9CE2B@oracle.com>
 <8EC6F4F1-EAF6-4EB3-9F7F-F7A37A759E84@oracle.com>
 
Message-ID: <18897794-BB76-4062-A199-14654441D704@oracle.com>

Whatever you are comfortable with, we will have the final patch reviewed on the public list though.

Please keep me in the direct email recipient to make sure I read the email in time.

Cheers,
Henry


> On Nov 4, 2019, at 3:40 PM, Mat Carter  wrote:
> 
> Thanks Henry
> 
> I'm working on a test, do you want me to share directly with you (incl. questions) or continue with comms through the mailing list
> 
> Cheers
> Mat
> 
> From: Henry Jen 
> Sent: Monday, November 4, 2019 12:47 PM
> To: Mat Carter 
> Cc: core-libs-dev at openjdk.java.net 
> Subject: Re: JDK-8231863 bug fix candidate
>  
> Hi Mat,
> 
> I?ll sponsor this fix, let me know if you are coming up with test and I?ll work with you to get your patch committed.
> 
> Cheers,
> Henry
> 
> 
> > On Nov 4, 2019, at 9:21 AM, Henry Jen  wrote:
> > 
> > The fix is on the spot, good catch.
> > 
> > As the test, test/jdk/tools/launcher/ArgsFileTest.java is testing the file expansions, we can add a test case there to have an argument file not have newline at the end, and check that we get correct arguments.
> > 
> > Cheers,
> > Henry
> > 
> > 
> >> On Nov 1, 2019, at 7:06 AM, Mat Carter  wrote:
> >> 
> >> Hello core-libs-dev
> >> 
> >> I'm a VM engineer at Microsoft, now that we've signed the OCA (news of which was shared by Bruno Borges in the discuss mailing list) I wanted to pick up an issue in order to gain familiarity with the change process
> >> 
> >> After reproducing the error reported in "JDK-8231863: Crash if classpath is read from @argument file and the main gets option argument" (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8231863&data=02%7C01%7CMatthew.Carter%40microsoft.com%7C657f0afad82b4d31670a08d761682b0b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637085026486748197&sdata=19S%2BLGCPaoy0h2YmbKrKfsC21d6B43rITkZhnAKyuHw%3D&reserved=0), I've identified the root cause and a candidate fix.
> >> 
> >> As such I'd like to pick this issue up, assuming its current state of unassigned still holds what's the process of having it assigned to me or having it somehow reserved as I don't want to cause unnecessary duplicated work.
> >> 
> >> As well as validating the fix in the debugger on WIndows and Linux, I've run the AdoptOpenJDK sanity tests on Mac, Windows and Linux for both tip and 11u.
> >> 
> >> I'm currently figuring out where/how to write regression tests for this case; input from this mailing list would be welcomed (examples of tests for similar bugs etc)
> >> 
> >> This error occurs on all platforms (tip + 11u) but only results in a crash on Windows in java_md.c due to that platforms dependency on JLI_GetAppArgIndex().  Note that while the error is 100% reproducible, the crash only occurs <10%.  The following change fixes that problem by passing in the final token fragment from the argument file into the state machine via checkArg()
> >> 
> >> --- a/src/java.base/share/native/libjli/args.c
> >> +++ b/src/java.base/share/native/libjli/args.c
> >> @@ -337,7 +337,9 @@ static JLI_List readArgFile(FILE *file) {
> >>     // remaining partial token
> >>     if (ctx.state == IN_TOKEN || ctx.state == IN_QUOTE) {
> >>         if (ctx.parts->size != 0) {
> >> -            JLI_List_add(rv, JLI_List_combine(ctx.parts));
> >> +            token = JLI_List_combine(ctx.parts);
> >> +            checkArg(token);
> >> +            JLI_List_add(rv, token);
> >>         }
> >>     }
> >>     JLI_List_free(ctx.parts);
> >> 
> >> The fix tackles the memory corruption indirectly.  Further preventative changes could be made in java_md.c/CreateApplicationArgs to avoid future memory corruptions (caused by JLI_GetAppArgIndex() returning -1 in this case) ; but I felt that that handling those error cases ran secondary to addressing the bug in the argument file parsing code.
> >> 
> >> Cheers
> >> Mat
> > 
> 


From chris.hegarty at oracle.com  Tue Nov  5 09:37:20 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 5 Nov 2019 09:37:20 +0000
Subject: RFR: CSR Core-libs support for records
In-Reply-To: <878sovgwma.fsf@mid.deneb.enyo.de>
References: <4228cc74-7c04-5001-1998-3f7012e02775@oracle.com>
 <878sovgwma.fsf@mid.deneb.enyo.de>
Message-ID: 



> On 4 Nov 2019, at 21:27, Florian Weimer  wrote:
> 
> ...
> Right now, it appears to be possible to have a record implement
> java.io.Serializable, and serialization will appear to work, but
> because the names of the implicitly generated private fields are not
> specified, it is not portable across compilers and even compiler
> versions.


The private fields are specified. From 8.10.3 - Record Members [1]:

  ...
  For each record component appearing in the record component list:

	? An implicitly declared private final field with the same name as the record component and the type as the declared type of the record component. ? 

-Chris.

[1] https://cr.openjdk.java.net/~gbierman/jep359/jep359-20191031/specs/records-jls.html#jls-8.10.3

From jan.lahoda at oracle.com  Tue Nov  5 09:50:21 2019
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 5 Nov 2019 10:50:21 +0100
Subject: RFR: JDK-8232684: Make switch expressions final
In-Reply-To: 
References: 
 
Message-ID: 

I've missed updates to some hotspot and jdk tests in the first patch. 
The problem are unqualified invocations of Thread.yield(), which are no 
longer allowed (from the spec: JLS 3.9 Keywords: "All invocations of a 
method called yield must be qualified so as to be distinguished from a 
yield statement."). Therefore, these invocations need to be changed to 
qualified invocations (i.e. Thread.yield()). Updates to the hotspot and 
jdk tests are here:
http://cr.openjdk.java.net/~jlahoda/8232684/webrev.delta.00.01/

Full updated webrev, with changes to both javac and the tests, is here:
http://cr.openjdk.java.net/~jlahoda/8232684/webrev.01/

How does that look?

Thanks,
     Jan

On 21. 10. 19 16:17, Maurizio Cimadamore wrote:
> Looks generally good -? went through the test updates one by one and 
> they look ok, except this:
> 
> http://cr.openjdk.java.net/~jlahoda/8232684/webrev.00/test/langtools/tools/jdeps/listdeps/ListModuleDeps.java.udiff.html 
> 
> 
> Which you explained to me offline (we need to change this code every 
> time the compiler stops using the @Preview annotation - ugh). Nothing 
> specific to this webrev, so I approve.
> 
> Maurizio
> 
> On 21/10/2019 14:49, Jan Lahoda wrote:
>> Hi,
>>
>> As part of preparation for proposing JEP 361: Switch Expressions 
>> (Standard) to target, I would like to ask for a review of the patch to 
>> make switch expression a non-preview feature in javac:
>> http://cr.openjdk.java.net/~jlahoda/8232684/webrev.00/
>>
>> The patch basically removes the feature from the list of preview 
>> features, updates test to this new state (removes --enable-preview 
>> from associated tests, and adjusts their expected output), and removes 
>> the @PreviewFeature annotation and associated text from the javadoc of 
>> the Trees API.
>>
>> I also would like to ask for a review for the CSR associated with that:
>> https://bugs.openjdk.java.net/browse/JDK-8232685
>>
>> Reviews/comments on either of these would be very welcome!
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8232684
>>
>> Thanks!
>>
>> Jan

From chris.hegarty at oracle.com  Tue Nov  5 12:19:21 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 5 Nov 2019 12:19:21 +0000
Subject: RFR: CSR Core-libs support for records
In-Reply-To: <2436079e-7047-675d-5eb1-e0723d3f94a9@oracle.com>
References: <4228cc74-7c04-5001-1998-3f7012e02775@oracle.com>
 <878sovgwma.fsf@mid.deneb.enyo.de>
 <2436079e-7047-675d-5eb1-e0723d3f94a9@oracle.com>
Message-ID: 



> On 4 Nov 2019, at 23:22, Joe Darcy  wrote:
> ...
> It isn't unreasonable for java.lang.Record to make some mention of the special treatment by serialization. (As a point of reference, java.lang.Enum does *not* reference the special handling of enums of serialization.)
> 
> I think a reference to the serialization spec in java.lang.Record would suffice.

Agree. A link to subsection 1.13 - "Serialization of Records? [1], should be sufficient.

-Chris.

[1] https://cr.openjdk.java.net/~chegar/records/spec/records-serialization.05.html#serialization-of-records


From james.laskey at oracle.com  Tue Nov  5 13:58:12 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 5 Nov 2019 09:58:12 -0400
Subject: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and White
 Space (Preview)
Message-ID: 

Please review the following CSR. Provides for the introduction of two new escape sequences \ and \s.  \ allows developers to express unwieldy string literals in a text block as a cluster of short single line segments. The second is to allow developers to express ASCII space, much like \t for tab.

Thank you.

Cheers,

- Jim

CSR: https://bugs.openjdk.java.net/browse/JDK-8233117


From Roger.Riggs at oracle.com  Tue Nov  5 14:30:54 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 5 Nov 2019 09:30:54 -0500
Subject: Return value of DateFormatSymbols.getWeekdays()
In-Reply-To: 
References: 
Message-ID: 

Hi,

Please create an issue in the Jira (https://bugs.openjdk.java.net).

The appropriate email alias? is:
 ?? core-libs-dev at openjdk.java.net

Thanks, Roger

On 11/5/19 1:31 AM, Wang Zhuo(Zhuoren) wrote:
> Hi,
> I am an engineer from Alibaba, and I have a question for return value of DateFormatSymbols.getWeekdays().
> When using DateFormatSymbols.getInstance(Locale.ROOT).getWeekdays(), on JDK13 or JDK11u we get short names, such as Sun, Mon. While I think the return value should be full names, such as Sunday, Monday. The comments of this method also indicate full names.
> DateFormatSymbols.java:
>      /**
>       * Weekday strings. For example: "Sunday", "Monday", etc.  An array
>       * of 8 strings, indexed by Calendar.SUNDAY,
>       * Calendar.MONDAY, etc.
>       * The element weekdays[0] is ignored.
>       * @serial
>       */
>      String weekdays[] = null;
>
> This issue only exists in Local.ROOT, DateFormatSymbols.getInstance(Locale.US).getWeekdays() returns full names.
> I think it makes sense to return full names not short ones for Local.ROOT. What's your opinion?
>
> It seems this issue is caused by abbreviated and wide dayWidth are set the same value in root.xml. I made a patch for this, please also review it http://cr.openjdk.java.net/~wzhuo/getWeekdays//webrev.00/
>
> Regards,
> Zhuoren
>
>
>
>
>


From james.laskey at oracle.com  Tue Nov  5 15:40:37 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 5 Nov 2019 11:40:37 -0400
Subject: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and
 White Space (Preview)
In-Reply-To: 
References: 
Message-ID: <88096622-1959-4064-A656-76DC3A25729B@oracle.com>

I'm withdrawing until it is the correct format. Apologies.


> On Nov 5, 2019, at 9:58 AM, Jim Laskey  wrote:
> 
> Please review the following CSR. Provides for the introduction of two new escape sequences \ and \s.  \ allows developers to express unwieldy string literals in a text block as a cluster of short single line segments. The second is to allow developers to express ASCII space, much like \t for tab.
> 
> Thank you.
> 
> Cheers,
> 
> - Jim
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8233117
> 


From andy.herrick at oracle.com  Tue Nov  5 17:46:36 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Tue, 5 Nov 2019 12:46:36 -0500
Subject: Further comments on jpackage (JEP 343)
In-Reply-To: <20191104162506.890432047@eggemoggin.niobe.net>
References: <20191104162506.890432047@eggemoggin.niobe.net>
Message-ID: <0dc092fc-06df-462c-e80a-d8d71d059680@oracle.com>

The three suggestions below are captured in the 3 enhancements:

JDK-8233594  , 
JDK-8233592  , and 
JDK-8233591 

I should be able to have these three changes implemented, reviewed, and 
integrated by the end of this week or early next week at the latest.

/Andy


On 11/4/2019 7:25 PM, mark.reinhold at oracle.com wrote:
> Today I took the jpackage tool for another spin, using build
> 14-jpackage+1-64 from https://jdk.java.net/jpackage.
>
> This looks much better!  The simple command line
>
>    $ jpackage -p lib -m org.openjdk.hello -n hello
>
> did exactly what I expected, and the resulting package installed (and
> uninstalled) cleanly on an Ubuntu 18.04 machine.
>
> A few suggestions:
>
>    - The image for the above example is large for such a trivial
>      application (122MB).  That?s because you invoke the jlink tool with
>      the `--bind-services` option.  To avoid surprise I suggest that you
>      not do that by default, and add a `--bind-services` option to
>      jpackage that?s just passed through to jlink (like `--add-modules`).
>      That will make jpackage work in the same way as jlink in this regard,
>      further reducing confusion.
>
>    - The sample usages in the help output are overly focused on
>      application images.  I suspect that most developers will want to
>      start by creating actual packages, so consider reordering the
>      examples to put application packages first, followed by application
>      images and then runtime images.  You could simplify these first
>      examples further by removing the `--package-type ` and
>      describing them as ?Generate an application package suitable for
>      the host system?.
>
>    - Consider renaming the `--package-type` option to `--type`, with a
>      short-form option `-t`.
>
> - Mark

From james.laskey at oracle.com  Tue Nov  5 18:00:32 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 5 Nov 2019 14:00:32 -0400
Subject: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and
 White Space (Preview)
In-Reply-To: <88096622-1959-4064-A656-76DC3A25729B@oracle.com>
References: 
 <88096622-1959-4064-A656-76DC3A25729B@oracle.com>
Message-ID: <781A9EF0-9117-468E-B102-97CA4338A6EE@oracle.com>

Re-proposed.

> On Nov 5, 2019, at 11:40 AM, Jim Laskey  wrote:
> 
> I'm withdrawing until it is the correct format. Apologies.
> 
> 
>> On Nov 5, 2019, at 9:58 AM, Jim Laskey  wrote:
>> 
>> Please review the following CSR. Provides for the introduction of two new escape sequences \ and \s.  \ allows developers to express unwieldy string literals in a text block as a cluster of short single line segments. The second is to allow developers to express ASCII space, much like \t for tab.
>> 
>> Thank you.
>> 
>> Cheers,
>> 
>> - Jim
>> 
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8233117
>> 
> 


From forax at univ-mlv.fr  Tue Nov  5 18:17:19 2019
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 5 Nov 2019 19:17:19 +0100 (CET)
Subject: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and
 White Space (Preview)
In-Reply-To: <781A9EF0-9117-468E-B102-97CA4338A6EE@oracle.com>
References: 
 <88096622-1959-4064-A656-76DC3A25729B@oracle.com>
 <781A9EF0-9117-468E-B102-97CA4338A6EE@oracle.com>
Message-ID: <860162713.1334314.1572977839868.JavaMail.zimbra@u-pem.fr>

Hi Jim,
the rationale to add \ is well explain but why do you want to introduce \s given we already have \u0020 ?

R?mi 

----- Mail original -----
> De: "Jim Laskey" 
> ?: "core-libs-dev" , "compiler-dev" 
> Envoy?: Mardi 5 Novembre 2019 19:00:32
> Objet: Re: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview)

> Re-proposed.
> 
>> On Nov 5, 2019, at 11:40 AM, Jim Laskey  wrote:
>> 
>> I'm withdrawing until it is the correct format. Apologies.
>> 
>> 
>>> On Nov 5, 2019, at 9:58 AM, Jim Laskey  wrote:
>>> 
>>> Please review the following CSR. Provides for the introduction of two new escape
>>> sequences \ and \s.  \ allows developers to
>>> express unwieldy string literals in a text block as a cluster of short single
>>> line segments. The second is to allow developers to express ASCII space, much
>>> like \t for tab.
>>> 
>>> Thank you.
>>> 
>>> Cheers,
>>> 
>>> - Jim
>>> 
>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8233117
>>> 

From alex.buckley at oracle.com  Tue Nov  5 18:31:20 2019
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 5 Nov 2019 10:31:20 -0800
Subject: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and
 White Space (Preview)
In-Reply-To: <860162713.1334314.1572977839868.JavaMail.zimbra@u-pem.fr>
References: 
 <88096622-1959-4064-A656-76DC3A25729B@oracle.com>
 <781A9EF0-9117-468E-B102-97CA4338A6EE@oracle.com>
 <860162713.1334314.1572977839868.JavaMail.zimbra@u-pem.fr>
Message-ID: <56f4901a-c2d8-de86-562f-f9d75aee0b3e@oracle.com>

This should be answered in JEP 368, which currently introduces \s with 
its definition rather than a connecting line back to the final line of 
the Motivation. JEP 355 had text about the octal escape sequence \040 
and now Remi has raised \u0020 -- both should be positioned in 368 as 
less-clear options for explicit whitespace than a new escape sequence. 
Syntactic real estate for escape sequences is not in short supply, but 
there is an element of surprise that we're finally building there.

Alex

On 11/5/2019 10:17 AM, Remi Forax wrote:
> Hi Jim,
> the rationale to add \ is well explain but why do you want to introduce \s given we already have \u0020 ?
> 
> R?mi
> 
> ----- Mail original -----
>> De: "Jim Laskey" 
>> ?: "core-libs-dev" , "compiler-dev" 
>> Envoy?: Mardi 5 Novembre 2019 19:00:32
>> Objet: Re: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview)
> 
>> Re-proposed.
>>
>>> On Nov 5, 2019, at 11:40 AM, Jim Laskey  wrote:
>>>
>>> I'm withdrawing until it is the correct format. Apologies.
>>>
>>>
>>>> On Nov 5, 2019, at 9:58 AM, Jim Laskey  wrote:
>>>>
>>>> Please review the following CSR. Provides for the introduction of two new escape
>>>> sequences \ and \s.  \ allows developers to
>>>> express unwieldy string literals in a text block as a cluster of short single
>>>> line segments. The second is to allow developers to express ASCII space, much
>>>> like \t for tab.
>>>>
>>>> Thank you.
>>>>
>>>> Cheers,
>>>>
>>>> - Jim
>>>>
>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8233117
>>>>

From john.r.rose at oracle.com  Tue Nov  5 18:35:45 2019
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 5 Nov 2019 10:35:45 -0800
Subject: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and
 White Space (Preview)
In-Reply-To: <860162713.1334314.1572977839868.JavaMail.zimbra@u-pem.fr>
References: 
 <88096622-1959-4064-A656-76DC3A25729B@oracle.com>
 <781A9EF0-9117-468E-B102-97CA4338A6EE@oracle.com>
 <860162713.1334314.1572977839868.JavaMail.zimbra@u-pem.fr>
Message-ID: <504C0B28-C52B-49A3-9604-894EA76F785F@oracle.com>

On Nov 5, 2019, at 10:17 AM, Remi Forax  wrote:
> 
> the rationale to add \ is well explain but why do you want to introduce \s given we already have \u0020 ?

Remi, you are an expert in the field and you got fooled!  This is *exactly* why we need \s.

The \uXXXX syntax is expanded *before* token scanning, which means that the poor programmer
who tries \u0020 will see it stripped by the whitespace stripper.  Using \uXXXX where XXXX is
an ASCII code point is an anti-pattern!  (I think we would help our users if we deprecated it.)

You might have said \040, but that too is hard to remember and to read and to use correctly.
\s is the answer.

? John

From james.laskey at oracle.com  Tue Nov  5 18:35:39 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 5 Nov 2019 14:35:39 -0400
Subject: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and
 White Space (Preview)
In-Reply-To: <860162713.1334314.1572977839868.JavaMail.zimbra@u-pem.fr>
References: 
 <88096622-1959-4064-A656-76DC3A25729B@oracle.com>
 <781A9EF0-9117-468E-B102-97CA4338A6EE@oracle.com>
 <860162713.1334314.1572977839868.JavaMail.zimbra@u-pem.fr>
Message-ID: 

Whereas \u0020 is just another way of expressing space, it also gets consumed by trailing space stripping. Maybe you meant to say we already have \040, which I would reply that you might have the ASCII table memorized but many do not. \s also has brevity on its side.


String colors = """
    red    \040
    green  \040
    blue   \040
    """;

verses

String colors = """
    red    \s
    green  \s
    blue   \s
    """;
 
Cheers,

-- Jim


> On Nov 5, 2019, at 2:17 PM, Remi Forax  wrote:
> 
> Hi Jim,
> the rationale to add \ is well explain but why do you want to introduce \s given we already have \u0020 ?
> 
> R?mi 
> 
> ----- Mail original -----
>> De: "Jim Laskey" 
>> ?: "core-libs-dev" , "compiler-dev" 
>> Envoy?: Mardi 5 Novembre 2019 19:00:32
>> Objet: Re: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview)
> 
>> Re-proposed.
>> 
>>> On Nov 5, 2019, at 11:40 AM, Jim Laskey  wrote:
>>> 
>>> I'm withdrawing until it is the correct format. Apologies.
>>> 
>>> 
>>>> On Nov 5, 2019, at 9:58 AM, Jim Laskey  wrote:
>>>> 
>>>> Please review the following CSR. Provides for the introduction of two new escape
>>>> sequences \ and \s.  \ allows developers to
>>>> express unwieldy string literals in a text block as a cluster of short single
>>>> line segments. The second is to allow developers to express ASCII space, much
>>>> like \t for tab.
>>>> 
>>>> Thank you.
>>>> 
>>>> Cheers,
>>>> 
>>>> - Jim
>>>> 
>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8233117
>>>> 


From forax at univ-mlv.fr  Tue Nov  5 18:48:57 2019
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Tue, 5 Nov 2019 19:48:57 +0100 (CET)
Subject: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and
 White Space (Preview)
In-Reply-To: <504C0B28-C52B-49A3-9604-894EA76F785F@oracle.com>
References: 
 <88096622-1959-4064-A656-76DC3A25729B@oracle.com>
 <781A9EF0-9117-468E-B102-97CA4338A6EE@oracle.com>
 <860162713.1334314.1572977839868.JavaMail.zimbra@u-pem.fr>
 <504C0B28-C52B-49A3-9604-894EA76F785F@oracle.com>
Message-ID: <820257282.1340708.1572979737968.JavaMail.zimbra@u-pem.fr>

> De: "John Rose" 
> ?: "Remi Forax" 
> Cc: "Jim Laskey" , "compiler-dev"
> , "core-libs-dev"
> 
> Envoy?: Mardi 5 Novembre 2019 19:35:45
> Objet: Re: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and White
> Space (Preview)

> On Nov 5, 2019, at 10:17 AM, Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>> the rationale to add \ is well explain but why do you want to introduce
>> \s given we already have \u0020 ?

> Remi, you are an expert in the field and you got fooled! This is *exactly* why
> we need \s.

> The \uXXXX syntax is expanded *before* token scanning, which means that the poor
> programmer
> who tries \u0020 will see it stripped by the whitespace stripper. Using \uXXXX
> where XXXX is
> an ASCII code point is an anti-pattern! (I think we would help our users if we
> deprecated it.)

I was not thinking of the case where you put a \u0020 inside a text block at the beginning/end of a line :) 
I still think that i prefer to have a clear delimiter like '|' and a calls to replace('|', ' ') like this 

private lazy static final String text = """ 
| this | 
| is | 
| fun | 
""".replace('|', ' '); 

> You might have said \040, but that too is hard to remember and to read and to
> use correctly.
> \s is the answer.

> ? John

R?mi 

From alex.buckley at oracle.com  Tue Nov  5 18:56:20 2019
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 5 Nov 2019 10:56:20 -0800
Subject: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and
 White Space (Preview)
In-Reply-To: <781A9EF0-9117-468E-B102-97CA4338A6EE@oracle.com>
References: 
 <88096622-1959-4064-A656-76DC3A25729B@oracle.com>
 <781A9EF0-9117-468E-B102-97CA4338A6EE@oracle.com>
Message-ID: <002bcba5-4511-83c0-30dc-6001fc0d01d7@oracle.com>

I attached text-blocks-jls.html which contains the current unified text 
blocks + new escape sequences spec. Edited the CSR's Specification 
section refer specifically to section 3.10.7 of the attachment rather 
than reproducing some of that section. Made some small edits elsewhere 
related to having only two bold questions (corresponding to two new 
escapes) in the Problem.

Alex

On 11/5/2019 10:00 AM, Jim Laskey wrote:
> Re-proposed.
> 
>> On Nov 5, 2019, at 11:40 AM, Jim Laskey  wrote:
>>
>> I'm withdrawing until it is the correct format. Apologies.
>>
>>
>>> On Nov 5, 2019, at 9:58 AM, Jim Laskey  wrote:
>>>
>>> Please review the following CSR. Provides for the introduction of two new escape sequences \ and \s.  \ allows developers to express unwieldy string literals in a text block as a cluster of short single line segments. The second is to allow developers to express ASCII space, much like \t for tab.
>>>
>>> Thank you.
>>>
>>> Cheers,
>>>
>>> - Jim
>>>
>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8233117
>>>
>>
> 

From vicente.romero at oracle.com  Tue Nov  5 20:23:19 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 5 Nov 2019 15:23:19 -0500
Subject: RFR: CSR Core-libs support for records
In-Reply-To: <4228cc74-7c04-5001-1998-3f7012e02775@oracle.com>
References: <4228cc74-7c04-5001-1998-3f7012e02775@oracle.com>
Message-ID: 

I have updated the CSR after some feedback, please take a look at it. I 
have added some comments to the bug entry describing the last changes

Thanks,
Vicente

On 11/4/19 3:54 PM, Vicente Romero wrote:
> Hi,
>
> Please review the draft of the CSR for Core-libs support for records 
> at [1]
>
> Thanks,
> Vicente
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8233436


From andy.herrick at oracle.com  Tue Nov  5 20:39:15 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Tue, 5 Nov 2019 15:39:15 -0500
Subject: RFR: JDK-8233592: change --package-type option name to --type and
 allow -t short form
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).

This changes the --package-type option to just --type , and adds the -t 
short form.

[1] https://bugs.openjdk.java.net/browse/JDK-8233592

[2] https://cr.openjdk.java.net/~herrick/8233592/ 


/Andy


From alexey.semenyuk at oracle.com  Tue Nov  5 20:47:00 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Tue, 5 Nov 2019 15:47:00 -0500
Subject: RFR: JDK-8233592: change --package-type option name to --type and
 allow -t short form
In-Reply-To: 
References: 
Message-ID: 

Looks good.

- Alexey

On 11/5/2019 3:39 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 changes the --package-type option to just --type , and adds the 
> -t short form.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8233592
>
> [2] https://cr.openjdk.java.net/~herrick/8233592/ 
> 
>
> /Andy
>


From kevin.rushforth at oracle.com  Tue Nov  5 20:51:25 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 5 Nov 2019 21:51:25 +0100
Subject: RFR: JDK-8233592: change --package-type option name to --type and
 allow -t short form
In-Reply-To: 
References: 
 
Message-ID: <2953df1e-216b-0f9e-7348-3360e34391b5@oracle.com>

+1

On 11/5/2019 9:47 PM, Alexey Semenyuk wrote:
> Looks good.
>
> - Alexey
>
> On 11/5/2019 3:39 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 changes the --package-type option to just --type , and adds the 
>> -t short form.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8233592
>>
>> [2] https://cr.openjdk.java.net/~herrick/8233592/ 
>> 
>>
>> /Andy
>>
>


From naoto.sato at oracle.com  Tue Nov  5 20:48:36 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 5 Nov 2019 12:48:36 -0800
Subject: [14] RFR: 8232871: Host Locale Provider on Mac does not return
 translated values of Japanese calendar
Message-ID: <83707e65-41cb-ec0d-4a3c-005ae94967ae@oracle.com>

Hello,

Please review the fix to the following issue:

https://bugs.openjdk.java.net/browse/JDK-8232871

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8232871/webrev.00/

Implementation for getting calendar display names was missing in macOS's 
host adapter.

Naoto

From alexander.matveev at oracle.com  Tue Nov  5 23:08:29 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Tue, 5 Nov 2019 15:08:29 -0800
Subject: RFR: JDK-8233592: change --package-type option name to --type and
 allow -t short form
In-Reply-To: 
References: 
Message-ID: <6dd1b303-dddc-b166-e182-9a20dfc6faef@oracle.com>

Looks good.

On 11/5/2019 12:39 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 changes the --package-type option to just --type , and adds the 
> -t short form.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8233592
>
> [2] https://cr.openjdk.java.net/~herrick/8233592/ 
> 
>
> /Andy
>


From ivan.gerasimov at oracle.com  Tue Nov  5 23:35:20 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 5 Nov 2019 15:35:20 -0800
Subject: RFR (S) 8233650 : Javadoc for Math.floorMod(int, int) gives wrong
 example
Message-ID: 

Hello!

The javadoc for the method Math.floorMod(int, int) [1] contains an 
inaccuracy.

There are two sets of examples given:? One for the case when signs of 
the arguments are the same and the other for the case when signs of the 
arguments are different.
The second set of examples wrongly contains an example from the first set.

Would you please help review this javadoc-only fix?

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8233650
WEBREV: http://cr.openjdk.java.net/~igerasim/8233650/00/webrev/

[1] 
https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/lang/Math.html#floorMod(int,int)

-- 
With kind regards,
Ivan Gerasimov


From andy.herrick at oracle.com  Tue Nov  5 23:36:27 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Tue, 5 Nov 2019 18:36:27 -0500
Subject: RFR: JDK-8233594: create a new option --bind-servces to pass on to
 jlink
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).

This changes adds the --bind-services option and removes the previous 
behavior of always including --bind-services in the jlink options except 
when --add-modules was specified.

[1] - https://bugs.openjdk.java.net/browse/JDK-8233594

[2] - http://cr.openjdk.java.net/~herrick/8233594/

/Andy


From brian.burkhalter at oracle.com  Wed Nov  6 00:05:15 2019
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 5 Nov 2019 16:05:15 -0800
Subject: RFR (S) 8233650 : Javadoc for Math.floorMod(int, int) gives wrong
 example
In-Reply-To: 
References: 
Message-ID: <1A2720C2-E1E5-4015-8E59-471FC71C4E13@oracle.com>

Hi Ivan,

I think this looks good.

Brian

> On Nov 5, 2019, at 3:35 PM, Ivan Gerasimov  wrote:
> 
> The javadoc for the method Math.floorMod(int, int) [1] contains an inaccuracy.
> 
> There are two sets of examples given:  One for the case when signs of the arguments are the same and the other for the case when signs of the arguments are different.
> The second set of examples wrongly contains an example from the first set.
> 
> Would you please help review this javadoc-only fix?
> 
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8233650
> WEBREV: http://cr.openjdk.java.net/~igerasim/8233650/00/webrev/
> 
> [1] https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/lang/Math.html#floorMod(int,int)

From alexey.semenyuk at oracle.com  Wed Nov  6 00:30:58 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Tue, 5 Nov 2019 19:30:58 -0500
Subject: RFR: JDK-8233594: create a new option --bind-servces to pass on
 to jlink
In-Reply-To: 
References: 
Message-ID: 

Looks good.

- Alexey

On 11/5/2019 6:36 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 changes adds the --bind-services option and removes the previous 
> behavior of always including --bind-services in the jlink options 
> except when --add-modules was specified.
>
> [1] - https://bugs.openjdk.java.net/browse/JDK-8233594
>
> [2] - http://cr.openjdk.java.net/~herrick/8233594/
>
> /Andy
>


From philip.race at oracle.com  Wed Nov  6 01:02:49 2019
From: philip.race at oracle.com (Philip Race)
Date: Tue, 05 Nov 2019 17:02:49 -0800
Subject: RFR: JDK-8233594: create a new option --bind-servces to pass
 on to jlink
In-Reply-To: 
References: 
Message-ID: <5DC21BB9.3020405@oracle.com>

I noticed this problem when creating various demo scenarios so +1 to the change, but

+\          Pass on --bind-seervices option to jlink (which will link in \n\

typo here

-phil

On 11/5/19, 3:36 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 changes adds the --bind-services option and removes the previous 
> behavior of always including --bind-services in the jlink options 
> except when --add-modules was specified.
>
> [1] - https://bugs.openjdk.java.net/browse/JDK-8233594
>
> [2] - http://cr.openjdk.java.net/~herrick/8233594/
>
> /Andy
>

From alexander.matveev at oracle.com  Wed Nov  6 01:05:13 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Tue, 5 Nov 2019 17:05:13 -0800
Subject: RFR: JDK-8233594: create a new option --bind-servces to pass on
 to jlink
In-Reply-To: 
References: 
Message-ID: <174999a6-88a9-00ac-3afc-01823e932bc3@oracle.com>

Hi Andy,

http://cr.openjdk.java.net/~herrick/8233594/webrev.01/src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources.properties.frames.html

 ?106 \????????? Pass on --bind-seervices option to jlink (which will 
link in \n\
Spelling: --bind-seervices -> --bind-services

Otherwise looks fine.

Thanks,
Alexander

On 11/5/2019 3:36 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 changes adds the --bind-services option and removes the previous 
> behavior of always including --bind-services in the jlink options 
> except when --add-modules was specified.
>
> [1] - https://bugs.openjdk.java.net/browse/JDK-8233594
>
> [2] - http://cr.openjdk.java.net/~herrick/8233594/
>
> /Andy
>


From joe.darcy at oracle.com  Wed Nov  6 02:04:12 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 5 Nov 2019 18:04:12 -0800
Subject: JDK 14 RFR of JDK-8233452: java.math.BigDecimal.sqrt() with
 RoundingMode.FLOOR results in incorrect result
Message-ID: <402ee79d-4c8c-7af1-10fc-f8a8bf0864de@oracle.com>

Hello,

Please review the changes to fix

 ??? JDK-8233452: java.math.BigDecimal.sqrt() with RoundingMode.FLOOR 
results in incorrect result
 ??? http://cr.openjdk.java.net/~darcy/8233452.0/

Some background on the problem and fix.

The core of the BigDecimal.sqrt method is a Newton-Raphson loop. Given a 
sufficiently good initial value and given various other side conditions 
which hold for the square root function, the iteration converges 
quadratically, in this case to the square root of the receiver 
BigDecimal. The iteration starts using an initial value computed using 
Math.sqrt, which is sufficiently good for convergence.

Colloquially, quadratic convergence is described as "double the number 
of digits right" at each step. More formally, the error bound is reduced 
such that the error bound of the (k+1)st iteration is a function of the 
square of the error bound of the k-th iteration where the error bound is 
<< 1.

There are three basic rounding policies on BigDecimal operations:

1) Return an exact result (precision = 0 or RoundingMode.UNNECESSARY).
2) Return the nearest result, choosing a policy for ties (HALF_DOWN, 
HALF_EVEN, HALF_UP).
3) Directed rounding? (UP, DOWN, CEILING, FLOOR)

Since sqrt is only defined for non-negative values, UP and CEILING are 
equivalent for that function as are DOWN and FLOOR.

The directed roundings can have an error as much as 1 ulp (unit in the 
last place) as opposed to an error of only 1/2 ulp under the to-nearest 
rounding modes.? For example, say the true answer is between 1 and 2 
when rounding to integers. Under a to-nearest policy the largest 
difference between the true numerical answer and the returned results is 
at most 0.5; the true answer of 1.5 would round to either 1 or 2 
depending on how ties were handled. In contrast, under a directed 
rounding the largest difference can be nearly 1. If the true result is 
1.9999999.... and rounding down, the returned results will be 1 and the 
difference will be 0.9999999....

The Newton iteration reduces the error at each step and, as currently 
written, it can settle on a value like 2, which is closer to the actual 
answer, but *incorrect* according to the requested rounding mode.

There are a few ways to fix this one. One is to run the Newton loop to a 
higher-precision where these finer distinctions can be teased out. If 
the result is to have a p digits of accuracty, if the loop is run to 
have 2p+2 digits of precision, the correct final answer will be 
computed. (Proof of this property for floating-point arithmetic is 
discussed in various numerical references.) This approach has the 
disadvantage of running under higher precision at some performance cost. 
A reference implementation using this technique was added to the 
regression test.

Another approach is to detect when the result is too large/too small and 
then subtract/add an ulp as a fix-up. This is the approach taken for 
BigDecimal.sqrt. It should be a relatively inexpensive detection and 
fixup using a multiply, a compare, and possibility an add/subtract? as 
opposed to another divide operation under higher precision from going 
around the loop again. If enabled, the existing assertions in BigDecimal 
catch the erroneous answer computed by the existing code since it is 
detected as not bracketing the true result. The assertions pass when the 
need code is run against the previously problematic cases.

An approach not explored for this fix would be to arrange for the 
iteration to start from the "right" side of the number line depending on 
the rounding mode and then monotonically increase/decrease to approach 
the square root. For example, if rounding down, to start from a value 
greater than then root and then have each iteration decrease toward the 
final result. I believe this is technically possible, but would require 
some additional analysis to setup.

Thanks,

-Joe


From huaming.li at oracle.com  Wed Nov  6 02:07:22 2019
From: huaming.li at oracle.com (Hamlin Li)
Date: Wed, 6 Nov 2019 10:07:22 +0800
Subject: RFR of JDK-8232446: logging enhancement for rmi when socket closed
Message-ID: <5048d354-a480-ac6d-e46d-a14ce4349691@oracle.com>

Would you please review the patch?

bug: https://bugs.openjdk.java.net/browse/JDK-8232446

webrev: http://cr.openjdk.java.net/~mli/8232446/webrev.00/


We have some intermittent failures in rmi related to socket closing, 
this is to add more logging to help diagnose the issues.


Thanks you

-Hamlin


From kevin.rushforth at oracle.com  Wed Nov  6 04:18:15 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 6 Nov 2019 05:18:15 +0100
Subject: RFR: JDK-8233594: create a new option --bind-servces to pass on
 to jlink
In-Reply-To: <5DC21BB9.3020405@oracle.com>
References: 
 <5DC21BB9.3020405@oracle.com>
Message-ID: <58a2d94b-6de5-baed-8427-fa6a5b8214c9@oracle.com>

Yes, this is a good change.

+1

-- Kevin

On 11/6/2019 2:02 AM, Philip Race wrote:
> I noticed this problem when creating various demo scenarios so +1 to 
> the change, but
>
> +\????????? Pass on --bind-seervices option to jlink (which will link 
> in \n\
>
> typo here
>
> -phil
>
> On 11/5/19, 3:36 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 changes adds the --bind-services option and removes the previous 
>> behavior of always including --bind-services in the jlink options 
>> except when --add-modules was specified.
>>
>> [1] - https://bugs.openjdk.java.net/browse/JDK-8233594
>>
>> [2] - http://cr.openjdk.java.net/~herrick/8233594/
>>
>> /Andy
>>


From ivan.gerasimov at oracle.com  Wed Nov  6 04:28:48 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 5 Nov 2019 20:28:48 -0800
Subject: RFR (S) 8233650 : Javadoc for Math.floorMod(int, int) gives wrong
 example
In-Reply-To: <1A2720C2-E1E5-4015-8E59-471FC71C4E13@oracle.com>
References: 
 <1A2720C2-E1E5-4015-8E59-471FC71C4E13@oracle.com>
Message-ID: <6a7d8317-8d42-7990-836a-d36fc6d71741@oracle.com>

Thank you Brian!

Pushed.

On 11/5/19 4:05 PM, Brian Burkhalter wrote:
> Hi Ivan,
>
> I think this looks good.
>
> Brian
>
>> On Nov 5, 2019, at 3:35 PM, Ivan Gerasimov  wrote:
>>
>> The javadoc for the method Math.floorMod(int, int) [1] contains an inaccuracy.
>>
>> There are two sets of examples given:  One for the case when signs of the arguments are the same and the other for the case when signs of the arguments are different.
>> The second set of examples wrongly contains an example from the first set.
>>
>> Would you please help review this javadoc-only fix?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8233650
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8233650/00/webrev/
>>
>> [1] https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/lang/Math.html#floorMod(int,int)

-- 
With kind regards,
Ivan Gerasimov


From ivan.gerasimov at oracle.com  Wed Nov  6 05:39:24 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 5 Nov 2019 21:39:24 -0800
Subject: RFR (XXS) 8233658 : Escape + in the expression describing
 Runtime.Version string
Message-ID: <7a24b095-3d19-04c7-1d5b-04fc498cb4b9@oracle.com>

Hello!

Here's yet another javadoc-only fix.

Format of the Runtime.Version string is described as a list of regular 
expressions [1]:

 ???? $VNUM(-$PRE)?\+$BUILD(-$OPT)?
 ???? $VNUM-$PRE(-$OPT)?
 ???? $VNUM(+-$OPT)?

The character + in the last line should be escaped to be consistent with 
the first line and to avoid confusion with RE quantifiers.

[1] 
https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/lang/Runtime.Version.html

Would you please help review this trivial one-char fix?

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8233658
WEBREV: http://cr.openjdk.java.net/~igerasim/8233658/00/webrev/

-- 
With kind regards,
Ivan Gerasimov


From peter.levart at gmail.com  Wed Nov  6 09:36:46 2019
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 6 Nov 2019 10:36:46 +0100
Subject: RFR of JDK-8232446: logging enhancement for rmi when socket closed
In-Reply-To: <5048d354-a480-ac6d-e46d-a14ce4349691@oracle.com>
References: <5048d354-a480-ac6d-e46d-a14ce4349691@oracle.com>
Message-ID: <9db082f9-6e16-9e5e-1d99-280bbd381e8f@gmail.com>

Hi Hamlin,

in TCPTransport.decrementExportCount():

 ?283???????????? try {
 ?284???????????????? if (tcpLog.isLoggable(Log.BRIEF)) {
 ?285???????????????????? tcpLog.log(Log.BRIEF, "close server socket on 
" + ss);
 ?286???????????????? }
 ?287???????????????? ss.close();
 ?288???????????? } catch (IOException e) {
 ?289???????????? }

...you could add a log statement to the catch block too. Or even better, 
rearrange for IOException to be thrown from that method and deal with it 
in two places:

- in exportObject() - add it as suppressed exception to exception thrown 
from super.exportObject().
- in targetUnexported() - log it or wrap it into UncheckedIOException 
(depending on what are the callers of targetUnexported())

What do you think?

Regards, Peter



On 11/6/19 3:07 AM, Hamlin Li wrote:
> Would you please review the patch?
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8232446
>
> webrev: http://cr.openjdk.java.net/~mli/8232446/webrev.00/
>
>
> We have some intermittent failures in rmi related to socket closing, 
> this is to add more logging to help diagnose the issues.
>
>
> Thanks you
>
> -Hamlin
>


From huaming.li at oracle.com  Wed Nov  6 12:02:40 2019
From: huaming.li at oracle.com (Hamlin Li)
Date: Wed, 6 Nov 2019 20:02:40 +0800
Subject: RFR of JDK-8232446: logging enhancement for rmi when socket closed
In-Reply-To: <9db082f9-6e16-9e5e-1d99-280bbd381e8f@gmail.com>
References: <5048d354-a480-ac6d-e46d-a14ce4349691@oracle.com>
 <9db082f9-6e16-9e5e-1d99-280bbd381e8f@gmail.com>
Message-ID: <50bf13f3-f284-f3f4-1256-8ac51929637b@oracle.com>


On 2019/11/6 5:36 PM, Peter Levart wrote:
> Hi Hamlin,
>
> in TCPTransport.decrementExportCount():
>
> ?283???????????? try {
> ?284???????????????? if (tcpLog.isLoggable(Log.BRIEF)) {
> ?285???????????????????? tcpLog.log(Log.BRIEF, "close server socket on 
> " + ss);
> ?286???????????????? }
> ?287???????????????? ss.close();
> ?288???????????? } catch (IOException e) {
> ?289???????????? }
>
> ...you could add a log statement to the catch block too. Or even 
> better, rearrange for IOException to be thrown from that method and 
> deal with it in two places:
>
> - in exportObject() - add it as suppressed exception to exception 
> thrown from super.exportObject().
> - in targetUnexported() - log it or wrap it into UncheckedIOException 
> (depending on what are the callers of targetUnexported())
>
> What do you think?
Thanks Peter.

I agree. I adopt your first suggestion: add log statement to catch 
block, as I think it's simple/straight and sufficient to help diagnose.

And I also add log for catch blocks in other close places.

The change is updated in place at: 
http://cr.openjdk.java.net/~mli/8232446/webrev.00/


Thank you

-Hamlin

>
> Regards, Peter
>
>
>
> On 11/6/19 3:07 AM, Hamlin Li wrote:
>> Would you please review the patch?
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8232446
>>
>> webrev: http://cr.openjdk.java.net/~mli/8232446/webrev.00/
>>
>>
>> We have some intermittent failures in rmi related to socket closing, 
>> this is to add more logging to help diagnose the issues.
>>
>>
>> Thanks you
>>
>> -Hamlin
>>
>

From mp at jugs.org  Wed Nov  6 12:24:17 2019
From: mp at jugs.org (Michael Paus)
Date: Wed, 6 Nov 2019 13:24:17 +0100
Subject: RFR: JDK-8233594: create a new option --bind-servces to pass on
 to jlink
In-Reply-To: 
References: 
Message-ID: <88bbd919-cc20-e2c8-908a-3e4f85bb78af@jugs.org>

But this is also a very dangerous option because it may place time-bombs
into your packaged applications. For example, I recently realized that I 
could
not make any https-requests any more in my packaged application. To fix
that I had to explicitly add "jdk.crypto.ec" to the list of modules for 
jlink.
The symptoms of such bugs are not always very clear and do not
directly point you to missing modules with service providers.
So there should at least be a big warning that when you do not specify
the --bind-services option, you will have to watch out for sometimes
obscure runtime errors.

-- Michael

> Message: 2
> Date: Wed, 6 Nov 2019 05:18:15 +0100
> From: Kevin Rushforth 
> To: Philip Race , Andy Herrick
> 	
> Cc: core-libs-dev 
> Subject: Re: RFR: JDK-8233594: create a new option --bind-servces to
> 	pass on to jlink
> Message-ID: <58a2d94b-6de5-baed-8427-fa6a5b8214c9 at oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Yes, this is a good change.
>
> +1
>
> -- Kevin
>
> On 11/6/2019 2:02 AM, Philip Race wrote:
>> I noticed this problem when creating various demo scenarios so +1 to
>> the change, but
>>
>> +\????????? Pass on --bind-seervices option to jlink (which will link
>> in \n\
>>
>> typo here
>>
>> -phil
>>
>> On 11/5/19, 3:36 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 changes adds the --bind-services option and removes the previous
>>> behavior of always including --bind-services in the jlink options
>>> except when --add-modules was specified.
>>>
>>> [1] - https://bugs.openjdk.java.net/browse/JDK-8233594
>>>
>>> [2] - http://cr.openjdk.java.net/~herrick/8233594/
>>>
>>> /Andy
>>>


From Alan.Bateman at oracle.com  Wed Nov  6 13:07:03 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 6 Nov 2019 13:07:03 +0000
Subject: RFR: JDK-8233594: create a new option --bind-servces to pass on
 to jlink
In-Reply-To: <88bbd919-cc20-e2c8-908a-3e4f85bb78af@jugs.org>
References: 
 <88bbd919-cc20-e2c8-908a-3e4f85bb78af@jugs.org>
Message-ID: 

On 06/11/2019 12:24, Michael Paus wrote:
> But this is also a very dangerous option because it may place time-bombs
> into your packaged applications. For example, I recently realized that 
> I could
> not make any https-requests any more in my packaged application. To fix
> that I had to explicitly add "jdk.crypto.ec" to the list of modules 
> for jlink.
> The symptoms of such bugs are not always very clear and do not
> directly point you to missing modules with service providers.
> So there should at least be a big warning that when you do not specify
> the --bind-services option, you will have to watch out for sometimes
> obscure runtime errors.
`jlink` is a power tool that requires its user to have significant 
knowledge about the application, its dependences, and the environment 
where the resulting run-time image will be run. If you want to include 
additional crypto then you have to opt-in, if you want support for all 
or a subset of locales then you opt-in, and so. If you change the 
default and eagerly link in all modules then you'll annoy everyone that 
is looking for a the run-time image to be as small as possible. The best 
that we could come up with in JDK 9 `--suggest-providers` option to help 
users get some idea of the providers that could be used at run-time. I 
don't know if you've used that but if needed then I assume `jpackage` 
could pass the option through to `jlink` in a dry run.

-Alan

From mp at jugs.org  Wed Nov  6 14:01:14 2019
From: mp at jugs.org (Michael Paus)
Date: Wed, 6 Nov 2019 15:01:14 +0100
Subject: RFR: JDK-8233594: create a new option --bind-servces to pass on
 to jlink
In-Reply-To: 
References: 
 <88bbd919-cc20-e2c8-908a-3e4f85bb78af@jugs.org>
 
Message-ID: <8350718c-8441-6972-bea0-4e199fc2ff3e@jugs.org>

Am 06.11.19 um 14:07 schrieb Alan Bateman:
> On 06/11/2019 12:24, Michael Paus wrote:
>> But this is also a very dangerous option because it may place time-bombs
>> into your packaged applications. For example, I recently realized 
>> that I could
>> not make any https-requests any more in my packaged application. To fix
>> that I had to explicitly add "jdk.crypto.ec" to the list of modules 
>> for jlink.
>> The symptoms of such bugs are not always very clear and do not
>> directly point you to missing modules with service providers.
>> So there should at least be a big warning that when you do not specify
>> the --bind-services option, you will have to watch out for sometimes
>> obscure runtime errors.
> `jlink` is a power tool that requires its user to have significant 
> knowledge about the application, its dependences, and the environment 
> where the resulting run-time image will be run. If you want to include 
> additional crypto then you have to opt-in, if you want support for all 
> or a subset of locales then you opt-in, and so. If you change the 
> default and eagerly link in all modules then you'll annoy everyone 
> that is looking for a the run-time image to be as small as possible. 
> The best that we could come up with in JDK 9 `--suggest-providers` 
> option to help users get some idea of the providers that could be used 
> at run-time. I don't know if you've used that but if needed then I 
> assume `jpackage` could pass the option through to `jlink` in a dry run.
>
> -Alan

The --suggest-providers option would be more useful if one could limit 
it to the providers that can actually be used by my code, i.e.
a call like

jlink --add-modules java.base --suggest-providers

should only return the providers which can be reached by java.base. Or 
did I miss something here?


From Alan.Bateman at oracle.com  Wed Nov  6 15:32:14 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 6 Nov 2019 15:32:14 +0000
Subject: RFR: JDK-8233594: create a new option --bind-servces to pass on
 to jlink
In-Reply-To: <8350718c-8441-6972-bea0-4e199fc2ff3e@jugs.org>
References: 
 <88bbd919-cc20-e2c8-908a-3e4f85bb78af@jugs.org>
 
 <8350718c-8441-6972-bea0-4e199fc2ff3e@jugs.org>
Message-ID: <5442f75d-c256-f10e-2266-61cf52a2b108@oracle.com>

On 06/11/2019 14:01, Michael Paus wrote:
>
> The --suggest-providers option would be more useful if one could limit 
> it to the providers that can actually be used by my code, i.e.
> a call like
>
> jlink --add-modules java.base --suggest-providers
>
> should only return the providers which can be reached by java.base. Or 
> did I miss something here?
>
java.base is a prolific user of services. Many standard and JDK-specific 
modules provide implementations of services that are used by java.base. 
Those modules in turn make use of additional services. So it's working 
as intended. The other form of --suggest-providers allows you to specify 
the service interface so that you can fine tune the additional providers 
to add to the run-time image. If you change the above to 
`--suggest-providers java.security.Provider` then you'll see the list of 
modules provide implementations of Security. You should see the 
jdk.crypto.ec module in that list.

-Alan


From naoto.sato at oracle.com  Wed Nov  6 16:24:40 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 6 Nov 2019 08:24:40 -0800
Subject: RFR (XXS) 8233658 : Escape + in the expression describing
 Runtime.Version string
In-Reply-To: <7a24b095-3d19-04c7-1d5b-04fc498cb4b9@oracle.com>
References: <7a24b095-3d19-04c7-1d5b-04fc498cb4b9@oracle.com>
Message-ID: 

Hi Ivan,

Looks good to me.

Naoto

On 11/5/19 9:39 PM, Ivan Gerasimov wrote:
> Hello!
> 
> Here's yet another javadoc-only fix.
> 
> Format of the Runtime.Version string is described as a list of regular 
> expressions [1]:
> 
>  ???? $VNUM(-$PRE)?\+$BUILD(-$OPT)?
>  ???? $VNUM-$PRE(-$OPT)?
>  ???? $VNUM(+-$OPT)?
> 
> The character + in the last line should be escaped to be consistent with 
> the first line and to avoid confusion with RE quantifiers.
> 
> [1] 
> https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/lang/Runtime.Version.html 
> 
> 
> Would you please help review this trivial one-char fix?
> 
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8233658
> WEBREV: http://cr.openjdk.java.net/~igerasim/8233658/00/webrev/
> 

From mp at jugs.org  Wed Nov  6 16:35:02 2019
From: mp at jugs.org (Michael Paus)
Date: Wed, 6 Nov 2019 17:35:02 +0100
Subject: RFR: JDK-8233594: create a new option --bind-servces to pass on
 to jlink
In-Reply-To: <5442f75d-c256-f10e-2266-61cf52a2b108@oracle.com>
References: 
 <88bbd919-cc20-e2c8-908a-3e4f85bb78af@jugs.org>
 
 <8350718c-8441-6972-bea0-4e199fc2ff3e@jugs.org>
 <5442f75d-c256-f10e-2266-61cf52a2b108@oracle.com>
Message-ID: <06cfba08-19f6-36b4-e458-dd98405b1c74@jugs.org>

Am 06.11.19 um 16:32 schrieb Alan Bateman:
> On 06/11/2019 14:01, Michael Paus wrote:
>>
>> The --suggest-providers option would be more useful if one could 
>> limit it to the providers that can actually be used by my code, i.e.
>> a call like
>>
>> jlink --add-modules java.base --suggest-providers
>>
>> should only return the providers which can be reached by java.base. 
>> Or did I miss something here?
>>
> java.base is a prolific user of services. Many standard and 
> JDK-specific modules provide implementations of services that are used 
> by java.base. Those modules in turn make use of additional services. 
> So it's working as intended. The other form of --suggest-providers 
> allows you to specify the service interface so that you can fine tune 
> the additional providers to add to the run-time image. If you change 
> the above to `--suggest-providers java.security.Provider` then you'll 
> see the list of modules provide implementations of Security. You 
> should see the jdk.crypto.ec module in that list.
>
> -Alan
>
I still don't see how entries like this

java.desktop provides javax.sound.midi.spi.MidiDeviceProvider used by 
java.desktop

or this

jdk.jshell provides javax.tools.Tool not used by any observable module

come into play.

In practice a user does not know all service interfaces that are 
potentially relevant for an
application and so cannot search for them. All in all I still think that 
removing --bind-services
from the default parameters is dangerous and at least justifies a warning.

Just my two ?ent



From Alan.Bateman at oracle.com  Wed Nov  6 17:02:12 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 6 Nov 2019 17:02:12 +0000
Subject: RFR: JDK-8233594: create a new option --bind-servces to pass on
 to jlink
In-Reply-To: <06cfba08-19f6-36b4-e458-dd98405b1c74@jugs.org>
References: 
 <88bbd919-cc20-e2c8-908a-3e4f85bb78af@jugs.org>
 
 <8350718c-8441-6972-bea0-4e199fc2ff3e@jugs.org>
 <5442f75d-c256-f10e-2266-61cf52a2b108@oracle.com>
 <06cfba08-19f6-36b4-e458-dd98405b1c74@jugs.org>
Message-ID: 

On 06/11/2019 16:35, Michael Paus wrote:
>
> I still don't see how entries like this
>
> java.desktop provides javax.sound.midi.spi.MidiDeviceProvider used by 
> java.desktop
I assume you have this line in the output:

java.desktop provides java.net.ContentHandlerFactory used by java.base

java.desktop, in turn, is also a prolific user of services, many of 
which it provides itself (that's what the line you picked out is trying 
to say).


> :
>
> jdk.jshell provides javax.tools.Tool not used by any observable module
I don't see an issue here, I assume you jdk.jshell is not being linked in.

-Alan.




From ivan.gerasimov at oracle.com  Wed Nov  6 17:50:28 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 6 Nov 2019 09:50:28 -0800
Subject: RFR (XXS) 8233658 : Escape + in the expression describing
 Runtime.Version string
In-Reply-To: 
References: <7a24b095-3d19-04c7-1d5b-04fc498cb4b9@oracle.com>
 
Message-ID: <48231ad7-06d4-91e6-3e6f-f3b74b352f30@oracle.com>

Thank you Naoto!

Pushed.

On 11/6/19 8:24 AM, naoto.sato at oracle.com wrote:
> Hi Ivan,
>
> Looks good to me.
>
> Naoto
>
> On 11/5/19 9:39 PM, Ivan Gerasimov wrote:
>> Hello!
>>
>> Here's yet another javadoc-only fix.
>>
>> Format of the Runtime.Version string is described as a list of 
>> regular expressions [1]:
>>
>> ????? $VNUM(-$PRE)?\+$BUILD(-$OPT)?
>> ????? $VNUM-$PRE(-$OPT)?
>> ????? $VNUM(+-$OPT)?
>>
>> The character + in the last line should be escaped to be consistent 
>> with the first line and to avoid confusion with RE quantifiers.
>>
>> [1] 
>> https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/lang/Runtime.Version.html 
>>
>>
>> Would you please help review this trivial one-char fix?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8233658
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8233658/00/webrev/
>>
>
-- 
With kind regards,
Ivan Gerasimov


From naoto.sato at oracle.com  Wed Nov  6 21:45:29 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 6 Nov 2019 13:45:29 -0800
Subject: [14] RFR: 8233579: DateFormatSymbols.getShortMonths() return wrong
 string on es_CL, es_CO locales
Message-ID: <89efc1fb-1130-c533-4472-ae2c0dba1288@oracle.com>

Hi,

Please review the fix to the following issue:

https://bugs.openjdk.java.net/browse/JDK-8233579

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8233579/webrev.00/

The problem was in the CLDR converter where it substitutes the context 
dependent style names with stand alone style names, if the former set of 
names are missing in a locale bundle. Corrected to not substitute, thus 
inherit from the parent bundles.

Naoto

From brent.christian at oracle.com  Wed Nov  6 23:27:35 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Wed, 6 Nov 2019 15:27:35 -0800
Subject: [14] RFR: 8232871: Host Locale Provider on Mac does not return
 translated values of Japanese calendar
In-Reply-To: <83707e65-41cb-ec0d-4a3c-005ae94967ae@oracle.com>
References: <83707e65-41cb-ec0d-4a3c-005ae94967ae@oracle.com>
Message-ID: <6d45da8c-2fce-6925-8acf-a709339e47fa@oracle.com>

Hi, Naoto

Looks pretty good.  I have a few comments:

--
src/java.base/macosx/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java

  572                     map = new HashMap<>();

FWIW, I believe the HashMap could be pre-sized using 'names.length'.


--
src/java.base/macosx/native/libjava/HostLocaleProviderAdapter_md.c

  457     jobjectArray ret = NULL;

Is 'ret' needed?


  713                 int sindex = cal == kCFJapaneseCalendar ? 
JAPANESE_MEIJI_INDEX : 0;

So here we are moving 'sindex' past earlier eras in 'cferas', in order 
to start at Meiji, yes?


  740                 if (wdays != NULL) {
  741                     array_length = (*env)->GetArrayLength(env, wdays);
  742                 } else {
  743                     array_length = dayCount + 1;

It doesn't look like 'array_length' is needed for the 'wdays != NULL' 
case.  In fact, could 740-743 be changed to:

if (wdays == NULL) {
     jsize array_length = dayCount + 1;

?

Thanks,
-Brent

On 11/5/19 12:48 PM, naoto.sato at oracle.com wrote:
> Hello,
> 
> Please review the fix to the following issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8232871
> 
> The proposed changeset is located at:
> 
> https://cr.openjdk.java.net/~naoto/8232871/webrev.00/
> 
> Implementation for getting calendar display names was missing in macOS's 
> host adapter.
> 
> Naoto

From naoto.sato at oracle.com  Thu Nov  7 02:11:28 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 6 Nov 2019 18:11:28 -0800
Subject: [14] RFR: 8232871: Host Locale Provider on Mac does not return
 translated values of Japanese calendar
In-Reply-To: <6d45da8c-2fce-6925-8acf-a709339e47fa@oracle.com>
References: <83707e65-41cb-ec0d-4a3c-005ae94967ae@oracle.com>
 <6d45da8c-2fce-6925-8acf-a709339e47fa@oracle.com>
Message-ID: <05bc6dda-199f-66b5-b0b2-38c0180c99c1@oracle.com>

Hi Brent,

Thank you for the review! Please see my comments below.

On 11/6/19 3:27 PM, Brent Christian wrote:
> Hi, Naoto
> 
> Looks pretty good.? I have a few comments:
> 
> -- 
> src/java.base/macosx/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java 
> 
> 
>  ?572???????????????????? map = new HashMap<>();
> 
> FWIW, I believe the HashMap could be pre-sized using 'names.length'.

Modified to specify the initial capacity.

> 
> 
> -- 
> src/java.base/macosx/native/libjava/HostLocaleProviderAdapter_md.c
> 
>  ?457???? jobjectArray ret = NULL;
> 
> Is 'ret' needed?

Removed.

> 
> 
>  ?713???????????????? int sindex = cal == kCFJapaneseCalendar ? 
> JAPANESE_MEIJI_INDEX : 0;
> 
> So here we are moving 'sindex' past earlier eras in 'cferas', in order 
> to start at Meiji, yes?

Yes. While JDK's Japanese calendar provides eras since Meiji and 
"BeforeMeiji", which is a hypothetical era for all prior eras, macOS's 
Japanese calendar returns all Japanese eras. Copying should be done only 
for Meiji and after.

> 
> 
>  ?740???????????????? if (wdays != NULL) {
>  ?741???????????????????? array_length = (*env)->GetArrayLength(env, 
> wdays);
>  ?742???????????????? } else {
>  ?743???????????????????? array_length = dayCount + 1;
> 
> It doesn't look like 'array_length' is needed for the 'wdays != NULL' 
> case.? In fact, could 740-743 be changed to:
> 
> if (wdays == NULL) {
>  ??? jsize array_length = dayCount + 1;
> 
> ?

You're absolutely right. These are copied from Windows' counterpart and 
left over.

Here is the updated webrev:

https://cr.openjdk.java.net/~naoto/8232871/webrev.01/

Naoto

> 
> Thanks,
> -Brent
> 
> On 11/5/19 12:48 PM, naoto.sato at oracle.com wrote:
>> Hello,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8232871
>>
>> The proposed changeset is located at:
>>
>> https://cr.openjdk.java.net/~naoto/8232871/webrev.00/
>>
>> Implementation for getting calendar display names was missing in 
>> macOS's host adapter.
>>
>> Naoto

From huizhe.wang at oracle.com  Thu Nov  7 02:21:37 2019
From: huizhe.wang at oracle.com (Joe Wang)
Date: Wed, 6 Nov 2019 18:21:37 -0800
Subject:  [14] RFR: 8233579: DateFormatSymbols.getShortMonths()
 return wrong string on es_CL, es_CO locales
In-Reply-To: <89efc1fb-1130-c533-4472-ae2c0dba1288@oracle.com>
References: <89efc1fb-1130-c533-4472-ae2c0dba1288@oracle.com>
Message-ID: <789b55f2-1219-e3c1-1402-c69ff609a4a0@oracle.com>

Looks good to me. It might be good to leave a note to the method about 
the change (e.g. why it no longer substitutes).

-Joe

On 11/6/19 1:45 PM, naoto.sato at oracle.com wrote:
> Hi,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8233579
>
> The proposed changeset is located at:
>
> https://cr.openjdk.java.net/~naoto/8233579/webrev.00/
>
> The problem was in the CLDR converter where it substitutes the context 
> dependent style names with stand alone style names, if the former set 
> of names are missing in a locale bundle. Corrected to not substitute, 
> thus inherit from the parent bundles.
>
> Naoto


From naoto.sato at oracle.com  Thu Nov  7 02:34:31 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 6 Nov 2019 18:34:31 -0800
Subject:  [14] RFR: 8233579: DateFormatSymbols.getShortMonths()
 return wrong string on es_CL, es_CO locales
In-Reply-To: <789b55f2-1219-e3c1-1402-c69ff609a4a0@oracle.com>
References: <89efc1fb-1130-c533-4472-ae2c0dba1288@oracle.com>
 <789b55f2-1219-e3c1-1402-c69ff609a4a0@oracle.com>
Message-ID: 

Hi Joe,

Thanks for the review! I tried to draft some comments, but thinking of 
it, it could be confusing to leave a comment for a removed (wrong) code. 
So instead of leaving code comments, I modified the JIRA issue 
mentioning it, so that maintainers later could find out the rationale.

Naoto

On 11/6/19 6:21 PM, Joe Wang wrote:
> Looks good to me. It might be good to leave a note to the method about 
> the change (e.g. why it no longer substitutes).
> 
> -Joe
> 
> On 11/6/19 1:45 PM, naoto.sato at oracle.com wrote:
>> Hi,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8233579
>>
>> The proposed changeset is located at:
>>
>> https://cr.openjdk.java.net/~naoto/8233579/webrev.00/
>>
>> The problem was in the CLDR converter where it substitutes the context 
>> dependent style names with stand alone style names, if the former set 
>> of names are missing in a locale bundle. Corrected to not substitute, 
>> thus inherit from the parent bundles.
>>
>> Naoto
> 

From huizhe.wang at oracle.com  Thu Nov  7 03:24:47 2019
From: huizhe.wang at oracle.com (Joe Wang)
Date: Wed, 6 Nov 2019 19:24:47 -0800
Subject:  [14] RFR: 8233579: DateFormatSymbols.getShortMonths()
 return wrong string on es_CL, es_CO locales
In-Reply-To: 
References: <89efc1fb-1130-c533-4472-ae2c0dba1288@oracle.com>
 <789b55f2-1219-e3c1-1402-c69ff609a4a0@oracle.com>
 
Message-ID: <91badbb9-bbf3-5587-5894-c8c7c082c014@oracle.com>

That sounds good. JIRA makes sense.

Best,
Joe

On 11/6/19 6:34 PM, naoto.sato at oracle.com wrote:
> Hi Joe,
>
> Thanks for the review! I tried to draft some comments, but thinking of 
> it, it could be confusing to leave a comment for a removed (wrong) 
> code. So instead of leaving code comments, I modified the JIRA issue 
> mentioning it, so that maintainers later could find out the rationale.
>
> Naoto
>
> On 11/6/19 6:21 PM, Joe Wang wrote:
>> Looks good to me. It might be good to leave a note to the method 
>> about the change (e.g. why it no longer substitutes).
>>
>> -Joe
>>
>> On 11/6/19 1:45 PM, naoto.sato at oracle.com wrote:
>>> Hi,
>>>
>>> Please review the fix to the following issue:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8233579
>>>
>>> The proposed changeset is located at:
>>>
>>> https://cr.openjdk.java.net/~naoto/8233579/webrev.00/
>>>
>>> The problem was in the CLDR converter where it substitutes the 
>>> context dependent style names with stand alone style names, if the 
>>> former set of names are missing in a locale bundle. Corrected to not 
>>> substitute, thus inherit from the parent bundles.
>>>
>>> Naoto
>>


From james.laskey at oracle.com  Thu Nov  7 14:22:38 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Thu, 7 Nov 2019 10:22:38 -0400
Subject: RFR: JDK-8233117 Escape Sequences For Line Continuation and White
 Space (Preview) 
Message-ID: <0EEF3461-D8A4-496B-87DE-F143CB0FB995@oracle.com>

Please review the following code changes. Provides for the introduction of two new escape sequences \ and \s.  \ allows developers to express unwieldy string literals in a text block as a cluster of short single line segments. The second is to allow developers to express ASCII space, much like \t for tab. The changes are primarily in the compiler, with some small changes in String::translateEscapes. Small changeset overall.

Thank you.

-- Jim


webrev: http://cr.openjdk.java.net/~jlaskey/8233116/webrev/index.html 

jbs: https://bugs.openjdk.java.net/browse/JDK-8233116 
csr: https://bugs.openjdk.java.net/browse/JDK-8233117 

From vladimir.kozlov at oracle.com  Thu Nov  7 17:34:58 2019
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 7 Nov 2019 09:34:58 -0800
Subject: RFR: JDK-8232684: Make switch expressions final
In-Reply-To: 
References: 
 
 
Message-ID: <0c60f044-4d5b-8fc4-24ca-4da872be6333@oracle.com>

HotSpot tests changes (using Thread.yield()) look good.

Thanks,
Vladimir

On 11/5/19 1:50 AM, Jan Lahoda wrote:
> I've missed updates to some hotspot and jdk tests in the first patch. The problem are unqualified 
> invocations of Thread.yield(), which are no longer allowed (from the spec: JLS 3.9 Keywords: "All 
> invocations of a method called yield must be qualified so as to be distinguished from a yield 
> statement."). Therefore, these invocations need to be changed to qualified invocations (i.e. 
> Thread.yield()). Updates to the hotspot and jdk tests are here:
> http://cr.openjdk.java.net/~jlahoda/8232684/webrev.delta.00.01/
> 
> Full updated webrev, with changes to both javac and the tests, is here:
> http://cr.openjdk.java.net/~jlahoda/8232684/webrev.01/
> 
> How does that look?
> 
> Thanks,
>  ??? Jan
> 
> On 21. 10. 19 16:17, Maurizio Cimadamore wrote:
>> Looks generally good -? went through the test updates one by one and they look ok, except this:
>>
>> http://cr.openjdk.java.net/~jlahoda/8232684/webrev.00/test/langtools/tools/jdeps/listdeps/ListModuleDeps.java.udiff.html 
>>
>>
>> Which you explained to me offline (we need to change this code every time the compiler stops using 
>> the @Preview annotation - ugh). Nothing specific to this webrev, so I approve.
>>
>> Maurizio
>>
>> On 21/10/2019 14:49, Jan Lahoda wrote:
>>> Hi,
>>>
>>> As part of preparation for proposing JEP 361: Switch Expressions (Standard) to target, I would 
>>> like to ask for a review of the patch to make switch expression a non-preview feature in javac:
>>> http://cr.openjdk.java.net/~jlahoda/8232684/webrev.00/
>>>
>>> The patch basically removes the feature from the list of preview features, updates test to this 
>>> new state (removes --enable-preview from associated tests, and adjusts their expected output), 
>>> and removes the @PreviewFeature annotation and associated text from the javadoc of the Trees API.
>>>
>>> I also would like to ask for a review for the CSR associated with that:
>>> https://bugs.openjdk.java.net/browse/JDK-8232685
>>>
>>> Reviews/comments on either of these would be very welcome!
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8232684
>>>
>>> Thanks!
>>>
>>> Jan

From huizhe.wang at oracle.com  Thu Nov  7 19:01:19 2019
From: huizhe.wang at oracle.com (Joe Wang)
Date: Thu, 7 Nov 2019 11:01:19 -0800
Subject: RFR [14/java.xml] 8233686: XML transformer uses excessive amount of
 memory
Message-ID: 

Please review a quick fix that reduces unnecessary object allocations.

JBS: https://bugs.openjdk.java.net/browse/JDK-8233686
webrev: http://cr.openjdk.java.net/~joehw/jdk14/8233686/webrev/

Thanks,
Joe


From lance.andersen at oracle.com  Thu Nov  7 19:19:07 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 7 Nov 2019 14:19:07 -0500
Subject: RFR [14/java.xml] 8233686: XML transformer uses excessive amount
 of memory
In-Reply-To: 
References: 
Message-ID: <2D708002-5CB1-46B2-9C84-D5B5BCB052BA@oracle.com>

Looks OK Joe.  

> On Nov 7, 2019, at 2:01 PM, Joe Wang  wrote:
> 
> Please review a quick fix that reduces unnecessary object allocations.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8233686
> webrev: http://cr.openjdk.java.net/~joehw/jdk14/8233686/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 brent.christian at oracle.com  Thu Nov  7 19:26:30 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 7 Nov 2019 11:26:30 -0800
Subject: [14] RFR: 8232871: Host Locale Provider on Mac does not return
 translated values of Japanese calendar
In-Reply-To: <05bc6dda-199f-66b5-b0b2-38c0180c99c1@oracle.com>
References: <83707e65-41cb-ec0d-4a3c-005ae94967ae@oracle.com>
 <6d45da8c-2fce-6925-8acf-a709339e47fa@oracle.com>
 <05bc6dda-199f-66b5-b0b2-38c0180c99c1@oracle.com>
Message-ID: <0163dcc2-45fb-7c95-67ac-6ab736ec007b@oracle.com>

Looks good.  -B

On 11/6/19 6:11 PM, naoto.sato at oracle.com wrote:
> 
> Here is the updated webrev:
> 
> https://cr.openjdk.java.net/~naoto/8232871/webrev.01/
> 


From brent.christian at oracle.com  Thu Nov  7 21:23:54 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 7 Nov 2019 13:23:54 -0800
Subject: RFR: JDK-8233117 Escape Sequences For Line Continuation and White
 Space (Preview)
In-Reply-To: <0EEF3461-D8A4-496B-87DE-F143CB0FB995@oracle.com>
References: <0EEF3461-D8A4-496B-87DE-F143CB0FB995@oracle.com>
Message-ID: <414cb097-9616-f4b0-8a3d-462a9ccfbdea@oracle.com>

Should the new escapes be added to the table in the 
String.translateEscapes() JavaDoc?

-Brent

On 11/7/19 6:22 AM, Jim Laskey wrote:
> Please review the following code changes. Provides for the introduction of two new escape sequences \ and \s.  \ allows developers to express unwieldy string literals in a text block as a cluster of short single line segments. The second is to allow developers to express ASCII space, much like \t for tab. The changes are primarily in the compiler, with some small changes in String::translateEscapes. Small changeset overall.
> 
> Thank you.
> 
> -- Jim
> 
> 
> webrev: http://cr.openjdk.java.net/~jlaskey/8233116/webrev/index.html 
> 
> jbs: https://bugs.openjdk.java.net/browse/JDK-8233116 
> csr: https://bugs.openjdk.java.net/browse/JDK-8233117 
> 

From andy.herrick at oracle.com  Thu Nov  7 21:45:33 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Thu, 7 Nov 2019 16:45:33 -0500
Subject: RFR: JDK-8233636: Make jpackage an incubator and remove tool provider
 implementation
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).

This changes the module name, and base package name from jdk.jpackage to 
jdk.incubator.jpackage.

This removes the "provides" statement in module-info so 
jdk.incubator.jpackage can not directly be discovered as a ToolProvider, 
but it also exports jdk.incubator.jpackage which now contains 
ToolProviderFactory.java which can be used for the same purpose.

[1] https://bugs.openjdk.java.net/browse/JDK-8233636

[2] https://cr.openjdk.java.net/~herrick/8233636/webrev-02

/Andy


From brian.burkhalter at oracle.com  Thu Nov  7 21:52:15 2019
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 7 Nov 2019 13:52:15 -0800
Subject: JDK 14 RFR of JDK-8233452: java.math.BigDecimal.sqrt() with
 RoundingMode.FLOOR results in incorrect result
In-Reply-To: <402ee79d-4c8c-7af1-10fc-f8a8bf0864de@oracle.com>
References: <402ee79d-4c8c-7af1-10fc-f8a8bf0864de@oracle.com>
Message-ID: 


Hi Joe,

> On Nov 5, 2019, at 6:04 PM, Joe Darcy  wrote:
> 
> Please review the changes to fix
> 
>     JDK-8233452: java.math.BigDecimal.sqrt() with RoundingMode.FLOOR results in incorrect result
>     http://cr.openjdk.java.net/~darcy/8233452.0/ 
> 
> Some background on the problem and fix.
> 
> The core of the BigDecimal.sqrt method is a Newton-Raphson loop.
> [?]
> The Newton iteration reduces the error at each step and, as currently written, it can settle on a value like 2, which is closer to the actual answer, but *incorrect* according to the requested rounding mode.
> 
> There are a few ways to fix this one. One is to run the Newton loop to a higher-precision where these finer distinctions can be teased out. [?]
> 
> Another approach is to detect when the result is too large/too small and then subtract/add an ulp as a fix-up. This is the approach taken for BigDecimal.sqrt. [?]

This implementation change looks reasonable to me.

> An approach not explored for this fix would be to arrange for the iteration to start from the "right" side of the number line depending on the rounding mode and then monotonically increase/decrease to approach the square root. [?] I believe this is technically possible, but would require some additional analysis to setup.

This approach seems more appealing and could perhaps be investigated at a later date.

In the test I think you want to replace ?down? with ?up" at line 238.

Brian

From james.laskey at oracle.com  Thu Nov  7 22:11:29 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Thu, 7 Nov 2019 18:11:29 -0400
Subject: RFR: JDK-8233117 Escape Sequences For Line Continuation and White
 Space (Preview)
In-Reply-To: <414cb097-9616-f4b0-8a3d-462a9ccfbdea@oracle.com>
References: <0EEF3461-D8A4-496B-87DE-F143CB0FB995@oracle.com>
 <414cb097-9616-f4b0-8a3d-462a9ccfbdea@oracle.com>
Message-ID: 

Yep. :-) Too much juggling. Thank you.

> On Nov 7, 2019, at 5:23 PM, Brent Christian  wrote:
> 
> Should the new escapes be added to the table in the String.translateEscapes() JavaDoc?
> 
> -Brent
> 
> On 11/7/19 6:22 AM, Jim Laskey wrote:
>> Please review the following code changes. Provides for the introduction of two new escape sequences \ and \s.  \ allows developers to express unwieldy string literals in a text block as a cluster of short single line segments. The second is to allow developers to express ASCII space, much like \t for tab. The changes are primarily in the compiler, with some small changes in String::translateEscapes. Small changeset overall.
>> Thank you.
>> -- Jim
>> webrev: http://cr.openjdk.java.net/~jlaskey/8233116/webrev/index.html 
>> jbs: https://bugs.openjdk.java.net/browse/JDK-8233116 
>> csr: https://bugs.openjdk.java.net/browse/JDK-8233117 


From alexey.semenyuk at oracle.com  Thu Nov  7 22:38:12 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Thu, 7 Nov 2019 17:38:12 -0500
Subject: RFR: JDK-8233636: Make jpackage an incubator and remove tool
 provider implementation
In-Reply-To: 
References: 
Message-ID: 

I guess the link for the review is 
https://cr.openjdk.java.net/~herrick/8233636/webrev.02

http://cr.openjdk.java.net/~herrick/8233636/webrev.02/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JavaTool.java.sdiff.html:50 

I'd suggest to replace
---
if (name.equals("jpackage"))
---

with more robust
---
if (this == JPACKAGE)
---

http://cr.openjdk.java.net/~herrick/8233636/webrev.02/test/jdk/tools/jpackage/share/jdk/jpackage/tests/BasicTest.java.sdiff.html: 

Did you drop JPackageCommand.filterOutput() calls intentionally?

The rest looks good.

- Alexey

On 11/7/2019 4:45 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 changes the module name, and base package name from jdk.jpackage 
> to jdk.incubator.jpackage.
>
> This removes the "provides" statement in module-info so 
> jdk.incubator.jpackage can not directly be discovered as a 
> ToolProvider, but it also exports jdk.incubator.jpackage which now 
> contains ToolProviderFactory.java which can be used for the same purpose.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8233636
>
> [2] https://cr.openjdk.java.net/~herrick/8233636/webrev-02
>
> /Andy
>


From andy.herrick at oracle.com  Thu Nov  7 22:44:04 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Thu, 7 Nov 2019 17:44:04 -0500
Subject: RFR: JDK-8233636: Make jpackage an incubator and remove tool
 provider implementation
In-Reply-To: 
References: 
 
Message-ID: <4d51ab5a-fae9-9454-d338-77d7e2ad96b1@oracle.com>


On 11/7/2019 5:38 PM, Alexey Semenyuk wrote:
> I guess the link for the review is 
> https://cr.openjdk.java.net/~herrick/8233636/webrev.02
>
sry: yes webrev is http://cr.openjdk.java.net/~herrick/8233636/webrev.02
> http://cr.openjdk.java.net/~herrick/8233636/webrev.02/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JavaTool.java.sdiff.html:50 
>
> I'd suggest to replace
> ---
> if (name.equals("jpackage"))
> ---
sure, I can do that.
>
> with more robust
> ---
> if (this == JPACKAGE)
> ---
>
> http://cr.openjdk.java.net/~herrick/8233636/webrev.02/test/jdk/tools/jpackage/share/jdk/jpackage/tests/BasicTest.java.sdiff.html: 
>
> Did you drop JPackageCommand.filterOutput() calls intentionally?
>
> The rest looks good.
>
> - Alexey
>
> On 11/7/2019 4:45 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 changes the module name, and base package name from jdk.jpackage 
>> to jdk.incubator.jpackage.
>>
>> This removes the "provides" statement in module-info so 
>> jdk.incubator.jpackage can not directly be discovered as a 
>> ToolProvider, but it also exports jdk.incubator.jpackage which now 
>> contains ToolProviderFactory.java which can be used for the same 
>> purpose.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8233636
>>
>> [2] https://cr.openjdk.java.net/~herrick/8233636/webrev-02
>>
>> /Andy
>>
>

From henry.jen at oracle.com  Thu Nov  7 22:55:46 2019
From: henry.jen at oracle.com (Henry Jen)
Date: Thu, 7 Nov 2019 14:55:46 -0800
Subject: RFR: 8231863: Crash if classpath is read from @argument file and the
 main gets option argument
In-Reply-To: 
References: 
 <6788F903-A838-4D86-B511-DD7E64E9CE2B@oracle.com>
 <8EC6F4F1-EAF6-4EB3-9F7F-F7A37A759E84@oracle.com>
 
Message-ID: <10E09EEE-553E-4CBA-81BF-55DFA7C137BB@oracle.com>

Hi,

Please review the webrev[1], contributed by Mat Carter. You can find the bug details at JBS[2]. I have reviewed and tested the fix, I still need an official review before I can push this.

Cheers,
Henry


[1] http://cr.openjdk.java.net/~henryjen/jdk/8231863.0/webrev/
[2] https://bugs.openjdk.java.net/browse/JDK-8231863


> On Nov 4, 2019, at 3:40 PM, Mat Carter  wrote:
> 
> Thanks Henry
> 
> I'm working on a test, do you want me to share directly with you (incl. questions) or continue with comms through the mailing list
> 
> Cheers
> Mat
> 
> From: Henry Jen 
> Sent: Monday, November 4, 2019 12:47 PM
> To: Mat Carter 
> Cc: core-libs-dev at openjdk.java.net 
> Subject: Re: JDK-8231863 bug fix candidate
>  
> Hi Mat,
> 
> I?ll sponsor this fix, let me know if you are coming up with test and I?ll work with you to get your patch committed.
> 
> Cheers,
> Henry
> 
> 
> > On Nov 4, 2019, at 9:21 AM, Henry Jen  wrote:
> > 
> > The fix is on the spot, good catch.
> > 
> > As the test, test/jdk/tools/launcher/ArgsFileTest.java is testing the file expansions, we can add a test case there to have an argument file not have newline at the end, and check that we get correct arguments.
> > 
> > Cheers,
> > Henry
> > 
> > 
> >> On Nov 1, 2019, at 7:06 AM, Mat Carter  wrote:
> >> 
> >> Hello core-libs-dev
> >> 
> >> I'm a VM engineer at Microsoft, now that we've signed the OCA (news of which was shared by Bruno Borges in the discuss mailing list) I wanted to pick up an issue in order to gain familiarity with the change process
> >> 
> >> After reproducing the error reported in "JDK-8231863: Crash if classpath is read from @argument file and the main gets option argument" (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8231863&data=02%7C01%7CMatthew.Carter%40microsoft.com%7C657f0afad82b4d31670a08d761682b0b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637085026486748197&sdata=19S%2BLGCPaoy0h2YmbKrKfsC21d6B43rITkZhnAKyuHw%3D&reserved=0), I've identified the root cause and a candidate fix.
> >> 
> >> As such I'd like to pick this issue up, assuming its current state of unassigned still holds what's the process of having it assigned to me or having it somehow reserved as I don't want to cause unnecessary duplicated work.
> >> 
> >> As well as validating the fix in the debugger on WIndows and Linux, I've run the AdoptOpenJDK sanity tests on Mac, Windows and Linux for both tip and 11u.
> >> 
> >> I'm currently figuring out where/how to write regression tests for this case; input from this mailing list would be welcomed (examples of tests for similar bugs etc)
> >> 
> >> This error occurs on all platforms (tip + 11u) but only results in a crash on Windows in java_md.c due to that platforms dependency on JLI_GetAppArgIndex().  Note that while the error is 100% reproducible, the crash only occurs <10%.  The following change fixes that problem by passing in the final token fragment from the argument file into the state machine via checkArg()
> >> 
> >> --- a/src/java.base/share/native/libjli/args.c
> >> +++ b/src/java.base/share/native/libjli/args.c
> >> @@ -337,7 +337,9 @@ static JLI_List readArgFile(FILE *file) {
> >>     // remaining partial token
> >>     if (ctx.state == IN_TOKEN || ctx.state == IN_QUOTE) {
> >>         if (ctx.parts->size != 0) {
> >> -            JLI_List_add(rv, JLI_List_combine(ctx.parts));
> >> +            token = JLI_List_combine(ctx.parts);
> >> +            checkArg(token);
> >> +            JLI_List_add(rv, token);
> >>         }
> >>     }
> >>     JLI_List_free(ctx.parts);
> >> 
> >> The fix tackles the memory corruption indirectly.  Further preventative changes could be made in java_md.c/CreateApplicationArgs to avoid future memory corruptions (caused by JLI_GetAppArgIndex() returning -1 in this case) ; but I felt that that handling those error cases ran secondary to addressing the bug in the argument file parsing code.
> >> 
> >> Cheers
> >> Mat
> > 
> 


From alexander.matveev at oracle.com  Thu Nov  7 23:43:48 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Thu, 7 Nov 2019 15:43:48 -0800
Subject: RFR: JDK-8233636: Make jpackage an incubator and remove tool
 provider implementation
In-Reply-To: <4d51ab5a-fae9-9454-d338-77d7e2ad96b1@oracle.com>
References: 
 
 <4d51ab5a-fae9-9454-d338-77d7e2ad96b1@oracle.com>
Message-ID: <6a15589b-6f43-f998-869b-ac6bd2437fa3@oracle.com>

Hi Andy,

Agree with Alexey comments. Otherwise looks good.

Thanks,
Alexander

On 11/7/2019 2:44 PM, Andy Herrick wrote:
>
> On 11/7/2019 5:38 PM, Alexey Semenyuk wrote:
>> I guess the link for the review is 
>> https://cr.openjdk.java.net/~herrick/8233636/webrev.02
>>
> sry: yes webrev is http://cr.openjdk.java.net/~herrick/8233636/webrev.02
>> http://cr.openjdk.java.net/~herrick/8233636/webrev.02/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JavaTool.java.sdiff.html:50 
>>
>> I'd suggest to replace
>> ---
>> if (name.equals("jpackage"))
>> ---
> sure, I can do that.
>>
>> with more robust
>> ---
>> if (this == JPACKAGE)
>> ---
>>
>> http://cr.openjdk.java.net/~herrick/8233636/webrev.02/test/jdk/tools/jpackage/share/jdk/jpackage/tests/BasicTest.java.sdiff.html: 
>>
>> Did you drop JPackageCommand.filterOutput() calls intentionally?
>>
>> The rest looks good.
>>
>> - Alexey
>>
>> On 11/7/2019 4:45 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 changes the module name, and base package name from 
>>> jdk.jpackage to jdk.incubator.jpackage.
>>>
>>> This removes the "provides" statement in module-info so 
>>> jdk.incubator.jpackage can not directly be discovered as a 
>>> ToolProvider, but it also exports jdk.incubator.jpackage which now 
>>> contains ToolProviderFactory.java which can be used for the same 
>>> purpose.
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8233636
>>>
>>> [2] https://cr.openjdk.java.net/~herrick/8233636/webrev-02
>>>
>>> /Andy
>>>
>>


From mandy.chung at oracle.com  Fri Nov  8 06:50:46 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 7 Nov 2019 22:50:46 -0800
Subject: RFR: JDK-8233636: Make jpackage an incubator and remove tool
 provider implementation
In-Reply-To: 
References: 
Message-ID: 



On 11/7/19 1:45 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 changes the module name, and base package name from jdk.jpackage 
> to jdk.incubator.jpackage.
>
> This removes the "provides" statement in module-info so 
> jdk.incubator.jpackage can not directly be discovered as a 
> ToolProvider, but it also exports jdk.incubator.jpackage which now 
> contains ToolProviderFactory.java which can be used for the same purpose.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8233636
>
> [2] https://cr.openjdk.java.net/~herrick/8233636/webrev.02

make/common/Modules.gmk
src/java.base/share/classes/module-info.java
 ?? - it'd be good to keep the list in alphabetical order

jdk.incubator.jpackage.ToolProviderFactory is exported and needs the 
specification and javadoc.

   34     private static ToolProvider provider = new JPackageToolProvider();

Nit: this can be final field.

Mandy

From vyommani at gmail.com  Fri Nov  8 10:09:50 2019
From: vyommani at gmail.com (Vyom Tiwari)
Date: Fri, 8 Nov 2019 15:39:50 +0530
Subject: RFR [14/java.xml] 8233686: XML transformer uses excessive amount
 of memory
In-Reply-To: 
References: 
Message-ID: 

Hi Joe,

Fix looks OK to me , but i am not able to understand how come
"NamespaceMappings"  instance can increase memory uses from (20MB to 140MB
).

Current scope of "ns"  is  "case Node.ELEMENT_NODE:"  block and
"NamespaceMapping"  seems to be very lightweight class.

Thanks,
Vyom

On Fri, Nov 8, 2019 at 12:33 AM Joe Wang  wrote:

> Please review a quick fix that reduces unnecessary object allocations.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8233686
> webrev: http://cr.openjdk.java.net/~joehw/jdk14/8233686/webrev/
>
> Thanks,
> Joe
>
>

-- 
Thanks,
Vyom

From Alan.Bateman at oracle.com  Fri Nov  8 10:56:26 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 8 Nov 2019 10:56:26 +0000
Subject: RFR: 8231863: Crash if classpath is read from @argument file and
 the main gets option argument
In-Reply-To: <10E09EEE-553E-4CBA-81BF-55DFA7C137BB@oracle.com>
References: 
 <6788F903-A838-4D86-B511-DD7E64E9CE2B@oracle.com>
 <8EC6F4F1-EAF6-4EB3-9F7F-F7A37A759E84@oracle.com>
 
 <10E09EEE-553E-4CBA-81BF-55DFA7C137BB@oracle.com>
Message-ID: <66980a25-e3fc-dbfb-b95e-7dfe7cd2f697@oracle.com>

On 07/11/2019 22:55, Henry Jen wrote:
> Hi,
>
> Please review the webrev[1], contributed by Mat Carter. You can find the bug details at JBS[2]. I have reviewed and tested the fix, I still need an official review before I can push this.
>
Looks okay although in the test, the createAFile helper method could be 
replaced with Files(aFile.toPath, lines) and that would avoid the need 
to concatenate all the lines. You can specify the defaultCharset to that 
method if you need really it.

-Alan

From ecki at zusammenkunft.net  Fri Nov  8 12:33:43 2019
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Fri, 8 Nov 2019 12:33:43 +0000
Subject: RFR [14/java.xml] 8233686: XML transformer uses excessive amount
 of memory
In-Reply-To: 
References: ,
 
Message-ID: 

This does save object allocations and churn, not memory footprint I guess. The namespace mapping contains multiple stacks (with object arrays) and a hashtable and initialized records, so it seems to allocate a few kb on every node visited. (But 100MB allocation does sound like a very constructed case)

BTW the thing I wondered, is there a process to keep xerces in sync?

Gruss
Bernd


--
http://bernd.eckenfels.net

________________________________
Von: core-libs-dev  im Auftrag von Vyom Tiwari 
Gesendet: Freitag, November 8, 2019 11:14 AM
An: Joe Wang
Cc: core-libs-dev
Betreff: Re: RFR [14/java.xml] 8233686: XML transformer uses excessive amount of memory

Hi Joe,

Fix looks OK to me , but i am not able to understand how come
"NamespaceMappings" instance can increase memory uses from (20MB to 140MB
).

Current scope of "ns" is "case Node.ELEMENT_NODE:" block and
"NamespaceMapping" seems to be very lightweight class.

Thanks,
Vyom

On Fri, Nov 8, 2019 at 12:33 AM Joe Wang  wrote:

> Please review a quick fix that reduces unnecessary object allocations.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8233686
> webrev: http://cr.openjdk.java.net/~joehw/jdk14/8233686/webrev/
>
> Thanks,
> Joe
>
>

--
Thanks,
Vyom

From andy.herrick at oracle.com  Fri Nov  8 12:47:29 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Fri, 8 Nov 2019 07:47:29 -0500
Subject: RFR: JDK-8233636: Make jpackage an incubator and remove tool
 provider implementation
In-Reply-To: 
References: 
 
Message-ID: <57bfe37b-9c07-4a03-716c-9d411229a568@oracle.com>


On 11/7/2019 5:38 PM, Alexey Semenyuk wrote:
>
> http://cr.openjdk.java.net/~herrick/8233636/webrev.02/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JavaTool.java.sdiff.html:50 
>
> I'd suggest to replace
> ---
> if (name.equals("jpackage"))
> ---
>
> with more robust
> ---
> if (this == JPACKAGE)
> ---
>
> http://cr.openjdk.java.net/~herrick/8233636/webrev.02/test/jdk/tools/jpackage/share/jdk/jpackage/tests/BasicTest.java.sdiff.html: 
>
> Did you drop JPackageCommand.filterOutput() calls intentionally?

yes - this form of filter just removes the first line (where the other 
one removes a line starting with some specific strings). When we were 
printing the warning ourselves,? we would always print it.? Now that we 
are causing the system to print it by having the "jdk.incubator" package 
name prefix,? waning is printed when we invoke the tool, but not when we 
call into it's API (that warning was printed when we compiled the code 
that was linked to that package).

Anyway - these two tests began failing when we changed package names, 
because we were filtering out the first line of the output, then not 
matching.

side note - I noticed a bug in what is printed (in no arg case):

> MSG_Help_no_args=Usage: jpackage  \n\
> \Use jpackage --help (or -h) for a list of possible options\

there should be no more  in Usage.

(will fix this as part of JDK-8233591 
)

/Andy

>
> The rest looks good.
>
> - Alexey 

From james.laskey at oracle.com  Fri Nov  8 13:15:42 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Fri, 8 Nov 2019 09:15:42 -0400
Subject: RFR: JDK-8233117 Escape Sequences For Line Continuation and White
 Space (Preview)
In-Reply-To: <414cb097-9616-f4b0-8a3d-462a9ccfbdea@oracle.com>
References: <0EEF3461-D8A4-496B-87DE-F143CB0FB995@oracle.com>
 <414cb097-9616-f4b0-8a3d-462a9ccfbdea@oracle.com>
Message-ID: 

Updated

webrev: http://cr.openjdk.java.net/~jlaskey/8233116/webrev.01/index.html 


> On Nov 7, 2019, at 5:23 PM, Brent Christian  wrote:
> 
> Should the new escapes be added to the table in the String.translateEscapes() JavaDoc?
> 
> -Brent
> 
> On 11/7/19 6:22 AM, Jim Laskey wrote:
>> Please review the following code changes. Provides for the introduction of two new escape sequences \ and \s.  \ allows developers to express unwieldy string literals in a text block as a cluster of short single line segments. The second is to allow developers to express ASCII space, much like \t for tab. The changes are primarily in the compiler, with some small changes in String::translateEscapes. Small changeset overall.
>> Thank you.
>> -- Jim
>> webrev: http://cr.openjdk.java.net/~jlaskey/8233116/webrev/index.html 
>> jbs: https://bugs.openjdk.java.net/browse/JDK-8233116 
>> csr: https://bugs.openjdk.java.net/browse/JDK-8233117 


From adam.farley at uk.ibm.com  Fri Nov  8 13:49:09 2019
From: adam.farley at uk.ibm.com (Adam Farley8)
Date: Fri, 8 Nov 2019 13:49:09 +0000
Subject: RFR: JDK-8232773: ClassLoading Debug Output for Specific Classes
In-Reply-To: 
References: 
 
 
 <273d90f3-9e0b-0689-49eb-51be414bbaf3@oracle.com>
 <244a76db-437a-822f-1504-7f881e3dfa8b@oracle.com>
 
 <70e9ba6c-54bb-abac-0618-8d7709fc3730@oracle.com>
 
 
Message-ID: 

Hi Mandy,

Sorry for the delay in responding.

Mandy Chung  wrote on 29/10/2019 19:30:55:

> From: Mandy Chung 
> To: Adam Farley8 
> Cc: core-libs-dev 
> Date: 29/10/2019 19:31
> Subject: [EXTERNAL] Re: RFR: JDK-8232773: ClassLoading Debug Output 
> for Specific Classes
> 
> Hi Adam,
> 
> It'd be useful to provide a few typical scenarios that customers run 
into.
> 
> That would give better understanding on the problem "hard to diagnose 
> why a given class was not loaded" and help the consideration on 
> alternatives.   

I'm happy to provide some hypothetical example scenarios, which I've
included below. We should note that this is not limited to customers, and
that this sort of diagnostic output is also extremely useful for people
helping customers to resolve issues.

I've also included the way the webrev's debug output aids people trying
to reproduce this problem.

Scenario 1: A user gets a ClassNotFoundException because the location
of the class is not on the classpath used by the ClassLoader/s that
attempted to load it, despite the fact that one ClassLoader definitely
has the location of the class on its classpath.

Aid: This webrev's debug output tells the user, or the tech support 
aiding the user:
- If the ClassLoader with the classpath location for that class is
ever tasked with trying to load that class.
- If the ClassLoader with the classpath location for that class 
actually tries to load that class from the classpath (vs a module).
- If the ClassLoader with the classpath location actually checks that
location at all.
- What other ClassLoaders are used to attempt to load that class,
allowing the user/support agent to adjust the classpath for another 
ClassLoader if needed.

Scenario 2: A program uses the wrong version of a class.

Aid: This webrev's debug output tells the user, or the tech support 
aiding the user:
- Which classpath was used by the ClassLoader that loaded the class
at the time that the class was loaded.
- Which locations were checked by that ClassLoader before finding the
wrong version of the class. This, among other things, helps identify
access issues for the location of the correct class.
- Which ClassLoaders attempted to load the class, and in which order,
(increasingly useful in the current "nested" ClassLoading model).

Scenario 3: A program is unable to find a class because none of the
ClassLoaders could find it, and you lack both familiarity with the
ClassLoader code, and the time to figure out how all of the different
ones work.

Aid: This webrev's debug output tells the user, or the tech support 
aiding the user:
- Which ClassLoaders were involved in each attempt to load the class.
- What the logic path was for each ClassLoader asked to load the
class.
- Which module/s, if any, were identified by the ClassLoader as the 
potential owner/s of the class, and how that worked out in each
case.

> The debug output could produce lots of trace output but 
> the output does not clearly indicate the initiating class is.  

Correct. The scope of my debug output was limited to the actions
of the ClassLoader/s attempting to load a class that matches a
specific regex.

> I wonder 
> if the problem you are looking at is related to JDK-6747450 [1] or 
> really tracing the class loader delegation and search path. 

The latter. If I implied that I was interested in the initiating class,
then I was wrong. Also, though I am not fundamentally opposed to
expanding the scope to incorporate JDK-6747450, the fact that it's been
drifting for nine years tells me I'd just be adding complexity without
adding anything that would support the inclusion of the change.

Short version: I think this issue's scope should not include details
of the initiating class.

> Or maybe 
> Java Flight Recorder is a better candidate? 

I don't know much about Java Flight Recorder, as it currently only 
supports one of the VMs I work with.

>  Without knowing specific 
> of the problems customers have, perhaps VM logging can be enhanced to 
> trace the initiating class and class loader?
> 
> Mandy

It's possible. I wouldn't know where to start with that. The simplest,
and most straight-forward approach (in my mind) is to add the debug
code directly to the code we're debugging.

Plus, using a Class Library -based approach ensures that the debug
output is available regardless of the VM being used, or the user's
familiarity with Flight Recorder.

Though this might just be a "me" problem. ;)

What do you think?

Best Regards

Adam Farley



> [1] https://urldefense.proofpoint.com/v2/url?
> 
u=https-3A__bugs.openjdk.java.net_browse_JDK-2D6747450&d=DwIDaQ&c=jf_iaSHvJObTbx-
> siA1ZOg&r=P5m8KWUXJf-
> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=BL4kVqghO4gn5XZF6vk60QTPyLdZ5Q0i-
> YQhYV5AAXM&s=CRaeo9i-X27ZxNvgxD0IOJVROj6VpmLk5YINn7iJaVA&e= 
> 
> On 10/29/19 5:08 AM, Adam Farley8 wrote:
> > Hey All,
> >
> > To restart (and re-centre) the chat on this:
> >
> > The issue I'm trying to solve is that it's hard to determine why a 
given
> > class was not loaded by OpenJDK.
> >
> > The solution I proposed was additional (optional) debug output from 
the
> > different classloaders.
> >
> > This way we can find out:
> >
> > - Whether any classloaders tried to load the class from your class'
> > location (by displaying all locations they try to load the class 
from).
> > - Which type of ClassLoaders tried to find your class.
> > - Which classpath each ClassLoader tried to use.
> > - Which modules were consulted.
> > etc etc.
> >
> > Currently, it seems the only debug information available in this 
regard
> > centres around:
> >
> > - Classes that were successfully loaded
> > and
> > - Exceptions when the class couldn't be loaded.
> >
> > So my questions are:
> >
> > 1) Am I trying to solve the right problem here?
> >
> > 2) Is there any support for this solution in principle, despite the 
fact
> > that the webrev in its current form is...unrefined?
> >
> > 3) Is there a better way to get this information, with or without a 
code
> > change?
> >
> > Advice or opinions are appreciated.
> >
> >
> > Bug:https://urldefense.proofpoint.com/v2/url?
> 
u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8232773&d=DwIDaQ&c=jf_iaSHvJObTbx-
> siA1ZOg&r=P5m8KWUXJf-
> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=BL4kVqghO4gn5XZF6vk60QTPyLdZ5Q0i-
> YQhYV5AAXM&s=2uCIP9fqdKT2SmB0pjQXfhMGlAyZ9F-xdaW4Xp9elo4&e= 
> >
> > Rough example webrev:https://urldefense.proofpoint.com/v2/url?
> 
u=http-3A__cr.openjdk.java.net_-7Eafarley_8232773_webrev_&d=DwIDaQ&c=jf_iaSHvJObTbx-
> siA1ZOg&r=P5m8KWUXJf-
> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=BL4kVqghO4gn5XZF6vk60QTPyLdZ5Q0i-
> YQhYV5AAXM&s=Il7T1mpLjlE5s1Yvy4qteJTKQ3l6o7THfwH6RaEuzF8&e= 
> >
> > Best Regards
> >
> > Adam Farley
> > IBM Runtimes
> >
> >
> >
> >
> > From:   David Holmes
> > To:     Martin Buchholz
> > Cc:     Ioi Lam, core-libs-dev
> > , Adam Farley8
> > Date:   24/10/2019 05:22
> > Subject:        [EXTERNAL] Re: RFR: JDK-8232773: ClassLoading Debug 
Output
> > for Specific Classes
> >
> >
> >
> > Hi Martin,
> >
> > This is going a bit OT I think ...
> >
> > On 24/10/2019 1:24 pm, Martin Buchholz wrote:
> >> On Tue, Oct 22, 2019 at 3:58 PM David Holmes  >> > wrote:
> >>
> >>
> >>      Perhaps one aspect of the class 
loading/resolution/initialization
> >>      process that can lead to confusion here is that if a class fails 
to
> >>      execute its static initialization then it is marked as Erroneous 
and
> >>      all
> >>      subsequent attempts to use that class result in 
NoClassDefFoundError
> >>      being thrown. If the original ExceptionInInitializerError got
> > swallowed
> >>      somewhere then that can cause great confusion as to why the 
later
> > NCDFE
> >>      occurs. The VM logging should help in that case - though I'd 
have to
> >>      confirm that (if it doesn't that should be fixed).
> >>
> >>
> >> I had a need to debug an error in a  this week and was again
> >> frustrated by the difficulty.
> >> Classes falling into Erroneous state are rare so it seems reasonable 
to
> >> save the exception as a cause for the subsequent NCDFE (probably 
can't
> >> fix the misleading name of the exception)
> > So as you know such a request existed:
> >
> > https://urldefense.proofpoint.com/v2/url?
> 
u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8048190&d=DwIDaQ&c=jf_iaSHvJObTbx-
> siA1ZOg&r=P5m8KWUXJf-
> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=AfL8IyQ5gm4a9cA4orx0EnUwiGqvG6rei-
> DuA8gA0jQ&s=pzILDarpf9cN_MvQFqk1u3YZqFzSCRbBZVoRdFw4lS4&e= 
> >
> >
> > and was closed as it was considered that TraceExceptions (now
> > -Xlog:exceptions) would provide the additional information. As noted 
in
> > that bug there are also semantic issues about recording the cause of 
an
> > exception in thread B, with an exception object that was thrown in
> > thread A. So unless someone comes up with a very convincing argument, 
or
> > else it prepared to do the work, I don't see that being re-opened.
> >
> >> I couldn't find a way to get hotspot to report the stack trace of all
> >> exceptions that are thrown; -Xlog:exceptions=trace does not .
> > -Xlog:exceptions shows where the exception is thrown and how it 
proceeds
> > up the stack. It doesn't print the full stacktrace. That seems like a
> > logging request for the Throwable constructor, or fillInStackTrace, to
> > me, rather than trying to have the VM do it. IIRC we store minimal VM
> > information in the backTrace which is expanded when needed into the 
full
> > StacktraceElements array.
> >> I was also frustrated that a StackOverflowError failed to report the
> >> name of the thread and the stack size that was exceeded.  But
> >> -Xlog:threads*=trace helped there.
> > The issue there is that SOE instances are allocated natively without
> > executing any Java code (as we have run out of the Java stack) so we
> > can't (easily) create a String message for the exception. However
> > -Xlog:exceptions could be expanded to report that information at the
> > point we throw the SOE. I filed - JDK-8232923.
> >
> > Cheers,
> > David
> >
> >
> >
> >
> > 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 Matthew.Carter at microsoft.com  Fri Nov  8 15:43:59 2019
From: Matthew.Carter at microsoft.com (Mat Carter)
Date: Fri, 8 Nov 2019 15:43:59 +0000
Subject: RFR: 8231863: Crash if classpath is read from @argument file and
 the main gets option argument
In-Reply-To: <66980a25-e3fc-dbfb-b95e-7dfe7cd2f697@oracle.com>
References: 
 <6788F903-A838-4D86-B511-DD7E64E9CE2B@oracle.com>
 <8EC6F4F1-EAF6-4EB3-9F7F-F7A37A759E84@oracle.com>
 
 <10E09EEE-553E-4CBA-81BF-55DFA7C137BB@oracle.com>,
 <66980a25-e3fc-dbfb-b95e-7dfe7cd2f697@oracle.com>
Message-ID: 

Hi Alan

The method you propose: [nio.]Files[.write](aFile.toPath, lines) adds a trailing blank line to the file; the regression test needs to generate a file without a trailing blank line as this is the condition in which the bug occurs.  This is why it now writes out an array of bytes

Cheers
Mat

________________________________
From: core-libs-dev  on behalf of Alan Bateman 
Sent: Friday, November 8, 2019 2:56 AM
To: Henry Jen ; core-libs-dev at openjdk.java.net 
Subject: Re: RFR: 8231863: Crash if classpath is read from @argument file and the main gets option argument

On 07/11/2019 22:55, Henry Jen wrote:
> Hi,
>
> Please review the webrev[1], contributed by Mat Carter. You can find the bug details at JBS[2]. I have reviewed and tested the fix, I still need an official review before I can push this.
>
Looks okay although in the test, the createAFile helper method could be
replaced with Files(aFile.toPath, lines) and that would avoid the need
to concatenate all the lines. You can specify the defaultCharset to that
method if you need really it.

-Alan

From andy.herrick at oracle.com  Fri Nov  8 16:03:19 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Fri, 8 Nov 2019 11:03:19 -0500
Subject: RFR: JDK-823359: Reorder jpackage help text to focus on package
Message-ID: <62ed9f4b-d0d6-0b01-eca2-a2e105518b5e@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 fix reorders the sample usage in the help text.

[1] https://bugs.openjdk.java.net/browse/JDK-8233591

[2] https://cr.openjdk.java.net/~herrick/8233591

/Andy


From maurizio.cimadamore at oracle.com  Fri Nov  8 16:28:53 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 8 Nov 2019 16:28:53 +0000
Subject: RFR: JDK-8233117 Escape Sequences For Line Continuation and White
 Space (Preview)
In-Reply-To: 
References: <0EEF3461-D8A4-496B-87DE-F143CB0FB995@oracle.com>
 <414cb097-9616-f4b0-8a3d-462a9ccfbdea@oracle.com>
 
Message-ID: <0aa5b2c5-bb74-d72a-0770-1133001e0f8a@oracle.com>

Hi Jim,
the tokenizer changes looks good.

I was very confused by the dance between:

// Indicate that the final string should have escapes translated.
 ???????????????????? shouldTranslateEscapes = true;

This:

// Conditionally translate or validate escape sequence and add result to 
string buffer.
 ??????????????? scanLitChar(pos, !shouldTranslateEscapes, openCount != 1);


And then this:

 ??? private void scanLitChar(int pos, boolean translate, boolean 
multiline) {


As discussed offline, I think the confusion arises that, in the 
tokenizer, the 'shouldTranslateEscape' is some kind of a global variable 
which means "should we translate escapes AFTER reading the string 
literal", whereas the 'translate' parameter in scanLitChar means "should 
we translate escapes NOW".

The overlapping (but not identical) meaning of the two is confusing. I 
also wonder, if one is always the negation of the other, can we refer to 
the global 'shouldTranslateEscapes' from inside scanLitChar - maybe that 
will help getting rid of some of the indirection.

Thanks
Maurizio


On 08/11/2019 13:15, Jim Laskey wrote:
> Updated
>
> webrev: http://cr.openjdk.java.net/~jlaskey/8233116/webrev.01/index.html 
>
>
>> On Nov 7, 2019, at 5:23 PM, Brent Christian  wrote:
>>
>> Should the new escapes be added to the table in the String.translateEscapes() JavaDoc?
>>
>> -Brent
>>
>> On 11/7/19 6:22 AM, Jim Laskey wrote:
>>> Please review the following code changes. Provides for the introduction of two new escape sequences \ and \s.  \ allows developers to express unwieldy string literals in a text block as a cluster of short single line segments. The second is to allow developers to express ASCII space, much like \t for tab. The changes are primarily in the compiler, with some small changes in String::translateEscapes. Small changeset overall.
>>> Thank you.
>>> -- Jim
>>> webrev: http://cr.openjdk.java.net/~jlaskey/8233116/webrev/index.html 
>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8233116 
>>> csr: https://bugs.openjdk.java.net/browse/JDK-8233117 

From alexey.semenyuk at oracle.com  Fri Nov  8 17:39:55 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Fri, 8 Nov 2019 12:39:55 -0500
Subject: RFR: JDK-823359: Reorder jpackage help text to focus on package
In-Reply-To: <62ed9f4b-d0d6-0b01-eca2-a2e105518b5e@oracle.com>
References: <62ed9f4b-d0d6-0b01-eca2-a2e105518b5e@oracle.com>
Message-ID: 

Looks good

On 11/8/2019 11:03 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 fix reorders the sample usage in the help text.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8233591
>
> [2] https://cr.openjdk.java.net/~herrick/8233591
>
> /Andy
>


From kevin.rushforth at oracle.com  Fri Nov  8 18:14:36 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 8 Nov 2019 19:14:36 +0100
Subject: RFR: JDK-823359: Reorder jpackage help text to focus on package
In-Reply-To: 
References: <62ed9f4b-d0d6-0b01-eca2-a2e105518b5e@oracle.com>
 
Message-ID: 

It seems fine, but it might be even better to have both the non-modular 
and modular application examples be for the default package case and 
have a single example of --app-image. Also, I presume `--package-type` 
will be replaced with `--type` (or `-t`) to match the change in command 
line option name?

-- Kevin


On 11/8/2019 6:39 PM, Alexey Semenyuk wrote:
> Looks good
>
> On 11/8/2019 11:03 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 fix reorders the sample usage in the help text.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8233591
>>
>> [2] https://cr.openjdk.java.net/~herrick/8233591
>>
>> /Andy
>>
>


From huizhe.wang at oracle.com  Fri Nov  8 18:26:16 2019
From: huizhe.wang at oracle.com (Joe Wang)
Date: Fri, 8 Nov 2019 10:26:16 -0800
Subject: RFR [14/java.xml] 8233686: XML transformer uses excessive amount
 of memory
In-Reply-To: 
References: 
 
 
Message-ID: 

Thanks for looking at the changeset.

A small change to eliminate unnecessary object allocations, that's the 
whole purpose, and what makes it worth the effort. As for the exact 
numbers (of how much it might save), it depends on users/customers' 
environment.

In terms of keeping in sync, we do that for formal releases.

Best,
Joe

On 11/8/19 4:33 AM, Bernd Eckenfels wrote:
> This does save object allocations and churn, not memory footprint I guess. The namespace mapping contains multiple stacks (with object arrays) and a hashtable and initialized records, so it seems to allocate a few kb on every node visited. (But 100MB allocation does sound like a very constructed case)
>
> BTW the thing I wondered, is there a process to keep xerces in sync?
>
> Gruss
> Bernd
>
>
> --
> http://bernd.eckenfels.net
>
> ________________________________
> Von: core-libs-dev  im Auftrag von Vyom Tiwari 
> Gesendet: Freitag, November 8, 2019 11:14 AM
> An: Joe Wang
> Cc: core-libs-dev
> Betreff: Re: RFR [14/java.xml] 8233686: XML transformer uses excessive amount of memory
>
> Hi Joe,
>
> Fix looks OK to me , but i am not able to understand how come
> "NamespaceMappings" instance can increase memory uses from (20MB to 140MB
> ).
>
> Current scope of "ns" is "case Node.ELEMENT_NODE:" block and
> "NamespaceMapping" seems to be very lightweight class.
>
> Thanks,
> Vyom
>
> On Fri, Nov 8, 2019 at 12:33 AM Joe Wang  wrote:
>
>> Please review a quick fix that reduces unnecessary object allocations.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8233686
>> webrev: http://cr.openjdk.java.net/~joehw/jdk14/8233686/webrev/
>>
>> Thanks,
>> Joe
>>
>>
> --
> Thanks,
> Vyom


From andy.herrick at oracle.com  Fri Nov  8 19:38:18 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Fri, 8 Nov 2019 14:38:18 -0500
Subject: RFR: JDK-8233636: Make jpackage an incubator and remove tool
 provider implementation
In-Reply-To: 
References: 
Message-ID: <8704ffcb-34fb-8712-8bea-5ca562dab42e@oracle.com>

Please review the revised jpackage fix for bug [1] at [3].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).

This webrev (webrev.03) addresses feedback from previous version 
(webrev.02).

[1] https://bugs.openjdk.java.net/browse/JDK-8233636

[2] https://cr.openjdk.java.net/~herrick/8233636/webrev.02

[3] https://cr.openjdk.java.net/~herrick/8233636/webrev.03

/Andy

From andy.herrick at oracle.com  Fri Nov  8 20:41:40 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Fri, 8 Nov 2019 15:41:40 -0500
Subject: RFR: JDK-8233591: Reorder jpackage help text to focus on package
Message-ID: <3fe92015-ca7f-6365-152d-5c6968c0fd12@oracle.com>

Please review the revised jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).

This fix (webrev.02) was revised after feedback from webrev.01.

[1] https://bugs.openjdk.java.net/browse/JDK-8233591

[2] http://cr.openjdk.java.net/~herrick/8233591/webrev.02/

/Andy


From alexey.semenyuk at oracle.com  Fri Nov  8 20:55:27 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Fri, 8 Nov 2019 15:55:27 -0500
Subject: RFR: JDK-8233636: Make jpackage an incubator and remove tool
 provider implementation
In-Reply-To: <8704ffcb-34fb-8712-8bea-5ca562dab42e@oracle.com>
References: 
 <8704ffcb-34fb-8712-8bea-5ca562dab42e@oracle.com>
Message-ID: <4331931b-c47f-d311-d02b-9baa0c1caa86@oracle.com>

Looks good.

- Alexey

On 11/8/2019 2:38 PM, Andy Herrick wrote:
> Please review the revised jpackage fix for bug [1] at [3].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> This webrev (webrev.03) addresses feedback from previous version 
> (webrev.02).
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8233636
>
> [2] https://cr.openjdk.java.net/~herrick/8233636/webrev.02
>
> [3] https://cr.openjdk.java.net/~herrick/8233636/webrev.03
>
> /Andy


From alexey.semenyuk at oracle.com  Fri Nov  8 21:07:24 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Fri, 8 Nov 2019 16:07:24 -0500
Subject: RFR: JDK-8233591: Reorder jpackage help text to focus on package
In-Reply-To: <3fe92015-ca7f-6365-152d-5c6968c0fd12@oracle.com>
References: <3fe92015-ca7f-6365-152d-5c6968c0fd12@oracle.com>
Message-ID: 

This is minor and not directly related to this change, but looks like we 
have inconsistency in names in Sample usages.
Names used: modulePath, ModulePath, moduleName, className, 
moduleName/ClassName, moduleName/className, package.ClassName, inputdir, 
MyJar.jar, appRuntimeImage, name, .
I'd suggest the following changes if we are touching this section of 
help anyways:
package.ClassName -> packageName.className
MyJar.jar -> myJar.jar
inputdir -> inputDir
ModulePath -> modulePath
moduleName/ClassName -> moduleName/className
 -> appImageDir

- Alexey

On 11/8/2019 3:41 PM, Andy Herrick wrote:
> Please review the revised jpackage fix for bug [1] at [2].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> This fix (webrev.02) was revised after feedback from webrev.01.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8233591
>
> [2] http://cr.openjdk.java.net/~herrick/8233591/webrev.02/
>
> /Andy
>


From andy.herrick at oracle.com  Fri Nov  8 21:31:09 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Fri, 8 Nov 2019 16:31:09 -0500
Subject: RFR: JDK-8233591: Reorder jpackage help text to focus on package
In-Reply-To: 
References: <3fe92015-ca7f-6365-152d-5c6968c0fd12@oracle.com>
 
Message-ID: 

revised [3] as per below suggestions.

[3] http://cr.openjdk.java.net/~herrick/8233591/webrev.03

/Andy


On 11/8/2019 4:07 PM, Alexey Semenyuk wrote:
> This is minor and not directly related to this change, but looks like 
> we have inconsistency in names in Sample usages.
> Names used: modulePath, ModulePath, moduleName, className, 
> moduleName/ClassName, moduleName/className, package.ClassName, 
> inputdir, MyJar.jar, appRuntimeImage, name, .
> I'd suggest the following changes if we are touching this section of 
> help anyways:
> package.ClassName -> packageName.className
> MyJar.jar -> myJar.jar
> inputdir -> inputDir
> ModulePath -> modulePath
> moduleName/ClassName -> moduleName/className
>  -> appImageDir
>
> - Alexey
>
> On 11/8/2019 3:41 PM, Andy Herrick wrote:
>> Please review the revised jpackage fix for bug [1] at [2].
>>
>> This is a fix for the JDK-8200758-branch branch of the open sandbox 
>> repository (jpackage).
>>
>> This fix (webrev.02) was revised after feedback from webrev.01.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8233591
>>
>> [2] http://cr.openjdk.java.net/~herrick/8233591/webrev.02/
>>
>> /Andy
>>
>

From sergei.tsypanov at yandex.ru  Fri Nov  8 22:04:27 2019
From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=)
Date: Sat, 09 Nov 2019 00:04:27 +0200
Subject: [PATCH] Enhancement proposal for usage of Method::getParameterTypes
Message-ID: <81964221573250667@myt5-1466095fe4e5.qloud-c.yandex.net>

Hello,

it seems like Method.getParameterTypes() is often misused in JDK (and beyond): array returned from the method is used only to acquire number of method params by retrieving array.length.
The problem here is that Method.getPatameterTypes() clones underlying array and returns the copy.
Instead we can use Method.getParameterCount() which doesn't allocate any additional memory but returns directly the length of underlying  array.

To measure probable performance difference I've created a benchmark for the most simple case when tested method has no parameters:

@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class MethodToStringBenchmark {
  private Method method;

  @Setup
  public void setup() throws Exception { method = getClass().getMethod("toString"); }

  @Benchmark
  public int getParameterCount() { return method.getParameterCount(); }

  @Benchmark
  public int getParameterTypes() { return method.getParameterTypes().length; }
}

on my i7-7700 with JDK 11 it produces these results:


Benchmark                                                               Mode  Cnt     Score    Error   Units

MethodToStringBenchmark.getParameterCount                               avgt   25     2,528 ?  0,085   ns/op
MethodToStringBenchmark.getParameterCount:?gc.alloc.rate                avgt   25    ? 10??           MB/sec
MethodToStringBenchmark.getParameterCount:?gc.alloc.rate.norm           avgt   25    ? 10??             B/op
MethodToStringBenchmark.getParameterCount:?gc.count                     avgt   25       ? 0           counts

MethodToStringBenchmark.getParameterTypes                               avgt   25     7,299 ?  0,410   ns/op
MethodToStringBenchmark.getParameterTypes:?gc.alloc.rate                avgt   25  1999,454 ? 89,929  MB/sec
MethodToStringBenchmark.getParameterTypes:?gc.alloc.rate.norm           avgt   25    16,000 ?  0,001    B/op
MethodToStringBenchmark.getParameterTypes:?gc.churn.G1_Eden_Space       avgt   25  2003,360 ? 91,537  MB/sec
MethodToStringBenchmark.getParameterTypes:?gc.churn.G1_Eden_Space.norm  avgt   25    16,030 ?  0,045    B/op
MethodToStringBenchmark.getParameterTypes:?gc.churn.G1_Old_Gen          avgt   25     0,004 ?  0,001  MB/sec
MethodToStringBenchmark.getParameterTypes:?gc.churn.G1_Old_Gen.norm     avgt   25    ? 10??             B/op
MethodToStringBenchmark.getParameterTypes:?gc.count                     avgt   25  2380,000           counts
MethodToStringBenchmark.getParameterTypes:?gc.time                      avgt   25  1325,000               ms

I've prepared a small patch to replace usage of getParameterTypes() with getParameterCount() where appropriate in java.base module.

The patch is attached.

Regards,
Sergey Tsypanov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: getParamCount.patch
Type: text/x-diff
Size: 3558 bytes
Desc: not available
URL: 

From alexander.matveev at oracle.com  Fri Nov  8 22:21:37 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Fri, 8 Nov 2019 14:21:37 -0800
Subject: RFR: JDK-8233636: Make jpackage an incubator and remove tool
 provider implementation
In-Reply-To: <8704ffcb-34fb-8712-8bea-5ca562dab42e@oracle.com>
References: 
 <8704ffcb-34fb-8712-8bea-5ca562dab42e@oracle.com>
Message-ID: <5432f3b8-a699-9ca9-526e-0e32b479442d@oracle.com>

Looks good.

On 11/8/2019 11:38 AM, Andy Herrick wrote:
> Please review the revised jpackage fix for bug [1] at [3].
>
> This is a fix for the JDK-8200758-branch branch of the open sandbox 
> repository (jpackage).
>
> This webrev (webrev.03) addresses feedback from previous version 
> (webrev.02).
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8233636
>
> [2] https://cr.openjdk.java.net/~herrick/8233636/webrev.02
>
> [3] https://cr.openjdk.java.net/~herrick/8233636/webrev.03
>
> /Andy


From alexander.matveev at oracle.com  Fri Nov  8 23:14:04 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Fri, 8 Nov 2019 15:14:04 -0800
Subject: RFR: JDK-8233591: Reorder jpackage help text to focus on package
In-Reply-To: 
References: <3fe92015-ca7f-6365-152d-5c6968c0fd12@oracle.com>
 
 
Message-ID: <8811f446-99a1-21b3-e28f-54562770f608@oracle.com>

Looks good.

On 11/8/2019 1:31 PM, Andy Herrick wrote:
> revised [3] as per below suggestions.
>
> [3] http://cr.openjdk.java.net/~herrick/8233591/webrev.03
>
> /Andy
>
>
> On 11/8/2019 4:07 PM, Alexey Semenyuk wrote:
>> This is minor and not directly related to this change, but looks like 
>> we have inconsistency in names in Sample usages.
>> Names used: modulePath, ModulePath, moduleName, className, 
>> moduleName/ClassName, moduleName/className, package.ClassName, 
>> inputdir, MyJar.jar, appRuntimeImage, name, .
>> I'd suggest the following changes if we are touching this section of 
>> help anyways:
>> package.ClassName -> packageName.className
>> MyJar.jar -> myJar.jar
>> inputdir -> inputDir
>> ModulePath -> modulePath
>> moduleName/ClassName -> moduleName/className
>>  -> appImageDir
>>
>> - Alexey
>>
>> On 11/8/2019 3:41 PM, Andy Herrick wrote:
>>> Please review the revised jpackage fix for bug [1] at [2].
>>>
>>> This is a fix for the JDK-8200758-branch branch of the open sandbox 
>>> repository (jpackage).
>>>
>>> This fix (webrev.02) was revised after feedback from webrev.01.
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8233591
>>>
>>> [2] http://cr.openjdk.java.net/~herrick/8233591/webrev.02/
>>>
>>> /Andy
>>>
>>


From claes.redestad at oracle.com  Fri Nov  8 23:18:03 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Sat, 9 Nov 2019 00:18:03 +0100
Subject: [PATCH] Enhancement proposal for usage of
 Method::getParameterTypes
In-Reply-To: <81964221573250667@myt5-1466095fe4e5.qloud-c.yandex.net>
References: <81964221573250667@myt5-1466095fe4e5.qloud-c.yandex.net>
Message-ID: 

Hi,

some or all of these were pointed out as part of
https://bugs.openjdk.java.net/browse/JDK-8029019

There was a patch out for review early 2017. I'm not sure what happened
to that?

Either way I think it might make sense to get this small and trivial
enhancement separated out and fixed.

Thanks!

/Claes

On 2019-11-08 23:04, ?????? ??????? wrote:
> Hello,
> 
> it seems like Method.getParameterTypes() is often misused in JDK (and beyond): array returned from the method is used only to acquire number of method params by retrieving array.length.
> The problem here is that Method.getPatameterTypes() clones underlying array and returns the copy.
> Instead we can use Method.getParameterCount() which doesn't allocate any additional memory but returns directly the length of underlying  array.
> 
> To measure probable performance difference I've created a benchmark for the most simple case when tested method has no parameters:
> 
> @State(Scope.Thread)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class MethodToStringBenchmark {
>    private Method method;
> 
>    @Setup
>    public void setup() throws Exception { method = getClass().getMethod("toString"); }
> 
>    @Benchmark
>    public int getParameterCount() { return method.getParameterCount(); }
> 
>    @Benchmark
>    public int getParameterTypes() { return method.getParameterTypes().length; }
> }
> 
> on my i7-7700 with JDK 11 it produces these results:
> 
> 
> Benchmark                                                               Mode  Cnt     Score    Error   Units
> 
> MethodToStringBenchmark.getParameterCount                               avgt   25     2,528 ?  0,085   ns/op
> MethodToStringBenchmark.getParameterCount:?gc.alloc.rate                avgt   25    ? 10??           MB/sec
> MethodToStringBenchmark.getParameterCount:?gc.alloc.rate.norm           avgt   25    ? 10??             B/op
> MethodToStringBenchmark.getParameterCount:?gc.count                     avgt   25       ? 0           counts
> 
> MethodToStringBenchmark.getParameterTypes                               avgt   25     7,299 ?  0,410   ns/op
> MethodToStringBenchmark.getParameterTypes:?gc.alloc.rate                avgt   25  1999,454 ? 89,929  MB/sec
> MethodToStringBenchmark.getParameterTypes:?gc.alloc.rate.norm           avgt   25    16,000 ?  0,001    B/op
> MethodToStringBenchmark.getParameterTypes:?gc.churn.G1_Eden_Space       avgt   25  2003,360 ? 91,537  MB/sec
> MethodToStringBenchmark.getParameterTypes:?gc.churn.G1_Eden_Space.norm  avgt   25    16,030 ?  0,045    B/op
> MethodToStringBenchmark.getParameterTypes:?gc.churn.G1_Old_Gen          avgt   25     0,004 ?  0,001  MB/sec
> MethodToStringBenchmark.getParameterTypes:?gc.churn.G1_Old_Gen.norm     avgt   25    ? 10??             B/op
> MethodToStringBenchmark.getParameterTypes:?gc.count                     avgt   25  2380,000           counts
> MethodToStringBenchmark.getParameterTypes:?gc.time                      avgt   25  1325,000               ms
> 
> I've prepared a small patch to replace usage of getParameterTypes() with getParameterCount() where appropriate in java.base module.
> 
> The patch is attached.
> 
> Regards,
> Sergey Tsypanov
> 

From alexey.semenyuk at oracle.com  Sat Nov  9 01:50:46 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Fri, 8 Nov 2019 20:50:46 -0500
Subject: RFR: JDK-8233591: Reorder jpackage help text to focus on package
In-Reply-To: 
References: <3fe92015-ca7f-6365-152d-5c6968c0fd12@oracle.com>
 
 
Message-ID: <4b5561b9-7caf-ebd8-de2b-c24a2fc2d607@oracle.com>

Looks good.

- Alexey

On 11/8/2019 4:31 PM, Andy Herrick wrote:
> revised [3] as per below suggestions.
>
> [3] http://cr.openjdk.java.net/~herrick/8233591/webrev.03
>
> /Andy
>
>
> On 11/8/2019 4:07 PM, Alexey Semenyuk wrote:
>> This is minor and not directly related to this change, but looks like 
>> we have inconsistency in names in Sample usages.
>> Names used: modulePath, ModulePath, moduleName, className, 
>> moduleName/ClassName, moduleName/className, package.ClassName, 
>> inputdir, MyJar.jar, appRuntimeImage, name, .
>> I'd suggest the following changes if we are touching this section of 
>> help anyways:
>> package.ClassName -> packageName.className
>> MyJar.jar -> myJar.jar
>> inputdir -> inputDir
>> ModulePath -> modulePath
>> moduleName/ClassName -> moduleName/className
>>  -> appImageDir
>>
>> - Alexey
>>
>> On 11/8/2019 3:41 PM, Andy Herrick wrote:
>>> Please review the revised jpackage fix for bug [1] at [2].
>>>
>>> This is a fix for the JDK-8200758-branch branch of the open sandbox 
>>> repository (jpackage).
>>>
>>> This fix (webrev.02) was revised after feedback from webrev.01.
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8233591
>>>
>>> [2] http://cr.openjdk.java.net/~herrick/8233591/webrev.02/
>>>
>>> /Andy
>>>
>>


From kevin.rushforth at oracle.com  Sat Nov  9 05:37:45 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Sat, 9 Nov 2019 06:37:45 +0100
Subject: RFR: JDK-8233591: Reorder jpackage help text to focus on package
In-Reply-To: <4b5561b9-7caf-ebd8-de2b-c24a2fc2d607@oracle.com>
References: <3fe92015-ca7f-6365-152d-5c6968c0fd12@oracle.com>
 
 
 <4b5561b9-7caf-ebd8-de2b-c24a2fc2d607@oracle.com>
Message-ID: <6bfdab8d-1dbd-dbc3-ce37-41522f8e68ca@oracle.com>

I disagree with a couple of these changes, but they can be fixed in a 
subsequent pass, since you've already pushed the changes.

By convention, class names are camel case with leading upper-case 
letter, so ClassName expresses that better than className. Similarly, 
MyJar.jar seems better to me than myJar.jar. By convention, package 
names don't have upper-case letters at all, so package.name or `mypkg` 
might be better than packageName.

-- Kevin

On 11/9/2019 2:50 AM, Alexey Semenyuk wrote:
> Looks good.
>
> - Alexey
>
> On 11/8/2019 4:31 PM, Andy Herrick wrote:
>> revised [3] as per below suggestions.
>>
>> [3] http://cr.openjdk.java.net/~herrick/8233591/webrev.03
>>
>> /Andy
>>
>>
>> On 11/8/2019 4:07 PM, Alexey Semenyuk wrote:
>>> This is minor and not directly related to this change, but looks 
>>> like we have inconsistency in names in Sample usages.
>>> Names used: modulePath, ModulePath, moduleName, className, 
>>> moduleName/ClassName, moduleName/className, package.ClassName, 
>>> inputdir, MyJar.jar, appRuntimeImage, name, .
>>> I'd suggest the following changes if we are touching this section of 
>>> help anyways:
>>> package.ClassName -> packageName.className
>>> MyJar.jar -> myJar.jar
>>> inputdir -> inputDir
>>> ModulePath -> modulePath
>>> moduleName/ClassName -> moduleName/className
>>>  -> appImageDir
>>>
>>> - Alexey
>>>
>>> On 11/8/2019 3:41 PM, Andy Herrick wrote:
>>>> Please review the revised jpackage fix for bug [1] at [2].
>>>>
>>>> This is a fix for the JDK-8200758-branch branch of the open sandbox 
>>>> repository (jpackage).
>>>>
>>>> This fix (webrev.02) was revised after feedback from webrev.01.
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8233591
>>>>
>>>> [2] http://cr.openjdk.java.net/~herrick/8233591/webrev.02/
>>>>
>>>> /Andy
>>>>
>>>
>


From mandy.chung at oracle.com  Sat Nov  9 19:33:53 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Sat, 9 Nov 2019 11:33:53 -0800
Subject: RFR: 8231863: Crash if classpath is read from @argument file and
 the main gets option argument
In-Reply-To: 
References: 
 <6788F903-A838-4D86-B511-DD7E64E9CE2B@oracle.com>
 <8EC6F4F1-EAF6-4EB3-9F7F-F7A37A759E84@oracle.com>
 
 <10E09EEE-553E-4CBA-81BF-55DFA7C137BB@oracle.com>
 <66980a25-e3fc-dbfb-b95e-7dfe7cd2f697@oracle.com>
 
Message-ID: <1ba1d75b-ef9f-e953-fd4f-b342fcde4a91@oracle.com>

The patch looks fine to me as well.

As for the test, perhaps adding a new createAFile(File aFile, 
List lines, boolean hasTrailingBlankLine) in TestHelper instead 
may help avoid any confusion.


Mandy

On 11/8/19 7:43 AM, Mat Carter wrote:
> Hi Alan
>
> The method you propose: [nio.]Files[.write](aFile.toPath, lines) adds a trailing blank line to the file; the regression test needs to generate a file without a trailing blank line as this is the condition in which the bug occurs.  This is why it now writes out an array of bytes
>
> Cheers
> Mat
>
> ________________________________
> From: core-libs-dev  on behalf of Alan Bateman 
> Sent: Friday, November 8, 2019 2:56 AM
> To: Henry Jen ; core-libs-dev at openjdk.java.net 
> Subject: Re: RFR: 8231863: Crash if classpath is read from @argument file and the main gets option argument
>
> On 07/11/2019 22:55, Henry Jen wrote:
>> Hi,
>>
>> Please review the webrev[1], contributed by Mat Carter. You can find the bug details at JBS[2]. I have reviewed and tested the fix, I still need an official review before I can push this.
>>
> Looks okay although in the test, the createAFile helper method could be
> replaced with Files(aFile.toPath, lines) and that would avoid the need
> to concatenate all the lines. You can specify the defaultCharset to that
> method if you need really it.
>
> -Alan


From alexey.semenyuk at oracle.com  Sat Nov  9 19:46:25 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Sat, 9 Nov 2019 14:46:25 -0500
Subject: RFR: JDK-8233591: Reorder jpackage help text to focus on package
In-Reply-To: <6bfdab8d-1dbd-dbc3-ce37-41522f8e68ca@oracle.com>
References: <3fe92015-ca7f-6365-152d-5c6968c0fd12@oracle.com>
 
 
 <4b5561b9-7caf-ebd8-de2b-c24a2fc2d607@oracle.com>
 <6bfdab8d-1dbd-dbc3-ce37-41522f8e68ca@oracle.com>
Message-ID: <548852d9-55ca-8d19-20ee-86e8e0ac2abc@oracle.com>

Kevin,

My point was to add consistency. We used to have class names in camel 
case and pascal case (className, ClassName) and this didn't look right 
for me. I agree ClassName, `mypkg` is more appropriate. I'm neutral 
about myJar.jar and MyJar.jar.

- Alexey

On 11/9/2019 12:37 AM, Kevin Rushforth wrote:
> I disagree with a couple of these changes, but they can be fixed in a 
> subsequent pass, since you've already pushed the changes.
>
> By convention, class names are camel case with leading upper-case 
> letter, so ClassName expresses that better than className. Similarly, 
> MyJar.jar seems better to me than myJar.jar. By convention, package 
> names don't have upper-case letters at all, so package.name or `mypkg` 
> might be better than packageName.
>
> -- Kevin
>
> On 11/9/2019 2:50 AM, Alexey Semenyuk wrote:
>> Looks good.
>>
>> - Alexey
>>
>> On 11/8/2019 4:31 PM, Andy Herrick wrote:
>>> revised [3] as per below suggestions.
>>>
>>> [3] http://cr.openjdk.java.net/~herrick/8233591/webrev.03
>>>
>>> /Andy
>>>
>>>
>>> On 11/8/2019 4:07 PM, Alexey Semenyuk wrote:
>>>> This is minor and not directly related to this change, but looks 
>>>> like we have inconsistency in names in Sample usages.
>>>> Names used: modulePath, ModulePath, moduleName, className, 
>>>> moduleName/ClassName, moduleName/className, package.ClassName, 
>>>> inputdir, MyJar.jar, appRuntimeImage, name, .
>>>> I'd suggest the following changes if we are touching this section 
>>>> of help anyways:
>>>> package.ClassName -> packageName.className
>>>> MyJar.jar -> myJar.jar
>>>> inputdir -> inputDir
>>>> ModulePath -> modulePath
>>>> moduleName/ClassName -> moduleName/className
>>>>  -> appImageDir
>>>>
>>>> - Alexey
>>>>
>>>> On 11/8/2019 3:41 PM, Andy Herrick wrote:
>>>>> Please review the revised jpackage fix for bug [1] at [2].
>>>>>
>>>>> This is a fix for the JDK-8200758-branch branch of the open 
>>>>> sandbox repository (jpackage).
>>>>>
>>>>> This fix (webrev.02) was revised after feedback from webrev.01.
>>>>>
>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8233591
>>>>>
>>>>> [2] http://cr.openjdk.java.net/~herrick/8233591/webrev.02/
>>>>>
>>>>> /Andy
>>>>>
>>>>
>>
>


From kevin.rushforth at oracle.com  Mon Nov 11 14:12:29 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 11 Nov 2019 06:12:29 -0800
Subject: RFR: JDK-8233591: Reorder jpackage help text to focus on package
In-Reply-To: <548852d9-55ca-8d19-20ee-86e8e0ac2abc@oracle.com>
References: <3fe92015-ca7f-6365-152d-5c6968c0fd12@oracle.com>
 
 
 <4b5561b9-7caf-ebd8-de2b-c24a2fc2d607@oracle.com>
 <6bfdab8d-1dbd-dbc3-ce37-41522f8e68ca@oracle.com>
 <548852d9-55ca-8d19-20ee-86e8e0ac2abc@oracle.com>
Message-ID: 

OK.

-- Kevin


On 11/9/2019 11:46 AM, Alexey Semenyuk wrote:
> Kevin,
>
> My point was to add consistency. We used to have class names in camel 
> case and pascal case (className, ClassName) and this didn't look right 
> for me. I agree ClassName, `mypkg` is more appropriate. I'm neutral 
> about myJar.jar and MyJar.jar.
>
> - Alexey
>
> On 11/9/2019 12:37 AM, Kevin Rushforth wrote:
>> I disagree with a couple of these changes, but they can be fixed in a 
>> subsequent pass, since you've already pushed the changes.
>>
>> By convention, class names are camel case with leading upper-case 
>> letter, so ClassName expresses that better than className. Similarly, 
>> MyJar.jar seems better to me than myJar.jar. By convention, package 
>> names don't have upper-case letters at all, so package.name or 
>> `mypkg` might be better than packageName.
>>
>> -- Kevin
>>
>> On 11/9/2019 2:50 AM, Alexey Semenyuk wrote:
>>> Looks good.
>>>
>>> - Alexey
>>>
>>> On 11/8/2019 4:31 PM, Andy Herrick wrote:
>>>> revised [3] as per below suggestions.
>>>>
>>>> [3] http://cr.openjdk.java.net/~herrick/8233591/webrev.03
>>>>
>>>> /Andy
>>>>
>>>>
>>>> On 11/8/2019 4:07 PM, Alexey Semenyuk wrote:
>>>>> This is minor and not directly related to this change, but looks 
>>>>> like we have inconsistency in names in Sample usages.
>>>>> Names used: modulePath, ModulePath, moduleName, className, 
>>>>> moduleName/ClassName, moduleName/className, package.ClassName, 
>>>>> inputdir, MyJar.jar, appRuntimeImage, name, .
>>>>> I'd suggest the following changes if we are touching this section 
>>>>> of help anyways:
>>>>> package.ClassName -> packageName.className
>>>>> MyJar.jar -> myJar.jar
>>>>> inputdir -> inputDir
>>>>> ModulePath -> modulePath
>>>>> moduleName/ClassName -> moduleName/className
>>>>>  -> appImageDir
>>>>>
>>>>> - Alexey
>>>>>
>>>>> On 11/8/2019 3:41 PM, Andy Herrick wrote:
>>>>>> Please review the revised jpackage fix for bug [1] at [2].
>>>>>>
>>>>>> This is a fix for the JDK-8200758-branch branch of the open 
>>>>>> sandbox repository (jpackage).
>>>>>>
>>>>>> This fix (webrev.02) was revised after feedback from webrev.01.
>>>>>>
>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8233591
>>>>>>
>>>>>> [2] http://cr.openjdk.java.net/~herrick/8233591/webrev.02/
>>>>>>
>>>>>> /Andy
>>>>>>
>>>>>
>>>
>>
>


From fweimer at redhat.com  Mon Nov 11 15:30:45 2019
From: fweimer at redhat.com (Florian Weimer)
Date: Mon, 11 Nov 2019 16:30:45 +0100
Subject: _IEEE_LIBM targets and __kernel_standard
Message-ID: <87y2wmv3a2.fsf@oldenburg2.str.redhat.com>

__kernel_standard in src/java.base/share/native/libfdlibm/k_standard.c
is built for _IEEE_LIBM targets as well, but it appears superfluous
there.

In noticed this because GCC 10 flags an uninitialized variable in this
code:

?/src/java.base/share/native/libfdlibm/k_standard.c: In function '__j__kernel_standard':
?/src/java.base/share/native/libfdlibm/k_standard.c:743:19: error: 'exc.retval' may be used uninitialized in this function [-Werror=maybe-uninitialized]
  743 |         return exc.retval;
      |                ~~~^~~~~~~

Rather than debating whether this warning is reasonableor not, I would
suggest to #ifdef out this code for _IEEE_LIBM targets (are there any
else left?).

Thanks,
Florian


From henry.jen at oracle.com  Mon Nov 11 16:53:57 2019
From: henry.jen at oracle.com (Henry Jen)
Date: Mon, 11 Nov 2019 08:53:57 -0800
Subject: RFR: 8231863: Crash if classpath is read from @argument file and
 the main gets option argument
In-Reply-To: <1ba1d75b-ef9f-e953-fd4f-b342fcde4a91@oracle.com>
References: 
 <6788F903-A838-4D86-B511-DD7E64E9CE2B@oracle.com>
 <8EC6F4F1-EAF6-4EB3-9F7F-F7A37A759E84@oracle.com>
 
 <10E09EEE-553E-4CBA-81BF-55DFA7C137BB@oracle.com>
 <66980a25-e3fc-dbfb-b95e-7dfe7cd2f697@oracle.com>
 
 <1ba1d75b-ef9f-e953-fd4f-b342fcde4a91@oracle.com>
Message-ID: <9FD787FF-8BE8-4B7C-8CBA-E71AC10C938C@oracle.com>

Thanks Alan and Mandy for the review.

I am guessing the Alan?s preference to use Files.write(aFilePath, lines) is to avoid extra String.join operation, which I would too. The current version with byte[] is more flexible but we most likely won't need it in launcher. Anyway, I don?t think the difference would be noticeable with launcher tests.

The updated webrev[1] takes a boolean to decide which Files.write to use but gives up the byte[] version.

Cheers,
Henry

[1] http://cr.openjdk.java.net/~henryjen/jdk/8231863.1/webrev/

> On Nov 9, 2019, at 11:33 AM, Mandy Chung  wrote:
> 
> The patch looks fine to me as well.
> 
> As for the test, perhaps adding a new createAFile(File aFile, List lines, boolean hasTrailingBlankLine) in TestHelper instead may help avoid any confusion.
> 
> 
> Mandy
> 
> On 11/8/19 7:43 AM, Mat Carter wrote:
>> Hi Alan
>> 
>> The method you propose: [nio.]Files[.write](aFile.toPath, lines) adds a trailing blank line to the file; the regression test needs to generate a file without a trailing blank line as this is the condition in which the bug occurs.  This is why it now writes out an array of bytes
>> 
>> Cheers
>> Mat
>> 
>> ________________________________
>> From: core-libs-dev  on behalf of Alan Bateman 
>> Sent: Friday, November 8, 2019 2:56 AM
>> To: Henry Jen ; core-libs-dev at openjdk.java.net 
>> Subject: Re: RFR: 8231863: Crash if classpath is read from @argument file and the main gets option argument
>> 
>> On 07/11/2019 22:55, Henry Jen wrote:
>>> Hi,
>>> 
>>> Please review the webrev[1], contributed by Mat Carter. You can find the bug details at JBS[2]. I have reviewed and tested the fix, I still need an official review before I can push this.
>>> 
>> Looks okay although in the test, the createAFile helper method could be
>> replaced with Files(aFile.toPath, lines) and that would avoid the need
>> to concatenate all the lines. You can specify the defaultCharset to that
>> method if you need really it.
>> 
>> -Alan
> 


From Alan.Bateman at oracle.com  Mon Nov 11 18:24:56 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 11 Nov 2019 18:24:56 +0000
Subject: RFR: 8231863: Crash if classpath is read from @argument file and
 the main gets option argument
In-Reply-To: <9FD787FF-8BE8-4B7C-8CBA-E71AC10C938C@oracle.com>
References: 
 <6788F903-A838-4D86-B511-DD7E64E9CE2B@oracle.com>
 <8EC6F4F1-EAF6-4EB3-9F7F-F7A37A759E84@oracle.com>
 
 <10E09EEE-553E-4CBA-81BF-55DFA7C137BB@oracle.com>
 <66980a25-e3fc-dbfb-b95e-7dfe7cd2f697@oracle.com>
 
 <1ba1d75b-ef9f-e953-fd4f-b342fcde4a91@oracle.com>
 <9FD787FF-8BE8-4B7C-8CBA-E71AC10C938C@oracle.com>
Message-ID: <58d36221-a7be-2c73-5f42-593cb60f4682@oracle.com>

On 11/11/2019 16:53, Henry Jen wrote:
> Thanks Alan and Mandy for the review.
>
> I am guessing the Alan?s preference to use Files.write(aFilePath, lines) is to avoid extra String.join operation, which I would too. The current version with byte[] is more flexible but we most likely won't need it in launcher. Anyway, I don?t think the difference would be noticeable with launcher tests.
>
The update looks good (and should avoid others tripping up on the subtly 
of the last line).

-Alan

From Matthew.Carter at microsoft.com  Mon Nov 11 18:53:12 2019
From: Matthew.Carter at microsoft.com (Mat Carter)
Date: Mon, 11 Nov 2019 18:53:12 +0000
Subject: RFR: 8231863: Crash if classpath is read from @argument file and
 the main gets option argument
In-Reply-To: <58d36221-a7be-2c73-5f42-593cb60f4682@oracle.com>
References: 
 <6788F903-A838-4D86-B511-DD7E64E9CE2B@oracle.com>
 <8EC6F4F1-EAF6-4EB3-9F7F-F7A37A759E84@oracle.com>
 
 <10E09EEE-553E-4CBA-81BF-55DFA7C137BB@oracle.com>
 <66980a25-e3fc-dbfb-b95e-7dfe7cd2f697@oracle.com>
 
 <1ba1d75b-ef9f-e953-fd4f-b342fcde4a91@oracle.com>
 <9FD787FF-8BE8-4B7C-8CBA-E71AC10C938C@oracle.com>,
 <58d36221-a7be-2c73-5f42-593cb60f4682@oracle.com>
Message-ID: 

Thanks for the feedback, it's been a great learning experience and I'll make sure to incorporate these considerations in future contributions

Cheers
Mat


Sent from Outlook

________________________________
From: Alan Bateman 
Sent: Monday, November 11, 2019 10:24 AM
To: Henry Jen ; Mandy Chung 
Cc: Mat Carter ; core-libs-dev at openjdk.java.net 
Subject: Re: RFR: 8231863: Crash if classpath is read from @argument file and the main gets option argument

On 11/11/2019 16:53, Henry Jen wrote:
> Thanks Alan and Mandy for the review.
>
> I am guessing the Alan?s preference to use Files.write(aFilePath, lines) is to avoid extra String.join operation, which I would too. The current version with byte[] is more flexible but we most likely won't need it in launcher. Anyway, I don?t think the difference would be noticeable with launcher tests.
>
The update looks good (and should avoid others tripping up on the subtly
of the last line).

-Alan

From cvafadari at gmail.com  Mon Nov 11 21:08:07 2019
From: cvafadari at gmail.com (Cyrus Vafadari)
Date: Mon, 11 Nov 2019 13:08:07 -0800
Subject: RandomAccess Interface and List Heirarchy
In-Reply-To: 
References: 
 <1062347590.1395885.1569406540881.JavaMail.zimbra@u-pem.fr>
 <060d71d4-66e5-b593-dd72-e187b1dc8ae9@gmail.com>
 
Message-ID: 

Thanks for the thoughtful responses.

I think my issue with Runtime annotation is that it's just that -- Runtime.
Compiletime is highly preferable.

I also understand the challenges listed by Peter, and the original intended
use of RandomAccess as explained by Remi.

I'd like to propose another solution: A new interface that will be similar
to "RandomAccess", and be properly in the hierarchy, very similar to
RandomAccess but actually inheriting from List. This way, there is no new
syntax, no deprecation issues.
Users could then (at compile time), require that a function is passed an
"IndexableList" (or whatever it ends up being called). Remi points to an
issue where every implementer of list will need to declare its type (e.g.
"RandomImmutableList"), but I'm not sure I'm convinced by this argument:
Guava's ImmutableList, for example, already implements RandomAccess! For
Collections' UnmofidfiableList, of course, just returns a view of the
generic list it's used with, so there's no issue here. Maybe I
misunderstood, but I'm not sure the fanout of interface/class permutations
is not really an issue.

Thoughts?

On Mon, Sep 30, 2019 at 5:41 AM David Lloyd  wrote:

> On Sat, Sep 28, 2019 at 3:39 AM Peter Levart 
> wrote:
> >
> > On 9/25/19 12:15 PM, Remi Forax wrote:
> > > that said, i believe we should deprecate LinkedList (and any other
> List implementation that doesn't implement RandomAccess) because there are
> too much code out there that suppose that list.get() is O(1).
> >
> > Hi Remi,
> >
> > Deprecating LinkedList as a whole is maybe to harsh. LinkedList is a
> > List, but it is also the only JDK implementation of single-threaded
> > linked Deque, which, although a retrofitted feature, is a perfectly
> > fitted feature of LinkedList.
>
> Surely ArrayDeque is almost universally superior to LinkedList for
> this use, in the same way that ArrayList has been shown to be almost
> universally superior to LinkedList for list use cases?
>
> See also
> https://stackoverflow.com/questions/322715/when-to-use-linkedlist-over-arraylist-in-java
>
> The salient point being that in most cases the O(1) of LinkedList is
> effectively slower than the O(n) of Array*.
>
> --
> - DML
>
>

From mandy.chung at oracle.com  Mon Nov 11 21:23:53 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 11 Nov 2019 13:23:53 -0800
Subject: RFR JDK-8233527: Update Lookup::hasPrivateAccess and
 Lookup::defineClass spec w.r.t. full power lookup
Message-ID: <081f506c-62a9-dd98-8b62-04690f4cba14@oracle.com>

This is a follow-up of JDK-8226916. Lookup::hasPrivateAccess intends to 
test if this lookup is a full-power lookup; that is created by the 
original caller class calling MethodHandles::lookup. The current 
specification for Lookup::hasPrivateAccess returns true if the lookup 
modes contain PRIVATE but it does not check MODULE bit.

This patch also clarifies the capabilities w.r.t PRIVATE access and 
full-power access. The security permission check is performed if the 
Lookup is not a full power lookup and therefore Lookup::defineClass spec 
should be updated to perform security permission check if the security 
manager is present and this lookup refuses access, consistent with other 
Lookup operations.

http://cr.openjdk.java.net/~mchung/jdk14/8233527/webrev.02/
http://cr.openjdk.java.net/~mchung/jdk14/8233527/specdiff/

CSR: https://bugs.openjdk.java.net/browse/JDK-8233726

thanks
Mandy

From mandy.chung at oracle.com  Mon Nov 11 21:27:09 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 11 Nov 2019 13:27:09 -0800
Subject: RFR: 8231863: Crash if classpath is read from @argument file and
 the main gets option argument
In-Reply-To: <9FD787FF-8BE8-4B7C-8CBA-E71AC10C938C@oracle.com>
References: 
 <6788F903-A838-4D86-B511-DD7E64E9CE2B@oracle.com>
 <8EC6F4F1-EAF6-4EB3-9F7F-F7A37A759E84@oracle.com>
 
 <10E09EEE-553E-4CBA-81BF-55DFA7C137BB@oracle.com>
 <66980a25-e3fc-dbfb-b95e-7dfe7cd2f697@oracle.com>
 
 <1ba1d75b-ef9f-e953-fd4f-b342fcde4a91@oracle.com>
 <9FD787FF-8BE8-4B7C-8CBA-E71AC10C938C@oracle.com>
Message-ID: <58ab9685-b898-0c29-2b4b-355000e5d2fb@oracle.com>



On 11/11/19 8:53 AM, Henry Jen wrote:
> Thanks Alan and Mandy for the review.
>
> I am guessing the Alan?s preference to use Files.write(aFilePath, lines) is to avoid extra String.join operation, which I would too. The current version with byte[] is more flexible but we most likely won't need it in launcher. Anyway, I don?t think the difference would be noticeable with launcher tests.
>
> The updated webrev[1] takes a boolean to decide which Files.write to use but gives up the byte[] version.
>
> Cheers,
> Henry
>
> [1] http://cr.openjdk.java.net/~henryjen/jdk/8231863.1/webrev/
>
Looks good to me.

Mandy

From chrishennick1 at gmail.com  Mon Nov 11 21:12:18 2019
From: chrishennick1 at gmail.com (Chris Hennick)
Date: Mon, 11 Nov 2019 13:12:18 -0800
Subject: Collections.synchronized* Javadoc could use see-also links
Message-ID: 

When I was fresh out of college, I ended up reinventing the
ConcurrentHashMap wheel because I wasn't aware of it. I knew about
Collections.synchronizedMap(), but knew that locking the entire map for a
get or put (rather than just the hash bucket it hit) would prevent my
program from benefiting from parallelization.

To assist in the education of newer Java developers, why not create
see-also links from the Collections.synchronized* methods' Javadocs to the
corresponding concurrent collections, where those exist? Those would
include at least the following:

   - synchronizedMap -> ConcurrentHashMap
   - synchronizedSet -> ConcurrentHashMap.newKeySet()
   - synchronizedSortedMap & synchronizedNavigableMap ->
   ConcurrentSkipListMap
   - synchronizedNavigableSet & synchronizedSortedSet ->
   ConcurrentSkipListSet

Sincerely,
Chris Hennick

From TobiasDiez at gmx.de  Fri Nov  8 11:38:26 2019
From: TobiasDiez at gmx.de (Tobias Diez)
Date: Fri, 8 Nov 2019 12:38:26 +0100
Subject: Jpackage bug: Failed to find runtime/bin/jli.dll
Message-ID: <00c701d59629$09156400$1b402c00$@gmx.de>

Hello everybody,

I used the latest jpackage to create an installer for windows. The installed
(console) application does not start and complains about "Failed to find
library" with "$ROOTDIR\runtime\bin\jli.dll".
If I change the line "app.runtime=$ROOTDIR\runtime" to
"app.runtime=$APPDIR\runtime" in myapplication.cfg file in the app folder,
then everything works fine.

Another bug is that the default application launcher does not accept command
line arguments (it works if you add "win-console" as an argument to
jpackage).

Best
Tobias


From amy.lu at oracle.com  Tue Nov 12 06:04:43 2019
From: amy.lu at oracle.com (Amy Lu)
Date: Tue, 12 Nov 2019 14:04:43 +0800
Subject: [JDK 14] RFR 8233961: Problem list
 tools/jlink/JLinkReproducibleTest.java for windows-all
Message-ID: 

tools/jlink/JLinkReproducibleTest.java

This test has been seen to fail frequently due to JDK-8217166. Please 
review the patch to problem list it? until issue is addressed.

bug: https://bugs.openjdk.java.net/browse/JDK-8233961

Thanks,
Amy


diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt
+++ b/test/jdk/ProblemList.txt
@@ -837,6 +837,8 @@

 ?tools/pack200/CommandLineTests.java 8059906 generic-all

+tools/jlink/JLinkReproducibleTest.java 8217166 windows-all
+
 ?############################################################################

 ?# jdk_jdi


From joe.darcy at oracle.com  Tue Nov 12 06:13:55 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 11 Nov 2019 22:13:55 -0800
Subject: JDK 14 RFR of JDK-8233940: Preview API tests for String methods
 should use ${jdk.version} as -source arg
Message-ID: <02f2ee31-5998-6161-2eb8-5b923a72a71c@oracle.com>

Hello,

To remove the need to modify tests when the JDK version is updated, the 
tests of the preview API in String should use "${jdk.version}" as an 
argument to -source rather than a fixed version string:

 ??? JDK-8233940: Preview API tests for String methods should use 
${jdk.version} as -source arg
 ??? http://cr.openjdk.java.net/~darcy/8233940.0/

The new TEST.properties file only affects tests in the java/lang/String 
directory. Some additional work is needed before jtreg "smart actions" 
can be enabled throughout the tests in the "jdk" directory as they are 
already in "langtools".

Patch below.

Thanks,

-Joe

--- old/test/jdk/java/lang/String/Formatted.java?? ?2019-11-11 
22:09:42.692005000 -0800
+++ new/test/jdk/java/lang/String/Formatted.java?? ?2019-11-11 
22:09:42.476005000 -0800
@@ -25,7 +25,7 @@
 ? * @test
 ? * bug 8203444
 ? * @summary Unit tests for instance versions of String#format
- * @compile --enable-preview -source 14 Formatted.java
+ * @compile --enable-preview -source ${jdk.version} Formatted.java
 ? * @run main/othervm --enable-preview Formatted
 ? */

--- old/test/jdk/java/lang/String/StripIndent.java?? ?2019-11-11 
22:09:43.376005000 -0800
+++ new/test/jdk/java/lang/String/StripIndent.java?? ?2019-11-11 
22:09:43.120005000 -0800
@@ -25,7 +25,7 @@
 ? * @test
 ? * @bug 8223775
 ? * @summary This exercises String#stripIndent patterns and limits.
- * @compile --enable-preview -source 14 StripIndent.java
+ * @compile --enable-preview -source ${jdk.version} StripIndent.java
 ? * @run main/othervm --enable-preview StripIndent
 ? */

--- old/test/jdk/java/lang/String/TranslateEscapes.java ?2019-11-11 
22:09:44.020005000 -0800
+++ new/test/jdk/java/lang/String/TranslateEscapes.java ?2019-11-11 
22:09:43.776005000 -0800
@@ -25,7 +25,7 @@
 ? * @test
 ? * @bug 8223780
 ? * @summary This exercises String#translateEscapes patterns and limits.
- * @compile --enable-preview -source 14 TranslateEscapes.java
+ * @compile --enable-preview -source ${jdk.version} TranslateEscapes.java
 ? * @run main/othervm --enable-preview TranslateEscapes
 ? */

--- /dev/null?? ?2019-09-13 10:19:35.768000000 -0700
+++ new/test/jdk/java/lang/String/TEST.properties?? ?2019-11-11 
22:09:44.396005000 -0800
@@ -0,0 +1 @@
+allowSmartActionArgs=true


From Alan.Bateman at oracle.com  Tue Nov 12 08:09:31 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 12 Nov 2019 08:09:31 +0000
Subject: [JDK 14] RFR 8233961: Problem list
 tools/jlink/JLinkReproducibleTest.java for windows-all
In-Reply-To: 
References: 
Message-ID: <3e244e59-fa02-f428-b188-3f0b3c74ffc5@oracle.com>

On 12/11/2019 06:04, Amy Lu wrote:
> tools/jlink/JLinkReproducibleTest.java
>
> This test has been seen to fail frequently due to JDK-8217166. Please 
> review the patch to problem list it? until issue is addressed.
I see JDK-8217166 has been bumped to a P2 - good, as this test is 
important to check that run-time images created by jlink are 
reproducible. The change to temporarily exclude it is okay.

-Alan

From jorn.vernee at oracle.com  Tue Nov 12 11:09:06 2019
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Tue, 12 Nov 2019 12:09:06 +0100
Subject: RFR 8233920: MethodHandles::tryFinally generates illegal bytecode for
 long/double return types
Message-ID: 

Hi,

Please review the following patch that fixes handling of long/double 
returns for the tryFinally MethodHandle combinator.

Bug: https://bugs.openjdk.java.net/browse/JDK-8233920
Webrev: http://cr.openjdk.java.net/~jvernee/8233920/webrev.01/
(Testing=tier1)

FWIW, I also added some missing close tags to the javadoc in the 
InvokerBytecodeGenerator class (IntelliJ was warning about this).

As a heads-up; I'm not a committer on the jdk project, so a sponsor 
would be needed to push this.

Thanks,
Jorn


From Alan.Bateman at oracle.com  Tue Nov 12 12:56:11 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 12 Nov 2019 12:56:11 +0000
Subject: RFR JDK-8233527: Update Lookup::hasPrivateAccess and
 Lookup::defineClass spec w.r.t. full power lookup
In-Reply-To: <081f506c-62a9-dd98-8b62-04690f4cba14@oracle.com>
References: <081f506c-62a9-dd98-8b62-04690f4cba14@oracle.com>
Message-ID: <05a22ad4-0f86-0f2b-77ae-e7c70654ecd5@oracle.com>

On 11/11/2019 21:23, Mandy Chung wrote:
> This is a follow-up of JDK-8226916. Lookup::hasPrivateAccess intends 
> to test if this lookup is a full-power lookup; that is created by the 
> original caller class calling MethodHandles::lookup. The current 
> specification for Lookup::hasPrivateAccess returns true if the lookup 
> modes contain PRIVATE but it does not check MODULE bit.
>
> This patch also clarifies the capabilities w.r.t PRIVATE access and 
> full-power access. The security permission check is performed if the 
> Lookup is not a full power lookup and therefore Lookup::defineClass 
> spec should be updated to perform security permission check if the 
> security manager is present and this lookup refuses access, consistent 
> with other Lookup operations.
>
> http://cr.openjdk.java.net/~mchung/jdk14/8233527/webrev.02/
> http://cr.openjdk.java.net/~mchung/jdk14/8233527/specdiff/
>
> CSR: https://bugs.openjdk.java.net/browse/JDK-8233726
In the Lookup class description is has "Only lookups with both full 
privilege access posses the following capabilities". I assume "both" 
stems from an iteration that was going to both both PRIVATE and MODULE 
but I assume the word "both" should be removed now.

-Alan

From claes.redestad at oracle.com  Tue Nov 12 14:30:00 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 12 Nov 2019 15:30:00 +0100
Subject: RFR 8233920: MethodHandles::tryFinally generates illegal bytecode
 for long/double return types
In-Reply-To: 
References: 
Message-ID: 

Hi Jorn,

good catch!

Some minor stylistic concerns:

"* = depends on whether the return type is a category 2 type, which 
takes up 2 stack slots."

While long/double are known to use two stack slots, "category 2 type" 
isn't used much outside the specification. I'd either simplify to
"* = depends on whether the return type takes up 1 or 2 stack slots."
or add a reference to the definition of type categories.

Similarly I think:

boolean returnsCat2Type = returnType == long.class || returnType == 
double.class;

could be simplified as:

boolean isDoubleWord = basicReturnType.isDoubleWord(); // returnsDoubleWord?

In the test, is it possible to narrow the expected exception to the
exact type being thrown (T1?) rather than Throwable?

I can sponsor the patch.

/Claes

On 2019-11-12 12:09, Jorn Vernee wrote:
> Hi,
> 
> Please review the following patch that fixes handling of long/double 
> returns for the tryFinally MethodHandle combinator.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8233920
> Webrev: http://cr.openjdk.java.net/~jvernee/8233920/webrev.01/
> (Testing=tier1)
> 
> FWIW, I also added some missing close tags to the javadoc in the 
> InvokerBytecodeGenerator class (IntelliJ was warning about this).
> 
> As a heads-up; I'm not a committer on the jdk project, so a sponsor 
> would be needed to push this.
> 
> Thanks,
> Jorn
> 

From jorn.vernee at oracle.com  Tue Nov 12 14:56:06 2019
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Tue, 12 Nov 2019 15:56:06 +0100
Subject: RFR 8233920: MethodHandles::tryFinally generates illegal bytecode
 for long/double return types
In-Reply-To: 
References: 
 
Message-ID: <16ec7b47-13c7-c295-01a8-f1c3d00d51a2@oracle.com>

Hi Claes,

Thanks for the comments!

Updated webrev: http://cr.openjdk.java.net/~jvernee/8233920/webrev.02/

Also, thanks for sponsoring.

Jorn

On 12/11/2019 15:30, Claes Redestad wrote:
> Hi Jorn,
>
> good catch!
>
> Some minor stylistic concerns:
>
> "* = depends on whether the return type is a category 2 type, which 
> takes up 2 stack slots."
>
> While long/double are known to use two stack slots, "category 2 type" 
> isn't used much outside the specification. I'd either simplify to
> "* = depends on whether the return type takes up 1 or 2 stack slots."
> or add a reference to the definition of type categories.
>
> Similarly I think:
>
> boolean returnsCat2Type = returnType == long.class || returnType == 
> double.class;
>
> could be simplified as:
>
> boolean isDoubleWord = basicReturnType.isDoubleWord(); // 
> returnsDoubleWord?
>
> In the test, is it possible to narrow the expected exception to the
> exact type being thrown (T1?) rather than Throwable?
>
> I can sponsor the patch.
>
> /Claes
>
> On 2019-11-12 12:09, Jorn Vernee wrote:
>> Hi,
>>
>> Please review the following patch that fixes handling of long/double 
>> returns for the tryFinally MethodHandle combinator.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8233920
>> Webrev: http://cr.openjdk.java.net/~jvernee/8233920/webrev.01/
>> (Testing=tier1)
>>
>> FWIW, I also added some missing close tags to the javadoc in the 
>> InvokerBytecodeGenerator class (IntelliJ was warning about this).
>>
>> As a heads-up; I'm not a committer on the jdk project, so a sponsor 
>> would be needed to push this.
>>
>> Thanks,
>> Jorn
>>

From forax at univ-mlv.fr  Tue Nov 12 15:08:07 2019
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 12 Nov 2019 16:08:07 +0100 (CET)
Subject: RFR 8233920: MethodHandles::tryFinally generates illegal
 bytecode for long/double return types
In-Reply-To: <16ec7b47-13c7-c295-01a8-f1c3d00d51a2@oracle.com>
References: 
 
 <16ec7b47-13c7-c295-01a8-f1c3d00d51a2@oracle.com>
Message-ID: <205939871.532800.1573571287304.JavaMail.zimbra@u-pem.fr>

Hi Jorn, Claes,
Is it not better to always store in a local variable, like javac does, instead of doing the double SWAP if there is a return value of size 1 ?

R?mi 

----- Mail original -----
> De: "Jorn Vernee" 
> ?: "Claes Redestad" , "core-libs-dev" 
> Envoy?: Mardi 12 Novembre 2019 15:56:06
> Objet: Re: RFR 8233920: MethodHandles::tryFinally generates illegal bytecode for long/double return types

> Hi Claes,
> 
> Thanks for the comments!
> 
> Updated webrev: http://cr.openjdk.java.net/~jvernee/8233920/webrev.02/
> 
> Also, thanks for sponsoring.
> 
> Jorn
> 
> On 12/11/2019 15:30, Claes Redestad wrote:
>> Hi Jorn,
>>
>> good catch!
>>
>> Some minor stylistic concerns:
>>
>> "* = depends on whether the return type is a category 2 type, which
>> takes up 2 stack slots."
>>
>> While long/double are known to use two stack slots, "category 2 type"
>> isn't used much outside the specification. I'd either simplify to
>> "* = depends on whether the return type takes up 1 or 2 stack slots."
>> or add a reference to the definition of type categories.
>>
>> Similarly I think:
>>
>> boolean returnsCat2Type = returnType == long.class || returnType ==
>> double.class;
>>
>> could be simplified as:
>>
>> boolean isDoubleWord = basicReturnType.isDoubleWord(); //
>> returnsDoubleWord?
>>
>> In the test, is it possible to narrow the expected exception to the
>> exact type being thrown (T1?) rather than Throwable?
>>
>> I can sponsor the patch.
>>
>> /Claes
>>
>> On 2019-11-12 12:09, Jorn Vernee wrote:
>>> Hi,
>>>
>>> Please review the following patch that fixes handling of long/double
>>> returns for the tryFinally MethodHandle combinator.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8233920
>>> Webrev: http://cr.openjdk.java.net/~jvernee/8233920/webrev.01/
>>> (Testing=tier1)
>>>
>>> FWIW, I also added some missing close tags to the javadoc in the
>>> InvokerBytecodeGenerator class (IntelliJ was warning about this).
>>>
>>> As a heads-up; I'm not a committer on the jdk project, so a sponsor
>>> would be needed to push this.
>>>
>>> Thanks,
>>> Jorn

From james.laskey at oracle.com  Tue Nov 12 15:15:50 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 12 Nov 2019 11:15:50 -0400
Subject: RFR: JDK-8233117 Escape Sequences For Line Continuation and White
 Space (Preview)
In-Reply-To: 
References: <0EEF3461-D8A4-496B-87DE-F143CB0FB995@oracle.com>
 <414cb097-9616-f4b0-8a3d-462a9ccfbdea@oracle.com>
 
Message-ID: <00C5C729-D9FF-48E0-8F7F-DD8E7615ACEC@oracle.com>

updated

webrev: http://cr.openjdk.java.net/~jlaskey/8233116/webrev.03/index.html 



From claes.redestad at oracle.com  Tue Nov 12 15:35:57 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 12 Nov 2019 16:35:57 +0100
Subject: RFR 8233920: MethodHandles::tryFinally generates illegal bytecode
 for long/double return types
In-Reply-To: <205939871.532800.1573571287304.JavaMail.zimbra@u-pem.fr>
References: 
 
 <16ec7b47-13c7-c295-01a8-f1c3d00d51a2@oracle.com>
 <205939871.532800.1573571287304.JavaMail.zimbra@u-pem.fr>
Message-ID: <47ba05ec-d09f-9ee8-4fd0-aa25a365c0d8@oracle.com>

Interesting, and you might be right. However I think it'd be better to
file a follow-up to examine this (pre-existing) behavior than to expand 
the scope of this bug fix.

/Claes

On 2019-11-12 16:08, Remi Forax wrote:
> Hi Jorn, Claes,
> Is it not better to always store in a local variable, like javac does, instead of doing the double SWAP if there is a return value of size 1 ?
> 
> R?mi
> 
> ----- Mail original -----
>> De: "Jorn Vernee" 
>> ?: "Claes Redestad" , "core-libs-dev" 
>> Envoy?: Mardi 12 Novembre 2019 15:56:06
>> Objet: Re: RFR 8233920: MethodHandles::tryFinally generates illegal bytecode for long/double return types
> 
>> Hi Claes,
>>
>> Thanks for the comments!
>>
>> Updated webrev: http://cr.openjdk.java.net/~jvernee/8233920/webrev.02/
>>
>> Also, thanks for sponsoring.
>>
>> Jorn
>>
>> On 12/11/2019 15:30, Claes Redestad wrote:
>>> Hi Jorn,
>>>
>>> good catch!
>>>
>>> Some minor stylistic concerns:
>>>
>>> "* = depends on whether the return type is a category 2 type, which
>>> takes up 2 stack slots."
>>>
>>> While long/double are known to use two stack slots, "category 2 type"
>>> isn't used much outside the specification. I'd either simplify to
>>> "* = depends on whether the return type takes up 1 or 2 stack slots."
>>> or add a reference to the definition of type categories.
>>>
>>> Similarly I think:
>>>
>>> boolean returnsCat2Type = returnType == long.class || returnType ==
>>> double.class;
>>>
>>> could be simplified as:
>>>
>>> boolean isDoubleWord = basicReturnType.isDoubleWord(); //
>>> returnsDoubleWord?
>>>
>>> In the test, is it possible to narrow the expected exception to the
>>> exact type being thrown (T1?) rather than Throwable?
>>>
>>> I can sponsor the patch.
>>>
>>> /Claes
>>>
>>> On 2019-11-12 12:09, Jorn Vernee wrote:
>>>> Hi,
>>>>
>>>> Please review the following patch that fixes handling of long/double
>>>> returns for the tryFinally MethodHandle combinator.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8233920
>>>> Webrev: http://cr.openjdk.java.net/~jvernee/8233920/webrev.01/
>>>> (Testing=tier1)
>>>>
>>>> FWIW, I also added some missing close tags to the javadoc in the
>>>> InvokerBytecodeGenerator class (IntelliJ was warning about this).
>>>>
>>>> As a heads-up; I'm not a committer on the jdk project, so a sponsor
>>>> would be needed to push this.
>>>>
>>>> Thanks,
>>>> Jorn

From jorn.vernee at oracle.com  Tue Nov 12 16:05:42 2019
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Tue, 12 Nov 2019 17:05:42 +0100
Subject: RFR 8233920: MethodHandles::tryFinally generates illegal bytecode
 for long/double return types
In-Reply-To: <47ba05ec-d09f-9ee8-4fd0-aa25a365c0d8@oracle.com>
References: 
 
 <16ec7b47-13c7-c295-01a8-f1c3d00d51a2@oracle.com>
 <205939871.532800.1573571287304.JavaMail.zimbra@u-pem.fr>
 <47ba05ec-d09f-9ee8-4fd0-aa25a365c0d8@oracle.com>
Message-ID: <987d4f91-1941-7b1e-ea65-ed5acc08696a@oracle.com>

Hi R?mi, Claes,

Thanks for the suggestion, R?mi. I avoided using a store/load for all 
types since I didn't want to alter the existing code shape. But, using 
store/load for all types simplifies the generator code & javadoc, so it 
would be nice to do that I think. However, this might have other effects 
on peak/link-time performance as well.

Given that using store/load aligns the code-shape with what javac does, 
I think chances are good that the JIT will have an easier time 
optimizing that code shape. That said, it really needs more investigation.

Here is an updated webrev that uses store/load for all return types: 
http://cr.openjdk.java.net/~jvernee/8233920/webrev.03/

As long as Claes is okay with it, I think we should go for that one 
since the code/doc is simpler. I can file an RFE for examining the 
performance of different code shapes.

Thanks,
Jorn

On 12/11/2019 16:35, Claes Redestad wrote:
> Interesting, and you might be right. However I think it'd be better to
> file a follow-up to examine this (pre-existing) behavior than to 
> expand the scope of this bug fix.
>
> /Claes
>
> On 2019-11-12 16:08, Remi Forax wrote:
>> Hi Jorn, Claes,
>> Is it not better to always store in a local variable, like javac 
>> does, instead of doing the double SWAP if there is a return value of 
>> size 1 ?
>>
>> R?mi
>>
>> ----- Mail original -----
>>> De: "Jorn Vernee" 
>>> ?: "Claes Redestad" , "core-libs-dev" 
>>> 
>>> Envoy?: Mardi 12 Novembre 2019 15:56:06
>>> Objet: Re: RFR 8233920: MethodHandles::tryFinally generates illegal 
>>> bytecode for long/double return types
>>
>>> Hi Claes,
>>>
>>> Thanks for the comments!
>>>
>>> Updated webrev: http://cr.openjdk.java.net/~jvernee/8233920/webrev.02/
>>>
>>> Also, thanks for sponsoring.
>>>
>>> Jorn
>>>
>>> On 12/11/2019 15:30, Claes Redestad wrote:
>>>> Hi Jorn,
>>>>
>>>> good catch!
>>>>
>>>> Some minor stylistic concerns:
>>>>
>>>> "* = depends on whether the return type is a category 2 type, which
>>>> takes up 2 stack slots."
>>>>
>>>> While long/double are known to use two stack slots, "category 2 type"
>>>> isn't used much outside the specification. I'd either simplify to
>>>> "* = depends on whether the return type takes up 1 or 2 stack slots."
>>>> or add a reference to the definition of type categories.
>>>>
>>>> Similarly I think:
>>>>
>>>> boolean returnsCat2Type = returnType == long.class || returnType ==
>>>> double.class;
>>>>
>>>> could be simplified as:
>>>>
>>>> boolean isDoubleWord = basicReturnType.isDoubleWord(); //
>>>> returnsDoubleWord?
>>>>
>>>> In the test, is it possible to narrow the expected exception to the
>>>> exact type being thrown (T1?) rather than Throwable?
>>>>
>>>> I can sponsor the patch.
>>>>
>>>> /Claes
>>>>
>>>> On 2019-11-12 12:09, Jorn Vernee wrote:
>>>>> Hi,
>>>>>
>>>>> Please review the following patch that fixes handling of long/double
>>>>> returns for the tryFinally MethodHandle combinator.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8233920
>>>>> Webrev: http://cr.openjdk.java.net/~jvernee/8233920/webrev.01/
>>>>> (Testing=tier1)
>>>>>
>>>>> FWIW, I also added some missing close tags to the javadoc in the
>>>>> InvokerBytecodeGenerator class (IntelliJ was warning about this).
>>>>>
>>>>> As a heads-up; I'm not a committer on the jdk project, so a sponsor
>>>>> would be needed to push this.
>>>>>
>>>>> Thanks,
>>>>> Jorn

From claes.redestad at oracle.com  Tue Nov 12 16:14:24 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 12 Nov 2019 17:14:24 +0100
Subject: RFR 8233920: MethodHandles::tryFinally generates illegal bytecode
 for long/double return types
In-Reply-To: <987d4f91-1941-7b1e-ea65-ed5acc08696a@oracle.com>
References: 
 
 <16ec7b47-13c7-c295-01a8-f1c3d00d51a2@oracle.com>
 <205939871.532800.1573571287304.JavaMail.zimbra@u-pem.fr>
 <47ba05ec-d09f-9ee8-4fd0-aa25a365c0d8@oracle.com>
 <987d4f91-1941-7b1e-ea65-ed5acc08696a@oracle.com>
Message-ID: <8b80f680-b17e-d4a5-d796-15562cda1f30@oracle.com>

Hi, since you've already done the work I guess I'm ok with it. :-)

While I don't expect there to be a noticeable performance difference, it
seems prudent to investigate and add a simple microbenchmark. This can
be done as a future RFE.

/Claes

On 2019-11-12 17:05, Jorn Vernee wrote:
> Hi R?mi, Claes,
> 
> Thanks for the suggestion, R?mi. I avoided using a store/load for all 
> types since I didn't want to alter the existing code shape. But, using 
> store/load for all types simplifies the generator code & javadoc, so it 
> would be nice to do that I think. However, this might have other effects 
> on peak/link-time performance as well.
> 
> Given that using store/load aligns the code-shape with what javac does, 
> I think chances are good that the JIT will have an easier time 
> optimizing that code shape. That said, it really needs more investigation.
> 
> Here is an updated webrev that uses store/load for all return types: 
> http://cr.openjdk.java.net/~jvernee/8233920/webrev.03/
> 
> As long as Claes is okay with it, I think we should go for that one 
> since the code/doc is simpler. I can file an RFE for examining the 
> performance of different code shapes.
> 
> Thanks,
> Jorn
> 
> On 12/11/2019 16:35, Claes Redestad wrote:
>> Interesting, and you might be right. However I think it'd be better to
>> file a follow-up to examine this (pre-existing) behavior than to 
>> expand the scope of this bug fix.
>>
>> /Claes
>>
>> On 2019-11-12 16:08, Remi Forax wrote:
>>> Hi Jorn, Claes,
>>> Is it not better to always store in a local variable, like javac 
>>> does, instead of doing the double SWAP if there is a return value of 
>>> size 1 ?
>>>
>>> R?mi
>>>
>>> ----- Mail original -----
>>>> De: "Jorn Vernee" 
>>>> ?: "Claes Redestad" , "core-libs-dev" 
>>>> 
>>>> Envoy?: Mardi 12 Novembre 2019 15:56:06
>>>> Objet: Re: RFR 8233920: MethodHandles::tryFinally generates illegal 
>>>> bytecode for long/double return types
>>>
>>>> Hi Claes,
>>>>
>>>> Thanks for the comments!
>>>>
>>>> Updated webrev: http://cr.openjdk.java.net/~jvernee/8233920/webrev.02/
>>>>
>>>> Also, thanks for sponsoring.
>>>>
>>>> Jorn
>>>>
>>>> On 12/11/2019 15:30, Claes Redestad wrote:
>>>>> Hi Jorn,
>>>>>
>>>>> good catch!
>>>>>
>>>>> Some minor stylistic concerns:
>>>>>
>>>>> "* = depends on whether the return type is a category 2 type, which
>>>>> takes up 2 stack slots."
>>>>>
>>>>> While long/double are known to use two stack slots, "category 2 type"
>>>>> isn't used much outside the specification. I'd either simplify to
>>>>> "* = depends on whether the return type takes up 1 or 2 stack slots."
>>>>> or add a reference to the definition of type categories.
>>>>>
>>>>> Similarly I think:
>>>>>
>>>>> boolean returnsCat2Type = returnType == long.class || returnType ==
>>>>> double.class;
>>>>>
>>>>> could be simplified as:
>>>>>
>>>>> boolean isDoubleWord = basicReturnType.isDoubleWord(); //
>>>>> returnsDoubleWord?
>>>>>
>>>>> In the test, is it possible to narrow the expected exception to the
>>>>> exact type being thrown (T1?) rather than Throwable?
>>>>>
>>>>> I can sponsor the patch.
>>>>>
>>>>> /Claes
>>>>>
>>>>> On 2019-11-12 12:09, Jorn Vernee wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review the following patch that fixes handling of long/double
>>>>>> returns for the tryFinally MethodHandle combinator.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8233920
>>>>>> Webrev: http://cr.openjdk.java.net/~jvernee/8233920/webrev.01/
>>>>>> (Testing=tier1)
>>>>>>
>>>>>> FWIW, I also added some missing close tags to the javadoc in the
>>>>>> InvokerBytecodeGenerator class (IntelliJ was warning about this).
>>>>>>
>>>>>> As a heads-up; I'm not a committer on the jdk project, so a sponsor
>>>>>> would be needed to push this.
>>>>>>
>>>>>> Thanks,
>>>>>> Jorn

From andy.herrick at oracle.com  Tue Nov 12 16:41:41 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Tue, 12 Nov 2019 11:41:41 -0500
Subject: Jpackage bug: Failed to find runtime/bin/jli.dll
In-Reply-To: <00c701d59629$09156400$1b402c00$@gmx.de>
References: <00c701d59629$09156400$1b402c00$@gmx.de>
Message-ID: <1a68b981-acf3-154d-7a70-2879df9a7fe7@oracle.com>

Tobias:

I have tried to reproduce what you have done and can't reproduce any of 
the problems you describe.

Can you supply which jpackage build you are using and exactly what steps 
you use to get these problems.

/Andy

On 11/8/2019 6:38 AM, Tobias Diez wrote:
> Hello everybody,
>
> I used the latest jpackage to create an installer for windows. The installed
> (console) application does not start and complains about "Failed to find
> library" with "$ROOTDIR\runtime\bin\jli.dll".
> If I change the line "app.runtime=$ROOTDIR\runtime" to
> "app.runtime=$APPDIR\runtime" in myapplication.cfg file in the app folder,
> then everything works fine.
>
> Another bug is that the default application launcher does not accept command
> line arguments (it works if you add "win-console" as an argument to
> jpackage).
>
> Best
> Tobias
>

From naoto.sato at oracle.com  Tue Nov 12 17:10:14 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 12 Nov 2019 09:10:14 -0800
Subject: [14] RFR: 8232860: Error formatting integer values with
 MessageFormat.format() using HOST provider
Message-ID: <75c71988-40c6-3948-a260-23b55c26a58e@oracle.com>

Hi,

Please review the fix to the following issue:

https://bugs.openjdk.java.net/browse/JDK-8232860

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8232860/webrev.00/

Although this was reported for German locale, it is reproducible on any 
locale. The root cause of this issue was that the Host adapter for 
Windows returned the number pattern for number/integer instances, which 
always require fraction digits, i.e., '0'. Changing it to optional '#' 
will solve the issue.

Also, I modified the integer formatters to allow only integer processing 
(used to allow fractions as well).

Naoto

From mandy.chung at oracle.com  Tue Nov 12 17:12:34 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 12 Nov 2019 09:12:34 -0800
Subject: RFR JDK-8233527: Update Lookup::hasPrivateAccess and
 Lookup::defineClass spec w.r.t. full power lookup
In-Reply-To: <05a22ad4-0f86-0f2b-77ae-e7c70654ecd5@oracle.com>
References: <081f506c-62a9-dd98-8b62-04690f4cba14@oracle.com>
 <05a22ad4-0f86-0f2b-77ae-e7c70654ecd5@oracle.com>
Message-ID: <314a4fa2-19cd-5426-98d8-c6393da5db57@oracle.com>



On 11/12/19 4:56 AM, Alan Bateman wrote:
> On 11/11/2019 21:23, Mandy Chung wrote:
>> This is a follow-up of JDK-8226916. Lookup::hasPrivateAccess intends 
>> to test if this lookup is a full-power lookup; that is created by the 
>> original caller class calling MethodHandles::lookup. The current 
>> specification for Lookup::hasPrivateAccess returns true if the lookup 
>> modes contain PRIVATE but it does not check MODULE bit.
>>
>> This patch also clarifies the capabilities w.r.t PRIVATE access and 
>> full-power access. The security permission check is performed if the 
>> Lookup is not a full power lookup and therefore Lookup::defineClass 
>> spec should be updated to perform security permission check if the 
>> security manager is present and this lookup refuses access, 
>> consistent with other Lookup operations.
>>
>> http://cr.openjdk.java.net/~mchung/jdk14/8233527/webrev.02/
>> http://cr.openjdk.java.net/~mchung/jdk14/8233527/specdiff/
>>
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8233726
> In the Lookup class description is has "Only lookups with both full 
> privilege access posses the following capabilities". I assume "both" 
> stems from an iteration that was going to both both PRIVATE and MODULE 
> but I assume the word "both" should be removed now.

Yes the word "both" should be removed.? Thanks for catching it.

Mandy


From james.laskey at oracle.com  Tue Nov 12 17:45:10 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 12 Nov 2019 13:45:10 -0400
Subject: JDK 14 RFR of JDK-8233940: Preview API tests for String methods
 should use ${jdk.version} as -source arg
In-Reply-To: <02f2ee31-5998-6161-2eb8-5b923a72a71c@oracle.com>
References: <02f2ee31-5998-6161-2eb8-5b923a72a71c@oracle.com>
Message-ID: <61020433-DA9D-4124-9AFE-19EBFCD54677@oracle.com>

+1

> On Nov 12, 2019, at 2:13 AM, Joe Darcy  wrote:
> 
> Hello,
> 
> To remove the need to modify tests when the JDK version is updated, the tests of the preview API in String should use "${jdk.version}" as an argument to -source rather than a fixed version string:
> 
>     JDK-8233940: Preview API tests for String methods should use ${jdk.version} as -source arg
>     http://cr.openjdk.java.net/~darcy/8233940.0/
> 
> The new TEST.properties file only affects tests in the java/lang/String directory. Some additional work is needed before jtreg "smart actions" can be enabled throughout the tests in the "jdk" directory as they are already in "langtools".
> 
> Patch below.
> 
> Thanks,
> 
> -Joe
> 
> --- old/test/jdk/java/lang/String/Formatted.java    2019-11-11 22:09:42.692005000 -0800
> +++ new/test/jdk/java/lang/String/Formatted.java    2019-11-11 22:09:42.476005000 -0800
> @@ -25,7 +25,7 @@
>   * @test
>   * bug 8203444
>   * @summary Unit tests for instance versions of String#format
> - * @compile --enable-preview -source 14 Formatted.java
> + * @compile --enable-preview -source ${jdk.version} Formatted.java
>   * @run main/othervm --enable-preview Formatted
>   */
> 
> --- old/test/jdk/java/lang/String/StripIndent.java    2019-11-11 22:09:43.376005000 -0800
> +++ new/test/jdk/java/lang/String/StripIndent.java    2019-11-11 22:09:43.120005000 -0800
> @@ -25,7 +25,7 @@
>   * @test
>   * @bug 8223775
>   * @summary This exercises String#stripIndent patterns and limits.
> - * @compile --enable-preview -source 14 StripIndent.java
> + * @compile --enable-preview -source ${jdk.version} StripIndent.java
>   * @run main/othervm --enable-preview StripIndent
>   */
> 
> --- old/test/jdk/java/lang/String/TranslateEscapes.java  2019-11-11 22:09:44.020005000 -0800
> +++ new/test/jdk/java/lang/String/TranslateEscapes.java  2019-11-11 22:09:43.776005000 -0800
> @@ -25,7 +25,7 @@
>   * @test
>   * @bug 8223780
>   * @summary This exercises String#translateEscapes patterns and limits.
> - * @compile --enable-preview -source 14 TranslateEscapes.java
> + * @compile --enable-preview -source ${jdk.version} TranslateEscapes.java
>   * @run main/othervm --enable-preview TranslateEscapes
>   */
> 
> --- /dev/null    2019-09-13 10:19:35.768000000 -0700
> +++ new/test/jdk/java/lang/String/TEST.properties    2019-11-11 22:09:44.396005000 -0800
> @@ -0,0 +1 @@
> +allowSmartActionArgs=true
> 


From jan.lahoda at oracle.com  Tue Nov 12 17:50:26 2019
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 12 Nov 2019 17:50:26 +0000
Subject: JDK 14 RFR of JDK-8233940: Preview API tests for String methods
 should use ${jdk.version} as -source arg
In-Reply-To: <02f2ee31-5998-6161-2eb8-5b923a72a71c@oracle.com>
References: <02f2ee31-5998-6161-2eb8-5b923a72a71c@oracle.com>
Message-ID: 

Looks good to me.

Jan

On 12. 11. 19 7:13, Joe Darcy wrote:
> Hello,
> 
> To remove the need to modify tests when the JDK version is updated, the 
> tests of the preview API in String should use "${jdk.version}" as an 
> argument to -source rather than a fixed version string:
> 
>  ??? JDK-8233940: Preview API tests for String methods should use 
> ${jdk.version} as -source arg
>  ??? http://cr.openjdk.java.net/~darcy/8233940.0/
> 
> The new TEST.properties file only affects tests in the java/lang/String 
> directory. Some additional work is needed before jtreg "smart actions" 
> can be enabled throughout the tests in the "jdk" directory as they are 
> already in "langtools".
> 
> Patch below.
> 
> Thanks,
> 
> -Joe
> 
> --- old/test/jdk/java/lang/String/Formatted.java?? ?2019-11-11 
> 22:09:42.692005000 -0800
> +++ new/test/jdk/java/lang/String/Formatted.java?? ?2019-11-11 
> 22:09:42.476005000 -0800
> @@ -25,7 +25,7 @@
>  ? * @test
>  ? * bug 8203444
>  ? * @summary Unit tests for instance versions of String#format
> - * @compile --enable-preview -source 14 Formatted.java
> + * @compile --enable-preview -source ${jdk.version} Formatted.java
>  ? * @run main/othervm --enable-preview Formatted
>  ? */
> 
> --- old/test/jdk/java/lang/String/StripIndent.java?? ?2019-11-11 
> 22:09:43.376005000 -0800
> +++ new/test/jdk/java/lang/String/StripIndent.java?? ?2019-11-11 
> 22:09:43.120005000 -0800
> @@ -25,7 +25,7 @@
>  ? * @test
>  ? * @bug 8223775
>  ? * @summary This exercises String#stripIndent patterns and limits.
> - * @compile --enable-preview -source 14 StripIndent.java
> + * @compile --enable-preview -source ${jdk.version} StripIndent.java
>  ? * @run main/othervm --enable-preview StripIndent
>  ? */
> 
> --- old/test/jdk/java/lang/String/TranslateEscapes.java ?2019-11-11 
> 22:09:44.020005000 -0800
> +++ new/test/jdk/java/lang/String/TranslateEscapes.java ?2019-11-11 
> 22:09:43.776005000 -0800
> @@ -25,7 +25,7 @@
>  ? * @test
>  ? * @bug 8223780
>  ? * @summary This exercises String#translateEscapes patterns and limits.
> - * @compile --enable-preview -source 14 TranslateEscapes.java
> + * @compile --enable-preview -source ${jdk.version} TranslateEscapes.java
>  ? * @run main/othervm --enable-preview TranslateEscapes
>  ? */
> 
> --- /dev/null?? ?2019-09-13 10:19:35.768000000 -0700
> +++ new/test/jdk/java/lang/String/TEST.properties?? ?2019-11-11 
> 22:09:44.396005000 -0800
> @@ -0,0 +1 @@
> +allowSmartActionArgs=true
> 

From lance.andersen at oracle.com  Tue Nov 12 17:58:00 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 12 Nov 2019 12:58:00 -0500
Subject: Jar manifest and EOF character (code 26)
In-Reply-To: <1665721717567c2835e51fa1e3fc6e29b0ee4026.camel@paratix.ch>
References: <9930f76c594c2feee98d6be5db73265536f9861a.camel@paratix.ch>
 <7BF64E28-35AA-40A5-9093-0BF086BB51C1@oracle.com>
 <1665721717567c2835e51fa1e3fc6e29b0ee4026.camel@paratix.ch>
Message-ID: <587E0BAD-03BE-4910-8FE9-DBA84AC9F50F@oracle.com>

I have created a CSR, https://bugs.openjdk.java.net/browse/JDK-8233722 ,  to address the EOF issue.  The CSR has been approved.

Unless I hear any last minute reservations, I will move forward with the update to the JAR spec.

Best
Lance
> On Nov 4, 2019, at 1:38 AM, Philipp Kunz  wrote:
> 
> Hi Max,
> Even if it was easy to implement, I don't think we actually would want
> it. Hopefully not put too much to the point, it sound like last century
> operating with punch cards. The discussed portion of the specification
> refers to "EOF character (code 26)" and also I am not talking about an
> end of a file or input stream. Nowadays I don't see fit. However easy
> or difficult to implement, in either case, I'd opt for removing that
> sentence about EOF characters in manifests.
> I doubt that changing the reading of manifests, particularly at their
> ends, is a promising prospect at the moment. I tried to make this point
> already with references [3] through [14] in the previous mail below and
> I added one new reference [1] of that sort. It would be easy to
> implement only if it was not for compatibility, I figure. If a
> consensus or an agreement can be found for removing the discussed
> sentence from the specification we are kind of lucky that the code does
> not have to be changed. No way I'd want to jump to conclusions here but
> changing the specification around the EOF character only and not the
> code is possible without waiting for the other issues related to
> parsing an insufficiently terminated last line of a manifest which have
> been stuck for a while now.
> Regards,Philipp
> 
> [1] 
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058774.html
> 
> On Mon, 2019-10-14 at 09:41 +0800, Weijun Wang wrote:
>> Hi Philipp,
>> Although I also think this feature might be useless, I feel hesitated
>> to just remove it. How about implement it and let it stay useless? I
>> assume this will not break any existing test or app if no one is
>> actually using the character. Hopefully it's easy to implement.
>> On the other hand, if there is really a EOF char at the end, there
>> will be a behavior change. If that EOF is at the end an attribute
>> line, that line is ignored now, and it should be visible after the
>> change and this looks like a good thing. If that EOF is after a
>> newline, it will be useless anyway.
>> Also, my understanding is that hash/signature in a signed jar file
>> are calculated on raw bytes and old signed jars can still be
>> verified. We should take care to use the original raw bytes and not
>> the result of Manifest::write, but I think your previous fixes in
>> this area had already handled this correctly.
>> Just my $0.02.
>> Thanks,Max
>>> On Oct 11, 2019, at 2:11 PM, Philipp Kunz 
>>> wrote:
>>> Hi,
>>> The Jar File Specification [1] states that,
>>>> If the last character of the file is an EOF character (code 26),
>>>> the
>>> EOF is treated as whitespace. Two newlines are appended (one
>>> foreditors that don't put a newline at the end of the last line,
>>> and oneso that the grammar doesn't have to special-case the last
>>> entry, whichmay not have a blank line after it).
>>> But I can't see that this is actually the case. See the attached
>>> simpletest that indicates that this statement is not implemented.
>>> See also potentially remotely related bugs [2] and [3] which both
>>> referin my opinion to EOF as the end of the byte stream as opposed
>>> to theEOF character 26.
>>> After nobody has fixed this point inside of many years I tend to
>>> assumethat it is not at all necessary or useful. However, I cannot
>>> understandthe intention behind it or how that statement got there
>>> in the firstplace and hence might not be aware of the full context.
>>> Considering the activity about the last line of a manifest
>>> notterminated by a line break resulting in that line ignored
>>> unexpectedly (see [3] through [14]) I doubt that it is promising to
>>> attempt toimplement the EOF according to the specs.
>>> Instead I'd rather like to propose to update the specification
>>> byremoving the quoted statement.
>>> I'm not sure if the specification [1] has changed since 13 or where
>>> themost up to date one is.
>>> Regards,Philipp
>>> 
>>> 
>>> [1] 
>>> https://docs.oracle.com/en/java/javase/13/docs/specs/jar/jar.html#notes-on-manifest-and-signature-files
>>> 
>>> EOF-related:[2] https://bugs.openjdk.java.net/browse/JDK-7148584
>>> [3] https://bugs.openjdk.java.net/browse/JDK-4639129
>>> 
>>> Last line break required or missing related:[4] 
>>> https://bugs.openjdk.java.net/browse/JDK-4274235
>>> [5] https://bugs.openjdk.java.net/browse/JDK-4894998
>>> [6] https://bugs.openjdk.java.net/browse/JDK-4333854
>>> [7] https://bugs.openjdk.java.net/browse/JDK-6594305
>>> [8] 
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058774.html
>>> [9] https://bugs.openjdk.java.net/browse/JDK-4489716
>>> [10] https://bugs.openjdk.java.net/browse/JDK-4639129
>>> [11] https://bugs.openjdk.java.net/browse/JDK-4625822
>>> [12] 
>>> https://stackoverflow.com/questions/21859417/header-must-be-terminated-by-a-line-break-eclipse-manifest-mf
>>> [13] https://bugs.eclipse.org/bugs/show_bug.cgi?id=377249
>>> [14] https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4274235
>>> 
>>> <20191011-manifest-eof.patch>

 
  
 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  Tue Nov 12 21:16:34 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 12 Nov 2019 16:16:34 -0500
Subject: [14] RFR: 8232860: Error formatting integer values with
 MessageFormat.format() using HOST provider
In-Reply-To: <75c71988-40c6-3948-a260-23b55c26a58e@oracle.com>
References: <75c71988-40c6-3948-a260-23b55c26a58e@oracle.com>
Message-ID: <0af8fcb5-dc31-241d-ea89-2f9ad3f8fffa@oracle.com>

Hi Naoto,

Looks fine.

(You might make the comment clear that makeIntegerFormatter
modifies its argument and returns it. )

Thanks, Roger


On 11/12/19 12:10 PM, naoto.sato at oracle.com wrote:
> Hi,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8232860
>
> The proposed changeset is located at:
>
> https://cr.openjdk.java.net/~naoto/8232860/webrev.00/
>
> Although this was reported for German locale, it is reproducible on 
> any locale. The root cause of this issue was that the Host adapter for 
> Windows returned the number pattern for number/integer instances, 
> which always require fraction digits, i.e., '0'. Changing it to 
> optional '#' will solve the issue.
>
> Also, I modified the integer formatters to allow only integer 
> processing (used to allow fractions as well).
>
> Naoto


From naoto.sato at oracle.com  Tue Nov 12 21:47:12 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 12 Nov 2019 13:47:12 -0800
Subject: [14] RFR: 8232860: Error formatting integer values with
 MessageFormat.format() using HOST provider
In-Reply-To: <0af8fcb5-dc31-241d-ea89-2f9ad3f8fffa@oracle.com>
References: <75c71988-40c6-3948-a260-23b55c26a58e@oracle.com>
 <0af8fcb5-dc31-241d-ea89-2f9ad3f8fffa@oracle.com>
Message-ID: <065c80cd-f15c-dafa-dde6-53db6e8afa31@oracle.com>

Hi Roger,

Thank you for your review. The method description was modified per your 
suggestion:

https://cr.openjdk.java.net/~naoto/8232860/webrev.01/

Naoto

On 11/12/19 1:16 PM, Roger Riggs wrote:
> Hi Naoto,
> 
> Looks fine.
> 
> (You might make the comment clear that makeIntegerFormatter
> modifies its argument and returns it. )
> 
> Thanks, Roger
> 
> 
> On 11/12/19 12:10 PM, naoto.sato at oracle.com wrote:
>> Hi,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8232860
>>
>> The proposed changeset is located at:
>>
>> https://cr.openjdk.java.net/~naoto/8232860/webrev.00/
>>
>> Although this was reported for German locale, it is reproducible on 
>> any locale. The root cause of this issue was that the Host adapter for 
>> Windows returned the number pattern for number/integer instances, 
>> which always require fraction digits, i.e., '0'. Changing it to 
>> optional '#' will solve the issue.
>>
>> Also, I modified the integer formatters to allow only integer 
>> processing (used to allow fractions as well).
>>
>> Naoto
> 

From Roger.Riggs at oracle.com  Tue Nov 12 21:55:08 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 12 Nov 2019 16:55:08 -0500
Subject: [14] RFR: 8232860: Error formatting integer values with
 MessageFormat.format() using HOST provider
In-Reply-To: <065c80cd-f15c-dafa-dde6-53db6e8afa31@oracle.com>
References: <75c71988-40c6-3948-a260-23b55c26a58e@oracle.com>
 <0af8fcb5-dc31-241d-ea89-2f9ad3f8fffa@oracle.com>
 <065c80cd-f15c-dafa-dde6-53db6e8afa31@oracle.com>
Message-ID: <3d8bf33e-a0b4-3561-7d77-096ec4e255d4@oracle.com>

+1,

Thanks

On 11/12/19 4:47 PM, naoto.sato at oracle.com wrote:
> Hi Roger,
>
> Thank you for your review. The method description was modified per 
> your suggestion:
>
> https://cr.openjdk.java.net/~naoto/8232860/webrev.01/
>
> Naoto
>
> On 11/12/19 1:16 PM, Roger Riggs wrote:
>> Hi Naoto,
>>
>> Looks fine.
>>
>> (You might make the comment clear that makeIntegerFormatter
>> modifies its argument and returns it. )
>>
>> Thanks, Roger
>>
>>
>> On 11/12/19 12:10 PM, naoto.sato at oracle.com wrote:
>>> Hi,
>>>
>>> Please review the fix to the following issue:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8232860
>>>
>>> The proposed changeset is located at:
>>>
>>> https://cr.openjdk.java.net/~naoto/8232860/webrev.00/
>>>
>>> Although this was reported for German locale, it is reproducible on 
>>> any locale. The root cause of this issue was that the Host adapter 
>>> for Windows returned the number pattern for number/integer 
>>> instances, which always require fraction digits, i.e., '0'. Changing 
>>> it to optional '#' will solve the issue.
>>>
>>> Also, I modified the integer formatters to allow only integer 
>>> processing (used to allow fractions as well).
>>>
>>> Naoto
>>


From mandy.chung at oracle.com  Tue Nov 12 23:22:32 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 12 Nov 2019 15:22:32 -0800
Subject: RFR JDK-8233527: Update Lookup::hasPrivateAccess and
 Lookup::defineClass spec w.r.t. full power lookup
In-Reply-To: <081f506c-62a9-dd98-8b62-04690f4cba14@oracle.com>
References: <081f506c-62a9-dd98-8b62-04690f4cba14@oracle.com>
Message-ID: <8f08172d-9288-2f4a-eb31-3d18f122764e@oracle.com>

John suggests to deprecate Lookup::hasPrivateAccess and introduce
a correctly named method `hasFullPrivilegeAccess`.??? Also clarify
`Lookup::findClass` javadoc that it's equivalent to `ldc` instruction.

Here is the updated webrev and specdiff:

http://cr.openjdk.java.net/~mchung/jdk14/8233527/webrev.03/
http://cr.openjdk.java.net/~mchung/jdk14/8233527/specdiff/

CSR has been updated as well.

Thanks
Mandy

On 11/11/19 1:23 PM, Mandy Chung wrote:
> This is a follow-up of JDK-8226916. Lookup::hasPrivateAccess intends 
> to test if this lookup is a full-power lookup; that is created by the 
> original caller class calling MethodHandles::lookup. The current 
> specification for Lookup::hasPrivateAccess returns true if the lookup 
> modes contain PRIVATE but it does not check MODULE bit.
>
> This patch also clarifies the capabilities w.r.t PRIVATE access and 
> full-power access. The security permission check is performed if the 
> Lookup is not a full power lookup and therefore Lookup::defineClass 
> spec should be updated to perform security permission check if the 
> security manager is present and this lookup refuses access, consistent 
> with other Lookup operations.
>
> http://cr.openjdk.java.net/~mchung/jdk14/8233527/webrev.02/
> http://cr.openjdk.java.net/~mchung/jdk14/8233527/specdiff/
>
> CSR: https://bugs.openjdk.java.net/browse/JDK-8233726
>
> thanks
> Mandy


From kiran.sidhartha.ravikumar at oracle.com  Wed Nov 13 10:13:11 2019
From: kiran.sidhartha.ravikumar at oracle.com (Kiran Ravikumar)
Date: Wed, 13 Nov 2019 10:13:11 +0000
Subject: RFR 8233731: repeated typo "fro" for "for"
Message-ID: <51aee57f-c2e4-39be-1c7e-f70083d4dfd7@oracle.com>

Hey Guys,

Please review the correction of a typo from 'fro' to 'for' in 
java.util.Arrays class.


Thanks,

Kiran

*Patch :*

@@ -2599,7 +2599,7 @@
 ????? *?????????????????? first array to be tested
 ????? * @param aToIndex the index (exclusive) of the last element in the
 ????? *???????????????? first array to be tested
-???? * @param b the second array to be tested fro equality
+???? * @param b the second array to be tested for equality
 ????? * @param bFromIndex the index (inclusive) of the first element in the
 ????? *?????????????????? second array to be tested
 ????? * @param bToIndex the index (exclusive) of the last element in the
@@ -2671,7 +2671,7 @@
 ????? *?????????????????? first array to be tested
 ????? * @param aToIndex the index (exclusive) of the last element in the
 ????? *???????????????? first array to be tested
-???? * @param b the second array to be tested fro equality
+???? * @param b the second array to be tested for equality
 ????? * @param bFromIndex the index (inclusive) of the first element in the
 ????? *?????????????????? second array to be tested
 ????? * @param bToIndex the index (exclusive) of the last element in the
@@ -2743,7 +2743,7 @@
 ????? *?????????????????? first array to be tested
 ????? * @param aToIndex the index (exclusive) of the last element in the
 ????? *???????????????? first array to be tested
-???? * @param b the second array to be tested fro equality
+???? * @param b the second array to be tested for equality
 ????? * @param bFromIndex the index (inclusive) of the first element in the
 ????? *?????????????????? second array to be tested
 ????? * @param bToIndex the index (exclusive) of the last element in the
@@ -2816,7 +2816,7 @@
 ????? *?????????????????? first array to be tested
 ????? * @param aToIndex the index (exclusive) of the last element in the
 ????? *???????????????? first array to be tested
-???? * @param b the second array to be tested fro equality
+???? * @param b the second array to be tested for equality
 ????? * @param bFromIndex the index (inclusive) of the first element in the
 ????? *?????????????????? second array to be tested
 ????? * @param bToIndex the index (exclusive) of the last element in the
@@ -2889,7 +2889,7 @@
 ????? *?????????????????? first array to be tested
 ????? * @param aToIndex the index (exclusive) of the last element in the
 ????? *???????????????? first array to be tested
-???? * @param b the second array to be tested fro equality
+???? * @param b the second array to be tested for equality
 ????? * @param bFromIndex the index (inclusive) of the first element in the
 ????? *?????????????????? second array to be tested
 ????? * @param bToIndex the index (exclusive) of the last element in the
@@ -2961,7 +2961,7 @@
 ????? *?????????????????? first array to be tested
 ????? * @param aToIndex the index (exclusive) of the last element in the
 ????? *???????????????? first array to be tested
-???? * @param b the second array to be tested fro equality
+???? * @param b the second array to be tested for equality
 ????? * @param bFromIndex the index (inclusive) of the first element in the
 ????? *?????????????????? second array to be tested
 ????? * @param bToIndex the index (exclusive) of the last element in the
@@ -3044,7 +3044,7 @@
 ????? *?????????????????? first array to be tested
 ????? * @param aToIndex the index (exclusive) of the last element in the
 ????? *???????????????? first array to be tested
-???? * @param b the second array to be tested fro equality
+???? * @param b the second array to be tested for equality
 ????? * @param bFromIndex the index (inclusive) of the first element in the
 ????? *?????????????????? second array to be tested
 ????? * @param bToIndex the index (exclusive) of the last element in the
@@ -3127,7 +3127,7 @@
 ????? *?????????????????? first array to be tested
 ????? * @param aToIndex the index (exclusive) of the last element in the
 ????? *???????????????? first array to be tested
-???? * @param b the second array to be tested fro equality
+???? * @param b the second array to be tested for equality
 ????? * @param bFromIndex the index (inclusive) of the first element in the
 ????? *?????????????????? second array to be tested
 ????? * @param bToIndex the index (exclusive) of the last element in the
@@ -3210,7 +3210,7 @@
 ????? *?????????????????? first array to be tested
 ????? * @param aToIndex the index (exclusive) of the last element in the
 ????? *???????????????? first array to be tested
-???? * @param b the second array to be tested fro equality
+???? * @param b the second array to be tested for equality
 ????? * @param bFromIndex the index (inclusive) of the first element in the
 ????? *?????????????????? second array to be tested
 ????? * @param bToIndex the index (exclusive) of the last element in the
@@ -3303,7 +3303,7 @@
 ????? *?????????????????? first array to be tested
 ????? * @param aToIndex the index (exclusive) of the last element in the
 ????? *???????????????? first array to be tested
-???? * @param b the second array to be tested fro equality
+???? * @param b the second array to be tested for equality
 ????? * @param bFromIndex the index (inclusive) of the first element in the
 ????? *?????????????????? second array to be tested
 ????? * @param bToIndex the index (exclusive) of the last element in the


From vladimir.x.ivanov at oracle.com  Wed Nov 13 10:28:32 2019
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 13 Nov 2019 13:28:32 +0300
Subject: RFR 8233920: MethodHandles::tryFinally generates illegal bytecode
 for long/double return types
In-Reply-To: <987d4f91-1941-7b1e-ea65-ed5acc08696a@oracle.com>
References: 
 
 <16ec7b47-13c7-c295-01a8-f1c3d00d51a2@oracle.com>
 <205939871.532800.1573571287304.JavaMail.zimbra@u-pem.fr>
 <47ba05ec-d09f-9ee8-4fd0-aa25a365c0d8@oracle.com>
 <987d4f91-1941-7b1e-ea65-ed5acc08696a@oracle.com>
Message-ID: <798179d6-6ff3-d187-a8ff-c6acc32bcbe4@oracle.com>


> http://cr.openjdk.java.net/~jvernee/8233920/webrev.03/

I like how the patch shapes. Looks good.

In addition, you can encapsulate the following code into a helper method:

           if (isNonVoid) {
-             mv.visitInsn(Opcodes.POP);
+             if (isDoubleWord) {
+                 mv.visitInsn(Opcodes.POP2);
+             } else {
+                 mv.visitInsn(Opcodes.POP);
+             }
           }


     if (isNonVoid) {
       BasicType basicReturnType = BasicType.basicType(returnType);
       emitPopInsn(basicReturnType);
     }

     private void emitPopInsn(BasicType type) {
       mv.visitVarInsn(popInsnOpcode(type));
     }

     private int popInsnOpcode(BasicType type) {
        switch (type) {
          case I_TYPE: return Opcodes.POP;
          case J_TYPE: return Opcodes.POP2;
          case F_TYPE: return Opcodes.POP;
          case D_TYPE: return Opcodes.POP2;
          case L_TYPE: return Opcodes.POP;
          default:
            throw new InternalError("unknown type: " + type);
     }

Best regards,
Vladimir Ivanov

> As long as Claes is okay with it, I think we should go for that one 
> since the code/doc is simpler. I can file an RFE for examining the 
> performance of different code shapes.
> 
> Thanks,
> Jorn
> 
> On 12/11/2019 16:35, Claes Redestad wrote:
>> Interesting, and you might be right. However I think it'd be better to
>> file a follow-up to examine this (pre-existing) behavior than to 
>> expand the scope of this bug fix.
>>
>> /Claes
>>
>> On 2019-11-12 16:08, Remi Forax wrote:
>>> Hi Jorn, Claes,
>>> Is it not better to always store in a local variable, like javac 
>>> does, instead of doing the double SWAP if there is a return value of 
>>> size 1 ?
>>>
>>> R?mi
>>>
>>> ----- Mail original -----
>>>> De: "Jorn Vernee" 
>>>> ?: "Claes Redestad" , "core-libs-dev" 
>>>> 
>>>> Envoy?: Mardi 12 Novembre 2019 15:56:06
>>>> Objet: Re: RFR 8233920: MethodHandles::tryFinally generates illegal 
>>>> bytecode for long/double return types
>>>
>>>> Hi Claes,
>>>>
>>>> Thanks for the comments!
>>>>
>>>> Updated webrev: http://cr.openjdk.java.net/~jvernee/8233920/webrev.02/
>>>>
>>>> Also, thanks for sponsoring.
>>>>
>>>> Jorn
>>>>
>>>> On 12/11/2019 15:30, Claes Redestad wrote:
>>>>> Hi Jorn,
>>>>>
>>>>> good catch!
>>>>>
>>>>> Some minor stylistic concerns:
>>>>>
>>>>> "* = depends on whether the return type is a category 2 type, which
>>>>> takes up 2 stack slots."
>>>>>
>>>>> While long/double are known to use two stack slots, "category 2 type"
>>>>> isn't used much outside the specification. I'd either simplify to
>>>>> "* = depends on whether the return type takes up 1 or 2 stack slots."
>>>>> or add a reference to the definition of type categories.
>>>>>
>>>>> Similarly I think:
>>>>>
>>>>> boolean returnsCat2Type = returnType == long.class || returnType ==
>>>>> double.class;
>>>>>
>>>>> could be simplified as:
>>>>>
>>>>> boolean isDoubleWord = basicReturnType.isDoubleWord(); //
>>>>> returnsDoubleWord?
>>>>>
>>>>> In the test, is it possible to narrow the expected exception to the
>>>>> exact type being thrown (T1?) rather than Throwable?
>>>>>
>>>>> I can sponsor the patch.
>>>>>
>>>>> /Claes
>>>>>
>>>>> On 2019-11-12 12:09, Jorn Vernee wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review the following patch that fixes handling of long/double
>>>>>> returns for the tryFinally MethodHandle combinator.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8233920
>>>>>> Webrev: http://cr.openjdk.java.net/~jvernee/8233920/webrev.01/
>>>>>> (Testing=tier1)
>>>>>>
>>>>>> FWIW, I also added some missing close tags to the javadoc in the
>>>>>> InvokerBytecodeGenerator class (IntelliJ was warning about this).
>>>>>>
>>>>>> As a heads-up; I'm not a committer on the jdk project, so a sponsor
>>>>>> would be needed to push this.
>>>>>>
>>>>>> Thanks,
>>>>>> Jorn

From daniel.fuchs at oracle.com  Wed Nov 13 10:51:49 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 13 Nov 2019 10:51:49 +0000
Subject: RFR 8233731: repeated typo "fro" for "for"
In-Reply-To: <51aee57f-c2e4-39be-1c7e-f70083d4dfd7@oracle.com>
References: <51aee57f-c2e4-39be-1c7e-f70083d4dfd7@oracle.com>
Message-ID: 

Hi Kiran,

Looks good to me.

best regards,

-- daniel

On 13/11/2019 10:13, Kiran Ravikumar wrote:
> Hey Guys,
> 
> Please review the correction of a typo from 'fro' to 'for' in 
> java.util.Arrays class.
> 
> 
> Thanks,
> 
> Kiran
> 
> *Patch :*
> 
> @@ -2599,7 +2599,7 @@
>  ????? *?????????????????? first array to be tested
>  ????? * @param aToIndex the index (exclusive) of the last element in the
>  ????? *???????????????? first array to be tested
> -???? * @param b the second array to be tested fro equality
> +???? * @param b the second array to be tested for equality
>  ????? * @param bFromIndex the index (inclusive) of the first element in 
> the
>  ????? *?????????????????? second array to be tested
>  ????? * @param bToIndex the index (exclusive) of the last element in the
> @@ -2671,7 +2671,7 @@
>  ????? *?????????????????? first array to be tested
>  ????? * @param aToIndex the index (exclusive) of the last element in the
>  ????? *???????????????? first array to be tested
> -???? * @param b the second array to be tested fro equality
> +???? * @param b the second array to be tested for equality
>  ????? * @param bFromIndex the index (inclusive) of the first element in 
> the
>  ????? *?????????????????? second array to be tested
>  ????? * @param bToIndex the index (exclusive) of the last element in the
> @@ -2743,7 +2743,7 @@
>  ????? *?????????????????? first array to be tested
>  ????? * @param aToIndex the index (exclusive) of the last element in the
>  ????? *???????????????? first array to be tested
> -???? * @param b the second array to be tested fro equality
> +???? * @param b the second array to be tested for equality
>  ????? * @param bFromIndex the index (inclusive) of the first element in 
> the
>  ????? *?????????????????? second array to be tested
>  ????? * @param bToIndex the index (exclusive) of the last element in the
> @@ -2816,7 +2816,7 @@
>  ????? *?????????????????? first array to be tested
>  ????? * @param aToIndex the index (exclusive) of the last element in the
>  ????? *???????????????? first array to be tested
> -???? * @param b the second array to be tested fro equality
> +???? * @param b the second array to be tested for equality
>  ????? * @param bFromIndex the index (inclusive) of the first element in 
> the
>  ????? *?????????????????? second array to be tested
>  ????? * @param bToIndex the index (exclusive) of the last element in the
> @@ -2889,7 +2889,7 @@
>  ????? *?????????????????? first array to be tested
>  ????? * @param aToIndex the index (exclusive) of the last element in the
>  ????? *???????????????? first array to be tested
> -???? * @param b the second array to be tested fro equality
> +???? * @param b the second array to be tested for equality
>  ????? * @param bFromIndex the index (inclusive) of the first element in 
> the
>  ????? *?????????????????? second array to be tested
>  ????? * @param bToIndex the index (exclusive) of the last element in the
> @@ -2961,7 +2961,7 @@
>  ????? *?????????????????? first array to be tested
>  ????? * @param aToIndex the index (exclusive) of the last element in the
>  ????? *???????????????? first array to be tested
> -???? * @param b the second array to be tested fro equality
> +???? * @param b the second array to be tested for equality
>  ????? * @param bFromIndex the index (inclusive) of the first element in 
> the
>  ????? *?????????????????? second array to be tested
>  ????? * @param bToIndex the index (exclusive) of the last element in the
> @@ -3044,7 +3044,7 @@
>  ????? *?????????????????? first array to be tested
>  ????? * @param aToIndex the index (exclusive) of the last element in the
>  ????? *???????????????? first array to be tested
> -???? * @param b the second array to be tested fro equality
> +???? * @param b the second array to be tested for equality
>  ????? * @param bFromIndex the index (inclusive) of the first element in 
> the
>  ????? *?????????????????? second array to be tested
>  ????? * @param bToIndex the index (exclusive) of the last element in the
> @@ -3127,7 +3127,7 @@
>  ????? *?????????????????? first array to be tested
>  ????? * @param aToIndex the index (exclusive) of the last element in the
>  ????? *???????????????? first array to be tested
> -???? * @param b the second array to be tested fro equality
> +???? * @param b the second array to be tested for equality
>  ????? * @param bFromIndex the index (inclusive) of the first element in 
> the
>  ????? *?????????????????? second array to be tested
>  ????? * @param bToIndex the index (exclusive) of the last element in the
> @@ -3210,7 +3210,7 @@
>  ????? *?????????????????? first array to be tested
>  ????? * @param aToIndex the index (exclusive) of the last element in the
>  ????? *???????????????? first array to be tested
> -???? * @param b the second array to be tested fro equality
> +???? * @param b the second array to be tested for equality
>  ????? * @param bFromIndex the index (inclusive) of the first element in 
> the
>  ????? *?????????????????? second array to be tested
>  ????? * @param bToIndex the index (exclusive) of the last element in the
> @@ -3303,7 +3303,7 @@
>  ????? *?????????????????? first array to be tested
>  ????? * @param aToIndex the index (exclusive) of the last element in the
>  ????? *???????????????? first array to be tested
> -???? * @param b the second array to be tested fro equality
> +???? * @param b the second array to be tested for equality
>  ????? * @param bFromIndex the index (inclusive) of the first element in 
> the
>  ????? *?????????????????? second array to be tested
>  ????? * @param bToIndex the index (exclusive) of the last element in the
> 


From amy.lu at oracle.com  Wed Nov 13 11:11:09 2019
From: amy.lu at oracle.com (Amy Lu)
Date: Wed, 13 Nov 2019 19:11:09 +0800
Subject: [JDK 14] RFR 8234079: ZipFileInputStreamSkipTest.java runs zero test
Message-ID: <81981fae-9886-f150-42b6-68fa5d0f8bbb@oracle.com>

java/util/zip/ZipFile/ZipFileInputStreamSkipTest.java

Test runs zero test. Please review the fix.

bug: https://bugs.openjdk.java.net/browse/JDK-8234079
webrev: http://cr.openjdk.java.net/~amlu/8234079/webrev.00

Thanks,
Amy

--- old/test/jdk/java/util/zip/ZipFile/ZipFileInputStreamSkipTest.java	2019-11-13 19:01:44.000000000 +0800
+++ new/test/jdk/java/util/zip/ZipFile/ZipFileInputStreamSkipTest.java	2019-11-13 19:01:44.000000000 +0800
@@ -105,7 +105,7 @@
       * @throws Exception If an error occurs during the test
       */
      @Test
-    private void testStoredSkip() throws Exception {
+    public void testStoredSkip() throws Exception {
  
          try (ZipFile zf = new ZipFile(STORED_ZIPFILE.toFile())) {
              var entries = zf.entries();
@@ -153,7 +153,7 @@
       * @throws Exception If an error occurs during the test
       */
      @Test
-    private void testStoredNegativeSkip() throws Exception {
+    public void testStoredNegativeSkip() throws Exception {
  
          try (ZipFile zf = new ZipFile(STORED_ZIPFILE.toFile())) {
              var entries = zf.entries();
@@ -198,7 +198,7 @@
       * @throws Exception If an error occurs during the test
       */
      @Test
-    private void testDeflatedSkip() throws Exception {
+    public void testDeflatedSkip() throws Exception {
          try (ZipFile zf = new ZipFile(DEFLATED_ZIPFILE.toFile())) {
              var toSkip = 5; // Bytes to Skip
              var entries = zf.entries();
@@ -225,7 +225,7 @@
       * @throws Exception If an unexpected error occurs during the test
       */
      @Test
-    private void testDeflatedIOException() throws Exception {
+    public void testDeflatedIOException() throws Exception {
          try (ZipFile zf = new ZipFile(DEFLATED_ZIPFILE.toFile())) {
              var entries = zf.entries();
              while (entries.hasMoreElements()) {



From lance.andersen at oracle.com  Wed Nov 13 11:58:24 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 13 Nov 2019 06:58:24 -0500
Subject: [JDK 14] RFR 8234079: ZipFileInputStreamSkipTest.java runs zero
 test
In-Reply-To: <81981fae-9886-f150-42b6-68fa5d0f8bbb@oracle.com>
References: <81981fae-9886-f150-42b6-68fa5d0f8bbb@oracle.com>
Message-ID: <314C7B9F-CD8E-4270-8EB3-0CEF1CBDC830@oracle.com>

Looks fine

> On Nov 13, 2019, at 6:11 AM, Amy Lu  wrote:
> 
> java/util/zip/ZipFile/ZipFileInputStreamSkipTest.java
> 
> Test runs zero test. Please review the fix.
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8234079
> webrev: http://cr.openjdk.java.net/~amlu/8234079/webrev.00
> 
> Thanks,
> Amy
> 
> --- old/test/jdk/java/util/zip/ZipFile/ZipFileInputStreamSkipTest.java	2019-11-13 19:01:44.000000000 +0800
> +++ new/test/jdk/java/util/zip/ZipFile/ZipFileInputStreamSkipTest.java	2019-11-13 19:01:44.000000000 +0800
> @@ -105,7 +105,7 @@
>      * @throws Exception If an error occurs during the test
>      */
>     @Test
> -    private void testStoredSkip() throws Exception {
> +    public void testStoredSkip() throws Exception {
>          try (ZipFile zf = new ZipFile(STORED_ZIPFILE.toFile())) {
>             var entries = zf.entries();
> @@ -153,7 +153,7 @@
>      * @throws Exception If an error occurs during the test
>      */
>     @Test
> -    private void testStoredNegativeSkip() throws Exception {
> +    public void testStoredNegativeSkip() throws Exception {
>          try (ZipFile zf = new ZipFile(STORED_ZIPFILE.toFile())) {
>             var entries = zf.entries();
> @@ -198,7 +198,7 @@
>      * @throws Exception If an error occurs during the test
>      */
>     @Test
> -    private void testDeflatedSkip() throws Exception {
> +    public void testDeflatedSkip() throws Exception {
>         try (ZipFile zf = new ZipFile(DEFLATED_ZIPFILE.toFile())) {
>             var toSkip = 5; // Bytes to Skip
>             var entries = zf.entries();
> @@ -225,7 +225,7 @@
>      * @throws Exception If an unexpected error occurs during the test
>      */
>     @Test
> -    private void testDeflatedIOException() throws Exception {
> +    public void testDeflatedIOException() throws Exception {
>         try (ZipFile zf = new ZipFile(DEFLATED_ZIPFILE.toFile())) {
>             var entries = zf.entries();
>             while (entries.hasMoreElements()) {
> 
> 

 
  
 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 info at j-kuhn.de  Wed Nov 13 14:10:19 2019
From: info at j-kuhn.de (Johannes Kuhn)
Date: Wed, 13 Nov 2019 15:10:19 +0100
Subject: RFR JDK-8233527: Update Lookup::hasPrivateAccess and
 Lookup::defineClass spec w.r.t. full power lookup
In-Reply-To: <081f506c-62a9-dd98-8b62-04690f4cba14@oracle.com>
References: <081f506c-62a9-dd98-8b62-04690f4cba14@oracle.com>
Message-ID: <083da65f-e1a5-4f30-9d15-cf69df1918ec@j-kuhn.de>

On 11.11.2019 22:23, Mandy Chung wrote:
> This is a follow-up of JDK-8226916. Lookup::hasPrivateAccess intends 
> to test if this lookup is a full-power lookup; that is created by the 
> original caller class calling MethodHandles::lookup. The current 
> specification for Lookup::hasPrivateAccess returns true if the lookup 
> modes contain PRIVATE but it does not check MODULE bit.
>
> This patch also clarifies the capabilities w.r.t PRIVATE access and 
> full-power access. The security permission check is performed if the 
> Lookup is not a full power lookup and therefore Lookup::defineClass 
> spec should be updated to perform security permission check if the 
> security manager is present and this lookup refuses access, consistent 
> with other Lookup operations.
>
> http://cr.openjdk.java.net/~mchung/jdk14/8233527/webrev.02/
> http://cr.openjdk.java.net/~mchung/jdk14/8233527/specdiff/
>
> CSR: https://bugs.openjdk.java.net/browse/JDK-8233726
>
> thanks
> Mandy

Thank you for all those changes. It fixed two of my reported bugs 
(JDK-8209005, JDK-8209078).
It also makes my suggested workaround for JDK-8230636 not longer 
possible. Thanks for picking that up too.

I just have a question about the requirement of 
MethodHandles.privateLookupIn: As it requires that the originating 
lookup has both PRIVATE and MODULE access, it sounds a lot like full 
privilege access. Should this be reworded?

Also, with the current specification, I don't see a way to abuse 
jdk.unsupported's privileged access into java.base (which IMHO caused 
the entire rework).

thanks,
Johannes


From andy.herrick at oracle.com  Wed Nov 13 14:44:45 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Wed, 13 Nov 2019 09:44:45 -0500
Subject: Jpackage EA build available
Message-ID: <005ebbcf-8996-e046-4109-704a1381d4b2@oracle.com>

The next EA build of JPackage is available at 
https://jdk.java.net/jpackage/

Build 14-jpackage+1-70 (2019/11/12) contains the following changes 
(since Build Build 14-jpackage+1-64 on 2019/10/28):

JDK-8233594???? create a new option --bind-services to pass on to jlink
JDK-8233636???? Make jpackage an incubator and remove tool provider 
implementation
JDK-8233591???? Reorder jpackage help text to focus on package creation
JDK-8233592???? change --package-type option name to --type and allow -t 
short form
JDK-8232919???? If user installs msi and exe, two installations are 
found in Add/Remove
JDK-8232186???? Add verification for pkg and dmg tests
JDK-8233265???? jpackage --add-modules cannot find additional modules 
with non-modular app
JDK-8233333???? Incorrect comparison of number version strings in 
ToolValidator
JDK-8233143???? RPM errors: rpmbuild: no spec files given for build
JDK-8233138???? Error 2343 when using --win-dir-chooser
JDK-8233218???? rpm uninstall errors (xdg-icon-resource: the icon size 
must be specified with --size)
JDK-8233114???? uninstalling app removes shortcut directory

please send feedback to core-libs-dev at openjdk.java.net

/Andy Herrick


From jorn.vernee at oracle.com  Wed Nov 13 15:03:38 2019
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Wed, 13 Nov 2019 16:03:38 +0100
Subject: RFR 8233920: MethodHandles::tryFinally generates illegal bytecode
 for long/double return types
In-Reply-To: <798179d6-6ff3-d187-a8ff-c6acc32bcbe4@oracle.com>
References: 
 
 <16ec7b47-13c7-c295-01a8-f1c3d00d51a2@oracle.com>
 <205939871.532800.1573571287304.JavaMail.zimbra@u-pem.fr>
 <47ba05ec-d09f-9ee8-4fd0-aa25a365c0d8@oracle.com>
 <987d4f91-1941-7b1e-ea65-ed5acc08696a@oracle.com>
 <798179d6-6ff3-d187-a8ff-c6acc32bcbe4@oracle.com>
Message-ID: <2188da92-ecf6-b4a2-0e73-db7be3932b39@oracle.com>

Hi Vladimir,

Thanks for the suggestion, I think it sounds good.

Here is the updated webrev: 
http://cr.openjdk.java.net/~jvernee/8233920/webrev.04/

Thanks,
Jorn

On 13/11/2019 11:28, Vladimir Ivanov wrote:
>
>> http://cr.openjdk.java.net/~jvernee/8233920/webrev.03/
>
> I like how the patch shapes. Looks good.
>
> In addition, you can encapsulate the following code into a helper method:
>
> ????????? if (isNonVoid) {
> -???????????? mv.visitInsn(Opcodes.POP);
> +???????????? if (isDoubleWord) {
> +???????????????? mv.visitInsn(Opcodes.POP2);
> +???????????? } else {
> +???????????????? mv.visitInsn(Opcodes.POP);
> +???????????? }
> ????????? }
>
>
> ??? if (isNonVoid) {
> ????? BasicType basicReturnType = BasicType.basicType(returnType);
> ????? emitPopInsn(basicReturnType);
> ??? }
>
> ??? private void emitPopInsn(BasicType type) {
> ????? mv.visitVarInsn(popInsnOpcode(type));
> ??? }
>
> ??? private int popInsnOpcode(BasicType type) {
> ?????? switch (type) {
> ???????? case I_TYPE: return Opcodes.POP;
> ???????? case J_TYPE: return Opcodes.POP2;
> ???????? case F_TYPE: return Opcodes.POP;
> ???????? case D_TYPE: return Opcodes.POP2;
> ???????? case L_TYPE: return Opcodes.POP;
> ???????? default:
> ?????????? throw new InternalError("unknown type: " + type);
> ??? }
>
> Best regards,
> Vladimir Ivanov
>
>> As long as Claes is okay with it, I think we should go for that one 
>> since the code/doc is simpler. I can file an RFE for examining the 
>> performance of different code shapes.
>>
>> Thanks,
>> Jorn
>>
>> On 12/11/2019 16:35, Claes Redestad wrote:
>>> Interesting, and you might be right. However I think it'd be better to
>>> file a follow-up to examine this (pre-existing) behavior than to 
>>> expand the scope of this bug fix.
>>>
>>> /Claes
>>>
>>> On 2019-11-12 16:08, Remi Forax wrote:
>>>> Hi Jorn, Claes,
>>>> Is it not better to always store in a local variable, like javac 
>>>> does, instead of doing the double SWAP if there is a return value 
>>>> of size 1 ?
>>>>
>>>> R?mi
>>>>
>>>> ----- Mail original -----
>>>>> De: "Jorn Vernee" 
>>>>> ?: "Claes Redestad" , "core-libs-dev" 
>>>>> 
>>>>> Envoy?: Mardi 12 Novembre 2019 15:56:06
>>>>> Objet: Re: RFR 8233920: MethodHandles::tryFinally generates 
>>>>> illegal bytecode for long/double return types
>>>>
>>>>> Hi Claes,
>>>>>
>>>>> Thanks for the comments!
>>>>>
>>>>> Updated webrev: 
>>>>> http://cr.openjdk.java.net/~jvernee/8233920/webrev.02/
>>>>>
>>>>> Also, thanks for sponsoring.
>>>>>
>>>>> Jorn
>>>>>
>>>>> On 12/11/2019 15:30, Claes Redestad wrote:
>>>>>> Hi Jorn,
>>>>>>
>>>>>> good catch!
>>>>>>
>>>>>> Some minor stylistic concerns:
>>>>>>
>>>>>> "* = depends on whether the return type is a category 2 type, which
>>>>>> takes up 2 stack slots."
>>>>>>
>>>>>> While long/double are known to use two stack slots, "category 2 
>>>>>> type"
>>>>>> isn't used much outside the specification. I'd either simplify to
>>>>>> "* = depends on whether the return type takes up 1 or 2 stack 
>>>>>> slots."
>>>>>> or add a reference to the definition of type categories.
>>>>>>
>>>>>> Similarly I think:
>>>>>>
>>>>>> boolean returnsCat2Type = returnType == long.class || returnType ==
>>>>>> double.class;
>>>>>>
>>>>>> could be simplified as:
>>>>>>
>>>>>> boolean isDoubleWord = basicReturnType.isDoubleWord(); //
>>>>>> returnsDoubleWord?
>>>>>>
>>>>>> In the test, is it possible to narrow the expected exception to the
>>>>>> exact type being thrown (T1?) rather than Throwable?
>>>>>>
>>>>>> I can sponsor the patch.
>>>>>>
>>>>>> /Claes
>>>>>>
>>>>>> On 2019-11-12 12:09, Jorn Vernee wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Please review the following patch that fixes handling of 
>>>>>>> long/double
>>>>>>> returns for the tryFinally MethodHandle combinator.
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8233920
>>>>>>> Webrev: http://cr.openjdk.java.net/~jvernee/8233920/webrev.01/
>>>>>>> (Testing=tier1)
>>>>>>>
>>>>>>> FWIW, I also added some missing close tags to the javadoc in the
>>>>>>> InvokerBytecodeGenerator class (IntelliJ was warning about this).
>>>>>>>
>>>>>>> As a heads-up; I'm not a committer on the jdk project, so a sponsor
>>>>>>> would be needed to push this.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Jorn

From simonisv at amazon.de  Wed Nov 13 15:22:46 2019
From: simonisv at amazon.de (Simonis, Volker)
Date: Wed, 13 Nov 2019 15:22:46 +0000
Subject: RFR(XS): 8234011: (zipfs) Memory leak in
 ZipFileSystem.releaseDeflater()
Message-ID: <1573658564822.16574@amazon.de>

Hi,

can I please get a review for this trivial fix of an old copy-and-paste error:

http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011/
https://bugs.openjdk.java.net/browse/JDK-8234011

ZipFileSystem caches MAX_FLATER (currently 20) Inflater/Deflater objects. However the logic for reusing Deflaters is wrong because it references the Inflater List when checking against the number of already cached objects. This seems like a day-one copy and paste error.

Notice that this issue is not as critical as it appears, because retaining of additional Deflaters only happens when more than MAX_FLATER are used and released concurrently. I.e. the maximum number of cached Deflaters is the maximal number of Deflaters that are released while no new Deflater is requested. In practice this is usually still a small number, less than MAX_FLATERS. Nevertheless we can easily construct an example which demonstrates the memory leak (see the JTRegtest in the patch) and because the fix is trivial we should really fix this.

Thank you and best regards,
Volker



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879




From christoph.langer at sap.com  Wed Nov 13 16:26:27 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 13 Nov 2019 16:26:27 +0000
Subject: RFR(XS): 8234011: (zipfs) Memory leak in
 ZipFileSystem.releaseDeflater()
In-Reply-To: <1573658564822.16574@amazon.de>
References: <1573658564822.16574@amazon.de>
Message-ID: 

Hi Volker,

good catch in ZipFileSystem ?? The fix is the right thing to do.

I have a few remarks to the test, though:

Line 52, initialization of the File object: I think you should just do Path zipFile = Paths.get("file.zip"); When the test is run in the jtreg framework, it's running in its own scratch directory, so no need to use java.io.tmpdir. You can also leave cleanup to jtreg and don't need to delete the file in the end (in the finally block). However, you should probably check whether the file exists in the beginning and delete it in that case.

Line 55ff: You don't need to use this URI thing any more. You can simply do: try (FileSystem fs = FileSystems.newFileSystem(zipFile, Map.of("create", true))) { (line 58).

Line 61/62: You're using a Vector, wow ?? You should rather use ArrayList, I think...

Line 85: This should rather be:
                    @SuppressWarnings("unchecked")
                    int inflater_count = ((List)inflaters.get(fs)).size();
Same for line 89.

Line 93 (Catch clause): I think we should fail in that case, too. Otherwise, if the implementation would change, the test could run unnoticed for years, testing basically nothing...

Best regards,
Christoph


> -----Original Message-----
> From: core-libs-dev  On Behalf
> Of Simonis, Volker
> Sent: Mittwoch, 13. November 2019 16:23
> To: core-libs-dev at openjdk.java.net
> Subject: RFR(XS): 8234011: (zipfs) Memory leak in
> ZipFileSystem.releaseDeflater()
> 
> Hi,
> 
> can I please get a review for this trivial fix of an old copy-and-paste error:
> 
> http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011/
> https://bugs.openjdk.java.net/browse/JDK-8234011
> 
> ZipFileSystem caches MAX_FLATER (currently 20) Inflater/Deflater objects.
> However the logic for reusing Deflaters is wrong because it references the
> Inflater List when checking against the number of already cached objects.
> This seems like a day-one copy and paste error.
> 
> Notice that this issue is not as critical as it appears, because retaining of
> additional Deflaters only happens when more than MAX_FLATER are used
> and released concurrently. I.e. the maximum number of cached Deflaters is
> the maximal number of Deflaters that are released while no new Deflater is
> requested. In practice this is usually still a small number, less than
> MAX_FLATERS. Nevertheless we can easily construct an example which
> demonstrates the memory leak (see the JTRegtest in the patch) and because
> the fix is trivial we should really fix this.
> 
> Thank you and best regards,
> Volker
> 
> 
> 
> Amazon Development Center Germany GmbH
> Krausenstr. 38
> 10117 Berlin
> Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
> Sitz: Berlin
> Ust-ID: DE 289 237 879
> 
> 


From vladimir.x.ivanov at oracle.com  Wed Nov 13 16:36:50 2019
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 13 Nov 2019 19:36:50 +0300
Subject: RFR 8233920: MethodHandles::tryFinally generates illegal bytecode
 for long/double return types
In-Reply-To: <2188da92-ecf6-b4a2-0e73-db7be3932b39@oracle.com>
References: 
 
 <16ec7b47-13c7-c295-01a8-f1c3d00d51a2@oracle.com>
 <205939871.532800.1573571287304.JavaMail.zimbra@u-pem.fr>
 <47ba05ec-d09f-9ee8-4fd0-aa25a365c0d8@oracle.com>
 <987d4f91-1941-7b1e-ea65-ed5acc08696a@oracle.com>
 <798179d6-6ff3-d187-a8ff-c6acc32bcbe4@oracle.com>
 <2188da92-ecf6-b4a2-0e73-db7be3932b39@oracle.com>
Message-ID: 


> http://cr.openjdk.java.net/~jvernee/8233920/webrev.04/

Looks good.

Best regards,
Vladimir Ivanov

> On 13/11/2019 11:28, Vladimir Ivanov wrote:
>>
>>> http://cr.openjdk.java.net/~jvernee/8233920/webrev.03/
>>
>> I like how the patch shapes. Looks good.
>>
>> In addition, you can encapsulate the following code into a helper method:
>>
>> ????????? if (isNonVoid) {
>> -???????????? mv.visitInsn(Opcodes.POP);
>> +???????????? if (isDoubleWord) {
>> +???????????????? mv.visitInsn(Opcodes.POP2);
>> +???????????? } else {
>> +???????????????? mv.visitInsn(Opcodes.POP);
>> +???????????? }
>> ????????? }
>>
>>
>> ??? if (isNonVoid) {
>> ????? BasicType basicReturnType = BasicType.basicType(returnType);
>> ????? emitPopInsn(basicReturnType);
>> ??? }
>>
>> ??? private void emitPopInsn(BasicType type) {
>> ????? mv.visitVarInsn(popInsnOpcode(type));
>> ??? }
>>
>> ??? private int popInsnOpcode(BasicType type) {
>> ?????? switch (type) {
>> ???????? case I_TYPE: return Opcodes.POP;
>> ???????? case J_TYPE: return Opcodes.POP2;
>> ???????? case F_TYPE: return Opcodes.POP;
>> ???????? case D_TYPE: return Opcodes.POP2;
>> ???????? case L_TYPE: return Opcodes.POP;
>> ???????? default:
>> ?????????? throw new InternalError("unknown type: " + type);
>> ??? }
>>
>> Best regards,
>> Vladimir Ivanov
>>
>>> As long as Claes is okay with it, I think we should go for that one 
>>> since the code/doc is simpler. I can file an RFE for examining the 
>>> performance of different code shapes.
>>>
>>> Thanks,
>>> Jorn
>>>
>>> On 12/11/2019 16:35, Claes Redestad wrote:
>>>> Interesting, and you might be right. However I think it'd be better to
>>>> file a follow-up to examine this (pre-existing) behavior than to 
>>>> expand the scope of this bug fix.
>>>>
>>>> /Claes
>>>>
>>>> On 2019-11-12 16:08, Remi Forax wrote:
>>>>> Hi Jorn, Claes,
>>>>> Is it not better to always store in a local variable, like javac 
>>>>> does, instead of doing the double SWAP if there is a return value 
>>>>> of size 1 ?
>>>>>
>>>>> R?mi
>>>>>
>>>>> ----- Mail original -----
>>>>>> De: "Jorn Vernee" 
>>>>>> ?: "Claes Redestad" , "core-libs-dev" 
>>>>>> 
>>>>>> Envoy?: Mardi 12 Novembre 2019 15:56:06
>>>>>> Objet: Re: RFR 8233920: MethodHandles::tryFinally generates 
>>>>>> illegal bytecode for long/double return types
>>>>>
>>>>>> Hi Claes,
>>>>>>
>>>>>> Thanks for the comments!
>>>>>>
>>>>>> Updated webrev: 
>>>>>> http://cr.openjdk.java.net/~jvernee/8233920/webrev.02/
>>>>>>
>>>>>> Also, thanks for sponsoring.
>>>>>>
>>>>>> Jorn
>>>>>>
>>>>>> On 12/11/2019 15:30, Claes Redestad wrote:
>>>>>>> Hi Jorn,
>>>>>>>
>>>>>>> good catch!
>>>>>>>
>>>>>>> Some minor stylistic concerns:
>>>>>>>
>>>>>>> "* = depends on whether the return type is a category 2 type, which
>>>>>>> takes up 2 stack slots."
>>>>>>>
>>>>>>> While long/double are known to use two stack slots, "category 2 
>>>>>>> type"
>>>>>>> isn't used much outside the specification. I'd either simplify to
>>>>>>> "* = depends on whether the return type takes up 1 or 2 stack 
>>>>>>> slots."
>>>>>>> or add a reference to the definition of type categories.
>>>>>>>
>>>>>>> Similarly I think:
>>>>>>>
>>>>>>> boolean returnsCat2Type = returnType == long.class || returnType ==
>>>>>>> double.class;
>>>>>>>
>>>>>>> could be simplified as:
>>>>>>>
>>>>>>> boolean isDoubleWord = basicReturnType.isDoubleWord(); //
>>>>>>> returnsDoubleWord?
>>>>>>>
>>>>>>> In the test, is it possible to narrow the expected exception to the
>>>>>>> exact type being thrown (T1?) rather than Throwable?
>>>>>>>
>>>>>>> I can sponsor the patch.
>>>>>>>
>>>>>>> /Claes
>>>>>>>
>>>>>>> On 2019-11-12 12:09, Jorn Vernee wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Please review the following patch that fixes handling of 
>>>>>>>> long/double
>>>>>>>> returns for the tryFinally MethodHandle combinator.
>>>>>>>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8233920
>>>>>>>> Webrev: http://cr.openjdk.java.net/~jvernee/8233920/webrev.01/
>>>>>>>> (Testing=tier1)
>>>>>>>>
>>>>>>>> FWIW, I also added some missing close tags to the javadoc in the
>>>>>>>> InvokerBytecodeGenerator class (IntelliJ was warning about this).
>>>>>>>>
>>>>>>>> As a heads-up; I'm not a committer on the jdk project, so a sponsor
>>>>>>>> would be needed to push this.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Jorn

From christoph.langer at sap.com  Wed Nov 13 16:42:22 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 13 Nov 2019 16:42:22 +0000
Subject: RFR: 8234089: (zipfs) Remove classes JarFileSystemProvider and
 JarFileSystem
Message-ID: 

Hi,

can I please get reviews for this cleanup change in zipfs.

Bug: https://bugs.openjdk.java.net/browse/JDK-8234089
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234089.0/

I figured that JarFileSystemProvider is completely obsolete (please correct me if I'm wrong) and the reasons for having a class JarFileSystem that extends ZipFileSystems are very little in my opinion. I think maintainability is better when the few implementation details of multi release jars live in ZipFileSystem as well. It saves some code. The only possible drawback is that ZipFileSystem:: getInode would have an additional call to a lookup function, that usually is an identity transformation. I would hope however, that runtime impact is negligible.

I also fix a small bug when property "releaseVersion" is set to null in the env map and multi-release contains a value. In the current implementation it would not consider the "multi-release" value and treat the mr jar as the current runtime version. I had to do a small fix in MultiReleaseJarTest.java to make sure the properties list is cleared in every case.

The jdk/nio/zipfs tests run well after my change.

Thanks
Christoph


From lance.andersen at oracle.com  Wed Nov 13 17:54:34 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 13 Nov 2019 12:54:34 -0500
Subject: RFR(XS): 8234011: (zipfs) Memory leak in
 ZipFileSystem.releaseDeflater()
In-Reply-To: 
References: <1573658564822.16574@amazon.de>
 
Message-ID: <45B01685-8D87-4171-BD84-778659680C67@oracle.com>

Hi Volker,

Thank you for doing this.

As Christoph mentioned,  you can just do Path.of() and create the file in the work directory for the test.

If possible, I would use TestNG as that is consistent with the vast majority of the tests.

I also believe the rest of the comments below are worth addressing.

Thank you again for the fix

Best
Lance
> On Nov 13, 2019, at 11:26 AM, Langer, Christoph  wrote:
> 
> Hi Volker,
> 
> good catch in ZipFileSystem ?? The fix is the right thing to do.
> 
> I have a few remarks to the test, though:
> 
> Line 52, initialization of the File object: I think you should just do Path zipFile = Paths.get("file.zip"); When the test is run in the jtreg framework, it's running in its own scratch directory, so no need to use java.io.tmpdir. You can also leave cleanup to jtreg and don't need to delete the file in the end (in the finally block). However, you should probably check whether the file exists in the beginning and delete it in that case.
> 
> Line 55ff: You don't need to use this URI thing any more. You can simply do: try (FileSystem fs = FileSystems.newFileSystem(zipFile, Map.of("create", true))) { (line 58).
> 
> Line 61/62: You're using a Vector, wow ?? You should rather use ArrayList, I think...
> 
> Line 85: This should rather be:
>                    @SuppressWarnings("unchecked")
>                    int inflater_count = ((List)inflaters.get(fs)).size();
> Same for line 89.
> 
> Line 93 (Catch clause): I think we should fail in that case, too. Otherwise, if the implementation would change, the test could run unnoticed for years, testing basically nothing...
> 
> Best regards,
> Christoph
> 
> 
>> -----Original Message-----
>> From: core-libs-dev  On Behalf
>> Of Simonis, Volker
>> Sent: Mittwoch, 13. November 2019 16:23
>> To: core-libs-dev at openjdk.java.net
>> Subject: RFR(XS): 8234011: (zipfs) Memory leak in
>> ZipFileSystem.releaseDeflater()
>> 
>> Hi,
>> 
>> can I please get a review for this trivial fix of an old copy-and-paste error:
>> 
>> http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011/
>> https://bugs.openjdk.java.net/browse/JDK-8234011
>> 
>> ZipFileSystem caches MAX_FLATER (currently 20) Inflater/Deflater objects.
>> However the logic for reusing Deflaters is wrong because it references the
>> Inflater List when checking against the number of already cached objects.
>> This seems like a day-one copy and paste error.
>> 
>> Notice that this issue is not as critical as it appears, because retaining of
>> additional Deflaters only happens when more than MAX_FLATER are used
>> and released concurrently. I.e. the maximum number of cached Deflaters is
>> the maximal number of Deflaters that are released while no new Deflater is
>> requested. In practice this is usually still a small number, less than
>> MAX_FLATERS. Nevertheless we can easily construct an example which
>> demonstrates the memory leak (see the JTRegtest in the patch) and because
>> the fix is trivial we should really fix this.
>> 
>> Thank you and best regards,
>> Volker
>> 
>> 
>> 
>> Amazon Development Center Germany GmbH
>> Krausenstr. 38
>> 10117 Berlin
>> Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
>> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
>> Sitz: Berlin
>> Ust-ID: DE 289 237 879
>> 
>> 
> 

 
  
 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 brent.christian at oracle.com  Wed Nov 13 18:37:19 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Wed, 13 Nov 2019 10:37:19 -0800
Subject: RFR 8233272 : The Class.forName specification should be updated to
 match the long-standing implementation with respect to class linking
Message-ID: <79528f01-3418-eb51-4dbd-897e4e97f853@oracle.com>

Hi,

Recently, the 2-arg and 3-arg Class.forName() methods were updated[1] to 
perform class linking, per the specification.  However this change had 
to be reverted[2].

Instead, let's clarify the Class.forName() spec not to guarantee linking 
(outside the case of also performing initialization, of course).  This 
is the long-standing behavior.

I also have a test of the non-linking behavior; it's based on the test 
case[3] for JDK-8231924.  It fails as of 14b14 (8212117) and passes as 
of 14b22 (8233091).

Please review my webrev:
http://cr.openjdk.java.net/~bchristi/8233272/webrev-02/

If the wording looks good, I'll fill in the Specification for the CSR[4] 
I've started.

Thanks,
-Brent


1. https://bugs.openjdk.java.net/browse/JDK-8212117

2. https://bugs.openjdk.java.net/browse/JDK-8233091

3. 
https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-October/062747.html

4. https://bugs.openjdk.java.net/browse/JDK-8233554

From gerard.ziemski at oracle.com  Wed Nov 13 18:50:30 2019
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Wed, 13 Nov 2019 12:50:30 -0600
Subject: RFR (M) 8223261 "JDK-8189208 followup - remove JDK_GetVersionInfo0
 and the supporting code"
Message-ID: <4623455a-2d90-e697-89b3-830d5becf8f9@oracle.com>

Hi all,

Please review this cleanup, where we remove JDK_GetVersionInfo0 and 
related code, since we can get build versions directly from within the 
VM itself:

I'm including core-libs and awt in this review because the proposed fix 
touches their corresponding files.


bug: https://bugs.openjdk.java.net/browse/JDK-8223261
webrev: http://cr.openjdk.java.net/~gziemski/8223261_rev1
tests: passes Mach5 tier1,2,3,4,5,6


cheers


From claes.redestad at oracle.com  Wed Nov 13 19:04:00 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 13 Nov 2019 20:04:00 +0100
Subject: RFR (M) 8223261 "JDK-8189208 followup - remove
 JDK_GetVersionInfo0 and the supporting code"
In-Reply-To: <4623455a-2d90-e697-89b3-830d5becf8f9@oracle.com>
References: <4623455a-2d90-e697-89b3-830d5becf8f9@oracle.com>
Message-ID: 

On 2019-11-13 19:50, gerard ziemski wrote:
> webrev: http://cr.openjdk.java.net/~gziemski/8223261_rev1

Nice cleanup! Looks good to me.

/Claes

From john.r.rose at oracle.com  Wed Nov 13 19:05:54 2019
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 13 Nov 2019 11:05:54 -0800
Subject: RFR 8233920: MethodHandles::tryFinally generates illegal bytecode
 for long/double return types
In-Reply-To: <798179d6-6ff3-d187-a8ff-c6acc32bcbe4@oracle.com>
References: 
 
 <16ec7b47-13c7-c295-01a8-f1c3d00d51a2@oracle.com>
 <205939871.532800.1573571287304.JavaMail.zimbra@u-pem.fr>
 <47ba05ec-d09f-9ee8-4fd0-aa25a365c0d8@oracle.com>
 <987d4f91-1941-7b1e-ea65-ed5acc08696a@oracle.com>
 <798179d6-6ff3-d187-a8ff-c6acc32bcbe4@oracle.com>
Message-ID: 

On Nov 13, 2019, at 2:28 AM, Vladimir Ivanov > wrote:
> 
>    private void emitPopInsn(BasicType type) {
>      mv.visitVarInsn(popInsnOpcode(type));
>    }
> 

Thanks for suggesting that Vladimir.  That indeed is how the existing code is organized.

From mandy.chung at oracle.com  Wed Nov 13 19:07:51 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 13 Nov 2019 11:07:51 -0800
Subject: RFR JDK-8233527: Update Lookup::hasPrivateAccess and
 Lookup::defineClass spec w.r.t. full power lookup
In-Reply-To: <083da65f-e1a5-4f30-9d15-cf69df1918ec@j-kuhn.de>
References: <081f506c-62a9-dd98-8b62-04690f4cba14@oracle.com>
 <083da65f-e1a5-4f30-9d15-cf69df1918ec@j-kuhn.de>
Message-ID: <94a4b52c-b47d-f861-54d5-6d661991b67b@oracle.com>



On 11/13/19 6:10 AM, Johannes Kuhn wrote:
> On 11.11.2019 22:23, Mandy Chung wrote:
>> This is a follow-up of JDK-8226916. Lookup::hasPrivateAccess intends 
>> to test if this lookup is a full-power lookup; that is created by the 
>> original caller class calling MethodHandles::lookup. The current 
>> specification for Lookup::hasPrivateAccess returns true if the lookup 
>> modes contain PRIVATE but it does not check MODULE bit.
>>
>> This patch also clarifies the capabilities w.r.t PRIVATE access and 
>> full-power access. The security permission check is performed if the 
>> Lookup is not a full power lookup and therefore Lookup::defineClass 
>> spec should be updated to perform security permission check if the 
>> security manager is present and this lookup refuses access, 
>> consistent with other Lookup operations.
>>
>> http://cr.openjdk.java.net/~mchung/jdk14/8233527/webrev.02/
>> http://cr.openjdk.java.net/~mchung/jdk14/8233527/specdiff/
>>
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8233726
>>
>> thanks
>> Mandy
>
> Thank you for all those changes. It fixed two of my reported bugs 
> (JDK-8209005, JDK-8209078).

Thanks for filing these good reports.?? JDK-8173978 resolved the issues 
reported by JDK-8209005 and JDK-8209078.

> It also makes my suggested workaround for JDK-8230636 not longer 
> possible. Thanks for picking that up too.
>
> I just have a question about the requirement of 
> MethodHandles.privateLookupIn: As it requires that the originating 
> lookup has both PRIVATE and MODULE access, it sounds a lot like full 
> privilege access. Should this be reworded?
>

The two bullets about the caller lookup object must have MODULE and 
PRIVATE are important explanation for it to require such access.

Maybe I can add a bullet to say "The caller lookup object must have full 
privilege access" and then move those two bullets as sub-bullets under it.

What do you think?

> Also, with the current specification, I don't see a way to abuse 
> jdk.unsupported's privileged access into java.base (which IMHO caused 
> the entire rework).

Thanks for looking at this.

Mandy

From claes.redestad at oracle.com  Wed Nov 13 19:24:17 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 13 Nov 2019 20:24:17 +0100
Subject: RFR 8233920: MethodHandles::tryFinally generates illegal bytecode
 for long/double return types
In-Reply-To: 
References: 
 
 <16ec7b47-13c7-c295-01a8-f1c3d00d51a2@oracle.com>
 <205939871.532800.1573571287304.JavaMail.zimbra@u-pem.fr>
 <47ba05ec-d09f-9ee8-4fd0-aa25a365c0d8@oracle.com>
 <987d4f91-1941-7b1e-ea65-ed5acc08696a@oracle.com>
 <798179d6-6ff3-d187-a8ff-c6acc32bcbe4@oracle.com>
 
Message-ID: <642febde-0cdc-199d-c7f7-2d81bf425a98@oracle.com>



On 2019-11-13 20:05, John Rose wrote:
> On Nov 13, 2019, at 2:28 AM, Vladimir Ivanov 
> > wrote:
>>
>> ???private void emitPopInsn(BasicType type) {
>> ?????mv.visitVarInsn(popInsnOpcode(type));
>> ???}
>>
> 
> Thanks for suggesting that Vladimir. ?That indeed is how the existing 
> code is organized.

Yes, not very startup friendly... ;-)

I'll do some sanity testing before push.

/Claes

From mandy.chung at oracle.com  Wed Nov 13 19:29:52 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 13 Nov 2019 11:29:52 -0800
Subject: RFR (M) 8223261 "JDK-8189208 followup - remove
 JDK_GetVersionInfo0 and the supporting code"
In-Reply-To: <4623455a-2d90-e697-89b3-830d5becf8f9@oracle.com>
References: <4623455a-2d90-e697-89b3-830d5becf8f9@oracle.com>
Message-ID: 



On 11/13/19 10:50 AM, gerard ziemski wrote:
> Hi all,
>
> Please review this cleanup, where we remove JDK_GetVersionInfo0 and 
> related code, since we can get build versions directly from within the 
> VM itself:
>
> I'm including core-libs and awt in this review because the proposed 
> fix touches their corresponding files.
>
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8223261
> webrev: http://cr.openjdk.java.net/~gziemski/8223261_rev1
> tests: passes Mach5 tier1,2,3,4,5,6
>

This is a good clean up.? JDK_GetVersionInfo0 was needed long time ago 
in particular in HS express support that is no longer applicable.

One leftover comment should also be removed.

src/hotspot/share/runtime/vm_version.hpp
 ? // Gets the jvm_version_info.jvm_version defined in jvm.h

otherwise looks good.

Mandy

From info at j-kuhn.de  Wed Nov 13 19:45:29 2019
From: info at j-kuhn.de (Johannes Kuhn)
Date: Wed, 13 Nov 2019 20:45:29 +0100
Subject: RFR JDK-8233527: Update Lookup::hasPrivateAccess and
 Lookup::defineClass spec w.r.t. full power lookup
In-Reply-To: <94a4b52c-b47d-f861-54d5-6d661991b67b@oracle.com>
References: <081f506c-62a9-dd98-8b62-04690f4cba14@oracle.com>
 <083da65f-e1a5-4f30-9d15-cf69df1918ec@j-kuhn.de>
 <94a4b52c-b47d-f861-54d5-6d661991b67b@oracle.com>
Message-ID: <6bb905bf-8803-cc9e-ea28-49da6685a78b@j-kuhn.de>

On 13.11.2019 20:07, Mandy Chung wrote:
>> Thank you for all those changes. It fixed two of my reported bugs 
>> (JDK-8209005, JDK-8209078).
>
> Thanks for filing these good reports.?? JDK-8173978 resolved the 
> issues reported by JDK-8209005 and JDK-8209078.
I'm happy I could help.
>> It also makes my suggested workaround for JDK-8230636 not longer 
>> possible. Thanks for picking that up too.
>>
>> I just have a question about the requirement of 
>> MethodHandles.privateLookupIn: As it requires that the originating 
>> lookup has both PRIVATE and MODULE access, it sounds a lot like full 
>> privilege access. Should this be reworded?
>>
>
> The two bullets about the caller lookup object must have MODULE and 
> PRIVATE are important explanation for it to require such access.
>
> Maybe I can add a bullet to say "The caller lookup object must have 
> full privilege access" and then move those two bullets as sub-bullets 
> under it.
>
> What do you think?
This is a good idea, because full privilege access is a new concept, and 
should be mentioned at the places where it is used.
>> Also, with the current specification, I don't see a way to abuse 
>> jdk.unsupported's privileged access into java.base (which IMHO caused 
>> the entire rework).
>
> Thanks for looking at this.
>
> Mandy

Shameless plug: I once asked on Stackoverflow if untrusted code running 
with a SecurityManager and -illegal-access=deny but granting 
|ReflectPermission("supressAccessChecks") |could escape the sandbox[1]. 
I found a way to escape the sandbox, which relies on the power of the 
Lookup returned by privateLookupIn.
As this has been changed, I wonder if this escape was ever intended in 
the first place. Are there any resources out there that can help answer 
this question?

Thanks,
Johannes

[1]: 
https://stackoverflow.com/questions/51712903/is-it-safe-to-grant-untrusted-code-supressaccesschecks-when-illegal-access-de


From john.r.rose at oracle.com  Wed Nov 13 20:04:54 2019
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 13 Nov 2019 12:04:54 -0800
Subject: RFR 8233920: MethodHandles::tryFinally generates illegal bytecode
 for long/double return types
In-Reply-To: <642febde-0cdc-199d-c7f7-2d81bf425a98@oracle.com>
References: 
 
 <16ec7b47-13c7-c295-01a8-f1c3d00d51a2@oracle.com>
 <205939871.532800.1573571287304.JavaMail.zimbra@u-pem.fr>
 <47ba05ec-d09f-9ee8-4fd0-aa25a365c0d8@oracle.com>
 <987d4f91-1941-7b1e-ea65-ed5acc08696a@oracle.com>
 <798179d6-6ff3-d187-a8ff-c6acc32bcbe4@oracle.com>
 
 <642febde-0cdc-199d-c7f7-2d81bf425a98@oracle.com>
Message-ID: 

On Nov 13, 2019, at 11:24 AM, Claes Redestad  wrote:
> 
>> Thanks for suggesting that Vladimir.  That indeed is how the existing code is organized.
> 
> Yes, not very startup friendly... ;-)

No, but it?s maintainer friendly.  We can walk and chew gum at the same time.

Is it time to think about a jlink plugin which inlines simple method calls?
Perhaps we need to wait until we understand (semi-)closed-world packaging.

Long, long ago, a very early version of javac did inlining of simple method calls.
That functionality was removed when we realized that this was placing ?getfield?
instructions in classes which didn?t have access to the referenced private fields,
causing code to break.  It also messed up the binary compatibility story required
to make sense of independently recompiled class files.  How innocent we were
back then.  We won?t make those same mistakes again, but we could try the
same trick again, more carefully, in jlink or some other static packaging workflow.

? John

From christoph.langer at sap.com  Wed Nov 13 20:05:12 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 13 Nov 2019 20:05:12 +0000
Subject: RFR (M) 8223261 "JDK-8189208 followup - remove
 JDK_GetVersionInfo0 and the supporting code"
In-Reply-To: 
References: <4623455a-2d90-e697-89b3-830d5becf8f9@oracle.com>
 
Message-ID: 

Hi Gerard,

generally it looks like a nice cleanup.

I've got a patch prepared though, which I was planning on posting tomorrow. It is about cleanup for the canonicalize function in libjava. I wanted to use jdk_util.h for the function prototype. I had not yet filed a bug but here is what I have:
http://cr.openjdk.java.net/~clanger/webrevs/cleanup-canonicalize/

So maybe you could refrain from removing jdk_util.h or maybe you can hold off submitting your change until my cleanup is reviewed?

I'll create a bug and post an official review thread tomorrow...

Thanks
Christoph

> -----Original Message-----
> From: hotspot-dev  On Behalf Of
> Mandy Chung
> Sent: Mittwoch, 13. November 2019 20:30
> To: gerard ziemski 
> Cc: awt-dev at openjdk.java.net; hotspot-dev developers  dev at openjdk.java.net>; core-libs-dev at openjdk.java.net
> Subject: Re: RFR (M) 8223261 "JDK-8189208 followup - remove
> JDK_GetVersionInfo0 and the supporting code"
> 
> 
> 
> On 11/13/19 10:50 AM, gerard ziemski wrote:
> > Hi all,
> >
> > Please review this cleanup, where we remove JDK_GetVersionInfo0 and
> > related code, since we can get build versions directly from within the
> > VM itself:
> >
> > I'm including core-libs and awt in this review because the proposed
> > fix touches their corresponding files.
> >
> >
> > bug: https://bugs.openjdk.java.net/browse/JDK-8223261
> > webrev: http://cr.openjdk.java.net/~gziemski/8223261_rev1
> > tests: passes Mach5 tier1,2,3,4,5,6
> >
> 
> This is a good clean up.? JDK_GetVersionInfo0 was needed long time ago
> in particular in HS express support that is no longer applicable.
> 
> One leftover comment should also be removed.
> 
> src/hotspot/share/runtime/vm_version.hpp
>  ? // Gets the jvm_version_info.jvm_version defined in jvm.h
> 
> otherwise looks good.
> 
> Mandy

From claes.redestad at oracle.com  Wed Nov 13 20:39:29 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 13 Nov 2019 21:39:29 +0100
Subject: RFR 8233920: MethodHandles::tryFinally generates illegal bytecode
 for long/double return types
In-Reply-To: 
References: 
 
 <16ec7b47-13c7-c295-01a8-f1c3d00d51a2@oracle.com>
 <205939871.532800.1573571287304.JavaMail.zimbra@u-pem.fr>
 <47ba05ec-d09f-9ee8-4fd0-aa25a365c0d8@oracle.com>
 <987d4f91-1941-7b1e-ea65-ed5acc08696a@oracle.com>
 <798179d6-6ff3-d187-a8ff-c6acc32bcbe4@oracle.com>
 
 <642febde-0cdc-199d-c7f7-2d81bf425a98@oracle.com>
 
Message-ID: <23adbdcb-d903-bbc4-709b-cb94f82808fc@oracle.com>


On 2019-11-13 21:04, John Rose wrote:
> On Nov 13, 2019, at 11:24 AM, Claes Redestad  > wrote:
>>
>>> Thanks for suggesting that Vladimir. ?That indeed is how the existing 
>>> code is organized.
>>
>> Yes, not very startup friendly... ;-)
> 
> No, but it?s maintainer friendly. ?We can walk and chew gum at the same 
> time >
> Is it time to think about a jlink plugin which inlines simple method calls?
> Perhaps we need to wait until we understand (semi-)closed-world packaging.
> 
> Long, long ago, a very early version of javac did inlining of simple 
> method calls.
> That functionality was removed when we realized that this was placing 
> ?getfield?
> instructions in classes which didn?t have access to the referenced 
> private fields,
> causing code to break. ?It also messed up the binary compatibility story 
> required
> to make sense of independently recompiled class files. ?How innocent we were
> back then. ?We won?t make those same mistakes again, but we could try the
> same trick again, more carefully, in jlink or some other static 
> packaging workflow.

As a startup optimization, inlining small (private?) methods at link-
time seems like a promising candidate, yes.

Similar to other promising candidates like constant folding I think it
opens up some more general questions about observability. For example:
do we retain the original bytecode and mappings everything back to it
so that a debugger would be none the wiser about any inlining that may
have happened? Do we "simply" deoptimize and redefine everything back to
the stashed original when someone hooks in a debugger..? (Do we go so
far as to allow opting out of debuggers entirely?)

/Claes




From john.r.rose at oracle.com  Wed Nov 13 20:49:03 2019
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 13 Nov 2019 12:49:03 -0800
Subject: RFR 8233920: MethodHandles::tryFinally generates illegal bytecode
 for long/double return types
In-Reply-To: <23adbdcb-d903-bbc4-709b-cb94f82808fc@oracle.com>
References: 
 
 <16ec7b47-13c7-c295-01a8-f1c3d00d51a2@oracle.com>
 <205939871.532800.1573571287304.JavaMail.zimbra@u-pem.fr>
 <47ba05ec-d09f-9ee8-4fd0-aa25a365c0d8@oracle.com>
 <987d4f91-1941-7b1e-ea65-ed5acc08696a@oracle.com>
 <798179d6-6ff3-d187-a8ff-c6acc32bcbe4@oracle.com>
 
 <642febde-0cdc-199d-c7f7-2d81bf425a98@oracle.com>
 
 <23adbdcb-d903-bbc4-709b-cb94f82808fc@oracle.com>
Message-ID: 

On Nov 13, 2019, at 12:39 PM, Claes Redestad  wrote:
> Similar to other promising candidates like constant folding I think it
> opens up some more general questions about observability. For example:
> do we retain the original bytecode and mappings everything back to it
> so that a debugger would be none the wiser about any inlining that may
> have happened? Do we "simply" deoptimize and redefine everything back to
> the stashed original when someone hooks in a debugger..? (Do we go so
> far as to allow opting out of debuggers entirely?)

Yep.  These questions are why link-time optimization is not a slam dunk.
If it were, I suppose we?d have it already.

Debugging is especially hard.  We don?t want to give it up, but any
program transformation is going to make debugging harder to implement.
You should see what the JITs do to support deopt; like exact GC, it?s
something that makes them different animals from the usual llvm/gcc
compilers.

That said, a bytecode-to-bytecode ?deoptimization? is easier to specify
and think about than a machine-code-to-bytecode deopt, which is what
the JITs support.  Juicy problems everywhere!

Also I wonder if stashing classifies for debugging only will motivate a partial
resurrection of pack200, for storing said things ?cold? on disk.


From claes.redestad at oracle.com  Wed Nov 13 21:02:27 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 13 Nov 2019 22:02:27 +0100
Subject: RFR 8233920: MethodHandles::tryFinally generates illegal bytecode
 for long/double return types
In-Reply-To: 
References: 
 
 <16ec7b47-13c7-c295-01a8-f1c3d00d51a2@oracle.com>
 <205939871.532800.1573571287304.JavaMail.zimbra@u-pem.fr>
 <47ba05ec-d09f-9ee8-4fd0-aa25a365c0d8@oracle.com>
 <987d4f91-1941-7b1e-ea65-ed5acc08696a@oracle.com>
 <798179d6-6ff3-d187-a8ff-c6acc32bcbe4@oracle.com>
 
 <642febde-0cdc-199d-c7f7-2d81bf425a98@oracle.com>
 
 <23adbdcb-d903-bbc4-709b-cb94f82808fc@oracle.com>
 
Message-ID: 

On 2019-11-13 21:49, John Rose wrote:
> On Nov 13, 2019, at 12:39 PM, Claes Redestad  wrote:
>> Similar to other promising candidates like constant folding I think it
>> opens up some more general questions about observability. For example:
>> do we retain the original bytecode and mappings everything back to it
>> so that a debugger would be none the wiser about any inlining that may
>> have happened? Do we "simply" deoptimize and redefine everything back to
>> the stashed original when someone hooks in a debugger..? (Do we go so
>> far as to allow opting out of debuggers entirely?)
> Yep.  These questions are why link-time optimization is not a slam dunk.
> If it were, I suppose we?d have it already.
> 
> Debugging is especially hard.  We don?t want to give it up, but any
> program transformation is going to make debugging harder to implement.
> You should see what the JITs do to support deopt; like exact GC, it?s
> something that makes them different animals from the usual llvm/gcc
> compilers.
> 
> That said, a bytecode-to-bytecode ?deoptimization? is easier to specify
> and think about than a machine-code-to-bytecode deopt, which is what
> the JITs support.  Juicy problems everywhere!

Yes, not trivial, but likely much easier.

> 
> Also I wonder if stashing classifies for debugging only will motivate a partial
> resurrection of pack200, for storing said things ?cold? on disk.

AFAIU, pack200 comes with a maintenance burden that we'd like to
permanently get rid of. For a stashed-away class file archive only used
when debugging then plain old zip at a high compression level might be
sufficient.

/Claes

From mandy.chung at oracle.com  Wed Nov 13 22:06:50 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 13 Nov 2019 14:06:50 -0800
Subject: RFR JDK-8233527: Update Lookup::hasPrivateAccess and
 Lookup::defineClass spec w.r.t. full power lookup
In-Reply-To: <6bb905bf-8803-cc9e-ea28-49da6685a78b@j-kuhn.de>
References: <081f506c-62a9-dd98-8b62-04690f4cba14@oracle.com>
 <083da65f-e1a5-4f30-9d15-cf69df1918ec@j-kuhn.de>
 <94a4b52c-b47d-f861-54d5-6d661991b67b@oracle.com>
 <6bb905bf-8803-cc9e-ea28-49da6685a78b@j-kuhn.de>
Message-ID: 



On 11/13/19 11:45 AM, Johannes Kuhn wrote:
> This is a good idea, because full privilege access is a new concept, 
> and should be mentioned at the places where it is used. 

To clarify, "full privilege access" (aka "full power") is not really a 
new concept.

Module access was introduced in Java SE 9.? A full privilege access 
(despite the name of `hasPrivateAccess`) necessarily includes module 
privilege.?? Before JDK-8173978, a Lookup with private access always 
includes module privilege.? After JDK-8173978, the module privilege has 
become independent of private privilege and hence this new 
`hasFullPrivilegeAcess` method, a correctly named method, is proposed.

Mandy

From jonathan.gibbons at oracle.com  Wed Nov 13 22:35:34 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 13 Nov 2019 14:35:34 -0800
Subject: JDK 14 RFR of JDK-8233940: Preview API tests for String methods
 should use ${jdk.version} as -source arg
In-Reply-To: 
References: <02f2ee31-5998-6161-2eb8-5b923a72a71c@oracle.com>
 
Message-ID: <64e7651e-3991-dea7-d472-acb75b1b1475@oracle.com>

+1


On 11/12/2019 09:50 AM, Jan Lahoda wrote:
> Looks good to me.
>
> Jan
>
> On 12. 11. 19 7:13, Joe Darcy wrote:
>> Hello,
>>
>> To remove the need to modify tests when the JDK version is updated, 
>> the tests of the preview API in String should use "${jdk.version}" as 
>> an argument to -source rather than a fixed version string:
>>
>> ???? JDK-8233940: Preview API tests for String methods should use 
>> ${jdk.version} as -source arg
>> ???? http://cr.openjdk.java.net/~darcy/8233940.0/
>>
>> The new TEST.properties file only affects tests in the 
>> java/lang/String directory. Some additional work is needed before 
>> jtreg "smart actions" can be enabled throughout the tests in the 
>> "jdk" directory as they are already in "langtools".
>>
>> Patch below.
>>
>> Thanks,
>>
>> -Joe
>>
>> --- old/test/jdk/java/lang/String/Formatted.java?? ?2019-11-11 
>> 22:09:42.692005000 -0800
>> +++ new/test/jdk/java/lang/String/Formatted.java?? ?2019-11-11 
>> 22:09:42.476005000 -0800
>> @@ -25,7 +25,7 @@
>> ?? * @test
>> ?? * bug 8203444
>> ?? * @summary Unit tests for instance versions of String#format
>> - * @compile --enable-preview -source 14 Formatted.java
>> + * @compile --enable-preview -source ${jdk.version} Formatted.java
>> ?? * @run main/othervm --enable-preview Formatted
>> ?? */
>>
>> --- old/test/jdk/java/lang/String/StripIndent.java?? ?2019-11-11 
>> 22:09:43.376005000 -0800
>> +++ new/test/jdk/java/lang/String/StripIndent.java?? ?2019-11-11 
>> 22:09:43.120005000 -0800
>> @@ -25,7 +25,7 @@
>> ?? * @test
>> ?? * @bug 8223775
>> ?? * @summary This exercises String#stripIndent patterns and limits.
>> - * @compile --enable-preview -source 14 StripIndent.java
>> + * @compile --enable-preview -source ${jdk.version} StripIndent.java
>> ?? * @run main/othervm --enable-preview StripIndent
>> ?? */
>>
>> --- old/test/jdk/java/lang/String/TranslateEscapes.java ?2019-11-11 
>> 22:09:44.020005000 -0800
>> +++ new/test/jdk/java/lang/String/TranslateEscapes.java ?2019-11-11 
>> 22:09:43.776005000 -0800
>> @@ -25,7 +25,7 @@
>> ?? * @test
>> ?? * @bug 8223780
>> ?? * @summary This exercises String#translateEscapes patterns and 
>> limits.
>> - * @compile --enable-preview -source 14 TranslateEscapes.java
>> + * @compile --enable-preview -source ${jdk.version} 
>> TranslateEscapes.java
>> ?? * @run main/othervm --enable-preview TranslateEscapes
>> ?? */
>>
>> --- /dev/null?? ?2019-09-13 10:19:35.768000000 -0700
>> +++ new/test/jdk/java/lang/String/TEST.properties?? ?2019-11-11 
>> 22:09:44.396005000 -0800
>> @@ -0,0 +1 @@
>> +allowSmartActionArgs=true
>>


From sergei.tsypanov at yandex.ru  Wed Nov 13 23:24:25 2019
From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=)
Date: Thu, 14 Nov 2019 01:24:25 +0200
Subject: [PATCH] Enhancement proposal for usage of
 Method::getParameterTypes
In-Reply-To: 
References: <81964221573250667@myt5-1466095fe4e5.qloud-c.yandex.net>
 
Message-ID: <104016241573687465@sas1-1c1950f2fdb4.qloud-c.yandex.net>

Hello,

thanks for quick review!

Tagir Valeev from JetBrains comes with suggestion to improve compiler optimizations here https://youtrack.jetbrains.com/issue/IDEA-226474.

Rationale: in fact the cloned array could be a subject of allocation erasure as any property dereferenced from it can be dereferenced from original array:

Consider this test:

@Test
void join() {
  final Object[] objects = new Object[3];
  objects[0] = "azaza";
  objects[1] = 365;
  objects[2] = 9876L;

  final Object[] clone = objects.clone();

  assertEquals(objects.length, clone.length);
  assertSame(objects[0], clone[0]);
  assertSame(objects[1], clone[1]);
  assertSame(objects[2], clone[2]);
}

Optimizing compiler could drop allocation of clone and substitute its usage with original array, but as previous benchmark demonstrates it doesn't do that at least on JDK 11.

Is there a way I can develop a patch for compiler and is this mailing list is appropriate place to discuss compiler issues?

Regards,
Sergey Tsypanov


09.11.2019, 01:15, "Claes Redestad" :
> Hi,
>
> some or all of these were pointed out as part of
> https://bugs.openjdk.java.net/browse/JDK-8029019
>
> There was a patch out for review early 2017. I'm not sure what happened
> to that?
>
> Either way I think it might make sense to get this small and trivial
> enhancement separated out and fixed.
>
> Thanks!
>
> /Claes
>
> On 2019-11-08 23:04, ?????? ??????? wrote:
>> ?Hello,
>>
>> ?it seems like Method.getParameterTypes() is often misused in JDK (and beyond): array returned from the method is used only to acquire number of method params by retrieving array.length.
>> ?The problem here is that Method.getPatameterTypes() clones underlying array and returns the copy.
>> ?Instead we can use Method.getParameterCount() which doesn't allocate any additional memory but returns directly the length of underlying array.
>>
>> ?To measure probable performance difference I've created a benchmark for the most simple case when tested method has no parameters:
>>
>> ?@State(Scope.Thread)
>> ?@BenchmarkMode(Mode.AverageTime)
>> ?@OutputTimeUnit(TimeUnit.NANOSECONDS)
>> ?public class MethodToStringBenchmark {
>> ????private Method method;
>>
>> ????@Setup
>> ????public void setup() throws Exception { method = getClass().getMethod("toString"); }
>>
>> ????@Benchmark
>> ????public int getParameterCount() { return method.getParameterCount(); }
>>
>> ????@Benchmark
>> ????public int getParameterTypes() { return method.getParameterTypes().length; }
>> ?}
>>
>> ?on my i7-7700 with JDK 11 it produces these results:
>>
>> ?Benchmark Mode Cnt Score Error Units
>>
>> ?MethodToStringBenchmark.getParameterCount avgt 25 2,528 ? 0,085 ns/op
>> ?MethodToStringBenchmark.getParameterCount:?gc.alloc.rate avgt 25 ? 10?? MB/sec
>> ?MethodToStringBenchmark.getParameterCount:?gc.alloc.rate.norm avgt 25 ? 10?? B/op
>> ?MethodToStringBenchmark.getParameterCount:?gc.count avgt 25 ? 0 counts
>>
>> ?MethodToStringBenchmark.getParameterTypes avgt 25 7,299 ? 0,410 ns/op
>> ?MethodToStringBenchmark.getParameterTypes:?gc.alloc.rate avgt 25 1999,454 ? 89,929 MB/sec
>> ?MethodToStringBenchmark.getParameterTypes:?gc.alloc.rate.norm avgt 25 16,000 ? 0,001 B/op
>> ?MethodToStringBenchmark.getParameterTypes:?gc.churn.G1_Eden_Space avgt 25 2003,360 ? 91,537 MB/sec
>> ?MethodToStringBenchmark.getParameterTypes:?gc.churn.G1_Eden_Space.norm avgt 25 16,030 ? 0,045 B/op
>> ?MethodToStringBenchmark.getParameterTypes:?gc.churn.G1_Old_Gen avgt 25 0,004 ? 0,001 MB/sec
>> ?MethodToStringBenchmark.getParameterTypes:?gc.churn.G1_Old_Gen.norm avgt 25 ? 10?? B/op
>> ?MethodToStringBenchmark.getParameterTypes:?gc.count avgt 25 2380,000 counts
>> ?MethodToStringBenchmark.getParameterTypes:?gc.time avgt 25 1325,000 ms
>>
>> ?I've prepared a small patch to replace usage of getParameterTypes() with getParameterCount() where appropriate in java.base module.
>>
>> ?The patch is attached.
>>
>> ?Regards,
>> ?Sergey Tsypanov

From andy.herrick at oracle.com  Thu Nov 14 00:23:00 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Wed, 13 Nov 2019 19:23:00 -0500
Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
Message-ID: 

Please review? changes for [1] which is the implementation bug for JEP-343.

The webrev at [2] is the total cumulative webrev of changes for the 
jpackage tool, currently in the JDK-8200758-branch branch of the open 
sandbox repository.

The webrev at [3] shows the changes since EA-06 (Build 13-jpackage+1-49 
) up to the current point.

The latest EA (Build 14-jpackage+1-49 ) is posted at [4].

Please send feedback to core-libs-dev at openjdk.java.net


[1] https://bugs.openjdk.java.net/browse/JDK-8212780

[2] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-10/

[3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-10/

[4] http://jdk.java.net/jpackage/


From david.holmes at oracle.com  Thu Nov 14 03:21:50 2019
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 14 Nov 2019 13:21:50 +1000
Subject: RFR (M) 8223261 "JDK-8189208 followup - remove
 JDK_GetVersionInfo0 and the supporting code"
In-Reply-To: 
References: <4623455a-2d90-e697-89b3-830d5becf8f9@oracle.com>
 
 
Message-ID: 

Hi Gerard,

On 14/11/2019 6:05 am, Langer, Christoph wrote:
> Hi Gerard,
> 
> generally it looks like a nice cleanup.
> 
> I've got a patch prepared though, which I was planning on posting tomorrow. It is about cleanup for the canonicalize function in libjava. I wanted to use jdk_util.h for the function prototype. I had not yet filed a bug but here is what I have:
> http://cr.openjdk.java.net/~clanger/webrevs/cleanup-canonicalize/
> 
> So maybe you could refrain from removing jdk_util.h or maybe you can hold off submitting your change until my cleanup is reviewed?

I'd also suggest not deleting jdk_util.h. It seems very odd to me to 
have jdk_util_md.h with no shared jdk_util.h. If you keep jdk_util.h 
then you don't need to touch a number of the files.

Otherwise this looks like a good cleanup.

Thanks,
David
-----

> I'll create a bug and post an official review thread tomorrow...
> 
> Thanks
> Christoph
> 
>> -----Original Message-----
>> From: hotspot-dev  On Behalf Of
>> Mandy Chung
>> Sent: Mittwoch, 13. November 2019 20:30
>> To: gerard ziemski 
>> Cc: awt-dev at openjdk.java.net; hotspot-dev developers > dev at openjdk.java.net>; core-libs-dev at openjdk.java.net
>> Subject: Re: RFR (M) 8223261 "JDK-8189208 followup - remove
>> JDK_GetVersionInfo0 and the supporting code"
>>
>>
>>
>> On 11/13/19 10:50 AM, gerard ziemski wrote:
>>> Hi all,
>>>
>>> Please review this cleanup, where we remove JDK_GetVersionInfo0 and
>>> related code, since we can get build versions directly from within the
>>> VM itself:
>>>
>>> I'm including core-libs and awt in this review because the proposed
>>> fix touches their corresponding files.
>>>
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8223261
>>> webrev: http://cr.openjdk.java.net/~gziemski/8223261_rev1
>>> tests: passes Mach5 tier1,2,3,4,5,6
>>>
>>
>> This is a good clean up.? JDK_GetVersionInfo0 was needed long time ago
>> in particular in HS express support that is no longer applicable.
>>
>> One leftover comment should also be removed.
>>
>> src/hotspot/share/runtime/vm_version.hpp
>>   ? // Gets the jvm_version_info.jvm_version defined in jvm.h
>>
>> otherwise looks good.
>>
>> Mandy

From Sergey.Bylokhov at oracle.com  Thu Nov 14 03:44:05 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 13 Nov 2019 19:44:05 -0800
Subject: RFR (M) 8223261 "JDK-8189208 followup - remove
 JDK_GetVersionInfo0 and the supporting code"
In-Reply-To: <4623455a-2d90-e697-89b3-830d5becf8f9@oracle.com>
References: <4623455a-2d90-e697-89b3-830d5becf8f9@oracle.com>
Message-ID: <52ca300d-c870-a7d4-934d-7e5fcfe77446@oracle.com>

Looks fine.

On 11/13/19 10:50 am, gerard ziemski wrote:
> Hi all,
> 
> Please review this cleanup, where we remove JDK_GetVersionInfo0 and related code, since we can get build versions directly from within the VM itself:
> 
> I'm including core-libs and awt in this review because the proposed fix touches their corresponding files.
> 
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8223261
> webrev: http://cr.openjdk.java.net/~gziemski/8223261_rev1
> tests: passes Mach5 tier1,2,3,4,5,6
> 
> 
> cheers
> 


-- 
Best regards, Sergey.

From mandy.chung at oracle.com  Thu Nov 14 04:57:10 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 13 Nov 2019 20:57:10 -0800
Subject: RFR JDK-8233527: Update Lookup::hasPrivateAccess and
 Lookup::defineClass spec w.r.t. full power lookup
In-Reply-To: <6bb905bf-8803-cc9e-ea28-49da6685a78b@j-kuhn.de>
References: <081f506c-62a9-dd98-8b62-04690f4cba14@oracle.com>
 <083da65f-e1a5-4f30-9d15-cf69df1918ec@j-kuhn.de>
 <94a4b52c-b47d-f861-54d5-6d661991b67b@oracle.com>
 <6bb905bf-8803-cc9e-ea28-49da6685a78b@j-kuhn.de>
Message-ID: <97aefa43-ada4-a0a6-df3b-eb5c350a8a0f@oracle.com>



On 11/13/19 11:45 AM, Johannes Kuhn wrote:
>> The two bullets about the caller lookup object must have MODULE and 
>> PRIVATE are important explanation for it to require such access.
>>
>> Maybe I can add a bullet to say "The caller lookup object must have 
>> full privilege access" and then move those two bullets as sub-bullets 
>> under it.
>>
>> What do you think?
> This is a good idea, because full privilege access is a new concept, 
> and should be mentioned at the places where it is used. 

Updated in place:

http://cr.openjdk.java.net/~mchung/jdk14/8233527/webrev.02/
http://cr.openjdk.java.net/~mchung/jdk14/8233527/specdiff/

Mandy

From kiran.sidhartha.ravikumar at oracle.com  Thu Nov 14 09:47:55 2019
From: kiran.sidhartha.ravikumar at oracle.com (Kiran Ravikumar)
Date: Thu, 14 Nov 2019 09:47:55 +0000
Subject: RFR 8233187: Return Empty List if 0 Copies Requested in Collections
 nCopies
Message-ID: <963f1eed-2b92-f00a-9a37-4acfc71d9939@oracle.com>

Hi Guys,


Please review the following optimization to nCopies method to return 
empty list and to avoid instantiating an empty CopiesList object.


JBS link : https://bugs.openjdk.java.net/browse/JDK-8233187


Patch:

diff -r f279d8a9bb78 src/java.base/share/classes/java/util/Collections.java
--- a/src/java.base/share/classes/java/util/Collections.java Wed Nov 13 
11:27:50 2019 +0000
+++ b/src/java.base/share/classes/java/util/Collections.java Thu Nov 14 
09:37:56 2019 +0000
@@ -5105,6 +5105,8 @@
 ???? public static  List nCopies(int n, T o) {
 ???????? if (n < 0)
 ???????????? throw new IllegalArgumentException("List length = " + n);
+??????? if (n == 0)
+??????????? return Collections.emptyList();
 ???????? return new CopiesList<>(n, o);
 ???? }


Thanks,

Kiran


From Alan.Bateman at oracle.com  Thu Nov 14 10:33:57 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 14 Nov 2019 10:33:57 +0000
Subject: RFR JDK-8233527: Update Lookup::hasPrivateAccess and
 Lookup::defineClass spec w.r.t. full power lookup
In-Reply-To: <97aefa43-ada4-a0a6-df3b-eb5c350a8a0f@oracle.com>
References: <081f506c-62a9-dd98-8b62-04690f4cba14@oracle.com>
 <083da65f-e1a5-4f30-9d15-cf69df1918ec@j-kuhn.de>
 <94a4b52c-b47d-f861-54d5-6d661991b67b@oracle.com>
 <6bb905bf-8803-cc9e-ea28-49da6685a78b@j-kuhn.de>
 <97aefa43-ada4-a0a6-df3b-eb5c350a8a0f@oracle.com>
Message-ID: <61d471dd-42ac-02cb-75e2-de63dadc3763@oracle.com>

On 14/11/2019 04:57, Mandy Chung wrote:
>
> Updated in place:
>
> http://cr.openjdk.java.net/~mchung/jdk14/8233527/webrev.02/
> http://cr.openjdk.java.net/~mchung/jdk14/8233527/specdiff/
The addition of hasFullPrivilegeAccess looks okay and probably the right 
thing to do.

For the @deprecated message on the old method it might be simpler to say 
that the method was originally designed to test PRIVATE access but has 
since changed to test full privilege access. I think that would be 
better than saying anything about "Java SE 14".

-Alan



From gerard.ziemski at oracle.com  Thu Nov 14 15:10:14 2019
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Thu, 14 Nov 2019 09:10:14 -0600
Subject: RFR (M) 8223261 "JDK-8189208 followup - remove
 JDK_GetVersionInfo0 and the supporting code"
In-Reply-To: 
References: <4623455a-2d90-e697-89b3-830d5becf8f9@oracle.com>
 
Message-ID: 

Thank you for the review, will remove the comment and updated the 
webrev, but only after Christop Langer gets his fix in - I'm going to 
wait for him to check in first.


cheers

On 11/13/19 1:29 PM, Mandy Chung wrote:
>
>
> On 11/13/19 10:50 AM, gerard ziemski wrote:
>> Hi all,
>>
>> Please review this cleanup, where we remove JDK_GetVersionInfo0 and 
>> related code, since we can get build versions directly from within 
>> the VM itself:
>>
>> I'm including core-libs and awt in this review because the proposed 
>> fix touches their corresponding files.
>>
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8223261
>> webrev: http://cr.openjdk.java.net/~gziemski/8223261_rev1
>> tests: passes Mach5 tier1,2,3,4,5,6
>>
>
> This is a good clean up.? JDK_GetVersionInfo0 was needed long time ago 
> in particular in HS express support that is no longer applicable.
>
> One leftover comment should also be removed.
>
> src/hotspot/share/runtime/vm_version.hpp
> ? // Gets the jvm_version_info.jvm_version defined in jvm.h
>
> otherwise looks good.
>
> Mandy


From gerard.ziemski at oracle.com  Thu Nov 14 15:11:16 2019
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Thu, 14 Nov 2019 09:11:16 -0600
Subject: RFR (M) 8223261 "JDK-8189208 followup - remove
 JDK_GetVersionInfo0 and the supporting code"
In-Reply-To: 
References: <4623455a-2d90-e697-89b3-830d5becf8f9@oracle.com>
 
 
Message-ID: <59bfddd2-34ec-5fe9-1f01-481fb749af5d@oracle.com>

Thank you for the review.

I'm happy to wait for your fix to go in first - this will make my fix 
smaller.


cheers

On 11/13/19 2:05 PM, Langer, Christoph wrote:
> Hi Gerard,
>
> generally it looks like a nice cleanup.
>
> I've got a patch prepared though, which I was planning on posting tomorrow. It is about cleanup for the canonicalize function in libjava. I wanted to use jdk_util.h for the function prototype. I had not yet filed a bug but here is what I have:
> http://cr.openjdk.java.net/~clanger/webrevs/cleanup-canonicalize/
>
> So maybe you could refrain from removing jdk_util.h or maybe you can hold off submitting your change until my cleanup is reviewed?
>
> I'll create a bug and post an official review thread tomorrow...
>
> Thanks
> Christoph
>
>> -----Original Message-----
>> From: hotspot-dev  On Behalf Of
>> Mandy Chung
>> Sent: Mittwoch, 13. November 2019 20:30
>> To: gerard ziemski 
>> Cc: awt-dev at openjdk.java.net; hotspot-dev developers > dev at openjdk.java.net>; core-libs-dev at openjdk.java.net
>> Subject: Re: RFR (M) 8223261 "JDK-8189208 followup - remove
>> JDK_GetVersionInfo0 and the supporting code"
>>
>>
>>
>> On 11/13/19 10:50 AM, gerard ziemski wrote:
>>> Hi all,
>>>
>>> Please review this cleanup, where we remove JDK_GetVersionInfo0 and
>>> related code, since we can get build versions directly from within the
>>> VM itself:
>>>
>>> I'm including core-libs and awt in this review because the proposed
>>> fix touches their corresponding files.
>>>
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8223261
>>> webrev: http://cr.openjdk.java.net/~gziemski/8223261_rev1
>>> tests: passes Mach5 tier1,2,3,4,5,6
>>>
>> This is a good clean up.? JDK_GetVersionInfo0 was needed long time ago
>> in particular in HS express support that is no longer applicable.
>>
>> One leftover comment should also be removed.
>>
>> src/hotspot/share/runtime/vm_version.hpp
>>   ? // Gets the jvm_version_info.jvm_version defined in jvm.h
>>
>> otherwise looks good.
>>
>> Mandy


From gerard.ziemski at oracle.com  Thu Nov 14 15:13:41 2019
From: gerard.ziemski at oracle.com (gerard ziemski)
Date: Thu, 14 Nov 2019 09:13:41 -0600
Subject: RFR (M) 8223261 "JDK-8189208 followup - remove
 JDK_GetVersionInfo0 and the supporting code"
In-Reply-To: 
References: <4623455a-2d90-e697-89b3-830d5becf8f9@oracle.com>
 
 
 
Message-ID: <306d4073-7d64-d807-b670-52126462e81c@oracle.com>

Thank you for the review.

I'm definitively going to wait for Christoph to check in his fix first.

I tried in fact to leave jdk_util.c/.h files in empty without removing 
them from the repo, and even though Mac/Linux were OK with that, 
Solaris/Windows were not.


cheers

On 11/13/19 9:21 PM, David Holmes wrote:
> Hi Gerard,
>
> On 14/11/2019 6:05 am, Langer, Christoph wrote:
>> Hi Gerard,
>>
>> generally it looks like a nice cleanup.
>>
>> I've got a patch prepared though, which I was planning on posting 
>> tomorrow. It is about cleanup for the canonicalize function in 
>> libjava. I wanted to use jdk_util.h for the function prototype. I had 
>> not yet filed a bug but here is what I have:
>> http://cr.openjdk.java.net/~clanger/webrevs/cleanup-canonicalize/
>>
>> So maybe you could refrain from removing jdk_util.h or maybe you can 
>> hold off submitting your change until my cleanup is reviewed?
>
> I'd also suggest not deleting jdk_util.h. It seems very odd to me to 
> have jdk_util_md.h with no shared jdk_util.h. If you keep jdk_util.h 
> then you don't need to touch a number of the files.
>
> Otherwise this looks like a good cleanup.
>
> Thanks,
> David
> -----
>
>> I'll create a bug and post an official review thread tomorrow...
>>
>> Thanks
>> Christoph
>>
>>> -----Original Message-----
>>> From: hotspot-dev  On Behalf Of
>>> Mandy Chung
>>> Sent: Mittwoch, 13. November 2019 20:30
>>> To: gerard ziemski 
>>> Cc: awt-dev at openjdk.java.net; hotspot-dev developers >> dev at openjdk.java.net>; core-libs-dev at openjdk.java.net
>>> Subject: Re: RFR (M) 8223261 "JDK-8189208 followup - remove
>>> JDK_GetVersionInfo0 and the supporting code"
>>>
>>>
>>>
>>> On 11/13/19 10:50 AM, gerard ziemski wrote:
>>>> Hi all,
>>>>
>>>> Please review this cleanup, where we remove JDK_GetVersionInfo0 and
>>>> related code, since we can get build versions directly from within the
>>>> VM itself:
>>>>
>>>> I'm including core-libs and awt in this review because the proposed
>>>> fix touches their corresponding files.
>>>>
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8223261
>>>> webrev: http://cr.openjdk.java.net/~gziemski/8223261_rev1
>>>> tests: passes Mach5 tier1,2,3,4,5,6
>>>>
>>>
>>> This is a good clean up.? JDK_GetVersionInfo0 was needed long time ago
>>> in particular in HS express support that is no longer applicable.
>>>
>>> One leftover comment should also be removed.
>>>
>>> src/hotspot/share/runtime/vm_version.hpp
>>> ? ? // Gets the jvm_version_info.jvm_version defined in jvm.h
>>>
>>> otherwise looks good.
>>>
>>> Mandy


From christoph.langer at sap.com  Thu Nov 14 15:23:32 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 14 Nov 2019 15:23:32 +0000
Subject: RFR: 8234089: (zipfs) Remove classes JarFileSystemProvider and
 JarFileSystem
Message-ID: 

Hi,

after exchanging some direct mails with Lance, I came to the conclusion that the current behavior to ignore file system property "multi-release" when "releaseVersion" is explicitly set to null is the right thing to do. So I updated the webrev to reinstate this functionality and added explicit comments as well as augmenting MultiReleaseJarTest.java a little bit to test that "multi-release" is ignored in the right places.

This is the new webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234089.1/

Best regards
Christoph


From: Langer, Christoph
Sent: Mittwoch, 13. November 2019 17:42
To: core-libs-dev at openjdk.java.net; nio-dev 
Subject: RFR: 8234089: (zipfs) Remove classes JarFileSystemProvider and JarFileSystem

Hi,

can I please get reviews for this cleanup change in zipfs.

Bug: https://bugs.openjdk.java.net/browse/JDK-8234089
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234089.0/

I figured that JarFileSystemProvider is completely obsolete (please correct me if I'm wrong) and the reasons for having a class JarFileSystem that extends ZipFileSystems are very little in my opinion. I think maintainability is better when the few implementation details of multi release jars live in ZipFileSystem as well. It saves some code. The only possible drawback is that ZipFileSystem:: getInode would have an additional call to a lookup function, that usually is an identity transformation. I would hope however, that runtime impact is negligible.

I also fix a small bug when property "releaseVersion" is set to null in the env map and multi-release contains a value. In the current implementation it would not consider the "multi-release" value and treat the mr jar as the current runtime version. I had to do a small fix in MultiReleaseJarTest.java to make sure the properties list is cleared in every case.

The jdk/nio/zipfs tests run well after my change.

Thanks
Christoph


From lance.andersen at oracle.com  Thu Nov 14 15:27:22 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 14 Nov 2019 10:27:22 -0500
Subject: RFR(XS): 8234011: (zipfs) Memory leak in
 ZipFileSystem.releaseDeflater()
In-Reply-To: 
References: <1573658564822.16574@amazon.de>
 
 <45B01685-8D87-4171-BD84-778659680C67@oracle.com>
 
Message-ID: <69AB1167-0598-4B51-9A18-31BF0F6A9701@oracle.com>

Hi Volker,

> On Nov 14, 2019, at 8:53 AM, Volker Simonis  wrote:
> 
> On 13.11.19 18:54, Lance Andersen wrote:
>> Hi Volker,
>> Thank you for doing this.
>> As Christoph mentioned,  you can just do Path.of() and create the file in the work directory for the test.
> 
> Done.
> 
>> If possible, I would use TestNG as that is consistent with the vast majority of the tests.
>> 
> 
> I don't particularly like to nest one test harness within another one :)
> But seriously, I think using JUnit or TestNG makes sens if you write a whole test suit which uses the features of such a test harness (e.g. tear up, tear down, etc.)

Well you could use @AfterMethod or @AfterClass to clean up files etc? ;-)
> But for small trivial tests I really prefer to use plain JTreg. This also has the big advantage that is becomes trivial to run such a test stand-alone which may come handy if you have to debug it.
Easy enough to add a main method to call your test method (there are some testng tests I have seen in the workspace that do that)
> 
> So if you don't insist, I'll prefer to leave the test as it is.

While I would prefer it for new tests, I am not insisting you need to change the test?.. ;-)
> 
>> I also believe the rest of the comments below are worth addressing.
> 
> Besides that, I've addressed all the other points mentioned by Christoph. Please find the new webrev at:
> 
> http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011.v1/

line 55 you can remove the creation of the HashMap

line 73, do you really need the equals check seeing you do not do anything?

I am not sure throwing a SkippedException is correct,  I would probably throw a RuntimeException

Best
Lance
> 
> Thank you and best regards,
> Volker
> 
>> Thank you again for the fix
>> Best
>> Lance
>>> On Nov 13, 2019, at 11:26 AM, Langer, Christoph > wrote:
>>> 
>>> Hi Volker,
>>> 
>>> good catch in ZipFileSystem ?? The fix is the right thing to do.
>>> 
>>> I have a few remarks to the test, though:
>>> 
>>> Line 52, initialization of the File object: I think you should just do Path zipFile = Paths.get("file.zip"); When the test is run in the jtreg framework, it's running in its own scratch directory, so no need to use java.io.tmpdir. You can also leave cleanup to jtreg and don't need to delete the file in the end (in the finally block). However, you should probably check whether the file exists in the beginning and delete it in that case.
>>> 
>>> Line 55ff: You don't need to use this URI thing any more. You can simply do: try (FileSystem fs = FileSystems.newFileSystem(zipFile, Map.of("create", true))) { (line 58).
>>> 
>>> Line 61/62: You're using a Vector, wow ?? You should rather use ArrayList, I think...
>>> 
>>> Line 85: This should rather be:
>>>                    @SuppressWarnings("unchecked")
>>>                    int inflater_count = ((List)inflaters.get(fs)).size();
>>> Same for line 89.
>>> 
>>> Line 93 (Catch clause): I think we should fail in that case, too. Otherwise, if the implementation would change, the test could run unnoticed for years, testing basically nothing...
>>> 
>>> Best regards,
>>> Christoph
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: core-libs-dev > On Behalf
>>>> Of Simonis, Volker
>>>> Sent: Mittwoch, 13. November 2019 16:23
>>>> To: core-libs-dev at openjdk.java.net 
>>>> Subject: RFR(XS): 8234011: (zipfs) Memory leak in
>>>> ZipFileSystem.releaseDeflater()
>>>> 
>>>> Hi,
>>>> 
>>>> can I please get a review for this trivial fix of an old copy-and-paste error:
>>>> 
>>>> http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011/
>>>> https://bugs.openjdk.java.net/browse/JDK-8234011
>>>> 
>>>> ZipFileSystem caches MAX_FLATER (currently 20) Inflater/Deflater objects.
>>>> However the logic for reusing Deflaters is wrong because it references the
>>>> Inflater List when checking against the number of already cached objects.
>>>> This seems like a day-one copy and paste error.
>>>> 
>>>> Notice that this issue is not as critical as it appears, because retaining of
>>>> additional Deflaters only happens when more than MAX_FLATER are used
>>>> and released concurrently. I.e. the maximum number of cached Deflaters is
>>>> the maximal number of Deflaters that are released while no new Deflater is
>>>> requested. In practice this is usually still a small number, less than
>>>> MAX_FLATERS. Nevertheless we can easily construct an example which
>>>> demonstrates the memory leak (see the JTRegtest in the patch) and because
>>>> the fix is trivial we should really fix this.
>>>> 
>>>> Thank you and best regards,
>>>> Volker
>>>> 
>>>> 
>>>> 
>>>> Amazon Development Center Germany GmbH
>>>> Krausenstr. 38
>>>> 10117 Berlin
>>>> Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
>>>> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
>>>> Sitz: Berlin
>>>> Ust-ID: DE 289 237 879
>>>> 
>>>> 
>>> 
>> 
>> 
>> 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 
> 
> 
> 
> 
> Amazon Development Center Germany GmbH
> Krausenstr. 38
> 10117 Berlin
> Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
> Sitz: Berlin
> Ust-ID: DE 289 237 879
> 
> 

 
  
 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 Nov 14 15:34:05 2019
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 14 Nov 2019 07:34:05 -0800
Subject: RFR 8233187: Return Empty List if 0 Copies Requested in
 Collections nCopies
In-Reply-To: <963f1eed-2b92-f00a-9a37-4acfc71d9939@oracle.com>
References: <963f1eed-2b92-f00a-9a37-4acfc71d9939@oracle.com>
Message-ID: 

Hi Kiran, pleased to meet you

Code like this should be written so that the common case has only one
boolean test.

On Thu, Nov 14, 2019 at 1:50 AM Kiran Ravikumar <
kiran.sidhartha.ravikumar at oracle.com> wrote:

> Hi Guys,
>
>
> Please review the following optimization to nCopies method to return
> empty list and to avoid instantiating an empty CopiesList object.
>
>
> JBS link : https://bugs.openjdk.java.net/browse/JDK-8233187
>
>
> Patch:
>
> diff -r f279d8a9bb78 src/java.base/share/classes/java/util/Collections.java
> --- a/src/java.base/share/classes/java/util/Collections.java Wed Nov 13
> 11:27:50 2019 +0000
> +++ b/src/java.base/share/classes/java/util/Collections.java Thu Nov 14
> 09:37:56 2019 +0000
> @@ -5105,6 +5105,8 @@
>       public static  List nCopies(int n, T o) {
>           if (n < 0)
>               throw new IllegalArgumentException("List length = " + n);
> +        if (n == 0)
> +            return Collections.emptyList();
>           return new CopiesList<>(n, o);
>       }
>
>
> Thanks,
>
> Kiran
>
>

From christoph.langer at sap.com  Thu Nov 14 15:37:21 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 14 Nov 2019 15:37:21 +0000
Subject: RFR: 8234185: Cleanup usage of canonicalize function between libjava, 
 hotspot and libinstrument
Message-ID: 

Hi,

please review this cleanup change regarding function "canonicalize" of libjava.

Bug: https://bugs.openjdk.java.net/browse/JDK-8234185
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234185.0/


The goal is to cleanup how this function is defined and used. One thing is, that there was an unnecessary wrapper function "Canonicalize" in jni_util.c. It wrapped the call to "canonicalize". We can get rid of this wrapper. Unfortunately, it is not possible to just export "canonicalize" since this will conflict with a method signature from the math library, at least on modern Linuxes. So I decided to call the method JDK_Canonicalize and will correctly define it in jdk_util.h which can be included everywhere.



Hotspot's classloader.cpp will dynamically resolve this method, so I add a local declaration of the function pointer in there.



This change shall be predecessor of JDK-8223261, where a review was already started here: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-November/063398.html

Thanks
Christoph


From jai.forums2013 at gmail.com  Thu Nov 14 15:40:03 2019
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Thu, 14 Nov 2019 21:10:03 +0530
Subject: ZipFileSystem and the impact of JDK-8031748 on ordering of
 MANIFEST files in the created jars
In-Reply-To: <9766726a-3c83-a1e8-5caf-39ef9ce9842a@gmail.com>
References: <9766726a-3c83-a1e8-5caf-39ef9ce9842a@gmail.com>
Message-ID: <2ab1ed01-8d9a-9175-cf9b-51e6f81b212e@gmail.com>

Adding core-libs-dev, since this also involves java.util.jar APIs.

-Jaikiran

On 14/11/19 8:47 PM, Jaikiran Pai wrote:
> Please consider the code listed at the end of this mail. What it does is
> uses ZipFileSystem to create 2 jar files with identical content. foo.jar
> and bar.jar. Both these jar files contain a (random) text file and a
> META-INF/MANIFEST.MF.
>
> In case of foo.jar, the text file gets created first and then the
> META-INF/MANIFEST.MF and the filesystem finally gets closed
>
> In case of bar.jar, the META-INF/MANIFEST.MF gets created first and then
> the text file and the filesystem finally gets closed.
>
> Once both these (identical) jars are created, the JarInputStream class
> is then used to open these jars and get hold of the Manifest file. What
> results is - the JarInputStream returns a null Manifest for foo.jar (the
> one where the META-INF/MANIFEST.MF wasn't created first), whereas the
> JarInputStream for bar.jar rightly finds the Manifest and its correct
> content.
>
> First of all it's a surprise that the JarInputStream seemingly "loses"
> the Manifest if the META-INF/MANIFEST.MF wasn't created first. But given
> that it's already a known issue reported in JBS
> https://bugs.openjdk.java.net/browse/JDK-8031748, at least we (the
> libraries that create jar files know what to do or how to deal with it).
>
> However, when using something like a zipfs FileSystem, where the code
> which deals with writing out content to the filesystem using
> standard/basic java.nio.file.Path and outputstreams, its hard to keep
> track (within the libraries or user code) of the order in which the
> files get written out. So is there any way this (undocumented)
> requirement be implemented as an internal detail within the zipfs
> filesystem implementation, such that it orders the META-INF/MANIFEST.MF
> entry correctly? Or is there a way JarInputStream itself can be fixed to
> not mandate this requirement?
>
> This issue was reported in the Quarkus project
> https://github.com/quarkusio/quarkus/issues/5399 and a workaround has
> been proposed, but given how involved the code is (unrelated to this
> issue), it's going to become more and more difficult to manage this
> ordering.
>
>
> Code reproducing this issue follows:
>
> import java.io.*;
> import java.nio.file.*;
> import java.util.*;
> import java.util.jar.*;
> import java.net.*;
> import static java.nio.file.StandardOpenOption.*;
>
> public class ZipFSJar {
> ??? public static void main(final String[] args) throws Exception {
> ??? ??? final Map options =
> Collections.singletonMap("create", "true");
> ??? ??? final Path jarPath = Paths.get("foo.jar");
> ??? ??? try (final FileSystem zipFs =
> FileSystems.newFileSystem(URI.create("jar:" + jarPath.toUri()), options)) {
> ??? ??? ??? // first write non-manifest content
> ??? ??? ??? writeTxtFile(zipFs.getPath("foo.txt"));
> ??? ??? ??? // now write manifest
> ??? ??? ??? Files.createDirectories(zipFs.getPath("META-INF"));
> ??? ??????? final Path manifestPath = zipFs.getPath("META-INF",
> "MANIFEST.MF");
> ??? ??? ??? writeManifest(manifestPath, "foo.bar.Baz");
> ??? ??? }
>
> ??? ??? // repeat for bar.jar but with manifest being written out first
> ??? ??? final Path barJar = Paths.get("bar.jar");
> ??? ??? try (final FileSystem zipFs =
> FileSystems.newFileSystem(URI.create("jar:" + barJar.toUri()), options)) {
> ??? ??? ??? Files.createDirectories(zipFs.getPath("META-INF"));
> ??? ??????? final Path manifestPath = zipFs.getPath("META-INF",
> "MANIFEST.MF");
> ??? ??? ??? // first write manifest content
> ??? ??? ??? writeManifest(manifestPath, "foo.bar.Baz");
> ??? ??? ??? // now write text file
> ??? ??? ??? writeTxtFile(zipFs.getPath("foo.txt"));
> ??? ??? }
>
> ??? ??? // now check the jar contents
> ??? ??? final Path[] jars = new Path[] {jarPath, barJar};
> ??? ??? for (final Path p : jars) {
> ??? ??? ??? try (InputStream fileInputStream = new
> FileInputStream(p.toFile());
> ??????????????? final JarInputStream jaris = new
> JarInputStream(fileInputStream);) {
> ??????????? ??? final Manifest manifest = jaris.getManifest();
> ??????????? ??? if (manifest == null) {
> ??????????? ??? ??? System.err.println(p + " is missing the manifest file");
> ??????????? ??? } else {
> ??????????? ??? ??? System.out.println(p + " has the manifest file");
> ??? ??????????? ??? final String mainClass =
> manifest.getMainAttributes().getValue(Attributes.Name.MAIN_CLASS);
> ??? ??????????? ??? if (!"foo.bar.Baz".equals(mainClass)) {
> ??? ??????????? ??? ??? System.err.println("Found unexpected main class
> " + mainClass + " in jar " + p);
> ??? ??????????? ??? }
> ??????????? ??? }
> ??? ??????? }
> ??? ??? }
>
> ??? }
>
> ??? private static void writeTxtFile(final Path filePath) throws
> IOException {
> ??? ??? try (final OutputStream os = Files.newOutputStream(filePath)) {
> ??????????? final byte[] someData = new byte[]{'b', 'c', 'd'};
> ??????????? os.write(someData);
> ??? ??? }
> ??? }
>
> ??? private static void writeManifest(final Path manifestPath, final
> String mainClass) throws IOException {
> ??? ??? try (final OutputStream os = Files.newOutputStream(manifestPath)) {
> ??? ??? ??? final Manifest manifest = new Manifest();
> ??????????? final Attributes attributes = manifest.getMainAttributes();
> ??????? ??? attributes.put(Attributes.Name.MANIFEST_VERSION, "1.0");
> ??? ??????? attributes.put(Attributes.Name.MAIN_CLASS, mainClass);
> ??? ??????? manifest.write(os);
> ??? ??? }
> ??? }
> }
>

From brian.burkhalter at oracle.com  Thu Nov 14 15:42:03 2019
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 14 Nov 2019 07:42:03 -0800
Subject: [ping] 8179320: File.getUsableSpace() returns a negative number on
 very large file system
References: <674F3B84-3737-4F55-8D2B-B1777F91203E@oracle.com>
Message-ID: <8F5DDADA-BF4B-4504-B69D-05FE216D2B9C@oracle.com>



> Begin forwarded message:
> 
> From: Brian Burkhalter 
> Subject: 8179320: File.getUsableSpace() returns a negative number on very large file system
> Date: November 1, 2019 at 5:13:28 PM PDT
> To: Core-Libs-Dev 
> 
> For this issue [1], please review this patch [2] and the corresponding CSR [3].
> 
> Thanks,
> 
> Brian
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8179320
> [2] http://cr.openjdk.java.net/~bpb/8179320/webrev.00/
> [3] https://bugs.openjdk.java.net/browse/JDK-8233426


From mandy.chung at oracle.com  Thu Nov 14 16:04:08 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 14 Nov 2019 08:04:08 -0800
Subject: RFR JDK-8233527: Update Lookup::hasPrivateAccess and
 Lookup::defineClass spec w.r.t. full power lookup
In-Reply-To: <61d471dd-42ac-02cb-75e2-de63dadc3763@oracle.com>
References: <081f506c-62a9-dd98-8b62-04690f4cba14@oracle.com>
 <083da65f-e1a5-4f30-9d15-cf69df1918ec@j-kuhn.de>
 <94a4b52c-b47d-f861-54d5-6d661991b67b@oracle.com>
 <6bb905bf-8803-cc9e-ea28-49da6685a78b@j-kuhn.de>
 <97aefa43-ada4-a0a6-df3b-eb5c350a8a0f@oracle.com>
 <61d471dd-42ac-02cb-75e2-de63dadc3763@oracle.com>
Message-ID: 



On 11/14/19 2:33 AM, Alan Bateman wrote:
> On 14/11/2019 04:57, Mandy Chung wrote:
>>
>> Updated in place:
>>
>> http://cr.openjdk.java.net/~mchung/jdk14/8233527/webrev.02/
>> http://cr.openjdk.java.net/~mchung/jdk14/8233527/specdiff/
> The addition of hasFullPrivilegeAccess looks okay and probably the 
> right thing to do.
>
> For the @deprecated message on the old method it might be simpler to 
> say that the method was originally designed to test PRIVATE access but 
> has since changed to test full privilege access. 

It was designed to test full privilege access while private access 
implies full privilege access as a Lookup with private access includes 
module access.

What about:
This method was originally designed to test PRIVATE access as full 
privilege access. Full privilege access necessarily includes module 
access that has since become independent of private access.

Mandy
> I think that would be better than saying anything about "Java SE 14".
>
> -Alan
>
>


From lance.andersen at oracle.com  Thu Nov 14 16:05:29 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 14 Nov 2019 11:05:29 -0500
Subject: ZipFileSystem and the impact of JDK-8031748 on ordering of
 MANIFEST files in the created jars
In-Reply-To: <2ab1ed01-8d9a-9175-cf9b-51e6f81b212e@gmail.com>
References: <9766726a-3c83-a1e8-5caf-39ef9ce9842a@gmail.com>
 <2ab1ed01-8d9a-9175-cf9b-51e6f81b212e@gmail.com>
Message-ID: <1856C8B1-CB9B-45D8-BEFC-340CA66AE476@oracle.com>

Hi Jaikarian,

This issue has been looked at several times over the years (see https://bugs.openjdk.java.net/browse/JDK-5046178  as an example) WRT JarInpuStream/MANIFEST

There is an existing Zip FS enhancement request, https://bugs.openjdk.java.net/browse/JDK-8211917.  

Best
Lance

> On Nov 14, 2019, at 10:40 AM, Jaikiran Pai  wrote:
> 
> Adding core-libs-dev, since this also involves java.util.jar APIs.
> 
> -Jaikiran
> 
> On 14/11/19 8:47 PM, Jaikiran Pai wrote:
>> Please consider the code listed at the end of this mail. What it does is
>> uses ZipFileSystem to create 2 jar files with identical content. foo.jar
>> and bar.jar. Both these jar files contain a (random) text file and a
>> META-INF/MANIFEST.MF.
>> 
>> In case of foo.jar, the text file gets created first and then the
>> META-INF/MANIFEST.MF and the filesystem finally gets closed
>> 
>> In case of bar.jar, the META-INF/MANIFEST.MF gets created first and then
>> the text file and the filesystem finally gets closed.
>> 
>> Once both these (identical) jars are created, the JarInputStream class
>> is then used to open these jars and get hold of the Manifest file. What
>> results is - the JarInputStream returns a null Manifest for foo.jar (the
>> one where the META-INF/MANIFEST.MF wasn't created first), whereas the
>> JarInputStream for bar.jar rightly finds the Manifest and its correct
>> content.
>> 
>> First of all it's a surprise that the JarInputStream seemingly "loses"
>> the Manifest if the META-INF/MANIFEST.MF wasn't created first. But given
>> that it's already a known issue reported in JBS
>> https://bugs.openjdk.java.net/browse/JDK-8031748, at least we (the
>> libraries that create jar files know what to do or how to deal with it).
>> 
>> However, when using something like a zipfs FileSystem, where the code
>> which deals with writing out content to the filesystem using
>> standard/basic java.nio.file.Path and outputstreams, its hard to keep
>> track (within the libraries or user code) of the order in which the
>> files get written out. So is there any way this (undocumented)
>> requirement be implemented as an internal detail within the zipfs
>> filesystem implementation, such that it orders the META-INF/MANIFEST.MF
>> entry correctly? Or is there a way JarInputStream itself can be fixed to
>> not mandate this requirement?
>> 
>> This issue was reported in the Quarkus project
>> https://github.com/quarkusio/quarkus/issues/5399 and a workaround has
>> been proposed, but given how involved the code is (unrelated to this
>> issue), it's going to become more and more difficult to manage this
>> ordering.
>> 
>> 
>> Code reproducing this issue follows:
>> 
>> import java.io.*;
>> import java.nio.file.*;
>> import java.util.*;
>> import java.util.jar.*;
>> import java.net.*;
>> import static java.nio.file.StandardOpenOption.*;
>> 
>> public class ZipFSJar {
>>     public static void main(final String[] args) throws Exception {
>>         final Map options =
>> Collections.singletonMap("create", "true");
>>         final Path jarPath = Paths.get("foo.jar");
>>         try (final FileSystem zipFs =
>> FileSystems.newFileSystem(URI.create("jar:" + jarPath.toUri()), options)) {
>>             // first write non-manifest content
>>             writeTxtFile(zipFs.getPath("foo.txt"));
>>             // now write manifest
>>             Files.createDirectories(zipFs.getPath("META-INF"));
>>             final Path manifestPath = zipFs.getPath("META-INF",
>> "MANIFEST.MF");
>>             writeManifest(manifestPath, "foo.bar.Baz");
>>         }
>> 
>>         // repeat for bar.jar but with manifest being written out first
>>         final Path barJar = Paths.get("bar.jar");
>>         try (final FileSystem zipFs =
>> FileSystems.newFileSystem(URI.create("jar:" + barJar.toUri()), options)) {
>>             Files.createDirectories(zipFs.getPath("META-INF"));
>>             final Path manifestPath = zipFs.getPath("META-INF",
>> "MANIFEST.MF");
>>             // first write manifest content
>>             writeManifest(manifestPath, "foo.bar.Baz");
>>             // now write text file
>>             writeTxtFile(zipFs.getPath("foo.txt"));
>>         }
>> 
>>         // now check the jar contents
>>         final Path[] jars = new Path[] {jarPath, barJar};
>>         for (final Path p : jars) {
>>             try (InputStream fileInputStream = new
>> FileInputStream(p.toFile());
>>                 final JarInputStream jaris = new
>> JarInputStream(fileInputStream);) {
>>                 final Manifest manifest = jaris.getManifest();
>>                 if (manifest == null) {
>>                     System.err.println(p + " is missing the manifest file");
>>                 } else {
>>                     System.out.println(p + " has the manifest file");
>>                     final String mainClass =
>> manifest.getMainAttributes().getValue(Attributes.Name.MAIN_CLASS);
>>                     if (!"foo.bar.Baz".equals(mainClass)) {
>>                         System.err.println("Found unexpected main class
>> " + mainClass + " in jar " + p);
>>                     }
>>                 }
>>             }
>>         }
>> 
>>     }
>> 
>>     private static void writeTxtFile(final Path filePath) throws
>> IOException {
>>         try (final OutputStream os = Files.newOutputStream(filePath)) {
>>             final byte[] someData = new byte[]{'b', 'c', 'd'};
>>             os.write(someData);
>>         }
>>     }
>> 
>>     private static void writeManifest(final Path manifestPath, final
>> String mainClass) throws IOException {
>>         try (final OutputStream os = Files.newOutputStream(manifestPath)) {
>>             final Manifest manifest = new Manifest();
>>             final Attributes attributes = manifest.getMainAttributes();
>>             attributes.put(Attributes.Name.MANIFEST_VERSION, "1.0");
>>             attributes.put(Attributes.Name.MAIN_CLASS, mainClass);
>>             manifest.write(os);
>>         }
>>     }
>> }
>> 

 
  
 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 mandy.chung at oracle.com  Thu Nov 14 16:22:36 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 14 Nov 2019 08:22:36 -0800
Subject: RFR 8233272 : The Class.forName specification should be updated
 to match the long-standing implementation with respect to class linking
In-Reply-To: <79528f01-3418-eb51-4dbd-897e4e97f853@oracle.com>
References: <79528f01-3418-eb51-4dbd-897e4e97f853@oracle.com>
Message-ID: <7ddee581-c68b-bf40-22db-871205b8ca1b@oracle.com>



On 11/13/19 10:37 AM, Brent Christian wrote:
> Hi,
>
> Recently, the 2-arg and 3-arg Class.forName() methods were updated[1] 
> to perform class linking, per the specification. However this change 
> had to be reverted[2].
>
> Instead, let's clarify the Class.forName() spec not to guarantee 
> linking (outside the case of also performing initialization, of 
> course).? This is the long-standing behavior.
>
> I also have a test of the non-linking behavior; it's based on the test 
> case[3] for JDK-8231924.? It fails as of 14b14 (8212117) and passes as 
> of 14b22 (8233091).
>
> Please review my webrev:
> http://cr.openjdk.java.net/~bchristi/8233272/webrev-02/
>
> If the wording looks good, I'll fill in the Specification for the 
> CSR[4] I've started.

The spec change looks fine.

As for the test, I expect that it simply calls Class.forName("Provider", 
false, ucl) and then should succeed.

Then calling Class.forName("Provider", true, ucl) should fail with an 
error (I think it's EIIE with NCDFE?).? This way it verifies that 
initialization/linking does cause NCDFE during verification while 
Class.forName does not do linking if initialize=false.

Mandy


From lance.andersen at oracle.com  Thu Nov 14 16:38:21 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 14 Nov 2019 11:38:21 -0500
Subject: RFR(XS): 8234011: (zipfs) Memory leak in
 ZipFileSystem.releaseDeflater()
In-Reply-To: 
References: <1573658564822.16574@amazon.de>
 
 <45B01685-8D87-4171-BD84-778659680C67@oracle.com>
 
 <69AB1167-0598-4B51-9A18-31BF0F6A9701@oracle.com>
 
Message-ID: 


> On Nov 14, 2019, at 11:27 AM, Volker Simonis  wrote:
> 
> On 14.11.19 16:27, Lance Andersen wrote:
>> Hi Volker,
>>> On Nov 14, 2019, at 8:53 AM, Volker Simonis  >> wrote:
>>> 
>>> On 13.11.19 18:54, Lance Andersen wrote:
>>>> Hi Volker,
>>>> Thank you for doing this.
>>>> As Christoph mentioned,  you can just do Path.of() and create the file in the work directory for the test.
>>> 
>>> Done.
>>> 
>>>> If possible, I would use TestNG as that is consistent with the vast majority of the tests.
>>>> 
>>> 
>>> I don't particularly like to nest one test harness within another one :)
>>> But seriously, I think using JUnit or TestNG makes sens if you write a whole test suit which uses the features of such a test harness (e.g. tear up, tear down, etc.)
>> Well you could use @AfterMethod or @AfterClass to clean up files etc? ;-)
>>> But for small trivial tests I really prefer to use plain JTreg. This also has the big advantage that is becomes trivial to run such a test stand-alone which may come handy if you have to debug it.
>> Easy enough to add a main method to call your test method (there are some testng tests I have seen in the workspace that do that)
>>> 
>>> So if you don't insist, I'll prefer to leave the test as it is.
>> While I would prefer it for new tests, I am not insisting you need to change the test?.. ;-)
> 
> OK, thanks. I might consider using it in the future :)
> 
>>> 
>>>> I also believe the rest of the comments below are worth addressing.
>>> 
>>> Besides that, I've addressed all the other points mentioned by Christoph. Please find the new webrev at:
>>> 
>>> http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011.v1/ 
>> line 55 you can remove the creation of the HashMap
> 
> Good catch! Removed.
> 
>> line 73, do you really need the equals check seeing you do not do anything?
>> 
> 
> Removed. It was a leftover of local testing.
> 
>> I am not sure throwing a SkippedException is correct,  I would probably throw a RuntimeException
> 
> As I wrote in the answer to Christoph, this is a relatively new feature of JTreg [1] which I think was introduced for exactly such kind of situations where a tests detects at runtime only, that for some reasons he can't test the issue he was supposed to test. More and more tests are adapting it now [2]. The SkippedException will be handled specially by JTreg and let the test pass, but with status "Passed.Skipped" (plus exception message) instead of just "Passed" (plis "Execution successful").
> 
> Here's the next webrev:
> 
> http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011.v2/ 

Thank you for the updates.  I am still a bit skeptical of the use of SkippedException here as you would never see the test is no longer passing due to an implementation change unless you are specifically looking for it.

That being said,  if others who have more experience with using this Exception in a similar scenario are good, then I am good.

So once we get a couple of other views on this from others with a thumbs up for using SkippedException here, we are good to go :-)

Best
Lance

> 
> Thanks,
> Volker
> 
> [1] https://openjdk.java.net/jtreg/faq.html#what-if-a-test-does-not-apply-in-a-given-situation 
> [2] https://bugs.openjdk.java.net/browse/JDK-8208655 
> 
>> Best
>> Lance
>>> 
>>> Thank you and best regards,
>>> Volker
>>> 
>>>> Thank you again for the fix
>>>> Best
>>>> Lance
>>>>> On Nov 13, 2019, at 11:26 AM, Langer, Christoph  > >> wrote:
>>>>> 
>>>>> Hi Volker,
>>>>> 
>>>>> good catch in ZipFileSystem ?? The fix is the right thing to do.
>>>>> 
>>>>> I have a few remarks to the test, though:
>>>>> 
>>>>> Line 52, initialization of the File object: I think you should just do Path zipFile = Paths.get("file.zip"); When the test is run in the jtreg framework, it's running in its own scratch directory, so no need to use java.io.tmpdir. You can also leave cleanup to jtreg and don't need to delete the file in the end (in the finally block). However, you should probably check whether the file exists in the beginning and delete it in that case.
>>>>> 
>>>>> Line 55ff: You don't need to use this URI thing any more. You can simply do: try (FileSystem fs = FileSystems.newFileSystem(zipFile, Map.of("create", true))) { (line 58).
>>>>> 
>>>>> Line 61/62: You're using a Vector, wow ?? You should rather use ArrayList, I think...
>>>>> 
>>>>> Line 85: This should rather be:
>>>>>                    @SuppressWarnings("unchecked")
>>>>>                    int inflater_count = ((List)inflaters.get(fs)).size();
>>>>> Same for line 89.
>>>>> 
>>>>> Line 93 (Catch clause): I think we should fail in that case, too. Otherwise, if the implementation would change, the test could run unnoticed for years, testing basically nothing...
>>>>> 
>>>>> Best regards,
>>>>> Christoph
>>>>> 
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: core-libs-dev  > >> On Behalf
>>>>>> Of Simonis, Volker
>>>>>> Sent: Mittwoch, 13. November 2019 16:23
>>>>>> To: core-libs-dev at openjdk.java.net  > >
>>>>>> Subject: RFR(XS): 8234011: (zipfs) Memory leak in
>>>>>> ZipFileSystem.releaseDeflater()
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> can I please get a review for this trivial fix of an old copy-and-paste error:
>>>>>> 
>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011/ 
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8234011 
>>>>>> 
>>>>>> ZipFileSystem caches MAX_FLATER (currently 20) Inflater/Deflater objects.
>>>>>> However the logic for reusing Deflaters is wrong because it references the
>>>>>> Inflater List when checking against the number of already cached objects.
>>>>>> This seems like a day-one copy and paste error.
>>>>>> 
>>>>>> Notice that this issue is not as critical as it appears, because retaining of
>>>>>> additional Deflaters only happens when more than MAX_FLATER are used
>>>>>> and released concurrently. I.e. the maximum number of cached Deflaters is
>>>>>> the maximal number of Deflaters that are released while no new Deflater is
>>>>>> requested. In practice this is usually still a small number, less than
>>>>>> MAX_FLATERS. Nevertheless we can easily construct an example which
>>>>>> demonstrates the memory leak (see the JTRegtest in the patch) and because
>>>>>> the fix is trivial we should really fix this.
>>>>>> 
>>>>>> Thank you and best regards,
>>>>>> Volker
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Amazon Development Center Germany GmbH
>>>>>> Krausenstr. 38
>>>>>> 10117 Berlin
>>>>>> Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
>>>>>> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
>>>>>> Sitz: Berlin
>>>>>> Ust-ID: DE 289 237 879
>>>>>> 
>>>>>> 
>>>>> 
>>>> >
>>>> >>
>>>> >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  > >
>>> 
>>> 
>>> 
>>> 
>>> Amazon Development Center Germany GmbH
>>> Krausenstr. 38
>>> 10117 Berlin
>>> Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
>>> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
>>> Sitz: Berlin
>>> Ust-ID: DE 289 237 879
>>> 
>>> 
>> 
>> 
>> 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 
> 
> 
> 
> 
> Amazon Development Center Germany GmbH
> Krausenstr. 38
> 10117 Berlin
> Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
> Sitz: Berlin
> Ust-ID: DE 289 237 879

 
  
 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  Thu Nov 14 17:24:39 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 14 Nov 2019 17:24:39 +0000
Subject: RFR(XS): 8234011: (zipfs) Memory leak in
 ZipFileSystem.releaseDeflater()
In-Reply-To: 
References: <1573658564822.16574@amazon.de>
 
 <45B01685-8D87-4171-BD84-778659680C67@oracle.com>
 
 <69AB1167-0598-4B51-9A18-31BF0F6A9701@oracle.com>
 
 
Message-ID: 

Hi Volker,

funny, I didn?t get aware of your mails until I now recognized that my mail client moved your mail into the ?Amazon-advertisement-spam? folder of my mailbox. ?? I have to check and modify my filter rules?

Ok, let?s continue the little bike-shed about the test then.

First, thanks for making the adaptions. The test looks better already. I still have a few points:

1. The imports of java.io.File and java.util.HashMap can be removed now.
2. The two try statements in lines 54 and 55 look a bit awkward. I guess you could just use the one try-with-resource from line 55 and put the cleanup in its finally block.
3. Maybe you also want to attempt a Files.deleteIfExists(zipFile); before opening the Zip file system? Otherwise there is a remote possibility that ReleaseDeflaterTest.zip already exists and the test will fail because of this.
4. I?m also not a fan of the SkippedException here. I for myself would probably not get aware of a skip. And if somebody changes the implementation of ZipFileSystem, why shouldn?t he/she/? immediately recognize this and adapt the test in the same change?

Best regards
Christoph




From: Lance Andersen 
Sent: Donnerstag, 14. November 2019 17:38
To: Volker Simonis 
Cc: Langer, Christoph ; Simonis, Volker ; core-libs-dev at openjdk.java.net
Subject: Re: RFR(XS): 8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater()


On Nov 14, 2019, at 11:27 AM, Volker Simonis > wrote:

On 14.11.19 16:27, Lance Andersen wrote:

Hi Volker,

On Nov 14, 2019, at 8:53 AM, Volker Simonis  > wrote:

On 13.11.19 18:54, Lance Andersen wrote:

Hi Volker,
Thank you for doing this.
As Christoph mentioned,  you can just do Path.of() and create the file in the work directory for the test.

Done.


If possible, I would use TestNG as that is consistent with the vast majority of the tests.

I don't particularly like to nest one test harness within another one :)
But seriously, I think using JUnit or TestNG makes sens if you write a whole test suit which uses the features of such a test harness (e.g. tear up, tear down, etc.)
Well you could use @AfterMethod or @AfterClass to clean up files etc? ;-)

But for small trivial tests I really prefer to use plain JTreg. This also has the big advantage that is becomes trivial to run such a test stand-alone which may come handy if you have to debug it.
Easy enough to add a main method to call your test method (there are some testng tests I have seen in the workspace that do that)


So if you don't insist, I'll prefer to leave the test as it is.
While I would prefer it for new tests, I am not insisting you need to change the test?.. ;-)

OK, thanks. I might consider using it in the future :)




I also believe the rest of the comments below are worth addressing.

Besides that, I've addressed all the other points mentioned by Christoph. Please find the new webrev at:

http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011.v1/
line 55 you can remove the creation of the HashMap

Good catch! Removed.


line 73, do you really need the equals check seeing you do not do anything?

Removed. It was a leftover of local testing.


I am not sure throwing a SkippedException is correct,  I would probably throw a RuntimeException

As I wrote in the answer to Christoph, this is a relatively new feature of JTreg [1] which I think was introduced for exactly such kind of situations where a tests detects at runtime only, that for some reasons he can't test the issue he was supposed to test. More and more tests are adapting it now [2]. The SkippedException will be handled specially by JTreg and let the test pass, but with status "Passed.Skipped" (plus exception message) instead of just "Passed" (plis "Execution successful").

Here's the next webrev:

http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011.v2/

Thank you for the updates.  I am still a bit skeptical of the use of SkippedException here as you would never see the test is no longer passing due to an implementation change unless you are specifically looking for it.

That being said,  if others who have more experience with using this Exception in a similar scenario are good, then I am good.

So once we get a couple of other views on this from others with a thumbs up for using SkippedException here, we are good to go :-)

Best
Lance



Thanks,
Volker

[1] https://openjdk.java.net/jtreg/faq.html#what-if-a-test-does-not-apply-in-a-given-situation
[2] https://bugs.openjdk.java.net/browse/JDK-8208655


Best
Lance


Thank you and best regards,
Volker


Thank you again for the fix
Best
Lance

On Nov 13, 2019, at 11:26 AM, Langer, Christoph   > wrote:

Hi Volker,

good catch in ZipFileSystem ?? The fix is the right thing to do.

I have a few remarks to the test, though:

Line 52, initialization of the File object: I think you should just do Path zipFile = Paths.get("file.zip"); When the test is run in the jtreg framework, it's running in its own scratch directory, so no need to use java.io.tmpdir. You can also leave cleanup to jtreg and don't need to delete the file in the end (in the finally block). However, you should probably check whether the file exists in the beginning and delete it in that case.

Line 55ff: You don't need to use this URI thing any more. You can simply do: try (FileSystem fs = FileSystems.newFileSystem(zipFile, Map.of("create", true))) { (line 58).

Line 61/62: You're using a Vector, wow ?? You should rather use ArrayList, I think...

Line 85: This should rather be:
                   @SuppressWarnings("unchecked")
                   int inflater_count = ((List)inflaters.get(fs)).size();
Same for line 89.

Line 93 (Catch clause): I think we should fail in that case, too. Otherwise, if the implementation would change, the test could run unnoticed for years, testing basically nothing...

Best regards,
Christoph



-----Original Message-----
From: core-libs-dev   > On Behalf
Of Simonis, Volker
Sent: Mittwoch, 13. November 2019 16:23
To: core-libs-dev at openjdk.java.net  
Subject: RFR(XS): 8234011: (zipfs) Memory leak in
ZipFileSystem.releaseDeflater()

Hi,

can I please get a review for this trivial fix of an old copy-and-paste error:

http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011/
https://bugs.openjdk.java.net/browse/JDK-8234011

ZipFileSystem caches MAX_FLATER (currently 20) Inflater/Deflater objects.
However the logic for reusing Deflaters is wrong because it references the
Inflater List when checking against the number of already cached objects.
This seems like a day-one copy and paste error.

Notice that this issue is not as critical as it appears, because retaining of
additional Deflaters only happens when more than MAX_FLATER are used
and released concurrently. I.e. the maximum number of cached Deflaters is
the maximal number of Deflaters that are released while no new Deflater is
requested. In practice this is usually still a small number, less than
MAX_FLATERS. Nevertheless we can easily construct an example which
demonstrates the memory leak (see the JTRegtest in the patch) and because
the fix is trivial we should really fix this.

Thank you and best regards,
Volker



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879




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  




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



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 




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879

[cid:image001.gif at 01D59B17.D3955530]

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 simonisv at amazon.com  Thu Nov 14 13:47:52 2019
From: simonisv at amazon.com (Volker Simonis)
Date: Thu, 14 Nov 2019 14:47:52 +0100
Subject: RFR(XS): 8234011: (zipfs) Memory leak in
 ZipFileSystem.releaseDeflater()
In-Reply-To: 
References: <1573658564822.16574@amazon.de>
 
Message-ID: <46493528-ead5-247d-d495-f8f45ee3389f@amazon.com>

On 13.11.19 17:26, Langer, Christoph wrote:
> Hi Volker,
> 
> good catch in ZipFileSystem ?? The fix is the right thing to do.
>

Hi Christoph,

thanks for looking at my fix. I've prepared a new webrev at:

http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011.v1/

Please find my further comments inline..

> I have a few remarks to the test, though:

I knew that this review would be mostly about the test and not about the 
fix itself :)

> 
> Line 52, initialization of the File object: I think you should just do Path zipFile = Paths.get("file.zip"); When the test is run in the jtreg framework, it's running in its own scratch directory, so no need to use java.io.tmpdir. You can also leave cleanup to jtreg and don't need to delete the file in the end (in the finally block). However, you should probably check whether the file exists in the beginning and delete it in that case.
> 

OK, I renamed the temporary zip file ReleaseDeflaterTest.zip and put it 
into the default JTreg scratch directory. I still like to clean up my 
garbage tough :) And it doesn't harm if the file will still exists from 
a previous run.

> Line 55ff: You don't need to use this URI thing any more. You can simply do: try (FileSystem fs = FileSystems.newFileSystem(zipFile, Map.of("create", true))) { (line 58).
> 

Good point. Done.

> Line 61/62: You're using a Vector, wow ?? You should rather use ArrayList, I think...
>

OK, if that makes you happy :)

> Line 85: This should rather be:
>                      @SuppressWarnings("unchecked")
>                      int inflater_count = ((List)inflaters.get(fs)).size();
> Same for line 89.
> 

I don't think we need that. We can't check at runtime if the List is 
really a List and we don't use the list's element type in the 
test anyway. So introducing a cast we don't need and then suppressing 
the warning it provokes seems unnecessary to me. I've changed it to 
List as a compromise, which doesn't produce a warning :)

> Line 93 (Catch clause): I think we should fail in that case, too. Otherwise, if the implementation would change, the test could run unnoticed for years, testing basically nothing...
> 

I was not sure about this either and I didn't wanted to let the test 
fail because of implementation changes in ZipFileSystem (because that's 
actually not an error). I finally think the right way to handle this is 
to throw a SkippedException. This will let the test pass with status 
"Passed.Skipped" instead of "Passed". This pattern was introduced 
recently and more and more tests are adapting it in order to signal that 
they couldn't really test the issue they were supposed to test because 
of whatsoever reason.


Finally, I've also changed the execution type from "@run main/othervm" 
to "@run main" because the test doesn't really require a new VM.

Thank you and best regards,
Volker

> Best regards,
> Christoph
> 
> 
>> -----Original Message-----
>> From: core-libs-dev  On Behalf
>> Of Simonis, Volker
>> Sent: Mittwoch, 13. November 2019 16:23
>> To: core-libs-dev at openjdk.java.net
>> Subject: RFR(XS): 8234011: (zipfs) Memory leak in
>> ZipFileSystem.releaseDeflater()
>>
>> Hi,
>>
>> can I please get a review for this trivial fix of an old copy-and-paste error:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011/
>> https://bugs.openjdk.java.net/browse/JDK-8234011
>>
>> ZipFileSystem caches MAX_FLATER (currently 20) Inflater/Deflater objects.
>> However the logic for reusing Deflaters is wrong because it references the
>> Inflater List when checking against the number of already cached objects.
>> This seems like a day-one copy and paste error.
>>
>> Notice that this issue is not as critical as it appears, because retaining of
>> additional Deflaters only happens when more than MAX_FLATER are used
>> and released concurrently. I.e. the maximum number of cached Deflaters is
>> the maximal number of Deflaters that are released while no new Deflater is
>> requested. In practice this is usually still a small number, less than
>> MAX_FLATERS. Nevertheless we can easily construct an example which
>> demonstrates the memory leak (see the JTRegtest in the patch) and because
>> the fix is trivial we should really fix this.
>>
>> Thank you and best regards,
>> Volker
>>
>>
>>
>> Amazon Development Center Germany GmbH
>> Krausenstr. 38
>> 10117 Berlin
>> Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
>> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
>> Sitz: Berlin
>> Ust-ID: DE 289 237 879
>>
>>
> 




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



From simonisv at amazon.com  Thu Nov 14 13:53:47 2019
From: simonisv at amazon.com (Volker Simonis)
Date: Thu, 14 Nov 2019 14:53:47 +0100
Subject: RFR(XS): 8234011: (zipfs) Memory leak in
 ZipFileSystem.releaseDeflater()
In-Reply-To: <45B01685-8D87-4171-BD84-778659680C67@oracle.com>
References: <1573658564822.16574@amazon.de>
 
 <45B01685-8D87-4171-BD84-778659680C67@oracle.com>
Message-ID: 

On 13.11.19 18:54, Lance Andersen wrote:
> Hi Volker,
> 
> Thank you for doing this.
> 
> As Christoph mentioned, ?you can just do Path.of() and create the file 
> in the work directory for the test.
> 

Done.

> If possible, I would use TestNG as that is consistent with the vast 
> majority of the tests.
>

I don't particularly like to nest one test harness within another one :)
But seriously, I think using JUnit or TestNG makes sens if you write a 
whole test suit which uses the features of such a test harness (e.g. 
tear up, tear down, etc.) But for small trivial tests I really prefer to 
use plain JTreg. This also has the big advantage that is becomes trivial 
to run such a test stand-alone which may come handy if you have to debug it.

So if you don't insist, I'll prefer to leave the test as it is.

> I also believe the rest of the comments below are worth addressing.
> 

Besides that, I've addressed all the other points mentioned by 
Christoph. Please find the new webrev at:

http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011.v1/

Thank you and best regards,
Volker

> Thank you again for the fix
> 
> Best
> Lance
>> On Nov 13, 2019, at 11:26 AM, Langer, Christoph 
>> > wrote:
>>
>> Hi Volker,
>>
>> good catch in ZipFileSystem ?? The fix is the right thing to do.
>>
>> I have a few remarks to the test, though:
>>
>> Line 52, initialization of the File object: I think you should just do 
>> Path zipFile = Paths.get("file.zip"); When the test is run in the 
>> jtreg framework, it's running in its own scratch directory, so no need 
>> to use java.io.tmpdir. You can also leave cleanup to jtreg and don't 
>> need to delete the file in the end (in the finally block). However, 
>> you should probably check whether the file exists in the beginning and 
>> delete it in that case.
>>
>> Line 55ff: You don't need to use this URI thing any more. You can 
>> simply do: try (FileSystem fs = FileSystems.newFileSystem(zipFile, 
>> Map.of("create", true))) { (line 58).
>>
>> Line 61/62: You're using a Vector, wow ?? You should rather use 
>> ArrayList, I think...
>>
>> Line 85: This should rather be:
>> ???????????????????@SuppressWarnings("unchecked")
>> ???????????????????int inflater_count = 
>> ((List)inflaters.get(fs)).size();
>> Same for line 89.
>>
>> Line 93 (Catch clause): I think we should fail in that case, too. 
>> Otherwise, if the implementation would change, the test could run 
>> unnoticed for years, testing basically nothing...
>>
>> Best regards,
>> Christoph
>>
>>
>>> -----Original Message-----
>>> From: core-libs-dev >> > On Behalf
>>> Of Simonis, Volker
>>> Sent: Mittwoch, 13. November 2019 16:23
>>> To: core-libs-dev at openjdk.java.net 
>>> 
>>> Subject: RFR(XS): 8234011: (zipfs) Memory leak in
>>> ZipFileSystem.releaseDeflater()
>>>
>>> Hi,
>>>
>>> can I please get a review for this trivial fix of an old 
>>> copy-and-paste error:
>>>
>>> http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011/
>>> https://bugs.openjdk.java.net/browse/JDK-8234011
>>>
>>> ZipFileSystem caches MAX_FLATER (currently 20) Inflater/Deflater objects.
>>> However the logic for reusing Deflaters is wrong because it 
>>> references the
>>> Inflater List when checking against the number of already cached objects.
>>> This seems like a day-one copy and paste error.
>>>
>>> Notice that this issue is not as critical as it appears, because 
>>> retaining of
>>> additional Deflaters only happens when more than MAX_FLATER are used
>>> and released concurrently. I.e. the maximum number of cached Deflaters is
>>> the maximal number of Deflaters that are released while no new 
>>> Deflater is
>>> requested. In practice this is usually still a small number, less than
>>> MAX_FLATERS. Nevertheless we can easily construct an example which
>>> demonstrates the memory leak (see the JTRegtest in the patch) and because
>>> the fix is trivial we should really fix this.
>>>
>>> Thank you and best regards,
>>> Volker
>>>
>>>
>>>
>>> Amazon Development Center Germany GmbH
>>> Krausenstr. 38
>>> 10117 Berlin
>>> Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
>>> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
>>> Sitz: Berlin
>>> Ust-ID: DE 289 237 879
>>>
>>>
>>
> 
> 
> 
> 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 
> 
> 
> 




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



From simonisv at amazon.com  Thu Nov 14 16:27:15 2019
From: simonisv at amazon.com (Volker Simonis)
Date: Thu, 14 Nov 2019 17:27:15 +0100
Subject: RFR(XS): 8234011: (zipfs) Memory leak in
 ZipFileSystem.releaseDeflater()
In-Reply-To: <69AB1167-0598-4B51-9A18-31BF0F6A9701@oracle.com>
References: <1573658564822.16574@amazon.de>
 
 <45B01685-8D87-4171-BD84-778659680C67@oracle.com>
 
 <69AB1167-0598-4B51-9A18-31BF0F6A9701@oracle.com>
Message-ID: 

On 14.11.19 16:27, Lance Andersen wrote:
> Hi Volker,
> 
>> On Nov 14, 2019, at 8:53 AM, Volker Simonis > > wrote:
>>
>> On 13.11.19 18:54, Lance Andersen wrote:
>>> Hi Volker,
>>> Thank you for doing this.
>>> As Christoph mentioned, ?you can just do Path.of() and create the 
>>> file in the work directory for the test.
>>
>> Done.
>>
>>> If possible, I would use TestNG as that is consistent with the vast 
>>> majority of the tests.
>>>
>>
>> I don't particularly like to nest one test harness within another one :)
>> But seriously, I think using JUnit or TestNG makes sens if you write a 
>> whole test suit which uses the features of such a test harness (e.g. 
>> tear up, tear down, etc.)
> 
> Well you could use @AfterMethod or @AfterClass to clean up files etc? ;-)
>> But for small trivial tests I really prefer to use plain JTreg. This 
>> also has the big advantage that is becomes trivial to run such a test 
>> stand-alone which may come handy if you have to debug it.
> Easy enough to add a main method to call your test method (there are 
> some testng tests I have seen in the workspace that do that)
>>
>> So if you don't insist, I'll prefer to leave the test as it is.
> 
> While I would prefer it for new tests, I am not insisting you need to 
> change the test?.. ;-)

OK, thanks. I might consider using it in the future :)

>>
>>> I also believe the rest of the comments below are worth addressing.
>>
>> Besides that, I've addressed all the other points mentioned by 
>> Christoph. Please find the new webrev at:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011.v1/
> 
> line 55 you can remove the creation of the HashMap
> 

Good catch! Removed.

> line 73, do you really need the equals check seeing you do not do anything?
>

Removed. It was a leftover of local testing.

> I am not sure throwing a SkippedException is correct, ?I would probably 
> throw a RuntimeException
> 

As I wrote in the answer to Christoph, this is a relatively new feature 
of JTreg [1] which I think was introduced for exactly such kind of 
situations where a tests detects at runtime only, that for some reasons 
he can't test the issue he was supposed to test. More and more tests are 
adapting it now [2]. The SkippedException will be handled specially by 
JTreg and let the test pass, but with status "Passed.Skipped" (plus 
exception message) instead of just "Passed" (plis "Execution successful").

Here's the next webrev:

http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011.v2/

Thanks,
Volker

[1] 
https://openjdk.java.net/jtreg/faq.html#what-if-a-test-does-not-apply-in-a-given-situation
[2] https://bugs.openjdk.java.net/browse/JDK-8208655

> Best
> Lance
>>
>> Thank you and best regards,
>> Volker
>>
>>> Thank you again for the fix
>>> Best
>>> Lance
>>>> On Nov 13, 2019, at 11:26 AM, Langer, Christoph 
>>>>  
>>>> > wrote:
>>>>
>>>> Hi Volker,
>>>>
>>>> good catch in ZipFileSystem ?? The fix is the right thing to do.
>>>>
>>>> I have a few remarks to the test, though:
>>>>
>>>> Line 52, initialization of the File object: I think you should just 
>>>> do Path zipFile = Paths.get("file.zip"); When the test is run in the 
>>>> jtreg framework, it's running in its own scratch directory, so no 
>>>> need to use java.io.tmpdir. You can also leave cleanup to jtreg and 
>>>> don't need to delete the file in the end (in the finally block). 
>>>> However, you should probably check whether the file exists in the 
>>>> beginning and delete it in that case.
>>>>
>>>> Line 55ff: You don't need to use this URI thing any more. You can 
>>>> simply do: try (FileSystem fs = FileSystems.newFileSystem(zipFile, 
>>>> Map.of("create", true))) { (line 58).
>>>>
>>>> Line 61/62: You're using a Vector, wow ?? You should rather use 
>>>> ArrayList, I think...
>>>>
>>>> Line 85: This should rather be:
>>>> ???????????????????@SuppressWarnings("unchecked")
>>>> ???????????????????int inflater_count = 
>>>> ((List)inflaters.get(fs)).size();
>>>> Same for line 89.
>>>>
>>>> Line 93 (Catch clause): I think we should fail in that case, too. 
>>>> Otherwise, if the implementation would change, the test could run 
>>>> unnoticed for years, testing basically nothing...
>>>>
>>>> Best regards,
>>>> Christoph
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: core-libs-dev >>>>  
>>>>> > On Behalf
>>>>> Of Simonis, Volker
>>>>> Sent: Mittwoch, 13. November 2019 16:23
>>>>> To: core-libs-dev at openjdk.java.net 
>>>>>  
>>>>> 
>>>>> Subject: RFR(XS): 8234011: (zipfs) Memory leak in
>>>>> ZipFileSystem.releaseDeflater()
>>>>>
>>>>> Hi,
>>>>>
>>>>> can I please get a review for this trivial fix of an old 
>>>>> copy-and-paste error:
>>>>>
>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011/
>>>>> https://bugs.openjdk.java.net/browse/JDK-8234011
>>>>>
>>>>> ZipFileSystem caches MAX_FLATER (currently 20) Inflater/Deflater 
>>>>> objects.
>>>>> However the logic for reusing Deflaters is wrong because it 
>>>>> references the
>>>>> Inflater List when checking against the number of already cached 
>>>>> objects.
>>>>> This seems like a day-one copy and paste error.
>>>>>
>>>>> Notice that this issue is not as critical as it appears, because 
>>>>> retaining of
>>>>> additional Deflaters only happens when more than MAX_FLATER are used
>>>>> and released concurrently. I.e. the maximum number of cached 
>>>>> Deflaters is
>>>>> the maximal number of Deflaters that are released while no new 
>>>>> Deflater is
>>>>> requested. In practice this is usually still a small number, less than
>>>>> MAX_FLATERS. Nevertheless we can easily construct an example which
>>>>> demonstrates the memory leak (see the JTRegtest in the patch) and 
>>>>> because
>>>>> the fix is trivial we should really fix this.
>>>>>
>>>>> Thank you and best regards,
>>>>> Volker
>>>>>
>>>>>
>>>>>
>>>>> Amazon Development Center Germany GmbH
>>>>> Krausenstr. 38
>>>>> 10117 Berlin
>>>>> Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
>>>>> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
>>>>> Sitz: Berlin
>>>>> Ust-ID: DE 289 237 879
>>>>>
>>>>>
>>>>
>>> 
>>> 
>>> 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  
>>> 
>>
>>
>>
>>
>> Amazon Development Center Germany GmbH
>> Krausenstr. 38
>> 10117 Berlin
>> Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
>> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
>> Sitz: Berlin
>> Ust-ID: DE 289 237 879
>>
>>
> 
> 
> 
> 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 
> 
> 
> 




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



From simonisv at amazon.com  Thu Nov 14 17:05:32 2019
From: simonisv at amazon.com (Volker Simonis)
Date: Thu, 14 Nov 2019 18:05:32 +0100
Subject: RFR(XS): 8234011: (zipfs) Memory leak in
 ZipFileSystem.releaseDeflater()
In-Reply-To: 
References: <1573658564822.16574@amazon.de>
 
 <45B01685-8D87-4171-BD84-778659680C67@oracle.com>
 
 <69AB1167-0598-4B51-9A18-31BF0F6A9701@oracle.com>
 
 
Message-ID: 

On 14.11.19 17:38, Lance Andersen wrote:
> 
>> On Nov 14, 2019, at 11:27 AM, Volker Simonis > > wrote:
>>
>> On 14.11.19 16:27, Lance Andersen wrote:
>>> Hi Volker,
>>>> On Nov 14, 2019, at 8:53 AM, Volker Simonis >>> > wrote:
>>>>
>>>> On 13.11.19 18:54, Lance Andersen wrote:
>>>>> Hi Volker,
>>>>> Thank you for doing this.
>>>>> As Christoph mentioned, ?you can just do Path.of() and create the 
>>>>> file in the work directory for the test.
>>>>
>>>> Done.
>>>>
>>>>> If possible, I would use TestNG as that is consistent with the vast 
>>>>> majority of the tests.
>>>>>
>>>>
>>>> I don't particularly like to nest one test harness within another one :)
>>>> But seriously, I think using JUnit or TestNG makes sens if you write 
>>>> a whole test suit which uses the features of such a test harness 
>>>> (e.g. tear up, tear down, etc.)
>>> Well you could use @AfterMethod or @AfterClass to clean up files etc? ;-)
>>>> But for small trivial tests I really prefer to use plain JTreg. This 
>>>> also has the big advantage that is becomes trivial to run such a 
>>>> test stand-alone which may come handy if you have to debug it.
>>> Easy enough to add a main method to call your test method (there are 
>>> some testng tests I have seen in the workspace that do that)
>>>>
>>>> So if you don't insist, I'll prefer to leave the test as it is.
>>> While I would prefer it for new tests, I am not insisting you need to 
>>> change the test?.. ;-)
>>
>> OK, thanks. I might consider using it in the future :)
>>
>>>>
>>>>> I also believe the rest of the comments below are worth addressing.
>>>>
>>>> Besides that, I've addressed all the other points mentioned by 
>>>> Christoph. Please find the new webrev at:
>>>>
>>>> http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011.v1/
>>> line 55 you can remove the creation of the HashMap
>>
>> Good catch! Removed.
>>
>>> line 73, do you really need the equals check seeing you do not do 
>>> anything?
>>>
>>
>> Removed. It was a leftover of local testing.
>>
>>> I am not sure throwing a SkippedException is correct, ?I would 
>>> probably throw a RuntimeException
>>
>> As I wrote in the answer to Christoph, this is a relatively new 
>> feature of JTreg [1] which I think was introduced for exactly such 
>> kind of situations where a tests detects at runtime only, that for 
>> some reasons he can't test the issue he was supposed to test. More and 
>> more tests are adapting it now [2]. The SkippedException will be 
>> handled specially by JTreg and let the test pass, but with status 
>> "Passed.Skipped" (plus exception message) instead of just "Passed" 
>> (plis "Execution successful").
>>
>> Here's the next webrev:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011.v2/
> 
> Thank you for the updates. ?I am still a bit skeptical of the use of 
> SkippedException here as you would never see the test is no longer 
> passing due to an implementation change unless you are specifically 
> looking for it.
> 
> That being said, ?if others who have more experience with using this 
> Exception in a similar scenario are good, then I am good.
> 
> So once we get a couple of other views on this from others with a thumbs 
> up for using SkippedException here, we are good to go :-)

If this is the last blocker, I'm actually not insisting this time :)

Do you think it is better to just throw an exception and let the test 
fail if the underlying implementation changes? I thought it is better to 
be more conservative, because that would be actually a mistake in the 
test and not an error in the testee. But if you think it would be more 
appropriate to fail in such a case, I'm happy to change it?

> 
> Best
> Lance
> 
>>
>> Thanks,
>> Volker
>>
>> [1]https://openjdk.java.net/jtreg/faq.html#what-if-a-test-does-not-apply-in-a-given-situation
>> [2]https://bugs.openjdk.java.net/browse/JDK-8208655
>>
>>> Best
>>> Lance
>>>>
>>>> Thank you and best regards,
>>>> Volker
>>>>
>>>>> Thank you again for the fix
>>>>> Best
>>>>> Lance
>>>>>> On Nov 13, 2019, at 11:26 AM, Langer, Christoph 
>>>>>> >>>>>  
>>>>>> > wrote:
>>>>>>
>>>>>> Hi Volker,
>>>>>>
>>>>>> good catch in ZipFileSystem ?? The fix is the right thing to do.
>>>>>>
>>>>>> I have a few remarks to the test, though:
>>>>>>
>>>>>> Line 52, initialization of the File object: I think you should 
>>>>>> just do Path zipFile = Paths.get("file.zip"); When the test is run 
>>>>>> in the jtreg framework, it's running in its own scratch directory, 
>>>>>> so no need to use java.io.tmpdir. You can also leave cleanup to 
>>>>>> jtreg and don't need to delete the file in the end (in the finally 
>>>>>> block). However, you should probably check whether the file exists 
>>>>>> in the beginning and delete it in that case.
>>>>>>
>>>>>> Line 55ff: You don't need to use this URI thing any more. You can 
>>>>>> simply do: try (FileSystem fs = FileSystems.newFileSystem(zipFile, 
>>>>>> Map.of("create", true))) { (line 58).
>>>>>>
>>>>>> Line 61/62: You're using a Vector, wow ?? You should rather use 
>>>>>> ArrayList, I think...
>>>>>>
>>>>>> Line 85: This should rather be:
>>>>>> ???????????????????@SuppressWarnings("unchecked")
>>>>>> ???????????????????int inflater_count = 
>>>>>> ((List)inflaters.get(fs)).size();
>>>>>> Same for line 89.
>>>>>>
>>>>>> Line 93 (Catch clause): I think we should fail in that case, too. 
>>>>>> Otherwise, if the implementation would change, the test could run 
>>>>>> unnoticed for years, testing basically nothing...
>>>>>>
>>>>>> Best regards,
>>>>>> Christoph
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: core-libs-dev >>>>>>  
>>>>>>> > On Behalf
>>>>>>> Of Simonis, Volker
>>>>>>> Sent: Mittwoch, 13. November 2019 16:23
>>>>>>> To:core-libs-dev at openjdk.java.net 
>>>>>>>  
>>>>>>> 
>>>>>>> Subject: RFR(XS): 8234011: (zipfs) Memory leak in
>>>>>>> ZipFileSystem.releaseDeflater()
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> can I please get a review for this trivial fix of an old 
>>>>>>> copy-and-paste error:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011/
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8234011
>>>>>>>
>>>>>>> ZipFileSystem caches MAX_FLATER (currently 20) Inflater/Deflater 
>>>>>>> objects.
>>>>>>> However the logic for reusing Deflaters is wrong because it 
>>>>>>> references the
>>>>>>> Inflater List when checking against the number of already cached 
>>>>>>> objects.
>>>>>>> This seems like a day-one copy and paste error.
>>>>>>>
>>>>>>> Notice that this issue is not as critical as it appears, because 
>>>>>>> retaining of
>>>>>>> additional Deflaters only happens when more than MAX_FLATER are used
>>>>>>> and released concurrently. I.e. the maximum number of cached 
>>>>>>> Deflaters is
>>>>>>> the maximal number of Deflaters that are released while no new 
>>>>>>> Deflater is
>>>>>>> requested. In practice this is usually still a small number, less 
>>>>>>> than
>>>>>>> MAX_FLATERS. Nevertheless we can easily construct an example which
>>>>>>> demonstrates the memory leak (see the JTRegtest in the patch) and 
>>>>>>> because
>>>>>>> the fix is trivial we should really fix this.
>>>>>>>
>>>>>>> Thank you and best regards,
>>>>>>> Volker
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Amazon Development Center Germany GmbH
>>>>>>> Krausenstr. 38
>>>>>>> 10117 Berlin
>>>>>>> Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
>>>>>>> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
>>>>>>> Sitz: Berlin
>>>>>>> Ust-ID: DE 289 237 879
>>>>>>>
>>>>>>>
>>>>>>
>>>>> 
>>>>> 
>>>>> 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 
>>>>>  
>>>>
>>>>
>>>>
>>>>
>>>> Amazon Development Center Germany GmbH
>>>> Krausenstr. 38
>>>> 10117 Berlin
>>>> Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
>>>> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
>>>> Sitz: Berlin
>>>> Ust-ID: DE 289 237 879
>>>>
>>>>
>>> 
>>> 
>>> 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  
>>> 
>>
>>
>>
>>
>> Amazon Development Center Germany GmbH
>> Krausenstr. 38
>> 10117 Berlin
>> Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
>> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
>> Sitz: Berlin
>> Ust-ID: DE 289 237 879
> 
> 
> 
> 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 
> 
> 
> 




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



From tschoening at am-soft.de  Thu Nov 14 19:46:42 2019
From: tschoening at am-soft.de (=?utf-8?Q?Thorsten_Sch=C3=B6ning?=)
Date: Thu, 14 Nov 2019 20:46:42 +0100
Subject: Should Java support ERROR_NO_MORE_FILES when canonicalizing paths on
 Windows?
Message-ID: <346034750.20191114204642@am-soft.de>

Hi all,

while the details can be read on SO[1][2], the bottom line is that I
have a setup in which Windows sets the error code ERROR_NO_MORE_FILES 
during calls to FindFirstFileW sometimes. In theory that shouldn't
happen, but it simply does once in a while and make my Java daemon run
into exceptions, because that error code isn't expected.

The following lists all expected error codes from the function
"lastErrorReportable", which is used during canonicalizing paths:

>    if ((errval == ERROR_FILE_NOT_FOUND)
>        || (errval == ERROR_DIRECTORY)
>        || (errval == ERROR_PATH_NOT_FOUND)
>        || (errval == ERROR_BAD_NETPATH)
>        || (errval == ERROR_BAD_NET_NAME)
>        || (errval == ERROR_ACCESS_DENIED)
>        || (errval == ERROR_NETWORK_UNREACHABLE)
>        || (errval == ERROR_NETWORK_ACCESS_DENIED)) {
>        return 0;
>    }

https://github.com/openjdk/jdk/blob/master/src/java.base/windows/native/libjava/canonicalize_md.c#L131

Obviously ERROR_NO_MORE_FILES is missing, but its pretty interesting
as well that Java supports other error codes already. Regarding the
docs, FindFirstFileW should only return ERROR_FILE_NOT_FOUND, but most
likely people ran into other error codes already Windows used in
various circumstances. All of those totally make sense.

So, how about adding ERROR_NO_MORE_FILES there as well?

As can be read in my SO-questions, I didn't recognized any other real
technical problem like permissions issues, timeouts in the network or
stuff. Its only that Windows sometimes decides to use that error code
for some unknown reason. Adding it would only be one line of text and
increase compatibility with setups like mine. I guess problems like
these were the reason to add other error codes in the past as well.

Thanks!

[1]: https://stackoverflow.com/questions/58825588/does-java-need-to-support-error-no-more-files-when-canonicalizing-paths-on-windo
[2]: https://stackoverflow.com/questions/58825963/when-does-findfirstfilew-set-last-error-to-be-error-no-more-files-instead-of-err?noredirect=1&lq=1

Mit freundlichen Gr??en,

Thorsten Sch?ning

-- 
Thorsten Sch?ning       E-Mail: Thorsten.Schoening at AM-SoFT.de
AM-SoFT IT-Systeme      http://www.AM-SoFT.de/

Telefon...........05151-  9468- 55
Fax...............05151-  9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Gesch?ftsf?hrer: Andreas Muchow


From lance.andersen at oracle.com  Thu Nov 14 20:20:12 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 14 Nov 2019 15:20:12 -0500
Subject: RFR(XS): 8234011: (zipfs) Memory leak in
 ZipFileSystem.releaseDeflater()
In-Reply-To: 
References: <1573658564822.16574@amazon.de>
 
 <45B01685-8D87-4171-BD84-778659680C67@oracle.com>
 
 <69AB1167-0598-4B51-9A18-31BF0F6A9701@oracle.com>
 
 
 
Message-ID: <0C0555C2-47DA-472D-AF6D-6F8E451D7496@oracle.com>

Hi Volker,
> On Nov 14, 2019, at 12:05 PM, Volker Simonis  wrote:
> 
> On 14.11.19 17:38, Lance Andersen wrote:
>>> On Nov 14, 2019, at 11:27 AM, Volker Simonis > wrote:
>>> 
>>> 
>>>> I am not sure throwing a SkippedException is correct,  I would probably throw a RuntimeException
>>> 
>>> As I wrote in the answer to Christoph, this is a relatively new feature of JTreg [1] which I think was introduced for exactly such kind of situations where a tests detects at runtime only, that for some reasons he can't test the issue he was supposed to test. More and more tests are adapting it now [2]. The SkippedException will be handled specially by JTreg and let the test pass, but with status "Passed.Skipped" (plus exception message) instead of just "Passed" (plis "Execution successful").
>>> 
>>> Here's the next webrev:
>>> 
>>> http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011.v2/
>> Thank you for the updates.  I am still a bit skeptical of the use of SkippedException here as you would never see the test is no longer passing due to an implementation change unless you are specifically looking for it.
>> That being said,  if others who have more experience with using this Exception in a similar scenario are good, then I am good.
>> So once we get a couple of other views on this from others with a thumbs up for using SkippedException here, we are good to go :-)
> 
> If this is the last blocker, I'm actually not insisting this time :)
> 
> Do you think it is better to just throw an exception and let the test fail if the underlying implementation changes? I thought it is better to be more conservative, because that would be actually a mistake in the test and not an error in the testee. But if you think it would be more appropriate to fail in such a case, I'm happy to change it?

I do think it would be best to fail as if the implementation is changed and it impacts the test, we would want to make sure we update it at the same time. 

Best
Lance
> 
>> Best
>> Lance
>>> 
>>> Thanks,
>>> Volker
>>> 
>>> [1]https://openjdk.java.net/jtreg/faq.html#what-if-a-test-does-not-apply-in-a-given-situation
>>> [2]https://bugs.openjdk.java.net/browse/JDK-8208655
>>> 
>>>> Best
>>>> Lance
>>>>> 
>>>>> Thank you and best regards,
>>>>> Volker
>>>>> 
>>>>>> Thank you again for the fix
>>>>>> Best
>>>>>> Lance
>>>>>>> On Nov 13, 2019, at 11:26 AM, Langer, Christoph  > wrote:
>>>>>>> 
>>>>>>> Hi Volker,
>>>>>>> 
>>>>>>> good catch in ZipFileSystem ?? The fix is the right thing to do.
>>>>>>> 
>>>>>>> I have a few remarks to the test, though:
>>>>>>> 
>>>>>>> Line 52, initialization of the File object: I think you should just do Path zipFile = Paths.get("file.zip"); When the test is run in the jtreg framework, it's running in its own scratch directory, so no need to use java.io.tmpdir. You can also leave cleanup to jtreg and don't need to delete the file in the end (in the finally block). However, you should probably check whether the file exists in the beginning and delete it in that case.
>>>>>>> 
>>>>>>> Line 55ff: You don't need to use this URI thing any more. You can simply do: try (FileSystem fs = FileSystems.newFileSystem(zipFile, Map.of("create", true))) { (line 58).
>>>>>>> 
>>>>>>> Line 61/62: You're using a Vector, wow ?? You should rather use ArrayList, I think...
>>>>>>> 
>>>>>>> Line 85: This should rather be:
>>>>>>>                    @SuppressWarnings("unchecked")
>>>>>>>                    int inflater_count = ((List)inflaters.get(fs)).size();
>>>>>>> Same for line 89.
>>>>>>> 
>>>>>>> Line 93 (Catch clause): I think we should fail in that case, too. Otherwise, if the implementation would change, the test could run unnoticed for years, testing basically nothing...
>>>>>>> 
>>>>>>> Best regards,
>>>>>>> Christoph
>>>>>>> 
>>>>>>> 
>>>>>>>> -----Original Message-----
>>>>>>>> From: core-libs-dev  > On Behalf
>>>>>>>> Of Simonis, Volker
>>>>>>>> Sent: Mittwoch, 13. November 2019 16:23
>>>>>>>> To:core-libs-dev at openjdk.java.net  
>>>>>>>> Subject: RFR(XS): 8234011: (zipfs) Memory leak in
>>>>>>>> ZipFileSystem.releaseDeflater()
>>>>>>>> 
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> can I please get a review for this trivial fix of an old copy-and-paste error:
>>>>>>>> 
>>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011/
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8234011
>>>>>>>> 
>>>>>>>> ZipFileSystem caches MAX_FLATER (currently 20) Inflater/Deflater objects.
>>>>>>>> However the logic for reusing Deflaters is wrong because it references the
>>>>>>>> Inflater List when checking against the number of already cached objects.
>>>>>>>> This seems like a day-one copy and paste error.
>>>>>>>> 
>>>>>>>> Notice that this issue is not as critical as it appears, because retaining of
>>>>>>>> additional Deflaters only happens when more than MAX_FLATER are used
>>>>>>>> and released concurrently. I.e. the maximum number of cached Deflaters is
>>>>>>>> the maximal number of Deflaters that are released while no new Deflater is
>>>>>>>> requested. In practice this is usually still a small number, less than
>>>>>>>> MAX_FLATERS. Nevertheless we can easily construct an example which
>>>>>>>> demonstrates the memory leak (see the JTRegtest in the patch) and because
>>>>>>>> the fix is trivial we should really fix this.
>>>>>>>> 
>>>>>>>> Thank you and best regards,
>>>>>>>> Volker
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Amazon Development Center Germany GmbH
>>>>>>>> Krausenstr. 38
>>>>>>>> 10117 Berlin
>>>>>>>> Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
>>>>>>>> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
>>>>>>>> Sitz: Berlin
>>>>>>>> Ust-ID: DE 289 237 879
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 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  
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Amazon Development Center Germany GmbH
>>>>> Krausenstr. 38
>>>>> 10117 Berlin
>>>>> Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
>>>>> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
>>>>> Sitz: Berlin
>>>>> Ust-ID: DE 289 237 879
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 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  
>>> 
>>> 
>>> 
>>> 
>>> Amazon Development Center Germany GmbH
>>> Krausenstr. 38
>>> 10117 Berlin
>>> Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
>>> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
>>> Sitz: Berlin
>>> Ust-ID: DE 289 237 879
>> 
>> 
>> 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 
> 
> 
> 
> 
> Amazon Development Center Germany GmbH
> Krausenstr. 38
> 10117 Berlin
> Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
> Sitz: Berlin
> Ust-ID: DE 289 237 879
> 
> 

 
  
 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  Thu Nov 14 21:35:11 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 14 Nov 2019 16:35:11 -0500
Subject: [ping] 8179320: File.getUsableSpace() returns a negative number
 on very large file system
In-Reply-To: <8F5DDADA-BF4B-4504-B69D-05FE216D2B9C@oracle.com>
References: <674F3B84-3737-4F55-8D2B-B1777F91203E@oracle.com>
 <8F5DDADA-BF4B-4504-B69D-05FE216D2B9C@oracle.com>
Message-ID: <2c8fc362-426b-1895-c1e3-7548ec224ffe@oracle.com>

Hi Brian,

The changes look fine.

In the CSR, the typography of the code font for |java.io.File.getXSpace
|will not read well in all the places where the summary sentence is used 
by itself.
Spelling out the names of the affected methods will help.

Having to unpack a zip file to see the changes in the CSR is not reader 
friendly.
They are relatively small and could be included inline in the CSR.

Regards, Roger

||

On 11/14/19 10:42 AM, Brian Burkhalter wrote:
>
>> Begin forwarded message:
>>
>> From: Brian Burkhalter 
>> Subject: 8179320: File.getUsableSpace() returns a negative number on very large file system
>> Date: November 1, 2019 at 5:13:28 PM PDT
>> To: Core-Libs-Dev 
>>
>> For this issue [1], please review this patch [2] and the corresponding CSR [3].
>>
>> Thanks,
>>
>> Brian
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8179320
>> [2] http://cr.openjdk.java.net/~bpb/8179320/webrev.00/
>> [3] https://bugs.openjdk.java.net/browse/JDK-8233426


From david.holmes at oracle.com  Thu Nov 14 22:04:06 2019
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 15 Nov 2019 08:04:06 +1000
Subject: RFR (M) 8223261 "JDK-8189208 followup - remove
 JDK_GetVersionInfo0 and the supporting code"
In-Reply-To: <306d4073-7d64-d807-b670-52126462e81c@oracle.com>
References: <4623455a-2d90-e697-89b3-830d5becf8f9@oracle.com>
 
 
 
 <306d4073-7d64-d807-b670-52126462e81c@oracle.com>
Message-ID: <1fc99211-7b79-cc8c-b54f-b7de27294a95@oracle.com>

On 15/11/2019 1:13 am, gerard ziemski wrote:
> Thank you for the review.
> 
> I'm definitively going to wait for Christoph to check in his fix first.
> 
> I tried in fact to leave jdk_util.c/.h files in empty without removing 
> them from the repo, and even though Mac/Linux were OK with that, 
> Solaris/Windows were not.

The .c file can go. The .h file wouldn't be empty as it still has the 
other includes.

David

> 
> cheers
> 
> On 11/13/19 9:21 PM, David Holmes wrote:
>> Hi Gerard,
>>
>> On 14/11/2019 6:05 am, Langer, Christoph wrote:
>>> Hi Gerard,
>>>
>>> generally it looks like a nice cleanup.
>>>
>>> I've got a patch prepared though, which I was planning on posting 
>>> tomorrow. It is about cleanup for the canonicalize function in 
>>> libjava. I wanted to use jdk_util.h for the function prototype. I had 
>>> not yet filed a bug but here is what I have:
>>> http://cr.openjdk.java.net/~clanger/webrevs/cleanup-canonicalize/
>>>
>>> So maybe you could refrain from removing jdk_util.h or maybe you can 
>>> hold off submitting your change until my cleanup is reviewed?
>>
>> I'd also suggest not deleting jdk_util.h. It seems very odd to me to 
>> have jdk_util_md.h with no shared jdk_util.h. If you keep jdk_util.h 
>> then you don't need to touch a number of the files.
>>
>> Otherwise this looks like a good cleanup.
>>
>> Thanks,
>> David
>> -----
>>
>>> I'll create a bug and post an official review thread tomorrow...
>>>
>>> Thanks
>>> Christoph
>>>
>>>> -----Original Message-----
>>>> From: hotspot-dev  On Behalf Of
>>>> Mandy Chung
>>>> Sent: Mittwoch, 13. November 2019 20:30
>>>> To: gerard ziemski 
>>>> Cc: awt-dev at openjdk.java.net; hotspot-dev developers >>> dev at openjdk.java.net>; core-libs-dev at openjdk.java.net
>>>> Subject: Re: RFR (M) 8223261 "JDK-8189208 followup - remove
>>>> JDK_GetVersionInfo0 and the supporting code"
>>>>
>>>>
>>>>
>>>> On 11/13/19 10:50 AM, gerard ziemski wrote:
>>>>> Hi all,
>>>>>
>>>>> Please review this cleanup, where we remove JDK_GetVersionInfo0 and
>>>>> related code, since we can get build versions directly from within the
>>>>> VM itself:
>>>>>
>>>>> I'm including core-libs and awt in this review because the proposed
>>>>> fix touches their corresponding files.
>>>>>
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8223261
>>>>> webrev: http://cr.openjdk.java.net/~gziemski/8223261_rev1
>>>>> tests: passes Mach5 tier1,2,3,4,5,6
>>>>>
>>>>
>>>> This is a good clean up.? JDK_GetVersionInfo0 was needed long time ago
>>>> in particular in HS express support that is no longer applicable.
>>>>
>>>> One leftover comment should also be removed.
>>>>
>>>> src/hotspot/share/runtime/vm_version.hpp
>>>> ? ? // Gets the jvm_version_info.jvm_version defined in jvm.h
>>>>
>>>> otherwise looks good.
>>>>
>>>> Mandy
> 

From brent.christian at oracle.com  Thu Nov 14 23:58:11 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 14 Nov 2019 15:58:11 -0800
Subject: RFR 8233272 : The Class.forName specification should be updated
 to match the long-standing implementation with respect to class linking
In-Reply-To: <7ddee581-c68b-bf40-22db-871205b8ca1b@oracle.com>
References: <79528f01-3418-eb51-4dbd-897e4e97f853@oracle.com>
 <7ddee581-c68b-bf40-22db-871205b8ca1b@oracle.com>
Message-ID: <3d305a6d-fd45-f6e5-93f2-c47250f31985@oracle.com>

On 11/14/19 8:22 AM, Mandy Chung wrote:
> On 11/13/19 10:37 AM, Brent Christian wrote:
> 
> The spec change looks fine.

OK, thanks.

> As for the test, I expect that it simply calls Class.forName("Provider", 
> false, ucl) and then should succeed.
> 
> Then calling Class.forName("Provider", true, ucl) should fail with an 
> error (I think it's EIIE with NCDFE?).? This way it verifies that 
> initialization/linking does cause NCDFE during verification while 
> Class.forName does not do linking if initialize=false.

Yes, that works well, thanks for the idea (plus I can do it with one 
fewer class):

http://cr.openjdk.java.net/~bchristi/8233272/webrev-03/

-Brent

From brian.burkhalter at oracle.com  Fri Nov 15 00:11:55 2019
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 14 Nov 2019 16:11:55 -0800
Subject: [ping] 8179320: File.getUsableSpace() returns a negative number
 on very large file system
In-Reply-To: <2c8fc362-426b-1895-c1e3-7548ec224ffe@oracle.com>
References: <674F3B84-3737-4F55-8D2B-B1777F91203E@oracle.com>
 <8F5DDADA-BF4B-4504-B69D-05FE216D2B9C@oracle.com>
 <2c8fc362-426b-1895-c1e3-7548ec224ffe@oracle.com>
Message-ID: 

Hi Roger,

> On Nov 14, 2019, at 1:35 PM, Roger Riggs  wrote:
> 
> The changes look fine.

Thanks for the comments.

> In the CSR, the typography of the code font for |java.io.File.getXSpace
> |will not read well in all the places where the summary sentence is used by itself.
> Spelling out the names of the affected methods will help.

Done [1].

> Having to unpack a zip file to see the changes in the CSR is not reader friendly.
> They are relatively small and could be included inline in the CSR.

I could not get the diff to format properly inline but I included the changes as seen in the javadoc.

Thanks,

Brian

[1] https://bugs.openjdk.java.net/browse/JDK-8233426

From david.holmes at oracle.com  Fri Nov 15 00:12:31 2019
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 15 Nov 2019 10:12:31 +1000
Subject: RFR 8233272 : The Class.forName specification should be updated
 to match the long-standing implementation with respect to class linking
In-Reply-To: <3d305a6d-fd45-f6e5-93f2-c47250f31985@oracle.com>
References: <79528f01-3418-eb51-4dbd-897e4e97f853@oracle.com>
 <7ddee581-c68b-bf40-22db-871205b8ca1b@oracle.com>
 <3d305a6d-fd45-f6e5-93f2-c47250f31985@oracle.com>
Message-ID: 

Hi Brent,

On 15/11/2019 9:58 am, Brent Christian wrote:
> On 11/14/19 8:22 AM, Mandy Chung wrote:
>> On 11/13/19 10:37 AM, Brent Christian wrote:
>>
>> The spec change looks fine.
> 
> OK, thanks.

+1 from me on spec changes.

> 
>> As for the test, I expect that it simply calls 
>> Class.forName("Provider", false, ucl) and then should succeed.
>>
>> Then calling Class.forName("Provider", true, ucl) should fail with an 
>> error (I think it's EIIE with NCDFE?).? This way it verifies that 
>> initialization/linking does cause NCDFE during verification while 
>> Class.forName does not do linking if initialize=false.
> 
> Yes, that works well, thanks for the idea (plus I can do it with one 
> fewer class):
> 
> http://cr.openjdk.java.net/~bchristi/8233272/webrev-03/

Test is fine. Just one note/clarification:

  63         // Loading (but not linking) Container will succeed.

Container was already loaded as part of the failing forName call, so 
this second forName will just return it.

Thanks,
David
-----

> -Brent

From brent.christian at oracle.com  Fri Nov 15 00:33:51 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 14 Nov 2019 16:33:51 -0800
Subject: RFR 8233272 : The Class.forName specification should be updated
 to match the long-standing implementation with respect to class linking
In-Reply-To: 
References: <79528f01-3418-eb51-4dbd-897e4e97f853@oracle.com>
 <7ddee581-c68b-bf40-22db-871205b8ca1b@oracle.com>
 <3d305a6d-fd45-f6e5-93f2-c47250f31985@oracle.com>
 
Message-ID: <99dded93-17d2-ea40-deef-56efd10218c7@oracle.com>

On 11/14/19 4:12 PM, David Holmes wrote:
> On 15/11/2019 9:58 am, Brent Christian wrote:
>>
>> http://cr.openjdk.java.net/~bchristi/8233272/webrev-03/
> 
> Test is fine. Just one note/clarification:
> 
>  ?63???????? // Loading (but not linking) Container will succeed.
> 
> Container was already loaded as part of the failing forName call, so 
> this second forName will just return it.

Hmm.  I could use a different classloader instance for the second 
Class.forName() call.

(The test does fail as expected using a build with 8212117 but without 
8233091.)

-Brent

From david.holmes at oracle.com  Fri Nov 15 00:42:04 2019
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 15 Nov 2019 10:42:04 +1000
Subject: RFR 8233272 : The Class.forName specification should be updated
 to match the long-standing implementation with respect to class linking
In-Reply-To: <99dded93-17d2-ea40-deef-56efd10218c7@oracle.com>
References: <79528f01-3418-eb51-4dbd-897e4e97f853@oracle.com>
 <7ddee581-c68b-bf40-22db-871205b8ca1b@oracle.com>
 <3d305a6d-fd45-f6e5-93f2-c47250f31985@oracle.com>
 
 <99dded93-17d2-ea40-deef-56efd10218c7@oracle.com>
Message-ID: 

On 15/11/2019 10:33 am, Brent Christian wrote:
> On 11/14/19 4:12 PM, David Holmes wrote:
>> On 15/11/2019 9:58 am, Brent Christian wrote:
>>>
>>> http://cr.openjdk.java.net/~bchristi/8233272/webrev-03/
>>
>> Test is fine. Just one note/clarification:
>>
>> ??63???????? // Loading (but not linking) Container will succeed.
>>
>> Container was already loaded as part of the failing forName call, so 
>> this second forName will just return it.
> 
> Hmm.? I could use a different classloader instance for the second 
> Class.forName() call.

If you really want to test both positive and negative cases from a clean 
slate then I would suggest modifying the test slightly and using two 
@run commands - one to try to initialize and one to not.

Cheers,
David

> (The test does fail as expected using a build with 8212117 but without 
> 8233091.)
> 
> -Brent

From mandy.chung at oracle.com  Fri Nov 15 00:46:18 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 14 Nov 2019 16:46:18 -0800
Subject: RFR 8233272 : The Class.forName specification should be updated
 to match the long-standing implementation with respect to class linking
In-Reply-To: 
References: <79528f01-3418-eb51-4dbd-897e4e97f853@oracle.com>
 <7ddee581-c68b-bf40-22db-871205b8ca1b@oracle.com>
 <3d305a6d-fd45-f6e5-93f2-c47250f31985@oracle.com>
 
 <99dded93-17d2-ea40-deef-56efd10218c7@oracle.com>
 
Message-ID: <1e4cd61f-dddd-b221-f0b4-448e64a4b440@oracle.com>



On 11/14/19 4:42 PM, David Holmes wrote:
> On 15/11/2019 10:33 am, Brent Christian wrote:
>> On 11/14/19 4:12 PM, David Holmes wrote:
>>> On 15/11/2019 9:58 am, Brent Christian wrote:
>>>>
>>>> http://cr.openjdk.java.net/~bchristi/8233272/webrev-03/
>>>
>>> Test is fine. Just one note/clarification:
>>>
>>> ??63???????? // Loading (but not linking) Container will succeed.
>>>
>>> Container was already loaded as part of the failing forName call, so 
>>> this second forName will just return it.
>>
>> Hmm.? I could use a different classloader instance for the second 
>> Class.forName() call.
>
> If you really want to test both positive and negative cases from a 
> clean slate then I would suggest modifying the test slightly and using 
> two @run commands - one to try to initialize and one to not.

Yes this is what I was thinking.? Two separate @run commands with an 
argument to indicate if initialize is true or false would do it.

Mandy

From mandy.chung at oracle.com  Fri Nov 15 00:51:39 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 14 Nov 2019 16:51:39 -0800
Subject: RFR JDK-8233527: Update Lookup::hasPrivateAccess and
 Lookup::defineClass spec w.r.t. full power lookup
In-Reply-To: 
References: <081f506c-62a9-dd98-8b62-04690f4cba14@oracle.com>
 <083da65f-e1a5-4f30-9d15-cf69df1918ec@j-kuhn.de>
 <94a4b52c-b47d-f861-54d5-6d661991b67b@oracle.com>
 <6bb905bf-8803-cc9e-ea28-49da6685a78b@j-kuhn.de>
 <97aefa43-ada4-a0a6-df3b-eb5c350a8a0f@oracle.com>
 <61d471dd-42ac-02cb-75e2-de63dadc3763@oracle.com>
 
Message-ID: <2a4f6ff4-e6bb-b988-b3f2-ca0f9ea8d1f5@oracle.com>



On 11/14/19 8:04 AM, Mandy Chung wrote:
>
>
> On 11/14/19 2:33 AM, Alan Bateman wrote:
>> On 14/11/2019 04:57, Mandy Chung wrote:
>>>
>>> Updated in place:
>>>
>>> http://cr.openjdk.java.net/~mchung/jdk14/8233527/webrev.02/
>>> http://cr.openjdk.java.net/~mchung/jdk14/8233527/specdiff/
>> The addition of hasFullPrivilegeAccess looks okay and probably the 
>> right thing to do.
>>
>> For the @deprecated message on the old method it might be simpler to 
>> say that the method was originally designed to test PRIVATE access 
>> but has since changed to test full privilege access. 
>
> It was designed to test full privilege access while private access 
> implies full privilege access as a Lookup with private access includes 
> module access.
>

I updated to:

This method was originally designed to test PRIVATE access that implies 
full privilege access but PRIVATE access has since become independent of 
PRIVATE access. It is recommended to call hasFullPrivilegeAccess() instead.

http://cr.openjdk.java.net/~mchung/jdk14//8233527/specdiff/java.base/java/lang/invoke/MethodHandles.Lookup.html

Mandy

From david.holmes at oracle.com  Fri Nov 15 01:04:20 2019
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 15 Nov 2019 11:04:20 +1000
Subject: RFR JDK-8233527: Update Lookup::hasPrivateAccess and
 Lookup::defineClass spec w.r.t. full power lookup
In-Reply-To: <2a4f6ff4-e6bb-b988-b3f2-ca0f9ea8d1f5@oracle.com>
References: <081f506c-62a9-dd98-8b62-04690f4cba14@oracle.com>
 <083da65f-e1a5-4f30-9d15-cf69df1918ec@j-kuhn.de>
 <94a4b52c-b47d-f861-54d5-6d661991b67b@oracle.com>
 <6bb905bf-8803-cc9e-ea28-49da6685a78b@j-kuhn.de>
 <97aefa43-ada4-a0a6-df3b-eb5c350a8a0f@oracle.com>
 <61d471dd-42ac-02cb-75e2-de63dadc3763@oracle.com>
 
 <2a4f6ff4-e6bb-b988-b3f2-ca0f9ea8d1f5@oracle.com>
Message-ID: <2d4b50dd-e19f-9c40-60c4-b4c36751601d@oracle.com>

Hi Mandy,

On 15/11/2019 10:51 am, Mandy Chung wrote:
> 
> 
> On 11/14/19 8:04 AM, Mandy Chung wrote:
>>
>>
>> On 11/14/19 2:33 AM, Alan Bateman wrote:
>>> On 14/11/2019 04:57, Mandy Chung wrote:
>>>>
>>>> Updated in place:
>>>>
>>>> http://cr.openjdk.java.net/~mchung/jdk14/8233527/webrev.02/
>>>> http://cr.openjdk.java.net/~mchung/jdk14/8233527/specdiff/
>>> The addition of hasFullPrivilegeAccess looks okay and probably the 
>>> right thing to do.
>>>
>>> For the @deprecated message on the old method it might be simpler to 
>>> say that the method was originally designed to test PRIVATE access 
>>> but has since changed to test full privilege access. 
>>
>> It was designed to test full privilege access while private access 
>> implies full privilege access as a Lookup with private access includes 
>> module access.
>>
> 
> I updated to:
> 
> This method was originally designed to test PRIVATE access that implies 
> full privilege access but PRIVATE access has since become independent of 
> PRIVATE access. It is recommended to call hasFullPrivilegeAccess() instead.

That doesn't read correctly: "PRIVATE" is independent of "PRIVATE" ??

David

> http://cr.openjdk.java.net/~mchung/jdk14//8233527/specdiff/java.base/java/lang/invoke/MethodHandles.Lookup.html 
> 
> 
> Mandy

From lance.andersen at oracle.com  Fri Nov 15 01:06:55 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 14 Nov 2019 20:06:55 -0500
Subject: RFR: 8234089: (zipfs) Remove classes JarFileSystemProvider and
 JarFileSystem
In-Reply-To: 
References: 
Message-ID: <3532D7A1-DF2F-41BF-80BF-09EF53B022B6@oracle.com>

Hi Christoph,

Thank you for looking into this.

Overall, I think this is OK.  Not sure there is currently any downside to removing the JAR FS right now outside of keeping the multi-release code separate.

I would suggesting moving the code added to the constructor for checking the releaseVersion/multi-release properties to a method and grouping it with the other methods added for supporting MR jars around line 1396. (keeps it easier to follow and maintain)

Could you also add a comment above the isMultiReleaseJar method to for clarity going forward (I know there was not one there before)

I might change the name of the lookup field in the method makeParentDirs with the addition of the Function lookup on line 126.

The methods in JarFileSystemProvider getPath and uriToPath are slightly different in ZipFileSystemProvider.  That being said, I do not see anything obvious of concern but wanted to point it out.

The test changes look fine 

Again, thanks for your efforts to improve Zip FS

Best
Lance

> On Nov 14, 2019, at 10:23 AM, Langer, Christoph  wrote:
> 
> Hi,
>  
> after exchanging some direct mails with Lance, I came to the conclusion that the current behavior to ignore file system property ?multi-release? when ?releaseVersion? is explicitly set to null is the right thing to do. So I updated the webrev to reinstate this functionality and added explicit comments as well as augmenting MultiReleaseJarTest.java a little bit to test that ?multi-release? is ignored in the right places.
>  
> This is the new webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234089.1/ 
>  
> Best regards
> Christoph
>  
>  
> From: Langer, Christoph 
> Sent: Mittwoch, 13. November 2019 17:42
> To: core-libs-dev at openjdk.java.net ; nio-dev >
> Subject: RFR: 8234089: (zipfs) Remove classes JarFileSystemProvider and JarFileSystem
>  
> Hi,
>  
> can I please get reviews for this cleanup change in zipfs.
>  
> Bug: https://bugs.openjdk.java.net/browse/JDK-8234089 
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234089.0/ 
>  
> I figured that JarFileSystemProvider is completely obsolete (please correct me if I?m wrong) and the reasons for having a class JarFileSystem that extends ZipFileSystems are very little in my opinion. I think maintainability is better when the few implementation details of multi release jars live in ZipFileSystem as well. It saves some code. The only possible drawback is that ZipFileSystem:: getInode would have an additional call to a lookup function, that usually is an identity transformation. I would hope however, that runtime impact is negligible.
>  
> I also fix a small bug when property ?releaseVersion? is set to null in the env map and multi-release contains a value. In the current implementation it would not consider the ?multi-release? value and treat the mr jar as the current runtime version. I had to do a small fix in MultiReleaseJarTest.java to make sure the properties list is cleared in every case.
>  
> The jdk/nio/zipfs tests run well after my change.
>  
> 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 mandy.chung at oracle.com  Fri Nov 15 02:04:20 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 14 Nov 2019 18:04:20 -0800
Subject: RFR JDK-8233527: Update Lookup::hasPrivateAccess and
 Lookup::defineClass spec w.r.t. full power lookup
In-Reply-To: <2d4b50dd-e19f-9c40-60c4-b4c36751601d@oracle.com>
References: <081f506c-62a9-dd98-8b62-04690f4cba14@oracle.com>
 <083da65f-e1a5-4f30-9d15-cf69df1918ec@j-kuhn.de>
 <94a4b52c-b47d-f861-54d5-6d661991b67b@oracle.com>
 <6bb905bf-8803-cc9e-ea28-49da6685a78b@j-kuhn.de>
 <97aefa43-ada4-a0a6-df3b-eb5c350a8a0f@oracle.com>
 <61d471dd-42ac-02cb-75e2-de63dadc3763@oracle.com>
 
 <2a4f6ff4-e6bb-b988-b3f2-ca0f9ea8d1f5@oracle.com>
 <2d4b50dd-e19f-9c40-60c4-b4c36751601d@oracle.com>
Message-ID: 



On 11/14/19 5:04 PM, David Holmes wrote:
> Hi Mandy,
>
> On 15/11/2019 10:51 am, Mandy Chung wrote:
>>
>>
>> On 11/14/19 8:04 AM, Mandy Chung wrote:
>>>
>>>
>>> On 11/14/19 2:33 AM, Alan Bateman wrote:
>>>> On 14/11/2019 04:57, Mandy Chung wrote:
>>>>>
>>>>> Updated in place:
>>>>>
>>>>> http://cr.openjdk.java.net/~mchung/jdk14/8233527/webrev.02/
>>>>> http://cr.openjdk.java.net/~mchung/jdk14/8233527/specdiff/
>>>> The addition of hasFullPrivilegeAccess looks okay and probably the 
>>>> right thing to do.
>>>>
>>>> For the @deprecated message on the old method it might be simpler 
>>>> to say that the method was originally designed to test PRIVATE 
>>>> access but has since changed to test full privilege access. 
>>>
>>> It was designed to test full privilege access while private access 
>>> implies full privilege access as a Lookup with private access 
>>> includes module access.
>>>
>>
>> I updated to:
>>
>> This method was originally designed to test PRIVATE access that 
>> implies full privilege access but PRIVATE access has since become 
>> independent of PRIVATE access. It is recommended to call 
>> hasFullPrivilegeAccess() instead.
>
> That doesn't read correctly: "PRIVATE" is independent of "PRIVATE" ??
>

Dunno how I got that typo :( thanks for catching it.

This method was originally designed to test PRIVATE access that implies 
full privilege access but MODULE access has since become independent of 
PRIVATE access. It is recommended to call hasFullPrivilegeAccess() instead.

Mandy

> David
>
>> http://cr.openjdk.java.net/~mchung/jdk14//8233527/specdiff/java.base/java/lang/invoke/MethodHandles.Lookup.html 
>>
>>
>> Mandy


From jai.forums2013 at gmail.com  Fri Nov 15 04:11:48 2019
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Fri, 15 Nov 2019 09:41:48 +0530
Subject: ZipFileSystem and the impact of JDK-8031748 on ordering of
 MANIFEST files in the created jars
In-Reply-To: <1856C8B1-CB9B-45D8-BEFC-340CA66AE476@oracle.com>
References: <9766726a-3c83-a1e8-5caf-39ef9ce9842a@gmail.com>
 <2ab1ed01-8d9a-9175-cf9b-51e6f81b212e@gmail.com>
 <1856C8B1-CB9B-45D8-BEFC-340CA66AE476@oracle.com>
Message-ID: <93237b1b-4cb4-bd9a-8292-9fae6f7a02f9@gmail.com>

Hello Lance,

On 14/11/19 9:35 PM, Lance Andersen wrote:
> ...
>
> There is an existing Zip FS enhancement
> request,?https://bugs.openjdk.java.net/browse/JDK-8211917.?

Thank you, I hadn't noticed this one before sending this mail. I'll keep
a watch on this one.

-Jaikiran


From christoph.langer at sap.com  Fri Nov 15 08:40:20 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 15 Nov 2019 08:40:20 +0000
Subject: RFR: 8234089: (zipfs) Remove classes JarFileSystemProvider and
 JarFileSystem
In-Reply-To: <3532D7A1-DF2F-41BF-80BF-09EF53B022B6@oracle.com>
References: 
 <3532D7A1-DF2F-41BF-80BF-09EF53B022B6@oracle.com>
Message-ID: 

Hi Lance,

thanks for reviewing. I've addressed your points:

> I would suggesting moving the code added to the constructor for checking
> the releaseVersion/multi-release properties to a method and grouping it
> with the other methods added for supporting MR jars around line 1396.
> (keeps it easier to follow and maintain)

Done that.

> Could you also add a comment above the isMultiReleaseJar method to for
> clarity going forward (I know there was not one there before)

Done, too.

> I might change the name of the lookup field in the method makeParentDirs
> with the addition of the Function lookup on line 126.

I chose to change the name of the global field in line 126 to be named mrlookup. Also updated the comment.

This is the new webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234089.2/

Cheers
Christoph


From peter.levart at gmail.com  Fri Nov 15 09:32:18 2019
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 15 Nov 2019 10:32:18 +0100
Subject: RFR JDK-8233527: Update Lookup::hasPrivateAccess and
 Lookup::defineClass spec w.r.t. full power lookup
In-Reply-To: <081f506c-62a9-dd98-8b62-04690f4cba14@oracle.com>
References: <081f506c-62a9-dd98-8b62-04690f4cba14@oracle.com>
Message-ID: <460ffa29-a022-b5df-4c53-6f44a5b16394@gmail.com>

Hi Mandy,

>
> http://cr.openjdk.java.net/~mchung/jdk14/8233527/webrev.03/

In Lookup's findBoundCallerClass and checkSecurityManager the javadoc is 
still talking about private access only although the checks are now made 
against full privilege access.



Some possible nano optimization / simplification suggestions. Take each 
with a grain of salt...


 ??????? public Class defineClass(byte[] bytes) throws 
IllegalAccessException {
 ??????????? if (allowedModes != TRUSTED && !hasFullPrivilegeAccess()) {


TRUSTED == -1, which has all bits set. Therefore allowedModes == TRUSTED 
implies hasFullPrivilegeAccess(). In other words, 
!hasFullPrivilegeAccess() implies allowedModes != TRUSTED. Above 
condition could be simplified to:

if (!hasFullPrivilegeAccess()) { ...


Please correct me if I'm wrong: All final instance fields in 
java.lang.invoke package are treated as though they were annotated with 
@Stable right? If that is the case, then all these checks will be folded 
into a constant if Lookup instance can be folded into a constant when 
JITed, since allowedModes field is final. But anyway, less branches in 
code sometimes makes code faster. In this respect, the following:

 ??????? public boolean hasFullPrivilegeAccess() {
 ??????????? return (allowedModes & PRIVATE) != 0 && (allowedModes & 
MODULE) != 0;
 ??????? }

...could also be written as:

 ??????? public boolean hasFullPrivilegeAccess() {
 ??????????? return (allowedModes & (PRIVATE | MODULE)) == (PRIVATE | 
MODULE);
 ??????? }

So it's just a matter of taste probably which one is nicer to read.

Also in the following part:

 ??????? void checkSecurityManager(Class refc, MemberName m) {
 ??????????? SecurityManager smgr = System.getSecurityManager();
 ??????????? if (smgr == null)? return;
 ??????????? if (allowedModes == TRUSTED)? return;

...the allowedModes == TRUSTED may be folded into a constant, while 
security manager check above can not. Perhaps JIT is smart enough to 
reorder these two checks since they both have the same path (return), 
but if it doesn't, reordering them in code might be more optimal:

 ??????? void checkSecurityManager(Class refc, MemberName m) {
 ??????????? if (allowedModes == TRUSTED)? return;
 ??????????? SecurityManager smgr = System.getSecurityManager();
 ??????????? if (smgr == null)? return;



Regards, Peter


From Alan.Bateman at oracle.com  Fri Nov 15 10:59:33 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 15 Nov 2019 10:59:33 +0000
Subject: 8179320: File.getUsableSpace() returns a negative number on very
 large file system
In-Reply-To: <674F3B84-3737-4F55-8D2B-B1777F91203E@oracle.com>
References: <674F3B84-3737-4F55-8D2B-B1777F91203E@oracle.com>
Message-ID: <5328f442-ebdc-87bb-b79a-881d3f9986ac@oracle.com>

On 02/11/2019 00:13, Brian Burkhalter wrote:
> For this issue [1], please review this patch [2] and the corresponding CSR [3].
>
>
One thing that isn't clear is how these methods behave when the space 
info can't be obtained. It is specified to return 0L when the path is 
not "a partition" but I think it also returns 0L when the information 
cannot be obtained.

-Alan

From simonisv at amazon.de  Fri Nov 15 11:30:28 2019
From: simonisv at amazon.de (Volker Simonis)
Date: Fri, 15 Nov 2019 12:30:28 +0100
Subject: RFR(XS): 8234011: (zipfs) Memory leak in
 ZipFileSystem.releaseDeflater()
In-Reply-To: 
References: <1573658564822.16574@amazon.de>
 
 <45B01685-8D87-4171-BD84-778659680C67@oracle.com>
 
 <69AB1167-0598-4B51-9A18-31BF0F6A9701@oracle.com>
 
 
 
Message-ID: <8e4ca29b-8bec-c96e-ab32-56ea10aba94f@amazon.de>

On 14.11.19 18:24, Langer, Christoph wrote:
> Hi Volker,
> 
> funny, I didn?t get aware of your mails until I now recognized that my 
> mail client moved your mail into the ?Amazon-advertisement-spam? folder 
> of my mailbox. ?? I have to check and modify my filter rules?
> 
> Ok, let?s continue the little bike-shed about the test then.
> 
> First, thanks for making the adaptions. The test looks better already. I 
> still have a few points:
> 
> 1. The imports of java.io.File and java.util.HashMap can be removed now.
> 

Done.

> 2. The two try statements in lines 54 and 55 look a bit awkward. I guess 
> you could just use the one try-with-resource from line 55 and put the 
> cleanup in its finally block.
> 

Done.

> 3. Maybe you also want to attempt a Files.deleteIfExists(zipFile); 
> before opening the Zip file system? Otherwise there is a remote 
> possibility that ReleaseDeflaterTest.zip already exists and the test 
> will fail because of this.
> 

That doesn't harm. The file will just be reused.

> 4. I?m also not a fan of the SkippedException here. I for myself would 
> probably not get aware of a skip. And if somebody changes the 
> implementation of ZipFileSystem, why shouldn?t he/she/? immediately 
> recognize this and adapt the test in the same change?
> 

OK, changed it to a RuntimeException now.

Here's the new webrev:

http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011.v3

> Best regards
> 
> Christoph
> 
> *From:* Lance Andersen 
> *Sent:* Donnerstag, 14. November 2019 17:38
> *To:* Volker Simonis 
> *Cc:* Langer, Christoph ; Simonis, Volker 
> ; core-libs-dev at openjdk.java.net
> *Subject:* Re: RFR(XS): 8234011: (zipfs) Memory leak in 
> ZipFileSystem.releaseDeflater()
> 
>     On Nov 14, 2019, at 11:27 AM, Volker Simonis      > wrote:
> 
>     On 14.11.19 16:27, Lance Andersen wrote:
> 
>         Hi Volker,
> 
>             On Nov 14, 2019, at 8:53 AM, Volker Simonis
>                          > wrote:
> 
>             On 13.11.19 18:54, Lance Andersen wrote:
> 
>                 Hi Volker,
>                 Thank you for doing this.
>                 As Christoph mentioned, ?you can just do Path.of() and
>                 create the file in the work directory for the test.
> 
> 
>             Done.
> 
> 
>                 If possible, I would use TestNG as that is consistent
>                 with the vast majority of the tests.
> 
> 
>             I don't particularly like to nest one test harness within
>             another one :)
>             But seriously, I think using JUnit or TestNG makes sens if
>             you write a whole test suit which uses the features of such
>             a test harness (e.g. tear up, tear down, etc.)
> 
>         Well you could use @AfterMethod or @AfterClass to clean up files
>         etc? ;-)
> 
>             But for small trivial tests I really prefer to use plain
>             JTreg. This also has the big advantage that is becomes
>             trivial to run such a test stand-alone which may come handy
>             if you have to debug it.
> 
>         Easy enough to add a main method to call your test method (there
>         are some testng tests I have seen in the workspace that do that)
> 
> 
>             So if you don't insist, I'll prefer to leave the test as it is.
> 
>         While I would prefer it for new tests, I am not insisting you
>         need to change the test?.. ;-)
> 
> 
>     OK, thanks. I might consider using it in the future :)
> 
> 
> 
> 
>                 I also believe the rest of the comments below are worth
>                 addressing.
> 
> 
>             Besides that, I've addressed all the other points mentioned
>             by Christoph. Please find the new webrev at:
> 
>             http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011.v1/
> 
>         line 55 you can remove the creation of the HashMap
> 
> 
>     Good catch! Removed.
> 
> 
>         line 73, do you really need the equals check seeing you do not
>         do anything?
> 
> 
>     Removed. It was a leftover of local testing.
> 
> 
>         I am not sure throwing a SkippedException is correct, ?I would
>         probably throw a RuntimeException
> 
> 
>     As I wrote in the answer to Christoph, this is a relatively new
>     feature of JTreg [1] which I think was introduced for exactly such
>     kind of situations where a tests detects at runtime only, that for
>     some reasons he can't test the issue he was supposed to test. More
>     and more tests are adapting it now [2]. The SkippedException will be
>     handled specially by JTreg and let the test pass, but with status
>     "Passed.Skipped" (plus exception message) instead of just "Passed"
>     (plis "Execution successful").
> 
>     Here's the next webrev:
> 
>     http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011.v2/
> 
> Thank you for the updates. ?I am still a bit skeptical of the use of 
> SkippedException here as you would never see the test is no longer 
> passing due to an implementation change unless you are specifically 
> looking for it.
> 
> That being said, ?if others who have more experience with using this 
> Exception in a similar scenario are good, then I am good.
> 
> So once we get a couple of other views on this from others with a thumbs 
> up for using SkippedException here, we are good to go :-)
> 
> Best
> 
> Lance
> 
> 
> 
> 
>     Thanks,
>     Volker
> 
>     [1]https://openjdk.java.net/jtreg/faq.html#what-if-a-test-does-not-apply-in-a-given-situation
>     [2]https://bugs.openjdk.java.net/browse/JDK-8208655
> 
> 
>         Best
>         Lance
> 
> 
>             Thank you and best regards,
>             Volker
> 
> 
>                 Thank you again for the fix
>                 Best
>                 Lance
> 
>                     On Nov 13, 2019, at 11:26 AM, Langer, Christoph
>                                          
>                     > wrote:
> 
>                     Hi Volker,
> 
>                     good catch in ZipFileSystem ??The fix is the right
>                     thing to do.
> 
>                     I have a few remarks to the test, though:
> 
>                     Line 52, initialization of the File object: I think
>                     you should just do Path zipFile =
>                     Paths.get("file.zip"); When the test is run in the
>                     jtreg framework, it's running in its own scratch
>                     directory, so no need to use java.io.tmpdir. You can
>                     also leave cleanup to jtreg and don't need to delete
>                     the file in the end (in the finally block). However,
>                     you should probably check whether the file exists in
>                     the beginning and delete it in that case.
> 
>                     Line 55ff: You don't need to use this URI thing any
>                     more. You can simply do: try (FileSystem fs =
>                     FileSystems.newFileSystem(zipFile, Map.of("create",
>                     true))) { (line 58).
> 
>                     Line 61/62: You're using a Vector, wow ??You should
>                     rather use ArrayList, I think...
> 
>                     Line 85: This should rather be:
>                      ???????????????????@SuppressWarnings("unchecked")
>                      ???????????????????int inflater_count =
>                     ((List)inflaters.get(fs)).size();
>                     Same for line 89.
> 
>                     Line 93 (Catch clause): I think we should fail in
>                     that case, too. Otherwise, if the implementation
>                     would change, the test could run unnoticed for
>                     years, testing basically nothing...
> 
>                     Best regards,
>                     Christoph
> 
> 
> 
>                         -----Original Message-----
>                         From: core-libs-dev
>                                                  
>                         >
>                         On Behalf
>                         Of Simonis, Volker
>                         Sent: Mittwoch, 13. November 2019 16:23
>                         To:core-libs-dev at openjdk.java.net
>                         
>                         
>                         Subject: RFR(XS): 8234011: (zipfs) Memory leak in
>                         ZipFileSystem.releaseDeflater()
> 
>                         Hi,
> 
>                         can I please get a review for this trivial fix
>                         of an old copy-and-paste error:
> 
>                         http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011/
>                         https://bugs.openjdk.java.net/browse/JDK-8234011
> 
>                         ZipFileSystem caches MAX_FLATER (currently 20)
>                         Inflater/Deflater objects.
>                         However the logic for reusing Deflaters is wrong
>                         because it references the
>                         Inflater List when checking against the number
>                         of already cached objects.
>                         This seems like a day-one copy and paste error.
> 
>                         Notice that this issue is not as critical as it
>                         appears, because retaining of
>                         additional Deflaters only happens when more than
>                         MAX_FLATER are used
>                         and released concurrently. I.e. the maximum
>                         number of cached Deflaters is
>                         the maximal number of Deflaters that are
>                         released while no new Deflater is
>                         requested. In practice this is usually still a
>                         small number, less than
>                         MAX_FLATERS. Nevertheless we can easily
>                         construct an example which
>                         demonstrates the memory leak (see the JTRegtest
>                         in the patch) and because
>                         the fix is trivial we should really fix this.
> 
>                         Thank you and best regards,
>                         Volker
> 
> 
> 
>                         Amazon Development Center Germany GmbH
>                         Krausenstr. 38
>                         10117 Berlin
>                         Geschaeftsfuehrung: Christian Schlaeger, Ralf
>                         Herbrich
>                         Eingetragen am Amtsgericht Charlottenburg unter
>                         HRB 149173 B
>                         Sitz: Berlin
>                         Ust-ID: DE 289 237 879
> 
>                 
>                 
>                 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
>                 
>                 
> 
> 
> 
> 
> 
>             Amazon Development Center Germany GmbH
>             Krausenstr. 38
>             10117 Berlin
>             Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
>             Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
>             Sitz: Berlin
>             Ust-ID: DE 289 237 879
> 
>         
>         
>         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 
>         
> 
> 
> 
> 
> 
>     Amazon Development Center Germany GmbH
>     Krausenstr. 38
>     10117 Berlin
>     Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
>     Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
>     Sitz: Berlin
>     Ust-ID: DE 289 237 879
> 
> 
> 
> 
> 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 
> 
> 
> 




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



From simonisv at amazon.de  Fri Nov 15 11:32:39 2019
From: simonisv at amazon.de (Volker Simonis)
Date: Fri, 15 Nov 2019 12:32:39 +0100
Subject: RFR(XS): 8234011: (zipfs) Memory leak in
 ZipFileSystem.releaseDeflater()
In-Reply-To: <0C0555C2-47DA-472D-AF6D-6F8E451D7496@oracle.com>
References: <1573658564822.16574@amazon.de>
 
 <45B01685-8D87-4171-BD84-778659680C67@oracle.com>
 
 <69AB1167-0598-4B51-9A18-31BF0F6A9701@oracle.com>
 
 
 
 <0C0555C2-47DA-472D-AF6D-6F8E451D7496@oracle.com>
Message-ID: 

On 14.11.19 21:20, Lance Andersen wrote:
> Hi Volker,
>> On Nov 14, 2019, at 12:05 PM, Volker Simonis > > wrote:
>>
>> On 14.11.19 17:38, Lance Andersen wrote:
>>>> On Nov 14, 2019, at 11:27 AM, Volker Simonis >>>  > wrote:
>>>>
>>>>
>>>>> I am not sure throwing a SkippedException is correct, ?I would 
>>>>> probably throw a RuntimeException
>>>>
>>>> As I wrote in the answer to Christoph, this is a relatively new 
>>>> feature of JTreg [1] which I think was introduced for exactly such 
>>>> kind of situations where a tests detects at runtime only, that for 
>>>> some reasons he can't test the issue he was supposed to test. More 
>>>> and more tests are adapting it now [2]. The SkippedException will be 
>>>> handled specially by JTreg and let the test pass, but with status 
>>>> "Passed.Skipped" (plus exception message) instead of just "Passed" 
>>>> (plis "Execution successful").
>>>>
>>>> Here's the next webrev:
>>>>
>>>> http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011.v2/
>>> Thank you for the updates. ?I am still a bit skeptical of the use of 
>>> SkippedException here as you would never see the test is no longer 
>>> passing due to an implementation change unless you are specifically 
>>> looking for it.
>>> That being said, ?if others who have more experience with using this 
>>> Exception in a similar scenario are good, then I am good.
>>> So once we get a couple of other views on this from others with a 
>>> thumbs up for using SkippedException here, we are good to go :-)
>>
>> If this is the last blocker, I'm actually not insisting this time :)
>>
>> Do you think it is better to just throw an exception and let the test 
>> fail if the underlying implementation changes? I thought it is better 
>> to be more conservative, because that would be actually a mistake in 
>> the test and not an error in the testee. But if you think it would be 
>> more appropriate to fail in such a case, I'm happy to change it?
> 
> I do think it would be best to fail as if the implementation is changed 
> and it impacts the test, we would want to make sure we update it at the 
> same time.
> 

OK, changed it to a RuntimeException (together with some other minor 
tweaks requested by Christoph in his last mail).

Here's the new webrev:

http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011.v3

OK now?

> Best
> Lance
>>
>>> Best
>>> Lance
>>>>
>>>> Thanks,
>>>> Volker
>>>>
>>>> [1]https://openjdk.java.net/jtreg/faq.html#what-if-a-test-does-not-apply-in-a-given-situation
>>>> [2]https://bugs.openjdk.java.net/browse/JDK-8208655
>>>>
>>>>> Best
>>>>> Lance
>>>>>>
>>>>>> Thank you and best regards,
>>>>>> Volker
>>>>>>
>>>>>>> Thank you again for the fix
>>>>>>> Best
>>>>>>> Lance
>>>>>>>> On Nov 13, 2019, at 11:26 AM, Langer, Christoph 
>>>>>>>>  
>>>>>>>>  
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>> Hi Volker,
>>>>>>>>
>>>>>>>> good catch in ZipFileSystem ?? The fix is the right thing to do.
>>>>>>>>
>>>>>>>> I have a few remarks to the test, though:
>>>>>>>>
>>>>>>>> Line 52, initialization of the File object: I think you should 
>>>>>>>> just do Path zipFile = Paths.get("file.zip"); When the test is 
>>>>>>>> run in the jtreg framework, it's running in its own scratch 
>>>>>>>> directory, so no need to use java.io.tmpdir. You can also leave 
>>>>>>>> cleanup to jtreg and don't need to delete the file in the end 
>>>>>>>> (in the finally block). However, you should probably check 
>>>>>>>> whether the file exists in the beginning and delete it in that case.
>>>>>>>>
>>>>>>>> Line 55ff: You don't need to use this URI thing any more. You 
>>>>>>>> can simply do: try (FileSystem fs = 
>>>>>>>> FileSystems.newFileSystem(zipFile, Map.of("create", true))) { 
>>>>>>>> (line 58).
>>>>>>>>
>>>>>>>> Line 61/62: You're using a Vector, wow ?? You should rather use 
>>>>>>>> ArrayList, I think...
>>>>>>>>
>>>>>>>> Line 85: This should rather be:
>>>>>>>> ???????????????????@SuppressWarnings("unchecked")
>>>>>>>> ???????????????????int inflater_count = 
>>>>>>>> ((List)inflaters.get(fs)).size();
>>>>>>>> Same for line 89.
>>>>>>>>
>>>>>>>> Line 93 (Catch clause): I think we should fail in that case, 
>>>>>>>> too. Otherwise, if the implementation would change, the test 
>>>>>>>> could run unnoticed for years, testing basically nothing...
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Christoph
>>>>>>>>
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: core-libs-dev >>>>>>>>  
>>>>>>>>>  
>>>>>>>>> > On Behalf
>>>>>>>>> Of Simonis, Volker
>>>>>>>>> Sent: Mittwoch, 13. November 2019 16:23
>>>>>>>>> To:core-libs-dev at openjdk.java.net 
>>>>>>>>>  
>>>>>>>>>  
>>>>>>>>> 
>>>>>>>>> Subject: RFR(XS): 8234011: (zipfs) Memory leak in
>>>>>>>>> ZipFileSystem.releaseDeflater()
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> can I please get a review for this trivial fix of an old 
>>>>>>>>> copy-and-paste error:
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011/
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8234011
>>>>>>>>>
>>>>>>>>> ZipFileSystem caches MAX_FLATER (currently 20) 
>>>>>>>>> Inflater/Deflater objects.
>>>>>>>>> However the logic for reusing Deflaters is wrong because it 
>>>>>>>>> references the
>>>>>>>>> Inflater List when checking against the number of already 
>>>>>>>>> cached objects.
>>>>>>>>> This seems like a day-one copy and paste error.
>>>>>>>>>
>>>>>>>>> Notice that this issue is not as critical as it appears, 
>>>>>>>>> because retaining of
>>>>>>>>> additional Deflaters only happens when more than MAX_FLATER are 
>>>>>>>>> used
>>>>>>>>> and released concurrently. I.e. the maximum number of cached 
>>>>>>>>> Deflaters is
>>>>>>>>> the maximal number of Deflaters that are released while no new 
>>>>>>>>> Deflater is
>>>>>>>>> requested. In practice this is usually still a small number, 
>>>>>>>>> less than
>>>>>>>>> MAX_FLATERS. Nevertheless we can easily construct an example which
>>>>>>>>> demonstrates the memory leak (see the JTRegtest in the patch) 
>>>>>>>>> and because
>>>>>>>>> the fix is trivial we should really fix this.
>>>>>>>>>
>>>>>>>>> Thank you and best regards,
>>>>>>>>> Volker
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Amazon Development Center Germany GmbH
>>>>>>>>> Krausenstr. 38
>>>>>>>>> 10117 Berlin
>>>>>>>>> Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
>>>>>>>>> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
>>>>>>>>> Sitz: Berlin
>>>>>>>>> Ust-ID: DE 289 237 879
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>> 
>>>>>>> 
>>>>>>> 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  
>>>>>>>  
>>>>>>> 
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Amazon Development Center Germany GmbH
>>>>>> Krausenstr. 38
>>>>>> 10117 Berlin
>>>>>> Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
>>>>>> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
>>>>>> Sitz: Berlin
>>>>>> Ust-ID: DE 289 237 879
>>>>>>
>>>>>>
>>>>> 
>>>>> 
>>>>> 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  
>>>>>  
>>>>
>>>>
>>>>
>>>>
>>>> Amazon Development Center Germany GmbH
>>>> Krausenstr. 38
>>>> 10117 Berlin
>>>> Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
>>>> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
>>>> Sitz: Berlin
>>>> Ust-ID: DE 289 237 879
>>> 
>>> 
>>> 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  
>>> 
>>
>>
>>
>>
>> Amazon Development Center Germany GmbH
>> Krausenstr. 38
>> 10117 Berlin
>> Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
>> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
>> Sitz: Berlin
>> Ust-ID: DE 289 237 879
>>
>>
> 
> 
> 
> 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 
> 
> 
> 




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



From christoph.langer at sap.com  Fri Nov 15 12:44:54 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 15 Nov 2019 12:44:54 +0000
Subject: RFR(XS): 8234011: (zipfs) Memory leak in
 ZipFileSystem.releaseDeflater()
In-Reply-To: <8e4ca29b-8bec-c96e-ab32-56ea10aba94f@amazon.de>
References: <1573658564822.16574@amazon.de>
 
 <45B01685-8D87-4171-BD84-778659680C67@oracle.com>
 
 <69AB1167-0598-4B51-9A18-31BF0F6A9701@oracle.com>
 
 
 
 <8e4ca29b-8bec-c96e-ab32-56ea10aba94f@amazon.de>
Message-ID: 

Hi Volker,

Looks awesome now ??

Please remove the "import java.nio.file.Files;" statement before pushing.

Cheers
Christoph


> -----Original Message-----
> From: Volker Simonis 
> Sent: Freitag, 15. November 2019 12:30
> To: Langer, Christoph ; Volker Simonis
> 
> Cc: core-libs-dev at openjdk.java.net; Lance Andersen
> 
> Subject: Re: RFR(XS): 8234011: (zipfs) Memory leak in
> ZipFileSystem.releaseDeflater()
> 
> On 14.11.19 18:24, Langer, Christoph wrote:
> > Hi Volker,
> >
> > funny, I didn?t get aware of your mails until I now recognized that my
> > mail client moved your mail into the ?Amazon-advertisement-spam? folder
> > of my mailbox. ?? I have to check and modify my filter rules?
> >
> > Ok, let?s continue the little bike-shed about the test then.
> >
> > First, thanks for making the adaptions. The test looks better already. I
> > still have a few points:
> >
> > 1. The imports of java.io.File and java.util.HashMap can be removed now.
> >
> 
> Done.
> 
> > 2. The two try statements in lines 54 and 55 look a bit awkward. I guess
> > you could just use the one try-with-resource from line 55 and put the
> > cleanup in its finally block.
> >
> 
> Done.
> 
> > 3. Maybe you also want to attempt a Files.deleteIfExists(zipFile);
> > before opening the Zip file system? Otherwise there is a remote
> > possibility that ReleaseDeflaterTest.zip already exists and the test
> > will fail because of this.
> >
> 
> That doesn't harm. The file will just be reused.
> 
> > 4. I?m also not a fan of the SkippedException here. I for myself would
> > probably not get aware of a skip. And if somebody changes the
> > implementation of ZipFileSystem, why shouldn?t he/she/? immediately
> > recognize this and adapt the test in the same change?
> >
> 
> OK, changed it to a RuntimeException now.
> 
> Here's the new webrev:
> 
> http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011.v3
> 
> > Best regards
> >
> > Christoph
> >
> > *From:* Lance Andersen 
> > *Sent:* Donnerstag, 14. November 2019 17:38
> > *To:* Volker Simonis 
> > *Cc:* Langer, Christoph ; Simonis, Volker
> > ; core-libs-dev at openjdk.java.net
> > *Subject:* Re: RFR(XS): 8234011: (zipfs) Memory leak in
> > ZipFileSystem.releaseDeflater()
> >
> >     On Nov 14, 2019, at 11:27 AM, Volker Simonis  >     > wrote:
> >
> >     On 14.11.19 16:27, Lance Andersen wrote:
> >
> >         Hi Volker,
> >
> >             On Nov 14, 2019, at 8:53 AM, Volker Simonis
> >              >             >
> wrote:
> >
> >             On 13.11.19 18:54, Lance Andersen wrote:
> >
> >                 Hi Volker,
> >                 Thank you for doing this.
> >                 As Christoph mentioned, ?you can just do Path.of() and
> >                 create the file in the work directory for the test.
> >
> >
> >             Done.
> >
> >
> >                 If possible, I would use TestNG as that is consistent
> >                 with the vast majority of the tests.
> >
> >
> >             I don't particularly like to nest one test harness within
> >             another one :)
> >             But seriously, I think using JUnit or TestNG makes sens if
> >             you write a whole test suit which uses the features of such
> >             a test harness (e.g. tear up, tear down, etc.)
> >
> >         Well you could use @AfterMethod or @AfterClass to clean up files
> >         etc? ;-)
> >
> >             But for small trivial tests I really prefer to use plain
> >             JTreg. This also has the big advantage that is becomes
> >             trivial to run such a test stand-alone which may come handy
> >             if you have to debug it.
> >
> >         Easy enough to add a main method to call your test method (there
> >         are some testng tests I have seen in the workspace that do that)
> >
> >
> >             So if you don't insist, I'll prefer to leave the test as it is.
> >
> >         While I would prefer it for new tests, I am not insisting you
> >         need to change the test?.. ;-)
> >
> >
> >     OK, thanks. I might consider using it in the future :)
> >
> >
> >
> >
> >                 I also believe the rest of the comments below are worth
> >                 addressing.
> >
> >
> >             Besides that, I've addressed all the other points mentioned
> >             by Christoph. Please find the new webrev at:
> >
> >             http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011.v1/
> >
> >         line 55 you can remove the creation of the HashMap
> >
> >
> >     Good catch! Removed.
> >
> >
> >         line 73, do you really need the equals check seeing you do not
> >         do anything?
> >
> >
> >     Removed. It was a leftover of local testing.
> >
> >
> >         I am not sure throwing a SkippedException is correct, ?I would
> >         probably throw a RuntimeException
> >
> >
> >     As I wrote in the answer to Christoph, this is a relatively new
> >     feature of JTreg [1] which I think was introduced for exactly such
> >     kind of situations where a tests detects at runtime only, that for
> >     some reasons he can't test the issue he was supposed to test. More
> >     and more tests are adapting it now [2]. The SkippedException will be
> >     handled specially by JTreg and let the test pass, but with status
> >     "Passed.Skipped" (plus exception message) instead of just "Passed"
> >     (plis "Execution successful").
> >
> >     Here's the next webrev:
> >
> >     http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011.v2/
> >
> > Thank you for the updates. ?I am still a bit skeptical of the use of
> > SkippedException here as you would never see the test is no longer
> > passing due to an implementation change unless you are specifically
> > looking for it.
> >
> > That being said, ?if others who have more experience with using this
> > Exception in a similar scenario are good, then I am good.
> >
> > So once we get a couple of other views on this from others with a thumbs
> > up for using SkippedException here, we are good to go :-)
> >
> > Best
> >
> > Lance
> >
> >
> >
> >
> >     Thanks,
> >     Volker
> >
> >     [1]https://openjdk.java.net/jtreg/faq.html#what-if-a-test-does-not-
> apply-in-a-given-situation
> >     [2]https://bugs.openjdk.java.net/browse/JDK-8208655
> >
> >
> >         Best
> >         Lance
> >
> >
> >             Thank you and best regards,
> >             Volker
> >
> >
> >                 Thank you again for the fix
> >                 Best
> >                 Lance
> >
> >                     On Nov 13, 2019, at 11:26 AM, Langer, Christoph
> >                      >
> 
> >                     > wrote:
> >
> >                     Hi Volker,
> >
> >                     good catch in ZipFileSystem ??The fix is the right
> >                     thing to do.
> >
> >                     I have a few remarks to the test, though:
> >
> >                     Line 52, initialization of the File object: I think
> >                     you should just do Path zipFile =
> >                     Paths.get("file.zip"); When the test is run in the
> >                     jtreg framework, it's running in its own scratch
> >                     directory, so no need to use java.io.tmpdir. You can
> >                     also leave cleanup to jtreg and don't need to delete
> >                     the file in the end (in the finally block). However,
> >                     you should probably check whether the file exists in
> >                     the beginning and delete it in that case.
> >
> >                     Line 55ff: You don't need to use this URI thing any
> >                     more. You can simply do: try (FileSystem fs =
> >                     FileSystems.newFileSystem(zipFile, Map.of("create",
> >                     true))) { (line 58).
> >
> >                     Line 61/62: You're using a Vector, wow ??You should
> >                     rather use ArrayList, I think...
> >
> >                     Line 85: This should rather be:
> >                      ???????????????????@SuppressWarnings("unchecked")
> >                      ???????????????????int inflater_count =
> >                     ((List)inflaters.get(fs)).size();
> >                     Same for line 89.
> >
> >                     Line 93 (Catch clause): I think we should fail in
> >                     that case, too. Otherwise, if the implementation
> >                     would change, the test could run unnoticed for
> >                     years, testing basically nothing...
> >
> >                     Best regards,
> >                     Christoph
> >
> >
> >
> >                         -----Original Message-----
> >                         From: core-libs-dev
> >                          >                          bounces at openjdk.java.net> bounces at openjdk.java.net>
> >                         >
> >                         On Behalf
> >                         Of Simonis, Volker
> >                         Sent: Mittwoch, 13. November 2019 16:23
> >                         To:core-libs-dev at openjdk.java.net
> >                          dev at openjdk.java.net>
> >                         
> >                         Subject: RFR(XS): 8234011: (zipfs) Memory leak in
> >                         ZipFileSystem.releaseDeflater()
> >
> >                         Hi,
> >
> >                         can I please get a review for this trivial fix
> >                         of an old copy-and-paste error:
> >
> >                         http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011/
> >                         https://bugs.openjdk.java.net/browse/JDK-8234011
> >
> >                         ZipFileSystem caches MAX_FLATER (currently 20)
> >                         Inflater/Deflater objects.
> >                         However the logic for reusing Deflaters is wrong
> >                         because it references the
> >                         Inflater List when checking against the number
> >                         of already cached objects.
> >                         This seems like a day-one copy and paste error.
> >
> >                         Notice that this issue is not as critical as it
> >                         appears, because retaining of
> >                         additional Deflaters only happens when more than
> >                         MAX_FLATER are used
> >                         and released concurrently. I.e. the maximum
> >                         number of cached Deflaters is
> >                         the maximal number of Deflaters that are
> >                         released while no new Deflater is
> >                         requested. In practice this is usually still a
> >                         small number, less than
> >                         MAX_FLATERS. Nevertheless we can easily
> >                         construct an example which
> >                         demonstrates the memory leak (see the JTRegtest
> >                         in the patch) and because
> >                         the fix is trivial we should really fix this.
> >
> >                         Thank you and best regards,
> >                         Volker
> >
> >
> >
> >                         Amazon Development Center Germany GmbH
> >                         Krausenstr. 38
> >                         10117 Berlin
> >                         Geschaeftsfuehrung: Christian Schlaeger, Ralf
> >                         Herbrich
> >                         Eingetragen am Amtsgericht Charlottenburg unter
> >                         HRB 149173 B
> >                         Sitz: Berlin
> >                         Ust-ID: DE 289 237 879
> >
> >                 
> >                  198324.gif>
> >                 Lance
> >                 Andersen| Principal Member of Technical Staff |
> >                 +1.781.442.2037
> >                 Oracle?Java Engineering
> >                 1 Network Drive
> >                 Burlington, MA 01803
> >                 Lance.Andersen at oracle.com
> >
>  >
> >                 
> >
> >
> >
> >
> >
> >             Amazon Development Center Germany GmbH
> >             Krausenstr. 38
> >             10117 Berlin
> >             Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
> >             Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
> >             Sitz: Berlin
> >             Ust-ID: DE 289 237 879
> >
> >         
> >          198324.gif>
> >         Lance
> >         Andersen| Principal Member of Technical Staff | +1.781.442.2037
> >         Oracle?Java Engineering
> >         1 Network Drive
> >         Burlington, MA 01803
> >         Lance.Andersen at oracle.com 
> >         
> >
> >
> >
> >
> >
> >     Amazon Development Center Germany GmbH
> >     Krausenstr. 38
> >     10117 Berlin
> >     Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
> >     Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
> >     Sitz: Berlin
> >     Ust-ID: DE 289 237 879
> >
> > 
> >
> >
> > 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 
> >
> >
> >
> 
> 
> 
> 
> Amazon Development Center Germany GmbH
> Krausenstr. 38
> 10117 Berlin
> Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
> Sitz: Berlin
> Ust-ID: DE 289 237 879
> 


From mp at jugs.org  Fri Nov 15 13:30:54 2019
From: mp at jugs.org (Michael Paus)
Date: Fri, 15 Nov 2019 14:30:54 +0100
Subject: Jpackage ignores @2x-files
Message-ID: <6567a617-9357-9e46-a72b-cf04373b86f9@jugs.org>

Hi,
I am trying to customize a DMG built with jpackage.
I have therefore placed two images into the configured resource folder.

myApp-background.png
myApp-background at 2x.png

The assumption is that when you open the DMG on a Mac with a retina display,
it should automatically use the @2x-version of the file in order to get 
a clear
and crisp rendering.

But this does not work because jpackage only picks up the first file 
from the
resource folder but not the second one. So this file is never copied 
into the
DMG and thus the rendering of the image on a retina display does not 
look nice.

Michael


From Roger.Riggs at oracle.com  Fri Nov 15 14:54:25 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 15 Nov 2019 09:54:25 -0500
Subject: [ping] 8179320: File.getUsableSpace() returns a negative number
 on very large file system
In-Reply-To: 
References: <674F3B84-3737-4F55-8D2B-B1777F91203E@oracle.com>
 <8F5DDADA-BF4B-4504-B69D-05FE216D2B9C@oracle.com>
 <2c8fc362-426b-1895-c1e3-7548ec224ffe@oracle.com>
 
Message-ID: 

+1

Thanks

On 11/14/19 7:11 PM, Brian Burkhalter wrote:
> Hi Roger,
>
>> On Nov 14, 2019, at 1:35 PM, Roger Riggs > > wrote:
>>
>> The changes look fine.
>
> Thanks for the comments.
>
>> In the CSR, the typography of the code font for |java.io.File.getXSpace
>> |will not read well in all the places where the summary sentence is 
>> used by itself.
>> Spelling out the names of the affected methods will help.
>
> Done [1].
>
>> Having to unpack a zip file to see the changes in the CSR is not 
>> reader friendly.
>> They are relatively small and could be included inline in the CSR.
>
> I could not get the diff to format properly inline but I included the 
> changes as seen in the javadoc.
>
> Thanks,
>
> Brian
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8233426


From daniel.daugherty at oracle.com  Fri Nov 15 15:25:33 2019
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 15 Nov 2019 10:25:33 -0500
Subject: Java launcher with `--module=name[/entry-point]` fails on Windows
In-Reply-To: 
References: 
Message-ID: 

Forwarding over to core-libs-dev at ...? I think that's where launcher
issues are addressed.

Bcc'ing jdk-dev at ...

Dan


On 11/15/19 6:23 AM, Christian Stein wrote:
> Hi,
>
> relying on the "Note: To specify an argument for a long option,
> you can use either --name=value or --name value." from [0] and
> assuming that `--module` is a long option (with `-m` being its
> short counterpart) I think I found an error in `java.exe`.
>
> The brief history of the search is recorded at JBS [1], and
> yesterday, I managed to create a minimal, complete and
> verifiable example at [2] -- which contains a README.md
> file with more details. Here's a gist:
>
> Calling `java --module-path=lib --module=m/Main --help ...`
> sometimes fails to launch the JVM. The failure, if it occurs,
> expresses mostly via a silent exit of the `java.exe` program
> leaving a negative value in the "DOS shell" `ERRORLEVEL`
> environment variable. Seldom, a fatal error log is written
> to the current working directory.
>
> The underlying reason seems to be an error in the
> calculation of the application argument count and index.
> The later reads: AppArgIndex: -1 points to (null)
>
> Work-around: omit the `=` (equals sign) after `--module`
> and the entry-point, here `m/Main`. This command line
> always gets the JVM up and running.
>
> Cheers,
> Christain
>
> [0] https://docs.oracle.com/en/java/javase/11/tools/java.html
> [1] https://bugs.openjdk.java.net/browse/JDK-8234076
> [2] https://github.com/sormuras/JDK-8234076
>


From simonisv at amazon.de  Fri Nov 15 15:34:06 2019
From: simonisv at amazon.de (Volker Simonis)
Date: Fri, 15 Nov 2019 16:34:06 +0100
Subject: RFR(XS): 8234011: (zipfs) Memory leak in
 ZipFileSystem.releaseDeflater()
In-Reply-To: 
References: <1573658564822.16574@amazon.de>
 
 <45B01685-8D87-4171-BD84-778659680C67@oracle.com>
 
 <69AB1167-0598-4B51-9A18-31BF0F6A9701@oracle.com>
 
 
 
 <8e4ca29b-8bec-c96e-ab32-56ea10aba94f@amazon.de>
 
Message-ID: <6be5e4d0-6fc5-2895-e70d-99968ea82e6d@amazon.de>

On 15.11.19 13:44, Langer, Christoph wrote:
> Hi Volker,
> 
> Looks awesome now ??
> 

Thanks :)

> Please remove the "import java.nio.file.Files;" statement before pushing.
>

It's needed for "Files.deleteIfExists(zipFile)" in the finally block..

> Cheers
> Christoph
> 
> 
>> -----Original Message-----
>> From: Volker Simonis 
>> Sent: Freitag, 15. November 2019 12:30
>> To: Langer, Christoph ; Volker Simonis
>> 
>> Cc: core-libs-dev at openjdk.java.net; Lance Andersen
>> 
>> Subject: Re: RFR(XS): 8234011: (zipfs) Memory leak in
>> ZipFileSystem.releaseDeflater()
>>
>> On 14.11.19 18:24, Langer, Christoph wrote:
>>> Hi Volker,
>>>
>>> funny, I didn?t get aware of your mails until I now recognized that my
>>> mail client moved your mail into the ?Amazon-advertisement-spam? folder
>>> of my mailbox. ?? I have to check and modify my filter rules?
>>>
>>> Ok, let?s continue the little bike-shed about the test then.
>>>
>>> First, thanks for making the adaptions. The test looks better already. I
>>> still have a few points:
>>>
>>> 1. The imports of java.io.File and java.util.HashMap can be removed now.
>>>
>>
>> Done.
>>
>>> 2. The two try statements in lines 54 and 55 look a bit awkward. I guess
>>> you could just use the one try-with-resource from line 55 and put the
>>> cleanup in its finally block.
>>>
>>
>> Done.
>>
>>> 3. Maybe you also want to attempt a Files.deleteIfExists(zipFile);
>>> before opening the Zip file system? Otherwise there is a remote
>>> possibility that ReleaseDeflaterTest.zip already exists and the test
>>> will fail because of this.
>>>
>>
>> That doesn't harm. The file will just be reused.
>>
>>> 4. I?m also not a fan of the SkippedException here. I for myself would
>>> probably not get aware of a skip. And if somebody changes the
>>> implementation of ZipFileSystem, why shouldn?t he/she/? immediately
>>> recognize this and adapt the test in the same change?
>>>
>>
>> OK, changed it to a RuntimeException now.
>>
>> Here's the new webrev:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011.v3
>>
>>> Best regards
>>>
>>> Christoph
>>>
>>> *From:* Lance Andersen 
>>> *Sent:* Donnerstag, 14. November 2019 17:38
>>> *To:* Volker Simonis 
>>> *Cc:* Langer, Christoph ; Simonis, Volker
>>> ; core-libs-dev at openjdk.java.net
>>> *Subject:* Re: RFR(XS): 8234011: (zipfs) Memory leak in
>>> ZipFileSystem.releaseDeflater()
>>>
>>>      On Nov 14, 2019, at 11:27 AM, Volker Simonis >>      > wrote:
>>>
>>>      On 14.11.19 16:27, Lance Andersen wrote:
>>>
>>>          Hi Volker,
>>>
>>>              On Nov 14, 2019, at 8:53 AM, Volker Simonis
>>>              >>              >
>> wrote:
>>>
>>>              On 13.11.19 18:54, Lance Andersen wrote:
>>>
>>>                  Hi Volker,
>>>                  Thank you for doing this.
>>>                  As Christoph mentioned, ?you can just do Path.of() and
>>>                  create the file in the work directory for the test.
>>>
>>>
>>>              Done.
>>>
>>>
>>>                  If possible, I would use TestNG as that is consistent
>>>                  with the vast majority of the tests.
>>>
>>>
>>>              I don't particularly like to nest one test harness within
>>>              another one :)
>>>              But seriously, I think using JUnit or TestNG makes sens if
>>>              you write a whole test suit which uses the features of such
>>>              a test harness (e.g. tear up, tear down, etc.)
>>>
>>>          Well you could use @AfterMethod or @AfterClass to clean up files
>>>          etc? ;-)
>>>
>>>              But for small trivial tests I really prefer to use plain
>>>              JTreg. This also has the big advantage that is becomes
>>>              trivial to run such a test stand-alone which may come handy
>>>              if you have to debug it.
>>>
>>>          Easy enough to add a main method to call your test method (there
>>>          are some testng tests I have seen in the workspace that do that)
>>>
>>>
>>>              So if you don't insist, I'll prefer to leave the test as it is.
>>>
>>>          While I would prefer it for new tests, I am not insisting you
>>>          need to change the test?.. ;-)
>>>
>>>
>>>      OK, thanks. I might consider using it in the future :)
>>>
>>>
>>>
>>>
>>>                  I also believe the rest of the comments below are worth
>>>                  addressing.
>>>
>>>
>>>              Besides that, I've addressed all the other points mentioned
>>>              by Christoph. Please find the new webrev at:
>>>
>>>              http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011.v1/
>>>
>>>          line 55 you can remove the creation of the HashMap
>>>
>>>
>>>      Good catch! Removed.
>>>
>>>
>>>          line 73, do you really need the equals check seeing you do not
>>>          do anything?
>>>
>>>
>>>      Removed. It was a leftover of local testing.
>>>
>>>
>>>          I am not sure throwing a SkippedException is correct, ?I would
>>>          probably throw a RuntimeException
>>>
>>>
>>>      As I wrote in the answer to Christoph, this is a relatively new
>>>      feature of JTreg [1] which I think was introduced for exactly such
>>>      kind of situations where a tests detects at runtime only, that for
>>>      some reasons he can't test the issue he was supposed to test. More
>>>      and more tests are adapting it now [2]. The SkippedException will be
>>>      handled specially by JTreg and let the test pass, but with status
>>>      "Passed.Skipped" (plus exception message) instead of just "Passed"
>>>      (plis "Execution successful").
>>>
>>>      Here's the next webrev:
>>>
>>>      http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011.v2/
>>>
>>> Thank you for the updates. ?I am still a bit skeptical of the use of
>>> SkippedException here as you would never see the test is no longer
>>> passing due to an implementation change unless you are specifically
>>> looking for it.
>>>
>>> That being said, ?if others who have more experience with using this
>>> Exception in a similar scenario are good, then I am good.
>>>
>>> So once we get a couple of other views on this from others with a thumbs
>>> up for using SkippedException here, we are good to go :-)
>>>
>>> Best
>>>
>>> Lance
>>>
>>>
>>>
>>>
>>>      Thanks,
>>>      Volker
>>>
>>>      [1]https://openjdk.java.net/jtreg/faq.html#what-if-a-test-does-not-
>> apply-in-a-given-situation
>>>      [2]https://bugs.openjdk.java.net/browse/JDK-8208655
>>>
>>>
>>>          Best
>>>          Lance
>>>
>>>
>>>              Thank you and best regards,
>>>              Volker
>>>
>>>
>>>                  Thank you again for the fix
>>>                  Best
>>>                  Lance
>>>
>>>                      On Nov 13, 2019, at 11:26 AM, Langer, Christoph
>>>                      >>
>> 
>>>                      > wrote:
>>>
>>>                      Hi Volker,
>>>
>>>                      good catch in ZipFileSystem ??The fix is the right
>>>                      thing to do.
>>>
>>>                      I have a few remarks to the test, though:
>>>
>>>                      Line 52, initialization of the File object: I think
>>>                      you should just do Path zipFile =
>>>                      Paths.get("file.zip"); When the test is run in the
>>>                      jtreg framework, it's running in its own scratch
>>>                      directory, so no need to use java.io.tmpdir. You can
>>>                      also leave cleanup to jtreg and don't need to delete
>>>                      the file in the end (in the finally block). However,
>>>                      you should probably check whether the file exists in
>>>                      the beginning and delete it in that case.
>>>
>>>                      Line 55ff: You don't need to use this URI thing any
>>>                      more. You can simply do: try (FileSystem fs =
>>>                      FileSystems.newFileSystem(zipFile, Map.of("create",
>>>                      true))) { (line 58).
>>>
>>>                      Line 61/62: You're using a Vector, wow ??You should
>>>                      rather use ArrayList, I think...
>>>
>>>                      Line 85: This should rather be:
>>>                       ???????????????????@SuppressWarnings("unchecked")
>>>                       ???????????????????int inflater_count =
>>>                      ((List)inflaters.get(fs)).size();
>>>                      Same for line 89.
>>>
>>>                      Line 93 (Catch clause): I think we should fail in
>>>                      that case, too. Otherwise, if the implementation
>>>                      would change, the test could run unnoticed for
>>>                      years, testing basically nothing...
>>>
>>>                      Best regards,
>>>                      Christoph
>>>
>>>
>>>
>>>                          -----Original Message-----
>>>                          From: core-libs-dev
>>>                          >>                          > bounces at openjdk.java.net>> bounces at openjdk.java.net>
>>>                          >
>>>                          On Behalf
>>>                          Of Simonis, Volker
>>>                          Sent: Mittwoch, 13. November 2019 16:23
>>>                          To:core-libs-dev at openjdk.java.net
>>>                          > dev at openjdk.java.net>
>>>                          
>>>                          Subject: RFR(XS): 8234011: (zipfs) Memory leak in
>>>                          ZipFileSystem.releaseDeflater()
>>>
>>>                          Hi,
>>>
>>>                          can I please get a review for this trivial fix
>>>                          of an old copy-and-paste error:
>>>
>>>                          http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011/
>>>                          https://bugs.openjdk.java.net/browse/JDK-8234011
>>>
>>>                          ZipFileSystem caches MAX_FLATER (currently 20)
>>>                          Inflater/Deflater objects.
>>>                          However the logic for reusing Deflaters is wrong
>>>                          because it references the
>>>                          Inflater List when checking against the number
>>>                          of already cached objects.
>>>                          This seems like a day-one copy and paste error.
>>>
>>>                          Notice that this issue is not as critical as it
>>>                          appears, because retaining of
>>>                          additional Deflaters only happens when more than
>>>                          MAX_FLATER are used
>>>                          and released concurrently. I.e. the maximum
>>>                          number of cached Deflaters is
>>>                          the maximal number of Deflaters that are
>>>                          released while no new Deflater is
>>>                          requested. In practice this is usually still a
>>>                          small number, less than
>>>                          MAX_FLATERS. Nevertheless we can easily
>>>                          construct an example which
>>>                          demonstrates the memory leak (see the JTRegtest
>>>                          in the patch) and because
>>>                          the fix is trivial we should really fix this.
>>>
>>>                          Thank you and best regards,
>>>                          Volker
>>>
>>>
>>>
>>>                          Amazon Development Center Germany GmbH
>>>                          Krausenstr. 38
>>>                          10117 Berlin
>>>                          Geschaeftsfuehrung: Christian Schlaeger, Ralf
>>>                          Herbrich
>>>                          Eingetragen am Amtsgericht Charlottenburg unter
>>>                          HRB 149173 B
>>>                          Sitz: Berlin
>>>                          Ust-ID: DE 289 237 879
>>>
>>>                  
>>>                  > 198324.gif>
>>>                  Lance
>>>                  Andersen| Principal Member of Technical Staff |
>>>                  +1.781.442.2037
>>>                  Oracle?Java Engineering
>>>                  1 Network Drive
>>>                  Burlington, MA 01803
>>>                  Lance.Andersen at oracle.com
>>>
>> >>
>>>                  
>>>
>>>
>>>
>>>
>>>
>>>              Amazon Development Center Germany GmbH
>>>              Krausenstr. 38
>>>              10117 Berlin
>>>              Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
>>>              Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
>>>              Sitz: Berlin
>>>              Ust-ID: DE 289 237 879
>>>
>>>          
>>>          > 198324.gif>
>>>          Lance
>>>          Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>          Oracle?Java Engineering
>>>          1 Network Drive
>>>          Burlington, MA 01803
>>>          Lance.Andersen at oracle.com 
>>>          
>>>
>>>
>>>
>>>
>>>
>>>      Amazon Development Center Germany GmbH
>>>      Krausenstr. 38
>>>      10117 Berlin
>>>      Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
>>>      Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
>>>      Sitz: Berlin
>>>      Ust-ID: DE 289 237 879
>>>
>>> 
>>>
>>>
>>> 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 
>>>
>>>
>>>
>>
>>
>>
>>
>> Amazon Development Center Germany GmbH
>> Krausenstr. 38
>> 10117 Berlin
>> Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
>> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
>> Sitz: Berlin
>> Ust-ID: DE 289 237 879
>>
> 




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



From christoph.langer at sap.com  Fri Nov 15 15:41:15 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 15 Nov 2019 15:41:15 +0000
Subject: RFR(XS): 8234011: (zipfs) Memory leak in
 ZipFileSystem.releaseDeflater()
In-Reply-To: <6be5e4d0-6fc5-2895-e70d-99968ea82e6d@amazon.de>
References: <1573658564822.16574@amazon.de>
 
 <45B01685-8D87-4171-BD84-778659680C67@oracle.com>
 
 <69AB1167-0598-4B51-9A18-31BF0F6A9701@oracle.com>
 
 
 
 <8e4ca29b-8bec-c96e-ab32-56ea10aba94f@amazon.de>
 
 <6be5e4d0-6fc5-2895-e70d-99968ea82e6d@amazon.de>
Message-ID: 

Hi Volker,

> > Please remove the "import java.nio.file.Files;" statement before pushing.
> >
> 
> It's needed for "Files.deleteIfExists(zipFile)" in the finally block..

Oops, you're right. It popped up in my IDE because I tested what happened when the file remained in the directory and therefore I commented that block out.

So, go for it ??

Cheers
Christoph


From brian.burkhalter at oracle.com  Fri Nov 15 15:57:55 2019
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 15 Nov 2019 07:57:55 -0800
Subject: 8179320: File.getUsableSpace() returns a negative number on very
 large file system
In-Reply-To: <5328f442-ebdc-87bb-b79a-881d3f9986ac@oracle.com>
References: <674F3B84-3737-4F55-8D2B-B1777F91203E@oracle.com>
 <5328f442-ebdc-87bb-b79a-881d3f9986ac@oracle.com>
Message-ID: 


> On Nov 15, 2019, at 2:59 AM, Alan Bateman  wrote:
> 
> On 02/11/2019 00:13, Brian Burkhalter wrote:
>> For this issue [1], please review this patch [2] and the corresponding CSR [3].
>> 
>> 
> One thing that isn't clear is how these methods behave when the space info can't be obtained. It is specified to return 0L when the path is not "a partition" but I think it also returns 0L when the information cannot be obtained.

It checks whether it has read permission, as documented, and also whether the path string is invalid. In the latter case 0L is returned. Zero is also returned if statfs(2) fails (returns -1). This is different behavior from FileStore.getXSpace() which throws an IOException if statfs fails.

For the File.getXSpace() case, then perhaps something like this would be better documentation of return:

"The size, in bytes, of the partition or 0L if this abstract pathname is not a valid path or the information cannot be obtained."

Brian

From sgehwolf at redhat.com  Fri Nov 15 16:51:31 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 15 Nov 2019 17:51:31 +0100
Subject: RFR: 8231111: Cgroups v2: Rework Metrics in java.base so as to
 recognize unified hierarchy
Message-ID: <75fc377f8d5ca76b7dac02f55db640cbdd305633.camel@redhat.com>

Hi,

Could I please get reviews of these core-libs, Linux-only, changes to
the Metrics subsystem? This patch implements cgroupv2 support for
Metrics which are currently cgroupv1-only. Fedora 31 switched to
cgroupv2 by default so it's time to get OpenJDK recognize it.

Note that a couple of metrics are no longer supported with cgroupv2.
Most notably (not an exhaustive list, though):

Metrics.getKernel*() family of methods.
Metrics.getTcp*() family of methods.
Metrics.getBlkIO*() family of methods.
Metrics.isMemoryOOMKillEnabled()

A couple of open questions with regards to that:

1)
Most API docs of Metrics make no distiction between "unlimited" and
"not supported", both returning -1 for longs, for example. This is a
problem, because output of "java -XshowSettings:system -version" will
not distinguish between unlimited and not supported metrics. Would it
be acceptable to change the API to distinguish those cases so that
LauncherHelper could display them appropriately?

2)
How should we deal with "not supported" for booleans/arrays, etc.?
Would it make sense to return record objects from the Metrics API so
that this could be dealt with? E.g.

Metrics m = ...
MetricResult result = m.getCpuSetCpus();
switch(result.getType()) {
   case NOT_SUPPORTED: /* do something */; break;
   case SUPPORTED: int[] val = result.get(); break;
   ...         
}

I'm bringing this up, because the proposed patch doesn't deal with the
above open questions as of yet. With that being said, it's mostly
identical to the proposed hotspot changes in [1].

Bug: https://bugs.openjdk.java.net/browse/JDK-8231111
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/

Testing: jdk/submit and platform docker tests on Linux x86_64 (with
hybrid hierarchy, docker/podman) and on Linux x86_64 with unified
hierarchy (podman only).

Thoughts? Suggestions?

Thanks,
Severin

[1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-November/039909.html


From lance.andersen at oracle.com  Fri Nov 15 16:57:17 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 15 Nov 2019 11:57:17 -0500
Subject: RFR(XS): 8234011: (zipfs) Memory leak in
 ZipFileSystem.releaseDeflater()
In-Reply-To: 
References: <1573658564822.16574@amazon.de>
 
 <45B01685-8D87-4171-BD84-778659680C67@oracle.com>
 
 <69AB1167-0598-4B51-9A18-31BF0F6A9701@oracle.com>
 
 
 
 <8e4ca29b-8bec-c96e-ab32-56ea10aba94f@amazon.de>
 
 <6be5e4d0-6fc5-2895-e70d-99968ea82e6d@amazon.de>
 
Message-ID: <70D1DDC8-5BB5-47E0-89B7-25BA06C5C8FD@oracle.com>

Hi Volker

Lines 54.55  ArrayList foo = ?

This could be changed to List foo = ?  if you wanted

otherwise  I think you are good to go
> On Nov 15, 2019, at 10:41 AM, Langer, Christoph  wrote:
> 
> Hi Volker,
> 
>>> Please remove the "import java.nio.file.Files;" statement before pushing.
>>> 
>> 
>> It's needed for "Files.deleteIfExists(zipFile)" in the finally block..
> 
> Oops, you're right. It popped up in my IDE because I tested what happened when the file remained in the directory and therefore I commented that block out.
> 
> So, go for it ??
> 
> Cheers
> 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 philip.race at oracle.com  Fri Nov 15 17:05:26 2019
From: philip.race at oracle.com (Phil Race)
Date: Fri, 15 Nov 2019 09:05:26 -0800
Subject: Jpackage ignores @2x-files
In-Reply-To: <6567a617-9357-9e46-a72b-cf04373b86f9@jugs.org>
References: <6567a617-9357-9e46-a72b-cf04373b86f9@jugs.org>
Message-ID: 

Submit a bug for tools/jpackage.
Assuming this is just a missed copy it should be easy to fix.

-phil.

On 11/15/19 5:30 AM, Michael Paus wrote:
> Hi,
> I am trying to customize a DMG built with jpackage.
> I have therefore placed two images into the configured resource folder.
>
> myApp-background.png
> myApp-background at 2x.png
>
> The assumption is that when you open the DMG on a Mac with a retina 
> display,
> it should automatically use the @2x-version of the file in order to 
> get a clear
> and crisp rendering.
>
> But this does not work because jpackage only picks up the first file 
> from the
> resource folder but not the second one. So this file is never copied 
> into the
> DMG and thus the rendering of the image on a retina display does not 
> look nice.
>
> Michael
>


From stuart.marks at oracle.com  Fri Nov 15 18:23:02 2019
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 15 Nov 2019 10:23:02 -0800
Subject: RFR 8233187: Return Empty List if 0 Copies Requested in
 Collections nCopies
In-Reply-To: 
References: <963f1eed-2b92-f00a-9a37-4acfc71d9939@oracle.com>
 
Message-ID: <1d642723-0fd3-0d3e-29aa-bb06596ea2da@oracle.com>

I just added this comment to the bug report, but since there's a review thread,
I'll post it here too for discussion:

> I don't necessarily think that returning the instance from
> Collections.emptyList() is a good idea. It changes the serialized format, and
> it may also introduce some subtle behavioral changes. The nCopies() method
> could instead return a cached instance of a zero-length CopiesList instance.
> I question whether this is worthwhile. Is there an actual case where somebody
> is creating large numbers of empty lists, or is this just some random idea
> somebody thought up? If the latter, then it's usually not worth pursuing such
> changes.

There's no justification for this stated in the bug report, e.g., "we ran into a 
case where millions of redundant empty lists were being created...." It smells 
to me like this is one of those "optimizations" where somebody looked at the 
code and decided it would be a good idea.

s'marks




On 11/14/19 4:34 PM, Martin Buchholz wrote:
> Hi Kiran, pleased to meet you
> 
> Code like this should be written so that the common case has only one boolean
> test.
> 
> On Thu, Nov 14, 2019 at 1:50 AM Kiran Ravikumar < 
> kiran.sidhartha.ravikumar at oracle.com> wrote:
> 
>> Hi Guys,
>> 
>> 
>> Please review the following optimization to nCopies method to return empty
>> list and to avoid instantiating an empty CopiesList object.
>> 
>> 
>> JBS link : https://bugs.openjdk.java.net/browse/JDK-8233187
>> 
>> 
>> Patch:
>> 
>> diff -r f279d8a9bb78
>> src/java.base/share/classes/java/util/Collections.java ---
>> a/src/java.base/share/classes/java/util/Collections.java Wed Nov 13 
>> 11:27:50 2019 +0000 +++
>> b/src/java.base/share/classes/java/util/Collections.java Thu Nov 14 
>> 09:37:56 2019 +0000 @@ -5105,6 +5105,8 @@ public static  List
>> nCopies(int n, T o) { if (n < 0) throw new IllegalArgumentException("List
>> length = " + n); +        if (n == 0) +            return
>> Collections.emptyList(); return new CopiesList<>(n, o); }
>> 
>> 
>> Thanks,
>> 
>> Kiran
>> 
>> 

From brent.christian at oracle.com  Fri Nov 15 18:38:20 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Fri, 15 Nov 2019 10:38:20 -0800
Subject: RFR 8233272 : The Class.forName specification should be updated
 to match the long-standing implementation with respect to class linking
In-Reply-To: <1e4cd61f-dddd-b221-f0b4-448e64a4b440@oracle.com>
References: <79528f01-3418-eb51-4dbd-897e4e97f853@oracle.com>
 <7ddee581-c68b-bf40-22db-871205b8ca1b@oracle.com>
 <3d305a6d-fd45-f6e5-93f2-c47250f31985@oracle.com>
 
 <99dded93-17d2-ea40-deef-56efd10218c7@oracle.com>
 
 <1e4cd61f-dddd-b221-f0b4-448e64a4b440@oracle.com>
Message-ID: <38a77634-e3d7-426a-ae2d-c957804bf8f3@oracle.com>

On 11/14/19 4:46 PM, Mandy Chung wrote:
> On 11/14/19 4:42 PM, David Holmes wrote:
>>
>> If you really want to test both positive and negative cases from a 
>> clean slate then I would suggest modifying the test slightly and using 
>> two @run commands - one to try to initialize and one to not.
> 
> Yes this is what I was thinking.? Two separate @run commands with an 
> argument to indicate if initialize is true or false would do it.
> 

That sounds good.  Test updated here:
http://cr.openjdk.java.net/~bchristi/8233272/webrev-04/

Thanks,
-Brent

From brian.burkhalter at oracle.com  Fri Nov 15 22:40:06 2019
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 15 Nov 2019 14:40:06 -0800
Subject: 8179320: File.getUsableSpace() returns a negative number on very
 large file system
In-Reply-To: <5328f442-ebdc-87bb-b79a-881d3f9986ac@oracle.com>
References: <674F3B84-3737-4F55-8D2B-B1777F91203E@oracle.com>
 <5328f442-ebdc-87bb-b79a-881d3f9986ac@oracle.com>
Message-ID: 


> On Nov 15, 2019, at 2:59 AM, Alan Bateman  wrote:
> 
> On 02/11/2019 00:13, Brian Burkhalter wrote:
>> For this issue [1], please review this patch [2] and the corresponding CSR [3].
>> 
>> 
> One thing that isn't clear is how these methods behave when the space info can't be obtained. It is specified to return 0L when the path is not "a partition" but I think it also returns 0L when the information cannot be obtained.

I?ve updated the patch [1] to address this. The difference versus webrev.00 is [2].

Thanks,

Brian

[1] http://cr.openjdk.java.net/~bpb/8179320/webrev.01/
[2] diff vs. webrev.00

--- a/src/java.base/share/classes/java/io/File.java
+++ b/src/java.base/share/classes/java/io/File.java
@@ -1804,7 +1804,8 @@
      * returned.
      *
      * @return  The size, in bytes, of the partition or {@code 0L} if this
-     *          abstract pathname does not name a partition
+     *          abstract pathname does not name a partition or if the size
+     *          cannot be obtained
      *
      * @throws  SecurityException
      *          If a security manager has been installed and it denies
@@ -1844,9 +1845,10 @@
      * will succeed.
      *
      * @return  The number of unallocated bytes on the partition or {@code 0L}
-     *          if the abstract pathname does not name a partition.  This
-     *          value will be less than or equal to the total file system size
-     *          returned by {@link #getTotalSpace}.
+     *          if the abstract pathname does not name a partition or if this
+     *          number cannot be obtained.  This value will be less than or
+     *          equal to the total file system size returned by
+     *          {@link #getTotalSpace}.
      *
      * @throws  SecurityException
      *          If a security manager has been installed and it denies
@@ -1889,9 +1891,10 @@
      * to this file system will succeed.
      *
      * @return  The number of available bytes on the partition or {@code 0L}
-     *          if the abstract pathname does not name a partition.  On
-     *          systems where this information is not available, this method
-     *          will be equivalent to a call to {@link #getFreeSpace}.
+     *          if the abstract pathname does not name a partition or if this
+     *          number cannot be obtained.  On systems where this information
+     *          is not available, this method will be equivalent to a call to
+     *          {@link #getFreeSpace}.
      *
      * @throws  SecurityException
      *          If a security manager has been installed and it denies

From mandy.chung at oracle.com  Fri Nov 15 23:16:51 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 15 Nov 2019 15:16:51 -0800
Subject: RFR 8233272 : The Class.forName specification should be updated
 to match the long-standing implementation with respect to class linking
In-Reply-To: <38a77634-e3d7-426a-ae2d-c957804bf8f3@oracle.com>
References: <79528f01-3418-eb51-4dbd-897e4e97f853@oracle.com>
 <7ddee581-c68b-bf40-22db-871205b8ca1b@oracle.com>
 <3d305a6d-fd45-f6e5-93f2-c47250f31985@oracle.com>
 
 <99dded93-17d2-ea40-deef-56efd10218c7@oracle.com>
 
 <1e4cd61f-dddd-b221-f0b4-448e64a4b440@oracle.com>
 <38a77634-e3d7-426a-ae2d-c957804bf8f3@oracle.com>
Message-ID: 



On 11/15/19 10:38 AM, Brent Christian wrote:
> That sounds good.? Test updated here:
> http://cr.openjdk.java.net/~bchristi/8233272/webrev-04/

Looks good.? Minor: an additional check to consider is to check if 
NCDFE's cause whose message contains? "MissingClass" just to be sure.?? 
No new webrev needed.

Mandy


From letuyang at amazon.com  Fri Nov 15 23:19:46 2019
From: letuyang at amazon.com (Yang, Letu)
Date: Fri, 15 Nov 2019 23:19:46 +0000
Subject: Turkish Time Zone name string and translation
Message-ID: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>

Hi,

We recently found an issue with the Time Zone name for ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own Turkish Time (TRT) zone in 2016, although the tzdata had been updated, the Time Zone name string has not been updated yet:

https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836

It still returns "Eastern European Time" for the TimeZone.getDisplayName call, which has a summer time while Turkish Time does not. An entry for TRT need to be added to this file, and assign to both "Europe/Istanbul" and "Asian/Istanbul". This also need to be updated for other locales. I can create a JBS issue for this, but I am not sure whether we should fix this bug, or there is an existing procedure for this kind of bug which requires language translation.

Letu




From mandy.chung at oracle.com  Fri Nov 15 23:36:20 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 15 Nov 2019 15:36:20 -0800
Subject: RFR JDK-8233527: Update Lookup::hasPrivateAccess and
 Lookup::defineClass spec w.r.t. full power lookup
In-Reply-To: <460ffa29-a022-b5df-4c53-6f44a5b16394@gmail.com>
References: <081f506c-62a9-dd98-8b62-04690f4cba14@oracle.com>
 <460ffa29-a022-b5df-4c53-6f44a5b16394@gmail.com>
Message-ID: <8b4afabb-ba4d-e771-4f96-f6ea94528a31@oracle.com>

On 11/15/19 1:32 AM, Peter Levart wrote:
> Hi Mandy,
>
>>
>> http://cr.openjdk.java.net/~mchung/jdk14/8233527/webrev.03/
>
> In Lookup's findBoundCallerClass and checkSecurityManager the javadoc 
> is still talking about private access only although the checks are now 
> made against full privilege access.
>

Fixed.? @return in MethodHandles::lookup is also fixed.

>
>
> Some possible nano optimization / simplification suggestions. Take 
> each with a grain of salt...
>
>
> ??????? public Class defineClass(byte[] bytes) throws 
> IllegalAccessException {
> ??????????? if (allowedModes != TRUSTED && !hasFullPrivilegeAccess()) {
>
>
> TRUSTED == -1, which has all bits set. Therefore allowedModes == 
> TRUSTED implies hasFullPrivilegeAccess(). In other words, 
> !hasFullPrivilegeAccess() implies allowedModes != TRUSTED. Above 
> condition could be simplified to:
>
> if (!hasFullPrivilegeAccess()) { ...
>

OK with me.

>
> Please correct me if I'm wrong: 

These are interesting and I don't have the answer to final fields in 
Lookup class.? Maybe someone may chime in here.?? Otherwise I will find out.

> All final instance fields in java.lang.invoke package are treated as 
> though they were annotated with @Stable right? If that is the case, 
> then all these checks will be folded into a constant if Lookup 
> instance can be folded into a constant when JITed, since allowedModes 
> field is final. But anyway, less branches in code sometimes makes code 
> faster. In this respect, the following:
>
> ??????? public boolean hasFullPrivilegeAccess() {
> ??????????? return (allowedModes & PRIVATE) != 0 && (allowedModes & 
> MODULE) != 0;
> ??????? }
>
> ...could also be written as:
>
> ??????? public boolean hasFullPrivilegeAccess() {
> ??????????? return (allowedModes & (PRIVATE | MODULE)) == (PRIVATE | 
> MODULE);
> ??????? }
>
> So it's just a matter of taste probably which one is nicer to read.
>

I did consider both and no strong preference.? No objection to use the 
latter.

> Also in the following part:
>
> ??????? void checkSecurityManager(Class refc, MemberName m) {
> ??????????? SecurityManager smgr = System.getSecurityManager();
> ??????????? if (smgr == null)? return;
> ??????????? if (allowedModes == TRUSTED)? return;
>
> ...the allowedModes == TRUSTED may be folded into a constant, while 
> security manager check above can not. Perhaps JIT is smart enough to 
> reorder these two checks since they both have the same path (return), 
> but if it doesn't, reordering them in code might be more optimal:
>
> ??????? void checkSecurityManager(Class refc, MemberName m) {
> ??????????? if (allowedModes == TRUSTED)? return;
> ??????????? SecurityManager smgr = System.getSecurityManager();
> ??????????? if (smgr == null)? return;
>

Regarding the performance difference, I think moving TRUSTED check to 
the top is fine as it clearly will skip SM check.

http://cr.openjdk.java.net/~mchung/jdk14/8233527/webrev.04

Mandy

From brent.christian at oracle.com  Fri Nov 15 23:47:03 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Fri, 15 Nov 2019 15:47:03 -0800
Subject: RFR: JDK-8233117 Escape Sequences For Line Continuation and White
 Space (Preview)
In-Reply-To: <00C5C729-D9FF-48E0-8F7F-DD8E7615ACEC@oracle.com>
References: <0EEF3461-D8A4-496B-87DE-F143CB0FB995@oracle.com>
 <414cb097-9616-f4b0-8a3d-462a9ccfbdea@oracle.com>
 
 <00C5C729-D9FF-48E0-8F7F-DD8E7615ACEC@oracle.com>
Message-ID: <818dcc2d-2d4a-57c7-a4e0-c1c873999c2a@oracle.com>

Hi, Jim


src/java.base/share/classes/java/lang/String.java

These changes look fine.

--

test/jdk/java/lang/String/TranslateEscapes.java

I'm missing where the new verifyLineTerminator() method gets called. 
Perhaps that's meant to go here:

   83     static void test4() {
   84
   85     }

?

-Brent

On 11/12/19 7:15 AM, Jim Laskey wrote:
> updated
> 
> webrev: http://cr.openjdk.java.net/~jlaskey/8233116/webrev.03/index.html 
> 
> 

From naoto.sato at oracle.com  Sat Nov 16 00:27:05 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 15 Nov 2019 16:27:05 -0800
Subject:  Turkish Time Zone name string and translation
In-Reply-To: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>
References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>
Message-ID: 

Hi Letu,

Please file a JBS issue for this (component: core-libs, subcomponent: 
java.util:i18n).

Naoto

On 11/15/19 3:19 PM, Yang, Letu wrote:
> Hi,
> 
> We recently found an issue with the Time Zone name for ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own Turkish Time (TRT) zone in 2016, although the tzdata had been updated, the Time Zone name string has not been updated yet:
> 
> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836
> 
> It still returns "Eastern European Time" for the TimeZone.getDisplayName call, which has a summer time while Turkish Time does not. An entry for TRT need to be added to this file, and assign to both "Europe/Istanbul" and "Asian/Istanbul". This also need to be updated for other locales. I can create a JBS issue for this, but I am not sure whether we should fix this bug, or there is an existing procedure for this kind of bug which requires language translation.
> 
> Letu
> 
> 
> 

From letuyang at amazon.com  Sat Nov 16 01:56:35 2019
From: letuyang at amazon.com (Yang, Letu)
Date: Sat, 16 Nov 2019 01:56:35 +0000
Subject:  Turkish Time Zone name string and translation
In-Reply-To: 
References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>,
 
Message-ID: <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com>

Hi Naoto

Thank you for the quick response! We will file a ticket later today.

Shall we make an effort on fixing and translating the strings, or you prefer to take care of it at Oracle?

Letu

On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com wrote:
Hi Letu,

Please file a JBS issue for this (component: core-libs, subcomponent:
java.util:i18n).

Naoto

On 11/15/19 3:19 PM, Yang, Letu wrote:
> Hi,
>
> We recently found an issue with the Time Zone name for ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own Turkish Time (TRT) zone in 2016, although the tzdata had been updated, the Time Zone name string has not been updated yet:
>
> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836
>
> It still returns "Eastern European Time" for the TimeZone.getDisplayName call, which has a summer time while Turkish Time does not. An entry for TRT need to be added to this file, and assign to both "Europe/Istanbul" and "Asian/Istanbul". This also need to be updated for other locales. I can create a JBS issue for this, but I am not sure whether we should fix this bug, or there is an existing procedure for this kind of bug which requires language translation.
>
> Letu
>
>
>

From simonisv at amazon.de  Sat Nov 16 08:03:37 2019
From: simonisv at amazon.de (Simonis, Volker)
Date: Sat, 16 Nov 2019 08:03:37 +0000
Subject: RFR(XS): 8234011: (zipfs) Memory leak in
 ZipFileSystem.releaseDeflater()
In-Reply-To: <70D1DDC8-5BB5-47E0-89B7-25BA06C5C8FD@oracle.com>
References: <1573658564822.16574@amazon.de>
 
 <45B01685-8D87-4171-BD84-778659680C67@oracle.com>
 
 <69AB1167-0598-4B51-9A18-31BF0F6A9701@oracle.com>
 
 
 
 <8e4ca29b-8bec-c96e-ab32-56ea10aba94f@amazon.de>
 
 <6be5e4d0-6fc5-2895-e70d-99968ea82e6d@amazon.de>
 ,
 <70D1DDC8-5BB5-47E0-89B7-25BA06C5C8FD@oracle.com>
Message-ID: <7ef164e0-9a0c-4ef1-afdf-d6d0d73e6f51@amazon.de>

Am 15.11.2019 17:57 schrieb Lance Andersen :
>
> Hi Volker
>
> Lines 54.55  ArrayList foo = ?
>
> This could be changed to List foo = ?  if you wanted
>

Done and pushed.

Thanks for your patience,
Volker

> otherwise  I think you are good to go
>>
>> On Nov 15, 2019, at 10:41 AM, Langer, Christoph < christoph.langer at sap.com> wrote:
>>
>> Hi Volker,
>>
>>>> Please remove the "import java.nio.file.Files;" statement before pushing.
>>>>
>>>
>>> It's needed for "Files.deleteIfExists(zipFile)" in the finally block..
>>
>>
>> Oops, you're right. It popped up in my IDE because I tested what happened when the file remained in the directory and therefore I commented that block out.
>>
>> So, go for it ??
>>
>> Cheers
>> 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
>
>
>




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



From mp at jugs.org  Sat Nov 16 13:20:47 2019
From: mp at jugs.org (Michael Paus)
Date: Sat, 16 Nov 2019 14:20:47 +0100
Subject: Jpackage ignores @2x-files
In-Reply-To: 
References: 
Message-ID: 

Done: https://bugs.openjdk.java.net/browse/JDK-8234284
--Michael

Am 15.11.19 um 19:23 schrieb core-libs-dev-request at openjdk.java.net:
> Message: 5
> Date: Fri, 15 Nov 2019 09:05:26 -0800
> From: Phil Race 
> To: core-libs-dev at openjdk.java.net
> Subject: Re: Jpackage ignores @2x-files
> Message-ID: 
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Submit a bug for tools/jpackage.
> Assuming this is just a missed copy it should be easy to fix.
>
> -phil.
>
> On 11/15/19 5:30 AM, Michael Paus wrote:
>> Hi,
>> I am trying to customize a DMG built with jpackage.
>> I have therefore placed two images into the configured resource folder.
>>
>> myApp-background.png
>> myApp-background at 2x.png
>>
>> The assumption is that when you open the DMG on a Mac with a retina
>> display,
>> it should automatically use the @2x-version of the file in order to
>> get a clear
>> and crisp rendering.
>>
>> But this does not work because jpackage only picks up the first file
>> from the
>> resource folder but not the second one. So this file is never copied
>> into the
>> DMG and thus the rendering of the image on a retina display does not
>> look nice.
>>
>> Michael
>>


From naoto.sato at oracle.com  Sat Nov 16 14:41:56 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Sat, 16 Nov 2019 06:41:56 -0800
Subject:  Turkish Time Zone name string and translation
In-Reply-To: <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com>
References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>
 
 <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com>
Message-ID: <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com>

Letu,

Please go ahead and fix the issue in English resource. As to the 
translation, Oracle l10n will translate it in appropriate locales.

Naoto

On 11/15/19 5:56 PM, Yang, Letu wrote:
> Hi Naoto
> 
> Thank you for the quick response! We will file a ticket later today.
> 
> Shall we make an effort on fixing and translating the strings, or you 
> prefer to take care of it at Oracle?
> 
> Letu
> 
> On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com wrote:
> Hi Letu,
> 
> Please file a JBS issue for this (component: core-libs, subcomponent:
> java.util:i18n).
> 
> Naoto
> 
> On 11/15/19 3:19 PM, Yang, Letu wrote:
>> Hi,
>> 
>> We recently found an issue with the Time Zone name for ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own Turkish Time (TRT) zone in 2016, although the tzdata had been updated, the Time Zone name string has not been updated yet:
>> 
>> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836
>> 
>> It still returns "Eastern European Time" for the TimeZone.getDisplayName call, which has a summer time while Turkish Time does not. An entry for TRT need to be added to this file, and assign to both "Europe/Istanbul" and "Asian/Istanbul". This also need to  be updated for other locales. I can create a JBS issue for this, but I 
> am not sure whether we should fix this bug, or there is an existing 
> procedure for this kind of bug which requires language translation.
>> 
>> Letu
>> 
>> 
>> 

From martinrb at google.com  Sun Nov 17 21:49:52 2019
From: martinrb at google.com (Martin Buchholz)
Date: Sun, 17 Nov 2019 13:49:52 -0800
Subject:  Turkish Time Zone name string and translation
In-Reply-To: <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com>
References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>
 
 <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com>
 <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com>
Message-ID: 

I've always wondered how the timezone-related translations are managed.
CLDR seems to be the master repository of such data, and projects like
OpenJDK are simply supposed to import that data.
But I looked at the CLDR sources, and there doesn't seem to be any "Turkey
Time" strings defined like there are for e.g. Turkmenistan.
Maybe that work never got done?

On Sat, Nov 16, 2019 at 6:44 AM  wrote:

> Letu,
>
> Please go ahead and fix the issue in English resource. As to the
> translation, Oracle l10n will translate it in appropriate locales.
>
> Naoto
>
> On 11/15/19 5:56 PM, Yang, Letu wrote:
> > Hi Naoto
> >
> > Thank you for the quick response! We will file a ticket later today.
> >
> > Shall we make an effort on fixing and translating the strings, or you
> > prefer to take care of it at Oracle?
> >
> > Letu
> >
> > On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com wrote:
> > Hi Letu,
> >
> > Please file a JBS issue for this (component: core-libs, subcomponent:
> > java.util:i18n).
> >
> > Naoto
> >
> > On 11/15/19 3:19 PM, Yang, Letu wrote:
> >> Hi,
> >>
> >> We recently found an issue with the Time Zone name for
> ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own
> Turkish Time (TRT) zone in 2016, although the tzdata had been updated, the
> Time Zone name string has not been updated yet:
> >>
> >>
> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836
> >>
> >> It still returns "Eastern European Time" for the
> TimeZone.getDisplayName call, which has a summer time while Turkish Time
> does not. An entry for TRT need to be added to this file, and assign to
> both "Europe/Istanbul" and "Asian/Istanbul". This also need to  be updated
> for other locales. I can create a JBS issue for this, but I
> > am not sure whether we should fix this bug, or there is an existing
> > procedure for this kind of bug which requires language translation.
> >>
> >> Letu
> >>
> >>
> >>
>

From david.holmes at oracle.com  Mon Nov 18 03:31:03 2019
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 18 Nov 2019 13:31:03 +1000
Subject: RFR 8233272 : The Class.forName specification should be updated
 to match the long-standing implementation with respect to class linking
In-Reply-To: <38a77634-e3d7-426a-ae2d-c957804bf8f3@oracle.com>
References: <79528f01-3418-eb51-4dbd-897e4e97f853@oracle.com>
 <7ddee581-c68b-bf40-22db-871205b8ca1b@oracle.com>
 <3d305a6d-fd45-f6e5-93f2-c47250f31985@oracle.com>
 
 <99dded93-17d2-ea40-deef-56efd10218c7@oracle.com>
 
 <1e4cd61f-dddd-b221-f0b4-448e64a4b440@oracle.com>
 <38a77634-e3d7-426a-ae2d-c957804bf8f3@oracle.com>
Message-ID: 

On 16/11/2019 4:38 am, Brent Christian wrote:
> On 11/14/19 4:46 PM, Mandy Chung wrote:
>> On 11/14/19 4:42 PM, David Holmes wrote:
>>>
>>> If you really want to test both positive and negative cases from a 
>>> clean slate then I would suggest modifying the test slightly and 
>>> using two @run commands - one to try to initialize and one to not.
>>
>> Yes this is what I was thinking.? Two separate @run commands with an 
>> argument to indicate if initialize is true or false would do it.
>>
> 
> That sounds good.? Test updated here:
> http://cr.openjdk.java.net/~bchristi/8233272/webrev-04/

Minor optimisations:

   35  * @compile MissingClass.java
   36  * @compile Container.java
   37  *
   38  * @run main/othervm ClassFileInstaller -jar classes.jar Container 
Container$1

You can use a single @compile line to compile both classes.

You can use "@run driver" for ClassfileInstaller.

No need to see updated webrev.

Thanks,
David

> Thanks,
> -Brent

From david.holmes at oracle.com  Mon Nov 18 04:00:24 2019
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 18 Nov 2019 14:00:24 +1000
Subject: RFR: 8234185: Cleanup usage of canonicalize function between
 libjava, hotspot and libinstrument
In-Reply-To: 
References: 
Message-ID: 

Hi Christoph,

This all seems fine to me. One clarification:

- /* The appropriate location of getPrefixed() should be io_util_md.c, but
-    java.lang.instrument package has hardwired canonicalize_md.c into their
-    dll, to avoid complicate solution such as including io_util_md.c into
-    that package, as a workaround we put this method here.
-  */

I assume this hardwired usage was removed some time ago?

Thanks,
David

On 15/11/2019 1:37 am, Langer, Christoph wrote:
> Hi,
> 
> please review this cleanup change regarding function "canonicalize" of libjava.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8234185
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234185.0/
> 
> 
> The goal is to cleanup how this function is defined and used. One thing is, that there was an unnecessary wrapper function "Canonicalize" in jni_util.c. It wrapped the call to "canonicalize". We can get rid of this wrapper. Unfortunately, it is not possible to just export "canonicalize" since this will conflict with a method signature from the math library, at least on modern Linuxes. So I decided to call the method JDK_Canonicalize and will correctly define it in jdk_util.h which can be included everywhere.
> 
> 
> 
> Hotspot's classloader.cpp will dynamically resolve this method, so I add a local declaration of the function pointer in there.
> 
> 
> 
> This change shall be predecessor of JDK-8223261, where a review was already started here: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-November/063398.html
> 
> Thanks
> Christoph
> 

From letuyang at amazon.com  Mon Nov 18 04:54:37 2019
From: letuyang at amazon.com (Yang, Letu)
Date: Mon, 18 Nov 2019 04:54:37 +0000
Subject:  Turkish Time Zone name string and translation
In-Reply-To: <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com>
References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>
 
 <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com>
 <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com>
Message-ID: 

Hi Naoto,

Thank you for the clarification!

Xin from my team has filed a JBS and uploaded my webrev:
https://bugs.openjdk.java.net/browse/JDK-8234288
https://cr.openjdk.java.net/~xliu/8234288/webrev.00/

Letu

?On 11/16/19, 6:44 AM, "naoto.sato at oracle.com"  wrote:

    Letu,
    
    Please go ahead and fix the issue in English resource. As to the 
    translation, Oracle l10n will translate it in appropriate locales.
    
    Naoto
    
    On 11/15/19 5:56 PM, Yang, Letu wrote:
    > Hi Naoto
    > 
    > Thank you for the quick response! We will file a ticket later today.
    > 
    > Shall we make an effort on fixing and translating the strings, or you 
    > prefer to take care of it at Oracle?
    > 
    > Letu
    > 
    > On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com wrote:
    > Hi Letu,
    > 
    > Please file a JBS issue for this (component: core-libs, subcomponent:
    > java.util:i18n).
    > 
    > Naoto
    > 
    > On 11/15/19 3:19 PM, Yang, Letu wrote:
    >> Hi,
    >> 
    >> We recently found an issue with the Time Zone name for ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own Turkish Time (TRT) zone in 2016, although the tzdata had been updated, the Time Zone name string has not been updated yet:
    >> 
    >> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836
    >> 
    >> It still returns "Eastern European Time" for the TimeZone.getDisplayName call, which has a summer time while Turkish Time does not. An entry for TRT need to be added to this file, and assign to both "Europe/Istanbul" and "Asian/Istanbul". This also need to  be updated for other locales. I can create a JBS issue for this, but I 
    > am not sure whether we should fix this bug, or there is an existing 
    > procedure for this kind of bug which requires language translation.
    >> 
    >> Letu
    >> 
    >> 
    >> 
    


From tschoening at am-soft.de  Mon Nov 18 08:08:26 2019
From: tschoening at am-soft.de (=?utf-8?Q?Thorsten_Sch=C3=B6ning?=)
Date: Mon, 18 Nov 2019 09:08:26 +0100
Subject: Should Java support ERROR_NO_MORE_FILES when canonicalizing paths
 on Windows?
In-Reply-To: <346034750.20191114204642@am-soft.de>
References: <346034750.20191114204642@am-soft.de>
Message-ID: <15310170835.20191118090826@am-soft.de>

Guten Tag Thorsten Sch?ning,
am Donnerstag, 14. November 2019 um 20:46 schrieben Sie:

> So, how about adding ERROR_NO_MORE_FILES there as well?

Does nobody care about that request or am I not even received by
others on the list? In the first case, is anyone willing to tell me
where I should ask instead?

I'm not allowed to file bugs against the OpenJDK-project and filing a
bug in the Oracle-bugtracker doesn't seem to care anyone at all as well.

It's only one line of code making totally sense to be added, because
the same place already handles lots of exceptions to documented
Windows-behaviour.

Mit freundlichen Gr??en,

Thorsten Sch?ning

-- 
Thorsten Sch?ning       E-Mail: Thorsten.Schoening at AM-SoFT.de
AM-SoFT IT-Systeme      http://www.AM-SoFT.de/

Telefon...........05151-  9468- 55
Fax...............05151-  9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Gesch?ftsf?hrer: Andreas Muchow


From christoph.langer at sap.com  Mon Nov 18 09:00:32 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 18 Nov 2019 09:00:32 +0000
Subject: RFR: 8234185: Cleanup usage of canonicalize function between
 libjava, hotspot and libinstrument
In-Reply-To: 
References: 
 
Message-ID: 

Hi David,

> This all seems fine to me. One clarification:

Thanks for the review.

> 
> - /* The appropriate location of getPrefixed() should be io_util_md.c, but
> -    java.lang.instrument package has hardwired canonicalize_md.c into their
> -    dll, to avoid complicate solution such as including io_util_md.c into
> -    that package, as a workaround we put this method here.
> -  */
> 
> I assume this hardwired usage was removed some time ago?

AFAICS, yes. libinstrument builds/links against libjava. I cannot find any duplicates of canonicalize* in there.

Any other reviews (e.g. Gerard?)

Thanks & Best regards
Christoph

> 
> Thanks,
> David
> 
> On 15/11/2019 1:37 am, Langer, Christoph wrote:
> > Hi,
> >
> > please review this cleanup change regarding function "canonicalize" of
> libjava.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8234185
> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234185.0/
> >
> >
> > The goal is to cleanup how this function is defined and used. One thing is,
> that there was an unnecessary wrapper function "Canonicalize" in jni_util.c.
> It wrapped the call to "canonicalize". We can get rid of this wrapper.
> Unfortunately, it is not possible to just export "canonicalize" since this will
> conflict with a method signature from the math library, at least on modern
> Linuxes. So I decided to call the method JDK_Canonicalize and will correctly
> define it in jdk_util.h which can be included everywhere.
> >
> >
> >
> > Hotspot's classloader.cpp will dynamically resolve this method, so I add a
> local declaration of the function pointer in there.
> >
> >
> >
> > This change shall be predecessor of JDK-8223261, where a review was
> already started here: https://mail.openjdk.java.net/pipermail/core-libs-
> dev/2019-November/063398.html
> >
> > Thanks
> > Christoph
> >

From Alan.Bateman at oracle.com  Mon Nov 18 09:09:03 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 18 Nov 2019 09:09:03 +0000
Subject: RFR: 8234185: Cleanup usage of canonicalize function between
 libjava, hotspot and libinstrument
In-Reply-To: 
References: 
 
 
Message-ID: 

On 18/11/2019 09:00, Langer, Christoph wrote:
> :
> Any other reviews (e.g. Gerard?)
>
I plan to review this change. We also need to figure out how to remove 
the dependency on this function from the JPLIS agent as that should not 
be there.

-Alan

From christoph.langer at sap.com  Mon Nov 18 09:21:31 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 18 Nov 2019 09:21:31 +0000
Subject: RFR: 8234185: Cleanup usage of canonicalize function between
 libjava, hotspot and libinstrument
In-Reply-To: 
References: 
 
 
 
Message-ID: 

> I plan to review this change. We also need to figure out how to remove
> the dependency on this function from the JPLIS agent as that should not
> be there.

Agree. I'd hope, however, that this can be done with a different change (unless you have an idea for a very simple, straightforward way that could fit under the umbrella of JDK- 8234185).

/Christoph

From julia.boes at oracle.com  Mon Nov 18 13:04:26 2019
From: julia.boes at oracle.com (Julia Boes)
Date: Mon, 18 Nov 2019 13:04:26 +0000
Subject: RFR: 8234335: Remove line break in class declaration in java.base
Message-ID: <7ed7ea03-be6f-2974-847d-c3c0364e9d9d@oracle.com>

Hi,

This cleanup work addresses an outdated coding convention in java.base. 
It removes the line break from a class declaration, for example:

 ??? public
 ??? TypeNameOnNextLine

becomes

 ??? public TypeNameOnSameLine


Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8234335/webrev.00/

Bug: https://bugs.openjdk.java.net/browse/JDK-8234335


Regards,

Julia




From tschoening at am-soft.de  Mon Nov 18 13:09:19 2019
From: tschoening at am-soft.de (=?windows-1250?Q?Thorsten_Sch=F6ning?=)
Date: Mon, 18 Nov 2019 14:09:19 +0100
Subject: RFR: 8234185: Cleanup usage of canonicalize function between
 libjava, hotspot and libinstrument
In-Reply-To: 
References: 
Message-ID: <489372066.20191118140919@am-soft.de>

Guten Tag Langer, Christoph,
am Donnerstag, 14. November 2019 um 16:37 schrieben Sie:

> please review this cleanup change regarding function "canonicalize" of libjava.
[...]
> The goal is to cleanup how this function is defined and used.[...]

If you are already changing "lastErrorReportable" for Windows, how
about adding ERROR_NO_MORE_FILES there as well to not run into
unnecessary exceptions under some circumstances?

https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-November/063437.html
https://stackoverflow.com/questions/58825588/does-java-need-to-support-error-no-more-files-when-canonicalizing-paths-on-windo
https://stackoverflow.com/questions/58825963/when-does-findfirstfilew-set-last-error-to-be-error-no-more-files-instead-of-err?noredirect=1&lq=1

Mit freundlichen Gr??en,

Thorsten Sch?ning

-- 
Thorsten Sch?ning       E-Mail: Thorsten.Schoening at AM-SoFT.de
AM-SoFT IT-Systeme      http://www.AM-SoFT.de/

Telefon...........05151-  9468- 55
Fax...............05151-  9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Gesch?ftsf?hrer: Andreas Muchow


From christoph.langer at sap.com  Mon Nov 18 13:22:11 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 18 Nov 2019 13:22:11 +0000
Subject: RFR: 8234185: Cleanup usage of canonicalize function between
 libjava,  hotspot and libinstrument
In-Reply-To: <489372066.20191118140919@am-soft.de>
References: 
 <489372066.20191118140919@am-soft.de>
Message-ID: 

Hi Thorsten,

I saw your other mail already but didn't find time to reply.

I'm actually not convinced that it is a good idea to add ERROR_NO_MORE_FILES to lastErrorReportable. The error codes listed there are conditions on which canonicalization of a path is stopped but the result is deemed correct. E.g. if the path only exists up to a certain directory, one can assume the rest of the path is canonic. Or if there are conditions like network errors or access denied, then further canonicalization isn't possible, too.

However, your case, the sporadic ERROR_NO_MORE_FILES, needs to be understood first. I rather think if this happens, there's a real condition for an IOException. It should definitely be analyzed and understood what the reason is for ERROR_NO_MORE_FILES. Are you aware of other reports of this issue? Was this already analyzed by some Windows experts, e.g. Microsoft support?

Best regards
Christoph


> -----Original Message-----
> From: Thorsten Sch?ning 
> Sent: Montag, 18. November 2019 14:09
> To: core-libs-dev at openjdk.java.net
> Cc: Langer, Christoph ; hotspot-runtime-
> dev at openjdk.java.net; gerard ziemski 
> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function between
> libjava, hotspot and libinstrument
> 
> Guten Tag Langer, Christoph,
> am Donnerstag, 14. November 2019 um 16:37 schrieben Sie:
> 
> > please review this cleanup change regarding function "canonicalize" of
> libjava.
> [...]
> > The goal is to cleanup how this function is defined and used.[...]
> 
> If you are already changing "lastErrorReportable" for Windows, how
> about adding ERROR_NO_MORE_FILES there as well to not run into
> unnecessary exceptions under some circumstances?
> 
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-
> November/063437.html
> https://stackoverflow.com/questions/58825588/does-java-need-to-
> support-error-no-more-files-when-canonicalizing-paths-on-windo
> https://stackoverflow.com/questions/58825963/when-does-findfirstfilew-
> set-last-error-to-be-error-no-more-files-instead-of-err?noredirect=1&lq=1
> 
> Mit freundlichen Gr??en,
> 
> Thorsten Sch?ning
> 
> --
> Thorsten Sch?ning       E-Mail: Thorsten.Schoening at AM-SoFT.de
> AM-SoFT IT-Systeme      http://www.AM-SoFT.de/
> 
> Telefon...........05151-  9468- 55
> Fax...............05151-  9468- 88
> Mobil..............0178-8 9468- 04
> 
> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
> AG Hannover HRB 207 694 - Gesch?ftsf?hrer: Andreas Muchow


From james.laskey at oracle.com  Mon Nov 18 14:26:27 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Mon, 18 Nov 2019 10:26:27 -0400
Subject: RFR: JDK-8233117 Escape Sequences For Line Continuation and White
 Space (Preview)
In-Reply-To: <818dcc2d-2d4a-57c7-a4e0-c1c873999c2a@oracle.com>
References: <0EEF3461-D8A4-496B-87DE-F143CB0FB995@oracle.com>
 <414cb097-9616-f4b0-8a3d-462a9ccfbdea@oracle.com>
 
 <00C5C729-D9FF-48E0-8F7F-DD8E7615ACEC@oracle.com>
 <818dcc2d-2d4a-57c7-a4e0-c1c873999c2a@oracle.com>
Message-ID: 

Editing glitch.Was there but then it was gone. Thanks Brent.

http://cr.openjdk.java.net/~jlaskey/8233116/webrev.04/index.html




> On Nov 15, 2019, at 7:47 PM, Brent Christian  wrote:
> 
> Hi, Jim
> 
> 
> src/java.base/share/classes/java/lang/String.java
> 
> These changes look fine.
> 
> --
> 
> test/jdk/java/lang/String/TranslateEscapes.java
> 
> I'm missing where the new verifyLineTerminator() method gets called. Perhaps that's meant to go here:
> 
>  83     static void test4() {
>  84
>  85     }
> 
> ?
> 
> -Brent
> 
> On 11/12/19 7:15 AM, Jim Laskey wrote:
>> updated
>> webrev: http://cr.openjdk.java.net/~jlaskey/8233116/webrev.03/index.html 


From jai.forums2013 at gmail.com  Mon Nov 18 15:01:39 2019
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Mon, 18 Nov 2019 20:31:39 +0530
Subject: Class-Path (in jar file) semantics different between Java 11 and 13
 (on Windows)?
Message-ID: 

Imagine 2 jar files. One called helloworld.jar which contains just a
single org.myapp.HelloWorld class which prints to System.out from its
main method. The other jar called manifest-cp-test.jar. This
manifest-cp-test.jar contains (only a) META-INF/MANIFEST.MF with the
following content:

Manifest-Version: 1.0
Class-Path: /C:/helloworld.jar
Main-Class: org.myapp.HelloWorld

So this manifest-cp-test.jar has a Main-Class entry which points to the
HelloWorld class that belongs in the other helloworld.jar file. Both the
helloworld.jar and the manifest-cp-test.jar reside at C:\ on a Windows
system.

When run using Java 11, this runs correctly and prints the HelloWorld
message:

C:\>jdk-11.0.2\bin\java -jar manifest-cp-test.jar
Hello World


However, when run using Java 13 (and even latest upstream Java 14) on
the same Windows system, this now runs into a ClassNotFoundException:

Java 13:

C:\>jdk-13.0.1\bin\java -jar manifest-cp-test.jar
Error: Could not find or load main class org.myapp.HelloWorld
Caused by: java.lang.ClassNotFoundException: org.myapp.HelloWorld


Java 14:

C:\>jdk-14\bin\java -jar manifest-cp-test.jar
Error: Could not find or load main class org.myapp.HelloWorld
Caused by: java.lang.ClassNotFoundException: org.myapp.HelloWorld


Adding the "-Djdk.net.URLClassPath.showIgnoredClassPathEntries=true"
debug flag to the java launch command shows:

C:\>jdk-13.0.1\bin\java
-Djdk.net.URLClassPath.showIgnoredClassPathEntries=true
-jar manifest-cp-test.jar
Class-Path entry: "/C:/helloworld.jar" ignored in JAR file
file:/C:/manifest-cp-
test.jar
Error: Could not find or load main class org.myapp.HelloWorld
Caused by: java.lang.ClassNotFoundException: org.myapp.HelloWorld

So this Class-Path entry is being ignored starting Java 13.

I compared the spec for Class-Path entry for Java 11[1] and Java 13[2]
and I do changes in that section. The Java 13 version doc has those 3
rules mentioned under "A Class-Path entry is valid if the following
conditions are true:". So all 3 rules should be satisfied? I guess that
then means that this style of Class-Path entry will not satisfy the "It
can be used to create a URL, by resolving it against the context JAR's
URL"? I haven't yet had the time to look into the code or read up a bit
more on what this rule actually means. Specifically what does resolve
mean here?

[1]
https://docs.oracle.com/en/java/javase/11/docs/specs/jar/jar.html#class-path-attribute

[2]
https://docs.oracle.com/en/java/javase/13/docs/specs/jar/jar.html#class-path-attribute

P.S: This is another case of Class-Path semantics which behave not just
differently in different versions of Java but different in different
subsystems of the same Java version itself. More about this has been
discussed recently in
https://mail.openjdk.java.net/pipermail/compiler-dev/2019-October/013766.html
on compiler-dev.

-Jaikiran


From jai.forums2013 at gmail.com  Mon Nov 18 15:03:04 2019
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Mon, 18 Nov 2019 20:33:04 +0530
Subject: Class-Path (in jar file) semantics different between Java 11 and
 13 (on Windows)?
In-Reply-To: 
References: 
Message-ID: <15bf7cd7-8549-8266-a460-1d0bb4359f84@gmail.com>

FWIW - this was reported by one of Quarkus project users here
https://github.com/quarkusio/quarkus/issues/5359

-Jaikiran

On 18/11/19 8:31 PM, Jaikiran Pai wrote:
> Imagine 2 jar files. One called helloworld.jar which contains just a
> single org.myapp.HelloWorld class which prints to System.out from its
> main method. The other jar called manifest-cp-test.jar. This
> manifest-cp-test.jar contains (only a) META-INF/MANIFEST.MF with the
> following content:
>
> Manifest-Version: 1.0
> Class-Path: /C:/helloworld.jar
> Main-Class: org.myapp.HelloWorld
>
> So this manifest-cp-test.jar has a Main-Class entry which points to the
> HelloWorld class that belongs in the other helloworld.jar file. Both the
> helloworld.jar and the manifest-cp-test.jar reside at C:\ on a Windows
> system.
>
> When run using Java 11, this runs correctly and prints the HelloWorld
> message:
>
> C:\>jdk-11.0.2\bin\java -jar manifest-cp-test.jar
> Hello World
>
>
> However, when run using Java 13 (and even latest upstream Java 14) on
> the same Windows system, this now runs into a ClassNotFoundException:
>
> Java 13:
>
> C:\>jdk-13.0.1\bin\java -jar manifest-cp-test.jar
> Error: Could not find or load main class org.myapp.HelloWorld
> Caused by: java.lang.ClassNotFoundException: org.myapp.HelloWorld
>
>
> Java 14:
>
> C:\>jdk-14\bin\java -jar manifest-cp-test.jar
> Error: Could not find or load main class org.myapp.HelloWorld
> Caused by: java.lang.ClassNotFoundException: org.myapp.HelloWorld
>
>
> Adding the "-Djdk.net.URLClassPath.showIgnoredClassPathEntries=true"
> debug flag to the java launch command shows:
>
> C:\>jdk-13.0.1\bin\java
> -Djdk.net.URLClassPath.showIgnoredClassPathEntries=true
> -jar manifest-cp-test.jar
> Class-Path entry: "/C:/helloworld.jar" ignored in JAR file
> file:/C:/manifest-cp-
> test.jar
> Error: Could not find or load main class org.myapp.HelloWorld
> Caused by: java.lang.ClassNotFoundException: org.myapp.HelloWorld
>
> So this Class-Path entry is being ignored starting Java 13.
>
> I compared the spec for Class-Path entry for Java 11[1] and Java 13[2]
> and I do changes in that section. The Java 13 version doc has those 3
> rules mentioned under "A Class-Path entry is valid if the following
> conditions are true:". So all 3 rules should be satisfied? I guess that
> then means that this style of Class-Path entry will not satisfy the "It
> can be used to create a URL, by resolving it against the context JAR's
> URL"? I haven't yet had the time to look into the code or read up a bit
> more on what this rule actually means. Specifically what does resolve
> mean here?
>
> [1]
> https://docs.oracle.com/en/java/javase/11/docs/specs/jar/jar.html#class-path-attribute
>
> [2]
> https://docs.oracle.com/en/java/javase/13/docs/specs/jar/jar.html#class-path-attribute
>
> P.S: This is another case of Class-Path semantics which behave not just
> differently in different versions of Java but different in different
> subsystems of the same Java version itself. More about this has been
> discussed recently in
> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-October/013766.html
> on compiler-dev.
>
> -Jaikiran
>

From tschoening at am-soft.de  Mon Nov 18 15:05:38 2019
From: tschoening at am-soft.de (=?iso-8859-1?Q?Thorsten_Sch=F6ning?=)
Date: Mon, 18 Nov 2019 16:05:38 +0100
Subject: RFR: 8234185: Cleanup usage of canonicalize function between
 libjava, hotspot and libinstrument
In-Reply-To: 
References: 
 <489372066.20191118140919@am-soft.de>
 
Message-ID: <1716757562.20191118160538@am-soft.de>

Guten Tag Langer, Christoph,
am Montag, 18. November 2019 um 14:22 schrieben Sie:

> I saw your other mail already but didn't find time to reply.

Thanks, I wasn't sure if I'm received at all. Now that I know and
because of your negative answer, I'm going to leave this thread alone
and whoever is interested in discussing my problem might do so in the
original thread:

https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-November/063437.html

Am only going to answer your concrete questions...

> However, your case, the sporadic ERROR_NO_MORE_FILES, needs to be
> understood first. I rather think if this happens, there's a real
> condition for an IOException.

I don't see much difference to real problems like
ERROR_NETWORK_UNREACHABLE, in which case you don't even know if paths
exist already, of what type they are etc. Compared to that, my
ProcMon-logs looked pretty reasonable and "correct". The only
difference is the error code some rare times, without any changes in
the overall setup otherwise.

> It should definitely be analyzed and
> understood what the reason is for ERROR_NO_MORE_FILES. Are you aware
> of other reports of this issue?

No, I couldn't find anything of interest besides what I linked already
on SO. Additionally, while my software is used by multiple customers
with Windows environment, only one suffers from this problem and it
seems to occur only in the recent past after migrating to Windows
Server 2016, some new SAN etc. I'm somewhat sure that it didn't happen
before, this would have been noticed, like it was now.

> Was this already analyzed by some Windows experts, e.g. Microsoft
> support?

No and it's unlikely to happen, that customer is busy of course... I'm
going to see if I can push things in that direction anyway.

Mit freundlichen Gr??en,

Thorsten Sch?ning

-- 
Thorsten Sch?ning       E-Mail: Thorsten.Schoening at AM-SoFT.de
AM-SoFT IT-Systeme      http://www.AM-SoFT.de/

Telefon...........05151-  9468- 55
Fax...............05151-  9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Gesch?ftsf?hrer: Andreas Muchow


From Roger.Riggs at oracle.com  Mon Nov 18 15:10:37 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Mon, 18 Nov 2019 10:10:37 -0500
Subject: RFR: 8234335: Remove line break in class declaration in java.base
In-Reply-To: <7ed7ea03-be6f-2974-847d-c3c0364e9d9d@oracle.com>
References: <7ed7ea03-be6f-2974-847d-c3c0364e9d9d@oracle.com>
Message-ID: <84601299-2199-9a16-1923-ffeb92a527a1@oracle.com>

Hi Julia,

Can you recheck the edit to java/lang/invoke/ClassSpecializer.java: 544

I would think the line should be broken at the "..."

* class TopClass { ... * private static final class Species_LLI extends 
TopClass {


MemberName.java:1098
It seems like there should be some indentation of the 2nd line of the declaration:

public 
........MemberName resolveOrFail(byte refKind, MemberName m, Class lookupClass,
                          Class nsmClass)

java/lang/invoke/MethodHandles.java: 3787

If we're putting "public" on the same line as the method then
it seems useful to put the /* non-public */ on the same line too.
Though I don't know we have style guidance for that.
(And elsewhere too).

Thanks, Roger

On 11/18/19 8:04 AM, Julia Boes wrote:
> Hi,
>
> This cleanup work addresses an outdated coding convention in 
> java.base. It removes the line break from a class declaration, for 
> example:
>
> ??? public
> ??? TypeNameOnNextLine
>
> becomes
>
> ??? public TypeNameOnSameLine
>
>
> Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8234335/webrev.00/
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8234335
>
>
> Regards,
>
> Julia
>
>
>


From Alan.Bateman at oracle.com  Mon Nov 18 15:36:26 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 18 Nov 2019 15:36:26 +0000
Subject: Class-Path (in jar file) semantics different between Java 11 and
 13 (on Windows)?
In-Reply-To: 
References: 
Message-ID: <2bac906c-8489-5611-6865-085fc389e5ea@oracle.com>

On 18/11/2019 15:01, Jaikiran Pai wrote:
> :
>
> So this Class-Path entry is being ignored starting Java 13.
>
Yes, bad values are now ignored, bringing an end to an effort on the 
run-time over multiple releases to fix the problems this area. 
JDK-8224253[1] is the JDK 13 release note to announce this change and I 
see you've found the system property that you can use to track down bad 
values. In previous releases you will get the same behavior with 
-Djdk.net.URLClassPath.disableClassPathURLCheck=false as the changes to 
reject bad input have been in place for some time. Brent can summarize 
but I think the only outstanding work is to fix the javac handling.

-Alan
[1] https://bugs.openjdk.java.net/browse/JDK-8224253

From Alan.Bateman at oracle.com  Mon Nov 18 15:47:39 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 18 Nov 2019 15:47:39 +0000
Subject: Class-Path (in jar file) semantics different between Java 11 and
 13 (on Windows)?
In-Reply-To: <15bf7cd7-8549-8266-a460-1d0bb4359f84@gmail.com>
References: 
 <15bf7cd7-8549-8266-a460-1d0bb4359f84@gmail.com>
Message-ID: 

On 18/11/2019 15:03, Jaikiran Pai wrote:
> FWIW - this was reported by one of Quarkus project users here
> https://github.com/quarkusio/quarkus/issues/5359
>
BTW: Do you know if this is a mistake in this project or something in a 
plugin used in its build? There was an outreach effort to tack to down 
build tools and plugins that were incorrectly setting the attribute 
value to a file path instead of a URL.

-Alan

From Roger.Riggs at oracle.com  Mon Nov 18 15:48:22 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Mon, 18 Nov 2019 10:48:22 -0500
Subject: RFR of JDK-8232446: logging enhancement for rmi when socket closed
In-Reply-To: <50bf13f3-f284-f3f4-1256-8ac51929637b@oracle.com>
References: <5048d354-a480-ac6d-e46d-a14ce4349691@oracle.com>
 <9db082f9-6e16-9e5e-1d99-280bbd381e8f@gmail.com>
 <50bf13f3-f284-f3f4-1256-8ac51929637b@oracle.com>
Message-ID: 

Hi Hamlin,

TCPConnection.java:212:

Keep the "close connection" logging and add the socket to the same log 
message:

If anyone is scraping the log, they won't loose this message. 
TCPTransport.tcpLog.log(Log.BRIEF, "close connection, socket: " + socket);

TCPTransport.java

277-278:? combine the message to be one logging call.
server socket
289: use Log.BRIEF, avoid creating mixture of and too many log levels.

Reword the log messages so they each begin with "server socket...",
or "server socket close"...
it makes it easier to grep for and coorelate related messages

Thanks, Roger


On 11/6/19 7:02 AM, Hamlin Li wrote:
>
> On 2019/11/6 5:36 PM, Peter Levart wrote:
>> Hi Hamlin,
>>
>> in TCPTransport.decrementExportCount():
>>
>> ?283???????????? try {
>> ?284???????????????? if (tcpLog.isLoggable(Log.BRIEF)) {
>> ?285???????????????????? tcpLog.log(Log.BRIEF, "close server socket 
>> on " + ss);
>> ?286???????????????? }
>> ?287???????????????? ss.close();
>> ?288???????????? } catch (IOException e) {
>> ?289???????????? }
>>
>> ...you could add a log statement to the catch block too. Or even 
>> better, rearrange for IOException to be thrown from that method and 
>> deal with it in two places:
>>
>> - in exportObject() - add it as suppressed exception to exception 
>> thrown from super.exportObject().
>> - in targetUnexported() - log it or wrap it into UncheckedIOException 
>> (depending on what are the callers of targetUnexported())
>>
>> What do you think?
> Thanks Peter.
>
> I agree. I adopt your first suggestion: add log statement to catch 
> block, as I think it's simple/straight and sufficient to help diagnose.
>
> And I also add log for catch blocks in other close places.
>
> The change is updated in place at: 
> http://cr.openjdk.java.net/~mli/8232446/webrev.00/
>
>
> Thank you
>
> -Hamlin
>
>>
>> Regards, Peter
>>
>>
>>
>> On 11/6/19 3:07 AM, Hamlin Li wrote:
>>> Would you please review the patch?
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8232446
>>>
>>> webrev: http://cr.openjdk.java.net/~mli/8232446/webrev.00/
>>>
>>>
>>> We have some intermittent failures in rmi related to socket closing, 
>>> this is to add more logging to help diagnose the issues.
>>>
>>>
>>> Thanks you
>>>
>>> -Hamlin
>>>
>>


From jai.forums2013 at gmail.com  Mon Nov 18 15:56:48 2019
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Mon, 18 Nov 2019 21:26:48 +0530
Subject: Class-Path (in jar file) semantics different between Java 11 and
 13 (on Windows)?
In-Reply-To: 
References: 
 <15bf7cd7-8549-8266-a460-1d0bb4359f84@gmail.com>
 
Message-ID: 

Hello Alan,

On 18/11/19 9:17 PM, Alan Bateman wrote:
> On 18/11/2019 15:03, Jaikiran Pai wrote:
>> FWIW - this was reported by one of Quarkus project users here
>> https://github.com/quarkusio/quarkus/issues/5359
>>
> BTW: Do you know if this is a mistake in this project or something in
> a plugin used in its build? 

AFAIK, It actually wasn't a mistake but an intentional effort to make it
work on Windows. The linked thread on compiler-dev[1] has details
(especially the interpretation of "relative URLs") about why the
Manifest was constructed in this manner. The actual code which does this
construction, resides here[2] .


> There was an outreach effort to tack to down build tools and plugins
> that were incorrectly setting the attribute value to a file path
> instead of a URL.
>
Quarkus is a relatively new project and furthermore this specific code
is very new too (a few months old I think). So I think this never got
covered as part of the outreach efforts.


[1]
https://mail.openjdk.java.net/pipermail/compiler-dev/2019-October/013766.html

[2]
https://github.com/quarkusio/quarkus/blob/master/devtools/maven/src/main/java/io/quarkus/maven/DevMojo.java#L390

-Jaikiran



From naoto.sato at oracle.com  Mon Nov 18 16:00:01 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 18 Nov 2019 08:00:01 -0800
Subject:  Turkish Time Zone name string and translation
In-Reply-To: 
References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>
 
 <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com>
 <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com>
 
 
Message-ID: <87dfcc98-f5d8-ca00-0d84-3fbc0c4253f7@oracle.com>

Thanks, Mark.

Apparently there seems to be a bug in CLDR converter code, which cannot 
generate the localized names for "Turkey" metazone. Thus the localized 
names from the legacy COMPAT locale data are being used. I will look 
into it.

Apart from this, what Letu found out stands by itself as a bug in COMPAT 
provider.

Naoto

On 11/17/19 11:16 PM, Mark Davis ?? wrote:
> You'd have to look at the spec. For most names a pattern plus the 
> country name is used. That can be overridden with a non-composed name 
> where needed.
> 
> {phone}
> 
> On Sun, Nov 17, 2019, 21:50 Martin Buchholz  > wrote:
> 
>     I've always wondered how the timezone-related translations are managed.
>     CLDR seems to be the master repository of such data, and projects like
>     OpenJDK are simply supposed to import that data.
>     But I looked at the CLDR sources, and there doesn't seem to be any
>     "Turkey
>     Time" strings defined like there are for e.g. Turkmenistan.
>     Maybe that work never got done?
> 
>     On Sat, Nov 16, 2019 at 6:44 AM      > wrote:
> 
>      > Letu,
>      >
>      > Please go ahead and fix the issue in English resource. As to the
>      > translation, Oracle l10n will translate it in appropriate locales.
>      >
>      > Naoto
>      >
>      > On 11/15/19 5:56 PM, Yang, Letu wrote:
>      > > Hi Naoto
>      > >
>      > > Thank you for the quick response! We will file a ticket later
>     today.
>      > >
>      > > Shall we make an effort on fixing and translating the strings,
>     or you
>      > > prefer to take care of it at Oracle?
>      > >
>      > > Letu
>      > >
>      > > On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com
>      wrote:
>      > > Hi Letu,
>      > >
>      > > Please file a JBS issue for this (component: core-libs,
>     subcomponent:
>      > > java.util:i18n).
>      > >
>      > > Naoto
>      > >
>      > > On 11/15/19 3:19 PM, Yang, Letu wrote:
>      > >> Hi,
>      > >>
>      > >> We recently found an issue with the Time Zone name for
>      > ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to
>     their own
>      > Turkish Time (TRT) zone in 2016, although the tzdata had been
>     updated, the
>      > Time Zone name string has not been updated yet:
>      > >>
>      > >>
>      >
>     https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836
>      > >>
>      > >> It still returns "Eastern European Time" for the
>      > TimeZone.getDisplayName call, which has a summer time while
>     Turkish Time
>      > does not. An entry for TRT need to be added to this file, and
>     assign to
>      > both "Europe/Istanbul" and "Asian/Istanbul". This also need to 
>     be updated
>      > for other locales. I can create a JBS issue for this, but I
>      > > am not sure whether we should fix this bug, or there is an existing
>      > > procedure for this kind of bug which requires language translation.
>      > >>
>      > >> Letu
>      > >>
>      > >>
>      > >>
>      >
> 

From andy.herrick at oracle.com  Mon Nov 18 17:01:34 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Mon, 18 Nov 2019 12:01:34 -0500
Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
In-Reply-To: 
References: 
Message-ID: 


On 11/13/2019 7:23 PM, Andy Herrick wrote:
> Please review? changes for [1] which is the implementation bug for 
> JEP-343.
>
> The webrev at [2] is the total cumulative webrev of changes for the 
> jpackage tool, currently in the JDK-8200758-branch branch of the open 
> sandbox repository.
>
> The webrev at [3] shows the changes since EA-06 (Build 
> 13-jpackage+1-49 ) up to the current point.

note: this "incremental" webrev is invalid - please disregard for now.? 
I will try to generate a valid delat-webrev.

/Andy

>
> The latest EA (Build 14-jpackage+1-49 ) is posted at [4].
>
> Please send feedback to core-libs-dev at openjdk.java.net
>
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8212780
>
> [2] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-10/
>
> [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-10/
>
> [4] http://jdk.java.net/jpackage/
>

From naoto.sato at oracle.com  Mon Nov 18 17:07:18 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 18 Nov 2019 09:07:18 -0800
Subject:  Turkish Time Zone name string and translation
In-Reply-To: 
References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>
 
 <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com>
 <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com>
 
Message-ID: <95b0ed5b-8e44-7aad-3f64-4bb00c2fa4f5@oracle.com>

Hi Letu,

Here are my comments to your changes:

- You will need a regression test for this fix. Take a look at 
test/jdk/sun/text/resources/LocaleDataTest.java, and add appropriate 
test cases.

- Fix comment should follow the OpenJDK changeset guideline [1]

- As to the change itself, I would put "Turkey Summer Time"/"TRST" for 
the 3rd and 4th array elements. Even though Turkey time do not observe 
DST, names in those slots should reflect the DST (consistent to other names)

- time zone id "Turkey" (line 1050) should also point to TRT array.

Naoto

[1] http://openjdk.java.net/guide/producingChangeset.html

On 11/17/19 8:54 PM, Yang, Letu wrote:
> Hi Naoto,
> 
> Thank you for the clarification!
> 
> Xin from my team has filed a JBS and uploaded my webrev:
> https://bugs.openjdk.java.net/browse/JDK-8234288
> https://cr.openjdk.java.net/~xliu/8234288/webrev.00/
> 
> Letu
> 
> ?On 11/16/19, 6:44 AM, "naoto.sato at oracle.com"  wrote:
> 
>      Letu,
>      
>      Please go ahead and fix the issue in English resource. As to the
>      translation, Oracle l10n will translate it in appropriate locales.
>      
>      Naoto
>      
>      On 11/15/19 5:56 PM, Yang, Letu wrote:
>      > Hi Naoto
>      >
>      > Thank you for the quick response! We will file a ticket later today.
>      >
>      > Shall we make an effort on fixing and translating the strings, or you
>      > prefer to take care of it at Oracle?
>      >
>      > Letu
>      >
>      > On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com wrote:
>      > Hi Letu,
>      >
>      > Please file a JBS issue for this (component: core-libs, subcomponent:
>      > java.util:i18n).
>      >
>      > Naoto
>      >
>      > On 11/15/19 3:19 PM, Yang, Letu wrote:
>      >> Hi,
>      >>
>      >> We recently found an issue with the Time Zone name for ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own Turkish Time (TRT) zone in 2016, although the tzdata had been updated, the Time Zone name string has not been updated yet:
>      >>
>      >> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836
>      >>
>      >> It still returns "Eastern European Time" for the TimeZone.getDisplayName call, which has a summer time while Turkish Time does not. An entry for TRT need to be added to this file, and assign to both "Europe/Istanbul" and "Asian/Istanbul". This also need to  be updated for other locales. I can create a JBS issue for this, but I
>      > am not sure whether we should fix this bug, or there is an existing
>      > procedure for this kind of bug which requires language translation.
>      >>
>      >> Letu
>      >>
>      >>
>      >>
>      
> 

From naoto.sato at oracle.com  Mon Nov 18 17:15:02 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 18 Nov 2019 09:15:02 -0800
Subject:  Turkish Time Zone name string and translation
In-Reply-To: 
References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>
 
 <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com>
 <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com>
 
 
 <87dfcc98-f5d8-ca00-0d84-3fbc0c4253f7@oracle.com>
 
Message-ID: <7392fc19-2e99-ee83-1f0c-0faa54ef61dc@oracle.com>

I should have been clearer, but the bug seems to be in the JDK tool 
which converts CLDR's xml into JDK's resource bundles. I implemented the 
CLDR's time zone names fallback spec with 
https://bugs.openjdk.java.net/browse/JDK-8181157, but again there seems 
to be a bug in the code.

Filed a JDK bug: https://bugs.openjdk.java.net/browse/JDK-8234347

Naoto

On 11/18/19 9:08 AM, Mark Davis ?? wrote:
> Could you file a ticket at
> https://unicode-org.atlassian.net/ ?
> 
> {phone}
> 
> On Mon, Nov 18, 2019, 16:02  > wrote:
> 
>     Thanks, Mark.
> 
>     Apparently there seems to be a bug in CLDR converter code, which cannot
>     generate the localized names for "Turkey" metazone. Thus the localized
>     names from the legacy COMPAT locale data are being used. I will look
>     into it.
> 
>     Apart from this, what Letu found out stands by itself as a bug in
>     COMPAT
>     provider.
> 
>     Naoto
> 
>     On 11/17/19 11:16 PM, Mark Davis ?? wrote:
>      > You'd have to look at the spec. For most names a pattern plus the
>      > country name is used. That can be overridden with a non-composed
>     name
>      > where needed.
>      >
>      > {phone}
>      >
>      > On Sun, Nov 17, 2019, 21:50 Martin Buchholz      
>      > >> wrote:
>      >
>      >? ? ?I've always wondered how the timezone-related translations
>     are managed.
>      >? ? ?CLDR seems to be the master repository of such data, and
>     projects like
>      >? ? ?OpenJDK are simply supposed to import that data.
>      >? ? ?But I looked at the CLDR sources, and there doesn't seem to
>     be any
>      >? ? ?"Turkey
>      >? ? ?Time" strings defined like there are for e.g. Turkmenistan.
>      >? ? ?Maybe that work never got done?
>      >
>      >? ? ?On Sat, Nov 16, 2019 at 6:44 AM      
>      >? ? ?     >> wrote:
>      >
>      >? ? ? > Letu,
>      >? ? ? >
>      >? ? ? > Please go ahead and fix the issue in English resource. As
>     to the
>      >? ? ? > translation, Oracle l10n will translate it in appropriate
>     locales.
>      >? ? ? >
>      >? ? ? > Naoto
>      >? ? ? >
>      >? ? ? > On 11/15/19 5:56 PM, Yang, Letu wrote:
>      >? ? ? > > Hi Naoto
>      >? ? ? > >
>      >? ? ? > > Thank you for the quick response! We will file a ticket
>     later
>      >? ? ?today.
>      >? ? ? > >
>      >? ? ? > > Shall we make an effort on fixing and translating the
>     strings,
>      >? ? ?or you
>      >? ? ? > > prefer to take care of it at Oracle?
>      >? ? ? > >
>      >? ? ? > > Letu
>      >? ? ? > >
>      >? ? ? > > On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com
>     
>      >? ? ?>
>     wrote:
>      >? ? ? > > Hi Letu,
>      >? ? ? > >
>      >? ? ? > > Please file a JBS issue for this (component: core-libs,
>      >? ? ?subcomponent:
>      >? ? ? > > java.util:i18n).
>      >? ? ? > >
>      >? ? ? > > Naoto
>      >? ? ? > >
>      >? ? ? > > On 11/15/19 3:19 PM, Yang, Letu wrote:
>      >? ? ? > >> Hi,
>      >? ? ? > >>
>      >? ? ? > >> We recently found an issue with the Time Zone name for
>      >? ? ? > ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to
>      >? ? ?their own
>      >? ? ? > Turkish Time (TRT) zone in 2016, although the tzdata had been
>      >? ? ?updated, the
>      >? ? ? > Time Zone name string has not been updated yet:
>      >? ? ? > >>
>      >? ? ? > >>
>      >? ? ? >
>      >
>     https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836
>      >? ? ? > >>
>      >? ? ? > >> It still returns "Eastern European Time" for the
>      >? ? ? > TimeZone.getDisplayName call, which has a summer time while
>      >? ? ?Turkish Time
>      >? ? ? > does not. An entry for TRT need to be added to this file, and
>      >? ? ?assign to
>      >? ? ? > both "Europe/Istanbul" and "Asian/Istanbul". This also
>     need to
>      >? ? ?be updated
>      >? ? ? > for other locales. I can create a JBS issue for this, but I
>      >? ? ? > > am not sure whether we should fix this bug, or there is
>     an existing
>      >? ? ? > > procedure for this kind of bug which requires language
>     translation.
>      >? ? ? > >>
>      >? ? ? > >> Letu
>      >? ? ? > >>
>      >? ? ? > >>
>      >? ? ? > >>
>      >? ? ? >
>      >
> 

From lance.andersen at oracle.com  Mon Nov 18 17:53:59 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 18 Nov 2019 12:53:59 -0500
Subject: RFR: 8234089: (zipfs) Remove classes JarFileSystemProvider and
 JarFileSystem
In-Reply-To: 
References: 
 <3532D7A1-DF2F-41BF-80BF-09EF53B022B6@oracle.com>
 
Message-ID: 

Hi Christoph,

Sorry for the late reply but I was out of the office Friday
> On Nov 15, 2019, at 3:40 AM, Langer, Christoph  wrote:
> 
> Hi Lance,
> 
> thanks for reviewing. I've addressed your points:
> 
>> I would suggesting moving the code added to the constructor for checking
>> the releaseVersion/multi-release properties to a method and grouping it
>> with the other methods added for supporting MR jars around line 1396.
>> (keeps it easier to follow and maintain)
> 
> Done that.

Thank you.  I do think however we need to change the name of the method to perhaps ?checkReleaseVersionProperty? as the current name ?initializeMultiReleaseJar?  does not seem quite right to me.

I would also update the comment for the method to something like:

----------------
Checks to see if the Zip File System property  ?releaseVersion? has been specified.  If it has not been specified then check for the existence of the ?multi-release? property.   If set and the file represents a multi-release JAR, determine the runtime version to use.
----------------

> 
>> Could you also add a comment above the isMultiReleaseJar method to for
>> clarity going forward (I know there was not one there before)
> 
> Done, too.

Thank you.

I think we can tweak the comment slightly to something like

???????
Returns true if the Manifest main attribute ?Multi-Release? is set to true; false otherwise
--------------------
> 
>> I might change the name of the lookup field in the method makeParentDirs
>> with the addition of the Function lookup on line 126.
> 
> I chose to change the name of the global field in line 126 to be named mrlookup. Also updated the comment.

I am not sure ?mrlookup? is the best name as this field is used with or without a multi-release jar.  Perhaps ?IndexNodeNameLookup? or
?entryLookup"
> 
> This is the new webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234089.2/
> 
> Cheers
> Christoph

Thank you again!

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 lance.andersen at oracle.com  Mon Nov 18 18:49:11 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 18 Nov 2019 13:49:11 -0500
Subject: RFR: 8234335: Remove line break in class declaration in java.base
In-Reply-To: <84601299-2199-9a16-1923-ffeb92a527a1@oracle.com>
References: <7ed7ea03-be6f-2974-847d-c3c0364e9d9d@oracle.com>
 <84601299-2199-9a16-1923-ffeb92a527a1@oracle.com>
Message-ID: <1ABE9DB3-E8FB-4C09-B54B-B3A73F457152@oracle.com>

Hi Roger, Julia,

> On Nov 18, 2019, at 10:10 AM, Roger Riggs  wrote:
> 
> If we're putting "public" on the same line as the method then
> it seems useful to put the /* non-public */ on the same line too.
> Though I don't know we have style guidance for that.
> (And elsewhere too).
> 

????????
-    /*non-public*/ static
     @DontInline
-    void maybeCustomize(MethodHandle mh) {
+    /*non-public*/ static void maybeCustomize(MethodHandle mh) {
         byte count = mh.customizationCount;
         if (count >= CUSTOMIZE_THRESHOLD) {
             mh.customize();

???????????

Is the above common coding in the JDK?  To me it seems to be more readable to have the comment above the method?    

If I run reformat in Intellij for example with code similar to the above, it will put /*non-public*/ on its own line.

Before reformat:

??????
/*non-public*/ static void foo(String f1) {
    System.out.printf("hello %s%n", f1);
}
?????????
After reformat:
?????
/*non-public*/
static void foo(String f1) {
    System.out.printf("hello %s%n", f1);
}
??????

HTH

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 mark at macchiato.com  Mon Nov 18 07:16:35 2019
From: mark at macchiato.com (=?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?=)
Date: Mon, 18 Nov 2019 07:16:35 +0000
Subject:  Turkish Time Zone name string and translation
In-Reply-To: 
References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>
 
 <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com>
 <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com>
 
Message-ID: 

You'd have to look at the spec. For most names a pattern plus the country
name is used. That can be overridden with a non-composed name where needed.

{phone}

On Sun, Nov 17, 2019, 21:50 Martin Buchholz  wrote:

> I've always wondered how the timezone-related translations are managed.
> CLDR seems to be the master repository of such data, and projects like
> OpenJDK are simply supposed to import that data.
> But I looked at the CLDR sources, and there doesn't seem to be any "Turkey
> Time" strings defined like there are for e.g. Turkmenistan.
> Maybe that work never got done?
>
> On Sat, Nov 16, 2019 at 6:44 AM  wrote:
>
> > Letu,
> >
> > Please go ahead and fix the issue in English resource. As to the
> > translation, Oracle l10n will translate it in appropriate locales.
> >
> > Naoto
> >
> > On 11/15/19 5:56 PM, Yang, Letu wrote:
> > > Hi Naoto
> > >
> > > Thank you for the quick response! We will file a ticket later today.
> > >
> > > Shall we make an effort on fixing and translating the strings, or you
> > > prefer to take care of it at Oracle?
> > >
> > > Letu
> > >
> > > On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com wrote:
> > > Hi Letu,
> > >
> > > Please file a JBS issue for this (component: core-libs, subcomponent:
> > > java.util:i18n).
> > >
> > > Naoto
> > >
> > > On 11/15/19 3:19 PM, Yang, Letu wrote:
> > >> Hi,
> > >>
> > >> We recently found an issue with the Time Zone name for
> > ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own
> > Turkish Time (TRT) zone in 2016, although the tzdata had been updated,
> the
> > Time Zone name string has not been updated yet:
> > >>
> > >>
> >
> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836
> > >>
> > >> It still returns "Eastern European Time" for the
> > TimeZone.getDisplayName call, which has a summer time while Turkish Time
> > does not. An entry for TRT need to be added to this file, and assign to
> > both "Europe/Istanbul" and "Asian/Istanbul". This also need to  be
> updated
> > for other locales. I can create a JBS issue for this, but I
> > > am not sure whether we should fix this bug, or there is an existing
> > > procedure for this kind of bug which requires language translation.
> > >>
> > >> Letu
> > >>
> > >>
> > >>
> >
>

From mark at macchiato.com  Mon Nov 18 17:08:10 2019
From: mark at macchiato.com (=?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?=)
Date: Mon, 18 Nov 2019 17:08:10 +0000
Subject:  Turkish Time Zone name string and translation
In-Reply-To: <87dfcc98-f5d8-ca00-0d84-3fbc0c4253f7@oracle.com>
References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>
 
 <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com>
 <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com>
 
 
 <87dfcc98-f5d8-ca00-0d84-3fbc0c4253f7@oracle.com>
Message-ID: 

Could you file a ticket at
https://unicode-org.atlassian.net/ ?

{phone}

On Mon, Nov 18, 2019, 16:02  wrote:

> Thanks, Mark.
>
> Apparently there seems to be a bug in CLDR converter code, which cannot
> generate the localized names for "Turkey" metazone. Thus the localized
> names from the legacy COMPAT locale data are being used. I will look
> into it.
>
> Apart from this, what Letu found out stands by itself as a bug in COMPAT
> provider.
>
> Naoto
>
> On 11/17/19 11:16 PM, Mark Davis ?? wrote:
> > You'd have to look at the spec. For most names a pattern plus the
> > country name is used. That can be overridden with a non-composed name
> > where needed.
> >
> > {phone}
> >
> > On Sun, Nov 17, 2019, 21:50 Martin Buchholz  > > wrote:
> >
> >     I've always wondered how the timezone-related translations are
> managed.
> >     CLDR seems to be the master repository of such data, and projects
> like
> >     OpenJDK are simply supposed to import that data.
> >     But I looked at the CLDR sources, and there doesn't seem to be any
> >     "Turkey
> >     Time" strings defined like there are for e.g. Turkmenistan.
> >     Maybe that work never got done?
> >
> >     On Sat, Nov 16, 2019 at 6:44 AM  >     > wrote:
> >
> >      > Letu,
> >      >
> >      > Please go ahead and fix the issue in English resource. As to the
> >      > translation, Oracle l10n will translate it in appropriate locales.
> >      >
> >      > Naoto
> >      >
> >      > On 11/15/19 5:56 PM, Yang, Letu wrote:
> >      > > Hi Naoto
> >      > >
> >      > > Thank you for the quick response! We will file a ticket later
> >     today.
> >      > >
> >      > > Shall we make an effort on fixing and translating the strings,
> >     or you
> >      > > prefer to take care of it at Oracle?
> >      > >
> >      > > Letu
> >      > >
> >      > > On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com
> >      wrote:
> >      > > Hi Letu,
> >      > >
> >      > > Please file a JBS issue for this (component: core-libs,
> >     subcomponent:
> >      > > java.util:i18n).
> >      > >
> >      > > Naoto
> >      > >
> >      > > On 11/15/19 3:19 PM, Yang, Letu wrote:
> >      > >> Hi,
> >      > >>
> >      > >> We recently found an issue with the Time Zone name for
> >      > ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to
> >     their own
> >      > Turkish Time (TRT) zone in 2016, although the tzdata had been
> >     updated, the
> >      > Time Zone name string has not been updated yet:
> >      > >>
> >      > >>
> >      >
> >
> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836
> >      > >>
> >      > >> It still returns "Eastern European Time" for the
> >      > TimeZone.getDisplayName call, which has a summer time while
> >     Turkish Time
> >      > does not. An entry for TRT need to be added to this file, and
> >     assign to
> >      > both "Europe/Istanbul" and "Asian/Istanbul". This also need to
> >     be updated
> >      > for other locales. I can create a JBS issue for this, but I
> >      > > am not sure whether we should fix this bug, or there is an
> existing
> >      > > procedure for this kind of bug which requires language
> translation.
> >      > >>
> >      > >> Letu
> >      > >>
> >      > >>
> >      > >>
> >      >
> >
>

From TobiasDiez at gmx.de  Sun Nov 17 18:56:51 2019
From: TobiasDiez at gmx.de (TobiasDiez)
Date: Sun, 17 Nov 2019 11:56:51 -0700 (MST)
Subject: Jpackage bug: Failed to find runtime/bin/jli.dll
In-Reply-To: <1a68b981-acf3-154d-7a70-2879df9a7fe7@oracle.com>
References: <00c701d59629$09156400$1b402c00$@gmx.de>
 <1a68b981-acf3-154d-7a70-2879df9a7fe7@oracle.com>
Message-ID: <1574017011871-0.post@n7.nabble.com>

Thanks for investigating the issue. It is indeed fixed in the latest version
(jpackage 70). Thanks!



--
Sent from: http://openjdk.5641.n7.nabble.com/OpenJDK-Core-Libraries-f45829.html

From fweimer at redhat.com  Mon Nov 18 20:49:42 2019
From: fweimer at redhat.com (Florian Weimer)
Date: Mon, 18 Nov 2019 21:49:42 +0100
Subject: RFR 8234362: k_standard.c is not needed and should be removed (was:
 Re: _IEEE_LIBM targets and __kernel_standard)
In-Reply-To: <87y2wmv3a2.fsf@oldenburg2.str.redhat.com> (Florian Weimer's
 message of "Mon, 11 Nov 2019 16:30:45 +0100")
References: <87y2wmv3a2.fsf@oldenburg2.str.redhat.com>
Message-ID: <871ru429ll.fsf@oldenburg2.str.redhat.com>

* Florian Weimer:

> __kernel_standard in src/java.base/share/native/libfdlibm/k_standard.c
> is built for _IEEE_LIBM targets as well, but it appears superfluous
> there.
>
> In noticed this because GCC 10 flags an uninitialized variable in this
> code:
>
> ?/src/java.base/share/native/libfdlibm/k_standard.c: In function '__j__kernel_standard':
> ?/src/java.base/share/native/libfdlibm/k_standard.c:743:19: error: 'exc.retval' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>   743 |         return exc.retval;
>       |                ~~~^~~~~~~
>
> Rather than debating whether this warning is reasonableor not, I would
> suggest to #ifdef out this code for _IEEE_LIBM targets (are there any
> else left?).

I think the file should just be removed.

Bug: 
Webrev: 

As usual, I'll need a sponsor for this.

Thanks,
Florian


From ioi.lam at oracle.com  Mon Nov 18 21:21:47 2019
From: ioi.lam at oracle.com (Ioi Lam)
Date: Mon, 18 Nov 2019 13:21:47 -0800
Subject: Should Java support ERROR_NO_MORE_FILES when canonicalizing paths
 on Windows?
In-Reply-To: <346034750.20191114204642@am-soft.de>
References: <346034750.20191114204642@am-soft.de>
Message-ID: 

Hi Thorsten, since you have problems filing bugs on JBS, I filed the 
following bug on your behalf.

https://bugs.openjdk.java.net/browse/JDK-8234363

I have not investigated the issue in detail yet. How often do you see 
ERROR_NO_MORE_FILES happening? Have you checked if your process 
(apache?) has too many open files such that FindFirstFileW is not able 
to open the directory to get a file listing?

If that is indeed the case, I am not sure what's the best way of 
handling it. If resource (file descriptors) are running out, perhaps the 
current behavior of throwing an exception in 
WinNTFileSystem.canonicalize0() would be better than just ignoring it 
and return an incorrect result. But I'll defer to the folks on the 
core-libs team.

Thanks
- Ioi



On 11/14/19 11:46 AM, Thorsten Sch?ning wrote:
> Hi all,
>
> while the details can be read on SO[1][2], the bottom line is that I
> have a setup in which Windows sets the error code ERROR_NO_MORE_FILES
> during calls to FindFirstFileW sometimes. In theory that shouldn't
> happen, but it simply does once in a while and make my Java daemon run
> into exceptions, because that error code isn't expected.
>
> The following lists all expected error codes from the function
> "lastErrorReportable", which is used during canonicalizing paths:
>
>>     if ((errval == ERROR_FILE_NOT_FOUND)
>>         || (errval == ERROR_DIRECTORY)
>>         || (errval == ERROR_PATH_NOT_FOUND)
>>         || (errval == ERROR_BAD_NETPATH)
>>         || (errval == ERROR_BAD_NET_NAME)
>>         || (errval == ERROR_ACCESS_DENIED)
>>         || (errval == ERROR_NETWORK_UNREACHABLE)
>>         || (errval == ERROR_NETWORK_ACCESS_DENIED)) {
>>         return 0;
>>     }
> https://github.com/openjdk/jdk/blob/master/src/java.base/windows/native/libjava/canonicalize_md.c#L131
>
> Obviously ERROR_NO_MORE_FILES is missing, but its pretty interesting
> as well that Java supports other error codes already. Regarding the
> docs, FindFirstFileW should only return ERROR_FILE_NOT_FOUND, but most
> likely people ran into other error codes already Windows used in
> various circumstances. All of those totally make sense.
>
> So, how about adding ERROR_NO_MORE_FILES there as well?
>
> As can be read in my SO-questions, I didn't recognized any other real
> technical problem like permissions issues, timeouts in the network or
> stuff. Its only that Windows sometimes decides to use that error code
> for some unknown reason. Adding it would only be one line of text and
> increase compatibility with setups like mine. I guess problems like
> these were the reason to add other error codes in the past as well.
>
> Thanks!
>
> [1]: https://stackoverflow.com/questions/58825588/does-java-need-to-support-error-no-more-files-when-canonicalizing-paths-on-windo
> [2]: https://stackoverflow.com/questions/58825963/when-does-findfirstfilew-set-last-error-to-be-error-no-more-files-instead-of-err?noredirect=1&lq=1
>
> Mit freundlichen Gr??en,
>
> Thorsten Sch?ning
>


From gunnar at hibernate.org  Tue Nov 19 08:34:41 2019
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 19 Nov 2019 09:34:41 +0100
Subject: JEP 358 (Helpful NPEs) and single source file mode
Message-ID: 

Hi,

I've been exploring the new helpful NPE feature a bit.

It's a very welcomed improvement, but I noticed one potential usability
issue in conjunction with the single source file mode (JEP 330): as debug
info is missing in that case, e.g. local variables are rendered as
"" in the exception message. Single source file mode also doesn't
let me specify the "-g:vars" option I could use with javac for adding the
debugging info.

Perhaps single source file mode should add debug information by default to
prevent this issue?

Thanks,

--Gunnar

From forax at univ-mlv.fr  Tue Nov 19 08:40:27 2019
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 19 Nov 2019 09:40:27 +0100 (CET)
Subject: JEP 358 (Helpful NPEs) and single source file mode
In-Reply-To: 
References: 
Message-ID: <1619831852.538078.1574152827976.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Gunnar Morling" 
> ?: "core-libs-dev" 
> Envoy?: Mardi 19 Novembre 2019 09:34:41
> Objet: JEP 358 (Helpful NPEs) and single source file mode

> Hi,
> 
> I've been exploring the new helpful NPE feature a bit.
> 
> It's a very welcomed improvement, but I noticed one potential usability
> issue in conjunction with the single source file mode (JEP 330): as debug
> info is missing in that case, e.g. local variables are rendered as
> "" in the exception message. Single source file mode also doesn't
> let me specify the "-g:vars" option I could use with javac for adding the
> debugging info.
> 
> Perhaps single source file mode should add debug information by default to
> prevent this issue?

yes !

> 
> Thanks,
> 
> --Gunnar

R?mi


From matthias.baesken at sap.com  Tue Nov 19 09:23:12 2019
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 19 Nov 2019 09:23:12 +0000
Subject: RFR [XS] : 8234339: replace JLI_StrTok in java_md_solinux.c
Message-ID: 

Hello, please review this small change .

JLI_StrTok is only used in one function, so the define can be replaced, probably we should use the "safer" strtok_r (the MT safety might not be a big deal in the launcher however).


Bug/webrev :

https://bugs.openjdk.java.net/browse/JDK-8234339

http://cr.openjdk.java.net/~mbaesken/webrevs/8234339.0/


Thanks, Matthias

From maurizio.cimadamore at oracle.com  Tue Nov 19 09:24:46 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 19 Nov 2019 09:24:46 +0000
Subject: JEP 358 (Helpful NPEs) and single source file mode
In-Reply-To: 
References: 
Message-ID: <68003ce7-fc9a-eade-cce5-73112b667f24@oracle.com>

I like this suggestion a lot.

Maurizio

On 19/11/2019 08:34, Gunnar Morling wrote:
> Hi,
>
> I've been exploring the new helpful NPE feature a bit.
>
> It's a very welcomed improvement, but I noticed one potential usability
> issue in conjunction with the single source file mode (JEP 330): as debug
> info is missing in that case, e.g. local variables are rendered as
> "" in the exception message. Single source file mode also doesn't
> let me specify the "-g:vars" option I could use with javac for adding the
> debugging info.
>
> Perhaps single source file mode should add debug information by default to
> prevent this issue?
>
> Thanks,
>
> --Gunnar

From tschoening at am-soft.de  Tue Nov 19 09:30:30 2019
From: tschoening at am-soft.de (=?utf-8?Q?Thorsten_Sch=C3=B6ning?=)
Date: Tue, 19 Nov 2019 10:30:30 +0100
Subject: Should Java support ERROR_NO_MORE_FILES when canonicalizing paths
 on Windows?
In-Reply-To: 
References: <346034750.20191114204642@am-soft.de>
 
Message-ID: <1841161740.20191119103030@am-soft.de>

Guten Tag Ioi Lam,
am Montag, 18. November 2019 um 22:21 schrieben Sie:

> https://bugs.openjdk.java.net/browse/JDK-8234363

Thanks for doing that!

> I have not investigated the issue in detail yet. How often do you see 
> ERROR_NO_MORE_FILES happening?

It's difficult to say currently because my customer doesn't monitor
such things. So I don't know when it starts to happen and if so, if it
happens always really. From my tests, it seems to start at some point
and happens occasionally afterwards, maybe even getting more. But it
still doesn't happen always, during my tests there where some times at
which copying the files succeeded.

I'm trying to get some more logs in the meantime to find a pattern.

> Have you checked if your process
> (apache?) has too many open files such that FindFirstFileW is not able
> to open the directory to get a file listing?

With Apache I meant the Java-lib providing some I/O-helpers[1], not
the web server or stuff. My daemon is a plain Java-process started
manually on the shell and I'm somewhat sure that I don't have a
handle-leak in that process because of the following reasons:

At the point where I copy things and ERROR_NOR_MORE_FILES happen, I
don't have any open files myself anymore and looking at SCM-logs, code
didn't change. Commons-IO hasn't been updated in years as well, so is
unlikely to newly introduce leaks as well.

Besides that, what Process Monitor[2] logs during success/failure
looks exactly the same in case of error vs. success, the only
difference being ERROR_NO_SUCH_FILE vs. ERROR_NO_MORE_FILES. If there
would be some handle leak in the process resulting in the IOException,
keeping the process running would fail in former file-related
operations already, where I really read and create files on my own.
But that's not the case, all those operations always succeed, only
when it's about copying the created files into their target directory
things start failing at some point, but even then still succeed
sometimes.

But the most important thing in my opinion is that the error is
persistent during restarts of my daemon, which should clear all open
handles in theory. When the problem happens often, restarting my
daemon doesn't seem to change anything. What instantly solves the
problem is clearing the target directory of the copy operation,
either by renaming the old one and creating a new one or by simply
deleting what is present in that directory currently. ONLY if I do one
of those things the copy operations start to succeed reliably again,
regardless of if the daemon is restartedt or kept running even after
failing before.

I don't care about formerly available contents in the target directory
myself, but am using files with timestamps and stuff like that. And
that's my point: While there surely is some problem somewhere, I think
it's most likely to be in the infrastructure of my customer, because
he has storage-related problems anyway. Things are too slow sometimes
and all that. While I don't see anything of those problems in ProcMon,
like timeouts, permissions problems or other real errors, when my
problem occurs, it might simply be that Windows internally behaves
undocumented for some currently unknown reason.

By allowing ERROR_NO_MORE_FILES it might be that whatever the problem
in Windows might be simply gets ignored up until a point where a real
problem happens. And if that doesn't occur in the end, one doesn't
need to care as well. Allowing ERROR_NO_MORE_FILES doesn't look that
different to e.g. ERROR_NETWORK_UNREACHABLE to me, because in my setup
the latter would be the even bigger problem, as I'm copying things on
network shares in the end.

> If that is indeed the case, I am not sure what's the best way of
> handling it. If resource (file descriptors) are running out, perhaps the
> current behavior of throwing an exception in 
> WinNTFileSystem.canonicalize0() would be better than just ignoring it 
> and return an incorrect result. But I'll defer to the folks on the 
> core-libs team.

Please notice that Windows has ERROR_TOO_MANY_OPEN_FILES for that, so
in my opinion this is another strong hint that ERROR_NO_MORE_FILES
really is some kind of success. Only undocumented/unepxected, but that
seems to be the case with many of the other error codes handled in
"lastErrorReportable" as well.

[1]: https://commons.apache.org/proper/commons-io/
[2]: https://docs.microsoft.com/en-us/sysinternals/downloads/procmon

Mit freundlichen Gr??en,

Thorsten Sch?ning

-- 
Thorsten Sch?ning       E-Mail: Thorsten.Schoening at AM-SoFT.de
AM-SoFT IT-Systeme      http://www.AM-SoFT.de/

Telefon...........05151-  9468- 55
Fax...............05151-  9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Gesch?ftsf?hrer: Andreas Muchow


From dalibor.topic at oracle.com  Tue Nov 19 09:50:20 2019
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Tue, 19 Nov 2019 10:50:20 +0100
Subject: Class-Path (in jar file) semantics different between Java 11 and
 13 (on Windows)?
In-Reply-To: 
References: 
 <15bf7cd7-8549-8266-a460-1d0bb4359f84@gmail.com>
 
 
Message-ID: <650a9107-e62a-54e4-2ac0-0742ae2d5440@oracle.com>



On 18.11.2019 16:56, Jaikiran Pai wrote:
> Quarkus is a relatively new project and furthermore this specific code
> is very new too (a few months old I think). So I think this never got
> covered as part of the outreach efforts.
> 

Yeah, Quarkus is not on the OpenJDK Quality Outreach list yet. I've just 
pinged Emmanuel Bernard about adding it there, so we'll see if that'll 
change. ;)

cheers,
dalibor topic
-- 

Dalibor Topic | Consulting Product Manager
Phone: +494089091214  | Mobile: +491737185961
 | Video: dalibor.topic at oracle.com


Oracle Global Services Germany GmbH
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRB 246209
Gesch?ftsf?hrer: Ralf Herrmann

 Oracle is committed to developing
practices and products that help protect the environment

From tschoening at am-soft.de  Tue Nov 19 09:58:05 2019
From: tschoening at am-soft.de (=?utf-8?Q?Thorsten_Sch=C3=B6ning?=)
Date: Tue, 19 Nov 2019 10:58:05 +0100
Subject: Should Java support ERROR_NO_MORE_FILES when canonicalizing paths
 on Windows?
In-Reply-To: <1841161740.20191119103030@am-soft.de>
References: <346034750.20191114204642@am-soft.de> 
 
 <1841161740.20191119103030@am-soft.de>
Message-ID: <510285966.20191119105805@am-soft.de>

Guten Tag Thorsten Sch?ning,
am Dienstag, 19. November 2019 um 10:30 schrieben Sie:

> Please notice that Windows has ERROR_TOO_MANY_OPEN_FILES for that, so
> in my opinion this is another strong hint that ERROR_NO_MORE_FILES
> really is some kind of success. Only undocumented/unepxected, but that
> seems to be the case with many of the other error codes handled in
> "lastErrorReportable" as well.

I've searched the web again about people using ERROR_NO_MORE_FILES
strictly in context of FindFirstFile and at least found some:

https://www.tek-tips.com/viewthread.cfm?qid=876612
https://www.perlmonks.org/?node_id=1104873
ftp://kermit.columbia.edu/kermit/k95source/findfile.c
https://books.google.de/books?id=AF5Lr5HA5UEC&pg=PA68&lpg=PA68&dq=FindFirstFileW+ERROR_NO_MORE_FILES&source=bl&ots=Uvk3ZWJ3vo&sig=ACfU3U1XcESErD0A6I9zPfMjN9GG2pmJeQ&hl=de&sa=X&ved=2ahUKEwjc-dL1__XlAhWPKFAKHanrDi84FBDoATAJegQIChAB#v=onepage&q=FindFirstFileW%20ERROR_NO_MORE_FILES&f=false

Mit freundlichen Gr??en,

Thorsten Sch?ning

-- 
Thorsten Sch?ning       E-Mail: Thorsten.Schoening at AM-SoFT.de
AM-SoFT IT-Systeme      http://www.AM-SoFT.de/

Telefon...........05151-  9468- 55
Fax...............05151-  9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Gesch?ftsf?hrer: Andreas Muchow


From julia.boes at oracle.com  Tue Nov 19 10:06:44 2019
From: julia.boes at oracle.com (Julia Boes)
Date: Tue, 19 Nov 2019 10:06:44 +0000
Subject: RFR: 8234335: Remove line break in class declaration in java.base
In-Reply-To: <1ABE9DB3-E8FB-4C09-B54B-B3A73F457152@oracle.com>
References: <7ed7ea03-be6f-2974-847d-c3c0364e9d9d@oracle.com>
 <84601299-2199-9a16-1923-ffeb92a527a1@oracle.com>
 <1ABE9DB3-E8FB-4C09-B54B-B3A73F457152@oracle.com>
Message-ID: 

Hi Roger, Lance,


> Can you recheck the edit to java/lang/invoke/ClassSpecializer.java: 544
>
> I would think the line should be broken at the "..."
>
> * class TopClass { ... * private static final class Species_LLI 
> extends TopClass {

That's right, there was also a closing brace missing.


> MemberName.java:1098
> It seems like there should be some indentation of the 2nd line of the 
> declaration:
>
> public 
> ........MemberName resolveOrFail(byte refKind, MemberName m, Class 
> lookupClass,
> ???????????????????????? Class nsmClass)

Done.


>> If we're putting "public" on the same line as the method then
>> it seems useful to put the /* non-public */ on the same line too.
>> Though I don't know we have style guidance for that.
>> (And elsewhere too).
> Is the above common coding in the JDK?  To me it seems to be more readable to have the comment above the method?
>
> If I run reformat in Intellij for example with code similar to the above, it will put /*non-public*/ on its own line.
>
> Before reformat:
>
> ??????
> /*non-public*/ static void foo(String f1) {
>      System.out.printf("hello %s%n", f1);
> }
> ?????????
> After reformat:
> ?????
> /*non-public*/
> static void foo(String f1) {
>      System.out.printf("hello %s%n", f1);
> }
> ??????

Looking at the existing code base, the same-line version is slightly 
more common (57 of 100). I would lean on the side of consistency and 
stick to the same-line version unless there are any objections.

Updated webrev: http://cr.openjdk.java.net/~jboes/webrevs/8234335/webrev.01/


Regards,

Julia



From maurizio.cimadamore at oracle.com  Tue Nov 19 10:22:10 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 19 Nov 2019 10:22:10 +0000
Subject: JEP 358 (Helpful NPEs) and single source file mode
In-Reply-To: <68003ce7-fc9a-eade-cce5-73112b667f24@oracle.com>
References: 
 <68003ce7-fc9a-eade-cce5-73112b667f24@oracle.com>
Message-ID: <1ffc06ea-e6d6-c786-f77b-23a99148b7e5@oracle.com>

It occurred to me that jshell is yet another area where we might want to 
turn better NPE messages on by default.

Maurizio

On 19/11/2019 09:24, Maurizio Cimadamore wrote:
> I like this suggestion a lot.
>
> Maurizio
>
> On 19/11/2019 08:34, Gunnar Morling wrote:
>> Hi,
>>
>> I've been exploring the new helpful NPE feature a bit.
>>
>> It's a very welcomed improvement, but I noticed one potential usability
>> issue in conjunction with the single source file mode (JEP 330): as 
>> debug
>> info is missing in that case, e.g. local variables are rendered as
>> "" in the exception message. Single source file mode also 
>> doesn't
>> let me specify the "-g:vars" option I could use with javac for adding 
>> the
>> debugging info.
>>
>> Perhaps single source file mode should add debug information by 
>> default to
>> prevent this issue?
>>
>> Thanks,
>>
>> --Gunnar

From lance.andersen at oracle.com  Tue Nov 19 12:00:53 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 19 Nov 2019 07:00:53 -0500
Subject: RFR: 8234335: Remove line break in class declaration in java.base
In-Reply-To: 
References: <7ed7ea03-be6f-2974-847d-c3c0364e9d9d@oracle.com>
 <84601299-2199-9a16-1923-ffeb92a527a1@oracle.com>
 <1ABE9DB3-E8FB-4C09-B54B-B3A73F457152@oracle.com>
 
Message-ID: 

Hi Julia
> On Nov 19, 2019, at 5:06 AM, Julia Boes  wrote:
> 
> Hi Roger, Lance,
> 
>>> If we're putting "public" on the same line as the method then
>>> it seems useful to put the /* non-public */ on the same line too.
>>> Though I don't know we have style guidance for that.
>>> (And elsewhere too).
>> Is the above common coding in the JDK?  To me it seems to be more readable to have the comment above the method?
>> 
>> If I run reformat in Intellij for example with code similar to the above, it will put /*non-public*/ on its own line.
>> 
>> Before reformat:
>> 
>> ??????
>> /*non-public*/ static void foo(String f1) {
>>     System.out.printf("hello %s%n", f1);
>> }
>> ?????????
>> After reformat:
>> ?????
>> /*non-public*/
>> static void foo(String f1) {
>>     System.out.printf("hello %s%n", f1);
>> }
>> ??????
> 
> Looking at the existing code base, the same-line version is slightly more common (57 of 100). I would lean on the side of consistency and stick to the same-line version unless there are any objections.
> 
> Updated webrev: http://cr.openjdk.java.net/~jboes/webrevs/8234335/webrev.01/

Seems to be a ?your milage varies?.  I am fine with whatever the final decision is.  However, I do believe the comment above reads better and aligns the methods better.

Best
Lance
> 
> 
> Regards,
> 
> Julia
> 
> 

 
  
 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 vladimir.x.ivanov at oracle.com  Tue Nov 19 16:53:09 2019
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Tue, 19 Nov 2019 19:53:09 +0300
Subject: [14] RFR (S): 8234401: ConstantCallSite may stuck in non-frozen state
Message-ID: 

http://cr.openjdk.java.net/~vlivanov/8234401/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8234401

ConstantCallSite has a ctor which deliberately leaks partially 
initialized instance into user code. isFrozen is declared final and if 
user code is obstinate enough, it can end up with non-frozen state 
embedded into the generated code. It manifests as a ConstantCallSite 
instance which is stuck in non-frozen state.

I switched isFrozen from final to @Stable, so non-frozen state is never 
constant folded. Put some store-store barriers along the way to restore 
final field handling.

I deliberately stopped there (just restoring isFrozen final field 
behavior). Without proper synchronization, there's still a theoretical 
possibility of transiently observing a call site in non-frozen state 
right after ctor is over. But at least there's no way anymore to 
accidentally break an instance in such a way it becomes permanently 
unusable.

PS: converted CallSite.target to final along the way and made some other 
minor refactorings.

Testing: regression test, tier1-2

Best regards,
Vladimir Ivanov

From paul.sandoz at oracle.com  Tue Nov 19 17:35:44 2019
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 19 Nov 2019 09:35:44 -0800
Subject: [14] RFR (S): 8234401: ConstantCallSite may stuck in non-frozen
 state
In-Reply-To: 
References: 
Message-ID: 

Ah the perils of partial construction :-)

Subtle, so I could be misunderstanding something, did you intend to remove the assignment of isFrozen in the ConstantCallSite constructor?

ConstantCallSite:

     protected ConstantCallSite(MethodType targetType, MethodHandle createTargetHook) throws Throwable {

-        super(targetType, createTargetHook);
-        isFrozen = true;
+        super(targetType, createTargetHook); // "this" instance leaks into createTargetHook
+        UNSAFE.storeStoreFence(); // properly publish isFrozen

     }

Paul.

> On Nov 19, 2019, at 8:53 AM, Vladimir Ivanov  wrote:
> 
> http://cr.openjdk.java.net/~vlivanov/8234401/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8234401
> 
> ConstantCallSite has a ctor which deliberately leaks partially initialized instance into user code. isFrozen is declared final and if user code is obstinate enough, it can end up with non-frozen state embedded into the generated code. It manifests as a ConstantCallSite instance which is stuck in non-frozen state.
> 
> I switched isFrozen from final to @Stable, so non-frozen state is never constant folded. Put some store-store barriers along the way to restore final field handling.
> 
> I deliberately stopped there (just restoring isFrozen final field behavior). Without proper synchronization, there's still a theoretical possibility of transiently observing a call site in non-frozen state right after ctor is over. But at least there's no way anymore to accidentally break an instance in such a way it becomes permanently unusable.
> 
> PS: converted CallSite.target to final along the way and made some other minor refactorings.
> 
> Testing: regression test, tier1-2
> 
> Best regards,
> Vladimir Ivanov


From vladimir.x.ivanov at oracle.com  Tue Nov 19 17:49:35 2019
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Tue, 19 Nov 2019 20:49:35 +0300
Subject: [14] RFR (S): 8234401: ConstantCallSite may stuck in non-frozen
 state
In-Reply-To: 
References: 
 
Message-ID: 


> Subtle, so I could be misunderstanding something, did you intend to remove the assignment of isFrozen in the ConstantCallSite constructor?

Oh, good catch. It is my fault: the update should be there. (The 
barriers are added just to preserve final field semantics for isFrozen.)

Published the wrong version (with some leftovers from last-minute failed 
experiment). Updated in place.

Best regards,
Vladimir Ivanov

>> On Nov 19, 2019, at 8:53 AM, Vladimir Ivanov  wrote:
>>
>> http://cr.openjdk.java.net/~vlivanov/8234401/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8234401
>>
>> ConstantCallSite has a ctor which deliberately leaks partially initialized instance into user code. isFrozen is declared final and if user code is obstinate enough, it can end up with non-frozen state embedded into the generated code. It manifests as a ConstantCallSite instance which is stuck in non-frozen state.
>>
>> I switched isFrozen from final to @Stable, so non-frozen state is never constant folded. Put some store-store barriers along the way to restore final field handling.
>>
>> I deliberately stopped there (just restoring isFrozen final field behavior). Without proper synchronization, there's still a theoretical possibility of transiently observing a call site in non-frozen state right after ctor is over. But at least there's no way anymore to accidentally break an instance in such a way it becomes permanently unusable.
>>
>> PS: converted CallSite.target to final along the way and made some other minor refactorings.
>>
>> Testing: regression test, tier1-2
>>
>> Best regards,
>> Vladimir Ivanov
> 

From paul.sandoz at oracle.com  Tue Nov 19 18:03:09 2019
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 19 Nov 2019 10:03:09 -0800
Subject: [14] RFR (S): 8234401: ConstantCallSite may stuck in non-frozen
 state
In-Reply-To: 
References: 
 
 
Message-ID: 

Much better :-)

I accumulated some more questions while I was looking further.

CallSite:
 public class CallSite {
 
-    // The actual payload of this call site:
+    // The actual payload of this call site.
+    // Can be modified using {@link MethodHandleNatives#setCallSiteTargetNormal} or {@link MethodHandleNatives#setCallSiteTargetVolatile}.
     /*package-private*/
-    MethodHandle target;    // Note: This field is known to the JVM.  Do not change.
+    final MethodHandle target;  // Note: This field is known to the JVM.

Is there any benefit to making target final, even though it's not really for mutable call sites? (With the recent discussion of "final means final" it would be nice to not introduce more special case stomping on final fields if we can avoid it).


     CallSite(MethodType targetType, MethodHandle createTargetHook) throws Throwable {
-        this(targetType);
+        this(targetType); // need to initialize target to make CallSite.type() work in createTargetHook
         ConstantCallSite selfCCS = (ConstantCallSite) this;
         MethodHandle boundTarget = (MethodHandle) createTargetHook.invokeWithArguments(selfCCS);
-        checkTargetChange(this.target, boundTarget);
-        this.target = boundTarget;
+        setTargetNormal(boundTarget); // ConstantCallSite doesn't publish CallSite.target
+        UNSAFE.storeStoreFence(); // barrier between target and isFrozen updates
     }

I wonder if instead of introducing the store store fence here we could move it into ConstantCallSite?

     protected ConstantCallSite(MethodType targetType, MethodHandle createTargetHook) throws Throwable {
-        super(targetType, createTargetHook);
+        super(targetType, createTargetHook); // "this" instance leaks into createTargetHook
+        UNSAFE.storeStoreFence(); // barrier between target and isFrozen updates  On Nov 19, 2019, at 9:49 AM, Vladimir Ivanov  wrote:
> 
> 
>> Subtle, so I could be misunderstanding something, did you intend to remove the assignment of isFrozen in the ConstantCallSite constructor?
> 
> Oh, good catch. It is my fault: the update should be there. (The barriers are added just to preserve final field semantics for isFrozen.)
> 
> Published the wrong version (with some leftovers from last-minute failed experiment). Updated in place.
> 
> Best regards,
> Vladimir Ivanov
> 
>>> On Nov 19, 2019, at 8:53 AM, Vladimir Ivanov  wrote:
>>> 
>>> http://cr.openjdk.java.net/~vlivanov/8234401/webrev.00/
>>> https://bugs.openjdk.java.net/browse/JDK-8234401
>>> 
>>> ConstantCallSite has a ctor which deliberately leaks partially initialized instance into user code. isFrozen is declared final and if user code is obstinate enough, it can end up with non-frozen state embedded into the generated code. It manifests as a ConstantCallSite instance which is stuck in non-frozen state.
>>> 
>>> I switched isFrozen from final to @Stable, so non-frozen state is never constant folded. Put some store-store barriers along the way to restore final field handling.
>>> 
>>> I deliberately stopped there (just restoring isFrozen final field behavior). Without proper synchronization, there's still a theoretical possibility of transiently observing a call site in non-frozen state right after ctor is over. But at least there's no way anymore to accidentally break an instance in such a way it becomes permanently unusable.
>>> 
>>> PS: converted CallSite.target to final along the way and made some other minor refactorings.
>>> 
>>> Testing: regression test, tier1-2
>>> 
>>> Best regards,
>>> Vladimir Ivanov


From brent.christian at oracle.com  Tue Nov 19 18:06:11 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Tue, 19 Nov 2019 10:06:11 -0800
Subject: RFR 8233272 : The Class.forName specification should be updated
 to match the long-standing implementation with respect to class linking
In-Reply-To: 
References: <79528f01-3418-eb51-4dbd-897e4e97f853@oracle.com>
 <7ddee581-c68b-bf40-22db-871205b8ca1b@oracle.com>
 <3d305a6d-fd45-f6e5-93f2-c47250f31985@oracle.com>
 
 <99dded93-17d2-ea40-deef-56efd10218c7@oracle.com>
 
 <1e4cd61f-dddd-b221-f0b4-448e64a4b440@oracle.com>
 <38a77634-e3d7-426a-ae2d-c957804bf8f3@oracle.com>
 
Message-ID: <6a73ae42-2083-0346-6afb-6db73a36612e@oracle.com>

Thank you for the suggestions, Mandy and David.  I've pushed the change.

-Brent


From vladimir.x.ivanov at oracle.com  Tue Nov 19 18:12:37 2019
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Tue, 19 Nov 2019 21:12:37 +0300
Subject: [14] RFR (S): 8234401: ConstantCallSite may stuck in non-frozen
 state
In-Reply-To: 
References: 
 
 
 
Message-ID: 

Thanks, Paul.

> CallSite:
> 
>   public class CallSite {
>   
> - // The actual payload of this call site:
> + // The actual payload of this call site.
> + // Can be modified using {@link 
> MethodHandleNatives#setCallSiteTargetNormal} or {@link 
> MethodHandleNatives#setCallSiteTargetVolatile}.
>       /*package-private*/
> - MethodHandle target; // Note: This field is known to the JVM. Do not 
> change.
> + final MethodHandle target; // Note: This field is known to the JVM.
> 
> 
> Is there any benefit to making target final, even though it's not really 
> for mutable call sites? (With the recent discussion of "final means 
> final" it would be nice to not introduce more special case stomping on 
> final fields if we can avoid it).

CallSite.target is already treated specially: all updates go through 
MethodHandleNatives and JIT-compiler treat it as "final" irrespective of 
the flags.

My main interest in marking it final is to enforce proper initialization 
on JDK side to make it easier to reason about:

 
https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-November/036021.html 


>       CallSite(MethodType targetType, MethodHandle createTargetHook) throws Throwable {
> - this(targetType);
> + this(targetType); // need to initialize target to make CallSite.type() 
> work in createTargetHook
>           ConstantCallSite selfCCS = (ConstantCallSite) this;
>           MethodHandle boundTarget = (MethodHandle) createTargetHook.invokeWithArguments(selfCCS);
> - checkTargetChange(this.target, boundTarget);
> - this.target = boundTarget;
> + setTargetNormal(boundTarget); // ConstantCallSite doesn't publish 
> CallSite.target
> + UNSAFE.storeStoreFence(); // barrier between target and isFrozen updates
>       }
> 
> 
> I wonder if instead of introducing the store store fence here we could 
> move it into ConstantCallSite?

Sure, if you prefer to see it on ConstantCallSite side, we can move it 
there.

By putting it in CallSite near the call site update, I wanted to stress 
there's a CallSite.target update happening on partially published 
instance.

Best regards,
Vladimir Ivanov

> 
>       protected ConstantCallSite(MethodType targetType, MethodHandle createTargetHook) throws Throwable {
> - super(targetType, createTargetHook);
> + super(targetType, createTargetHook); // "this" instance leaks into 
> createTargetHook
> 
> + UNSAFE.storeStoreFence(); // barrier between target and isFrozen 
> updates 
>           isFrozen = true;
> + UNSAFE.storeStoreFence(); // properly publish isFrozen
>       }
>> On Nov 19, 2019, at 9:49 AM, Vladimir Ivanov 
>> > 
>> wrote:
>>
>>
>>> Subtle, so I could be misunderstanding something, did you intend to 
>>> remove the assignment of isFrozen in the ConstantCallSite constructor?
>>
>> Oh, good catch. It is my fault: the update should be there. (The 
>> barriers are added just to preserve final field semantics for isFrozen.)
>>
>> Published the wrong version (with some leftovers from last-minute 
>> failed experiment). Updated in place.
>>
>> Best regards,
>> Vladimir Ivanov
>>
>>>> On Nov 19, 2019, at 8:53 AM, Vladimir Ivanov 
>>>> > 
>>>> wrote:
>>>>
>>>> http://cr.openjdk.java.net/~vlivanov/8234401/webrev.00/
>>>> https://bugs.openjdk.java.net/browse/JDK-8234401
>>>>
>>>> ConstantCallSite has a ctor which deliberately leaks partially 
>>>> initialized instance into user code. isFrozen is declared final and 
>>>> if user code is obstinate enough, it can end up with non-frozen 
>>>> state embedded into the generated code. It manifests as a 
>>>> ConstantCallSite instance which is stuck in non-frozen state.
>>>>
>>>> I switched isFrozen from final to @Stable, so non-frozen state is 
>>>> never constant folded. Put some store-store barriers along the way 
>>>> to restore final field handling.
>>>>
>>>> I deliberately stopped there (just restoring isFrozen final field 
>>>> behavior). Without proper synchronization, there's still a 
>>>> theoretical possibility of transiently observing a call site in 
>>>> non-frozen state right after ctor is over. But at least there's no 
>>>> way anymore to accidentally break an instance in such a way it 
>>>> becomes permanently unusable.
>>>>
>>>> PS: converted CallSite.target to final along the way and made some 
>>>> other minor refactorings.
>>>>
>>>> Testing: regression test, tier1-2
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
> 

From joe.darcy at oracle.com  Tue Nov 19 18:21:29 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 19 Nov 2019 10:21:29 -0800
Subject: JDK14 RFR of JDK-8234381: API docs should mention special handling of
 enums in serialization
Message-ID: <76f0b7f6-2ff1-2c40-0d3e-d2551ff485c2@oracle.com>

Hello,

Please review this small doc changes to more explicitly discuss the 
special handling of enum types by serialization:

 ??? JDK-8234381: API docs should mention special handling of enums in 
serialization
 ??? http://cr.openjdk.java.net/~darcy/8234381.0/

Patch below; thanks,

-Joe

--- old/src/java.base/share/classes/java/io/Serializable.java 2019-11-19 
10:17:45.803443000 -0800
+++ new/src/java.base/share/classes/java/io/Serializable.java 2019-11-19 
10:17:45.399241001 -0800
@@ -134,6 +134,11 @@
 ? * This readResolve method follows the same invocation rules and
 ? * accessibility rules as writeReplace.

 ? *
+ * 
Enum types are all serializable and receive treatment defined by
+ * the Java Object Serialization Specification during
+ * serialization and deserialization. Any declarations of the special
+ * handling methods discussed above are ignored for enum types.
+ *
 ? * The serialization runtime associates with each serializable class a 
version
 ? * number, called a serialVersionUID, which is used during 
deserialization to
 ? * verify that the sender and receiver of a serialized object have loaded
@@ -152,8 +157,9 @@
 ? * If a serializable class does not explicitly declare a 
serialVersionUID, then
 ? * the serialization runtime will calculate a default serialVersionUID 
value
 ? * for that class based on various aspects of the class, as described 
in the
- * Java(TM) Object Serialization Specification.? However, it is 
strongly
- * recommended that all serializable classes explicitly declare
+ * Java Object Serialization Specification.? This specification defines the
+ * serialVersionUID of an enum type to be 0L. However, it is strongly
+ * recommended that all serializable classes other than enum types 
explicitly declare
 ? * serialVersionUID values, since the default serialVersionUID 
computation is
 ? * highly sensitive to class details that may vary depending on compiler
 ? * implementations, and can thus result in unexpected
--- old/src/java.base/share/classes/java/lang/Enum.java 2019-11-19 
10:17:46.807945000 -0800
+++ new/src/java.base/share/classes/java/lang/Enum.java 2019-11-19 
10:17:46.371727000 -0800
@@ -47,6 +47,13 @@
 ? * found in section 8.9 of
 ? * The Java™ Language Specification.
 ? *
+ * Enumeration types are all serializable and receive special handling
+ * by the serialization mechanism. The serialized representation used
+ * for enum constants cannot be customized. Declarations of methods
+ * and fields that would otherwise interact with serialization are
+ * ignored, including {@code serialVersionUID}; see the Java
+ * Object Serialization Specification for details.
+ *
 ? * 
 Note that when using an enumeration type as the type of a set
 ? * or as the type of the keys in a map, specialized and efficient
 ? * {@linkplain java.util.EnumSet set} and {@linkplain


From paul.sandoz at oracle.com  Tue Nov 19 18:25:11 2019
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 19 Nov 2019 10:25:11 -0800
Subject: [14] RFR (S): 8234401: ConstantCallSite may stuck in non-frozen
 state
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

+1

> On Nov 19, 2019, at 10:12 AM, Vladimir Ivanov  wrote:
> 
> Thanks, Paul.
> 
>> CallSite:
>>  public class CallSite {
>>  - // The actual payload of this call site:
>> + // The actual payload of this call site.
>> + // Can be modified using {@link MethodHandleNatives#setCallSiteTargetNormal} or {@link MethodHandleNatives#setCallSiteTargetVolatile}.
>>      /*package-private*/
>> - MethodHandle target; // Note: This field is known to the JVM. Do not change.
>> + final MethodHandle target; // Note: This field is known to the JVM.
>> Is there any benefit to making target final, even though it's not really for mutable call sites? (With the recent discussion of "final means final" it would be nice to not introduce more special case stomping on final fields if we can avoid it).
> 
> CallSite.target is already treated specially: all updates go through MethodHandleNatives and JIT-compiler treat it as "final" irrespective of the flags.
> 
> My main interest in marking it final is to enforce proper initialization on JDK side to make it easier to reason about:
> 
> https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-November/036021.html 
> 

Ok, I see now in light of that context.


>>      CallSite(MethodType targetType, MethodHandle createTargetHook) throws Throwable {
>> - this(targetType);
>> + this(targetType); // need to initialize target to make CallSite.type() work in createTargetHook
>>          ConstantCallSite selfCCS = (ConstantCallSite) this;
>>          MethodHandle boundTarget = (MethodHandle) createTargetHook.invokeWithArguments(selfCCS);
>> - checkTargetChange(this.target, boundTarget);
>> - this.target = boundTarget;
>> + setTargetNormal(boundTarget); // ConstantCallSite doesn't publish CallSite.target
>> + UNSAFE.storeStoreFence(); // barrier between target and isFrozen updates
>>      }
>> I wonder if instead of introducing the store store fence here we could move it into ConstantCallSite?
> 
> Sure, if you prefer to see it on ConstantCallSite side, we can move it there.
> 
> By putting it in CallSite near the call site update, I wanted to stress there's a CallSite.target update happening on partially published instance.
> 

Up to you.

Paul.

From jonathan.gibbons at oracle.com  Tue Nov 19 18:39:09 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 19 Nov 2019 10:39:09 -0800
Subject: JEP 358 (Helpful NPEs) and single source file mode
In-Reply-To: <1619831852.538078.1574152827976.JavaMail.zimbra@u-pem.fr>
References: 
 <1619831852.538078.1574152827976.JavaMail.zimbra@u-pem.fr>
Message-ID: 

It's a design constraint that the "single source file mode" does not and 
should not support javac-specific command-line options beyond those that 
are also runtime options (for example, --class-path).

That being said, since one of the use cases is for beginners learning 
Java, it seems reasonable to support debugging information in that case. 
The other use case is for scripts/shebang files, and the debugging 
information should not be an onerous overhead in that case as well.

Therefore, I'm inclined to agree with the suggestion.

-- Jon

On 11/19/19 12:40 AM, Remi Forax wrote:
> ----- Mail original -----
>> De: "Gunnar Morling" 
>> ?: "core-libs-dev" 
>> Envoy?: Mardi 19 Novembre 2019 09:34:41
>> Objet: JEP 358 (Helpful NPEs) and single source file mode
>> Hi,
>>
>> I've been exploring the new helpful NPE feature a bit.
>>
>> It's a very welcomed improvement, but I noticed one potential usability
>> issue in conjunction with the single source file mode (JEP 330): as debug
>> info is missing in that case, e.g. local variables are rendered as
>> "" in the exception message. Single source file mode also doesn't
>> let me specify the "-g:vars" option I could use with javac for adding the
>> debugging info.
>>
>> Perhaps single source file mode should add debug information by default to
>> prevent this issue?
> yes !
>
>> Thanks,
>>
>> --Gunnar
> R?mi
>

From lance.andersen at oracle.com  Tue Nov 19 18:57:23 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 19 Nov 2019 13:57:23 -0500
Subject: RFR: 8234089: (zipfs) Remove classes JarFileSystemProvider and
 JarFileSystem
In-Reply-To: 
References: 
 <3532D7A1-DF2F-41BF-80BF-09EF53B022B6@oracle.com>
 
 
Message-ID: <8C407967-F743-4070-B714-52E2056B5E32@oracle.com>

Hi Christoph,

Something else that should probably be done as part of this proposed change is  to clean up tests such as NodeCostDumpUtil.java and ModulesInCustomFileSystem.java and a few others as they have methods/fields etc... that make reference to the  Jar File System.  While it does not impact the tests as they are currently written, I think it would make sense to do this for clarity with the change you are making.

Best
Lance
> On Nov 18, 2019, at 12:53 PM, Lance Andersen  wrote:
> 
> Hi Christoph,
> 
> Sorry for the late reply but I was out of the office Friday
>> On Nov 15, 2019, at 3:40 AM, Langer, Christoph > wrote:
>> 
>> Hi Lance,
>> 
>> thanks for reviewing. I've addressed your points:
>> 
>>> I would suggesting moving the code added to the constructor for checking
>>> the releaseVersion/multi-release properties to a method and grouping it
>>> with the other methods added for supporting MR jars around line 1396.
>>> (keeps it easier to follow and maintain)
>> 
>> Done that.
> 
> Thank you.  I do think however we need to change the name of the method to perhaps ?checkReleaseVersionProperty? as the current name ?initializeMultiReleaseJar?  does not seem quite right to me.
> 
> I would also update the comment for the method to something like:
> 
> ----------------
> Checks to see if the Zip File System property  ?releaseVersion? has been specified.  If it has not been specified then check for the existence of the ?multi-release? property.   If set and the file represents a multi-release JAR, determine the runtime version to use.
> ----------------
> 
>> 
>>> Could you also add a comment above the isMultiReleaseJar method to for
>>> clarity going forward (I know there was not one there before)
>> 
>> Done, too.
> 
> Thank you.
> 
> I think we can tweak the comment slightly to something like
> 
> ???????
> Returns true if the Manifest main attribute ?Multi-Release? is set to true; false otherwise
> --------------------
>> 
>>> I might change the name of the lookup field in the method makeParentDirs
>>> with the addition of the Function lookup on line 126.
>> 
>> I chose to change the name of the global field in line 126 to be named mrlookup. Also updated the comment.
> 
> I am not sure ?mrlookup? is the best name as this field is used with or without a multi-release jar.  Perhaps ?IndexNodeNameLookup? or
> ?entryLookup"
>> 
>> This is the new webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234089.2/ 
>> 
>> Cheers
>> Christoph
> 
> Thank you again!
> 
> 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 
 
  
 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 john.r.rose at oracle.com  Tue Nov 19 19:17:22 2019
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 19 Nov 2019 11:17:22 -0800
Subject: RFR: 8234335: Remove line break in class declaration in java.base
In-Reply-To: 
References: <7ed7ea03-be6f-2974-847d-c3c0364e9d9d@oracle.com>
 <84601299-2199-9a16-1923-ffeb92a527a1@oracle.com>
 <1ABE9DB3-E8FB-4C09-B54B-B3A73F457152@oracle.com>
 
 
Message-ID: <96EEAF0B-B1B8-4533-A826-00F8DB928C8F@oracle.com>

On Nov 19, 2019, at 4:00 AM, Lance Andersen  wrote:
> 
> Seems to be a ?your milage varies?.  I am fine with whatever the final decision is.  However, I do believe the comment above reads better and aligns the methods better.

FWIW, and as author of many of the lines being changed, I prefer that comment on a separate from the actual modifiers.  I think the basic modifier patterns are easier to recognize quickly when comments and annotations are separate.

? John

P.S. And for the record, my intention of writing non-public is to ensure make it clear to maintainers that the absence of any modifier is both intentional and important (to security, in most cases).  The language doesn?t give any more explicit way to document that default access is required.


From brent.christian at oracle.com  Tue Nov 19 19:25:54 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Tue, 19 Nov 2019 11:25:54 -0800
Subject: RFR: JDK-8233117 Escape Sequences For Line Continuation and White
 Space (Preview)
In-Reply-To: 
References: <0EEF3461-D8A4-496B-87DE-F143CB0FB995@oracle.com>
 <414cb097-9616-f4b0-8a3d-462a9ccfbdea@oracle.com>
 
 <00C5C729-D9FF-48E0-8F7F-DD8E7615ACEC@oracle.com>
 <818dcc2d-2d4a-57c7-a4e0-c1c873999c2a@oracle.com>
 
Message-ID: <0218bbf8-0f0f-6727-91dc-d06184d1b261@oracle.com>

On 11/18/19 6:26 AM, Jim Laskey wrote:
> 
> http://cr.openjdk.java.net/~jlaskey/8233116/webrev.04/index.html
> 

OK, thanks.

The changes in:
   src/java.base/share/classes/java/lang/String.java
   test/jdk/java/lang/String/TranslateEscapes.java
look fine.

-Brent

From kevin.rushforth at oracle.com  Tue Nov 19 20:13:13 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 19 Nov 2019 12:13:13 -0800
Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
In-Reply-To: 
References: 
Message-ID: <35372d0e-910a-d8c1-6bf4-88fcb140daee@oracle.com>

I took the "git diff" patch [5] that you uploaded yesterday, applied it, 
and verified that it is the same as what is in the JDK-8200758-branch 
branch of the sandbox. It builds and runs fine for me.

I ran jcheck and it found the following three files with whitespace 
errors that will need to be fixed before you push:

src/jdk.incubator.jpackage/linux/classes/jdk/incubator/jpackage/internal/PackageProperty.java:49: 
Trailing whitespace
src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/ToolProviderFactory.java:35: 
Trailing whitespace
test/jdk/tools/jpackage/share/AddLauncherBase.java:137: Trailing whitespace

The second of these will go away with the fix for JDK-8234402 [6], so 
you don't need to do anything there. Once the fix for JDK-8234402 is 
pushed to sandbox, I presume you will update the webrev, right?

Pending the fix for JDK-8234402 and the needed white-space fixes, this 
is a +1 from me (although I am not a jdk Project Reviewer, so you will 
need at least one review from someone who is).

-- Kevin

[5] http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-10.git.patch
[6] https://bugs.openjdk.java.net/browse/JDK-8234402


On 11/13/2019 4:23 PM, Andy Herrick wrote:
> Please review? changes for [1] which is the implementation bug for 
> JEP-343.
>
> The webrev at [2] is the total cumulative webrev of changes for the 
> jpackage tool, currently in the JDK-8200758-branch branch of the open 
> sandbox repository.
>
> The webrev at [3] shows the changes since EA-06 (Build 
> 13-jpackage+1-49 ) up to the current point.
>
> The latest EA (Build 14-jpackage+1-49 ) is posted at [4].
>
> Please send feedback to core-libs-dev at openjdk.java.net
>
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8212780
>
> [2] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-10/
>
> [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-10/
>
> [4] http://jdk.java.net/jpackage/
>


From david.lloyd at redhat.com  Tue Nov 19 20:22:19 2019
From: david.lloyd at redhat.com (David Lloyd)
Date: Tue, 19 Nov 2019 14:22:19 -0600
Subject: Class-Path (in jar file) semantics different between Java 11 and
 13 (on Windows)?
In-Reply-To: <2bac906c-8489-5611-6865-085fc389e5ea@oracle.com>
References: 
 <2bac906c-8489-5611-6865-085fc389e5ea@oracle.com>
Message-ID: 

On Mon, Nov 18, 2019 at 9:37 AM Alan Bateman  wrote:
>
> On 18/11/2019 15:01, Jaikiran Pai wrote:
> > :
> >
> > So this Class-Path entry is being ignored starting Java 13.
> >
> Yes, bad values are now ignored, bringing an end to an effort on the
> run-time over multiple releases to fix the problems this area.
> JDK-8224253[1] is the JDK 13 release note to announce this change and I
> see you've found the system property that you can use to track down bad
> values. In previous releases you will get the same behavior with
> -Djdk.net.URLClassPath.disableClassPathURLCheck=false as the changes to
> reject bad input have been in place for some time. Brent can summarize
> but I think the only outstanding work is to fix the javac handling.
>
> -Alan
> [1] https://bugs.openjdk.java.net/browse/JDK-8224253

Where can the updated specification be found?  It has in the past been
clearly specified and well understood that class path entries are
interpreted as relative URLs.  If that has changed then this will
definitely break Quarkus and perhaps other applications as well.

A Google search for "JAR file specification" only seems to turn up
older versions (JDK 10 and earlier).
-- 
- DML


From lance.andersen at oracle.com  Tue Nov 19 20:34:45 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 19 Nov 2019 15:34:45 -0500
Subject: Class-Path (in jar file) semantics different between Java 11 and
 13 (on Windows)?
In-Reply-To: 
References: 
 <2bac906c-8489-5611-6865-085fc389e5ea@oracle.com>
 
Message-ID: 


> On Nov 19, 2019, at 3:22 PM, David Lloyd  wrote:
> 
> On Mon, Nov 18, 2019 at 9:37 AM Alan Bateman  wrote:
>> 
>> On 18/11/2019 15:01, Jaikiran Pai wrote:
>>> :
>>> 
>>> So this Class-Path entry is being ignored starting Java 13.
>>> 
>> Yes, bad values are now ignored, bringing an end to an effort on the
>> run-time over multiple releases to fix the problems this area.
>> JDK-8224253[1] is the JDK 13 release note to announce this change and I
>> see you've found the system property that you can use to track down bad
>> values. In previous releases you will get the same behavior with
>> -Djdk.net.URLClassPath.disableClassPathURLCheck=false as the changes to
>> reject bad input have been in place for some time. Brent can summarize
>> but I think the only outstanding work is to fix the javac handling.
>> 
>> -Alan
>> [1] https://bugs.openjdk.java.net/browse/JDK-8224253
> 
> Where can the updated specification be found?  It has in the past been
> clearly specified and well understood that class path entries are
> interpreted as relative URLs.  If that has changed then this will
> definitely break Quarkus and perhaps other applications as well.
> 
> A Google search for "JAR file specification" only seems to turn up
> older versions (JDK 10 and earlier).

https://docs.oracle.com/en/java/javase/13/docs/specs/jar/jar.html

> -- 
> - DML
> 

 
  
 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com 




From Alan.Bateman at oracle.com  Tue Nov 19 20:48:48 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 19 Nov 2019 20:48:48 +0000
Subject: Class-Path (in jar file) semantics different between Java 11 and
 13 (on Windows)?
In-Reply-To: 
References: 
 <2bac906c-8489-5611-6865-085fc389e5ea@oracle.com>
 
Message-ID: 

On 19/11/2019 20:22, David Lloyd wrote:
> :
> Where can the updated specification be found?  It has in the past been
> clearly specified and well understood that class path entries are
> interpreted as relative URLs.  If that has changed then this will
> definitely break Quarkus and perhaps other applications as well.
>
> A Google search for "JAR file specification" only seems to turn up
> older versions (JDK 10 and earlier).
One way to quickly get to it is type "java.util.jar" into the javadoc 
search box and it is linked from the package description. So for the JDK 
13 published on jdk.java.net it is:
https://docs.oracle.com/en/java/javase/13/docs/specs/jar/jar.html#class-path-attribute

The value is a relative URL, same as always, it's just that the 
implementation is less tolerant of bad input. The stricter checking has 
been in place for a few releases, controlled by the system property 
mentioned in the discussion here.

It's always hard to dial up checking after the fact and one of the main 
challenges has been mis-uses where tools have been putting file paths 
(rather than URL) or absolute URLs into the value. This is the reason 
why the spec now allows absolute file URLs (need to specify the "file:" 
scheme).

-Alan

From christoph.langer at sap.com  Tue Nov 19 21:03:21 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 19 Nov 2019 21:03:21 +0000
Subject: RFR: 8234089: (zipfs) Remove classes JarFileSystemProvider and
 JarFileSystem
In-Reply-To: <8C407967-F743-4070-B714-52E2056B5E32@oracle.com>
References: 
 <3532D7A1-DF2F-41BF-80BF-09EF53B022B6@oracle.com>
 
 
 <8C407967-F743-4070-B714-52E2056B5E32@oracle.com>
Message-ID: 

Hi Lance,

I?m actually not so sure about this. While my cleanup change would remove the implementation detail of zipfs to use a class named ?JarFileSystem? for multi-release jar peculiarities, I think a user of a FileSystem object upon a jar file is not wrong if he names the variable like jarFileSystem or the like. So I don?t see that such cleanup is really worth the while. Would you be ok with that?

I?ll get back to you soon with an updated webrev regarding the other changes you suggested.

Best regards
Christoph

From: Lance Andersen 
Sent: Dienstag, 19. November 2019 19:57
To: Langer, Christoph 
Cc: core-libs-dev at openjdk.java.net; nio-dev 
Subject: Re: RFR: 8234089: (zipfs) Remove classes JarFileSystemProvider and JarFileSystem

Hi Christoph,

Something else that should probably be done as part of this proposed change is  to clean up tests such as NodeCostDumpUtil.java and ModulesInCustomFileSystem.java and a few others as they have methods/fields etc... that make reference to the  Jar File System.  While it does not impact the tests as they are currently written, I think it would make sense to do this for clarity with the change you are making.

Best
Lance
On Nov 18, 2019, at 12:53 PM, Lance Andersen > wrote:

Hi Christoph,

Sorry for the late reply but I was out of the office Friday
On Nov 15, 2019, at 3:40 AM, Langer, Christoph > wrote:

Hi Lance,

thanks for reviewing. I've addressed your points:


I would suggesting moving the code added to the constructor for checking
the releaseVersion/multi-release properties to a method and grouping it
with the other methods added for supporting MR jars around line 1396.
(keeps it easier to follow and maintain)

Done that.

Thank you.  I do think however we need to change the name of the method to perhaps ?checkReleaseVersionProperty? as the current name ?initializeMultiReleaseJar?  does not seem quite right to me.

I would also update the comment for the method to something like:

----------------
Checks to see if the Zip File System property  ?releaseVersion? has been specified.  If it has not been specified then check for the existence of the ?multi-release? property.   If set and the file represents a multi-release JAR, determine the runtime version to use.
----------------



Could you also add a comment above the isMultiReleaseJar method to for
clarity going forward (I know there was not one there before)

Done, too.

Thank you.

I think we can tweak the comment slightly to something like

???????
Returns true if the Manifest main attribute ?Multi-Release? is set to true; false otherwise
--------------------



I might change the name of the lookup field in the method makeParentDirs
with the addition of the Function lookup on line 126.

I chose to change the name of the global field in line 126 to be named mrlookup. Also updated the comment.

I am not sure ?mrlookup? is the best name as this field is used with or without a multi-release jar.  Perhaps ?IndexNodeNameLookup? or
?entryLookup"


This is the new webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234089.2/

Cheers
Christoph

Thank you again!

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

[cid:image001.gif at 01D59F25.2712D690]

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 Nov 19 21:16:49 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 19 Nov 2019 16:16:49 -0500
Subject: RFR: 8234089: (zipfs) Remove classes JarFileSystemProvider and
 JarFileSystem
In-Reply-To: 
References: 
 <3532D7A1-DF2F-41BF-80BF-09EF53B022B6@oracle.com>
 
 
 <8C407967-F743-4070-B714-52E2056B5E32@oracle.com>
 
Message-ID: 

Hi Christoph,

If you look at MultiReleaseJarTest.java, it explicitly references JAR FS in a comment. Same for JFSTester.java in the @Summary.  These should definitely be updated.  There are comments in ModulesInCustomFileSystem.java as well.

As far as variable names, I think this is nice to clean up but less important as part of this update.

The good news is it is not a big set of changes for the comments so I would address those at a minimum.

Best
Lance

> On Nov 19, 2019, at 4:03 PM, Langer, Christoph  wrote:
> 
> Hi Lance,
>  
> I?m actually not so sure about this. While my cleanup change would remove the implementation detail of zipfs to use a class named ?JarFileSystem? for multi-release jar peculiarities, I think a user of a FileSystem object upon a jar file is not wrong if he names the variable like jarFileSystem or the like. So I don?t see that such cleanup is really worth the while. Would you be ok with that?
>  
> I?ll get back to you soon with an updated webrev regarding the other changes you suggested.
>  
> Best regards
> Christoph
>  
> From: Lance Andersen > 
> Sent: Dienstag, 19. November 2019 19:57
> To: Langer, Christoph >
> Cc: core-libs-dev at openjdk.java.net ; nio-dev >
> Subject: Re: RFR: 8234089: (zipfs) Remove classes JarFileSystemProvider and JarFileSystem
>  
> Hi Christoph,
>  
> Something else that should probably be done as part of this proposed change is  to clean up tests such as NodeCostDumpUtil.java and ModulesInCustomFileSystem.java and a few others as they have methods/fields etc... that make reference to the  Jar File System.  While it does not impact the tests as they are currently written, I think it would make sense to do this for clarity with the change you are making.
>  
> Best
> Lance
> On Nov 18, 2019, at 12:53 PM, Lance Andersen > wrote:
>  
> Hi Christoph,
>  
> Sorry for the late reply but I was out of the office Friday
> On Nov 15, 2019, at 3:40 AM, Langer, Christoph > wrote:
>  
> Hi Lance,
> 
> thanks for reviewing. I've addressed your points:
> 
> 
> I would suggesting moving the code added to the constructor for checking
> the releaseVersion/multi-release properties to a method and grouping it
> with the other methods added for supporting MR jars around line 1396.
> (keeps it easier to follow and maintain)
> 
> Done that.
>  
> Thank you.  I do think however we need to change the name of the method to perhaps ?checkReleaseVersionProperty? as the current name ?initializeMultiReleaseJar?  does not seem quite right to me.
>  
> I would also update the comment for the method to something like:
>  
> ----------------
> Checks to see if the Zip File System property  ?releaseVersion? has been specified.  If it has not been specified then check for the existence of the ?multi-release? property.   If set and the file represents a multi-release JAR, determine the runtime version to use.
> ----------------
>  
> 
> 
> Could you also add a comment above the isMultiReleaseJar method to for
> clarity going forward (I know there was not one there before)
> 
> Done, too.
>  
> Thank you.
>  
> I think we can tweak the comment slightly to something like
>  
> ???????
> Returns true if the Manifest main attribute ?Multi-Release? is set to true; false otherwise
> --------------------
> 
> 
> 
> I might change the name of the lookup field in the method makeParentDirs
> with the addition of the Function lookup on line 126.
> 
> I chose to change the name of the global field in line 126 to be named mrlookup. Also updated the comment.
>  
> I am not sure ?mrlookup? is the best name as this field is used with or without a multi-release jar.  Perhaps ?IndexNodeNameLookup? or
> ?entryLookup"
> 
> 
> This is the new webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234089.2/ 
> 
> Cheers
> Christoph
>  
> Thank you again!
>  
> 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 
>  
>  
> 
>  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 mark.reinhold at oracle.com  Tue Nov 19 21:48:34 2019
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 19 Nov 2019 13:48:34 -0800
Subject: RFR: 8234335: Remove line break in class declaration in java.base
In-Reply-To: <96EEAF0B-B1B8-4533-A826-00F8DB928C8F@oracle.com>
References: <7ed7ea03-be6f-2974-847d-c3c0364e9d9d@oracle.com>
 <84601299-2199-9a16-1923-ffeb92a527a1@oracle.com>
 <1ABE9DB3-E8FB-4C09-B54B-B3A73F457152@oracle.com>
 
 
 <96EEAF0B-B1B8-4533-A826-00F8DB928C8F@oracle.com>
Message-ID: <20191119134834.473503079@eggemoggin.niobe.net>

2019/11/19 11:17:22 -0800, john.r.rose at oracle.com:
> On Nov 19, 2019, at 4:00 AM, Lance Andersen  wrote:
>> Seems to be a ?your milage varies?.  I am fine with whatever the
>> final decision is.  However, I do believe the comment above reads
>> better and aligns the methods better.
> 
> FWIW, and as author of many of the lines being changed, I prefer that
> comment on a separate from the actual modifiers.  I think the basic
> modifier patterns are easier to recognize quickly when comments and
> annotations are separate.

Personally I prefer to place such pseudo-modifiers on the same line
as the actual modifiers, but I accept that some prefer otherwise.

When in doubt, respect the original author?s choice.

- Mark

From Roger.Riggs at oracle.com  Tue Nov 19 22:30:50 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 19 Nov 2019 17:30:50 -0500
Subject: JDK14 RFR of JDK-8234381: API docs should mention special
 handling of enums in serialization
In-Reply-To: <76f0b7f6-2ff1-2c40-0d3e-d2551ff485c2@oracle.com>
References: <76f0b7f6-2ff1-2c40-0d3e-d2551ff485c2@oracle.com>
Message-ID: <47af70e0-ed10-8775-e138-981977b259b1@oracle.com>

Hi Joe,

The clarification looks fine to me.

Roger


On 11/19/19 1:21 PM, Joe Darcy wrote:
> Hello,
>
> Please review this small doc changes to more explicitly discuss the 
> special handling of enum types by serialization:
>
> ??? JDK-8234381: API docs should mention special handling of enums in 
> serialization
> ??? http://cr.openjdk.java.net/~darcy/8234381.0/
>
> Patch below; thanks,
>
> -Joe
>
> --- old/src/java.base/share/classes/java/io/Serializable.java 
> 2019-11-19 10:17:45.803443000 -0800
> +++ new/src/java.base/share/classes/java/io/Serializable.java 
> 2019-11-19 10:17:45.399241001 -0800
> @@ -134,6 +134,11 @@
> ? * This readResolve method follows the same invocation rules and
> ? * accessibility rules as writeReplace.

> ? *
> + * 
Enum types are all serializable and receive treatment defined by
> + * the Java Object Serialization Specification during
> + * serialization and deserialization. Any declarations of the special
> + * handling methods discussed above are ignored for enum types.
> + *
> ? * The serialization runtime associates with each serializable class 
> a version
> ? * number, called a serialVersionUID, which is used during 
> deserialization to
> ? * verify that the sender and receiver of a serialized object have 
> loaded
> @@ -152,8 +157,9 @@
> ? * If a serializable class does not explicitly declare a 
> serialVersionUID, then
> ? * the serialization runtime will calculate a default 
> serialVersionUID value
> ? * for that class based on various aspects of the class, as described 
> in the
> - * Java(TM) Object Serialization Specification.? However, it is 
> strongly
> - * recommended that all serializable classes explicitly declare
> + * Java Object Serialization Specification.? This specification 
> defines the
> + * serialVersionUID of an enum type to be 0L. However, it is 
> strongly
> + * recommended that all serializable classes other than enum 
> types explicitly declare
> ? * serialVersionUID values, since the default serialVersionUID 
> computation is
> ? * highly sensitive to class details that may vary depending on compiler
> ? * implementations, and can thus result in unexpected
> --- old/src/java.base/share/classes/java/lang/Enum.java 2019-11-19 
> 10:17:46.807945000 -0800
> +++ new/src/java.base/share/classes/java/lang/Enum.java 2019-11-19 
> 10:17:46.371727000 -0800
> @@ -47,6 +47,13 @@
> ? * found in section 8.9 of
> ? * The Java™ Language Specification.
> ? *
> + * Enumeration types are all serializable and receive special handling
> + * by the serialization mechanism. The serialized representation used
> + * for enum constants cannot be customized. Declarations of methods
> + * and fields that would otherwise interact with serialization are
> + * ignored, including {@code serialVersionUID}; see the Java
> + * Object Serialization Specification for details.
> + *
> ? * 
 Note that when using an enumeration type as the type of a set
> ? * or as the type of the keys in a map, specialized and efficient
> ? * {@linkplain java.util.EnumSet set} and {@linkplain
>


From christoph.langer at sap.com  Tue Nov 19 22:37:29 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 19 Nov 2019 22:37:29 +0000
Subject: RFR: 8234089: (zipfs) Remove classes JarFileSystemProvider and
 JarFileSystem
In-Reply-To: 
References: 
 <3532D7A1-DF2F-41BF-80BF-09EF53B022B6@oracle.com>
 
 
 <8C407967-F743-4070-B714-52E2056B5E32@oracle.com>
 
 
Message-ID: 

Hi Lance,

> If you look at MultiReleaseJarTest.java, it explicitly references JAR FS in a
> comment. Same for JFSTester.java in the @Summary. ?These should
> definitely be updated. ?There are comments
> in?ModulesInCustomFileSystem.java as well.

Ok, agreed for MultiReleaseJarTest and JFSTester. I fixed the comments in there. In ModulesInCustomFileSystem I can't see comments that explicitly refer to JarFileSystem.

> I would suggesting moving the code added to the constructor for checking
> the releaseVersion/multi-release properties to a method and grouping it
> with the other methods added for supporting MR jars around line 1396.
> (keeps it easier to follow and maintain)
> 
> Done that.
> 
> Thank you. ?I do think however we need to change the name of the method
> to perhaps ?checkReleaseVersionProperty? as the current name
> ?initializeMultiReleaseJar? ?does not seem quite right to me.

Ok, I changed it to " initializeReleaseVersion". I didn't follow your suggestion because the method not only checks the release version property but also triggers some initialization if a version property is found and it's an mr-jar.

> I would also update the comment for the method to something like:
> 
> ----------------
> Checks to see if the Zip File System property ??releaseVersion? has been
> specified. ?If it has not been specified then check for the existence of the
> ?multi-release? property. ? If set and the file represents a multi-release JAR,
> determine the runtime version to use.
> ----------------

I updated the comment, trying to incorporate your suggestion. How do you like it?

> Could you also add a comment above the isMultiReleaseJar method to for
> clarity going forward (I know there was not one there before)
> 
> Done, too.
> 
> Thank you.
> 
> I think we can tweak the comment slightly to something like
> 
> ???????
> Returns true if the Manifest main attribute ?Multi-Release? is set to true;
> false otherwise
> --------------------

Done.

> I might change the name of the lookup field in the method makeParentDirs
> with the addition of the Function lookup on line 126.
> 
> I chose to change the name of the global field in line 126 to be named
> mrlookup. Also updated the comment.
> 
> I am not sure ?mrlookup? is the best name as this field is used with or
> without a multi-release jar. ?Perhaps ?IndexNodeNameLookup? or
> ?entryLookup"

Ok, entryLookup seems the best fit to me. Changed that.

http://cr.openjdk.java.net/~clanger/webrevs/8234089.3/

Thanks again for reviewing.

Cheers
Christoph


From lance.andersen at oracle.com  Tue Nov 19 22:41:38 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 19 Nov 2019 17:41:38 -0500
Subject: RFR: 8234089: (zipfs) Remove classes JarFileSystemProvider and
 JarFileSystem
In-Reply-To: 
References: 
 <3532D7A1-DF2F-41BF-80BF-09EF53B022B6@oracle.com>
 
 
 <8C407967-F743-4070-B714-52E2056B5E32@oracle.com>
 
 
 
Message-ID: 

Hi Christoph,

Thank you for the follow up.
> On Nov 19, 2019, at 5:37 PM, Langer, Christoph  wrote:
> 
> ModulesInCustomFileSystem

At line 71:

?????
    /**
     * Test exploded modules in a JAR file system.
     */
???????

I will look at the rest of the changes tomorrow

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 david.lloyd at redhat.com  Tue Nov 19 23:25:59 2019
From: david.lloyd at redhat.com (David Lloyd)
Date: Tue, 19 Nov 2019 17:25:59 -0600
Subject: Class-Path (in jar file) semantics different between Java 11 and
 13 (on Windows)?
In-Reply-To: <2bac906c-8489-5611-6865-085fc389e5ea@oracle.com>
References: 
 <2bac906c-8489-5611-6865-085fc389e5ea@oracle.com>
Message-ID: 

On Mon, Nov 18, 2019 at 9:37 AM Alan Bateman  wrote:
>
> On 18/11/2019 15:01, Jaikiran Pai wrote:
> > :
> >
> > So this Class-Path entry is being ignored starting Java 13.
> >
> Yes, bad values are now ignored, bringing an end to an effort on the
> run-time over multiple releases to fix the problems this area.
> JDK-8224253[1] is the JDK 13 release note to announce this change and I
> see you've found the system property that you can use to track down bad
> values. In previous releases you will get the same behavior with
> -Djdk.net.URLClassPath.disableClassPathURLCheck=false as the changes to
> reject bad input have been in place for some time. Brent can summarize
> but I think the only outstanding work is to fix the javac handling.

OK, having read the updated specification (thanks Alan!) I'm now quite
curious why `/C:/helloworld.jar` is considered invalid.  It is in fact
a valid relative URL (colons are allowed in path segments, and the
leading `/` unambiguously delineates the URL path), and thus it seems
that it should be considered valid.

Examining the code in URLClassPath:

static URL tryResolveFile(URL base, String input) throws MalformedURLException {
    int index = input.indexOf(':'); // <-- A
    boolean isFile;
    if (index >= 0) {
        String scheme = input.substring(0, index);
        isFile = "file".equalsIgnoreCase(scheme);
    } else {
        isFile = true;
    }
    return (isFile) ? new URL(base, input) : null;
}

The line marked as `A` seems to incorrectly detect URL scheme.  If a
`/` appears before the `:` then the `:` is legitimately part of the
path, not a scheme delimiter, however this code does not check to see
if the `:` appears after a `/`.
-- 
- DML


From brent.christian at oracle.com  Tue Nov 19 23:31:58 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Tue, 19 Nov 2019 15:31:58 -0800
Subject: Class-Path (in jar file) semantics different between Java 11 and
 13 (on Windows)?
In-Reply-To: <2bac906c-8489-5611-6865-085fc389e5ea@oracle.com>
References: 
 <2bac906c-8489-5611-6865-085fc389e5ea@oracle.com>
Message-ID: <43876285-f127-877a-2dea-dff0c104b259@oracle.com>

On 11/18/19 7:36 AM, Alan Bateman wrote:
 >
> Yes, bad values are now ignored, bringing an end to an effort on the 
> run-time over multiple releases to fix the problems this area. 
> JDK-8224253[1] is the JDK 13 release note to announce this change and I 
> see you've found the system property that you can use to track down bad 
> values. In previous releases you will get the same behavior with 
> -Djdk.net.URLClassPath.disableClassPathURLCheck=false as the changes to 
> reject bad input have been in place for some time.

Right, the "jdk.net.URLClassPath.disableClassPathURLCheck" system 
property can be used to once again allow bad values (though I believe it 
must be set to "true").

> Brent can summarize 
> but I think the only outstanding work is to fix the javac handling.

That's a good summary. :)  It's the only planned change I'm aware of.

It should be expected, however, that the disableClassPathURLCheck system 
property will be removed in a future release.

-Brent

From andy.herrick at oracle.com  Wed Nov 20 00:00:45 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Tue, 19 Nov 2019 19:00:45 -0500
Subject: RFR: JDK-8234402: revert change that stopped providing
 JPackageToolProvider
Message-ID: <99cb8aad-239d-f4b7-54a3-27c7e955607e@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 change restores JPackageToolProvider and gets rid of the temporary 
factory class.

[1] https://bugs.openjdk.java.net/browse/JDK-8234402

[2] http://cr.openjdk.java.net/~herrick/8234402/webrev.02/

/Andy


From alexander.matveev at oracle.com  Wed Nov 20 00:38:01 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Tue, 19 Nov 2019 16:38:01 -0800
Subject: RFR: JDK-8234402: revert change that stopped providing
 JPackageToolProvider
In-Reply-To: <99cb8aad-239d-f4b7-54a3-27c7e955607e@oracle.com>
References: <99cb8aad-239d-f4b7-54a3-27c7e955607e@oracle.com>
Message-ID: <2c596333-c2ce-9f1b-9209-b88edfc67478@oracle.com>

Looks good.

On 11/19/19 4:00 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 change restores JPackageToolProvider and gets rid of the 
> temporary factory class.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8234402
>
> [2] http://cr.openjdk.java.net/~herrick/8234402/webrev.02/
>
> /Andy
>


From alexey.semenyuk at oracle.com  Wed Nov 20 02:00:29 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Tue, 19 Nov 2019 21:00:29 -0500
Subject: RFR: JDK-8234402: revert change that stopped providing
 JPackageToolProvider
In-Reply-To: <99cb8aad-239d-f4b7-54a3-27c7e955607e@oracle.com>
References: <99cb8aad-239d-f4b7-54a3-27c7e955607e@oracle.com>
Message-ID: 

Andy,

I guess 
http://cr.openjdk.java.net/~herrick/8234402/webrev.02/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JavaTool.java.sdiff.html 
can be reverted to its initial state now:
---
public ToolProvider asToolProvider() {
 ??? return ToolProvider.findFirst(name).orElse(null);
}
---

- Alexey

On 11/19/2019 7:00 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 change restores JPackageToolProvider and gets rid of the 
> temporary factory class.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8234402
>
> [2] http://cr.openjdk.java.net/~herrick/8234402/webrev.02/
>
> /Andy
>


From kevin.rushforth at oracle.com  Wed Nov 20 02:05:18 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 19 Nov 2019 18:05:18 -0800
Subject: RFR: JDK-8234402: revert change that stopped providing
 JPackageToolProvider
In-Reply-To: 
References: <99cb8aad-239d-f4b7-54a3-27c7e955607e@oracle.com>
 
Message-ID: <67b7e99c-fd18-9305-a770-ec17cd0c2cce@oracle.com>

Good point. Looks good to me once this is fixed.

-- Kevin


On 11/19/2019 6:00 PM, Alexey Semenyuk wrote:
> Andy,
>
> I guess 
> http://cr.openjdk.java.net/~herrick/8234402/webrev.02/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JavaTool.java.sdiff.html 
> can be reverted to its initial state now:
> ---
> public ToolProvider asToolProvider() {
> ??? return ToolProvider.findFirst(name).orElse(null);
> }
> ---
>
> - Alexey
>
> On 11/19/2019 7:00 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 change restores JPackageToolProvider and gets rid of the 
>> temporary factory class.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8234402
>>
>> [2] http://cr.openjdk.java.net/~herrick/8234402/webrev.02/
>>
>> /Andy
>>
>


From serguei.spitsyn at oracle.com  Wed Nov 20 02:20:32 2019
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Tue, 19 Nov 2019 18:20:32 -0800
Subject: RFR: 8234185: Cleanup usage of canonicalize function between
 libjava, hotspot and libinstrument
In-Reply-To: 
References: 
Message-ID: 

Hi Christoph,

The fix looks good to me.
I'd recommend to run the jdk_instrument and vmTestbase_nsk_jvmti tests.
Also, it can be safe to run:
 ? open/test/hotspot/jtreg/serviceability/jvmti
 ? open/test/hotspot/jtreg/runtime/cds/appcds
 ? open/test/hotspot/jtreg/runtime/BootClassAppendProp

Thanks,
Serguei

On 11/14/19 07:37, Langer, Christoph wrote:
> Hi,
>
> please review this cleanup change regarding function "canonicalize" of libjava.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8234185
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234185.0/
>
>
> The goal is to cleanup how this function is defined and used. One thing is, that there was an unnecessary wrapper function "Canonicalize" in jni_util.c. It wrapped the call to "canonicalize". We can get rid of this wrapper. Unfortunately, it is not possible to just export "canonicalize" since this will conflict with a method signature from the math library, at least on modern Linuxes. So I decided to call the method JDK_Canonicalize and will correctly define it in jdk_util.h which can be included everywhere.
>
>
>
> Hotspot's classloader.cpp will dynamically resolve this method, so I add a local declaration of the function pointer in there.
>
>
>
> This change shall be predecessor of JDK-8223261, where a review was already started here: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-November/063398.html
>
> Thanks
> Christoph
>


From christoph.langer at sap.com  Wed Nov 20 07:47:36 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 20 Nov 2019 07:47:36 +0000
Subject: RFR: 8234185: Cleanup usage of canonicalize function between
 libjava, hotspot and libinstrument
In-Reply-To: 
References: 
 
Message-ID: 

Hi Serguei,

thanks for the review.

The patch successfully ran through our nightly test system which covers all these tests on several platforms.

Best regards
Christoph

> -----Original Message-----
> From: serguei.spitsyn at oracle.com 
> Sent: Mittwoch, 20. November 2019 03:21
> To: Langer, Christoph ; core-libs-
> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; gerard
> ziemski 
> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function between
> libjava, hotspot and libinstrument
> 
> Hi Christoph,
> 
> The fix looks good to me.
> I'd recommend to run the jdk_instrument and vmTestbase_nsk_jvmti tests.
> Also, it can be safe to run:
>  ? open/test/hotspot/jtreg/serviceability/jvmti
>  ? open/test/hotspot/jtreg/runtime/cds/appcds
>  ? open/test/hotspot/jtreg/runtime/BootClassAppendProp
> 
> Thanks,
> Serguei
> 
> On 11/14/19 07:37, Langer, Christoph wrote:
> > Hi,
> >
> > please review this cleanup change regarding function "canonicalize" of
> libjava.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8234185
> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234185.0/
> >
> >
> > The goal is to cleanup how this function is defined and used. One thing is,
> that there was an unnecessary wrapper function "Canonicalize" in jni_util.c.
> It wrapped the call to "canonicalize". We can get rid of this wrapper.
> Unfortunately, it is not possible to just export "canonicalize" since this will
> conflict with a method signature from the math library, at least on modern
> Linuxes. So I decided to call the method JDK_Canonicalize and will correctly
> define it in jdk_util.h which can be included everywhere.
> >
> >
> >
> > Hotspot's classloader.cpp will dynamically resolve this method, so I add a
> local declaration of the function pointer in there.
> >
> >
> >
> > This change shall be predecessor of JDK-8223261, where a review was
> already started here: https://mail.openjdk.java.net/pipermail/core-libs-
> dev/2019-November/063398.html
> >
> > Thanks
> > Christoph
> >


From serguei.spitsyn at oracle.com  Wed Nov 20 07:58:21 2019
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Tue, 19 Nov 2019 23:58:21 -0800
Subject: RFR: 8234185: Cleanup usage of canonicalize function between
 libjava, hotspot and libinstrument
In-Reply-To: 
References: 
 
 
Message-ID: <17b627f8-c1ff-34c0-d21a-ef1cf2cede87@oracle.com>

Thanks, Christoph!
I forgot to tell that my recommendation is for the serviceability 
(j.l.instrument) coverage only.

Thanks,
Serguei

On 11/19/19 23:47, Langer, Christoph wrote:
> Hi Serguei,
>
> thanks for the review.
>
> The patch successfully ran through our nightly test system which covers all these tests on several platforms.
>
> Best regards
> Christoph
>
>> -----Original Message-----
>> From: serguei.spitsyn at oracle.com 
>> Sent: Mittwoch, 20. November 2019 03:21
>> To: Langer, Christoph ; core-libs-
>> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; gerard
>> ziemski 
>> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function between
>> libjava, hotspot and libinstrument
>>
>> Hi Christoph,
>>
>> The fix looks good to me.
>> I'd recommend to run the jdk_instrument and vmTestbase_nsk_jvmti tests.
>> Also, it can be safe to run:
>>   ? open/test/hotspot/jtreg/serviceability/jvmti
>>   ? open/test/hotspot/jtreg/runtime/cds/appcds
>>   ? open/test/hotspot/jtreg/runtime/BootClassAppendProp
>>
>> Thanks,
>> Serguei
>>
>> On 11/14/19 07:37, Langer, Christoph wrote:
>>> Hi,
>>>
>>> please review this cleanup change regarding function "canonicalize" of
>> libjava.
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8234185
>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234185.0/
>>>
>>>
>>> The goal is to cleanup how this function is defined and used. One thing is,
>> that there was an unnecessary wrapper function "Canonicalize" in jni_util.c.
>> It wrapped the call to "canonicalize". We can get rid of this wrapper.
>> Unfortunately, it is not possible to just export "canonicalize" since this will
>> conflict with a method signature from the math library, at least on modern
>> Linuxes. So I decided to call the method JDK_Canonicalize and will correctly
>> define it in jdk_util.h which can be included everywhere.
>>>
>>>
>>> Hotspot's classloader.cpp will dynamically resolve this method, so I add a
>> local declaration of the function pointer in there.
>>>
>>>
>>> This change shall be predecessor of JDK-8223261, where a review was
>> already started here: https://mail.openjdk.java.net/pipermail/core-libs-
>> dev/2019-November/063398.html
>>> Thanks
>>> Christoph
>>>


From christoph.langer at sap.com  Wed Nov 20 08:15:22 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 20 Nov 2019 08:15:22 +0000
Subject: RFR: 8234089: (zipfs) Remove classes JarFileSystemProvider and
 JarFileSystem
In-Reply-To: 
References: 
 <3532D7A1-DF2F-41BF-80BF-09EF53B022B6@oracle.com>
 
 
 <8C407967-F743-4070-B714-52E2056B5E32@oracle.com>
 
 
 
 
Message-ID: 

Hi Lance,

I?ve taken care of ModulesInCustomFileSystem then, too.

Updated webrev in place?

Cheers
Christoph

From: Lance Andersen 
Sent: Dienstag, 19. November 2019 23:42
To: Langer, Christoph 
Cc: core-libs-dev at openjdk.java.net; nio-dev 
Subject: Re: RFR: 8234089: (zipfs) Remove classes JarFileSystemProvider and JarFileSystem

Hi Christoph,

Thank you for the follow up.
On Nov 19, 2019, at 5:37 PM, Langer, Christoph > wrote:

ModulesInCustomFileSystem

At line 71:
?????
    /**
     * Test exploded modules in a JAR file system.
     */
???????

I will look at the rest of the changes tomorrow

Best
Lance

[cid:image001.gif at 01D59F83.08ADFCD0]

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com





From Alan.Bateman at oracle.com  Wed Nov 20 08:24:47 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 20 Nov 2019 08:24:47 +0000
Subject: Class-Path (in jar file) semantics different between Java 11 and
 13 (on Windows)?
In-Reply-To: 
References: 
 <2bac906c-8489-5611-6865-085fc389e5ea@oracle.com>
 
Message-ID: 

On 19/11/2019 23:25, David Lloyd wrote:
> :
> OK, having read the updated specification (thanks Alan!) I'm now quite
> curious why `/C:/helloworld.jar` is considered invalid.  It is in fact
> a valid relative URL (colons are allowed in path segments, and the
> leading `/` unambiguously delineates the URL path), and thus it seems
> that it should be considered valid.
This is a awkward area as the parsing here is very security sensitive. 
The current implementation is deliberately limited to make it easy to 
audit. It was a deliberate decision to disallow relative URLs that 
encode a Windows file path containing a drive letter. You can of course 
use an absolute file URL here and I would expect 
"file:/C:/helloworld.jar" to work. The spec was relaxed to allow 
absolute file URLs for cases like this. I'm not opposed to expanding the 
parsing to allow for more cases but a detailed security review will be 
needed on all changes in this area.

-Alan

From Alan.Bateman at oracle.com  Wed Nov 20 08:32:35 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 20 Nov 2019 08:32:35 +0000
Subject: RFR: 8234089: (zipfs) Remove classes JarFileSystemProvider and
 JarFileSystem
In-Reply-To: 
References: 
 <3532D7A1-DF2F-41BF-80BF-09EF53B022B6@oracle.com>
 
 
 <8C407967-F743-4070-B714-52E2056B5E32@oracle.com>
 
 
 
 
 
Message-ID: <838ae646-93a8-2a17-6c76-97cfd528bc09@oracle.com>



On 20/11/2019 08:15, Langer, Christoph wrote:
>
> Hi Lance,
>
> I?ve taken care of ModulesInCustomFileSystem then, too.
>
> Updated webrev in place?
>
If the ModulesInCustomFileSystem test really needs to be changed then 
the private method that has been renamed to testZipFileSystem shoud have 
its parameter changed too. The parameter can be renamed to zipfile (or 
similar) as it's a file path to a zip file. While in the area, it should 
be changed to use the 1-arg newFileSystem method, no need to use the 
system class loader.

-Alan

From julia.boes at oracle.com  Wed Nov 20 10:52:48 2019
From: julia.boes at oracle.com (Julia Boes)
Date: Wed, 20 Nov 2019 10:52:48 +0000
Subject: RFR: 8234335: Remove line break in class declaration in java.base
In-Reply-To: <20191119134834.473503079@eggemoggin.niobe.net>
References: <7ed7ea03-be6f-2974-847d-c3c0364e9d9d@oracle.com>
 <84601299-2199-9a16-1923-ffeb92a527a1@oracle.com>
 <1ABE9DB3-E8FB-4C09-B54B-B3A73F457152@oracle.com>
 
 
 <96EEAF0B-B1B8-4533-A826-00F8DB928C8F@oracle.com>
 <20191119134834.473503079@eggemoggin.niobe.net>
Message-ID: 

>>> Seems to be a ?your milage varies?.  I am fine with whatever the
>>> final decision is.  However, I do believe the comment above reads
>>> better and aligns the methods better.
>> FWIW, and as author of many of the lines being changed, I prefer that
>> comment on a separate from the actual modifiers.  I think the basic
>> modifier patterns are easier to recognize quickly when comments and
>> annotations are separate.
> Personally I prefer to place such pseudo-modifiers on the same line
> as the actual modifiers, but I accept that some prefer otherwise.
>
> When in doubt, respect the original author?s choice.


Thanks for your comments. The separate-line version it is then!

Updated webrev:http://cr.openjdk.java.net/~jboes/webrevs/8234335/webrev.02/


Regards,

Julia


From vladimir.x.ivanov at oracle.com  Wed Nov 20 11:11:53 2019
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 20 Nov 2019 14:11:53 +0300
Subject: [14] RFR (S): 8234401: ConstantCallSite may stuck in non-frozen
 state
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: <3949ef3f-ba3c-2ff5-282c-86b6662e502f@oracle.com>

Thanks for review, Paul.

Best regards,
Vladimir Ivanov

On 19.11.2019 21:25, Paul Sandoz wrote:
> +1
> 
>> On Nov 19, 2019, at 10:12 AM, Vladimir Ivanov  wrote:
>>
>> Thanks, Paul.
>>
>>> CallSite:
>>>   public class CallSite {
>>>   - // The actual payload of this call site:
>>> + // The actual payload of this call site.
>>> + // Can be modified using {@link MethodHandleNatives#setCallSiteTargetNormal} or {@link MethodHandleNatives#setCallSiteTargetVolatile}.
>>>       /*package-private*/
>>> - MethodHandle target; // Note: This field is known to the JVM. Do not change.
>>> + final MethodHandle target; // Note: This field is known to the JVM.
>>> Is there any benefit to making target final, even though it's not really for mutable call sites? (With the recent discussion of "final means final" it would be nice to not introduce more special case stomping on final fields if we can avoid it).
>>
>> CallSite.target is already treated specially: all updates go through MethodHandleNatives and JIT-compiler treat it as "final" irrespective of the flags.
>>
>> My main interest in marking it final is to enforce proper initialization on JDK side to make it easier to reason about:
>>
>> https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-November/036021.html
>>
> 
> Ok, I see now in light of that context.
> 
> 
>>>       CallSite(MethodType targetType, MethodHandle createTargetHook) throws Throwable {
>>> - this(targetType);
>>> + this(targetType); // need to initialize target to make CallSite.type() work in createTargetHook
>>>           ConstantCallSite selfCCS = (ConstantCallSite) this;
>>>           MethodHandle boundTarget = (MethodHandle) createTargetHook.invokeWithArguments(selfCCS);
>>> - checkTargetChange(this.target, boundTarget);
>>> - this.target = boundTarget;
>>> + setTargetNormal(boundTarget); // ConstantCallSite doesn't publish CallSite.target
>>> + UNSAFE.storeStoreFence(); // barrier between target and isFrozen updates
>>>       }
>>> I wonder if instead of introducing the store store fence here we could move it into ConstantCallSite?
>>
>> Sure, if you prefer to see it on ConstantCallSite side, we can move it there.
>>
>> By putting it in CallSite near the call site update, I wanted to stress there's a CallSite.target update happening on partially published instance.
>>
> 
> Up to you.
> 
> Paul.
> 

From christoph.langer at sap.com  Wed Nov 20 13:39:16 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 20 Nov 2019 13:39:16 +0000
Subject: RFR: 8234089: (zipfs) Remove classes JarFileSystemProvider and
 JarFileSystem
In-Reply-To: <838ae646-93a8-2a17-6c76-97cfd528bc09@oracle.com>
References: 
 <3532D7A1-DF2F-41BF-80BF-09EF53B022B6@oracle.com>
 
 
 <8C407967-F743-4070-B714-52E2056B5E32@oracle.com>
 
 
 
 
 
 <838ae646-93a8-2a17-6c76-97cfd528bc09@oracle.com>
Message-ID: 

Hi Alan,

makes sense. I?ve updated the patch: http://cr.openjdk.java.net/~clanger/webrevs/8234089.4/

Best regards
Christoph

From: Alan Bateman 
Sent: Mittwoch, 20. November 2019 09:33
To: Langer, Christoph ; Lance Andersen 
Cc: nio-dev ; core-libs-dev at openjdk.java.net
Subject: Re: RFR: 8234089: (zipfs) Remove classes JarFileSystemProvider and JarFileSystem


On 20/11/2019 08:15, Langer, Christoph wrote:
Hi Lance,

I?ve taken care of ModulesInCustomFileSystem then, too.

Updated webrev in place?

If the ModulesInCustomFileSystem test really needs to be changed then the private method that has been renamed to testZipFileSystem shoud have its parameter changed too. The parameter can be renamed to zipfile (or similar) as it's a file path to a zip file. While in the area, it should be changed to use the 1-arg newFileSystem method, no need to use the system class loader.

-Alan

From david.lloyd at redhat.com  Wed Nov 20 13:50:07 2019
From: david.lloyd at redhat.com (David Lloyd)
Date: Wed, 20 Nov 2019 07:50:07 -0600
Subject: Class-Path (in jar file) semantics different between Java 11 and
 13 (on Windows)?
In-Reply-To: 
References: 
 <2bac906c-8489-5611-6865-085fc389e5ea@oracle.com>
 
 
Message-ID: 

On Wed, Nov 20, 2019 at 2:25 AM Alan Bateman  wrote:
>
> On 19/11/2019 23:25, David Lloyd wrote:
> > :
> > OK, having read the updated specification (thanks Alan!) I'm now quite
> > curious why `/C:/helloworld.jar` is considered invalid.  It is in fact
> > a valid relative URL (colons are allowed in path segments, and the
> > leading `/` unambiguously delineates the URL path), and thus it seems
> > that it should be considered valid.
> This is a awkward area as the parsing here is very security sensitive.
> The current implementation is deliberately limited to make it easy to
> audit. It was a deliberate decision to disallow relative URLs that
> encode a Windows file path containing a drive letter.

OK, but this decision violates both the old and updated spec (and
makes it difficult to write code that works in both cases: in
situations that reject absolute URLs (javac) and in situations that
reject drive letters (this code)), so I would request that this be
revisited.

> You can of course
> use an absolute file URL here and I would expect
> "file:/C:/helloworld.jar" to work. The spec was relaxed to allow
> absolute file URLs for cases like this. I'm not opposed to expanding the
> parsing to allow for more cases but a detailed security review will be
> needed on all changes in this area.

Is there anything I can do to help?

-- 
- DML


From andy.herrick at oracle.com  Wed Nov 20 14:31:15 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Wed, 20 Nov 2019 09:31:15 -0500
Subject: RFR: JDK-8234402: revert change that stopped providing
 JPackageToolProvider
In-Reply-To: 
References: <99cb8aad-239d-f4b7-54a3-27c7e955607e@oracle.com>
 
Message-ID: <2e7cd9f8-80dd-512c-705f-2d25e06ef0ce@oracle.com>


On 11/19/2019 9:00 PM, Alexey Semenyuk wrote:
> Andy,
>
> I guess 
> http://cr.openjdk.java.net/~herrick/8234402/webrev.02/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JavaTool.java.sdiff.html 
> can be reverted to its initial state now:
> ---
> public ToolProvider asToolProvider() {
> ??? return ToolProvider.findFirst(name).orElse(null);
> }
> ---
>
sure - can include that.

/Andy

> - Alexey
>
> On 11/19/2019 7:00 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 change restores JPackageToolProvider and gets rid of the 
>> temporary factory class.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8234402
>>
>> [2] http://cr.openjdk.java.net/~herrick/8234402/webrev.02/
>>
>> /Andy
>>
>

From andy.herrick at oracle.com  Wed Nov 20 14:36:34 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Wed, 20 Nov 2019 09:36:34 -0500
Subject: RFR: JDK-8234402: revert change that stopped providing
 JPackageToolProvider
In-Reply-To: 
References: <99cb8aad-239d-f4b7-54a3-27c7e955607e@oracle.com>
 
Message-ID: 

webrev revised in place at [2].

/Andy

On 11/19/2019 9:00 PM, Alexey Semenyuk wrote:
> Andy,
>
> I guess 
> http://cr.openjdk.java.net/~herrick/8234402/webrev.02/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JavaTool.java.sdiff.html 
> can be reverted to its initial state now:
> ---
> public ToolProvider asToolProvider() {
> ??? return ToolProvider.findFirst(name).orElse(null);
> }
> ---
>
> - Alexey
>
> On 11/19/2019 7:00 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 change restores JPackageToolProvider and gets rid of the 
>> temporary factory class.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8234402
>>
>> [2] http://cr.openjdk.java.net/~herrick/8234402/webrev.02/
>>
>> /Andy
>>
>

From kevin.rushforth at oracle.com  Wed Nov 20 14:39:06 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 20 Nov 2019 06:39:06 -0800
Subject: RFR: JDK-8234402: revert change that stopped providing
 JPackageToolProvider
In-Reply-To: 
References: <99cb8aad-239d-f4b7-54a3-27c7e955607e@oracle.com>
 
 
Message-ID: <15ad5e31-981f-238f-d5c4-9ad9e860a57d@oracle.com>

Looks good.

-- Kevin


On 11/20/2019 6:36 AM, Andy Herrick wrote:
> webrev revised in place at [2].
>
> /Andy
>
> On 11/19/2019 9:00 PM, Alexey Semenyuk wrote:
>> Andy,
>>
>> I guess 
>> http://cr.openjdk.java.net/~herrick/8234402/webrev.02/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JavaTool.java.sdiff.html 
>> can be reverted to its initial state now:
>> ---
>> public ToolProvider asToolProvider() {
>> ??? return ToolProvider.findFirst(name).orElse(null);
>> }
>> ---
>>
>> - Alexey
>>
>> On 11/19/2019 7:00 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 change restores JPackageToolProvider and gets rid of the 
>>> temporary factory class.
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8234402
>>>
>>> [2] http://cr.openjdk.java.net/~herrick/8234402/webrev.02/
>>>
>>> /Andy
>>>
>>


From Alan.Bateman at oracle.com  Wed Nov 20 14:58:43 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 20 Nov 2019 14:58:43 +0000
Subject: Class-Path (in jar file) semantics different between Java 11 and
 13 (on Windows)?
In-Reply-To: 
References: 
 <2bac906c-8489-5611-6865-085fc389e5ea@oracle.com>
 
 
 
Message-ID: 

On 20/11/2019 13:50, David Lloyd wrote:
> :
> OK, but this decision violates both the old and updated spec (and
> makes it difficult to write code that works in both cases: in
> situations that reject absolute URLs (javac) and in situations that
> reject drive letters (this code)), so I would request that this be
> revisited.
>
This cannot be rushed as it require detailed security analysis. Is there 
any reason why you need to encode absolute file paths as relative URLs? 
I assume the use-case discussed here will work if File::toURI or toURL 
is used to create the file URL as it will have the "file:" scheme.

-Alan

From Alan.Bateman at oracle.com  Wed Nov 20 15:02:21 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 20 Nov 2019 15:02:21 +0000
Subject: RFR: 8234089: (zipfs) Remove classes JarFileSystemProvider and
 JarFileSystem
In-Reply-To: 
References: 
 <3532D7A1-DF2F-41BF-80BF-09EF53B022B6@oracle.com>
 
 
 <8C407967-F743-4070-B714-52E2056B5E32@oracle.com>
 
 
 
 
 
 <838ae646-93a8-2a17-6c76-97cfd528bc09@oracle.com>
 
Message-ID: <6006563b-f46b-f0c8-0b83-53628d27287b@oracle.com>



On 20/11/2019 13:39, Langer, Christoph wrote:
>
> Hi Alan,
>
> makes sense. I?ve updated the patch: 
> http://cr.openjdk.java.net/~clanger/webrevs/8234089.4/ 
> 
>
>
The updated test looks okay.

-Alan

From Roger.Riggs at oracle.com  Wed Nov 20 15:07:58 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 20 Nov 2019 10:07:58 -0500
Subject: RFR [XS] : 8234339: replace JLI_StrTok in java_md_solinux.c
In-Reply-To: 
References: 
Message-ID: <508aaeaa-5168-da52-2196-f521de1e5931@oracle.com>

Hi Matthias,

Good to see the switch to strtok_r.
Looks fine.

Thanks, Roger


On 11/19/19 4:23 AM, Baesken, Matthias wrote:
> Hello, please review this small change .
>
> JLI_StrTok is only used in one function, so the define can be replaced, probably we should use the "safer" strtok_r (the MT safety might not be a big deal in the launcher however).
>
>
> Bug/webrev :
>
> https://bugs.openjdk.java.net/browse/JDK-8234339
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8234339.0/
>
>
> Thanks, Matthias


From swpalmer at gmail.com  Wed Nov 20 15:25:45 2019
From: swpalmer at gmail.com (Scott Palmer)
Date: Wed, 20 Nov 2019 10:25:45 -0500
Subject: Class-Path (in jar file) semantics different between Java 11 and
 13 (on Windows)?
In-Reply-To: 
References: 
 <2bac906c-8489-5611-6865-085fc389e5ea@oracle.com>
 
 
 
 
Message-ID: 

/C:/blah... is ?root relative?. The (old) spec says the URL must be
"relative to the code base".  What does "code base" mean when not referring
to Applets or RMI?

This seems like a bad idea (security hole) that worked by accident.

Scott

On Wed, Nov 20, 2019 at 10:00 AM Alan Bateman 
wrote:

> On 20/11/2019 13:50, David Lloyd wrote:
> > :
> > OK, but this decision violates both the old and updated spec (and
> > makes it difficult to write code that works in both cases: in
> > situations that reject absolute URLs (javac) and in situations that
> > reject drive letters (this code)), so I would request that this be
> > revisited.
> >
> This cannot be rushed as it require detailed security analysis. Is there
> any reason why you need to encode absolute file paths as relative URLs?
> I assume the use-case discussed here will work if File::toURI or toURL
> is used to create the file URL as it will have the "file:" scheme.
>
> -Alan
>

From david.lloyd at redhat.com  Wed Nov 20 16:54:59 2019
From: david.lloyd at redhat.com (David Lloyd)
Date: Wed, 20 Nov 2019 10:54:59 -0600
Subject: Class-Path (in jar file) semantics different between Java 11 and
 13 (on Windows)?
In-Reply-To: 
References: 
 <2bac906c-8489-5611-6865-085fc389e5ea@oracle.com>
 
 
 
 
 
Message-ID: 

On Wed, Nov 20, 2019 at 9:26 AM Scott Palmer  wrote:
>
> /C:/blah... is ?root relative?. The (old) spec says the URL must be "relative to the code base".  What does "code base" mean when not referring to Applets or RMI?

"code base" is generally the URL of the class path entry itself.  It's
mainly defined in the specification for java.lang.ClassLoader.

> This seems like a bad idea (security hole) that worked by accident.

The specification is pretty clear, and doesn't seem unintentional.
Relative URLs have a very specific normative definition.  It's very
unambiguous; the code just doesn't work the way the specification says
it should.

-- 
- DML


From david.lloyd at redhat.com  Wed Nov 20 17:02:08 2019
From: david.lloyd at redhat.com (David Lloyd)
Date: Wed, 20 Nov 2019 11:02:08 -0600
Subject: Class-Path (in jar file) semantics different between Java 11 and
 13 (on Windows)?
In-Reply-To: 
References: 
 <2bac906c-8489-5611-6865-085fc389e5ea@oracle.com>
 
 
 
 
Message-ID: 

On Wed, Nov 20, 2019 at 8:59 AM Alan Bateman  wrote:
>
> On 20/11/2019 13:50, David Lloyd wrote:
> > :
> > OK, but this decision violates both the old and updated spec (and
> > makes it difficult to write code that works in both cases: in
> > situations that reject absolute URLs (javac) and in situations that
> > reject drive letters (this code)), so I would request that this be
> > revisited.
> >
> This cannot be rushed as it require detailed security analysis.

Sure, whatever process is necessary should be undertaken.  Hopefully
there is not a lot to do in terms of security analysis for this
particular change though; I imagine it's more of just running through
the process.  But when the just-rewritten code doesn't meet the
just-rewritten spec, I think it's warranted.

> Is there
> any reason why you need to encode absolute file paths as relative URLs?
> I assume the use-case discussed here will work if File::toURI or toURL
> is used to create the file URL as it will have the "file:" scheme.

I'll see where the usages are.  I believe at least one usage is out of
our control though, and I'm pretty sure that Maven uses absolute paths
for surefire and failsafe (test) launching.

-- 
- DML


From lance.andersen at oracle.com  Wed Nov 20 17:02:58 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 20 Nov 2019 12:02:58 -0500
Subject: RFR: 8234335: Remove line break in class declaration in java.base
In-Reply-To: 
References: <7ed7ea03-be6f-2974-847d-c3c0364e9d9d@oracle.com>
 <84601299-2199-9a16-1923-ffeb92a527a1@oracle.com>
 <1ABE9DB3-E8FB-4C09-B54B-B3A73F457152@oracle.com>
 
 
 <96EEAF0B-B1B8-4533-A826-00F8DB928C8F@oracle.com>
 <20191119134834.473503079@eggemoggin.niobe.net>
 
Message-ID: 

Looks Good Julia

> On Nov 20, 2019, at 5:52 AM, Julia Boes  wrote:
> 
>>>> Seems to be a ?your milage varies?.  I am fine with whatever the
>>>> final decision is.  However, I do believe the comment above reads
>>>> better and aligns the methods better.
>>> FWIW, and as author of many of the lines being changed, I prefer that
>>> comment on a separate from the actual modifiers.  I think the basic
>>> modifier patterns are easier to recognize quickly when comments and
>>> annotations are separate.
>> Personally I prefer to place such pseudo-modifiers on the same line
>> as the actual modifiers, but I accept that some prefer otherwise.
>> 
>> When in doubt, respect the original author?s choice.
> 
> 
> Thanks for your comments. The separate-line version it is then!
> 
> Updated webrev:http://cr.openjdk.java.net/~jboes/webrevs/8234335/webrev.02/
> 
> 
> Regards,
> 
> Julia
> 

 
  
 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 alexey.semenyuk at oracle.com  Wed Nov 20 17:16:09 2019
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Wed, 20 Nov 2019 12:16:09 -0500
Subject: RFR: JDK-8234402: revert change that stopped providing
 JPackageToolProvider
In-Reply-To: 
References: <99cb8aad-239d-f4b7-54a3-27c7e955607e@oracle.com>
 
 
Message-ID: <5f3090ff-dbde-c5b0-234e-c424102f2dd9@oracle.com>

Looks good.

- Alexey

On 11/20/2019 9:36 AM, Andy Herrick wrote:
> webrev revised in place at [2].
>
> /Andy
>
> On 11/19/2019 9:00 PM, Alexey Semenyuk wrote:
>> Andy,
>>
>> I guess 
>> http://cr.openjdk.java.net/~herrick/8234402/webrev.02/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JavaTool.java.sdiff.html 
>> can be reverted to its initial state now:
>> ---
>> public ToolProvider asToolProvider() {
>> ??? return ToolProvider.findFirst(name).orElse(null);
>> }
>> ---
>>
>> - Alexey
>>
>> On 11/19/2019 7:00 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 change restores JPackageToolProvider and gets rid of the 
>>> temporary factory class.
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8234402
>>>
>>> [2] http://cr.openjdk.java.net/~herrick/8234402/webrev.02/
>>>
>>> /Andy
>>>
>>


From Alan.Bateman at oracle.com  Wed Nov 20 17:21:40 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 20 Nov 2019 17:21:40 +0000
Subject: Class-Path (in jar file) semantics different between Java 11 and
 13 (on Windows)?
In-Reply-To: 
References: 
 <2bac906c-8489-5611-6865-085fc389e5ea@oracle.com>
 
 
 
 
 
Message-ID: 



On 20/11/2019 17:02, David Lloyd wrote:
> I'll see where the usages are.  I believe at least one usage is out of
> our control though, and I'm pretty sure that Maven uses absolute paths
> for surefire and failsafe (test) launching.
>
Let us know on that. I remember we ran into issues with Sunfire abusing 
this attribute and this was part of the motivation for relaxing the spec 
to allow absolute URLs when the scheme is "file".

-Alan

From Roger.Riggs at oracle.com  Wed Nov 20 17:31:47 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 20 Nov 2019 12:31:47 -0500
Subject: RFR: 8234335: Remove line break in class declaration in java.base
In-Reply-To: 
References: <7ed7ea03-be6f-2974-847d-c3c0364e9d9d@oracle.com>
 <84601299-2199-9a16-1923-ffeb92a527a1@oracle.com>
 <1ABE9DB3-E8FB-4C09-B54B-B3A73F457152@oracle.com>
 
 
 <96EEAF0B-B1B8-4533-A826-00F8DB928C8F@oracle.com>
 <20191119134834.473503079@eggemoggin.niobe.net>
 
 
Message-ID: 

+1

Thanks, Roger

On 11/20/19 12:02 PM, Lance Andersen wrote:
> Looks Good Julia
>
>> On Nov 20, 2019, at 5:52 AM, Julia Boes  wrote:
>>
>>>>> Seems to be a ?your milage varies?.  I am fine with whatever the
>>>>> final decision is.  However, I do believe the comment above reads
>>>>> better and aligns the methods better.
>>>> FWIW, and as author of many of the lines being changed, I prefer that
>>>> comment on a separate from the actual modifiers.  I think the basic
>>>> modifier patterns are easier to recognize quickly when comments and
>>>> annotations are separate.
>>> Personally I prefer to place such pseudo-modifiers on the same line
>>> as the actual modifiers, but I accept that some prefer otherwise.
>>>
>>> When in doubt, respect the original author?s choice.
>>
>> Thanks for your comments. The separate-line version it is then!
>>
>> Updated webrev:http://cr.openjdk.java.net/~jboes/webrevs/8234335/webrev.02/
>>
>>
>> Regards,
>>
>> Julia
>>
>   
>    
>   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  Wed Nov 20 17:37:20 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Wed, 20 Nov 2019 12:37:20 -0500
Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation
In-Reply-To: <35372d0e-910a-d8c1-6bf4-88fcb140daee@oracle.com>
References: 
 <35372d0e-910a-d8c1-6bf4-88fcb140daee@oracle.com>
Message-ID: <2589963b-b10e-7af9-bf1a-208df190fb2a@oracle.com>

I posted new composite webrev [7], and git patch [8] after pushing fix 
for JDK-8234402 [6].

[7] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11/

[8] http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-11.git.patch

/Andy

On 11/19/2019 3:13 PM, Kevin Rushforth wrote:
> I took the "git diff" patch [5] that you uploaded yesterday, applied 
> it, and verified that it is the same as what is in the 
> JDK-8200758-branch branch of the sandbox. It builds and runs fine for me.
>
> I ran jcheck and it found the following three files with whitespace 
> errors that will need to be fixed before you push:
>
> src/jdk.incubator.jpackage/linux/classes/jdk/incubator/jpackage/internal/PackageProperty.java:49: 
> Trailing whitespace
> src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/ToolProviderFactory.java:35: 
> Trailing whitespace
> test/jdk/tools/jpackage/share/AddLauncherBase.java:137: Trailing 
> whitespace
>
> The second of these will go away with the fix for JDK-8234402 [6], so 
> you don't need to do anything there. Once the fix for JDK-8234402 is 
> pushed to sandbox, I presume you will update the webrev, right?
>
> Pending the fix for JDK-8234402 and the needed white-space fixes, this 
> is a +1 from me (although I am not a jdk Project Reviewer, so you will 
> need at least one review from someone who is).
>
> -- Kevin
>
> [5] http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-10.git.patch
> [6] https://bugs.openjdk.java.net/browse/JDK-8234402
>
>
> On 11/13/2019 4:23 PM, Andy Herrick wrote:
>> Please review? changes for [1] which is the implementation bug for 
>> JEP-343.
>>
>> The webrev at [2] is the total cumulative webrev of changes for the 
>> jpackage tool, currently in the JDK-8200758-branch branch of the open 
>> sandbox repository.
>>
>> The webrev at [3] shows the changes since EA-06 (Build 
>> 13-jpackage+1-49 ) up to the current point.
>>
>> The latest EA (Build 14-jpackage+1-49 ) is posted at [4].
>>
>> Please send feedback to core-libs-dev at openjdk.java.net
>>
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8212780
>>
>> [2] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-10/
>>
>> [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-10/
>>
>> [4] http://jdk.java.net/jpackage/
>>
>

From lance.andersen at oracle.com  Wed Nov 20 18:01:58 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 20 Nov 2019 13:01:58 -0500
Subject: RFR: 8234089: (zipfs) Remove classes JarFileSystemProvider and
 JarFileSystem
In-Reply-To: <6006563b-f46b-f0c8-0b83-53628d27287b@oracle.com>
References: 
 <3532D7A1-DF2F-41BF-80BF-09EF53B022B6@oracle.com>
 
 
 <8C407967-F743-4070-B714-52E2056B5E32@oracle.com>
 
 
 
 
 
 <838ae646-93a8-2a17-6c76-97cfd528bc09@oracle.com>
 
 <6006563b-f46b-f0c8-0b83-53628d27287b@oracle.com>
Message-ID: <97B14E3E-737A-4E31-B878-23D48F076392@oracle.com>

Hi Christoph,

Again, thank you for your efforts here.

Overall I think your latest changes look fine.  I would like to suggest that for the methods that you added for MR support, that we make sure the 1st character in the comment is capitalized prior to your push of the changes.  I know this was not that way prior, but I think it helps with consistency.

BTW,  I am not sure that JarFileSystemProvider was actually ever used(JarFileSystem was though) as when I look at the installed providers on my Mac, I see:

[sun.nio.fs.MacOSXFileSystemProvider at 5b2133b1, jdk.nio.zipfs.ZipFileSystemProvider at 72ea2f77, jdk.internal.jrtfs.JrtFileSystemProvider at 33c7353a]


Best
Lance
> On Nov 20, 2019, at 10:02 AM, Alan Bateman  wrote:
> 
> 
> 
> On 20/11/2019 13:39, Langer, Christoph wrote:
>> Hi Alan,
>>  
>> makes sense. I?ve updated the patch: http://cr.openjdk.java.net/~clanger/webrevs/8234089.4/ 
> The updated test looks okay.
> 
> -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 Nikola.Grcevski at microsoft.com  Wed Nov 20 19:42:29 2019
From: Nikola.Grcevski at microsoft.com (Nikola Grcevski)
Date: Wed, 20 Nov 2019 19:42:29 +0000
Subject: JDK-8234076 bug fix candidate
Message-ID: 

Hello core-libs-dev,

I'm a VM engineer at Microsoft and new to this mailing list. I took a look at JDK- 8234076 and the root cause is similar to a prior thread on a Windows launcher bug for JDK- 8231863, after the command line arguments are processed, the static variable firstAppArgIndex in src/java.base/share/native/libjli/args.c remains set to NOT_FOUND (-1). The reason for not finding a firstAppArgIndex in this case is because the command line supplied to the launcher has every argument prefixed with a dash, for example:

java --module-path=mods --module=com.greetings/com.greetings.Main --help

Because all arguments are prefixed with a dash, the checkArg function inside src/java.base/share/native/libjli/args.c never finds an app arg index.

Currently, this only causes an issue on Windows because of the custom argument expansion code in function CreateApplicationArgs  of src/java.base/windows/native/libjli/java_md.c. The code queries the firstAppArgIndex and proceeds to perform an array access without checking if the app index is greater or equal to 0, causing the randomly observed crash. 

I have made the following patch to address the issue:

--- a/src/java.base/windows/native/libjli/java_md.c
+++ b/src/java.base/windows/native/libjli/java_md.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include "java.h"
@@ -1015,6 +1016,17 @@ CreateApplicationArgs(JNIEnv *env, char **strv, int argc)
 
     // sanity check, match the args we have, to the holy grail
     idx = JLI_GetAppArgIndex();
+
+    // First arg index is NOT_FOUND
+    if (idx < 0) {
+        // The only allowed value should be NOT_FOUND (-1) unless another change introduces 
+        // a different negative index
+        assert (idx == -1);
+        JLI_TraceLauncher("Warning: first app arg index not found, %d\n", idx);
+        JLI_TraceLauncher("passing arguments as-is.\n");
+        return NewPlatformStringArray(env, strv, argc);
+    }
+
     isTool = (idx == 0);
     if (isTool) { idx++; } // skip tool name
     JLI_TraceLauncher("AppArgIndex: %d points to %s\n", idx, stdargs[idx].arg);

I wanted to ask for an advice and opinion if this is the correct way to fix the problem?

I did few tests and I can confirm that the fix above doesn't change the current behaviour on Windows, because in case the negative index array access doesn't cause a crash, the later sanity check below (in java_md.c CreateApplicationArgs ) will always catch the invalid case and simply pass down the arguments as is.

    // sanity check, ensure same number of arguments for application
    if (j != argc) {
        JLI_TraceLauncher("Warning: app args count doesn't match, %d %d\n", j, argc);
        JLI_TraceLauncher("passing arguments as-is.\n");
        JLI_MemFree(appArgIdx);
        return NewPlatformStringArray(env, strv, argc);
    }

However, if the command line is supplied with --module= instead of --module followed by a blank space, Windows will not perform argument expansion on the application arguments. For example:

java --module-path=mods --module=com.greetings/com.greetings.Main ./* --help (the path will not be expanded) 
java --module-path=mods --module com.greetings/com.greetings.Main ./* --help (the path will be correctly expanded)

I tested on Linux x86-64 and the argument expansion is correctly performed in both cases where --module= is used and where --module is followed by a space. Essentially, Windows behaves differently in this case, but it has always been this way. The patch only prevents the random crash, fixing the command line incompatibility will require a more substantial change. 

Please let me know if this approach is acceptable for the current bug report and I'll make a webrev and include appropriate launcher tests. I was thinking the tests should do extra validation on the output from _JAVA_LAUNCHER_DEBUG on Windows.

Thank you!
-Nikola


From alexander.matveev at oracle.com  Wed Nov 20 19:46:41 2019
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Wed, 20 Nov 2019 11:46:41 -0800
Subject: RFR: JDK-8234402: revert change that stopped providing
 JPackageToolProvider
In-Reply-To: 
References: <99cb8aad-239d-f4b7-54a3-27c7e955607e@oracle.com>
 
 
Message-ID: <3c8af5a7-257a-c108-f254-d3cf178ee781@oracle.com>

Looks good.

On 11/20/2019 6:36 AM, Andy Herrick wrote:
> webrev revised in place at [2].
>
> /Andy
>
> On 11/19/2019 9:00 PM, Alexey Semenyuk wrote:
>> Andy,
>>
>> I guess 
>> http://cr.openjdk.java.net/~herrick/8234402/webrev.02/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JavaTool.java.sdiff.html 
>> can be reverted to its initial state now:
>> ---
>> public ToolProvider asToolProvider() {
>> ??? return ToolProvider.findFirst(name).orElse(null);
>> }
>> ---
>>
>> - Alexey
>>
>> On 11/19/2019 7:00 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 change restores JPackageToolProvider and gets rid of the 
>>> temporary factory class.
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8234402
>>>
>>> [2] http://cr.openjdk.java.net/~herrick/8234402/webrev.02/
>>>
>>> /Andy
>>>
>>


From huizhe.wang at oracle.com  Wed Nov 20 21:48:17 2019
From: huizhe.wang at oracle.com (Joe Wang)
Date: Wed, 20 Nov 2019 13:48:17 -0800
Subject: RFR [14/java.xml] 8233548: Update CUP to v0.11b
Message-ID: <08726be0-44b3-0da8-c839-0e2fe4448091@oracle.com>

Hi,

Please review an update to Java CUP. This is an effort to move to the 
latest version, v0.11b. JCUP is used by Xalan to generate XPathParser. 
Included in the JDK are runtime classes and XPathParser. In CUP 0.11b, 
the main additions to the runtime were SymbolFactory and ComplexSymbol 
that were used to report a bit more details (locations) about the 
parsing process. They were not used by Xalan nor the JDK since the 
benefit of these additions were in error reporting, but Xalan and JDK 
used their own reporting mechanism. I could have removed the JCUP error 
report process altogether, but decided to keep it in case it might be 
used for debugging.

The main change for this update therefore is to the XPathParser itself. 
Since JCUP has been stable, and no major Xalan update in sight, I took 
the liberty to re-format the whole class, plus some cleanup (mainly 
boxing/unboxing), that constitute the changes before the inner class 
parser_actions. Within parser_actions, the main change is that the 0.11b 
fixed the order of the switch block. Other than that, I removed many 
unused variables, and also formatted the long lines.

There were no other material changes. So there's no new test, all 
existing tests (including JCK) passed.

JBS: https://bugs.openjdk.java.net/browse/JDK-8233548
webrevs: http://cr.openjdk.java.net/~joehw/jdk14/8233548/webrev/

Thanks,
Joe


From vicente.romero at oracle.com  Thu Nov 21 00:11:05 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Wed, 20 Nov 2019 19:11:05 -0500
Subject: RFR: JEP 367: Remove the Pack200 Tools and API
In-Reply-To: <6668f1ff-6a56-e66a-c013-f6ed5a7a8d8b@oracle.com>
References: <09dc53f1-9208-3b1f-3ee6-e0e22210afc5@oracle.com>
 <96643033-bcac-20f3-32d6-3152a6926459@oracle.com>
 <061e3eb4-0492-f286-0fca-7b70a4a1255b@oracle.com>
 <6668f1ff-6a56-e66a-c013-f6ed5a7a8d8b@oracle.com>
Message-ID: <5a1812bb-3239-6a08-ef96-6956b2cc2bc0@oracle.com>

moving the discussion to core-libs. I have updated the webrev [1], after 
removing the reference found by David and another one I found with a 
help text at:

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties

Thanks,
Vicente

[1] http://cr.openjdk.java.net/~vromero/8234542/webrev.01/

On 11/20/19 6:26 PM, David Holmes wrote:
> Hi Vicente,
>
> On 21/11/2019 9:22 am, Vicente Romero wrote:
>> Hi David,
>>
>> This is the list that appears in the `Discussion` tag in the JEP [1]. 
>
> Sure but we're not discussing the JEP, this is now the RFR.
>
> Cheers,
> David
>
>> I will remove that reference,
>>
>> Thanks,
>> Vicente
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8232022
>>
>> On 11/20/19 6:10 PM, David Holmes wrote:
>>> Hi Vicente,
>>>
>>> Not sure the best mailing list for this review ... jdk-dev may not 
>>> be well monitored.
>>>
>>> Is there a separate review thread for the actual tool removal 
>>> (jdk.pack) and build system changes?
>>>
>>> This removal seems okay, but I found one additional reference:
>>>
>>> ./src/utils/IdealGraphVisualizer/nbproject/project.properties:auxiliary.org-netbeans-modules-apisupport-installer.pack200-enabled=false 
>>>
>>>
>>> Thanks,
>>> David
>>> -----
>>>
>>> On 21/11/2019 8:54 am, Vicente Romero wrote:
>>>> Hi,
>>>>
>>>> I need a reviewer for the changes to remove pack200 and unpack200 
>>>> from the JDK. The webrev with the removal is at [1]. This patch is 
>>>> the "implementation" of JEP 367 [2]. The patch is basically 
>>>> removing the Pack200 related APIs plus its implementation plus any 
>>>> reference to it in other tools like `jar`. In the case of `jar`, 
>>>> Pack200 was only used if the `-n` flag was passed to the tool. I 
>>>> have removed the code that was executed when that flag was passed. 
>>>> I have also removed all the tests for Pack200.
>>>>
>>>> Thanks,
>>>> Vicente
>>>>
>>>> [1] http://cr.openjdk.java.net/~vromero/8234542/webrev.00/
>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8232022
>>


From mandy.chung at oracle.com  Thu Nov 21 01:01:18 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 20 Nov 2019 17:01:18 -0800
Subject: RFR: JEP 367: Remove the Pack200 Tools and API
In-Reply-To: <5a1812bb-3239-6a08-ef96-6956b2cc2bc0@oracle.com>
References: <09dc53f1-9208-3b1f-3ee6-e0e22210afc5@oracle.com>
 <96643033-bcac-20f3-32d6-3152a6926459@oracle.com>
 <061e3eb4-0492-f286-0fca-7b70a4a1255b@oracle.com>
 <6668f1ff-6a56-e66a-c013-f6ed5a7a8d8b@oracle.com>
 <5a1812bb-3239-6a08-ef96-6956b2cc2bc0@oracle.com>
Message-ID: <49b1a0c5-4456-ed91-d103-b0582a680f91@oracle.com>

(bcc jdk-dev.?? The review can continue on core-libs-dev)

Hi Vicente,

The following files should also be removed.
 ?? make/launcher/Launcher-jdk.pack.gmk
test/jdk/java/util/jar/Pack200/*

The following files reference pack200 in its comment.? I'm not sure if 
they need update or not.

src/java.base/solaris/native/libjvm_db/libjvm_db.c
src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CompressedReadStream.java
src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CompressedStream.java

Is a CSR ready to be reviewed?

Mandy


On 11/20/19 4:11 PM, Vicente Romero wrote:
> moving the discussion to core-libs. I have updated the webrev [1], 
> after removing the reference found by David and another one I found 
> with a help text at:
>
> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties
>
> Thanks,
> Vicente
>
> [1] http://cr.openjdk.java.net/~vromero/8234542/webrev.01/
>
> On 11/20/19 6:26 PM, David Holmes wrote:
>> Hi Vicente,
>>
>> On 21/11/2019 9:22 am, Vicente Romero wrote:
>>> Hi David,
>>>
>>> This is the list that appears in the `Discussion` tag in the JEP [1]. 
>>
>> Sure but we're not discussing the JEP, this is now the RFR.
>>
>> Cheers,
>> David
>>
>>> I will remove that reference,
>>>
>>> Thanks,
>>> Vicente
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8232022
>>>
>>> On 11/20/19 6:10 PM, David Holmes wrote:
>>>> Hi Vicente,
>>>>
>>>> Not sure the best mailing list for this review ... jdk-dev may not 
>>>> be well monitored.
>>>>
>>>> Is there a separate review thread for the actual tool removal 
>>>> (jdk.pack) and build system changes?
>>>>
>>>> This removal seems okay, but I found one additional reference:
>>>>
>>>> ./src/utils/IdealGraphVisualizer/nbproject/project.properties:auxiliary.org-netbeans-modules-apisupport-installer.pack200-enabled=false 
>>>>
>>>>
>>>> Thanks,
>>>> David
>>>> -----
>>>>
>>>> On 21/11/2019 8:54 am, Vicente Romero wrote:
>>>>> Hi,
>>>>>
>>>>> I need a reviewer for the changes to remove pack200 and unpack200 
>>>>> from the JDK. The webrev with the removal is at [1]. This patch is 
>>>>> the "implementation" of JEP 367 [2]. The patch is basically 
>>>>> removing the Pack200 related APIs plus its implementation plus any 
>>>>> reference to it in other tools like `jar`. In the case of `jar`, 
>>>>> Pack200 was only used if the `-n` flag was passed to the tool. I 
>>>>> have removed the code that was executed when that flag was passed. 
>>>>> I have also removed all the tests for Pack200.
>>>>>
>>>>> Thanks,
>>>>> Vicente
>>>>>
>>>>> [1] http://cr.openjdk.java.net/~vromero/8234542/webrev.00/
>>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8232022
>>>
>


From david.holmes at oracle.com  Thu Nov 21 01:18:30 2019
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 21 Nov 2019 11:18:30 +1000
Subject: RFR: JEP 367: Remove the Pack200 Tools and API
In-Reply-To: <49b1a0c5-4456-ed91-d103-b0582a680f91@oracle.com>
References: <09dc53f1-9208-3b1f-3ee6-e0e22210afc5@oracle.com>
 <96643033-bcac-20f3-32d6-3152a6926459@oracle.com>
 <061e3eb4-0492-f286-0fca-7b70a4a1255b@oracle.com>
 <6668f1ff-6a56-e66a-c013-f6ed5a7a8d8b@oracle.com>
 <5a1812bb-3239-6a08-ef96-6956b2cc2bc0@oracle.com>
 <49b1a0c5-4456-ed91-d103-b0582a680f91@oracle.com>
Message-ID: <2d06b079-279a-0715-a131-79f34df015b1@oracle.com>

On 21/11/2019 11:01 am, Mandy Chung wrote:
> (bcc jdk-dev.?? The review can continue on core-libs-dev)
> 
> Hi Vicente,
> 
> The following files should also be removed.
>  ?? make/launcher/Launcher-jdk.pack.gmk

There are a number of build changes to be made:

./make/autoconf/compare.sh.in:export UNPACK200="@FIXPATH@ 
@BOOT_JDK@/bin/unpack200"
./make/autoconf/flags-cflags.m4:    # unpack200.exe.
./make/launcher/Launcher-jdk.pack.gmk
./make/scripts/compare_exceptions.sh.incl:      ./bin/unpack200

which need to be reviewed on build-dev

> test/jdk/java/util/jar/Pack200/*
> 
> The following files reference pack200 in its comment.? I'm not sure if 
> they need update or not.
> 
> src/java.base/solaris/native/libjvm_db/libjvm_db.c
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CompressedReadStream.java 
> 
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CompressedStream.java 

Same comments in ./src/hotspot/share/code/compressedStream.hpp

Cheers,
David

> Is a CSR ready to be reviewed?
> 
> Mandy
> 
> 
> On 11/20/19 4:11 PM, Vicente Romero wrote:
>> moving the discussion to core-libs. I have updated the webrev [1], 
>> after removing the reference found by David and another one I found 
>> with a help text at:
>>
>> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties
>>
>> Thanks,
>> Vicente
>>
>> [1] http://cr.openjdk.java.net/~vromero/8234542/webrev.01/
>>
>> On 11/20/19 6:26 PM, David Holmes wrote:
>>> Hi Vicente,
>>>
>>> On 21/11/2019 9:22 am, Vicente Romero wrote:
>>>> Hi David,
>>>>
>>>> This is the list that appears in the `Discussion` tag in the JEP [1]. 
>>>
>>> Sure but we're not discussing the JEP, this is now the RFR.
>>>
>>> Cheers,
>>> David
>>>
>>>> I will remove that reference,
>>>>
>>>> Thanks,
>>>> Vicente
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8232022
>>>>
>>>> On 11/20/19 6:10 PM, David Holmes wrote:
>>>>> Hi Vicente,
>>>>>
>>>>> Not sure the best mailing list for this review ... jdk-dev may not 
>>>>> be well monitored.
>>>>>
>>>>> Is there a separate review thread for the actual tool removal 
>>>>> (jdk.pack) and build system changes?
>>>>>
>>>>> This removal seems okay, but I found one additional reference:
>>>>>
>>>>> ./src/utils/IdealGraphVisualizer/nbproject/project.properties:auxiliary.org-netbeans-modules-apisupport-installer.pack200-enabled=false 
>>>>>
>>>>>
>>>>> Thanks,
>>>>> David
>>>>> -----
>>>>>
>>>>> On 21/11/2019 8:54 am, Vicente Romero wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I need a reviewer for the changes to remove pack200 and unpack200 
>>>>>> from the JDK. The webrev with the removal is at [1]. This patch is 
>>>>>> the "implementation" of JEP 367 [2]. The patch is basically 
>>>>>> removing the Pack200 related APIs plus its implementation plus any 
>>>>>> reference to it in other tools like `jar`. In the case of `jar`, 
>>>>>> Pack200 was only used if the `-n` flag was passed to the tool. I 
>>>>>> have removed the code that was executed when that flag was passed. 
>>>>>> I have also removed all the tests for Pack200.
>>>>>>
>>>>>> Thanks,
>>>>>> Vicente
>>>>>>
>>>>>> [1] http://cr.openjdk.java.net/~vromero/8234542/webrev.00/
>>>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8232022
>>>>
>>
> 

From david.holmes at oracle.com  Thu Nov 21 01:21:16 2019
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 21 Nov 2019 11:21:16 +1000
Subject: RFR: JEP 367: Remove the Pack200 Tools and API
In-Reply-To: <96643033-bcac-20f3-32d6-3152a6926459@oracle.com>
References: <09dc53f1-9208-3b1f-3ee6-e0e22210afc5@oracle.com>
 <96643033-bcac-20f3-32d6-3152a6926459@oracle.com>
Message-ID: 

Correction ...

On 21/11/2019 9:10 am, David Holmes wrote:
> Hi Vicente,
> 
> Not sure the best mailing list for this review ... jdk-dev may not be 
> well monitored.
> 
> Is there a separate review thread for the actual tool removal (jdk.pack) 

I overlooked the removal of jdk.pack (scrolling too fast through the 
webrev) - apologies.

David
-----

> and build system changes?
> 
> This removal seems okay, but I found one additional reference:
> 
> ./src/utils/IdealGraphVisualizer/nbproject/project.properties:auxiliary.org-netbeans-modules-apisupport-installer.pack200-enabled=false 
> 
> 
> Thanks,
> David
> -----
> 
> On 21/11/2019 8:54 am, Vicente Romero wrote:
>> Hi,
>>
>> I need a reviewer for the changes to remove pack200 and unpack200 from 
>> the JDK. The webrev with the removal is at [1]. This patch is the 
>> "implementation" of JEP 367 [2]. The patch is basically removing the 
>> Pack200 related APIs plus its implementation plus any reference to it 
>> in other tools like `jar`. In the case of `jar`, Pack200 was only used 
>> if the `-n` flag was passed to the tool. I have removed the code that 
>> was executed when that flag was passed. I have also removed all the 
>> tests for Pack200.
>>
>> Thanks,
>> Vicente
>>
>> [1] http://cr.openjdk.java.net/~vromero/8234542/webrev.00/
>> [2] https://bugs.openjdk.java.net/browse/JDK-8232022

From letuyang at amazon.com  Thu Nov 21 05:43:46 2019
From: letuyang at amazon.com (Yang, Letu)
Date: Thu, 21 Nov 2019 05:43:46 +0000
Subject:  Turkish Time Zone name string and translation
In-Reply-To: <95b0ed5b-8e44-7aad-3f64-4bb00c2fa4f5@oracle.com>
References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>
 
 <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com>
 <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com>
 
 <95b0ed5b-8e44-7aad-3f64-4bb00c2fa4f5@oracle.com>
Message-ID: <99070CC7-3197-4E3D-BC25-4CC0A459CBBA@amazon.com>

Hi Naoto,

Thank you for the suggestions!

I've added a new webrev: https://cr.openjdk.java.net/~xliu/8234288/webrev.01/ 

Letu

?On 11/18/19, 9:09 AM, "naoto.sato at oracle.com"  wrote:

    Hi Letu,
    
    Here are my comments to your changes:
    
    - You will need a regression test for this fix. Take a look at 
    test/jdk/sun/text/resources/LocaleDataTest.java, and add appropriate 
    test cases.
    
    - Fix comment should follow the OpenJDK changeset guideline [1]
    
    - As to the change itself, I would put "Turkey Summer Time"/"TRST" for 
    the 3rd and 4th array elements. Even though Turkey time do not observe 
    DST, names in those slots should reflect the DST (consistent to other names)
    
    - time zone id "Turkey" (line 1050) should also point to TRT array.
    
    Naoto
    
    [1] http://openjdk.java.net/guide/producingChangeset.html
    
    On 11/17/19 8:54 PM, Yang, Letu wrote:
    > Hi Naoto,
    > 
    > Thank you for the clarification!
    > 
    > Xin from my team has filed a JBS and uploaded my webrev:
    > https://bugs.openjdk.java.net/browse/JDK-8234288
    > https://cr.openjdk.java.net/~xliu/8234288/webrev.00/
    > 
    > Letu
    > 
    > On 11/16/19, 6:44 AM, "naoto.sato at oracle.com"  wrote:
    > 
    >      Letu,
    >      
    >      Please go ahead and fix the issue in English resource. As to the
    >      translation, Oracle l10n will translate it in appropriate locales.
    >      
    >      Naoto
    >      
    >      On 11/15/19 5:56 PM, Yang, Letu wrote:
    >      > Hi Naoto
    >      >
    >      > Thank you for the quick response! We will file a ticket later today.
    >      >
    >      > Shall we make an effort on fixing and translating the strings, or you
    >      > prefer to take care of it at Oracle?
    >      >
    >      > Letu
    >      >
    >      > On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com wrote:
    >      > Hi Letu,
    >      >
    >      > Please file a JBS issue for this (component: core-libs, subcomponent:
    >      > java.util:i18n).
    >      >
    >      > Naoto
    >      >
    >      > On 11/15/19 3:19 PM, Yang, Letu wrote:
    >      >> Hi,
    >      >>
    >      >> We recently found an issue with the Time Zone name for ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own Turkish Time (TRT) zone in 2016, although the tzdata had been updated, the Time Zone name string has not been updated yet:
    >      >>
    >      >> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836
    >      >>
    >      >> It still returns "Eastern European Time" for the TimeZone.getDisplayName call, which has a summer time while Turkish Time does not. An entry for TRT need to be added to this file, and assign to both "Europe/Istanbul" and "Asian/Istanbul". This also need to  be updated for other locales. I can create a JBS issue for this, but I
    >      > am not sure whether we should fix this bug, or there is an existing
    >      > procedure for this kind of bug which requires language translation.
    >      >>
    >      >> Letu
    >      >>
    >      >>
    >      >>
    >      
    > 
    


From ivan.gerasimov at oracle.com  Thu Nov 21 06:11:28 2019
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 20 Nov 2019 22:11:28 -0800
Subject: RFR 8234423 : More accurate handling of modification counter in
 ArrayList.SubList.Iterator
Message-ID: 

Hello!

When a sublist of a sublist of an ArrayList is created, its modCount is 
initialized from the ArrayList root, and not from its immediate parent.

This means that modifying that 2nd level sublist will reset modCounts of 
the entire chain up to the root, and consequently the 1st level sublist 
won't detect concurrent modification done to the ArrayList root.

Along with the fix, handling of modCount is slightly improved in a few 
other places.

Would you please help review the fix?

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8234423
WEBREV: http://cr.openjdk.java.net/~igerasim/8234423/00/webrev/

-- 
With kind regards,
Ivan Gerasimov


From Alan.Bateman at oracle.com  Thu Nov 21 08:50:31 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 21 Nov 2019 08:50:31 +0000
Subject: RFR: 8234185: Cleanup usage of canonicalize function between
 libjava, hotspot and libinstrument
In-Reply-To: 
References: 
Message-ID: <6209301e-ae85-2a91-7d9e-c9096581365d@oracle.com>

On 14/11/2019 15:37, Langer, Christoph wrote:
> Hi,
>
> please review this cleanup change regarding function "canonicalize" of libjava.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8234185
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234185.0/
>
>
> The goal is to cleanup how this function is defined and used. One thing is, that there was an unnecessary wrapper function "Canonicalize" in jni_util.c. It wrapped the call to "canonicalize". We can get rid of this wrapper. Unfortunately, it is not possible to just export "canonicalize" since this will conflict with a method signature from the math library, at least on modern Linuxes. So I decided to call the method JDK_Canonicalize and will correctly define it in jdk_util.h which can be included everywhere.
>
I think this change is okay. My main concern when initially seeing this 
go by was that it would leak the \\?\ or \\?\UNC\ prefix into the 
canonical File when it wasn't there previously, this would of course 
have several implications. But I think you have it right and this is, as 
you position, just refactoring/cleanup.

-Alan

From matthias.baesken at sap.com  Thu Nov 21 08:54:39 2019
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 21 Nov 2019 08:54:39 +0000
Subject: RFR: 8234525: enable link-time section-gc for linux s390x to remove
 unused code
Message-ID: 

Hello,

gcc and ld can be instructed to work together to "garbage collect" unused input sections.
This feature eliminates unused code from native libraries. As a prerequisite to take full advantage of the feature,
the source files need to be compiled with "-ffunction-sections -fdata-sections".

Details on what happens can be found in the ld documentation: https://linux.die.net/man/1/ld .
See the description of --gc-sections and --print-gc-sections therein.
For more detailed insights there is a talk available from ELC2010: https://elinux.org/images/2/2d/ELC2010-gc-sections_Denys_Vlasenko.pdf

My change enables the unused code elimination on linux s390x .
(on the other Linux platforms, there are still issues to be solved with the serviceability agent, but we do not have the serviceability agent  on linux s390x).

The change has 2 benefits :
- native libs with unused code get smaller (some get alot smaller)
some example lib sizes  from  linuxs390x (product build) :
                    default settings  / link-time gc-sections
libmlib_image.so        556K                 536K
libjavajpeg.so              300K                 292K
libsplashscreen.so      412K                 268K
libfontmanager.so       1.4M                 864K
libjvm.so                        19M                  17M

- the flag --print-gc-sections  outputs the removed sections when calling the linker;
this helps a lot to find coding "waiting for" cross-platform removal.


Here is an example output of --print-gc-sections for the libnet-build (linux s390x) :

/bin/ld: Removing unused section '.bss.my_gconf_init_func' in file '/builddir/support/native/java.base/libnet/DefaultProxySelector.o'  <--- seems to be dead
/bin/ld: Removing unused section '.text.NET_ReadV' in file '/builddir/support/native/java.base/libnet/linux_close.o'                   <--- seems to be dead, I requested cross-platform removal with https://bugs.openjdk.java.net/browse/JDK-8234501
/bin/ld: Removing unused section '.text.getInet6Address_scopeifname' in file '/builddir/support/native/java.base/libnet/net_util.o'    <--- seems to be dead
/bin/ld: Removing unused section '.text.getInet6Address_scopeid_set' in file '/builddir/support/native/java.base/libnet/net_util.o'    <--- seems to be dead
/bin/ld: Removing unused section '.text.getInetAddress_hostName' in file '/builddir/support/native/java.base/libnet/net_util.o'        <--- seems to be dead
/bin/ld: Removing unused section '.text.setDefaultScopeID' in file '/builddir/support/native/java.base/libnet/net_util_md.o'           <--- seems to be dead indeed
/bin/ld: Removing unused section '.text.getDefaultScopeID' in file '/builddir/support/native/java.base/libnet/net_util_md.o'           <--- seems to be dead indeed
/bin/ld: Removing unused section '.text.kernelIsV24' in file '/builddir/support/native/java.base/libnet/net_util_md.o'                 <--- seems to be dead indeed
/bin/ld: Removing unused section '.bss.ni_defaultIndexID.8722' in file '/builddir/support/native/java.base/libnet/net_util_md.o'       <--- only used in getDefaultScopeID , which is dead
/bin/ld: Removing unused section '.bss.ni_class.8721' in file '/builddir/support/native/java.base/libnet/net_util_md.o'                <--- only used in getDefaultScopeID , which is dead
/bin/ld: Removing unused section '.bss.vinit24' in file '/builddir/support/native/java.base/libnet/net_util_md.o'                      <--- only used in kernelIsV24 which is dead
/bin/ld: Removing unused section '.bss.kernelV24' in file '/builddir/support/native/java.base/libnet/net_util_md.o'                    <--- only used in kernelIsV24 which is dead

bug/webrev :
https://bugs.openjdk.java.net/browse/JDK-8234525

http://cr.openjdk.java.net/~mbaesken/webrevs/8234525.1/

Thanks, Matthias



From christoph.langer at sap.com  Thu Nov 21 13:18:57 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 21 Nov 2019 13:18:57 +0000
Subject: RFR: 8234185: Cleanup usage of canonicalize function between
 libjava, hotspot and libinstrument
In-Reply-To: <6209301e-ae85-2a91-7d9e-c9096581365d@oracle.com>
References: 
 <6209301e-ae85-2a91-7d9e-c9096581365d@oracle.com>
Message-ID: 

Hi Alan,

thanks for the review. I'll push it then after running through jdk-submit.

/Christoph

> -----Original Message-----
> From: Alan Bateman 
> Sent: Donnerstag, 21. November 2019 09:51
> To: Langer, Christoph ; core-libs-
> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function between
> libjava, hotspot and libinstrument
> 
> On 14/11/2019 15:37, Langer, Christoph wrote:
> > Hi,
> >
> > please review this cleanup change regarding function "canonicalize" of
> libjava.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8234185
> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234185.0/
> >
> >
> > The goal is to cleanup how this function is defined and used. One thing is,
> that there was an unnecessary wrapper function "Canonicalize" in jni_util.c.
> It wrapped the call to "canonicalize". We can get rid of this wrapper.
> Unfortunately, it is not possible to just export "canonicalize" since this will
> conflict with a method signature from the math library, at least on modern
> Linuxes. So I decided to call the method JDK_Canonicalize and will correctly
> define it in jdk_util.h which can be included everywhere.
> >
> I think this change is okay. My main concern when initially seeing this
> go by was that it would leak the \\?\ or \\?\UNC\ prefix into the
> canonical File when it wasn't there previously, this would of course
> have several implications. But I think you have it right and this is, as
> you position, just refactoring/cleanup.
> 
> -Alan

From chris.hegarty at oracle.com  Thu Nov 21 13:58:55 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 21 Nov 2019 13:58:55 +0000
Subject: JDK14 RFR of JDK-8234381: API docs should mention special
 handling of enums in serialization
In-Reply-To: <76f0b7f6-2ff1-2c40-0d3e-d2551ff485c2@oracle.com>
References: <76f0b7f6-2ff1-2c40-0d3e-d2551ff485c2@oracle.com>
Message-ID: <01DA2CF2-FE45-4A5E-9768-3031B4FA8488@oracle.com>

LGTM Joe.

-Chris.

> On 19 Nov 2019, at 18:21, Joe Darcy  wrote:
> 
> Hello,
> 
> Please review this small doc changes to more explicitly discuss the special handling of enum types by serialization:
> 
>     JDK-8234381: API docs should mention special handling of enums in serialization
>     http://cr.openjdk.java.net/~darcy/8234381.0/
> 
> Patch below; thanks,
> 
> -Joe
> 
> --- old/src/java.base/share/classes/java/io/Serializable.java 2019-11-19 10:17:45.803443000 -0800
> +++ new/src/java.base/share/classes/java/io/Serializable.java 2019-11-19 10:17:45.399241001 -0800
> @@ -134,6 +134,11 @@
>   * This readResolve method follows the same invocation rules and
>   * accessibility rules as writeReplace.

>   *
> + * 
Enum types are all serializable and receive treatment defined by
> + * the Java Object Serialization Specification during
> + * serialization and deserialization. Any declarations of the special
> + * handling methods discussed above are ignored for enum types.
> + *
>   * The serialization runtime associates with each serializable class a version
>   * number, called a serialVersionUID, which is used during deserialization to
>   * verify that the sender and receiver of a serialized object have loaded
> @@ -152,8 +157,9 @@
>   * If a serializable class does not explicitly declare a serialVersionUID, then
>   * the serialization runtime will calculate a default serialVersionUID value
>   * for that class based on various aspects of the class, as described in the
> - * Java(TM) Object Serialization Specification.  However, it is strongly
> - * recommended that all serializable classes explicitly declare
> + * Java Object Serialization Specification.  This specification defines the
> + * serialVersionUID of an enum type to be 0L. However, it is strongly
> + * recommended that all serializable classes other than enum types explicitly declare
>   * serialVersionUID values, since the default serialVersionUID computation is
>   * highly sensitive to class details that may vary depending on compiler
>   * implementations, and can thus result in unexpected
> --- old/src/java.base/share/classes/java/lang/Enum.java 2019-11-19 10:17:46.807945000 -0800
> +++ new/src/java.base/share/classes/java/lang/Enum.java 2019-11-19 10:17:46.371727000 -0800
> @@ -47,6 +47,13 @@
>   * found in section 8.9 of
>   * The Java™ Language Specification.
>   *
> + * Enumeration types are all serializable and receive special handling
> + * by the serialization mechanism. The serialized representation used
> + * for enum constants cannot be customized. Declarations of methods
> + * and fields that would otherwise interact with serialization are
> + * ignored, including {@code serialVersionUID}; see the Java
> + * Object Serialization Specification for details.
> + *
>   * 
 Note that when using an enumeration type as the type of a set
>   * or as the type of the keys in a map, specialized and efficient
>   * {@linkplain java.util.EnumSet set} and {@linkplain
> 


From naoto.sato at oracle.com  Thu Nov 21 17:16:59 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Thu, 21 Nov 2019 09:16:59 -0800
Subject:  Turkish Time Zone name string and translation
In-Reply-To: <99070CC7-3197-4E3D-BC25-4CC0A459CBBA@amazon.com>
References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>
 
 <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com>
 <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com>
 
 <95b0ed5b-8e44-7aad-3f64-4bb00c2fa4f5@oracle.com>
 <99070CC7-3197-4E3D-BC25-4CC0A459CBBA@amazon.com>
Message-ID: <863d66ad-deaf-1ffc-aded-d1485cf8b213@oracle.com>

Hi Letu,

The change in the resource bundle file looks good.

As to the regression test, I would avoid adding a separate file, instead 
add some variations for 
open/test/jdk/sun/text/resources/LocaleDataTest.java as I mentioned. Add 
some lines in "LocaleData" file, which contains the expected resources 
for the COMPAT locale provider.

Naoto

On 11/20/19 9:43 PM, Yang, Letu wrote:
> Hi Naoto,
> 
> Thank you for the suggestions!
> 
> I've added a new webrev: https://cr.openjdk.java.net/~xliu/8234288/webrev.01/
> 
> Letu
> 
> ?On 11/18/19, 9:09 AM, "naoto.sato at oracle.com"  wrote:
> 
>      Hi Letu,
>      
>      Here are my comments to your changes:
>      
>      - You will need a regression test for this fix. Take a look at
>      test/jdk/sun/text/resources/LocaleDataTest.java, and add appropriate
>      test cases.
>      
>      - Fix comment should follow the OpenJDK changeset guideline [1]
>      
>      - As to the change itself, I would put "Turkey Summer Time"/"TRST" for
>      the 3rd and 4th array elements. Even though Turkey time do not observe
>      DST, names in those slots should reflect the DST (consistent to other names)
>      
>      - time zone id "Turkey" (line 1050) should also point to TRT array.
>      
>      Naoto
>      
>      [1] http://openjdk.java.net/guide/producingChangeset.html
>      
>      On 11/17/19 8:54 PM, Yang, Letu wrote:
>      > Hi Naoto,
>      >
>      > Thank you for the clarification!
>      >
>      > Xin from my team has filed a JBS and uploaded my webrev:
>      > https://bugs.openjdk.java.net/browse/JDK-8234288
>      > https://cr.openjdk.java.net/~xliu/8234288/webrev.00/
>      >
>      > Letu
>      >
>      > On 11/16/19, 6:44 AM, "naoto.sato at oracle.com"  wrote:
>      >
>      >      Letu,
>      >
>      >      Please go ahead and fix the issue in English resource. As to the
>      >      translation, Oracle l10n will translate it in appropriate locales.
>      >
>      >      Naoto
>      >
>      >      On 11/15/19 5:56 PM, Yang, Letu wrote:
>      >      > Hi Naoto
>      >      >
>      >      > Thank you for the quick response! We will file a ticket later today.
>      >      >
>      >      > Shall we make an effort on fixing and translating the strings, or you
>      >      > prefer to take care of it at Oracle?
>      >      >
>      >      > Letu
>      >      >
>      >      > On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com wrote:
>      >      > Hi Letu,
>      >      >
>      >      > Please file a JBS issue for this (component: core-libs, subcomponent:
>      >      > java.util:i18n).
>      >      >
>      >      > Naoto
>      >      >
>      >      > On 11/15/19 3:19 PM, Yang, Letu wrote:
>      >      >> Hi,
>      >      >>
>      >      >> We recently found an issue with the Time Zone name for ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own Turkish Time (TRT) zone in 2016, although the tzdata had been updated, the Time Zone name string has not been updated yet:
>      >      >>
>      >      >> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836
>      >      >>
>      >      >> It still returns "Eastern European Time" for the TimeZone.getDisplayName call, which has a summer time while Turkish Time does not. An entry for TRT need to be added to this file, and assign to both "Europe/Istanbul" and "Asian/Istanbul". This also need to  be updated for other locales. I can create a JBS issue for this, but I
>      >      > am not sure whether we should fix this bug, or there is an existing
>      >      > procedure for this kind of bug which requires language translation.
>      >      >>
>      >      >> Letu
>      >      >>
>      >      >>
>      >      >>
>      >
>      >
>      
> 

From vicente.romero at oracle.com  Thu Nov 21 19:53:12 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Thu, 21 Nov 2019 14:53:12 -0500
Subject: RFR: JEP 367: Remove the Pack200 Tools and API
In-Reply-To: 
References: <09dc53f1-9208-3b1f-3ee6-e0e22210afc5@oracle.com>
 <96643033-bcac-20f3-32d6-3152a6926459@oracle.com>
 
Message-ID: <8eccfd0c-04da-dc09-2e1f-a76b61fef519@oracle.com>

Hi,

I think I have covered all the proposed fixes so far. This is the last 
iteration of the webrev [1], all the current changes are in this one, 
the code hasn't been split into different webrevs. I'm also forwarding 
to build-dev as there are some build related changes too. The CSR for 
this change is at [2]

Thanks for all the comment so far,
Vicente

[1] http://cr.openjdk.java.net/~vromero/8234542/webrev.02/
[2] https://bugs.openjdk.java.net/browse/JDK-8234596



On 11/20/19 8:21 PM, David Holmes wrote:
> Correction ...
>
> On 21/11/2019 9:10 am, David Holmes wrote:
>> Hi Vicente,
>>
>> Not sure the best mailing list for this review ... jdk-dev may not be 
>> well monitored.
>>
>> Is there a separate review thread for the actual tool removal (jdk.pack) 
>
> I overlooked the removal of jdk.pack (scrolling too fast through the 
> webrev) - apologies.
>
> David
> -----
>
>> and build system changes?
>>
>> This removal seems okay, but I found one additional reference:
>>
>> ./src/utils/IdealGraphVisualizer/nbproject/project.properties:auxiliary.org-netbeans-modules-apisupport-installer.pack200-enabled=false 
>>
>>
>> Thanks,
>> David
>> -----
>>
>> On 21/11/2019 8:54 am, Vicente Romero wrote:
>>> Hi,
>>>
>>> I need a reviewer for the changes to remove pack200 and unpack200 
>>> from the JDK. The webrev with the removal is at [1]. This patch is 
>>> the "implementation" of JEP 367 [2]. The patch is basically removing 
>>> the Pack200 related APIs plus its implementation plus any reference 
>>> to it in other tools like `jar`. In the case of `jar`, Pack200 was 
>>> only used if the `-n` flag was passed to the tool. I have removed 
>>> the code that was executed when that flag was passed. I have also 
>>> removed all the tests for Pack200.
>>>
>>> Thanks,
>>> Vicente
>>>
>>> [1] http://cr.openjdk.java.net/~vromero/8234542/webrev.00/
>>> [2] https://bugs.openjdk.java.net/browse/JDK-8232022


From christoph.langer at sap.com  Thu Nov 21 22:13:14 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 21 Nov 2019 22:13:14 +0000
Subject: RFR [XS] : 8234339: replace JLI_StrTok in java_md_solinux.c
In-Reply-To: <508aaeaa-5168-da52-2196-f521de1e5931@oracle.com>
References: 
 <508aaeaa-5168-da52-2196-f521de1e5931@oracle.com>
Message-ID: 

+1

> -----Original Message-----
> From: core-libs-dev  On Behalf
> Of Roger Riggs
> Sent: Mittwoch, 20. November 2019 16:08
> To: core-libs-dev at openjdk.java.net
> Subject: Re: RFR [XS] : 8234339: replace JLI_StrTok in java_md_solinux.c
> 
> Hi Matthias,
> 
> Good to see the switch to strtok_r.
> Looks fine.
> 
> Thanks, Roger
> 
> 
> On 11/19/19 4:23 AM, Baesken, Matthias wrote:
> > Hello, please review this small change .
> >
> > JLI_StrTok is only used in one function, so the define can be replaced,
> probably we should use the "safer" strtok_r (the MT safety might not be a
> big deal in the launcher however).
> >
> >
> > Bug/webrev :
> >
> > https://bugs.openjdk.java.net/browse/JDK-8234339
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8234339.0/
> >
> >
> > Thanks, Matthias


From vicente.romero at oracle.com  Thu Nov 21 22:22:40 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Thu, 21 Nov 2019 17:22:40 -0500
Subject: RFR: JEP 367: Remove the Pack200 Tools and API
In-Reply-To: <8eccfd0c-04da-dc09-2e1f-a76b61fef519@oracle.com>
References: <09dc53f1-9208-3b1f-3ee6-e0e22210afc5@oracle.com>
 <96643033-bcac-20f3-32d6-3152a6926459@oracle.com>
 
 <8eccfd0c-04da-dc09-2e1f-a76b61fef519@oracle.com>
Message-ID: <50e49a08-6cfd-3ec5-5474-6c69cfc053cb@oracle.com>

please wait, I found some additional dependencies on module jdk.pack, 
will submit another webrev, sorry

Vicente

On 11/21/19 2:53 PM, Vicente Romero wrote:
> Hi,
>
> I think I have covered all the proposed fixes so far. This is the last 
> iteration of the webrev [1], all the current changes are in this one, 
> the code hasn't been split into different webrevs. I'm also forwarding 
> to build-dev as there are some build related changes too. The CSR for 
> this change is at [2]
>
> Thanks for all the comment so far,
> Vicente
>
> [1] http://cr.openjdk.java.net/~vromero/8234542/webrev.02/
> [2] https://bugs.openjdk.java.net/browse/JDK-8234596
>
>
>
> On 11/20/19 8:21 PM, David Holmes wrote:
>> Correction ...
>>
>> On 21/11/2019 9:10 am, David Holmes wrote:
>>> Hi Vicente,
>>>
>>> Not sure the best mailing list for this review ... jdk-dev may not 
>>> be well monitored.
>>>
>>> Is there a separate review thread for the actual tool removal 
>>> (jdk.pack) 
>>
>> I overlooked the removal of jdk.pack (scrolling too fast through the 
>> webrev) - apologies.
>>
>> David
>> -----
>>
>>> and build system changes?
>>>
>>> This removal seems okay, but I found one additional reference:
>>>
>>> ./src/utils/IdealGraphVisualizer/nbproject/project.properties:auxiliary.org-netbeans-modules-apisupport-installer.pack200-enabled=false 
>>>
>>>
>>> Thanks,
>>> David
>>> -----
>>>
>>> On 21/11/2019 8:54 am, Vicente Romero wrote:
>>>> Hi,
>>>>
>>>> I need a reviewer for the changes to remove pack200 and unpack200 
>>>> from the JDK. The webrev with the removal is at [1]. This patch is 
>>>> the "implementation" of JEP 367 [2]. The patch is basically 
>>>> removing the Pack200 related APIs plus its implementation plus any 
>>>> reference to it in other tools like `jar`. In the case of `jar`, 
>>>> Pack200 was only used if the `-n` flag was passed to the tool. I 
>>>> have removed the code that was executed when that flag was passed. 
>>>> I have also removed all the tests for Pack200.
>>>>
>>>> Thanks,
>>>> Vicente
>>>>
>>>> [1] http://cr.openjdk.java.net/~vromero/8234542/webrev.00/
>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8232022
>


From mandy.chung at oracle.com  Thu Nov 21 22:45:12 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 21 Nov 2019 14:45:12 -0800
Subject: RFR: JEP 367: Remove the Pack200 Tools and API
In-Reply-To: <50e49a08-6cfd-3ec5-5474-6c69cfc053cb@oracle.com>
References: <09dc53f1-9208-3b1f-3ee6-e0e22210afc5@oracle.com>
 <96643033-bcac-20f3-32d6-3152a6926459@oracle.com>
 
 <8eccfd0c-04da-dc09-2e1f-a76b61fef519@oracle.com>
 <50e49a08-6cfd-3ec5-5474-6c69cfc053cb@oracle.com>
Message-ID: <9e3f88da-8fca-1394-19b1-e3a9525eaad6@oracle.com>

CSR needs to mention that jar -n option is removed.? I made minor edit 
to the CSR to state that jdk.pack module is removed.

Mandy

On 11/21/19 2:22 PM, Vicente Romero wrote:
> please wait, I found some additional dependencies on module jdk.pack, 
> will submit another webrev, sorry
>
> Vicente
>
> On 11/21/19 2:53 PM, Vicente Romero wrote:
>> Hi,
>>
>> I think I have covered all the proposed fixes so far. This is the 
>> last iteration of the webrev [1], all the current changes are in this 
>> one, the code hasn't been split into different webrevs. I'm also 
>> forwarding to build-dev as there are some build related changes too. 
>> The CSR for this change is at [2]
>>
>> Thanks for all the comment so far,
>> Vicente
>>
>> [1] http://cr.openjdk.java.net/~vromero/8234542/webrev.02/
>> [2] https://bugs.openjdk.java.net/browse/JDK-8234596
>>
>>
>>
>> On 11/20/19 8:21 PM, David Holmes wrote:
>>> Correction ...
>>>
>>> On 21/11/2019 9:10 am, David Holmes wrote:
>>>> Hi Vicente,
>>>>
>>>> Not sure the best mailing list for this review ... jdk-dev may not 
>>>> be well monitored.
>>>>
>>>> Is there a separate review thread for the actual tool removal 
>>>> (jdk.pack) 
>>>
>>> I overlooked the removal of jdk.pack (scrolling too fast through the 
>>> webrev) - apologies.
>>>
>>> David
>>> -----
>>>
>>>> and build system changes?
>>>>
>>>> This removal seems okay, but I found one additional reference:
>>>>
>>>> ./src/utils/IdealGraphVisualizer/nbproject/project.properties:auxiliary.org-netbeans-modules-apisupport-installer.pack200-enabled=false 
>>>>
>>>>
>>>> Thanks,
>>>> David
>>>> -----
>>>>
>>>> On 21/11/2019 8:54 am, Vicente Romero wrote:
>>>>> Hi,
>>>>>
>>>>> I need a reviewer for the changes to remove pack200 and unpack200 
>>>>> from the JDK. The webrev with the removal is at [1]. This patch is 
>>>>> the "implementation" of JEP 367 [2]. The patch is basically 
>>>>> removing the Pack200 related APIs plus its implementation plus any 
>>>>> reference to it in other tools like `jar`. In the case of `jar`, 
>>>>> Pack200 was only used if the `-n` flag was passed to the tool. I 
>>>>> have removed the code that was executed when that flag was passed. 
>>>>> I have also removed all the tests for Pack200.
>>>>>
>>>>> Thanks,
>>>>> Vicente
>>>>>
>>>>> [1] http://cr.openjdk.java.net/~vromero/8234542/webrev.00/
>>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8232022
>>
>


From christoph.langer at sap.com  Thu Nov 21 23:04:27 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 21 Nov 2019 23:04:27 +0000
Subject: RFR: 8234089: (zipfs) Remove classes JarFileSystemProvider and
 JarFileSystem
In-Reply-To: <97B14E3E-737A-4E31-B878-23D48F076392@oracle.com>
References: 
 <3532D7A1-DF2F-41BF-80BF-09EF53B022B6@oracle.com>
 
 
 <8C407967-F743-4070-B714-52E2056B5E32@oracle.com>
 
 
 
 
 
 <838ae646-93a8-2a17-6c76-97cfd528bc09@oracle.com>
 
 <6006563b-f46b-f0c8-0b83-53628d27287b@oracle.com>
 <97B14E3E-737A-4E31-B878-23D48F076392@oracle.com>
Message-ID: 

Hi Lance,

thanks again. Makes sense to keep comments consistent. So this is what I?m going to push tomorrow: http://cr.openjdk.java.net/~clanger/webrevs/8234089.5/

Cheers
Christoph

From: Lance Andersen 
Sent: Mittwoch, 20. November 2019 19:02
Cc: Langer, Christoph ; nio-dev ; core-libs-dev at openjdk.java.net
Subject: Re: RFR: 8234089: (zipfs) Remove classes JarFileSystemProvider and JarFileSystem

Hi Christoph,

Again, thank you for your efforts here.

Overall I think your latest changes look fine.  I would like to suggest that for the methods that you added for MR support, that we make sure the 1st character in the comment is capitalized prior to your push of the changes.  I know this was not that way prior, but I think it helps with consistency.

BTW,  I am not sure that JarFileSystemProvider was actually ever used(JarFileSystem was though) as when I look at the installed providers on my Mac, I see:

[sun.nio.fs.MacOSXFileSystemProvider at 5b2133b1, jdk.nio.zipfs.ZipFileSystemProvider at 72ea2f77, jdk.internal.jrtfs.JrtFileSystemProvider at 33c7353a]


Best
Lance
On Nov 20, 2019, at 10:02 AM, Alan Bateman > wrote:



On 20/11/2019 13:39, Langer, Christoph wrote:
Hi Alan,

makes sense. I?ve updated the patch: http://cr.openjdk.java.net/~clanger/webrevs/8234089.4/

The updated test looks okay.

-Alan

[cid:image001.gif at 01D5A0C8.666731C0]

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  Thu Nov 21 23:59:06 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 21 Nov 2019 18:59:06 -0500
Subject: RFR [14/java.xml] 8233548: Update CUP to v0.11b
In-Reply-To: <08726be0-44b3-0da8-c839-0e2fe4448091@oracle.com>
References: <08726be0-44b3-0da8-c839-0e2fe4448091@oracle.com>
Message-ID: 

Hi Joe,

Looks OK overall. 

Best
Lance
> On Nov 20, 2019, at 4:48 PM, Joe Wang  wrote:
> 
> Hi,
> 
> Please review an update to Java CUP. This is an effort to move to the latest version, v0.11b. JCUP is used by Xalan to generate XPathParser. Included in the JDK are runtime classes and XPathParser. In CUP 0.11b, the main additions to the runtime were SymbolFactory and ComplexSymbol that were used to report a bit more details (locations) about the parsing process. They were not used by Xalan nor the JDK since the benefit of these additions were in error reporting, but Xalan and JDK used their own reporting mechanism. I could have removed the JCUP error report process altogether, but decided to keep it in case it might be used for debugging.
> 
> The main change for this update therefore is to the XPathParser itself. Since JCUP has been stable, and no major Xalan update in sight, I took the liberty to re-format the whole class, plus some cleanup (mainly boxing/unboxing), that constitute the changes before the inner class parser_actions. Within parser_actions, the main change is that the 0.11b fixed the order of the switch block. Other than that, I removed many unused variables, and also formatted the long lines.
> 
> There were no other material changes. So there's no new test, all existing tests (including JCK) passed.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8233548
> webrevs: http://cr.openjdk.java.net/~joehw/jdk14/8233548/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  Fri Nov 22 00:26:35 2019
From: huizhe.wang at oracle.com (Joe Wang)
Date: Thu, 21 Nov 2019 16:26:35 -0800
Subject: RFR [14/java.xml] 8233548: Update CUP to v0.11b
In-Reply-To: 
References: <08726be0-44b3-0da8-c839-0e2fe4448091@oracle.com>
 
Message-ID: 

Thanks Lance!

-Joe

On 11/21/19 3:59 PM, Lance Andersen wrote:
> Hi Joe,
>
> Looks OK overall.
>
> Best
> Lance
>> On Nov 20, 2019, at 4:48 PM, Joe Wang > > wrote:
>>
>> Hi,
>>
>> Please review an update to Java CUP. This is an effort to move to the 
>> latest version, v0.11b. JCUP is used by Xalan to generate 
>> XPathParser. Included in the JDK are runtime classes and XPathParser. 
>> In CUP 0.11b, the main additions to the runtime were SymbolFactory 
>> and ComplexSymbol that were used to report a bit more details 
>> (locations) about the parsing process. They were not used by Xalan 
>> nor the JDK since the benefit of these additions were in error 
>> reporting, but Xalan and JDK used their own reporting mechanism. I 
>> could have removed the JCUP error report process altogether, but 
>> decided to keep it in case it might be used for debugging.
>>
>> The main change for this update therefore is to the XPathParser 
>> itself. Since JCUP has been stable, and no major Xalan update in 
>> sight, I took the liberty to re-format the whole class, plus some 
>> cleanup (mainly boxing/unboxing), that constitute the changes before 
>> the inner class parser_actions. Within parser_actions, the main 
>> change is that the 0.11b fixed the order of the switch block. Other 
>> than that, I removed many unused variables, and also formatted the 
>> long lines.
>>
>> There were no other material changes. So there's no new test, all 
>> existing tests (including JCK) passed.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8233548
>> webrevs: http://cr.openjdk.java.net/~joehw/jdk14/8233548/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 vicente.romero at oracle.com  Fri Nov 22 02:41:47 2019
From: vicente.romero at oracle.com (Vicente Romero)
Date: Thu, 21 Nov 2019 21:41:47 -0500
Subject: RFR: JEP 367: Remove the Pack200 Tools and API
In-Reply-To: <9e3f88da-8fca-1394-19b1-e3a9525eaad6@oracle.com>
References: <09dc53f1-9208-3b1f-3ee6-e0e22210afc5@oracle.com>
 <96643033-bcac-20f3-32d6-3152a6926459@oracle.com>
 
 <8eccfd0c-04da-dc09-2e1f-a76b61fef519@oracle.com>
 <50e49a08-6cfd-3ec5-5474-6c69cfc053cb@oracle.com>
 <9e3f88da-8fca-1394-19b1-e3a9525eaad6@oracle.com>
Message-ID: 

Hi Mandy,

On 11/21/19 5:45 PM, Mandy Chung wrote:
> CSR needs to mention that jar -n option is removed.? I made minor edit 
> to the CSR to state that jdk.pack module is removed.

thanks for the changes, I added a mention to the jar -n option,

>
> Mandy

Thanks,
Vicente

>
> On 11/21/19 2:22 PM, Vicente Romero wrote:
>> please wait, I found some additional dependencies on module jdk.pack, 
>> will submit another webrev, sorry
>>
>> Vicente
>>
>> On 11/21/19 2:53 PM, Vicente Romero wrote:
>>> Hi,
>>>
>>> I think I have covered all the proposed fixes so far. This is the 
>>> last iteration of the webrev [1], all the current changes are in 
>>> this one, the code hasn't been split into different webrevs. I'm 
>>> also forwarding to build-dev as there are some build related changes 
>>> too. The CSR for this change is at [2]
>>>
>>> Thanks for all the comment so far,
>>> Vicente
>>>
>>> [1] http://cr.openjdk.java.net/~vromero/8234542/webrev.02/
>>> [2] https://bugs.openjdk.java.net/browse/JDK-8234596
>>>
>>>
>>>
>>> On 11/20/19 8:21 PM, David Holmes wrote:
>>>> Correction ...
>>>>
>>>> On 21/11/2019 9:10 am, David Holmes wrote:
>>>>> Hi Vicente,
>>>>>
>>>>> Not sure the best mailing list for this review ... jdk-dev may not 
>>>>> be well monitored.
>>>>>
>>>>> Is there a separate review thread for the actual tool removal 
>>>>> (jdk.pack) 
>>>>
>>>> I overlooked the removal of jdk.pack (scrolling too fast through 
>>>> the webrev) - apologies.
>>>>
>>>> David
>>>> -----
>>>>
>>>>> and build system changes?
>>>>>
>>>>> This removal seems okay, but I found one additional reference:
>>>>>
>>>>> ./src/utils/IdealGraphVisualizer/nbproject/project.properties:auxiliary.org-netbeans-modules-apisupport-installer.pack200-enabled=false 
>>>>>
>>>>>
>>>>> Thanks,
>>>>> David
>>>>> -----
>>>>>
>>>>> On 21/11/2019 8:54 am, Vicente Romero wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I need a reviewer for the changes to remove pack200 and unpack200 
>>>>>> from the JDK. The webrev with the removal is at [1]. This patch 
>>>>>> is the "implementation" of JEP 367 [2]. The patch is basically 
>>>>>> removing the Pack200 related APIs plus its implementation plus 
>>>>>> any reference to it in other tools like `jar`. In the case of 
>>>>>> `jar`, Pack200 was only used if the `-n` flag was passed to the 
>>>>>> tool. I have removed the code that was executed when that flag 
>>>>>> was passed. I have also removed all the tests for Pack200.
>>>>>>
>>>>>> Thanks,
>>>>>> Vicente
>>>>>>
>>>>>> [1] http://cr.openjdk.java.net/~vromero/8234542/webrev.00/
>>>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8232022
>>>
>>
>


From info at j-kuhn.de  Fri Nov 22 03:23:31 2019
From: info at j-kuhn.de (Johannes Kuhn)
Date: Fri, 22 Nov 2019 04:23:31 +0100
Subject: Looking for Sponsor: JDK-8229959 Convert proxy class to use constant
 dynamic
Message-ID: <1391ad74-c3a3-3d91-f8b9-dd2f2cc855b7@j-kuhn.de>

Hi everyone,

a few hours ago I signed the Oracle Contributor Agreement.
I'd like to work on JDK-8229959: Convert proxy class to use constant 
dynamic.

Without further ado, here are some questions and answers you may ask:

* What are you exactly planing to do?
I'd like to replace the GETSTATIC instruction with an LDC instruction in 
the current generated bytecode for the proxies.

* What benefits would such a change have?
First, it allows us to drop the static final fields and the class 
initializer for the generated proxy classes.
Second, it allows the code (both generated and generator) to be more 
clear by moving the essential parts together.
Third, it might bring some performance improvement, because the 
j.l.r.Method lookup is delayed to it's first use - which in some cases 
might never happen.

* Are you able to write such a patch?
Yes. I have some experience with the Java bytecode, ASM and ConstantDynamic.

* But java.lang.reflect.Method is not immutable/persistent?
That's not a question, but you are right. j.l.r.Method has 
setAccessible, modifying the Method instance. Still, the current 
implementation shares the same Method instance with all proxies with the 
same interfaces in the same ClassLoader.

* What should the bootstrap method look like?
The bootstrap method will take one additional argument, a direct 
MethodHandle to the to be resolved method, and should crack it using 
it's passed Lookup and then reflect it as Method. In other words, it 
should do `return lookup.revealDirect(mh).reflectAs(Method.class, lookup);`

*? Where should this bootstrap method reside?
I'm glad you asked. After some thoughts, there are two promising places 
where I could put it:
a) As private static method in the proxy itself.
Benefits: No public API changes. Also allows easy migration to option b) 
if pursued later.
Downsides: The bootstrap method will be duplicated into every proxy class.
b) As a public static method in the java.* namespace, preferably in 
java.lang.invoke.ConstantBootstraps.
Benefits: Only one single implementation in the JVM.
Downside: Changes to the public API. Also leads to other questions like 
"Should j.l.r.Member implement Constable?" and "Should I add a subclass 
of j.l.c.DynamicConstantDesc for this bootstrap method?"
I prefer option a), but I'm fine with both options. Please let me know 
what you think, or if you think of a better way.

* What do I expect from my Sponsor?
I expect my sponsor lo believe that this change will improve the 
OpenJDK. If consensus shows a preference for option b) above (bootstrap 
in j.l.i.ConstantBootstaps), a guidance what requests have to be made 
and where. In that case, I volunteer to write those requests and send 
them to my sponsor, who can (at their sole discretion) forward it to the 
relevant places.

If you have any additional questions, please don't hesitate to answer to 
this mail. I will try to answer all questions to the best of my ability.

With best regards,
Johannes Kuhn


From huaming.li at oracle.com  Fri Nov 22 07:54:14 2019
From: huaming.li at oracle.com (Hamlin Li)
Date: Fri, 22 Nov 2019 15:54:14 +0800
Subject: RFR of JDK-8232446: logging enhancement for rmi when socket closed
In-Reply-To: 
References: <5048d354-a480-ac6d-e46d-a14ce4349691@oracle.com>
 <9db082f9-6e16-9e5e-1d99-280bbd381e8f@gmail.com>
 <50bf13f3-f284-f3f4-1256-8ac51929637b@oracle.com>
 
Message-ID: 

Hi Roger,

Thank you for reviewing, I have updated as you suggested: 
http://cr.openjdk.java.net/~mli/8232446/webrev.01/

Thank you

-Hamlin

On 2019/11/18 11:48 PM, Roger Riggs wrote:
> Hi Hamlin,
>
> TCPConnection.java:212:
>
> Keep the "close connection" logging and add the socket to the same log 
> message:
>
> If anyone is scraping the log, they won't loose this message. 
> TCPTransport.tcpLog.log(Log.BRIEF, "close connection, socket: " + 
> socket);
>
> TCPTransport.java
>
> 277-278:? combine the message to be one logging call.
> server socket
> 289: use Log.BRIEF, avoid creating mixture of and too many log levels.
>
> Reword the log messages so they each begin with "server socket...",
> or "server socket close"...
> it makes it easier to grep for and coorelate related messages
>
> Thanks, Roger
>
>
> On 11/6/19 7:02 AM, Hamlin Li wrote:
>>
>> On 2019/11/6 5:36 PM, Peter Levart wrote:
>>> Hi Hamlin,
>>>
>>> in TCPTransport.decrementExportCount():
>>>
>>> ?283???????????? try {
>>> ?284???????????????? if (tcpLog.isLoggable(Log.BRIEF)) {
>>> ?285???????????????????? tcpLog.log(Log.BRIEF, "close server socket 
>>> on " + ss);
>>> ?286???????????????? }
>>> ?287???????????????? ss.close();
>>> ?288???????????? } catch (IOException e) {
>>> ?289???????????? }
>>>
>>> ...you could add a log statement to the catch block too. Or even 
>>> better, rearrange for IOException to be thrown from that method and 
>>> deal with it in two places:
>>>
>>> - in exportObject() - add it as suppressed exception to exception 
>>> thrown from super.exportObject().
>>> - in targetUnexported() - log it or wrap it into 
>>> UncheckedIOException (depending on what are the callers of 
>>> targetUnexported())
>>>
>>> What do you think?
>> Thanks Peter.
>>
>> I agree. I adopt your first suggestion: add log statement to catch 
>> block, as I think it's simple/straight and sufficient to help diagnose.
>>
>> And I also add log for catch blocks in other close places.
>>
>> The change is updated in place at: 
>> http://cr.openjdk.java.net/~mli/8232446/webrev.00/
>>
>>
>> Thank you
>>
>> -Hamlin
>>
>>>
>>> Regards, Peter
>>>
>>>
>>>
>>> On 11/6/19 3:07 AM, Hamlin Li wrote:
>>>> Would you please review the patch?
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8232446
>>>>
>>>> webrev: http://cr.openjdk.java.net/~mli/8232446/webrev.00/
>>>>
>>>>
>>>> We have some intermittent failures in rmi related to socket 
>>>> closing, this is to add more logging to help diagnose the issues.
>>>>
>>>>
>>>> Thanks you
>>>>
>>>> -Hamlin
>>>>
>>>
>

From Alan.Bateman at oracle.com  Fri Nov 22 08:21:37 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 22 Nov 2019 08:21:37 +0000
Subject: RFR: JEP 367: Remove the Pack200 Tools and API
In-Reply-To: <8eccfd0c-04da-dc09-2e1f-a76b61fef519@oracle.com>
References: <09dc53f1-9208-3b1f-3ee6-e0e22210afc5@oracle.com>
 <96643033-bcac-20f3-32d6-3152a6926459@oracle.com>
 
 <8eccfd0c-04da-dc09-2e1f-a76b61fef519@oracle.com>
Message-ID: <1e68fb03-814b-b671-346e-faa55b068a77@oracle.com>



On 21/11/2019 19:53, Vicente Romero wrote:
> Hi,
>
> I think I have covered all the proposed fixes so far. This is the last 
> iteration of the webrev [1], all the current changes are in this one, 
> the code hasn't been split into different webrevs. I'm also forwarding 
> to build-dev as there are some build related changes too. The CSR for 
> this change is at [2]
Would it be possible to summarize what will remain in 
test/jdk/tools/pack200 after this removal? The webrev makes it looks 
like badattr.jar is being added but since it already exists then I'm not 
sure whether to believe it. pack200-verifier/data/golden.jar is another 
one as it looks like JAR file that is generated by the tests today is 
being checked in, maybe `hg add` in error?

The change to flags-cflag.m4 to add LP64=1 on Windows will need eyes, 
it's not immediately obvious to me which shared code compiled on Windows 
is impacted by this.

-Alan

From matthias.baesken at sap.com  Fri Nov 22 08:39:58 2019
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 22 Nov 2019 08:39:58 +0000
Subject: RFR [XS] : 8234339: replace JLI_StrTok in java_md_solinux.c
In-Reply-To: 
References: 
 <508aaeaa-5168-da52-2196-f521de1e5931@oracle.com>
 
Message-ID: 

Hi Christoph / Roger , thanks for the reviews !

Best regards , Matthias

> -----Original Message-----
> From: Langer, Christoph 
> Sent: Donnerstag, 21. November 2019 23:13
> To: Roger Riggs ; core-libs-
> dev at openjdk.java.net; Baesken, Matthias 
> Subject: RE: RFR [XS] : 8234339: replace JLI_StrTok in java_md_solinux.c
> 
> +1
> 
> > -----Original Message-----
> > From: core-libs-dev  On Behalf
> > Of Roger Riggs
> > Sent: Mittwoch, 20. November 2019 16:08
> > To: core-libs-dev at openjdk.java.net
> > Subject: Re: RFR [XS] : 8234339: replace JLI_StrTok in java_md_solinux.c
> >
> > Hi Matthias,
> >
> > Good to see the switch to strtok_r.
> > Looks fine.
> >
> > Thanks, Roger
> >
> >
> > On 11/19/19 4:23 AM, Baesken, Matthias wrote:
> > > Hello, please review this small change .
> > >
> > > JLI_StrTok is only used in one function, so the define can be replaced,
> > probably we should use the "safer" strtok_r (the MT safety might not be a
> > big deal in the launcher however).
> > >
> > >
> > > Bug/webrev :
> > >
> > > https://bugs.openjdk.java.net/browse/JDK-8234339
> > >
> > > http://cr.openjdk.java.net/~mbaesken/webrevs/8234339.0/
> > >
> > >
> > > Thanks, Matthias


From christoph.langer at sap.com  Fri Nov 22 14:04:38 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 22 Nov 2019 14:04:38 +0000
Subject: RFR: 8234185: Cleanup usage of canonicalize function between
 libjava, hotspot and libinstrument
In-Reply-To: 
References: 
 <6209301e-ae85-2a91-7d9e-c9096581365d@oracle.com>
 
Message-ID: 

Hi,

I'd like to push this change. However, running it through jdk-submit shows reproducible errors:

Job: mach5-one-clanger-JDK-8234185-1-20191122-0927-6913189
BuildId: 2019-11-22-0926373.christoph.langer.source
No failed tests
Tasks Summary
?	NA: 0
?	NOTHING_TO_RUN: 0
?	KILLED: 0
?	PASSED: 76
?	UNABLE_TO_RUN: 0
?	EXECUTED_WITH_FAILURE: 1
?	FAILED: 0
?	HARNESS_ERROR: 0
Build
1 Executed with failure
o	windows-x64-install-windows-x64-build-19 error while building, return value: 2


Job: mach5-one-clanger-JDK-8234185-20191121-2313-6898791
BuildId: 2019-11-21-2311357.christoph.langer.source
No failed tests
Tasks Summary
?	NA: 0
?	NOTHING_TO_RUN: 0
?	KILLED: 0
?	PASSED: 76
?	UNABLE_TO_RUN: 0
?	EXECUTED_WITH_FAILURE: 1
?	FAILED: 0
?	HARNESS_ERROR: 0
Build
1 Executed with failure
o	windows-x64-install-windows-x64-build-19 error while building, return value: 2


David already had a look and let me know that the following was the reason:

t:/workspace/open/src/java.base/windows/native/libjava/canonicalize_md.c(41): fatal error C1083: Cannot open include file: 'jdk_util.h': No such file or directory

This is not explainable to me as I see this running through my local build and our nightly builds without problems. I also can't explain jdk_util.h can't be opened at this place - it should be there and part of the include directories...

I'd appreciate any help...

Thanks
Christoph


> -----Original Message-----
> From: Langer, Christoph
> Sent: Donnerstag, 21. November 2019 14:19
> To: Alan Bateman ; core-libs-
> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
> Subject: RE: RFR: 8234185: Cleanup usage of canonicalize function between
> libjava, hotspot and libinstrument
> 
> Hi Alan,
> 
> thanks for the review. I'll push it then after running through jdk-submit.
> 
> /Christoph
> 
> > -----Original Message-----
> > From: Alan Bateman 
> > Sent: Donnerstag, 21. November 2019 09:51
> > To: Langer, Christoph ; core-libs-
> > dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
> > Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function between
> > libjava, hotspot and libinstrument
> >
> > On 14/11/2019 15:37, Langer, Christoph wrote:
> > > Hi,
> > >
> > > please review this cleanup change regarding function "canonicalize" of
> > libjava.
> > >
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8234185
> > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234185.0/
> > >
> > >
> > > The goal is to cleanup how this function is defined and used. One thing is,
> > that there was an unnecessary wrapper function "Canonicalize" in jni_util.c.
> > It wrapped the call to "canonicalize". We can get rid of this wrapper.
> > Unfortunately, it is not possible to just export "canonicalize" since this will
> > conflict with a method signature from the math library, at least on modern
> > Linuxes. So I decided to call the method JDK_Canonicalize and will correctly
> > define it in jdk_util.h which can be included everywhere.
> > >
> > I think this change is okay. My main concern when initially seeing this
> > go by was that it would leak the \\?\ or \\?\UNC\ prefix into the
> > canonical File when it wasn't there previously, this would of course
> > have several implications. But I think you have it right and this is, as
> > you position, just refactoring/cleanup.
> >
> > -Alan

From erik.joelsson at oracle.com  Fri Nov 22 14:23:00 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 22 Nov 2019 06:23:00 -0800
Subject: RFR: 8234525: enable link-time section-gc for linux s390x to
 remove unused code
In-Reply-To: 
References: 
Message-ID: 

Hello Matthias,

This looks like an interesting change. If you want to enable this for 
s390x, I'm ok with it. If it works out well, perhaps we can find a way 
to expand this to other architectures.

Do you really want to set --print-gc-sections by default? I would assume 
that makes the build quite chatty.

/Erik

On 2019-11-21 00:54, Baesken, Matthias wrote:
> Hello,
>
> gcc and ld can be instructed to work together to "garbage collect" unused input sections.
> This feature eliminates unused code from native libraries. As a prerequisite to take full advantage of the feature,
> the source files need to be compiled with "-ffunction-sections -fdata-sections".
>
> Details on what happens can be found in the ld documentation: https://linux.die.net/man/1/ld .
> See the description of --gc-sections and --print-gc-sections therein.
> For more detailed insights there is a talk available from ELC2010: https://elinux.org/images/2/2d/ELC2010-gc-sections_Denys_Vlasenko.pdf
>
> My change enables the unused code elimination on linux s390x .
> (on the other Linux platforms, there are still issues to be solved with the serviceability agent, but we do not have the serviceability agent  on linux s390x).
>
> The change has 2 benefits :
> - native libs with unused code get smaller (some get alot smaller)
> some example lib sizes  from  linuxs390x (product build) :
>                      default settings  / link-time gc-sections
> libmlib_image.so        556K                 536K
> libjavajpeg.so              300K                 292K
> libsplashscreen.so      412K                 268K
> libfontmanager.so       1.4M                 864K
> libjvm.so                        19M                  17M
>
> - the flag --print-gc-sections  outputs the removed sections when calling the linker;
> this helps a lot to find coding "waiting for" cross-platform removal.
>
>
> Here is an example output of --print-gc-sections for the libnet-build (linux s390x) :
>
> /bin/ld: Removing unused section '.bss.my_gconf_init_func' in file '/builddir/support/native/java.base/libnet/DefaultProxySelector.o'  <--- seems to be dead
> /bin/ld: Removing unused section '.text.NET_ReadV' in file '/builddir/support/native/java.base/libnet/linux_close.o'                   <--- seems to be dead, I requested cross-platform removal with https://bugs.openjdk.java.net/browse/JDK-8234501
> /bin/ld: Removing unused section '.text.getInet6Address_scopeifname' in file '/builddir/support/native/java.base/libnet/net_util.o'    <--- seems to be dead
> /bin/ld: Removing unused section '.text.getInet6Address_scopeid_set' in file '/builddir/support/native/java.base/libnet/net_util.o'    <--- seems to be dead
> /bin/ld: Removing unused section '.text.getInetAddress_hostName' in file '/builddir/support/native/java.base/libnet/net_util.o'        <--- seems to be dead
> /bin/ld: Removing unused section '.text.setDefaultScopeID' in file '/builddir/support/native/java.base/libnet/net_util_md.o'           <--- seems to be dead indeed
> /bin/ld: Removing unused section '.text.getDefaultScopeID' in file '/builddir/support/native/java.base/libnet/net_util_md.o'           <--- seems to be dead indeed
> /bin/ld: Removing unused section '.text.kernelIsV24' in file '/builddir/support/native/java.base/libnet/net_util_md.o'                 <--- seems to be dead indeed
> /bin/ld: Removing unused section '.bss.ni_defaultIndexID.8722' in file '/builddir/support/native/java.base/libnet/net_util_md.o'       <--- only used in getDefaultScopeID , which is dead
> /bin/ld: Removing unused section '.bss.ni_class.8721' in file '/builddir/support/native/java.base/libnet/net_util_md.o'                <--- only used in getDefaultScopeID , which is dead
> /bin/ld: Removing unused section '.bss.vinit24' in file '/builddir/support/native/java.base/libnet/net_util_md.o'                      <--- only used in kernelIsV24 which is dead
> /bin/ld: Removing unused section '.bss.kernelV24' in file '/builddir/support/native/java.base/libnet/net_util_md.o'                    <--- only used in kernelIsV24 which is dead
>
> bug/webrev :
> https://bugs.openjdk.java.net/browse/JDK-8234525
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8234525.1/
>
> Thanks, Matthias
>
>

From matthias.baesken at sap.com  Fri Nov 22 15:00:41 2019
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 22 Nov 2019 15:00:41 +0000
Subject: RFR: 8234525: enable link-time section-gc for linux s390x to
 remove unused code
In-Reply-To: 
References: 
 
Message-ID: 

Hi Erik, 
   yes it makes the build more chatty -
our   linux s390   product   build  log  of  jdk/jdk   goes from  ~ 60.000  lines to  ~ 123.000  lines with the patch. 

However the change  is  linux s390 only so I guess it will not disturb other people ( in case we bring it to more platforms later on, we could remove the printing or make it configurable ).

Additionally the "chatty" output  is used currently for eliminating   unused  functions + data    cross-platform  
(see for example   https://bugs.openjdk.java.net/browse/JDK-8234629  ).

Best regards, Matthias



> 
> Hello Matthias,
> 
> This looks like an interesting change. If you want to enable this for
> s390x, I'm ok with it. If it works out well, perhaps we can find a way
> to expand this to other architectures.
> 
> Do you really want to set --print-gc-sections by default? I would assume
> that makes the build quite chatty.
> 
> /Erik
> 
> On 2019-11-21 00:54, Baesken, Matthias wrote:
> > Hello,
> >
> > gcc and ld can be instructed to work together to "garbage collect" unused
> input sections.
> > This feature eliminates unused code from native libraries. As a prerequisite
> to take full advantage of the feature,
> > the source files need to be compiled with "-ffunction-sections -fdata-
> sections".
> >
> > Details on what happens can be found in the ld documentation:
> https://linux.die.net/man/1/ld .
> > See the description of --gc-sections and --print-gc-sections therein.
> > For more detailed insights there is a talk available from ELC2010:
> https://elinux.org/images/2/2d/ELC2010-gc-sections_Denys_Vlasenko.pdf
> >
> > My change enables the unused code elimination on linux s390x .
> > (on the other Linux platforms, there are still issues to be solved with the
> serviceability agent, but we do not have the serviceability agent  on linux
> s390x).
> >
> > The change has 2 benefits :
> > - native libs with unused code get smaller (some get alot smaller)
> > some example lib sizes  from  linuxs390x (product build) :
> >                      default settings  / link-time gc-sections
> > libmlib_image.so        556K                 536K
> > libjavajpeg.so              300K                 292K
> > libsplashscreen.so      412K                 268K
> > libfontmanager.so       1.4M                 864K
> > libjvm.so                        19M                  17M
> >
> > - the flag --print-gc-sections  outputs the removed sections when calling
> the linker;
> > this helps a lot to find coding "waiting for" cross-platform removal.
> >
> >
> > Here is an example output of --print-gc-sections for the libnet-build (linux
> s390x) :
> >
> > /bin/ld: Removing unused section '.bss.my_gconf_init_func' in file
> '/builddir/support/native/java.base/libnet/DefaultProxySelector.o'  <---
> seems to be dead
> > /bin/ld: Removing unused section '.text.NET_ReadV' in file
> '/builddir/support/native/java.base/libnet/linux_close.o'                   <--- seems
> to be dead, I requested cross-platform removal with
> https://bugs.openjdk.java.net/browse/JDK-8234501
> > /bin/ld: Removing unused section '.text.getInet6Address_scopeifname' in
> file '/builddir/support/native/java.base/libnet/net_util.o'    <--- seems to be
> dead
> > /bin/ld: Removing unused section '.text.getInet6Address_scopeid_set' in
> file '/builddir/support/native/java.base/libnet/net_util.o'    <--- seems to be
> dead
> > /bin/ld: Removing unused section '.text.getInetAddress_hostName' in file
> '/builddir/support/native/java.base/libnet/net_util.o'        <--- seems to be
> dead
> > /bin/ld: Removing unused section '.text.setDefaultScopeID' in file
> '/builddir/support/native/java.base/libnet/net_util_md.o'           <--- seems to
> be dead indeed
> > /bin/ld: Removing unused section '.text.getDefaultScopeID' in file
> '/builddir/support/native/java.base/libnet/net_util_md.o'           <--- seems to
> be dead indeed
> > /bin/ld: Removing unused section '.text.kernelIsV24' in file
> '/builddir/support/native/java.base/libnet/net_util_md.o'                 <---
> seems to be dead indeed
> > /bin/ld: Removing unused section '.bss.ni_defaultIndexID.8722' in file
> '/builddir/support/native/java.base/libnet/net_util_md.o'       <--- only used
> in getDefaultScopeID , which is dead
> > /bin/ld: Removing unused section '.bss.ni_class.8721' in file
> '/builddir/support/native/java.base/libnet/net_util_md.o'                <--- only
> used in getDefaultScopeID , which is dead
> > /bin/ld: Removing unused section '.bss.vinit24' in file
> '/builddir/support/native/java.base/libnet/net_util_md.o'                      <---
> only used in kernelIsV24 which is dead
> > /bin/ld: Removing unused section '.bss.kernelV24' in file
> '/builddir/support/native/java.base/libnet/net_util_md.o'                    <--- only
> used in kernelIsV24 which is dead
> >
> > bug/webrev :
> > https://bugs.openjdk.java.net/browse/JDK-8234525
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8234525.1/
> >
> > Thanks, Matthias
> >
> >

From brian.burkhalter at oracle.com  Fri Nov 22 17:40:46 2019
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 22 Nov 2019 09:40:46 -0800
Subject: 8179320: File.getUsableSpace() returns a negative number on very
 large file system
References: 
Message-ID: 

PING!

> Begin forwarded message:
> 
> From: Brian Burkhalter 
> Subject: Re: 8179320: File.getUsableSpace() returns a negative number on very large file system
> Date: November 15, 2019 at 2:40:06 PM PST
> To: Alan Bateman 
> Cc: Core-Libs-Dev 
> 
> 
>> On Nov 15, 2019, at 2:59 AM, Alan Bateman > wrote:
>> 
>> On 02/11/2019 00:13, Brian Burkhalter wrote:
>>> For this issue [1], please review this patch [2] and the corresponding CSR [3].
>>> 
>>> 
>> One thing that isn't clear is how these methods behave when the space info can't be obtained. It is specified to return 0L when the path is not "a partition" but I think it also returns 0L when the information cannot be obtained.
> 
> I?ve updated the patch [1] to address this. The difference versus webrev.00 is [2].
> 
> Thanks,
> 
> Brian
> 
> [1] http://cr.openjdk.java.net/~bpb/8179320/webrev.01/ [2] diff vs. webrev.00
> 
> --- a/src/java.base/share/classes/java/io/File.java
> +++ b/src/java.base/share/classes/java/io/File.java
> @@ -1804,7 +1804,8 @@
>       * returned.
>       *
>       * @return  The size, in bytes, of the partition or {@code 0L} if this
> -     *          abstract pathname does not name a partition
> +     *          abstract pathname does not name a partition or if the size
> +     *          cannot be obtained
>       *
>       * @throws  SecurityException
>       *          If a security manager has been installed and it denies
> @@ -1844,9 +1845,10 @@
>       * will succeed.
>       *
>       * @return  The number of unallocated bytes on the partition or {@code 0L}
> -     *          if the abstract pathname does not name a partition.  This
> -     *          value will be less than or equal to the total file system size
> -     *          returned by {@link #getTotalSpace}.
> +     *          if the abstract pathname does not name a partition or if this
> +     *          number cannot be obtained.  This value will be less than or
> +     *          equal to the total file system size returned by
> +     *          {@link #getTotalSpace}.
>       *
>       * @throws  SecurityException
>       *          If a security manager has been installed and it denies
> @@ -1889,9 +1891,10 @@
>       * to this file system will succeed.
>       *
>       * @return  The number of available bytes on the partition or {@code 0L}
> -     *          if the abstract pathname does not name a partition.  On
> -     *          systems where this information is not available, this method
> -     *          will be equivalent to a call to {@link #getFreeSpace}.
> +     *          if the abstract pathname does not name a partition or if this
> +     *          number cannot be obtained.  On systems where this information
> +     *          is not available, this method will be equivalent to a call to
> +     *          {@link #getFreeSpace}.
>       *
>       * @throws  SecurityException
>       *          If a security manager has been installed and it denies


From mandy.chung at oracle.com  Fri Nov 22 19:17:48 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 22 Nov 2019 11:17:48 -0800
Subject: (XS) RFR JDK-8233956: MethodHandles.dropArguments javadoc lists
 parameters in wrong order
Message-ID: 

This patch reorders `@param pos` of MethodHandles.dropArguments matching 
the method signature.

It'd be nice if javadoc generates with the ordered list of @params 
matching the method signature (I created JDK-8234682).

diff --git 
a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java 
b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java
--- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java
+++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java
@@ -4286,8 +4286,8 @@
 ????? * {@link #dropArguments(MethodHandle,int,Class...) 
dropArguments}{@code (target, pos, valueTypes.toArray(new Class[0]))}
 ????? * 

 ????? * @param target the method handle to invoke after the arguments 
are dropped
+???? * @param pos position of first argument to drop (zero for the 
leftmost)
 ????? * @param valueTypes the type(s) of the argument(s) to drop
-???? * @param pos position of first argument to drop (zero for the 
leftmost)
 ????? * @return a method handle which drops arguments of the given types,
 ????? *???????? before calling the original method handle
 ????? * @throws NullPointerException if the target is null,
@@ -4366,8 +4366,8 @@
 ????? * {@link #dropArguments(MethodHandle,int,List) 
dropArguments}{@code (target, pos, Arrays.asList(valueTypes))}
 ????? *
????? * @param target the method handle to invoke after the arguments are dropped +???? * @param pos position of first argument to drop (zero for the leftmost) ????? * @param valueTypes the type(s) of the argument(s) to drop -???? * @param pos position of first argument to drop (zero for the leftmost) ????? * @return a method handle which drops arguments of the given types, ????? *???????? before calling the original method handle ????? * @throws NullPointerException if the target is null, Mandy From jonathan.gibbons at oracle.com Fri Nov 22 19:26:03 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 22 Nov 2019 11:26:03 -0800 Subject: (XS) RFR JDK-8233956: MethodHandles.dropArguments javadoc lists parameters in wrong order In-Reply-To: References: Message-ID: <183b2763-a310-bc8c-b425-b021fb6a7ba7@oracle.com> Looks good to me. -- Jon On 11/22/19 11:17 AM, Mandy Chung wrote: > This patch reorders `@param pos` of MethodHandles.dropArguments > matching the method signature. > > It'd be nice if javadoc generates with the ordered list of @params > matching the method signature (I created JDK-8234682). > > diff --git > a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java > b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java > --- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java > +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java > @@ -4286,8 +4286,8 @@ > ????? * {@link #dropArguments(MethodHandle,int,Class...) > dropArguments}{@code (target, pos, valueTypes.toArray(new Class[0]))} > ????? * > ????? * @param target the method handle to invoke after the arguments > are dropped > +???? * @param pos position of first argument to drop (zero for the > leftmost) > ????? * @param valueTypes the type(s) of the argument(s) to drop > -???? * @param pos position of first argument to drop (zero for the > leftmost) > ????? * @return a method handle which drops arguments of the given types, > ????? *???????? before calling the original method handle > ????? * @throws NullPointerException if the target is null, > @@ -4366,8 +4366,8 @@ > ????? * {@link #dropArguments(MethodHandle,int,List) > dropArguments}{@code (target, pos, Arrays.asList(valueTypes))} > ????? * > ????? * @param target the method handle to invoke after the arguments > are dropped > +???? * @param pos position of first argument to drop (zero for the > leftmost) > ????? * @param valueTypes the type(s) of the argument(s) to drop > -???? * @param pos position of first argument to drop (zero for the > leftmost) > ????? * @return a method handle which drops arguments of the given types, > ????? *???????? before calling the original method handle > ????? * @throws NullPointerException if the target is null, > > Mandy From mandy.chung at oracle.com Fri Nov 22 19:29:53 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 22 Nov 2019 11:29:53 -0800 Subject: (XS) RFR JDK-8233956: MethodHandles.dropArguments javadoc lists parameters in wrong order In-Reply-To: <183b2763-a310-bc8c-b425-b021fb6a7ba7@oracle.com> References: <183b2763-a310-bc8c-b425-b021fb6a7ba7@oracle.com> Message-ID: <852d8840-524d-b2c9-6c61-5a0018a1f46e@oracle.com> Thanks for the prompt review. Mandy On 11/22/19 11:26 AM, Jonathan Gibbons wrote: > Looks good to me. > > -- Jon > > On 11/22/19 11:17 AM, Mandy Chung wrote: >> This patch reorders `@param pos` of MethodHandles.dropArguments >> matching the method signature. >> >> It'd be nice if javadoc generates with the ordered list of @params >> matching the method signature (I created JDK-8234682). >> >> diff --git >> a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java >> b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java >> --- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java >> +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java >> @@ -4286,8 +4286,8 @@ >> ????? * {@link #dropArguments(MethodHandle,int,Class...) >> dropArguments}{@code (target, pos, valueTypes.toArray(new Class[0]))} >> ????? * >> ????? * @param target the method handle to invoke after the arguments >> are dropped >> +???? * @param pos position of first argument to drop (zero for the >> leftmost) >> ????? * @param valueTypes the type(s) of the argument(s) to drop >> -???? * @param pos position of first argument to drop (zero for the >> leftmost) >> ????? * @return a method handle which drops arguments of the given >> types, >> ????? *???????? before calling the original method handle >> ????? * @throws NullPointerException if the target is null, >> @@ -4366,8 +4366,8 @@ >> ????? * {@link #dropArguments(MethodHandle,int,List) >> dropArguments}{@code (target, pos, Arrays.asList(valueTypes))} >> ????? * >> ????? * @param target the method handle to invoke after the arguments >> are dropped >> +???? * @param pos position of first argument to drop (zero for the >> leftmost) >> ????? * @param valueTypes the type(s) of the argument(s) to drop >> -???? * @param pos position of first argument to drop (zero for the >> leftmost) >> ????? * @return a method handle which drops arguments of the given >> types, >> ????? *???????? before calling the original method handle >> ????? * @throws NullPointerException if the target is null, >> >> Mandy From brent.christian at oracle.com Fri Nov 22 19:42:13 2019 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 22 Nov 2019 11:42:13 -0800 Subject: Class-Path (in jar file) semantics different between Java 11 and 13 (on Windows)? In-Reply-To: References: <15bf7cd7-8549-8266-a460-1d0bb4359f84@gmail.com> Message-ID: <46dfc31a-3615-b18f-fa2f-77573ba6aa25@oracle.com> Hi, Jaikiran On 11/18/2019 7:56 AM, Jaikiran Pai wrote: > The actual code which does this construction, resides here[2] . I see at [3] that '/' is prepended to the path. As Alan suggested [4], prepending with "file:/" ought to get it working. -Brent 2. https://github.com/quarkusio/quarkus/blob/master/devtools/maven/src/main/java/io/quarkus/maven/DevMojo.java#L390 3. https://github.com/quarkusio/quarkus/blob/master/devtools/maven/src/main/java/io/quarkus/maven/DevMojo.java#L393 4. https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-November/063552.html From brian.goetz at oracle.com Fri Nov 22 19:52:21 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 22 Nov 2019 14:52:21 -0500 Subject: Looking for Sponsor: JDK-8229959 Convert proxy class to use constant dynamic In-Reply-To: <1391ad74-c3a3-3d91-f8b9-dd2f2cc855b7@j-kuhn.de> References: <1391ad74-c3a3-3d91-f8b9-dd2f2cc855b7@j-kuhn.de> Message-ID: <1062d391-5200-9b2f-6ecf-0fd3a6ea1614@oracle.com> For those that are not intimately familiar with the mechanics of proxy class generation, it would be great to flesh this out with a code example, that shows the proposed old and new translation. This would make it easier for folks to evaluate the benefits and costs of the approach, and possibly suggest improvements. On 11/21/2019 10:23 PM, Johannes Kuhn wrote: > > * What benefits would such a change have? > First, it allows us to drop the static final fields and the class > initializer for the generated proxy classes. > Second, it allows the code (both generated and generator) to be more > clear by moving the essential parts together. > Third, it might bring some performance improvement, because the > j.l.r.Method lookup is delayed to it's first use - which in some cases > might never happen. From Roger.Riggs at oracle.com Fri Nov 22 20:49:47 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 22 Nov 2019 15:49:47 -0500 Subject: 8179320: File.getUsableSpace() returns a negative number on very large file system In-Reply-To: References: Message-ID: <9b6cf270-658f-3a27-c3d7-4310694795d6@oracle.com> Hi Brian, The updated wording looks fine. Roger On 11/22/19 12:40 PM, Brian Burkhalter wrote: > PING! > >> Begin forwarded message: >> >> From: Brian Burkhalter >> Subject: Re: 8179320: File.getUsableSpace() returns a negative number on very large file system >> Date: November 15, 2019 at 2:40:06 PM PST >> To: Alan Bateman >> Cc: Core-Libs-Dev >> >> >>> On Nov 15, 2019, at 2:59 AM, Alan Bateman > wrote: >>> >>> On 02/11/2019 00:13, Brian Burkhalter wrote: >>>> For this issue [1], please review this patch [2] and the corresponding CSR [3]. >>>> >>>> >>> One thing that isn't clear is how these methods behave when the space info can't be obtained. It is specified to return 0L when the path is not "a partition" but I think it also returns 0L when the information cannot be obtained. >> I?ve updated the patch [1] to address this. The difference versus webrev.00 is [2]. >> >> Thanks, >> >> Brian >> >> [1] http://cr.openjdk.java.net/~bpb/8179320/webrev.01/ [2] diff vs. webrev.00 >> >> --- a/src/java.base/share/classes/java/io/File.java >> +++ b/src/java.base/share/classes/java/io/File.java >> @@ -1804,7 +1804,8 @@ >> * returned. >> * >> * @return The size, in bytes, of the partition or {@code 0L} if this >> - * abstract pathname does not name a partition >> + * abstract pathname does not name a partition or if the size >> + * cannot be obtained >> * >> * @throws SecurityException >> * If a security manager has been installed and it denies >> @@ -1844,9 +1845,10 @@ >> * will succeed. >> * >> * @return The number of unallocated bytes on the partition or {@code 0L} >> - * if the abstract pathname does not name a partition. This >> - * value will be less than or equal to the total file system size >> - * returned by {@link #getTotalSpace}. >> + * if the abstract pathname does not name a partition or if this >> + * number cannot be obtained. This value will be less than or >> + * equal to the total file system size returned by >> + * {@link #getTotalSpace}. >> * >> * @throws SecurityException >> * If a security manager has been installed and it denies >> @@ -1889,9 +1891,10 @@ >> * to this file system will succeed. >> * >> * @return The number of available bytes on the partition or {@code 0L} >> - * if the abstract pathname does not name a partition. On >> - * systems where this information is not available, this method >> - * will be equivalent to a call to {@link #getFreeSpace}. >> + * if the abstract pathname does not name a partition or if this >> + * number cannot be obtained. On systems where this information >> + * is not available, this method will be equivalent to a call to >> + * {@link #getFreeSpace}. >> * >> * @throws SecurityException >> * If a security manager has been installed and it denies From info at j-kuhn.de Fri Nov 22 21:27:11 2019 From: info at j-kuhn.de (Johannes Kuhn) Date: Fri, 22 Nov 2019 22:27:11 +0100 Subject: Looking for Sponsor: JDK-8229959 Convert proxy class to use constant dynamic In-Reply-To: <1062d391-5200-9b2f-6ecf-0fd3a6ea1614@oracle.com> References: <1391ad74-c3a3-3d91-f8b9-dd2f2cc855b7@j-kuhn.de> <1062d391-5200-9b2f-6ecf-0fd3a6ea1614@oracle.com> Message-ID: On 22.11.2019 20:52, Brian Goetz wrote: > For those that are not intimately familiar with the mechanics of proxy > class generation, it would be great to flesh this out with a code > example, that shows the proposed old and new translation. This would > make it easier for folks to evaluate the benefits and costs of the > approach, and possibly suggest improvements. > > On 11/21/2019 10:23 PM, Johannes Kuhn wrote: >> >> * What benefits would such a change have? >> First, it allows us to drop the static final fields and the class >> initializer for the generated proxy classes. >> Second, it allows the code (both generated and generator) to be more >> clear by moving the essential parts together. >> Third, it might bring some performance improvement, because the >> j.l.r.Method lookup is delayed to it's first use - which in some >> cases might never happen. > Thanks for the suggestion. A proxy can be used to create an implementation of one or more interfaces at run time. I just let Java 13 dump a generated Proxy and decompiled it using JD. This is the result: packagecom.sun.proxy; //imports...; publicfinalclass$Proxy0extendsProxyimplementsRunnable{ privatestaticMethodm1; privatestaticMethodm3; privatestaticMethodm2; privatestaticMethodm0; public$Proxy0(InvocationHandlerparamInvocationHandler){super(paramInvocationHandler);} publicfinalbooleanequals(ObjectparamObject){ try{ return((Boolean)this.h.invoke(this,m1,newObject[]{paramObject})).booleanValue(); }catch(Error|RuntimeExceptionerror){ throwerror; }catch(Throwablethrowable){ thrownewUndeclaredThrowableException(throwable); } } publicfinalvoidrun(){ try{ this.h.invoke(this,m3,null); return; }catch(Error|RuntimeExceptionerror){ throwerror; }catch(Throwablethrowable){ thrownewUndeclaredThrowableException(throwable); } } publicfinalStringtoString(){ try{ return(String)this.h.invoke(this,m2,null); }catch(Error|RuntimeExceptionerror){ throwerror; }catch(Throwablethrowable){ thrownewUndeclaredThrowableException(throwable); } } publicfinalinthashCode(){ try{ return((Integer)this.h.invoke(this,m0,null)).intValue(); }catch(Error|RuntimeExceptionerror){ throwerror; }catch(Throwablethrowable){ thrownewUndeclaredThrowableException(throwable); } } static{ try{ m1=Class.forName("java.lang.Object").getMethod("equals",newClass[]{Class.forName("java.lang.Object")}); m3=Class.forName("java.lang.Runnable").getMethod("run",newClass[0]); m2=Class.forName("java.lang.Object").getMethod("toString",newClass[0]); m0=Class.forName("java.lang.Object").getMethod("hashCode",newClass[0]); return; }catch(NoSuchMethodExceptionnoSuchMethodException){ thrownewNoSuchMethodError(noSuchMethodException.getMessage()); }catch(ClassNotFoundExceptionclassNotFoundException){ thrownewNoClassDefFoundError(classNotFoundException.getMessage()); } } } The new implementation using ASM generates a similar class. I intend to replace the the references to m0, m1... in the generated code through an LDC instruction, and remove the code that generates the fields and the static class initializer. The resulting code would look a something like this: packagecom.sun.proxy; //imports...; publicfinalclass$Proxy0extendsProxyimplementsRunnable{ public$Proxy0(InvocationHandlerparamInvocationHandler){super(paramInvocationHandler);} publicfinalbooleanequals(ObjectparamObject){ try{ return((Boolean)this.h.invoke(this,__LDC(__MethodHandle (com.sun.proxy.$Proxy0::$bootstap, "_", Method.class, __MethodHandle(java.lang.Object::equals)),newObject[]{paramObject})).booleanValue(); }catch(Error|RuntimeExceptionerror){ throwerror; }catch(Throwablethrowable){ thrownewUndeclaredThrowableException(throwable); } } // repeat for run(), hashCode() and equals(Object other) private static final Method $bootstrap(Lookup lookup, String ignored, Class clazz, MethodHandle mh) { return lookup.revealDirect(mh).reflectAs(clazz, lookup); } } I used __LDC as placeholder for the LDC bytecode instruction (limited to constant dynamic), and __MethodHandle for a MethodHandle in the constant pool. This means the Method is only looked up when the proxy method is called for the first time. In the actual source code (the generating code), it means that the following methods can be dropped: ProxyGenerator.generateStaticInitializer() https://hg.openjdk.java.net/jdk/jdk/file/a2a921609481/src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java#l576 ProxyGenerator.ProxyMethod.codeFieldInitialization(MethodVisitor, String) https://hg.openjdk.java.net/jdk/jdk/file/a2a921609481/src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java#l576 It will require the addition of a new method, which creates the $bootstrap method, and a change ProxyGenerator.ProxyMethod.generateMethod to emit an LDC instruction instead of a GETSTATIC. The next step is to remove the now unused ProxyMethod.methodFieldName and it's dependencies (constructor, their calls...), but this should be a fairly natural change. After all those changes, I assume that I will delete more code than I will add and change. Also, as suggested in my last mail, the bootstrap method doesn't need to be in the generated proxy class, it just needs to be accessible from the generated proxy classes (which can be in any module). Remi Forax suggested to put it in the java.lang.invoke.ConstantBootstraps in his initial proposal[1] - but this means it would be a public API. Using a private method avoids that, at some low cost, and changing to an external bootstrap method later would be a small change. [1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/061923.html From vicente.romero at oracle.com Fri Nov 22 21:30:42 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 22 Nov 2019 16:30:42 -0500 Subject: RFR: JEP 367: Remove the Pack200 Tools and API In-Reply-To: <1e68fb03-814b-b671-346e-faa55b068a77@oracle.com> References: <09dc53f1-9208-3b1f-3ee6-e0e22210afc5@oracle.com> <96643033-bcac-20f3-32d6-3152a6926459@oracle.com> <8eccfd0c-04da-dc09-2e1f-a76b61fef519@oracle.com> <1e68fb03-814b-b671-346e-faa55b068a77@oracle.com> Message-ID: <8fe0abd5-f154-292b-25fc-0bc907633037@oracle.com> Hi all, On 11/22/19 3:21 AM, Alan Bateman wrote: > > > On 21/11/2019 19:53, Vicente Romero wrote: >> Hi, >> >> I think I have covered all the proposed fixes so far. This is the >> last iteration of the webrev [1], all the current changes are in this >> one, the code hasn't been split into different webrevs. I'm also >> forwarding to build-dev as there are some build related changes too. >> The CSR for this change is at [2] > Would it be possible to summarize what will remain in > test/jdk/tools/pack200 after this removal? The webrev makes it looks > like badattr.jar is being added but since it already exists then I'm > not sure whether to believe it. pack200-verifier/data/golden.jar is > another one as it looks like JAR file that is generated by the tests > today is being checked in, maybe `hg add` in error? I don't know why it is shown as added in the webrev, they have been removed. I have published another iteration of the webrev at [1] > > The change to flags-cflag.m4 to add LP64=1 on Windows will need eyes, > it's not immediately obvious to me which shared code compiled on > Windows is impacted by this. yes probably this change is risky. I did it as the comment suggested that the only reason the treatment for Windows was different was because of pack200. But not sure if we can trust that comment. Should I restore this code to its original state? > > -Alan Thanks, Vicente [1] http://cr.openjdk.java.net/~vromero/8234542/webrev.03/ From forax at univ-mlv.fr Fri Nov 22 21:41:41 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 22 Nov 2019 22:41:41 +0100 (CET) Subject: Looking for Sponsor: JDK-8229959 Convert proxy class to use constant dynamic In-Reply-To: <1391ad74-c3a3-3d91-f8b9-dd2f2cc855b7@j-kuhn.de> References: <1391ad74-c3a3-3d91-f8b9-dd2f2cc855b7@j-kuhn.de> Message-ID: <718907609.2257625.1574458901743.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Johannes Kuhn" > ?: "core-libs-dev" > Envoy?: Vendredi 22 Novembre 2019 04:23:31 > Objet: Looking for Sponsor: JDK-8229959 Convert proxy class to use constant dynamic > Hi everyone, Hi Johannes, > > a few hours ago I signed the Oracle Contributor Agreement. felicitation ! > I'd like to work on JDK-8229959: Convert proxy class to use constant > dynamic. > > Without further ado, here are some questions and answers you may ask: > > * What are you exactly planing to do? > I'd like to replace the GETSTATIC instruction with an LDC instruction in > the current generated bytecode for the proxies. > > * What benefits would such a change have? > First, it allows us to drop the static final fields and the class > initializer for the generated proxy classes. > Second, it allows the code (both generated and generator) to be more > clear by moving the essential parts together. > Third, it might bring some performance improvement, because the > j.l.r.Method lookup is delayed to it's first use - which in some cases > might never happen. > > * Are you able to write such a patch? > Yes. I have some experience with the Java bytecode, ASM and ConstantDynamic. > > * But java.lang.reflect.Method is not immutable/persistent? > That's not a question, but you are right. j.l.r.Method has > setAccessible, modifying the Method instance. Still, the current > implementation shares the same Method instance with all proxies with the > same interfaces in the same ClassLoader. i wonder if some codes in the wild rely on that ? > > * What should the bootstrap method look like? > The bootstrap method will take one additional argument, a direct > MethodHandle to the to be resolved method, and should crack it using > it's passed Lookup and then reflect it as Method. In other words, it > should do `return lookup.revealDirect(mh).reflectAs(Method.class, lookup);` > > *? Where should this bootstrap method reside? > I'm glad you asked. After some thoughts, there are two promising places > where I could put it: > a) As private static method in the proxy itself. > Benefits: No public API changes. Also allows easy migration to option b) > if pursued later. > Downsides: The bootstrap method will be duplicated into every proxy class. > b) As a public static method in the java.* namespace, preferably in > java.lang.invoke.ConstantBootstraps. > Benefits: Only one single implementation in the JVM. > Downside: Changes to the public API. Also leads to other questions like > "Should j.l.r.Member implement Constable?" and "Should I add a subclass > of j.l.c.DynamicConstantDesc for this bootstrap method?" > I prefer option a), but I'm fine with both options. Please let me know > what you think, or if you think of a better way. There is perhaps a better way, as part of the branch nestmates of valhalla, Mandy has added a way to transfer a live object to a Class when defining it, with that you can send all the Methods as an array and in the bootstrap method of a condy, access to the right method by extracting it from the array using an index. It will avoid the whole serialization/deserialization of Methods dance. Here is an example: https://gist.github.com/forax/d0f0034190bc479b86ce977fb94ca176 I believe those changes are planned for Java 14 so will be integrated very soon. > > * What do I expect from my Sponsor? > I expect my sponsor lo believe that this change will improve the > OpenJDK. If consensus shows a preference for option b) above (bootstrap > in j.l.i.ConstantBootstaps), a guidance what requests have to be made > and where. In that case, I volunteer to write those requests and send > them to my sponsor, who can (at their sole discretion) forward it to the > relevant places. > > If you have any additional questions, please don't hesitate to answer to > this mail. I will try to answer all questions to the best of my ability. > regards, > With best regards, > Johannes Kuhn R?mi From erik.joelsson at oracle.com Fri Nov 22 21:41:56 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 22 Nov 2019 13:41:56 -0800 Subject: RFR: JEP 367: Remove the Pack200 Tools and API In-Reply-To: <8fe0abd5-f154-292b-25fc-0bc907633037@oracle.com> References: <09dc53f1-9208-3b1f-3ee6-e0e22210afc5@oracle.com> <96643033-bcac-20f3-32d6-3152a6926459@oracle.com> <8eccfd0c-04da-dc09-2e1f-a76b61fef519@oracle.com> <1e68fb03-814b-b671-346e-faa55b068a77@oracle.com> <8fe0abd5-f154-292b-25fc-0bc907633037@oracle.com> Message-ID: Hello, On 2019-11-22 13:30, Vicente Romero wrote: > Hi all, > > On 11/22/19 3:21 AM, Alan Bateman wrote: >> >> >> On 21/11/2019 19:53, Vicente Romero wrote: >>> Hi, >>> >>> I think I have covered all the proposed fixes so far. This is the >>> last iteration of the webrev [1], all the current changes are in >>> this one, the code hasn't been split into different webrevs. I'm >>> also forwarding to build-dev as there are some build related changes >>> too. The CSR for this change is at [2] >> Would it be possible to summarize what will remain in >> test/jdk/tools/pack200 after this removal? The webrev makes it looks >> like badattr.jar is being added but since it already exists then I'm >> not sure whether to believe it. pack200-verifier/data/golden.jar is >> another one as it looks like JAR file that is generated by the tests >> today is being checked in, maybe `hg add` in error? > > I don't know why it is shown as added in the webrev, they have been > removed. I have published another iteration of the webrev at [1] >> >> The change to flags-cflag.m4 to add LP64=1 on Windows will need eyes, >> it's not immediately obvious to me which shared code compiled on >> Windows is impacted by this. > > yes probably this change is risky. I did it as the comment suggested > that the only reason the treatment for Windows was different was > because of pack200. But not sure if we can trust that comment. Should > I restore this code to its original state? >> That comment is most likely originating from the build-infra rewrite in JDK 8. We probably added _LP64 on all platforms by mistake and noted that it caused a difference in the pack200 binary, so corrected the new build to mimic the old build. I wouldn't say just adding _LP64 on Windows is correct because of this. It may be correct regardless, or it may not. In make/scripts/compare.sh $UNPACK200 is still referenced. Should probably remove the whole section using it rather than just removing the string "jdk.pack". I would assume the *.pack and *.pack.gz files are long gone from any build. /Erik >> -Alan > > > Thanks, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8234542/webrev.03/ From info at j-kuhn.de Fri Nov 22 21:44:41 2019 From: info at j-kuhn.de (Johannes Kuhn) Date: Fri, 22 Nov 2019 22:44:41 +0100 Subject: Looking for Sponsor: JDK-8229959 Convert proxy class to use constant dynamic In-Reply-To: <1062d391-5200-9b2f-6ecf-0fd3a6ea1614@oracle.com> References: <1391ad74-c3a3-3d91-f8b9-dd2f2cc855b7@j-kuhn.de> <1062d391-5200-9b2f-6ecf-0fd3a6ea1614@oracle.com> Message-ID: <645fb0f1-4980-853b-5bc8-2924bafc128d@j-kuhn.de> Last mail got converted from HTML into plaintext, which dropped some significant whit espace. So, again, doing it by hand this time. On 22.11.2019 20:52, Brian Goetz wrote: > For those that are not intimately familiar with the mechanics of proxy class generation, it would be great to flesh this out with a code example, that shows the proposed old and new translation. This would make it easier for folks to evaluate the benefits and costs of the approach, and possibly suggest improvements. > > On 11/21/2019 10:23 PM, Johannes Kuhn wrote: >> >> * What benefits would such a change have? >> First, it allows us to drop the static final fields and the class initializer for the generated proxy classes. >> Second, it allows the code (both generated and generator) to be more clear by moving the essential parts together. >> Third, it might bring some performance improvement, because the j.l.r.Method lookup is delayed to it's first use - which in some cases might never happen. > Thanks for the suggestion. A proxy can be used to create an implementation of one or more interfaces at run time. I just let Java 13 dump a generated Proxy and decompiled it using JD. This is the result: package com.sun.proxy; // imports ...; public final class $Proxy0 extends Proxy implements Runnable { ? private static Method m1; ? private static Method m3; ? private static Method m2; ? private static Method m0; ? public $Proxy0(InvocationHandler paramInvocationHandler) { super(paramInvocationHandler); } ? public final boolean equals(Object paramObject) { ??? try { ????? return ((Boolean)this.h.invoke(this, m1, new Object[] { paramObject })).booleanValue(); ??? } catch (Error|RuntimeException error) { ????? throw error; ??? } catch (Throwable throwable) { ????? throw new UndeclaredThrowableException(throwable); ??? } ? } ? public final void run() { ??? try { ????? this.h.invoke(this, m3, null); ????? return; ??? } catch (Error|RuntimeException error) { ????? throw error; ??? } catch (Throwable throwable) { ????? throw new UndeclaredThrowableException(throwable); ??? } ? } ? public final String toString() { ??? try { ????? return (String)this.h.invoke(this, m2, null); ??? } catch (Error|RuntimeException error) { ????? throw error; ??? } catch (Throwable throwable) { ????? throw new UndeclaredThrowableException(throwable); ??? } ? } ? public final int hashCode() { ??? try { ????? return ((Integer)this.h.invoke(this, m0, null)).intValue(); ??? } catch (Error|RuntimeException error) { ????? throw error; ??? } catch (Throwable throwable) { ????? throw new UndeclaredThrowableException(throwable); ??? } ? } ? static? { ??? try { ????? m1 = Class.forName("java.lang.Object").getMethod("equals", new Class[] { Class.forName("java.lang.Object") }); ????? m3 = Class.forName("java.lang.Runnable").getMethod("run", new Class[0]); ????? m2 = Class.forName("java.lang.Object").getMethod("toString", new Class[0]); ????? m0 = Class.forName("java.lang.Object").getMethod("hashCode", new Class[0]); ????? return; ??? } catch (NoSuchMethodException noSuchMethodException) { ????? throw new NoSuchMethodError(noSuchMethodException.getMessage()); ??? } catch (ClassNotFoundException classNotFoundException) { ????? throw new NoClassDefFoundError(classNotFoundException.getMessage()); ??? } ? } } The new implementation using ASM generates a similar class. I intend to replace the the references to m0, m1... in the generated code through an LDC instruction, and remove the code that generates the fields and the static class initializer. The resulting code would look a something like this: package com.sun.proxy; // imports ...; public final class $Proxy0 extends Proxy implements Runnable { ? public $Proxy0(InvocationHandler paramInvocationHandler) { super(paramInvocationHandler); } ? public final boolean equals(Object paramObject) { ??? try { ????? return ((Boolean)this.h.invoke(this, __LDC(__MethodHandle (com.sun.proxy.$Proxy0::$bootstap, "_", Method.class, __MethodHandle(java.lang.Object::equals)), new Object[] { paramObject })).booleanValue(); ??? } catch (Error|RuntimeException error) { ????? throw error; ??? } catch (Throwable throwable) { ????? throw new UndeclaredThrowableException(throwable); ??? } ? } ? // repeat for run(), hashCode() and equals(Object other) ? private static final Method $bootstrap(Lookup lookup, String ignored, Class clazz, MethodHandle mh) { ??? return lookup.revealDirect(mh).reflectAs(clazz, lookup); ? } } I used __LDC as placeholder for the LDC bytecode instruction (limited to constant dynamic), and __MethodHandle for a MethodHandle in the constant pool. This means the Method is only looked up when the proxy method is called for the first time. In the actual source code (the generating code), it means that the following methods can be dropped: ProxyGenerator.generateStaticInitializer() https://hg.openjdk.java.net/jdk/jdk/file/a2a921609481/src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java#l576 ProxyGenerator.ProxyMethod.codeFieldInitialization(MethodVisitor, String) https://hg.openjdk.java.net/jdk/jdk/file/a2a921609481/src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java#l576 It will require the addition of a new method, which creates the $bootstrap method, and a change ProxyGenerator.ProxyMethod.generateMethod to emit an LDC instruction instead of a GETSTATIC. The next step is to remove the now unused ProxyMethod.methodFieldName and it's dependencies (constructor, their calls...), but this should be a fairly natural change. After all those changes, I assume that I will delete more code than I will add and change. Also, as suggested in my last mail, the bootstrap method doesn't need to be in the generated proxy class, it just needs to be accessible from the generated proxy classes (which can be in any module). Remi Forax suggested to put it in the java.lang.invoke.ConstantBootstraps in his initial proposal[1] - but this means it would be a public API. Using a private method avoids that, at some low cost, and changing to an external bootstrap method later would be a small change. [1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/061923.html From info at j-kuhn.de Fri Nov 22 22:05:56 2019 From: info at j-kuhn.de (Johannes Kuhn) Date: Fri, 22 Nov 2019 23:05:56 +0100 Subject: Looking for Sponsor: JDK-8229959 Convert proxy class to use constant dynamic In-Reply-To: <718907609.2257625.1574458901743.JavaMail.zimbra@u-pem.fr> References: <1391ad74-c3a3-3d91-f8b9-dd2f2cc855b7@j-kuhn.de> <718907609.2257625.1574458901743.JavaMail.zimbra@u-pem.fr> Message-ID: On 22.11.2019 22:41, Remi Forax wrote: > i wonder if some codes in the wild rely on that ? I don't think some code does, but you never know. > There is perhaps a better way, as part of the branch nestmates of valhalla, Mandy has added a way to transfer a live object to a Class when defining it, with that you can send all the Methods as an array and in the bootstrap method of a condy, access to the right method by extracting it from the array using an index. > It will avoid the whole serialization/deserialization of Methods dance. That is a better idea - and could be done today using Unsafe.defineAnonymousClass - If it didn't need a host class. > Here is an example: > https://gist.github.com/forax/d0f0034190bc479b86ce977fb94ca176 > > I believe those changes are planned for Java 14 so will be integrated very soon. It looks like the class is defined using Lookup.defineHiddenClassWithClassData - in the current proxy implementation there is no lookup object. Also, I'm not sure if the defined proxy class needs to be findable. In short: I did not do an evaluation on what unspecified parts of a proxy can be changed without breaking someones cod From mandy.chung at oracle.com Fri Nov 22 23:15:56 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 22 Nov 2019 15:15:56 -0800 Subject: Looking for Sponsor: JDK-8229959 Convert proxy class to use constant dynamic In-Reply-To: References: <1391ad74-c3a3-3d91-f8b9-dd2f2cc855b7@j-kuhn.de> <718907609.2257625.1574458901743.JavaMail.zimbra@u-pem.fr> Message-ID: On 11/22/19 2:05 PM, Johannes Kuhn wrote: > On 22.11.2019 22:41, Remi Forax wrote: >> i wonder if some codes in the wild rely on that ? > I don't think some code does, but you never know. >> There is perhaps a better way, as part of the branch nestmates of >> valhalla, Mandy has added a way to transfer a live object to a Class >> when defining it, with that you can send all the Methods as an array >> and in the bootstrap method of a condy, access to the right method by >> extracting it from the array using an index. >> It will avoid the whole serialization/deserialization of Methods dance. > > That is a better idea - and could be done today using > Unsafe.defineAnonymousClass - If it didn't need a host class. > The new API to define a hidden class [1] replaces all existing JDK use of Unsafe::defineAnonymousClass. As for dynamic proxy class, it needs a mechanism to allow creating a hidden class in an empty package.? It's a separate RFE that I plan to follow up in the future. >> Here is an example: >> https://gist.github.com/forax/d0f0034190bc479b86ce977fb94ca176 >> >> I believe those changes are planned for Java 14 so will be integrated >> very soon. As RDP1 is approaching fast, I think it may catch the next train. > > It looks like the class is defined using > Lookup.defineHiddenClassWithClassData - in the current proxy > implementation there is no lookup object. > Also, I'm not sure if the defined proxy class needs to be findable. Proxy class should be a hidden class as it's not intended for other classes to symbolic reference it. > In short: I did not do an evaluation on what unspecified parts of a > proxy can be changed without breaking someones cod IMO I see JDK-8229959 requires a couple of prototypes to understand the pros and cons.?? I can't put time on this RFE at this time due to other higher priority items. Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8220607 From letuyang at amazon.com Sat Nov 23 00:16:45 2019 From: letuyang at amazon.com (Yang, Letu) Date: Sat, 23 Nov 2019 00:16:45 +0000 Subject: Turkish Time Zone name string and translation In-Reply-To: <863d66ad-deaf-1ffc-aded-d1485cf8b213@oracle.com> References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com> <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com> <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com> <95b0ed5b-8e44-7aad-3f64-4bb00c2fa4f5@oracle.com> <99070CC7-3197-4E3D-BC25-4CC0A459CBBA@amazon.com> <863d66ad-deaf-1ffc-aded-d1485cf8b213@oracle.com> Message-ID: <862256B3-5F3F-45C5-9591-8BAAC641D22C@amazon.com> Hi Naoto, Thank you for the advice! I've uploaded a new version: https://cr.openjdk.java.net/~xliu/8234288/webrev.02/webrev/ Letu ?On 11/21/19, 9:18 AM, "naoto.sato at oracle.com" wrote: Hi Letu, The change in the resource bundle file looks good. As to the regression test, I would avoid adding a separate file, instead add some variations for open/test/jdk/sun/text/resources/LocaleDataTest.java as I mentioned. Add some lines in "LocaleData" file, which contains the expected resources for the COMPAT locale provider. Naoto On 11/20/19 9:43 PM, Yang, Letu wrote: > Hi Naoto, > > Thank you for the suggestions! > > I've added a new webrev: https://cr.openjdk.java.net/~xliu/8234288/webrev.01/ > > Letu > > On 11/18/19, 9:09 AM, "naoto.sato at oracle.com" wrote: > > Hi Letu, > > Here are my comments to your changes: > > - You will need a regression test for this fix. Take a look at > test/jdk/sun/text/resources/LocaleDataTest.java, and add appropriate > test cases. > > - Fix comment should follow the OpenJDK changeset guideline [1] > > - As to the change itself, I would put "Turkey Summer Time"/"TRST" for > the 3rd and 4th array elements. Even though Turkey time do not observe > DST, names in those slots should reflect the DST (consistent to other names) > > - time zone id "Turkey" (line 1050) should also point to TRT array. > > Naoto > > [1] http://openjdk.java.net/guide/producingChangeset.html > > On 11/17/19 8:54 PM, Yang, Letu wrote: > > Hi Naoto, > > > > Thank you for the clarification! > > > > Xin from my team has filed a JBS and uploaded my webrev: > > https://bugs.openjdk.java.net/browse/JDK-8234288 > > https://cr.openjdk.java.net/~xliu/8234288/webrev.00/ > > > > Letu > > > > On 11/16/19, 6:44 AM, "naoto.sato at oracle.com" wrote: > > > > Letu, > > > > Please go ahead and fix the issue in English resource. As to the > > translation, Oracle l10n will translate it in appropriate locales. > > > > Naoto > > > > On 11/15/19 5:56 PM, Yang, Letu wrote: > > > Hi Naoto > > > > > > Thank you for the quick response! We will file a ticket later today. > > > > > > Shall we make an effort on fixing and translating the strings, or you > > > prefer to take care of it at Oracle? > > > > > > Letu > > > > > > On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com wrote: > > > Hi Letu, > > > > > > Please file a JBS issue for this (component: core-libs, subcomponent: > > > java.util:i18n). > > > > > > Naoto > > > > > > On 11/15/19 3:19 PM, Yang, Letu wrote: > > >> Hi, > > >> > > >> We recently found an issue with the Time Zone name for ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own Turkish Time (TRT) zone in 2016, although the tzdata had been updated, the Time Zone name string has not been updated yet: > > >> > > >> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836 > > >> > > >> It still returns "Eastern European Time" for the TimeZone.getDisplayName call, which has a summer time while Turkish Time does not. An entry for TRT need to be added to this file, and assign to both "Europe/Istanbul" and "Asian/Istanbul". This also need to be updated for other locales. I can create a JBS issue for this, but I > > > am not sure whether we should fix this bug, or there is an existing > > > procedure for this kind of bug which requires language translation. > > >> > > >> Letu > > >> > > >> > > >> > > > > > > From sergey.kuksenko at oracle.com Sat Nov 23 00:34:14 2019 From: sergey.kuksenko at oracle.com (Sergey Kuksenko) Date: Fri, 22 Nov 2019 16:34:14 -0800 Subject: RFR(s): 8176894 Provide specialized implementation for default methods putIfAbsent, computeIfAbsent, computeIfPresent, compute, merge in TreeMap In-Reply-To: References: Message-ID: <7f748558-3a5b-1784-8717-69f1954cb786@oracle.com> Thanks! Looks good. The only I have comments for added microbenchmark: * Keys and values should be preallocated in setup. We want to measure TreeMap, not boxing. I'd prefer to see preallocated array of keys. * What is the reason to have "shuffled" parameter? Random keys distribution is more preferable. * pairs of similar operations looks weird. I mean code like this: bh.consume(map.put(key, key)); bh.consume(map.put(key, key)); The second put has advantage due to the fact that all required data is in CPU cache already. If we want to take into account operations over existing keys - it would be better to have two keys in the preallocated array. If array of keys is shuffled -> put operations for equal keys won't be following as sequentially. I think it will be closer to real behavior. * general notice about random keys. Typically I use the following scheme: @Param("0") long seed; @Setup() public void setup() { Random rnd = seed==0 ? new Random() : new Random(seed); // use rnd for generating data } In default case we always generates random data and cover quite nice distribution of really random cases. But if we found some "bad" behavior in some cases or we want to fix sequence of out tree modifications - we always may setup seed parameter as we wish and make it fixed. On 10/13/19 2:51 AM, Tagir Valeev wrote: > Hello! > > Please review the updated patch (no sponsorship is necessary; review only): > https://cr.openjdk.java.net/~tvaleev/webrev/8176894/r3/ > https://bugs.openjdk.java.net/browse/JDK-8176894 > > The difference from the previous version [1] is minimal: I just > noticed that the specification for computeIfAbsent should say > "mapping" instead of "remapping", so I fixed the spec. No changes in > code/tests. > > Also please review the associated CSR: > https://bugs.openjdk.java.net/browse/JDK-8227666 > I updated it, according to Joe Darcy's comments. > > An additional explanation and background is copied below from my > original e-mail [2] for your convenience: > > The patch was originally submitted by Sergey Kuksenko in March 2017 and > reviewed by some people: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-March/046825.html > The latest patch submitted by Sergey is here: > http://cr.openjdk.java.net/~skuksenko/corelibs/utils/8176894/webrev.01/ > > I asked Sergey why it was abandoned. Seems there were no particular reason > and Sergey asked if I could pick up this work. I will be happy to finish it. > > Here's the list of differences between the latest Sergey patch and my patch: > - A bug is fixed in putIfAbsent implementation. TreeMap.java, lines 576 and > 596: `|| oldValue == null` condition added (the null value should be > overwritten no matter what) > - A testcase is added to cover this problem (InPlaceOpsCollisions.java, > also checks HashMap and LinkedHashMap). Not sure if it's the best place for > such test though. Probably a separate file would be better? > - TreeMap.merge() implementation is added. > - TreeMap is added to the FunctionalCMEs.java test (btw this file copyright > says that it's a subject to Classpath exception which is probably wrong?) > - Simple microbenchmark is added: TreeMapUpdate.java > > My quick benchmarking shows that optimized version is indeed faster for the > most of the tests and no regression is observed for put() method. Here's > raw results of jdk13-ea+26 and jdk13-ea+26+patch if anybody is interested. > http://cr.openjdk.java.net/~tvaleev/jmh/JDK-8176894/ > > With best regards, > Tagir Valeev. > > [1] https://cr.openjdk.java.net/~tvaleev/webrev/8176894/r2/ > [2] https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-July/061309.html From naoto.sato at oracle.com Sat Nov 23 00:38:12 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 22 Nov 2019 16:38:12 -0800 Subject: Turkish Time Zone name string and translation In-Reply-To: <862256B3-5F3F-45C5-9591-8BAAC641D22C@amazon.com> References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com> <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com> <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com> <95b0ed5b-8e44-7aad-3f64-4bb00c2fa4f5@oracle.com> <99070CC7-3197-4E3D-BC25-4CC0A459CBBA@amazon.com> <863d66ad-deaf-1ffc-aded-d1485cf8b213@oracle.com> <862256B3-5F3F-45C5-9591-8BAAC641D22C@amazon.com> Message-ID: Hi Letu, You might want to add lines for "Turkey" zone as well in LocaleData? Naoto On 11/22/19 4:16 PM, Yang, Letu wrote: > Hi Naoto, > > Thank you for the advice! I've uploaded a new version: https://cr.openjdk.java.net/~xliu/8234288/webrev.02/webrev/ > > Letu > > ?On 11/21/19, 9:18 AM, "naoto.sato at oracle.com" wrote: > > Hi Letu, > > The change in the resource bundle file looks good. > > As to the regression test, I would avoid adding a separate file, instead > add some variations for > open/test/jdk/sun/text/resources/LocaleDataTest.java as I mentioned. Add > some lines in "LocaleData" file, which contains the expected resources > for the COMPAT locale provider. > > Naoto > > On 11/20/19 9:43 PM, Yang, Letu wrote: > > Hi Naoto, > > > > Thank you for the suggestions! > > > > I've added a new webrev: https://cr.openjdk.java.net/~xliu/8234288/webrev.01/ > > > > Letu > > > > On 11/18/19, 9:09 AM, "naoto.sato at oracle.com" wrote: > > > > Hi Letu, > > > > Here are my comments to your changes: > > > > - You will need a regression test for this fix. Take a look at > > test/jdk/sun/text/resources/LocaleDataTest.java, and add appropriate > > test cases. > > > > - Fix comment should follow the OpenJDK changeset guideline [1] > > > > - As to the change itself, I would put "Turkey Summer Time"/"TRST" for > > the 3rd and 4th array elements. Even though Turkey time do not observe > > DST, names in those slots should reflect the DST (consistent to other names) > > > > - time zone id "Turkey" (line 1050) should also point to TRT array. > > > > Naoto > > > > [1] http://openjdk.java.net/guide/producingChangeset.html > > > > On 11/17/19 8:54 PM, Yang, Letu wrote: > > > Hi Naoto, > > > > > > Thank you for the clarification! > > > > > > Xin from my team has filed a JBS and uploaded my webrev: > > > https://bugs.openjdk.java.net/browse/JDK-8234288 > > > https://cr.openjdk.java.net/~xliu/8234288/webrev.00/ > > > > > > Letu > > > > > > On 11/16/19, 6:44 AM, "naoto.sato at oracle.com" wrote: > > > > > > Letu, > > > > > > Please go ahead and fix the issue in English resource. As to the > > > translation, Oracle l10n will translate it in appropriate locales. > > > > > > Naoto > > > > > > On 11/15/19 5:56 PM, Yang, Letu wrote: > > > > Hi Naoto > > > > > > > > Thank you for the quick response! We will file a ticket later today. > > > > > > > > Shall we make an effort on fixing and translating the strings, or you > > > > prefer to take care of it at Oracle? > > > > > > > > Letu > > > > > > > > On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com wrote: > > > > Hi Letu, > > > > > > > > Please file a JBS issue for this (component: core-libs, subcomponent: > > > > java.util:i18n). > > > > > > > > Naoto > > > > > > > > On 11/15/19 3:19 PM, Yang, Letu wrote: > > > >> Hi, > > > >> > > > >> We recently found an issue with the Time Zone name for ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own Turkish Time (TRT) zone in 2016, although the tzdata had been updated, the Time Zone name string has not been updated yet: > > > >> > > > >> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836 > > > >> > > > >> It still returns "Eastern European Time" for the TimeZone.getDisplayName call, which has a summer time while Turkish Time does not. An entry for TRT need to be added to this file, and assign to both "Europe/Istanbul" and "Asian/Istanbul". This also need to be updated for other locales. I can create a JBS issue for this, but I > > > > am not sure whether we should fix this bug, or there is an existing > > > > procedure for this kind of bug which requires language translation. > > > >> > > > >> Letu > > > >> > > > >> > > > >> > > > > > > > > > > > > From weijun.wang at oracle.com Sat Nov 23 03:37:23 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 23 Nov 2019 11:37:23 +0800 Subject: 8179320: File.getUsableSpace() returns a negative number on very large file system In-Reply-To: References: Message-ID: <471BCC35-8477-4CBA-8E9E-906B4959F89C@oracle.com> Just curious. Why is fs.getSpace() returning negative here? Naively, I would think it is truncating an int128 to int64. If so, if the value exceeds 2^64, will it be positive again? Thanks, Max > On Nov 23, 2019, at 1:40 AM, Brian Burkhalter wrote: > > PING! > >> Begin forwarded message: >> >> From: Brian Burkhalter >> Subject: Re: 8179320: File.getUsableSpace() returns a negative number on very large file system >> Date: November 15, 2019 at 2:40:06 PM PST >> To: Alan Bateman >> Cc: Core-Libs-Dev >> >> >>> On Nov 15, 2019, at 2:59 AM, Alan Bateman > wrote: >>> >>> On 02/11/2019 00:13, Brian Burkhalter wrote: >>>> For this issue [1], please review this patch [2] and the corresponding CSR [3]. >>>> >>>> >>> One thing that isn't clear is how these methods behave when the space info can't be obtained. It is specified to return 0L when the path is not "a partition" but I think it also returns 0L when the information cannot be obtained. >> >> I?ve updated the patch [1] to address this. The difference versus webrev.00 is [2]. >> >> Thanks, >> >> Brian >> >> [1] http://cr.openjdk.java.net/~bpb/8179320/webrev.01/ [2] diff vs. webrev.00 >> >> --- a/src/java.base/share/classes/java/io/File.java >> +++ b/src/java.base/share/classes/java/io/File.java >> @@ -1804,7 +1804,8 @@ >> * returned. >> * >> * @return The size, in bytes, of the partition or {@code 0L} if this >> - * abstract pathname does not name a partition >> + * abstract pathname does not name a partition or if the size >> + * cannot be obtained >> * >> * @throws SecurityException >> * If a security manager has been installed and it denies >> @@ -1844,9 +1845,10 @@ >> * will succeed. >> * >> * @return The number of unallocated bytes on the partition or {@code 0L} >> - * if the abstract pathname does not name a partition. This >> - * value will be less than or equal to the total file system size >> - * returned by {@link #getTotalSpace}. >> + * if the abstract pathname does not name a partition or if this >> + * number cannot be obtained. This value will be less than or >> + * equal to the total file system size returned by >> + * {@link #getTotalSpace}. >> * >> * @throws SecurityException >> * If a security manager has been installed and it denies >> @@ -1889,9 +1891,10 @@ >> * to this file system will succeed. >> * >> * @return The number of available bytes on the partition or {@code 0L} >> - * if the abstract pathname does not name a partition. On >> - * systems where this information is not available, this method >> - * will be equivalent to a call to {@link #getFreeSpace}. >> + * if the abstract pathname does not name a partition or if this >> + * number cannot be obtained. On systems where this information >> + * is not available, this method will be equivalent to a call to >> + * {@link #getFreeSpace}. >> * >> * @throws SecurityException >> * If a security manager has been installed and it denies > From letuyang at amazon.com Sat Nov 23 05:55:35 2019 From: letuyang at amazon.com (Yang, Letu) Date: Sat, 23 Nov 2019 05:55:35 +0000 Subject: Turkish Time Zone name string and translation In-Reply-To: References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com> <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com> <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com> <95b0ed5b-8e44-7aad-3f64-4bb00c2fa4f5@oracle.com> <99070CC7-3197-4E3D-BC25-4CC0A459CBBA@amazon.com> <863d66ad-deaf-1ffc-aded-d1485cf8b213@oracle.com> <862256B3-5F3F-45C5-9591-8BAAC641D22C@amazon.com>, Message-ID: <32588966-0750-4916-8583-a4af328ecbcd@amazon.com> Hi Naoto, Added it in the new webrev https://cr.openjdk.java.net/~xliu/8234288/webrev.03/ . Thanks! Letu On Nov 22, 2019 4:40 PM, naoto.sato at oracle.com wrote: Hi Letu, You might want to add lines for "Turkey" zone as well in LocaleData? Naoto On 11/22/19 4:16 PM, Yang, Letu wrote: > Hi Naoto, > > Thank you for the advice! I've uploaded a new version: https://cr.openjdk.java.net/~xliu/8234288/webrev.02/webrev/ > > Letu > > ?On 11/21/19, 9:18 AM, "naoto.sato at oracle.com" wrote: > > Hi Letu, > > The change in the resource bundle file looks good. > > As to the regression test, I would avoid adding a separate file, instead > add some variations for > open/test/jdk/sun/text/resources/LocaleDataTest.java as I mentioned. Add > some lines in "LocaleData" file, which contains the expected resources > for the COMPAT locale provider. > > Naoto > > On 11/20/19 9:43 PM, Yang, Letu wrote: > > Hi Naoto, > > > > Thank you for the suggestions! > > > > I've added a new webrev: https://cr.openjdk.java.net/~xliu/8234288/webrev.01/ > > > > Letu > > > > On 11/18/19, 9:09 AM, "naoto.sato at oracle.com" wrote: > > > > Hi Letu, > > > > Here are my comments to your changes: > > > > - You will need a regression test for this fix. Take a look at > > test/jdk/sun/text/resources/LocaleDataTest.java, and add appropriate > > test cases. > > > > - Fix comment should follow the OpenJDK changeset guideline [1] > > > > - As to the change itself, I would put "Turkey Summer Time"/"TRST" for > > the 3rd and 4th array elements. Even though Turkey time do not observe > > DST, names in those slots should reflect the DST (consistent to other names) > > > > - time zone id "Turkey" (line 1050) should also point to TRT array. > > > > Naoto > > > > [1] http://openjdk.java.net/guide/producingChangeset.html > > > > On 11/17/19 8:54 PM, Yang, Letu wrote: > > > Hi Naoto, > > > > > > Thank you for the clarification! > > > > > > Xin from my team has filed a JBS and uploaded my webrev: > > > https://bugs.openjdk.java.net/browse/JDK-8234288 > > > https://cr.openjdk.java.net/~xliu/8234288/webrev.00/ > > > > > > Letu > > > > > > On 11/16/19, 6:44 AM, "naoto.sato at oracle.com" wrote: > > > > > > Letu, > > > > > > Please go ahead and fix the issue in English resource. As to the > > > translation, Oracle l10n will translate it in appropriate locales. > > > > > > Naoto > > > > > > On 11/15/19 5:56 PM, Yang, Letu wrote: > > > > Hi Naoto > > > > > > > > Thank you for the quick response! We will file a ticket later today. > > > > > > > > Shall we make an effort on fixing and translating the strings, or you > > > > prefer to take care of it at Oracle? > > > > > > > > Letu > > > > > > > > On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com wrote: > > > > Hi Letu, > > > > > > > > Please file a JBS issue for this (component: core-libs, subcomponent: > > > > java.util:i18n). > > > > > > > > Naoto > > > > > > > > On 11/15/19 3:19 PM, Yang, Letu wrote: > > > >> Hi, > > > >> > > > >> We recently found an issue with the Time Zone name for ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own Turkish Time (TRT) zone in 2016, although the tzdata had been updated, the Time Zone name string has not been updated yet: > > > >> > > > >> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836 > > > >> > > > >> It still returns "Eastern European Time" for the TimeZone.getDisplayName call, which has a summer time while Turkish Time does not. An entry for TRT need to be added to this file, and assign to both "Europe/Istanbul" and "Asian/Istanbul". This also need to be updated for other locales. I can create a JBS issue for this, but I > > > > am not sure whether we should fix this bug, or there is an existing > > > > procedure for this kind of bug which requires language translation. > > > >> > > > >> Letu > > > >> > > > >> > > > >> > > > > > > > > > > > > From ivan.gerasimov at oracle.com Sat Nov 23 07:30:10 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 22 Nov 2019 23:30:10 -0800 Subject: RFR 8234423 : Modifying ArrayList.subList().subList() resets modCount of subList In-Reply-To: References: Message-ID: Re-sending the request with the correct Subject line - the bug is not (only) about the iterator. On 11/20/19 10:11 PM, Ivan Gerasimov wrote: > Hello! > > When a sublist of a sublist of an ArrayList is created, its modCount > is initialized from the ArrayList root, and not from its immediate > parent. > > This means that modifying that 2nd level sublist will reset modCounts > of the entire chain up to the root, and consequently the 1st level > sublist won't detect concurrent modification done to the ArrayList root. > > Along with the fix, handling of modCount is slightly improved in a few > other places. > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8234423 > WEBREV: http://cr.openjdk.java.net/~igerasim/8234423/00/webrev/ > -- With kind regards, Ivan Gerasimov From mik3hall at gmail.com Sat Nov 23 16:37:27 2019 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 23 Nov 2019 10:37:27 -0600 Subject: jpackage ROOTDIR variable in a Windows bat file Message-ID: I am trying to come up with a simple Windows bat file execution of jpackage. I would like to use the builtin ROOTDIR variable. How should this be done? Not very familiar with Windows. This -Djava.security.policy=$ROOTDIR\app\all.policy Gets Error: Invalid Option: [-Djava.security.policy=$ROOTDIR\app\all.policy] This -Djava.security.policy=%ROOTDIR%\app\all.policy Gets this Error: Invalid Option: [-Djava.security.policy=\app\all.policy] These are included in the ?java-options parameter. This thread seems to end up indicating that $ROOTDIR should work on windows https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-November/063361.html Although it is for finding the runtime and not included in ?java-options From kevin.rushforth at oracle.com Sat Nov 23 16:51:07 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 23 Nov 2019 08:51:07 -0800 Subject: jpackage ROOTDIR variable in a Windows bat file In-Reply-To: References: Message-ID: <43ad0e64-f5f1-c0bc-d5b1-7ac6d0589600@oracle.com> $ROOTDIR is not a supported interface. You should use "$APPDIR" instead. Having said that, the real problem is likely your use of backslashes. I recommend using forward slashes and also enclosing it in single quotes, like this: ??? -Djava.security.policy='$APPDIR/all.policy' If you need to use backslashes for some reason, then you will need to use two (the first is treated as an escape character). -- Kevin On 11/23/2019 8:37 AM, Michael Hall wrote: > I am trying to come up with a simple Windows bat file execution of jpackage. I would like to use the builtin ROOTDIR variable. How should this be done? > Not very familiar with Windows. > > This > -Djava.security.policy=$ROOTDIR\app\all.policy > Gets > Error: Invalid Option: [-Djava.security.policy=$ROOTDIR\app\all.policy] > > This > -Djava.security.policy=%ROOTDIR%\app\all.policy > Gets this > Error: Invalid Option: [-Djava.security.policy=\app\all.policy] > > These are included in the ?java-options parameter. > > This thread seems to end up indicating that $ROOTDIR should work on windows > https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-November/063361.html > Although it is for finding the runtime and not included in ?java-options > > From brian.goetz at oracle.com Sat Nov 23 17:09:11 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 23 Nov 2019 12:09:11 -0500 Subject: Looking for Sponsor: JDK-8229959 Convert proxy class to use constant dynamic In-Reply-To: <645fb0f1-4980-853b-5bc8-2924bafc128d@j-kuhn.de> References: <1391ad74-c3a3-3d91-f8b9-dd2f2cc855b7@j-kuhn.de> <1062d391-5200-9b2f-6ecf-0fd3a6ea1614@oracle.com> <645fb0f1-4980-853b-5bc8-2924bafc128d@j-kuhn.de> Message-ID: <0FFEF0FB-FB4D-46F3-81CA-ABD78E2D2D6C@oracle.com> Thanks for the examples. A few comments: - A reasonable place to consider putting the bootstrap is in Proxy itself. I am not sure that ConstantBootstraps is the right place (or anywhere in JLI for that matter) unless Method is retrofitted to implement Constable, which is problematic given that Methods are not constants. - In the department of ?future things that might be applied here? (Remi started it), this is a perfect application for lazy statics. But we don?t have those yet. - The main benefit here is that it makes proxy creation faster. However, given the amount of work that goes on at proxy creation (reflection, byte code spinning, class loading), its not clear how much of the cost is initializing the proxy class. Some benchmarking to establish the cost benefit here would be good. (If we are spinning the proxy at jlink time, then the benefit is probably greater.) Overall, the translation approach seems sound but I would suggest that we clarify the benefits a little bit before embarking. > On Nov 22, 2019, at 4:44 PM, Johannes Kuhn wrote: > > Last mail got converted from HTML into plaintext, which dropped some significant whit espace. So, again, doing it by hand this time. > > On 22.11.2019 20:52, Brian Goetz wrote: > > For those that are not intimately familiar with the mechanics of proxy class generation, it would be great to flesh this out with a code example, that shows the proposed old and new translation. This would make it easier for folks to evaluate the benefits and costs of the approach, and possibly suggest improvements. > > > > On 11/21/2019 10:23 PM, Johannes Kuhn wrote: > >> > >> * What benefits would such a change have? > >> First, it allows us to drop the static final fields and the class initializer for the generated proxy classes. > >> Second, it allows the code (both generated and generator) to be more clear by moving the essential parts together. > >> Third, it might bring some performance improvement, because the j.l.r.Method lookup is delayed to it's first use - which in some cases might never happen. > > > Thanks for the suggestion. A proxy can be used to create an implementation of one or more interfaces at run time. > I just let Java 13 dump a generated Proxy and decompiled it using JD. This is the result: > > package com.sun.proxy; > // imports ...; > public final class $Proxy0 extends Proxy implements Runnable { > private static Method m1; > private static Method m3; > private static Method m2; > private static Method m0; > > public $Proxy0(InvocationHandler paramInvocationHandler) { super(paramInvocationHandler); } > > public final boolean equals(Object paramObject) { > try { > return ((Boolean)this.h.invoke(this, m1, new Object[] { paramObject })).booleanValue(); > } catch (Error|RuntimeException error) { > throw error; > } catch (Throwable throwable) { > throw new UndeclaredThrowableException(throwable); > } > } > > public final void run() { > try { > this.h.invoke(this, m3, null); > return; > } catch (Error|RuntimeException error) { > throw error; > } catch (Throwable throwable) { > throw new UndeclaredThrowableException(throwable); > } > } > > public final String toString() { > try { > return (String)this.h.invoke(this, m2, null); > } catch (Error|RuntimeException error) { > throw error; > } catch (Throwable throwable) { > throw new UndeclaredThrowableException(throwable); > } > } > > public final int hashCode() { > try { > return ((Integer)this.h.invoke(this, m0, null)).intValue(); > } catch (Error|RuntimeException error) { > throw error; > } catch (Throwable throwable) { > throw new UndeclaredThrowableException(throwable); > } > } > > static { > try { > m1 = Class.forName("java.lang.Object").getMethod("equals", new Class[] { Class.forName("java.lang.Object") }); > m3 = Class.forName("java.lang.Runnable").getMethod("run", new Class[0]); > m2 = Class.forName("java.lang.Object").getMethod("toString", new Class[0]); > m0 = Class.forName("java.lang.Object").getMethod("hashCode", new Class[0]); > return; > } catch (NoSuchMethodException noSuchMethodException) { > throw new NoSuchMethodError(noSuchMethodException.getMessage()); > } catch (ClassNotFoundException classNotFoundException) { > throw new NoClassDefFoundError(classNotFoundException.getMessage()); > } > } > } > > The new implementation using ASM generates a similar class. > I intend to replace the the references to m0, m1... in the generated code through an LDC instruction, and remove the code that generates the fields and the static class initializer. > > The resulting code would look a something like this: > > package com.sun.proxy; > // imports ...; > public final class $Proxy0 extends Proxy implements Runnable { > > public $Proxy0(InvocationHandler paramInvocationHandler) { super(paramInvocationHandler); } > > public final boolean equals(Object paramObject) { > try { > return ((Boolean)this.h.invoke(this, __LDC(__MethodHandle > (com.sun.proxy.$Proxy0::$bootstap, "_", Method.class, > __MethodHandle(java.lang.Object::equals)), new Object[] { paramObject })).booleanValue(); > } catch (Error|RuntimeException error) { > throw error; > } catch (Throwable throwable) { > throw new UndeclaredThrowableException(throwable); > } > } > > // repeat for run(), hashCode() and equals(Object other) > > private static final Method $bootstrap(Lookup lookup, String ignored, Class clazz, MethodHandle mh) { > return lookup.revealDirect(mh).reflectAs(clazz, lookup); > } > > } > > I used __LDC as placeholder for the LDC bytecode instruction (limited to constant dynamic), and __MethodHandle for a MethodHandle in the constant pool. > This means the Method is only looked up when the proxy method is called for the first time. > > In the actual source code (the generating code), it means that the following methods can be dropped: > ProxyGenerator.generateStaticInitializer() https://hg.openjdk.java.net/jdk/jdk/file/a2a921609481/src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java#l576 > ProxyGenerator.ProxyMethod.codeFieldInitialization(MethodVisitor, String) https://hg.openjdk.java.net/jdk/jdk/file/a2a921609481/src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java#l576 > > It will require the addition of a new method, which creates the $bootstrap method, and a change ProxyGenerator.ProxyMethod.generateMethod to emit an LDC instruction instead of a GETSTATIC. > > The next step is to remove the now unused ProxyMethod.methodFieldName and it's dependencies (constructor, their calls...), but this should be a fairly natural change. > After all those changes, I assume that I will delete more code than I will add and change. > > Also, as suggested in my last mail, the bootstrap method doesn't need to be in the generated proxy class, it just needs to be accessible from the generated proxy classes (which can be in any module). > Remi Forax suggested to put it in the java.lang.invoke.ConstantBootstraps in his initial proposal[1] - but this means it would be a public API. > Using a private method avoids that, at some low cost, and changing to an external bootstrap method later would be a small change. > > [1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/061923.html > From mik3hall at gmail.com Sat Nov 23 17:10:18 2019 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 23 Nov 2019 11:10:18 -0600 Subject: jpackage ROOTDIR variable in a Windows bat file In-Reply-To: <43ad0e64-f5f1-c0bc-d5b1-7ac6d0589600@oracle.com> References: <43ad0e64-f5f1-c0bc-d5b1-7ac6d0589600@oracle.com> Message-ID: <1C99B0A1-9263-4020-B1C9-50E1BC1D1062@gmail.com> > On Nov 23, 2019, at 10:51 AM, Kevin Rushforth wrote: > > $ROOTDIR is not a supported interface. You should use "$APPDIR" instead. Having said that, the real problem is likely your use of backslashes. I recommend using forward slashes and also enclosing it in single quotes, like this: It is apparently sometimes a unsupported interface. Since my OS X invocation works with? -Djava.security.policy=$ROOTDIR/app/all.policy I?ll have to change that to APPDIR to be sure it still works. But this does show you should be correct for APPDIR being supported? JDK-8231910 Expose the APPDIR variable to applications that use jpackage > > -Djava.security.policy='$APPDIR/all.policy' > > If you need to use backslashes for some reason, then you will need to use two (the first is treated as an escape character). > I thought java on Windows was pretty indifferent to forward or backslashes in file paths but I haven?t done much on Windows. I figured when in Rome or on Windows do what they do. First try keeping backslashes? Error: Invalid Option: [-Djava.security.policy=$APPDIR\app\all.policy] With forward slashes Error: Invalid Option: [-Djava.security.policy=$ROOTDIR/app/all.policy] From mik3hall at gmail.com Sat Nov 23 17:12:59 2019 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 23 Nov 2019 11:12:59 -0600 Subject: jpackage ROOTDIR variable in a Windows bat file In-Reply-To: <1C99B0A1-9263-4020-B1C9-50E1BC1D1062@gmail.com> References: <43ad0e64-f5f1-c0bc-d5b1-7ac6d0589600@oracle.com> <1C99B0A1-9263-4020-B1C9-50E1BC1D1062@gmail.com> Message-ID: <7BC977C3-4176-4814-8BBB-033065B2D561@gmail.com> > > With forward slashes > > Error: Invalid Option: [-Djava.security.policy=$ROOTDIR/app/all.policy] Sorry that should of been APPDIR. manually cutting and pasting with edit since I can?t currently cut and paste directly between Windows VirtualBox and OS X. From kevin.rushforth at oracle.com Sat Nov 23 17:22:28 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 23 Nov 2019 09:22:28 -0800 Subject: jpackage ROOTDIR variable in a Windows bat file In-Reply-To: <7BC977C3-4176-4814-8BBB-033065B2D561@gmail.com> References: <43ad0e64-f5f1-c0bc-d5b1-7ac6d0589600@oracle.com> <1C99B0A1-9263-4020-B1C9-50E1BC1D1062@gmail.com> <7BC977C3-4176-4814-8BBB-033065B2D561@gmail.com> Message-ID: <81a59597-c7aa-fbee-d3c8-e0a8d855e7f7@oracle.com> I just tried this and it worked fine for me: jpackage --java-options '-Djava.security.policy=$APPDIR/all.policy' ... (note that there should not be an extra "/app" since $APPDIR points to the app directory). It generated this in the ApplicationName/app/ApplicationName.cfg file: [JavaOptions] -Djava.security.policy=$APPDIR/all.policy -- Kevin On 11/23/2019 9:12 AM, Michael Hall wrote: > >> With forward slashes >> >> Error: Invalid Option: [-Djava.security.policy=$ROOTDIR/app/all.policy] > Sorry that should of been APPDIR. manually cutting and pasting with edit since I can?t currently cut and paste directly between Windows VirtualBox and OS X. From mik3hall at gmail.com Sat Nov 23 17:45:00 2019 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 23 Nov 2019 11:45:00 -0600 Subject: jpackage ROOTDIR variable in a Windows bat file In-Reply-To: <81a59597-c7aa-fbee-d3c8-e0a8d855e7f7@oracle.com> References: <43ad0e64-f5f1-c0bc-d5b1-7ac6d0589600@oracle.com> <1C99B0A1-9263-4020-B1C9-50E1BC1D1062@gmail.com> <7BC977C3-4176-4814-8BBB-033065B2D561@gmail.com> <81a59597-c7aa-fbee-d3c8-e0a8d855e7f7@oracle.com> Message-ID: > On Nov 23, 2019, at 11:22 AM, Kevin Rushforth wrote: > > I just tried this and it worked fine for me: > > jpackage --java-options '-Djava.security.policy=$APPDIR/all.policy' ... > > (note that there should not be an extra "/app" since $APPDIR points to the app directory). > > It generated this in the ApplicationName/app/ApplicationName.cfg file: > > [JavaOptions] > -Djava.security.policy=$APPDIR/all.policy Maybe something is different about running from a bat. Or I?m missing a typo or something. Command line it seems to get past that error but gets? Can not find WiX tools (light.exe, candle.exe) Download WiX 3.0 or later from?. Error: Invalid or unsupported type: [null] This is from a VirtualBox Windows 10 64bit virtual machine. The bat file continues to get the same error. I?ll look closer to be sure it isn?t an error in my bat. On OS X, yes APPDIR works when I remove ?app? from the path as you indicated. From info at j-kuhn.de Sat Nov 23 20:08:06 2019 From: info at j-kuhn.de (Johannes Kuhn) Date: Sat, 23 Nov 2019 21:08:06 +0100 Subject: Looking for Sponsor: JDK-8229959 Convert proxy class to use constant dynamic In-Reply-To: <0FFEF0FB-FB4D-46F3-81CA-ABD78E2D2D6C@oracle.com> References: <1391ad74-c3a3-3d91-f8b9-dd2f2cc855b7@j-kuhn.de> <1062d391-5200-9b2f-6ecf-0fd3a6ea1614@oracle.com> <645fb0f1-4980-853b-5bc8-2924bafc128d@j-kuhn.de> <0FFEF0FB-FB4D-46F3-81CA-ABD78E2D2D6C@oracle.com> Message-ID: <3ee26c09-6f47-8675-ca1f-2e1eca3f5c3d@j-kuhn.de> On 11/23/2019 6:09 PM, Brian Goetz wrote: > Thanks for the examples. > > A few comments: > > ? - A reasonable place to consider putting the bootstrap is in Proxy > itself.? I am not sure that ConstantBootstraps is the right place (or > anywhere in JLI for that matter) unless Method is retrofitted to > implement Constable, which is problematic given that Methods are not > constants. Yes, Method implementing Constable might not be the right thing, because Method is not immutable. Adding the bootstrap method to j.l.r.Proxy is a good alternative. > ? - In the department of ?future things that might be? applied here? > (Remi started it), this is a perfect application for lazy statics.? > But we don?t have those yet. What Remi and Mandy suggested is to pass the Method instances that we already use to spin the bytecode to the new class, which avoids an other round of method lookups. While I like the idea, it relies on on future things. I will try to write a prototype for that. > ? - The main benefit here is that it makes proxy creation faster.? > However, given the amount of work that goes on at proxy creation > (reflection, byte code spinning, class loading), its not clear how > much of the cost is initializing the proxy class.? Some benchmarking > to establish the cost benefit here would be good.? (If we are spinning > the proxy at jlink time, then the benefit is probably greater.) > > Overall, the translation approach seems sound but I would suggest that > we clarify the benefits a little bit before embarking. I just finished the first prototype, which can be found at https://gist.github.com/DasBrain/7766bedfbc8b76ba6a0ee66a54ba97ed - it contains a patch, the javap output of a generated proxy class with and without that patch, and the code I used to dump the proxy class. "make run-test-tier1" passes all JDK tests with the patch. I hope this will help the discussion a bit. The other benefit I talked about is: It makes to code easier, because it's less code and it's a greater locality. I know, this is hard to measure. Everything was spawned by a small sentence Remi wrote on this list: > A follow up should to use constant dynamic (introduce in Java 11) to > get the j.l.r.Method object instead of pre-calculating all of them in > the static init block. > The idea is that a ldc on a constant dynamic with bootstrap method > that takes a MethodHandle as parameter (as boostrap argument) can > return the corresponding Method by using Lookup.revealDirect + reflectAs. > The bootstrap method can be added to j.l.i.ConstantBootstraps https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/061923.html But there were never a real discussion about the benefits yet. It's good that we have one now. As I am a novice JMH user, I don't trust myself to write good benchmarks that actually measure what I want to measure, not confirm what I would like it to be From brian.goetz at oracle.com Sat Nov 23 20:19:57 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 23 Nov 2019 15:19:57 -0500 Subject: Looking for Sponsor: JDK-8229959 Convert proxy class to use constant dynamic In-Reply-To: <3ee26c09-6f47-8675-ca1f-2e1eca3f5c3d@j-kuhn.de> References: <1391ad74-c3a3-3d91-f8b9-dd2f2cc855b7@j-kuhn.de> <1062d391-5200-9b2f-6ecf-0fd3a6ea1614@oracle.com> <645fb0f1-4980-853b-5bc8-2924bafc128d@j-kuhn.de> <0FFEF0FB-FB4D-46F3-81CA-ABD78E2D2D6C@oracle.com> <3ee26c09-6f47-8675-ca1f-2e1eca3f5c3d@j-kuhn.de> Message-ID: > I just finished the first prototype, which can be found at > https://gist.github.com/DasBrain/7766bedfbc8b76ba6a0ee66a54ba97ed - it > contains a patch, the javap output of a generated proxy class with and > without that patch, and the code I used to dump the proxy class. "make > run-test-tier1" passes all JDK tests with the patch. I hope this will > help the discussion a bit. Good start. > https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/061923.html > > > But there were never a real discussion about the benefits yet. It's > good that we have one now. > > As I am a novice JMH user, I don't trust myself to write good > benchmarks that actually measure what I want to measure, not confirm > what I would like it to be Right, I think that's the next step.? You need to design an experiment to measure the cost of the here.? I suspect the best way is to lift that work to an instance method (one that just overwrites the fields), and benchmark that, for various numbers of reflective calls.? Then we can separately measure the cost of spinning the bytecode for a proxy, and of loading the class from a cached byte[].? This will give us a sense of the relative costs of the various pieces, to validate that reducing the cost is relevant. Finally, we can benchmark the current approach against the LDC approach on a per-Method basis.? The LDC approach may well be doing more work per Method, so it's a tradeoff to determine whether deferring that work is a win. From brian.goetz at oracle.com Sat Nov 23 21:40:23 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 23 Nov 2019 16:40:23 -0500 Subject: Looking for Sponsor: JDK-8229959 Convert proxy class to use constant dynamic In-Reply-To: References: <1391ad74-c3a3-3d91-f8b9-dd2f2cc855b7@j-kuhn.de> <1062d391-5200-9b2f-6ecf-0fd3a6ea1614@oracle.com> <645fb0f1-4980-853b-5bc8-2924bafc128d@j-kuhn.de> <0FFEF0FB-FB4D-46F3-81CA-ABD78E2D2D6C@oracle.com> <3ee26c09-6f47-8675-ca1f-2e1eca3f5c3d@j-kuhn.de> Message-ID: > > Finally, we can benchmark the current approach against the LDC > approach on a per-Method basis.? The LDC approach may well be doing > more work per Method, so it's a tradeoff to determine whether > deferring that work is a win. By this last bit, I mean JMH'ing: ??? Method m1() { ?????? return Class.forName("java.lang.Object").getMethod("equals", new Class[] { Class.forName("java.lang.Object") }); ??? } vs ??? Method m2() { ??????? return bootstrap(... constant bootstrap args for above ...) ??? } From info at j-kuhn.de Sat Nov 23 22:54:51 2019 From: info at j-kuhn.de (Johannes Kuhn) Date: Sat, 23 Nov 2019 23:54:51 +0100 Subject: Looking for Sponsor: JDK-8229959 Convert proxy class to use constant dynamic In-Reply-To: References: <1391ad74-c3a3-3d91-f8b9-dd2f2cc855b7@j-kuhn.de> <1062d391-5200-9b2f-6ecf-0fd3a6ea1614@oracle.com> <645fb0f1-4980-853b-5bc8-2924bafc128d@j-kuhn.de> <0FFEF0FB-FB4D-46F3-81CA-ABD78E2D2D6C@oracle.com> <3ee26c09-6f47-8675-ca1f-2e1eca3f5c3d@j-kuhn.de> Message-ID: <4db1e33b-1f83-eda6-333b-4259fc735d46@j-kuhn.de> On 11/23/2019 10:40 PM, Brian Goetz wrote: > >> >> Finally, we can benchmark the current approach against the LDC >> approach on a per-Method basis.? The LDC approach may well be doing >> more work per Method, so it's a tradeoff to determine whether >> deferring that work is a win. > > By this last bit, I mean JMH'ing: > > ??? Method m1() { > ?????? return Class.forName("java.lang.Object").getMethod("equals", > new Class[] { Class.forName("java.lang.Object") }); > ??? } > > vs > > ??? Method m2() { > ??????? return bootstrap(... constant bootstrap args for above ...) > ??? } > > Thanks for the pointers, I did run one round on my machine - I don't have a dedicated one - so, maybe treat it with a fine grain of salt. The test code and results can be found here: https://gist.github.com/DasBrain/501fd5ac1e2ade2e28347ec666299473 Benchmark????????????????????????????? Mode? Cnt Score??????? Error? Units ProxyFindMethod.getMethod???????????? thrpt?? 25? 1505594.515 ? 42238.663? ops/s ProxyFindMethod.lookupMethod????????? thrpt?? 25?? 760530.602 ? 25074.003? ops/s ProxyFindMethod.lookupMethodCachedMH? thrpt?? 25? 4327814.284 ? 103456.616? ops/s I wrote three tests, the first one (getMethod) uses the Class.forName().getMethod(), the second uses lookup.findVirtual to get the MethodHandle every iteration, while the third one caches it in a static final field. My interpretation: If the method has to be looked up (and the VM has to do that at least once), then the old getMethod call is faster. I also suspect the Class.forName call to be optimized - on some old java versions, iirc pre-1.5, Foo.class was compiled into Class.forName("Foo"), so the JIT might do something there. So, now I have to learn how to read assembly. Good. From naoto.sato at oracle.com Sun Nov 24 02:09:14 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Sat, 23 Nov 2019 18:09:14 -0800 Subject: Turkish Time Zone name string and translation In-Reply-To: <32588966-0750-4916-8583-a4af328ecbcd@amazon.com> References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com> <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com> <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com> <95b0ed5b-8e44-7aad-3f64-4bb00c2fa4f5@oracle.com> <99070CC7-3197-4E3D-BC25-4CC0A459CBBA@amazon.com> <863d66ad-deaf-1ffc-aded-d1485cf8b213@oracle.com> <862256B3-5F3F-45C5-9591-8BAAC641D22C@amazon.com> <32588966-0750-4916-8583-a4af328ecbcd@amazon.com> Message-ID: <0f89d195-5c5e-8a70-ab08-a0aa87e3a0e5@oracle.com> Looks good. Naoto On 11/22/19 9:55 PM, Yang, Letu wrote: > Hi Naoto, > > Added it in the new webrev > https://cr.openjdk.java.net/~xliu/8234288/webrev.03/ . Thanks! > > Letu > > > On Nov 22, 2019 4:40 PM, naoto.sato at oracle.com wrote: > Hi Letu, > > You might want to add lines for "Turkey" zone as well in LocaleData? > > Naoto > > On 11/22/19 4:16 PM, Yang, Letu wrote: >> Hi Naoto, >> >> Thank you for the advice! I've uploaded a new version: https://cr.openjdk.java.net/~xliu/8234288/webrev.02/webrev/ >> >> Letu >> >> ?On 11/21/19, 9:18 AM, "naoto.sato at oracle.com" wrote: >> >>????? Hi Letu, >> >>????? The change in the resource bundle file looks good. >> >>????? As to the regression test, I would avoid adding a separate file, instead >>????? add some variations for >>????? open/test/jdk/sun/text/resources/LocaleDataTest.java as I mentioned. Add >>????? some lines in "LocaleData" file, which contains the expected resources >>????? for the COMPAT locale provider. >> >>????? Naoto >> >>????? On 11/20/19 9:43 PM, Yang, Letu wrote: >>????? > Hi Naoto, >>????? > >>????? > Thank you for the suggestions! >>????? > >>????? > I've added a new webrev: https://cr.openjdk.java.net/~xliu/8234288/webrev.01/ >>????? > >>????? > Letu >>????? > >>????? > On 11/18/19, 9:09 AM, "naoto.sato at oracle.com" wrote: >>????? > >>????? >????? Hi Letu, >>????? > >>????? >????? Here are my comments to your changes: >>????? > >>????? >????? - You will need a regression test for this fix. Take a look at >>????? >????? test/jdk/sun/text/resources/LocaleDataTest.java, and add appropriate >>????? >????? test cases. >>????? > >>????? >????? - Fix comment should follow the OpenJDK changeset guideline [1] >>????? > >>????? >????? - As to the change itself, I would put "Turkey Summer Time"/"TRST" for >>????? >????? the 3rd and 4th array elements. Even though Turkey time do not observe >>????? >????? DST, names in those slots should reflect the DST (consistent to other names) >>????? > >>????? >????? - time zone id "Turkey" (line 1050) should also point to TRT array. >>????? > >>????? >????? Naoto >>????? > >>????? >????? [1] http://openjdk.java.net/guide/producingChangeset.html >>????? > >>????? >????? On 11/17/19 8:54 PM, Yang, Letu wrote: >>????? >????? > Hi Naoto, >>????? >????? > >>????? >????? > Thank you for the clarification! >>????? >????? > >>????? >????? > Xin from my team has filed a JBS and uploaded my webrev: >>????? >????? > https://bugs.openjdk.java.net/browse/JDK-8234288 >>????? >????? > https://cr.openjdk.java.net/~xliu/8234288/webrev.00/ >>????? >????? > >>????? >????? > Letu >>????? >????? > >>????? >????? > On 11/16/19, 6:44 AM, "naoto.sato at oracle.com" wrote: >>????? >????? > >>????? >????? >????? Letu, >>????? >????? > >>????? >????? >????? Please go ahead and fix the issue in English resource. As to the >>????? >????? >????? translation, Oracle l10n will translate it in appropriate locales. >>????? >????? > >>????? >????? >????? Naoto >>????? >????? > >>????? >????? >????? On 11/15/19 5:56 PM, Yang, Letu wrote: >>????? >????? >????? > Hi Naoto >>????? >????? >????? > >>????? >????? >????? > Thank you for the quick response! We will file a ticket later today. >>????? >????? >????? > >>????? >????? >????? > Shall we make an effort on fixing and translating the strings, or you >>????? >????? >????? > prefer to take care of it at Oracle? >>????? >????? >????? > >>????? >????? >????? > Letu >>????? >????? >????? > >>????? >????? >????? > On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com wrote: >>????? >????? >????? > Hi Letu, >>????? >????? >????? > >>????? >????? >????? > Please file a JBS issue for this (component: core-libs, subcomponent: >>????? >????? >????? > java.util:i18n). >>????? >????? >????? > >>????? >????? >????? > Naoto >>????? >????? >????? > >>????? >????? >????? > On 11/15/19 3:19 PM, Yang, Letu wrote: >>????? >????? >????? >> Hi, >>????? >????? >????? >> >>????? >????? >????? >> We recently found an issue with the Time Zone name for ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own Turkish Time (TRT) zone in 2016, although the tzdata had been updated, the Time Zone name string has not been updated yet: >>????? >????? >????? >> >>????? >????? >????? >> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836 >>????? >????? >????? >> >>????? >????? >????? >> It still returns "Eastern European Time" for the TimeZone.getDisplayName call, which has a summer time while Turkish Time does not. An entry for TRT need to be added to this file, and assign to both "Europe/Istanbul" and "Asian/Istanbul". This also need to? be updated for other locales. I can create a JBS > issue for this, but I >>????? >????? >????? > am not sure whether we should fix this bug, or there is an existing >>????? >????? >????? > procedure for this kind of bug which requires language translation. >>????? >????? >????? >> >>????? >????? >????? >> Letu >>????? >????? >????? >> >>????? >????? >????? >> >>????? >????? >????? >> >>????? >????? > >>????? >????? > >>????? > >>????? > >> >> From brian.goetz at oracle.com Sun Nov 24 17:58:51 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 24 Nov 2019 12:58:51 -0500 Subject: Looking for Sponsor: JDK-8229959 Convert proxy class to use constant dynamic In-Reply-To: <4db1e33b-1f83-eda6-333b-4259fc735d46@j-kuhn.de> References: <1391ad74-c3a3-3d91-f8b9-dd2f2cc855b7@j-kuhn.de> <1062d391-5200-9b2f-6ecf-0fd3a6ea1614@oracle.com> <645fb0f1-4980-853b-5bc8-2924bafc128d@j-kuhn.de> <0FFEF0FB-FB4D-46F3-81CA-ABD78E2D2D6C@oracle.com> <3ee26c09-6f47-8675-ca1f-2e1eca3f5c3d@j-kuhn.de> <4db1e33b-1f83-eda6-333b-4259fc735d46@j-kuhn.de> Message-ID: OK, interesting.? Your interpretation seems right; that getting the MH is a big part of the expense of the LDC approach.? Caching simulates using Constant_MethodHandle_info, so that's a fair comparision.? It's not clear whether there's a performance difference getting the MH via lookup (as your approach does) vs CP resolution; measuring this is harder because once the CP is resolved, it's already cached.? But it does point at this approach being a tradeoff, where we're using a more expensive means to get our hands on the Method, in exchange for hopefully resolving fewer Methods overall (or pushing the cost to a less critical path.) You can replace Class.forName("java.lang.Object") with Object.class (which turns into an LDC) to factor out the cost of that particular reflection. It's unfortunate that InvocationHandler exposes the Method directly to the Proxy client, since a Method is a heavier object than we necessarily want, but we have limited ability to refactor here. Another direction here would be as follows: generate code like the following: ??? class Proxy$1 { ??????? private static final Class c1 = Object.class; ??????? private Method equals$bootstrap(Lookup, String, Class) { ??????????? return c1.getMethod("equals", new Class[] { c1 }); ??????? } ??????? public boolean equals(Object o) { ?????????? return ... __LDC__[equals$bootstrap...] ... ??????? } ??? } In other words, use condy to delay evaluation, but don't go through the MH machinery.? There's a subtle proof we would have to do to prove this safe; we want reflective lookups to be done using the right access control context.? This is why I factored out the Class resolution and left that in the ; since the methods of a proxy are public (can only proxy interfaces), the interesting access control is done on the class lookup.? This would result in similar costs for looking up the Method, but delaying it to first use (still paying the one-by-one condy dispatch vs doing them all as a group in .) On 11/23/2019 5:54 PM, Johannes Kuhn wrote: > On 11/23/2019 10:40 PM, Brian Goetz wrote: >> >>> >>> Finally, we can benchmark the current approach against the LDC >>> approach on a per-Method basis.? The LDC approach may well be doing >>> more work per Method, so it's a tradeoff to determine whether >>> deferring that work is a win. >> >> By this last bit, I mean JMH'ing: >> >> ??? Method m1() { >> ?????? return Class.forName("java.lang.Object").getMethod("equals", >> new Class[] { Class.forName("java.lang.Object") }); >> ??? } >> >> vs >> >> ??? Method m2() { >> ??????? return bootstrap(... constant bootstrap args for above ...) >> ??? } >> >> > Thanks for the pointers, I did run one round on my machine - I don't > have a dedicated one - so, maybe treat it with a fine grain of salt. > The test code and results can be found here: > https://gist.github.com/DasBrain/501fd5ac1e2ade2e28347ec666299473 > > Benchmark????????????????????????????? Mode? Cnt Score Error? Units > ProxyFindMethod.getMethod???????????? thrpt?? 25? 1505594.515 ? > 42238.663? ops/s > ProxyFindMethod.lookupMethod????????? thrpt?? 25?? 760530.602 ? > 25074.003? ops/s > ProxyFindMethod.lookupMethodCachedMH? thrpt?? 25? 4327814.284 ? > 103456.616? ops/s > > I wrote three tests, the first one (getMethod) uses the > Class.forName().getMethod(), the second uses lookup.findVirtual to get > the MethodHandle every iteration, while the third one caches it in a > static final field. > > My interpretation: If the method has to be looked up (and the VM has > to do that at least once), then the old getMethod call is faster. > I also suspect the Class.forName call to be optimized - on some old > java versions, iirc pre-1.5, Foo.class was compiled into > Class.forName("Foo"), so the JIT might do something there. > So, now I have to learn how to read assembly. Good. > From david.holmes at oracle.com Sun Nov 24 21:33:16 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Nov 2019 07:33:16 +1000 Subject: RFR: 8234185: Cleanup usage of canonicalize function between libjava, hotspot and libinstrument In-Reply-To: References: <6209301e-ae85-2a91-7d9e-c9096581365d@oracle.com> Message-ID: <21f83181-eea8-7b7f-9f5f-5f1a26413154@oracle.com> Hi Christoph, On 23/11/2019 12:04 am, Langer, Christoph wrote: > Hi, > > I'd like to push this change. However, running it through jdk-submit shows reproducible errors: > > Job: mach5-one-clanger-JDK-8234185-1-20191122-0927-6913189 > BuildId: 2019-11-22-0926373.christoph.langer.source > No failed tests > Tasks Summary > ? NA: 0 > ? NOTHING_TO_RUN: 0 > ? KILLED: 0 > ? PASSED: 76 > ? UNABLE_TO_RUN: 0 > ? EXECUTED_WITH_FAILURE: 1 > ? FAILED: 0 > ? HARNESS_ERROR: 0 > Build > 1 Executed with failure > o windows-x64-install-windows-x64-build-19 error while building, return value: 2 > > > Job: mach5-one-clanger-JDK-8234185-20191121-2313-6898791 > BuildId: 2019-11-21-2311357.christoph.langer.source > No failed tests > Tasks Summary > ? NA: 0 > ? NOTHING_TO_RUN: 0 > ? KILLED: 0 > ? PASSED: 76 > ? UNABLE_TO_RUN: 0 > ? EXECUTED_WITH_FAILURE: 1 > ? FAILED: 0 > ? HARNESS_ERROR: 0 > Build > 1 Executed with failure > o windows-x64-install-windows-x64-build-19 error while building, return value: 2 > > > David already had a look and let me know that the following was the reason: > > t:/workspace/open/src/java.base/windows/native/libjava/canonicalize_md.c(41): fatal error C1083: Cannot open include file: 'jdk_util.h': No such file or directory > > This is not explainable to me as I see this running through my local build and our nightly builds without problems. I also can't explain jdk_util.h can't be opened at this place - it should be there and part of the include directories... > > I'd appreciate any help... I just dug a little deeper and this is failing in part of our closed build for the install repo. There is a library there that is using canonicalize_md.c directly - i.e. it adds that file to its source files list. The build instructions don't include that directory on the include directory list - hence the failure. But it will also fail due to the name change you made. Someone will need to work with you to make the necessary changes to our code. David > Thanks > Christoph > > >> -----Original Message----- >> From: Langer, Christoph >> Sent: Donnerstag, 21. November 2019 14:19 >> To: Alan Bateman ; core-libs- >> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net >> Subject: RE: RFR: 8234185: Cleanup usage of canonicalize function between >> libjava, hotspot and libinstrument >> >> Hi Alan, >> >> thanks for the review. I'll push it then after running through jdk-submit. >> >> /Christoph >> >>> -----Original Message----- >>> From: Alan Bateman >>> Sent: Donnerstag, 21. November 2019 09:51 >>> To: Langer, Christoph ; core-libs- >>> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net >>> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function between >>> libjava, hotspot and libinstrument >>> >>> On 14/11/2019 15:37, Langer, Christoph wrote: >>>> Hi, >>>> >>>> please review this cleanup change regarding function "canonicalize" of >>> libjava. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8234185 >>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234185.0/ >>>> >>>> >>>> The goal is to cleanup how this function is defined and used. One thing is, >>> that there was an unnecessary wrapper function "Canonicalize" in jni_util.c. >>> It wrapped the call to "canonicalize". We can get rid of this wrapper. >>> Unfortunately, it is not possible to just export "canonicalize" since this will >>> conflict with a method signature from the math library, at least on modern >>> Linuxes. So I decided to call the method JDK_Canonicalize and will correctly >>> define it in jdk_util.h which can be included everywhere. >>>> >>> I think this change is okay. My main concern when initially seeing this >>> go by was that it would leak the \\?\ or \\?\UNC\ prefix into the >>> canonical File when it wasn't there previously, this would of course >>> have several implications. But I think you have it right and this is, as >>> you position, just refactoring/cleanup. >>> >>> -Alan From david.holmes at oracle.com Sun Nov 24 21:49:13 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Nov 2019 07:49:13 +1000 Subject: RFR: 8234185: Cleanup usage of canonicalize function between libjava, hotspot and libinstrument In-Reply-To: <21f83181-eea8-7b7f-9f5f-5f1a26413154@oracle.com> References: <6209301e-ae85-2a91-7d9e-c9096581365d@oracle.com> <21f83181-eea8-7b7f-9f5f-5f1a26413154@oracle.com> Message-ID: <5b46607d-c84b-086d-6241-cf2eee95d0a6@oracle.com> On 25/11/2019 7:33 am, David Holmes wrote: > Hi Christoph, > > On 23/11/2019 12:04 am, Langer, Christoph wrote: >> Hi, >> >> I'd like to push this change. However, running it through jdk-submit >> shows reproducible errors: >> >> Job: mach5-one-clanger-JDK-8234185-1-20191122-0927-6913189 >> BuildId: 2019-11-22-0926373.christoph.langer.source >> No failed tests >> Tasks Summary >> ???? NA: 0 >> ???? NOTHING_TO_RUN: 0 >> ???? KILLED: 0 >> ???? PASSED: 76 >> ???? UNABLE_TO_RUN: 0 >> ???? EXECUTED_WITH_FAILURE: 1 >> ???? FAILED: 0 >> ???? HARNESS_ERROR: 0 >> Build >> 1 Executed with failure >> o??? windows-x64-install-windows-x64-build-19 error while building, >> return value: 2 >> >> >> Job: mach5-one-clanger-JDK-8234185-20191121-2313-6898791 >> BuildId: 2019-11-21-2311357.christoph.langer.source >> No failed tests >> Tasks Summary >> ???? NA: 0 >> ???? NOTHING_TO_RUN: 0 >> ???? KILLED: 0 >> ???? PASSED: 76 >> ???? UNABLE_TO_RUN: 0 >> ???? EXECUTED_WITH_FAILURE: 1 >> ???? FAILED: 0 >> ???? HARNESS_ERROR: 0 >> Build >> 1 Executed with failure >> o??? windows-x64-install-windows-x64-build-19 error while building, >> return value: 2 >> >> >> David already had a look and let me know that the following was the >> reason: >> >> t:/workspace/open/src/java.base/windows/native/libjava/canonicalize_md.c(41): >> fatal error C1083: Cannot open include file: 'jdk_util.h': No such >> file or directory >> >> This is not explainable to me as I see this running through my local >> build and our nightly builds without problems. I also can't explain >> jdk_util.h can't be opened at this place - it should be there and part >> of the include directories... >> >> I'd appreciate any help... > > I just dug a little deeper and this is failing in part of our closed > build for the install repo. There is a library there that is using > canonicalize_md.c directly - i.e. it adds that file to its source files > list. The build instructions don't include that directory on the include > directory list - hence the failure. But it will also fail due to the > name change you made. Actually it appears that the other source code doesn't actually refer to the canonicalize function at all, so a simple fix may be possible at the build level on our side. I'm testing that now. David ----- > Someone will need to work with you to make the necessary changes to our > code. > > David > >> Thanks >> Christoph >> >> >>> -----Original Message----- >>> From: Langer, Christoph >>> Sent: Donnerstag, 21. November 2019 14:19 >>> To: Alan Bateman ; core-libs- >>> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net >>> Subject: RE: RFR: 8234185: Cleanup usage of canonicalize function >>> between >>> libjava, hotspot and libinstrument >>> >>> Hi Alan, >>> >>> thanks for the review. I'll push it then after running through >>> jdk-submit. >>> >>> /Christoph >>> >>>> -----Original Message----- >>>> From: Alan Bateman >>>> Sent: Donnerstag, 21. November 2019 09:51 >>>> To: Langer, Christoph ; core-libs- >>>> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net >>>> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function >>>> between >>>> libjava, hotspot and libinstrument >>>> >>>> On 14/11/2019 15:37, Langer, Christoph wrote: >>>>> Hi, >>>>> >>>>> please review this cleanup change regarding function "canonicalize" of >>>> libjava. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8234185 >>>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234185.0/ >>>>> >>>>> >>>>> The goal is to cleanup how this function is defined and used. One >>>>> thing is, >>>> that there was an unnecessary wrapper function "Canonicalize" in >>>> jni_util.c. >>>> It wrapped the call to "canonicalize". We can get rid of this wrapper. >>>> Unfortunately, it is not possible to just export "canonicalize" >>>> since this will >>>> conflict with a method signature from the math library, at least on >>>> modern >>>> Linuxes. So I decided to call the method JDK_Canonicalize and will >>>> correctly >>>> define it in jdk_util.h which can be included everywhere. >>>>> >>>> I think this change is okay. My main concern when initially seeing this >>>> go by was that it would leak the \\?\ or \\?\UNC\ prefix into the >>>> canonical File when it wasn't there previously, this would of course >>>> have several implications. But I think you have it right and this >>>> is, as >>>> you position, just refactoring/cleanup. >>>> >>>> -Alan From david.holmes at oracle.com Sun Nov 24 22:45:34 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Nov 2019 08:45:34 +1000 Subject: RFR: 8234185: Cleanup usage of canonicalize function between libjava, hotspot and libinstrument In-Reply-To: <5b46607d-c84b-086d-6241-cf2eee95d0a6@oracle.com> References: <6209301e-ae85-2a91-7d9e-c9096581365d@oracle.com> <21f83181-eea8-7b7f-9f5f-5f1a26413154@oracle.com> <5b46607d-c84b-086d-6241-cf2eee95d0a6@oracle.com> Message-ID: On 25/11/2019 7:49 am, David Holmes wrote: > On 25/11/2019 7:33 am, David Holmes wrote: >> Hi Christoph, >> >> On 23/11/2019 12:04 am, Langer, Christoph wrote: >>> Hi, >>> >>> I'd like to push this change. However, running it through jdk-submit >>> shows reproducible errors: >>> >>> Job: mach5-one-clanger-JDK-8234185-1-20191122-0927-6913189 >>> BuildId: 2019-11-22-0926373.christoph.langer.source >>> No failed tests >>> Tasks Summary >>> ???? NA: 0 >>> ???? NOTHING_TO_RUN: 0 >>> ???? KILLED: 0 >>> ???? PASSED: 76 >>> ???? UNABLE_TO_RUN: 0 >>> ???? EXECUTED_WITH_FAILURE: 1 >>> ???? FAILED: 0 >>> ???? HARNESS_ERROR: 0 >>> Build >>> 1 Executed with failure >>> o??? windows-x64-install-windows-x64-build-19 error while building, >>> return value: 2 >>> >>> >>> Job: mach5-one-clanger-JDK-8234185-20191121-2313-6898791 >>> BuildId: 2019-11-21-2311357.christoph.langer.source >>> No failed tests >>> Tasks Summary >>> ???? NA: 0 >>> ???? NOTHING_TO_RUN: 0 >>> ???? KILLED: 0 >>> ???? PASSED: 76 >>> ???? UNABLE_TO_RUN: 0 >>> ???? EXECUTED_WITH_FAILURE: 1 >>> ???? FAILED: 0 >>> ???? HARNESS_ERROR: 0 >>> Build >>> 1 Executed with failure >>> o??? windows-x64-install-windows-x64-build-19 error while building, >>> return value: 2 >>> >>> >>> David already had a look and let me know that the following was the >>> reason: >>> >>> t:/workspace/open/src/java.base/windows/native/libjava/canonicalize_md.c(41): >>> fatal error C1083: Cannot open include file: 'jdk_util.h': No such >>> file or directory >>> >>> This is not explainable to me as I see this running through my local >>> build and our nightly builds without problems. I also can't explain >>> jdk_util.h can't be opened at this place - it should be there and >>> part of the include directories... >>> >>> I'd appreciate any help... >> >> I just dug a little deeper and this is failing in part of our closed >> build for the install repo. There is a library there that is using >> canonicalize_md.c directly - i.e. it adds that file to its source >> files list. The build instructions don't include that directory on the >> include directory list - hence the failure. But it will also fail due >> to the name change you made. > > Actually it appears that the other source code doesn't actually refer to > the canonicalize function at all, so a simple fix may be possible at the > build level on our side. I'm testing that now. It isn't the canonicalize function that is used, it is getPrefixed, which has now been moved to the io_util_md.c file. So a fix will be a bit more involved. David > > David > ----- > >> Someone will need to work with you to make the necessary changes to >> our code. >> >> David >> >>> Thanks >>> Christoph >>> >>> >>>> -----Original Message----- >>>> From: Langer, Christoph >>>> Sent: Donnerstag, 21. November 2019 14:19 >>>> To: Alan Bateman ; core-libs- >>>> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net >>>> Subject: RE: RFR: 8234185: Cleanup usage of canonicalize function >>>> between >>>> libjava, hotspot and libinstrument >>>> >>>> Hi Alan, >>>> >>>> thanks for the review. I'll push it then after running through >>>> jdk-submit. >>>> >>>> /Christoph >>>> >>>>> -----Original Message----- >>>>> From: Alan Bateman >>>>> Sent: Donnerstag, 21. November 2019 09:51 >>>>> To: Langer, Christoph ; core-libs- >>>>> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net >>>>> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function >>>>> between >>>>> libjava, hotspot and libinstrument >>>>> >>>>> On 14/11/2019 15:37, Langer, Christoph wrote: >>>>>> Hi, >>>>>> >>>>>> please review this cleanup change regarding function >>>>>> "canonicalize" of >>>>> libjava. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8234185 >>>>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234185.0/ >>>>>> >>>>>> >>>>>> The goal is to cleanup how this function is defined and used. One >>>>>> thing is, >>>>> that there was an unnecessary wrapper function "Canonicalize" in >>>>> jni_util.c. >>>>> It wrapped the call to "canonicalize". We can get rid of this wrapper. >>>>> Unfortunately, it is not possible to just export "canonicalize" >>>>> since this will >>>>> conflict with a method signature from the math library, at least on >>>>> modern >>>>> Linuxes. So I decided to call the method JDK_Canonicalize and will >>>>> correctly >>>>> define it in jdk_util.h which can be included everywhere. >>>>>> >>>>> I think this change is okay. My main concern when initially seeing >>>>> this >>>>> go by was that it would leak the \\?\ or \\?\UNC\ prefix into the >>>>> canonical File when it wasn't there previously, this would of course >>>>> have several implications. But I think you have it right and this >>>>> is, as >>>>> you position, just refactoring/cleanup. >>>>> >>>>> -Alan From david.holmes at oracle.com Mon Nov 25 00:02:13 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Nov 2019 10:02:13 +1000 Subject: RFR: 8234185: Cleanup usage of canonicalize function between libjava, hotspot and libinstrument In-Reply-To: References: <6209301e-ae85-2a91-7d9e-c9096581365d@oracle.com> <21f83181-eea8-7b7f-9f5f-5f1a26413154@oracle.com> <5b46607d-c84b-086d-6241-cf2eee95d0a6@oracle.com> Message-ID: <1d4ed7c6-d626-053a-e077-da284a078082@oracle.com> On 25/11/2019 8:45 am, David Holmes wrote: > On 25/11/2019 7:49 am, David Holmes wrote: >> On 25/11/2019 7:33 am, David Holmes wrote: >>> Hi Christoph, >>> >>> On 23/11/2019 12:04 am, Langer, Christoph wrote: >>>> Hi, >>>> >>>> I'd like to push this change. However, running it through jdk-submit >>>> shows reproducible errors: >>>> >>>> Job: mach5-one-clanger-JDK-8234185-1-20191122-0927-6913189 >>>> BuildId: 2019-11-22-0926373.christoph.langer.source >>>> No failed tests >>>> Tasks Summary >>>> ???? NA: 0 >>>> ???? NOTHING_TO_RUN: 0 >>>> ???? KILLED: 0 >>>> ???? PASSED: 76 >>>> ???? UNABLE_TO_RUN: 0 >>>> ???? EXECUTED_WITH_FAILURE: 1 >>>> ???? FAILED: 0 >>>> ???? HARNESS_ERROR: 0 >>>> Build >>>> 1 Executed with failure >>>> o??? windows-x64-install-windows-x64-build-19 error while building, >>>> return value: 2 >>>> >>>> >>>> Job: mach5-one-clanger-JDK-8234185-20191121-2313-6898791 >>>> BuildId: 2019-11-21-2311357.christoph.langer.source >>>> No failed tests >>>> Tasks Summary >>>> ???? NA: 0 >>>> ???? NOTHING_TO_RUN: 0 >>>> ???? KILLED: 0 >>>> ???? PASSED: 76 >>>> ???? UNABLE_TO_RUN: 0 >>>> ???? EXECUTED_WITH_FAILURE: 1 >>>> ???? FAILED: 0 >>>> ???? HARNESS_ERROR: 0 >>>> Build >>>> 1 Executed with failure >>>> o??? windows-x64-install-windows-x64-build-19 error while building, >>>> return value: 2 >>>> >>>> >>>> David already had a look and let me know that the following was the >>>> reason: >>>> >>>> t:/workspace/open/src/java.base/windows/native/libjava/canonicalize_md.c(41): >>>> fatal error C1083: Cannot open include file: 'jdk_util.h': No such >>>> file or directory >>>> >>>> This is not explainable to me as I see this running through my local >>>> build and our nightly builds without problems. I also can't explain >>>> jdk_util.h can't be opened at this place - it should be there and >>>> part of the include directories... >>>> >>>> I'd appreciate any help... >>> >>> I just dug a little deeper and this is failing in part of our closed >>> build for the install repo. There is a library there that is using >>> canonicalize_md.c directly - i.e. it adds that file to its source >>> files list. The build instructions don't include that directory on >>> the include directory list - hence the failure. But it will also fail >>> due to the name change you made. >> >> Actually it appears that the other source code doesn't actually refer >> to the canonicalize function at all, so a simple fix may be possible >> at the build level on our side. I'm testing that now. > > It isn't the canonicalize function that is used, it is getPrefixed, > which has now been moved to the io_util_md.c file. So a fix will be a > bit more involved. I tried adding io_util_md.c to the library source list instead of canonicalize_md.c but that just caused a slew of other compilation failures, so I don't see any quick fix for us here. David > > David > >> >> David >> ----- >> >>> Someone will need to work with you to make the necessary changes to >>> our code. >>> >>> David >>> >>>> Thanks >>>> Christoph >>>> >>>> >>>>> -----Original Message----- >>>>> From: Langer, Christoph >>>>> Sent: Donnerstag, 21. November 2019 14:19 >>>>> To: Alan Bateman ; core-libs- >>>>> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net >>>>> Subject: RE: RFR: 8234185: Cleanup usage of canonicalize function >>>>> between >>>>> libjava, hotspot and libinstrument >>>>> >>>>> Hi Alan, >>>>> >>>>> thanks for the review. I'll push it then after running through >>>>> jdk-submit. >>>>> >>>>> /Christoph >>>>> >>>>>> -----Original Message----- >>>>>> From: Alan Bateman >>>>>> Sent: Donnerstag, 21. November 2019 09:51 >>>>>> To: Langer, Christoph ; core-libs- >>>>>> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net >>>>>> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function >>>>>> between >>>>>> libjava, hotspot and libinstrument >>>>>> >>>>>> On 14/11/2019 15:37, Langer, Christoph wrote: >>>>>>> Hi, >>>>>>> >>>>>>> please review this cleanup change regarding function >>>>>>> "canonicalize" of >>>>>> libjava. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8234185 >>>>>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234185.0/ >>>>>>> >>>>>>> >>>>>>> The goal is to cleanup how this function is defined and used. One >>>>>>> thing is, >>>>>> that there was an unnecessary wrapper function "Canonicalize" in >>>>>> jni_util.c. >>>>>> It wrapped the call to "canonicalize". We can get rid of this >>>>>> wrapper. >>>>>> Unfortunately, it is not possible to just export "canonicalize" >>>>>> since this will >>>>>> conflict with a method signature from the math library, at least >>>>>> on modern >>>>>> Linuxes. So I decided to call the method JDK_Canonicalize and will >>>>>> correctly >>>>>> define it in jdk_util.h which can be included everywhere. >>>>>>> >>>>>> I think this change is okay. My main concern when initially seeing >>>>>> this >>>>>> go by was that it would leak the \\?\ or \\?\UNC\ prefix into the >>>>>> canonical File when it wasn't there previously, this would of course >>>>>> have several implications. But I think you have it right and this >>>>>> is, as >>>>>> you position, just refactoring/cleanup. >>>>>> >>>>>> -Alan From mik3hall at gmail.com Mon Nov 25 03:41:35 2019 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 24 Nov 2019 21:41:35 -0600 Subject: jpackage ROOTDIR variable in a Windows bat file In-Reply-To: References: <43ad0e64-f5f1-c0bc-d5b1-7ac6d0589600@oracle.com> <1C99B0A1-9263-4020-B1C9-50E1BC1D1062@gmail.com> <7BC977C3-4176-4814-8BBB-033065B2D561@gmail.com> <81a59597-c7aa-fbee-d3c8-e0a8d855e7f7@oracle.com> Message-ID: > On Nov 23, 2019, at 11:45 AM, Michael Hall wrote: > > > >> On Nov 23, 2019, at 11:22 AM, Kevin Rushforth wrote: >> >> I just tried this and it worked fine for me: >> >> jpackage --java-options '-Djava.security.policy=$APPDIR/all.policy' ... >> >> (note that there should not be an extra "/app" since $APPDIR points to the app directory). >> >> It generated this in the ApplicationName/app/ApplicationName.cfg file: >> >> [JavaOptions] >> -Djava.security.policy=$APPDIR/all.policy > > Maybe something is different about running from a bat. Or I?m missing a typo or something. > Command line it seems to get past that error but gets? > > Can not find WiX tools (light.exe, candle.exe) > Download WiX 3.0 or later from?. > Error: Invalid or unsupported type: [null] > > This is from a VirtualBox Windows 10 64bit virtual machine. > > The bat file continues to get the same error. I?ll look closer to be sure it isn?t an error in my bat. > > On OS X, yes APPDIR works when I remove ?app? from the path as you indicated. To follow up on this a little bit. I installed the indicated Wix. This in turn required a .Net framework of I believe 3.5.1. I tried the latest it still didn?t work. I installed the exact version indicated and it did work, Wix then installed. I got a command line invocation to run through but still not entirely successful. If I remember right it indicated something about the installed incubator runtime not being suitable to run the application. I probably should of followed up immediately but didn?t. Sorry, about being sort of vague here. I do sort of wonder about this being a Windows jpackage dependency. I recently saw I think you on javafx mention that you didn?t like depending on 3rd party libraries? I got to thinking that I needed something better than the bat file I was using that wasn?t working at all. It occurred to me I could try doing something with my own application which is a java shell intended to invoke things like jpackage. This got me looking closer at the jpackage parameters including @filename. This seemed a simple and effective way to do what my bat file was supposed to. Also what I am thinking of adding to my app. I tried this on Windows. --input ./HalfPipe.app/Contents/app --install-dir ./outputdir --name HalfPipe --runtime-image "c:/Program Files/Java/jdk-14" --main-class us.hall.hp.common.LoaderLaunchStub --add-modules java.compiler,java.desktop,java.logging,java.management,java.prefs,java.se,java.rmi,java.scripting,java.sql,java.xml,jdk.attach,jdk.jshell --java-options '-Xmx1024m -Djava.security.policy=$APPDIR/all.policy -Dconsole=pane' --main-jar halfpipe.jar Notice the exclusive use of forward slash as per your earlier. This is run against a successfully built OS X version of the app. This currently gets? C:\Users\mik3h\Documents\halfpipe_port>jpackage @jpkg.txt WARNING: Using incubator modules: jdk.incubator.jpackage java.nio.file.FileAlreadyExistsException: C:\Users\mik3h\AppData\Local\Temp\jdk.incubator.jpackage13266515172329575129\images\win-msi.image\HalfPipe\app\HalfPipe.cfg Possibly a simple error on my part but it is not yet clear to me what. From christoph.langer at sap.com Mon Nov 25 12:38:15 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 25 Nov 2019 12:38:15 +0000 Subject: RFR: 8234185: Cleanup usage of canonicalize function between libjava, hotspot and libinstrument In-Reply-To: <1d4ed7c6-d626-053a-e077-da284a078082@oracle.com> References: <6209301e-ae85-2a91-7d9e-c9096581365d@oracle.com> <21f83181-eea8-7b7f-9f5f-5f1a26413154@oracle.com> <5b46607d-c84b-086d-6241-cf2eee95d0a6@oracle.com> <1d4ed7c6-d626-053a-e077-da284a078082@oracle.com> Message-ID: Hi David, thanks for your investigation. I'll prepare a fix to move back getPrefixed into canonicalize_md.c. However, could you please still fix your internal build in terms that it would have 'jdk_util.h' in the include path? Thanks Christoph > -----Original Message----- > From: David Holmes > Sent: Montag, 25. November 2019 01:02 > To: Langer, Christoph ; Alan Bateman > ; gerard ziemski > Cc: core-libs-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function between > libjava, hotspot and libinstrument > > > > On 25/11/2019 8:45 am, David Holmes wrote: > > On 25/11/2019 7:49 am, David Holmes wrote: > >> On 25/11/2019 7:33 am, David Holmes wrote: > >>> Hi Christoph, > >>> > >>> On 23/11/2019 12:04 am, Langer, Christoph wrote: > >>>> Hi, > >>>> > >>>> I'd like to push this change. However, running it through jdk-submit > >>>> shows reproducible errors: > >>>> > >>>> Job: mach5-one-clanger-JDK-8234185-1-20191122-0927-6913189 > >>>> BuildId: 2019-11-22-0926373.christoph.langer.source > >>>> No failed tests > >>>> Tasks Summary > >>>> ???? NA: 0 > >>>> ???? NOTHING_TO_RUN: 0 > >>>> ???? KILLED: 0 > >>>> ???? PASSED: 76 > >>>> ???? UNABLE_TO_RUN: 0 > >>>> ???? EXECUTED_WITH_FAILURE: 1 > >>>> ???? FAILED: 0 > >>>> ???? HARNESS_ERROR: 0 > >>>> Build > >>>> 1 Executed with failure > >>>> o??? windows-x64-install-windows-x64-build-19 error while building, > >>>> return value: 2 > >>>> > >>>> > >>>> Job: mach5-one-clanger-JDK-8234185-20191121-2313-6898791 > >>>> BuildId: 2019-11-21-2311357.christoph.langer.source > >>>> No failed tests > >>>> Tasks Summary > >>>> ???? NA: 0 > >>>> ???? NOTHING_TO_RUN: 0 > >>>> ???? KILLED: 0 > >>>> ???? PASSED: 76 > >>>> ???? UNABLE_TO_RUN: 0 > >>>> ???? EXECUTED_WITH_FAILURE: 1 > >>>> ???? FAILED: 0 > >>>> ???? HARNESS_ERROR: 0 > >>>> Build > >>>> 1 Executed with failure > >>>> o??? windows-x64-install-windows-x64-build-19 error while building, > >>>> return value: 2 > >>>> > >>>> > >>>> David already had a look and let me know that the following was the > >>>> reason: > >>>> > >>>> > t:/workspace/open/src/java.base/windows/native/libjava/canonicalize_md. > c(41): > >>>> fatal error C1083: Cannot open include file: 'jdk_util.h': No such > >>>> file or directory > >>>> > >>>> This is not explainable to me as I see this running through my local > >>>> build and our nightly builds without problems. I also can't explain > >>>> jdk_util.h can't be opened at this place - it should be there and > >>>> part of the include directories... > >>>> > >>>> I'd appreciate any help... > >>> > >>> I just dug a little deeper and this is failing in part of our closed > >>> build for the install repo. There is a library there that is using > >>> canonicalize_md.c directly - i.e. it adds that file to its source > >>> files list. The build instructions don't include that directory on > >>> the include directory list - hence the failure. But it will also fail > >>> due to the name change you made. > >> > >> Actually it appears that the other source code doesn't actually refer > >> to the canonicalize function at all, so a simple fix may be possible > >> at the build level on our side. I'm testing that now. > > > > It isn't the canonicalize function that is used, it is getPrefixed, > > which has now been moved to the io_util_md.c file. So a fix will be a > > bit more involved. > > I tried adding io_util_md.c to the library source list instead of > canonicalize_md.c but that just caused a slew of other compilation > failures, so I don't see any quick fix for us here. > > David > > > > > David > > > >> > >> David > >> ----- > >> > >>> Someone will need to work with you to make the necessary changes to > >>> our code. > >>> > >>> David > >>> > >>>> Thanks > >>>> Christoph > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Langer, Christoph > >>>>> Sent: Donnerstag, 21. November 2019 14:19 > >>>>> To: Alan Bateman ; core-libs- > >>>>> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > >>>>> Subject: RE: RFR: 8234185: Cleanup usage of canonicalize function > >>>>> between > >>>>> libjava, hotspot and libinstrument > >>>>> > >>>>> Hi Alan, > >>>>> > >>>>> thanks for the review. I'll push it then after running through > >>>>> jdk-submit. > >>>>> > >>>>> /Christoph > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Alan Bateman > >>>>>> Sent: Donnerstag, 21. November 2019 09:51 > >>>>>> To: Langer, Christoph ; core-libs- > >>>>>> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > >>>>>> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function > >>>>>> between > >>>>>> libjava, hotspot and libinstrument > >>>>>> > >>>>>> On 14/11/2019 15:37, Langer, Christoph wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> please review this cleanup change regarding function > >>>>>>> "canonicalize" of > >>>>>> libjava. > >>>>>>> > >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8234185 > >>>>>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234185.0/ > >>>>>>> > >>>>>>> > >>>>>>> The goal is to cleanup how this function is defined and used. One > >>>>>>> thing is, > >>>>>> that there was an unnecessary wrapper function "Canonicalize" in > >>>>>> jni_util.c. > >>>>>> It wrapped the call to "canonicalize". We can get rid of this > >>>>>> wrapper. > >>>>>> Unfortunately, it is not possible to just export "canonicalize" > >>>>>> since this will > >>>>>> conflict with a method signature from the math library, at least > >>>>>> on modern > >>>>>> Linuxes. So I decided to call the method JDK_Canonicalize and will > >>>>>> correctly > >>>>>> define it in jdk_util.h which can be included everywhere. > >>>>>>> > >>>>>> I think this change is okay. My main concern when initially seeing > >>>>>> this > >>>>>> go by was that it would leak the \\?\ or \\?\UNC\ prefix into the > >>>>>> canonical File when it wasn't there previously, this would of course > >>>>>> have several implications. But I think you have it right and this > >>>>>> is, as > >>>>>> you position, just refactoring/cleanup. > >>>>>> > >>>>>> -Alan From david.holmes at oracle.com Mon Nov 25 12:41:53 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Nov 2019 22:41:53 +1000 Subject: RFR: 8234185: Cleanup usage of canonicalize function between libjava, hotspot and libinstrument In-Reply-To: References: <6209301e-ae85-2a91-7d9e-c9096581365d@oracle.com> <21f83181-eea8-7b7f-9f5f-5f1a26413154@oracle.com> <5b46607d-c84b-086d-6241-cf2eee95d0a6@oracle.com> <1d4ed7c6-d626-053a-e077-da284a078082@oracle.com> Message-ID: <1657461f-ea1f-cd0d-f842-e5a5404afb96@oracle.com> Hi Christoph, On 25/11/2019 10:38 pm, Langer, Christoph wrote: > Hi David, > > thanks for your investigation. I'll prepare a fix to move back getPrefixed into canonicalize_md.c. However, could you please still fix your internal build in terms that it would have 'jdk_util.h' in the include path? That should be simple enough to do. David > Thanks > Christoph > >> -----Original Message----- >> From: David Holmes >> Sent: Montag, 25. November 2019 01:02 >> To: Langer, Christoph ; Alan Bateman >> ; gerard ziemski >> Cc: core-libs-dev at openjdk.java.net; hotspot-runtime- >> dev at openjdk.java.net >> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function between >> libjava, hotspot and libinstrument >> >> >> >> On 25/11/2019 8:45 am, David Holmes wrote: >>> On 25/11/2019 7:49 am, David Holmes wrote: >>>> On 25/11/2019 7:33 am, David Holmes wrote: >>>>> Hi Christoph, >>>>> >>>>> On 23/11/2019 12:04 am, Langer, Christoph wrote: >>>>>> Hi, >>>>>> >>>>>> I'd like to push this change. However, running it through jdk-submit >>>>>> shows reproducible errors: >>>>>> >>>>>> Job: mach5-one-clanger-JDK-8234185-1-20191122-0927-6913189 >>>>>> BuildId: 2019-11-22-0926373.christoph.langer.source >>>>>> No failed tests >>>>>> Tasks Summary >>>>>> ???? NA: 0 >>>>>> ???? NOTHING_TO_RUN: 0 >>>>>> ???? KILLED: 0 >>>>>> ???? PASSED: 76 >>>>>> ???? UNABLE_TO_RUN: 0 >>>>>> ???? EXECUTED_WITH_FAILURE: 1 >>>>>> ???? FAILED: 0 >>>>>> ???? HARNESS_ERROR: 0 >>>>>> Build >>>>>> 1 Executed with failure >>>>>> o??? windows-x64-install-windows-x64-build-19 error while building, >>>>>> return value: 2 >>>>>> >>>>>> >>>>>> Job: mach5-one-clanger-JDK-8234185-20191121-2313-6898791 >>>>>> BuildId: 2019-11-21-2311357.christoph.langer.source >>>>>> No failed tests >>>>>> Tasks Summary >>>>>> ???? NA: 0 >>>>>> ???? NOTHING_TO_RUN: 0 >>>>>> ???? KILLED: 0 >>>>>> ???? PASSED: 76 >>>>>> ???? UNABLE_TO_RUN: 0 >>>>>> ???? EXECUTED_WITH_FAILURE: 1 >>>>>> ???? FAILED: 0 >>>>>> ???? HARNESS_ERROR: 0 >>>>>> Build >>>>>> 1 Executed with failure >>>>>> o??? windows-x64-install-windows-x64-build-19 error while building, >>>>>> return value: 2 >>>>>> >>>>>> >>>>>> David already had a look and let me know that the following was the >>>>>> reason: >>>>>> >>>>>> >> t:/workspace/open/src/java.base/windows/native/libjava/canonicalize_md. >> c(41): >>>>>> fatal error C1083: Cannot open include file: 'jdk_util.h': No such >>>>>> file or directory >>>>>> >>>>>> This is not explainable to me as I see this running through my local >>>>>> build and our nightly builds without problems. I also can't explain >>>>>> jdk_util.h can't be opened at this place - it should be there and >>>>>> part of the include directories... >>>>>> >>>>>> I'd appreciate any help... >>>>> >>>>> I just dug a little deeper and this is failing in part of our closed >>>>> build for the install repo. There is a library there that is using >>>>> canonicalize_md.c directly - i.e. it adds that file to its source >>>>> files list. The build instructions don't include that directory on >>>>> the include directory list - hence the failure. But it will also fail >>>>> due to the name change you made. >>>> >>>> Actually it appears that the other source code doesn't actually refer >>>> to the canonicalize function at all, so a simple fix may be possible >>>> at the build level on our side. I'm testing that now. >>> >>> It isn't the canonicalize function that is used, it is getPrefixed, >>> which has now been moved to the io_util_md.c file. So a fix will be a >>> bit more involved. >> >> I tried adding io_util_md.c to the library source list instead of >> canonicalize_md.c but that just caused a slew of other compilation >> failures, so I don't see any quick fix for us here. >> >> David >> >>> >>> David >>> >>>> >>>> David >>>> ----- >>>> >>>>> Someone will need to work with you to make the necessary changes to >>>>> our code. >>>>> >>>>> David >>>>> >>>>>> Thanks >>>>>> Christoph >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Langer, Christoph >>>>>>> Sent: Donnerstag, 21. November 2019 14:19 >>>>>>> To: Alan Bateman ; core-libs- >>>>>>> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net >>>>>>> Subject: RE: RFR: 8234185: Cleanup usage of canonicalize function >>>>>>> between >>>>>>> libjava, hotspot and libinstrument >>>>>>> >>>>>>> Hi Alan, >>>>>>> >>>>>>> thanks for the review. I'll push it then after running through >>>>>>> jdk-submit. >>>>>>> >>>>>>> /Christoph >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Alan Bateman >>>>>>>> Sent: Donnerstag, 21. November 2019 09:51 >>>>>>>> To: Langer, Christoph ; core-libs- >>>>>>>> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net >>>>>>>> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function >>>>>>>> between >>>>>>>> libjava, hotspot and libinstrument >>>>>>>> >>>>>>>> On 14/11/2019 15:37, Langer, Christoph wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> please review this cleanup change regarding function >>>>>>>>> "canonicalize" of >>>>>>>> libjava. >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8234185 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234185.0/ >>>>>>>>> >>>>>>>>> >>>>>>>>> The goal is to cleanup how this function is defined and used. One >>>>>>>>> thing is, >>>>>>>> that there was an unnecessary wrapper function "Canonicalize" in >>>>>>>> jni_util.c. >>>>>>>> It wrapped the call to "canonicalize". We can get rid of this >>>>>>>> wrapper. >>>>>>>> Unfortunately, it is not possible to just export "canonicalize" >>>>>>>> since this will >>>>>>>> conflict with a method signature from the math library, at least >>>>>>>> on modern >>>>>>>> Linuxes. So I decided to call the method JDK_Canonicalize and will >>>>>>>> correctly >>>>>>>> define it in jdk_util.h which can be included everywhere. >>>>>>>>> >>>>>>>> I think this change is okay. My main concern when initially seeing >>>>>>>> this >>>>>>>> go by was that it would leak the \\?\ or \\?\UNC\ prefix into the >>>>>>>> canonical File when it wasn't there previously, this would of course >>>>>>>> have several implications. But I think you have it right and this >>>>>>>> is, as >>>>>>>> you position, just refactoring/cleanup. >>>>>>>> >>>>>>>> -Alan From rob.mckenna at oracle.com Mon Nov 25 13:31:51 2019 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 25 Nov 2019 13:31:51 +0000 Subject: RFR: 8132359 - JarURLConnection.getJarFile() resource leak when file is not found In-Reply-To: References: <20191124153317.GA7604@yoga> Message-ID: <20191125133151.GA7185@yoga> Thanks Daniel, cc'ing core-libs-dev in case there are any objections. -Rob On 25/11/19 10:47, Daniel Fuchs wrote: > Hi Rob, > > That looks good to me. I wonder if that should go to corelibs for > review as well. > > The underlying issue here is that JarURLConnection open both its > jar file and its jar file entry in its connect() method. > However, it delegates the opening of the jar file to the cache, > when uses cache is true. > In this latter case, if opening the entry throws an exception, > it can't close the jar file because the file might have come from > the cache and it might still be used by someone else. > But because getJarFile() calls connect() then there's no way > to retrieve the jar file through that (failed) connection. > > I agree that fixing the issue in URLClassPath is probably the > less risky. > > I see that your test caters for all possible setting of uses cache > and combination of success/failure when opening the jar entry, > so this give me confidence that the fix is working as intended. > > best regards, > > -- daniel > > > On 24/11/2019 15:33, Rob McKenna wrote: > > Hi folks, > > > > If a FileNotFoundException is thrown when attempting to load a class > > from a jar file, a reference to the open JarFile remains even after the > > loader is closed. The test in the webrev demonstrates the problem by > > attempting to delete the JarFile after attempting a class load. > > > > The deletion will fail as the JarFile is still in use (i.e. open) > > despite the fact that the loader has been closed. > > > > Note: the behaviour depends on the URLConnections useCaches setting so > > the test cycles through the combinations. (this helpfully found a problem > > with an earlier fix attempt) > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8132359 > > webrev: http://cr.openjdk.java.net/~robm/8132359/webrev.01/ > > > > Thanks, > > > > -Rob > > > From Alan.Bateman at oracle.com Mon Nov 25 13:49:08 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 25 Nov 2019 13:49:08 +0000 Subject: RFR: 8132359 - JarURLConnection.getJarFile() resource leak when file is not found In-Reply-To: <20191125133151.GA7185@yoga> References: <20191124153317.GA7604@yoga> <20191125133151.GA7185@yoga> Message-ID: <09dd9d37-6a51-7c41-d843-ab0bcf865299@oracle.com> Daniel's summary is useful but changing URLClassPath doesn't feel right. Are you in a hurry to find a solution to this? Just asking as I think I'd prefer to see other options explored that fixed it in the protocol handler instead. -Alan On 25/11/2019 13:31, Rob McKenna wrote: > Thanks Daniel, > > cc'ing core-libs-dev in case there are any objections. > > -Rob > > On 25/11/19 10:47, Daniel Fuchs wrote: >> Hi Rob, >> >> That looks good to me. I wonder if that should go to corelibs for >> review as well. >> >> The underlying issue here is that JarURLConnection open both its >> jar file and its jar file entry in its connect() method. >> However, it delegates the opening of the jar file to the cache, >> when uses cache is true. >> In this latter case, if opening the entry throws an exception, >> it can't close the jar file because the file might have come from >> the cache and it might still be used by someone else. >> But because getJarFile() calls connect() then there's no way >> to retrieve the jar file through that (failed) connection. >> >> I agree that fixing the issue in URLClassPath is probably the >> less risky. >> >> I see that your test caters for all possible setting of uses cache >> and combination of success/failure when opening the jar entry, >> so this give me confidence that the fix is working as intended. >> >> best regards, >> >> -- daniel >> >> >> On 24/11/2019 15:33, Rob McKenna wrote: >>> Hi folks, >>> >>> If a FileNotFoundException is thrown when attempting to load a class >>> from a jar file, a reference to the open JarFile remains even after the >>> loader is closed. The test in the webrev demonstrates the problem by >>> attempting to delete the JarFile after attempting a class load. >>> >>> The deletion will fail as the JarFile is still in use (i.e. open) >>> despite the fact that the loader has been closed. >>> >>> Note: the behaviour depends on the URLConnections useCaches setting so >>> the test cycles through the combinations. (this helpfully found a problem >>> with an earlier fix attempt) >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8132359 >>> webrev: http://cr.openjdk.java.net/~robm/8132359/webrev.01/ >>> >>> Thanks, >>> >>> -Rob >>> From andy.herrick at oracle.com Mon Nov 25 14:00:58 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 25 Nov 2019 09:00:58 -0500 Subject: jpackage ROOTDIR variable in a Windows bat file In-Reply-To: References: <43ad0e64-f5f1-c0bc-d5b1-7ac6d0589600@oracle.com> <1C99B0A1-9263-4020-B1C9-50E1BC1D1062@gmail.com> <7BC977C3-4176-4814-8BBB-033065B2D561@gmail.com> <81a59597-c7aa-fbee-d3c8-e0a8d855e7f7@oracle.com> Message-ID: <85a38efe-e572-9d79-38f4-abbcfad6c175@oracle.com> On 11/24/2019 10:41 PM, Michael Hall wrote: > >> On Nov 23, 2019, at 11:45 AM, Michael Hall wrote: >> >> >> >>> On Nov 23, 2019, at 11:22 AM, Kevin Rushforth wrote: >>> >>> I just tried this and it worked fine for me: >>> >>> jpackage --java-options '-Djava.security.policy=$APPDIR/all.policy' ... >>> >>> (note that there should not be an extra "/app" since $APPDIR points to the app directory). >>> >>> It generated this in the ApplicationName/app/ApplicationName.cfg file: >>> >>> [JavaOptions] >>> -Djava.security.policy=$APPDIR/all.policy >> Maybe something is different about running from a bat. Or I?m missing a typo or something. >> Command line it seems to get past that error but gets? >> >> Can not find WiX tools (light.exe, candle.exe) >> Download WiX 3.0 or later from?. >> Error: Invalid or unsupported type: [null] >> >> This is from a VirtualBox Windows 10 64bit virtual machine. >> >> The bat file continues to get the same error. I?ll look closer to be sure it isn?t an error in my bat. >> >> On OS X, yes APPDIR works when I remove ?app? from the path as you indicated. > To follow up on this a little bit. > > I installed the indicated Wix. This in turn required a .Net framework of I believe 3.5.1. I tried the latest it still didn?t work. I installed the exact version indicated and it did work, Wix then installed. > > I got a command line invocation to run through but still not entirely successful. If I remember right it indicated something about the installed incubator runtime not being suitable to run the application. I probably should of followed up immediately but didn?t. Sorry, about being sort of vague here. I do sort of wonder about this being a Windows jpackage dependency. I recently saw I think you on javafx mention that you didn?t like depending on 3rd party libraries? > > I got to thinking that I needed something better than the bat file I was using that wasn?t working at all. It occurred to me I could try doing something with my own application which is a java shell intended to invoke things like jpackage. This got me looking closer at the jpackage parameters including @filename. This seemed a simple and effective way to do what my bat file was supposed to. Also what I am thinking of adding to my app. I tried this on Windows. > > --input ./HalfPipe.app/Contents/app > --install-dir ./outputdir > --name HalfPipe > --runtime-image "c:/Program Files/Java/jdk-14" > --main-class us.hall.hp.common.LoaderLaunchStub > --add-modules java.compiler,java.desktop,java.logging,java.management,java.prefs,java.se,java.rmi,java.scripting,java.sql,java.xml,jdk.attach,jdk.jshell > --java-options '-Xmx1024m -Djava.security.policy=$APPDIR/all.policy -Dconsole=pane' > --main-jar halfpipe.jar > > Notice the exclusive use of forward slash as per your earlier. This is run against a successfully built OS X version of the app. This currently gets? > > C:\Users\mik3h\Documents\halfpipe_port>jpackage @jpkg.txt > WARNING: Using incubator modules: jdk.incubator.jpackage > java.nio.file.FileAlreadyExistsException: C:\Users\mik3h\AppData\Local\Temp\jdk.incubator.jpackage13266515172329575129\images\win-msi.image\HalfPipe\app\HalfPipe.cfg > > Possibly a simple error on my part but it is not yet clear to me what. 1.) - you might learn more by running with --verbose ('jpackage @jpkg.txt --verbose') if you can sift thry the excess output. 2.) in my test app I need to escape the '$' in front of APPDIR because command is being processed first by shell, for example I have: (? --java-options '-splash:\$APPDIR/boinga.jpg' ) still - I don't understand how you get a FileAlreadyExists on a cfg file in the temp directory. Oh - wait - I see the problem! ---------------------------------------- you are using the $APPDIR of one run of jpackage (albeit from a different OS) as the input dir of another run. the APPDIR contains all the files from the input dir, plus a config file .cfg so after copying all the files from the input dir, there is already a HalfPipe.cfg in the app dir before we try to create one. I can reproduce this by adding an empty file "simple.cfg" to my input dir creating an app named simple. This is probably a bug we can fix - but you should be able to work around it by removing ./HalfPipe.app/Contents/app/HalfPipe.cfg before running windows build. /Andy > > > From Alan.Bateman at oracle.com Mon Nov 25 14:35:00 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 25 Nov 2019 14:35:00 +0000 Subject: 8179320: File.getUsableSpace() returns a negative number on very large file system In-Reply-To: References: <674F3B84-3737-4F55-8D2B-B1777F91203E@oracle.com> <5328f442-ebdc-87bb-b79a-881d3f9986ac@oracle.com> Message-ID: <35b53682-ae51-7e47-f32f-3c3f3c46eb0a@oracle.com> On 15/11/2019 22:40, Brian Burkhalter wrote: > >> On Nov 15, 2019, at 2:59 AM, Alan Bateman > > wrote: >> >> On 02/11/2019 00:13, Brian Burkhalter wrote: >>> For this issue [1], please review this patch [2] and the >>> corresponding CSR [3]. >>> >>> >> One thing that isn't clear is how these methods behave when the space >> info can't be obtained. It is specified to return 0L when the path is >> not "a partition" but I think it also returns 0L when the information >> cannot be obtained. > > I?ve updated the patch [1] to address this. The difference versus > webrev.00 is [2]. > Looks okay to me. -Alan From rob.mckenna at oracle.com Mon Nov 25 16:09:24 2019 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 25 Nov 2019 16:09:24 +0000 Subject: RFR: 8132359 - JarURLConnection.getJarFile() resource leak when file is not found In-Reply-To: <09dd9d37-6a51-7c41-d843-ab0bcf865299@oracle.com> References: <20191124153317.GA7604@yoga> <20191125133151.GA7185@yoga> <09dd9d37-6a51-7c41-d843-ab0bcf865299@oracle.com> Message-ID: <20191125160924.GB7185@yoga> I'm afraid so. The option of changing the the JarURLConnection spec to indicate what could happen when the class file is missing was discussed but that will require some further thought. (and it may not necessarily result in a fix for this problem, the assumption being that behaviour changes in this code would be unwelcome) -Rob On 25/11/19 13:49, Alan Bateman wrote: > > Daniel's summary is useful but changing URLClassPath doesn't feel right. Are > you in a hurry to find a solution to this? Just asking as I think I'd prefer > to see other options explored that fixed it in the protocol handler instead. > > -Alan > > On 25/11/2019 13:31, Rob McKenna wrote: > > Thanks Daniel, > > > > cc'ing core-libs-dev in case there are any objections. > > > > -Rob > > > > On 25/11/19 10:47, Daniel Fuchs wrote: > > > Hi Rob, > > > > > > That looks good to me. I wonder if that should go to corelibs for > > > review as well. > > > > > > The underlying issue here is that JarURLConnection open both its > > > jar file and its jar file entry in its connect() method. > > > However, it delegates the opening of the jar file to the cache, > > > when uses cache is true. > > > In this latter case, if opening the entry throws an exception, > > > it can't close the jar file because the file might have come from > > > the cache and it might still be used by someone else. > > > But because getJarFile() calls connect() then there's no way > > > to retrieve the jar file through that (failed) connection. > > > > > > I agree that fixing the issue in URLClassPath is probably the > > > less risky. > > > > > > I see that your test caters for all possible setting of uses cache > > > and combination of success/failure when opening the jar entry, > > > so this give me confidence that the fix is working as intended. > > > > > > best regards, > > > > > > -- daniel > > > > > > > > > On 24/11/2019 15:33, Rob McKenna wrote: > > > > Hi folks, > > > > > > > > If a FileNotFoundException is thrown when attempting to load a class > > > > from a jar file, a reference to the open JarFile remains even after the > > > > loader is closed. The test in the webrev demonstrates the problem by > > > > attempting to delete the JarFile after attempting a class load. > > > > > > > > The deletion will fail as the JarFile is still in use (i.e. open) > > > > despite the fact that the loader has been closed. > > > > > > > > Note: the behaviour depends on the URLConnections useCaches setting so > > > > the test cycles through the combinations. (this helpfully found a problem > > > > with an earlier fix attempt) > > > > > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8132359 > > > > webrev: http://cr.openjdk.java.net/~robm/8132359/webrev.01/ > > > > > > > > Thanks, > > > > > > > > -Rob > > > > > From mark.reinhold at oracle.com Mon Nov 25 17:27:56 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 25 Nov 2019 09:27:56 -0800 (PST) Subject: New candidate JEP: 370: Foreign-Memory Access API Message-ID: <20191125172756.29B2330F46E@eggemoggin.niobe.net> https://openjdk.java.net/jeps/370 - Mark From alexey.semenyuk at oracle.com Mon Nov 25 17:29:50 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Mon, 25 Nov 2019 12:29:50 -0500 Subject: jpackage ROOTDIR variable in a Windows bat file In-Reply-To: <1C99B0A1-9263-4020-B1C9-50E1BC1D1062@gmail.com> References: <43ad0e64-f5f1-c0bc-d5b1-7ac6d0589600@oracle.com> <1C99B0A1-9263-4020-B1C9-50E1BC1D1062@gmail.com> Message-ID: <6ca82310-e277-68b8-c3fc-8663bb2a1bfa@oracle.com> On 11/23/2019 12:10 PM, Michael Hall wrote: > >> On Nov 23, 2019, at 10:51 AM, Kevin Rushforth wrote: >> >> $ROOTDIR is not a supported interface. You should use "$APPDIR" instead. Having said that, the real problem is likely your use of backslashes. I recommend using forward slashes and also enclosing it in single quotes, like this: > It is apparently sometimes a unsupported interface. Since my OS X invocation works with? > -Djava.security.policy=$ROOTDIR/app/all.policy > I?ll have to change that to APPDIR to be sure it still works. As Kevin pointed out, $ROOTDIR is a part of jpackage's internal interface. However the problem problem you face is because you use backslashes which a treated by jpackage as escape characters. This should work: --- -Djava.security.policy=$ROOTDIR/app/all.policy --- and this should work too: --- -Djava.security.policy=$ROOTDIR\\app\\all.policy --- On condition these strings don't go through any environment that does its own escape characters processing. > > But this does show you should be correct for APPDIR being supported? > JDK-8231910 Expose the APPDIR variable to applications that use jpackage > >> -Djava.security.policy='$APPDIR/all.policy' >> >> If you need to use backslashes for some reason, then you will need to use two (the first is treated as an escape character). >> > I thought java on Windows was pretty indifferent to forward or backslashes in file paths but I haven?t done much on Windows. > I figured when in Rome or on Windows do what they do. > First try keeping backslashes? > > Error: Invalid Option: [-Djava.security.policy=$APPDIR\app\all.policy] > > With forward slashes > > Error: Invalid Option: [-Djava.security.policy=$ROOTDIR/app/all.policy] Hmm, I'm surprised of this error. What is the exact value of ?java-options parameter? As I side note, I'd recommend putting each java option in a separate ?java-options jpackage parameter. jpackage supports multiple ?java-options on command line. - Alexey From alexey.semenyuk at oracle.com Mon Nov 25 17:47:38 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Mon, 25 Nov 2019 12:47:38 -0500 Subject: jpackage ROOTDIR variable in a Windows bat file In-Reply-To: <85a38efe-e572-9d79-38f4-abbcfad6c175@oracle.com> References: <43ad0e64-f5f1-c0bc-d5b1-7ac6d0589600@oracle.com> <1C99B0A1-9263-4020-B1C9-50E1BC1D1062@gmail.com> <7BC977C3-4176-4814-8BBB-033065B2D561@gmail.com> <81a59597-c7aa-fbee-d3c8-e0a8d855e7f7@oracle.com> <85a38efe-e572-9d79-38f4-abbcfad6c175@oracle.com> Message-ID: On 11/25/2019 9:00 AM, Andy Herrick wrote: > > On 11/24/2019 10:41 PM, Michael Hall wrote: >> >>> On Nov 23, 2019, at 11:45 AM, Michael Hall wrote: >>> >>> >>> >>>> On Nov 23, 2019, at 11:22 AM, Kevin Rushforth >>>> wrote: >>>> >>>> I just tried this and it worked fine for me: >>>> >>>> jpackage --java-options '-Djava.security.policy=$APPDIR/all.policy' >>>> ... >>>> >>>> (note that there should not be an extra "/app" since $APPDIR points >>>> to the app directory). >>>> >>>> It generated this in the ApplicationName/app/ApplicationName.cfg file: >>>> >>>> [JavaOptions] >>>> -Djava.security.policy=$APPDIR/all.policy >>> Maybe something is different about running from a bat. Or I?m >>> missing a typo or something. >>> Command line it seems to get past that error but gets? >>> >>> Can not find WiX tools (light.exe, candle.exe) >>> Download WiX 3.0 or later from?. >>> Error: Invalid or unsupported type: [null] >>> >>> This is from a VirtualBox Windows 10 64bit virtual machine. >>> >>> The bat file continues to get the same error. I?ll look closer to be >>> sure it isn?t an error in my bat. >>> >>> On OS X, yes APPDIR works when I remove ?app? from the path as you >>> indicated. >> To follow up on this a little bit. >> >> I installed the indicated Wix. This in turn required a .Net framework >> of I believe 3.5.1. I tried the latest it still didn?t work. I >> installed the exact version indicated and it did work, Wix then >> installed. >> >> I got a command line invocation to run through but still not entirely >> successful. If I remember right it indicated something about the >> installed incubator runtime not being suitable to run the >> application. I probably should of followed up immediately but didn?t. >> Sorry, about being sort of vague here. I do sort of wonder about this >> being a Windows jpackage dependency. I recently saw I think you on >> javafx mention that you didn?t like depending on 3rd party libraries? >> >> I got to thinking that I needed something better than the bat file I >> was using that wasn?t working at all. It occurred to me I could try >> doing something with my own application which is a java shell >> intended to invoke things like jpackage. This got me looking closer >> at the jpackage parameters including @filename. This seemed a simple >> and effective way to do what my bat file was supposed to. Also what I >> am thinking of adding to my app. I tried this on Windows. >> >> --input ./HalfPipe.app/Contents/app >> --install-dir ./outputdir Are you sure you want your app to be installed in %ProgramFiles%\outputdir directory? >> >> --name HalfPipe >> --runtime-image "c:/Program Files/Java/jdk-14" --runtime-image and --add-modules parameters should not be used together. If Java run-time image is specified with --runtime-image parameter, jpackage will not run jlink command to create custom run-time from the list of modules specified in --add-modules parameter(s). So I'd recommend to remove --runtime-image from your input. - Alexey >> --main-class us.hall.hp.common.LoaderLaunchStub >> --add-modules >> java.compiler,java.desktop,java.logging,java.management,java.prefs,java.se,java.rmi,java.scripting,java.sql,java.xml,jdk.attach,jdk.jshell >> --java-options '-Xmx1024m -Djava.security.policy=$APPDIR/all.policy >> -Dconsole=pane' >> --main-jar halfpipe.jar >> >> Notice the exclusive use of forward slash as per your earlier. This >> is run against a successfully built OS X version of the app. This >> currently gets? >> >> C:\Users\mik3h\Documents\halfpipe_port>jpackage @jpkg.txt >> WARNING: Using incubator modules: jdk.incubator.jpackage >> java.nio.file.FileAlreadyExistsException: >> C:\Users\mik3h\AppData\Local\Temp\jdk.incubator.jpackage13266515172329575129\images\win-msi.image\HalfPipe\app\HalfPipe.cfg >> >> Possibly a simple error on my part but it is not yet clear to me what. > > 1.) - you might learn more by running with --verbose ('jpackage > @jpkg.txt --verbose') if you can sift thry the excess output. > > 2.) in my test app I need to escape the '$' in front of APPDIR because > command is being processed first by shell, for example I have: (? > --java-options '-splash:\$APPDIR/boinga.jpg' ) > > still - I don't understand how you get a FileAlreadyExists on a cfg > file in the temp directory. > > Oh - wait - I see the problem! > > ---------------------------------------- > > you are using the $APPDIR of one run of jpackage (albeit from a > different OS) as the input dir of another run. > > the APPDIR contains all the files from the input dir, plus a config > file .cfg > > so after copying all the files from the input dir, there is already a > HalfPipe.cfg in the app dir before we try to create one. > > I can reproduce this by adding an empty file "simple.cfg" to my input > dir creating an app named simple. > > This is probably a bug we can fix - but you should be able to work > around it by removing > > ./HalfPipe.app/Contents/app/HalfPipe.cfg before running windows build. > > /Andy > >> >> >> From mik3hall at gmail.com Mon Nov 25 18:08:50 2019 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 25 Nov 2019 12:08:50 -0600 Subject: jpackage ROOTDIR variable in a Windows bat file In-Reply-To: <85a38efe-e572-9d79-38f4-abbcfad6c175@oracle.com> References: <43ad0e64-f5f1-c0bc-d5b1-7ac6d0589600@oracle.com> <1C99B0A1-9263-4020-B1C9-50E1BC1D1062@gmail.com> <7BC977C3-4176-4814-8BBB-033065B2D561@gmail.com> <81a59597-c7aa-fbee-d3c8-e0a8d855e7f7@oracle.com> <85a38efe-e572-9d79-38f4-abbcfad6c175@oracle.com> Message-ID: <8C0B42AA-AD0B-4BCE-9FF8-B7C59DE24FE1@gmail.com> >> >> > > 1.) - you might learn more by running with --verbose ('jpackage @jpkg.txt --verbose') if you can sift thry the excess output. > > 2.) in my test app I need to escape the '$' in front of APPDIR because command is being processed first by shell, for example I have: ( --java-options '-splash:\$APPDIR/boinga.jpg' ) > > still - I don't understand how you get a FileAlreadyExists on a cfg file in the temp directory. > > Oh - wait - I see the problem! I saw this after the verbose run. I can see Wix is busy in the verbose. But yes this was the problem. Good catch, should of thought of it myself. I remove the OS X runtime for size but removing the cfg file didn?t occur to me. My first successful run through on Windows with the current build. Now I have to figure out what I have. Thanks. Still want to verify if the escape fixes the bat shell file parameter although for Windows currently I think I?d prefer filename. From mik3hall at gmail.com Mon Nov 25 18:13:32 2019 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 25 Nov 2019 12:13:32 -0600 Subject: jpackage ROOTDIR variable in a Windows bat file In-Reply-To: References: <43ad0e64-f5f1-c0bc-d5b1-7ac6d0589600@oracle.com> <1C99B0A1-9263-4020-B1C9-50E1BC1D1062@gmail.com> <7BC977C3-4176-4814-8BBB-033065B2D561@gmail.com> <81a59597-c7aa-fbee-d3c8-e0a8d855e7f7@oracle.com> <85a38efe-e572-9d79-38f4-abbcfad6c175@oracle.com> Message-ID: >>> --install-dir ./outputdir > Are you sure you want your app to be installed in %ProgramFiles%\outputdir directory? I need to look at your detailed discussion of this. > >>> >>> --name HalfPipe >>> --runtime-image "c:/Program Files/Java/jdk-14" > --runtime-image and --add-modules parameters should not be used together. > If Java run-time image is specified with --runtime-image parameter, jpackage will not run jlink command to create custom run-time from the list of modules specified in --add-modules parameter(s). > So I'd recommend to remove --runtime-image from your input. > This I didn?t know. I?ll probably have to change my OS X build for this as well. You also mentioned ROOTDIR. If this is jpackage internal - I think it used to be OS X public - I have no problem using APPDIR instead since everything currently seems to end up there anyhow. From martinrb at google.com Mon Nov 25 18:26:19 2019 From: martinrb at google.com (Martin Buchholz) Date: Mon, 25 Nov 2019 10:26:19 -0800 Subject: Turkish Time Zone name string and translation In-Reply-To: <32588966-0750-4916-8583-a4af328ecbcd@amazon.com> References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com> <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com> <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com> <95b0ed5b-8e44-7aad-3f64-4bb00c2fa4f5@oracle.com> <99070CC7-3197-4E3D-BC25-4CC0A459CBBA@amazon.com> <863d66ad-deaf-1ffc-aded-d1485cf8b213@oracle.com> <862256B3-5F3F-45C5-9591-8BAAC641D22C@amazon.com> <32588966-0750-4916-8583-a4af328ecbcd@amazon.com> Message-ID: \ No newline at end of file Please fix. From alexey.semenyuk at oracle.com Mon Nov 25 18:26:52 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Mon, 25 Nov 2019 13:26:52 -0500 Subject: jpackage ROOTDIR variable in a Windows bat file In-Reply-To: References: <43ad0e64-f5f1-c0bc-d5b1-7ac6d0589600@oracle.com> <1C99B0A1-9263-4020-B1C9-50E1BC1D1062@gmail.com> <7BC977C3-4176-4814-8BBB-033065B2D561@gmail.com> <81a59597-c7aa-fbee-d3c8-e0a8d855e7f7@oracle.com> <85a38efe-e572-9d79-38f4-abbcfad6c175@oracle.com> Message-ID: On 11/25/2019 1:13 PM, Michael Hall wrote: > >>>> --install-dir ./outputdir >> Are you sure you want your app to be installed in >> %ProgramFiles%\outputdir directory? > > I need to look at your detailed discussion of this. --install-dir parameter specifies directory where your app will be installed. Its value is interpreted differently on Linux, OSX and Windows. On Windows the value should be relative path. The absolute installation path will be constructed from %ProgramFiles% and the value of --install-dir parameter. If --install-dir parameter is not specified, installation directory will be constructed from app name. In your case if --install-dir parameter will not be set, the installation directory will be %ProgramFiles%\HalfPipe. - Alexey > >> >>>> >>>> --name HalfPipe >>>> --runtime-image "c:/Program Files/Java/jdk-14" >> --runtime-image and --add-modules parameters should not be used together. >> If Java run-time image is specified with --runtime-image parameter, >> jpackage will not run jlink command to create custom run-time from >> the list of modules specified in --add-modules parameter(s). >> So I'd recommend to remove --runtime-image from your input. >> > > This I didn?t know. I?ll probably have to change my OS X build for > this as well. > > You also mentioned ROOTDIR. If this is jpackage internal - I think it > used to be OS X public - You can find ROOTDIR in .cfg files generated by jpackage. However this doesn't mean that using ROOTDIR outside of .cfg files is recommended. Semantics of ROOTDIR can be changed or it can be removed in the future versions of jpackage. There is APPDIR in public jpackage interface with semantics that will be stable across jpackage versions going forward. APPDIR also hides differences between app image layout on Linux, OSX and Windows. On Windows and OSX APPDIR resolves in $ROOTDIR/app, on Linux in $ROOTDIR/lib/app. > I have no problem using APPDIR instead since everything currently > seems to end up there anyhow. Great. - Alexey From letuyang at amazon.com Mon Nov 25 18:43:10 2019 From: letuyang at amazon.com (Yang, Letu) Date: Mon, 25 Nov 2019 18:43:10 +0000 Subject: Turkish Time Zone name string and translation In-Reply-To: References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com> <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com> <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com> <95b0ed5b-8e44-7aad-3f64-4bb00c2fa4f5@oracle.com> <99070CC7-3197-4E3D-BC25-4CC0A459CBBA@amazon.com> <863d66ad-deaf-1ffc-aded-d1485cf8b213@oracle.com> <862256B3-5F3F-45C5-9591-8BAAC641D22C@amazon.com> <32588966-0750-4916-8583-a4af328ecbcd@amazon.com> Message-ID: <7C49485A-7967-4F56-B00F-A4D3B178C709@amazon.com> Fixed in https://cr.openjdk.java.net/~xliu/8234288/webrev.04/ Thanks! From: Martin Buchholz Date: Monday, November 25, 2019 at 10:27 AM To: "Yang, Letu" Cc: "core-libs-dev at openjdk.java.net" , "i18n-dev at openjdk.java.net" , "naoto.sato at oracle.com" , Leo Jiang , "Liu, Xin" Subject: Re: Turkish Time Zone name string and translation \ No newline at end of file Please fix. From mandy.chung at oracle.com Mon Nov 25 18:52:38 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 25 Nov 2019 10:52:38 -0800 Subject: RFR: JEP 367: Remove the Pack200 Tools and API In-Reply-To: <8fe0abd5-f154-292b-25fc-0bc907633037@oracle.com> References: <09dc53f1-9208-3b1f-3ee6-e0e22210afc5@oracle.com> <96643033-bcac-20f3-32d6-3152a6926459@oracle.com> <8eccfd0c-04da-dc09-2e1f-a76b61fef519@oracle.com> <1e68fb03-814b-b671-346e-faa55b068a77@oracle.com> <8fe0abd5-f154-292b-25fc-0bc907633037@oracle.com> Message-ID: On 11/22/19 1:30 PM, Vicente Romero wrote: > [1] http://cr.openjdk.java.net/~vromero/8234542/webrev.03/ make/lib/Lib-jdk.pack.gmk should be removed. make/scripts/compare_exceptions.sh.incl ??? Should ./lib/libunpack.so also be removed? make/scripts/compare.sh ??? line 535-543 invokes unpack200.?? You should get the advice from the build team what to be done with this file (or file a JBS issue as a follow-up) Mandy From david.lloyd at redhat.com Mon Nov 25 20:04:51 2019 From: david.lloyd at redhat.com (David Lloyd) Date: Mon, 25 Nov 2019 14:04:51 -0600 Subject: New candidate JEP: 370: Foreign-Memory Access API In-Reply-To: <20191125172756.29B2330F46E@eggemoggin.niobe.net> References: <20191125172756.29B2330F46E@eggemoggin.niobe.net> Message-ID: On Mon, Nov 25, 2019 at 11:28 AM wrote: > > https://openjdk.java.net/jeps/370 Looks pretty interesting! Why make the API user deal with VarHandles though, as opposed to (say) putting accessor methods directly onto MemoryAddress? -- - DML From maurizio.cimadamore at oracle.com Mon Nov 25 21:09:03 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 25 Nov 2019 21:09:03 +0000 Subject: New candidate JEP: 370: Foreign-Memory Access API In-Reply-To: References: <20191125172756.29B2330F46E@eggemoggin.niobe.net> Message-ID: On 25/11/2019 20:04, David Lloyd wrote: > On Mon, Nov 25, 2019 at 11:28 AM wrote: >> https://openjdk.java.net/jeps/370 > Looks pretty interesting! Why make the API user deal with VarHandles > though, as opposed to (say) putting accessor methods directly onto > MemoryAddress? While this could be done (and it was considered early during the design phase), we decided against it for two reasons: first, the VarHandle API is very expressive and already supports. atomic compareAndSwap? operations out of the box, which are _very_ handy when dealing with shared memory segments. If we had to add all the methods from the VarHandle API, multiplied by _each_ possible carrier type, the API footprint would quickly balloon up. The second motivation is that memory access VarHandles are pretty clever things - once you define e.g. a layout for a bidimensional matrix like this: [ [1, 2, 3, 4, 5 ], [6, 7, 8, 9, 10 ] ] Then you can get a memory access VarHandle which access the following slice: [ [1, 3, 5] [6, 8, 10] ] (or even obtain the element 'backwards' using a negative step!). Stuff like this would be hard to achieve with instance methods on MemoryAddress/Segment. In other words, decoupling access from the description of a segment allows us to be more expressive in how access is achieved, which is, I think, a benefit of the design. To address basic usability concerns (e.g. I just want to dereference an int at a given address), it would be best to provide a bunch of _static_ dereference helpers for the common cases, so that users won't have to create var handles manually, in all cases. I suspect that, during incubation, we will get a better sense of which "usability" shortcuts would make more sense to invest into, given some concrete feedback. Cheers Maurizio From naoto.sato at oracle.com Mon Nov 25 21:16:55 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 25 Nov 2019 13:16:55 -0800 Subject: [14] RFR: 8222756: Plural support in CompactNumberFormat Message-ID: <350d65d3-1c97-bba9-485c-b393fbbb899d@oracle.com> Hello, CompactNumberFormat has been added since JDK 12 to support compact number formatting, such as 10_000 being formatted as "10K." [1] It works fine for English, however, not for other languages that take plural forms in formatted number prefixes/suffixes. In order to fix this, I filed the following CSR to extend the current CompactNumberFormat spec: https://bugs.openjdk.java.net/browse/JDK-8232633 It basically accommodates the plural prefix/suffix forms into the existing compact patterns array, so that the existing compact number format works compatibly. The plural rules are solely based on the CLDR's plural language rules [2] Here is the implementation of the CSR: https://cr.openjdk.java.net/~naoto/8222756/webrev.00/ Please review the CSR as well as its implementation. Naoto [1] https://bugs.openjdk.java.net/browse/JDK-8177552 [2] https://unicode.org/reports/tr35/tr35-numbers.html#Language_Plural_Rules From joe.darcy at oracle.com Tue Nov 26 01:46:28 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 25 Nov 2019 17:46:28 -0800 Subject: JDK 14 RFR of JDK-8234781: Update description of InvalidClassException to include more conditions Message-ID: <0d6e518d-545b-f9be-fdce-8dd9d093a93f@oracle.com> Hello, Noticed in the context of doing some other reviews, the spec for the serialization exception InvalidClassException does not have an exhaustive and up-date-date listing of the conditions where the exception in thrown: ??? JDK-8234781: Update description of InvalidClassException to include more conditions Please review the patch below to include the missing condition and add a catch-all clause to implicitly cover any future changes to the serialization spec (correct by default, event if not as precise as possible). This would not preclude making more precise updates of course. Thanks, -Joe diff -r a74627659f96 src/java.base/share/classes/java/io/InvalidClassException.java --- a/src/java.base/share/classes/java/io/InvalidClassException.java Mon Nov 25 15:00:32 2019 +0100 +++ b/src/java.base/share/classes/java/io/InvalidClassException.java Mon Nov 25 17:31:51 2019 -0800 @@ -33,6 +33,10 @@ ? *????? descriptor read from the stream ? *
  • The class contains unknown datatypes ? *
  • The class does not have an accessible no-arg constructor + *
  • The ObjectStreamClass of an enum constant does not represent + * an enum type + *
  • Other conditions given in the Java Object Serialization + * Specification ? * ? * ? * @author? unascribed From Alan.Bateman at oracle.com Tue Nov 26 08:36:59 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Nov 2019 08:36:59 +0000 Subject: JDK 14 RFR of JDK-8234781: Update description of InvalidClassException to include more conditions In-Reply-To: <0d6e518d-545b-f9be-fdce-8dd9d093a93f@oracle.com> References: <0d6e518d-545b-f9be-fdce-8dd9d093a93f@oracle.com> Message-ID: <81f22e8e-7bdf-2276-21ed-bdd105556861@oracle.com> On 26/11/2019 01:46, Joe Darcy wrote: > : > > Please review the patch below to include the missing condition and add > a catch-all clause to implicitly cover any future changes to the > serialization spec (correct by default, event if not as precise as > possible). This would not preclude making more precise updates of course. Looks okay, just a minor nit that the new list items use different line wrapping to the existing items so that should be fixed before pushing. -Alan. From martin.doerr at sap.com Tue Nov 26 10:43:51 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 26 Nov 2019 10:43:51 +0000 Subject: RFR: 8234525: enable link-time section-gc for linux s390x to remove unused code In-Reply-To: References: Message-ID: Hi Matthias and Erik, I also think this is an interesting option. I like the idea to generate smaller libraries. In addition to that, I could also imagine building with -Os (size optimized) by default and only select -O3 for performance critical files (e.g. C2's register allocation, some gc code, ...). If we want to go into such a direction for all linux platforms and want to use this s390 only change as some kind of pipe cleaner, I think this change is fine and can get pushed. Otherwise, I think building s390 differently and not intending to do the same for other linux platforms would be not so good. We should only make sure the exported symbols are set up properly to avoid that this optimization throws out too much. My 50 Cents. Best regards, Martin > -----Original Message----- > From: build-dev On Behalf Of > Baesken, Matthias > Sent: Freitag, 22. November 2019 16:01 > To: Erik Joelsson ; 'build-dev at openjdk.java.net' > ; core-libs-dev at openjdk.java.net > Subject: RE: RFR: 8234525: enable link-time section-gc for linux > s390x to remove unused code > > Hi Erik, > yes it makes the build more chatty - > our linux s390 product build log of jdk/jdk goes from ~ 60.000 lines to ~ > 123.000 lines with the patch. > > However the change is linux s390 only so I guess it will not disturb other > people ( in case we bring it to more platforms later on, we could remove the > printing or make it configurable ). > > Additionally the "chatty" output is used currently for eliminating unused > functions + data cross-platform > (see for example https://bugs.openjdk.java.net/browse/JDK-8234629 ). > > Best regards, Matthias > > > > > > > Hello Matthias, > > > > This looks like an interesting change. If you want to enable this for > > s390x, I'm ok with it. If it works out well, perhaps we can find a way > > to expand this to other architectures. > > > > Do you really want to set --print-gc-sections by default? I would assume > > that makes the build quite chatty. > > > > /Erik > > > > On 2019-11-21 00:54, Baesken, Matthias wrote: > > > Hello, > > > > > > gcc and ld can be instructed to work together to "garbage collect" unused > > input sections. > > > This feature eliminates unused code from native libraries. As a > prerequisite > > to take full advantage of the feature, > > > the source files need to be compiled with "-ffunction-sections -fdata- > > sections". > > > > > > Details on what happens can be found in the ld documentation: > > https://linux.die.net/man/1/ld . > > > See the description of --gc-sections and --print-gc-sections therein. > > > For more detailed insights there is a talk available from ELC2010: > > https://elinux.org/images/2/2d/ELC2010-gc-sections_Denys_Vlasenko.pdf > > > > > > My change enables the unused code elimination on linux s390x . > > > (on the other Linux platforms, there are still issues to be solved with the > > serviceability agent, but we do not have the serviceability agent on linux > > s390x). > > > > > > The change has 2 benefits : > > > - native libs with unused code get smaller (some get alot smaller) > > > some example lib sizes from linuxs390x (product build) : > > > default settings / link-time gc-sections > > > libmlib_image.so 556K 536K > > > libjavajpeg.so 300K 292K > > > libsplashscreen.so 412K 268K > > > libfontmanager.so 1.4M 864K > > > libjvm.so 19M 17M > > > > > > - the flag --print-gc-sections outputs the removed sections when calling > > the linker; > > > this helps a lot to find coding "waiting for" cross-platform removal. > > > > > > > > > Here is an example output of --print-gc-sections for the libnet-build (linux > > s390x) : > > > > > > /bin/ld: Removing unused section '.bss.my_gconf_init_func' in file > > '/builddir/support/native/java.base/libnet/DefaultProxySelector.o' <--- > > seems to be dead > > > /bin/ld: Removing unused section '.text.NET_ReadV' in file > > '/builddir/support/native/java.base/libnet/linux_close.o' <--- > seems > > to be dead, I requested cross-platform removal with > > https://bugs.openjdk.java.net/browse/JDK-8234501 > > > /bin/ld: Removing unused section '.text.getInet6Address_scopeifname' > in > > file '/builddir/support/native/java.base/libnet/net_util.o' <--- seems to > be > > dead > > > /bin/ld: Removing unused section '.text.getInet6Address_scopeid_set' in > > file '/builddir/support/native/java.base/libnet/net_util.o' <--- seems to > be > > dead > > > /bin/ld: Removing unused section '.text.getInetAddress_hostName' in > file > > '/builddir/support/native/java.base/libnet/net_util.o' <--- seems to be > > dead > > > /bin/ld: Removing unused section '.text.setDefaultScopeID' in file > > '/builddir/support/native/java.base/libnet/net_util_md.o' <--- seems > to > > be dead indeed > > > /bin/ld: Removing unused section '.text.getDefaultScopeID' in file > > '/builddir/support/native/java.base/libnet/net_util_md.o' <--- seems > to > > be dead indeed > > > /bin/ld: Removing unused section '.text.kernelIsV24' in file > > '/builddir/support/native/java.base/libnet/net_util_md.o' <--- > > seems to be dead indeed > > > /bin/ld: Removing unused section '.bss.ni_defaultIndexID.8722' in file > > '/builddir/support/native/java.base/libnet/net_util_md.o' <--- only > used > > in getDefaultScopeID , which is dead > > > /bin/ld: Removing unused section '.bss.ni_class.8721' in file > > '/builddir/support/native/java.base/libnet/net_util_md.o' <--- only > > used in getDefaultScopeID , which is dead > > > /bin/ld: Removing unused section '.bss.vinit24' in file > > '/builddir/support/native/java.base/libnet/net_util_md.o' <--- > > only used in kernelIsV24 which is dead > > > /bin/ld: Removing unused section '.bss.kernelV24' in file > > '/builddir/support/native/java.base/libnet/net_util_md.o' <--- > only > > used in kernelIsV24 which is dead > > > > > > bug/webrev : > > > https://bugs.openjdk.java.net/browse/JDK-8234525 > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8234525.1/ > > > > > > Thanks, Matthias > > > > > > From julia.boes at oracle.com Tue Nov 26 10:46:23 2019 From: julia.boes at oracle.com (Julia Boes) Date: Tue, 26 Nov 2019 10:46:23 +0000 Subject: RFR: 8234799: Word missing in javadoc of java.util.Arrays Message-ID: <97c16151-4a77-230a-9cf1-513fbf60f284@oracle.com> Hi, This is a minor fix, a word was missing in the javadoc of Arrays.compare(compare(T[] a, T[] b). Bug: https://bugs.openjdk.java.net/browse/JDK-8234799 Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8234799/webrev.00/ Regards, Julia From daniel.fuchs at oracle.com Tue Nov 26 10:50:27 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 26 Nov 2019 10:50:27 +0000 Subject: RFR: 8234799: Word missing in javadoc of java.util.Arrays In-Reply-To: <97c16151-4a77-230a-9cf1-513fbf60f284@oracle.com> References: <97c16151-4a77-230a-9cf1-513fbf60f284@oracle.com> Message-ID: <343b951f-04b8-402b-71f8-48f7504d8816@oracle.com> Hi Julia, Looks good to me. But can you find out if there exists a test where this statement is verified? best regards, -- daniel On 26/11/2019 10:46, Julia Boes wrote: > Hi, > > This is a minor fix, a word was missing in the javadoc of > Arrays.compare(compare(T[] a, T[] b). > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8234799 > > Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8234799/webrev.00/ > > > Regards, > > Julia > > From chris.hegarty at oracle.com Tue Nov 26 10:53:12 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 26 Nov 2019 10:53:12 +0000 Subject: JDK 14 RFR of JDK-8234781: Update description of InvalidClassException to include more conditions In-Reply-To: <0d6e518d-545b-f9be-fdce-8dd9d093a93f@oracle.com> References: <0d6e518d-545b-f9be-fdce-8dd9d093a93f@oracle.com> Message-ID: The change looks good to me Joe. Thanks for adding the catch-all clause. This will cover the ?bad? record class file, where the canonical constructor is not present. -Chris. > On 26 Nov 2019, at 01:46, Joe Darcy wrote: > > Hello, > > Noticed in the context of doing some other reviews, the spec for the serialization exception InvalidClassException does not have an exhaustive and up-date-date listing of the conditions where the exception in thrown: > > JDK-8234781: Update description of InvalidClassException to include more conditions > > Please review the patch below to include the missing condition and add a catch-all clause to implicitly cover any future changes to the serialization spec (correct by default, event if not as precise as possible). This would not preclude making more precise updates of course. > > Thanks, > > -Joe > > diff -r a74627659f96 src/java.base/share/classes/java/io/InvalidClassException.java > --- a/src/java.base/share/classes/java/io/InvalidClassException.java Mon Nov 25 15:00:32 2019 +0100 > +++ b/src/java.base/share/classes/java/io/InvalidClassException.java Mon Nov 25 17:31:51 2019 -0800 > @@ -33,6 +33,10 @@ > * descriptor read from the stream > *
  • The class contains unknown datatypes > *
  • The class does not have an accessible no-arg constructor > + *
  • The ObjectStreamClass of an enum constant does not represent > + * an enum type > + *
  • Other conditions given in the Java Object Serialization > + * Specification > * > * > * @author unascribed > From matthias.baesken at sap.com Tue Nov 26 12:53:07 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 26 Nov 2019 12:53:07 +0000 Subject: RFR: 8234525: enable link-time section-gc for linux s390x to remove unused code In-Reply-To: References: Message-ID: Hi Martin , > Hi Matthias and Erik, > > I also think this is an interesting option. > > I like the idea to generate smaller libraries. In addition to that, I could also > imagine building with -Os (size optimized) by default and only select -O3 for > performance critical files (e.g. C2's register allocation, some gc code, ...). > This is a good idea . However I would like to look into this separately in another change . ( Maybe there should also be a configure setting to select for size vs. speed optimization ) > If we want to go into such a direction for all linux platforms and want to use > this s390 only change as some kind of pipe cleaner, I think this change is fine > and can get pushed. Yes , that was my intention. Erik, may I add you as a reviewer too ? Best regards, Matthias > Otherwise, I think building s390 differently and not intending to do the same > for other linux platforms would be not so good. > > We should only make sure the exported symbols are set up properly to avoid > that this optimization throws out too much. > > My 50 Cents. > > Best regards, > Martin > From mik3hall at gmail.com Tue Nov 26 14:48:10 2019 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 26 Nov 2019 08:48:10 -0600 Subject: jpackage ROOTDIR variable in a Windows bat file In-Reply-To: References: <43ad0e64-f5f1-c0bc-d5b1-7ac6d0589600@oracle.com> <1C99B0A1-9263-4020-B1C9-50E1BC1D1062@gmail.com> <7BC977C3-4176-4814-8BBB-033065B2D561@gmail.com> <81a59597-c7aa-fbee-d3c8-e0a8d855e7f7@oracle.com> <85a38efe-e572-9d79-38f4-abbcfad6c175@oracle.com> Message-ID: <88728D87-6DE5-4568-8157-9E2925E02855@gmail.com> > On Nov 25, 2019, at 11:47 AM, Alexey Semenyuk wrote: > >>> >>> --name HalfPipe >>> --runtime-image "c:/Program Files/Java/jdk-14" > --runtime-image and --add-modules parameters should not be used together. > If Java run-time image is specified with --runtime-image parameter, jpackage will not run jlink command to create custom run-time from the list of modules specified in --add-modules parameter(s). > So I'd recommend to remove --runtime-image from your input. Good catch on this one as well. I must have not had it added at some point so I had the ?add-modules. Maybe sometime ?runtime-image seemed to help in running multiple runtimes for the machine and jpackage or sometime it seemed like a quick fix for a missing modules problem. After networking errors I did have to include jdk.crypto.ec as per? https://stackoverflow.com/questions/54770538/received-fatal-alert-handshake-failure-in-jlinked-jre It is not immediately clear to me how I could of anticipated the need for this module (base) Michaels-MBP:halfpipe_jpkg mjh$ jdeps outputdir/HalfPipe.app/Contents/app/halfpipe.jar | grep jdk.crypto.ec (base) Michaels-MBP:halfpipe_jpkg mjh$ jdeps outputdir/HalfPipe.app/Contents/app/httpclient.4.5.6.jar | grep jdk.crypto.ec (base) Michaels-MBP:halfpipe_jpkg mjh$ jdeps outputdir/HalfPipe.app/Contents/app/httpcore.4.4.10.jar | grep jdk.crypto.ec All show nothing. But the app appears to work fine after adding it. Before -rw-r--r--@ 1 mjh staff 107814191 Nov 26 07:37 HalfPipe-1.0.dmg After -rw-r--r--@ 1 mjh staff 70825384 Nov 26 07:50 HalfPipe-1.0.dmg So the application is seeing some benefit from modular on size now. If some options are more or less mutually exclusive would it be an idea if jpackage issued some warnings/errors? From julia.boes at oracle.com Tue Nov 26 15:57:32 2019 From: julia.boes at oracle.com (Julia Boes) Date: Tue, 26 Nov 2019 15:57:32 +0000 Subject: RFR: 8234799: Word missing in javadoc of java.util.Arrays In-Reply-To: <343b951f-04b8-402b-71f8-48f7504d8816@oracle.com> References: <97c16151-4a77-230a-9cf1-513fbf60f284@oracle.com> <343b951f-04b8-402b-71f8-48f7504d8816@oracle.com> Message-ID: <6718e650-f8da-cae0-881d-9a2ebebd40f2@oracle.com> Hi, The statement is indeed asserted in test/jdk/java/util/Arrays/ArraysEqCmpTest.testNullElementsInObjectArray(). Also, Lance pointed out that a CSR is required for this fix. CSR: https://bugs.openjdk.java.net/browse/JDK-8234810 Regards, Julia On 26/11/2019 10:50, Daniel Fuchs wrote: > Hi Julia, > > Looks good to me. But can you find out if there exists a test > where this statement is verified? > > best regards, > > -- daniel > > On 26/11/2019 10:46, Julia Boes wrote: >> Hi, >> >> This is a minor fix, a word was missing in the javadoc of >> Arrays.compare(compare(T[] a, T[] b). >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8234799 >> >> Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8234799/webrev.00/ >> >> >> Regards, >> >> Julia >> >> > From erik.joelsson at oracle.com Tue Nov 26 16:28:17 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 26 Nov 2019 08:28:17 -0800 Subject: RFR: 8234525: enable link-time section-gc for linux s390x to remove unused code In-Reply-To: References: Message-ID: <17a27614-2ada-6929-6dc5-a2c8c4a2255d@oracle.com> On 2019-11-26 04:53, Baesken, Matthias wrote: > Erik, may I add you as a reviewer too ? Yes. /Erik From daniel.fuchs at oracle.com Tue Nov 26 16:45:55 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 26 Nov 2019 16:45:55 +0000 Subject: RFR: 8234799: Word missing in javadoc of java.util.Arrays In-Reply-To: <6718e650-f8da-cae0-881d-9a2ebebd40f2@oracle.com> References: <97c16151-4a77-230a-9cf1-513fbf60f284@oracle.com> <343b951f-04b8-402b-71f8-48f7504d8816@oracle.com> <6718e650-f8da-cae0-881d-9a2ebebd40f2@oracle.com> Message-ID: Looks good! best regards, -- daniel On 26/11/2019 15:57, Julia Boes wrote: > Hi, > > The statement is indeed asserted in > test/jdk/java/util/Arrays/ArraysEqCmpTest.testNullElementsInObjectArray(). > > Also, Lance pointed out that a CSR is required for this fix. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8234810 > > Regards, > > Julia From matthias.baesken at sap.com Tue Nov 26 17:06:25 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 26 Nov 2019 17:06:25 +0000 Subject: RFR: 8234821: remove unused functions from libjli Message-ID: Hello, please review this small change . It removed unneeded functions from libjli (shown by link-time-gc) . libjli contains a few functions that are shown as unused when applying link-time-gc . Those functions fall into 2 categories : - totally unused/uncalled functions (can be deleted ) - functions that are always inlined, but still kept separate when linking (making them static often helps to remove the unneeded duplicate ) ( Similar approach has been done to libnet , see : 8234629: remove unused functions from libnet ) Thanks, Matthias Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8234821 http://cr.openjdk.java.net/~mbaesken/webrevs/8234821.0/ From lance.andersen at oracle.com Tue Nov 26 17:49:16 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 26 Nov 2019 12:49:16 -0500 Subject: RFR: 8234799: Word missing in javadoc of java.util.Arrays In-Reply-To: References: <97c16151-4a77-230a-9cf1-513fbf60f284@oracle.com> <343b951f-04b8-402b-71f8-48f7504d8816@oracle.com> <6718e650-f8da-cae0-881d-9a2ebebd40f2@oracle.com> Message-ID: +1 > On Nov 26, 2019, at 11:45 AM, Daniel Fuchs wrote: > > Looks good! > > best regards, > > -- daniel > > On 26/11/2019 15:57, Julia Boes wrote: >> Hi, >> The statement is indeed asserted in test/jdk/java/util/Arrays/ArraysEqCmpTest.testNullElementsInObjectArray(). >> Also, Lance pointed out that a CSR is required for this fix. >> CSR: https://bugs.openjdk.java.net/browse/JDK-8234810 >> Regards, >> Julia 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 Tue Nov 26 18:47:51 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 26 Nov 2019 13:47:51 -0500 Subject: RFR of JDK-8232446: logging enhancement for rmi when socket closed In-Reply-To: References: <5048d354-a480-ac6d-e46d-a14ce4349691@oracle.com> <9db082f9-6e16-9e5e-1d99-280bbd381e8f@gmail.com> <50bf13f3-f284-f3f4-1256-8ac51929637b@oracle.com> Message-ID: Hi Hamlin, ok, but it looses the logging of the connection close when the socket is null. I intended to suggest that the logging happened before/outside the test for socket != null. if (TCPTransport.tcpLog.isLoggable(Log.BRIEF)) { TCPTransport.tcpLog.log(Log.BRIEF,"close connection, socket: " + socket); }if (socket != null) { Thanks, Roger On 11/22/19 2:54 AM, Hamlin Li wrote: > Hi Roger, > > Thank you for reviewing, I have updated as you suggested: > http://cr.openjdk.java.net/~mli/8232446/webrev.01/ > > Thank you > > -Hamlin > > On 2019/11/18 11:48 PM, Roger Riggs wrote: >> Hi Hamlin, >> >> TCPConnection.java:212: >> >> Keep the "close connection" logging and add the socket to the same >> log message: >> >> If anyone is scraping the log, they won't loose this message. >> TCPTransport.tcpLog.log(Log.BRIEF, "close connection, socket: " + >> socket); >> >> TCPTransport.java >> >> 277-278:? combine the message to be one logging call. >> server socket >> 289: use Log.BRIEF, avoid creating mixture of and too many log levels. >> >> Reword the log messages so they each begin with "server socket...", >> or "server socket close"... >> it makes it easier to grep for and coorelate related messages >> >> Thanks, Roger >> >> >> On 11/6/19 7:02 AM, Hamlin Li wrote: >>> >>> On 2019/11/6 5:36 PM, Peter Levart wrote: >>>> Hi Hamlin, >>>> >>>> in TCPTransport.decrementExportCount(): >>>> >>>> ?283???????????? try { >>>> ?284???????????????? if (tcpLog.isLoggable(Log.BRIEF)) { >>>> ?285???????????????????? tcpLog.log(Log.BRIEF, "close server socket >>>> on " + ss); >>>> ?286???????????????? } >>>> ?287???????????????? ss.close(); >>>> ?288???????????? } catch (IOException e) { >>>> ?289???????????? } >>>> >>>> ...you could add a log statement to the catch block too. Or even >>>> better, rearrange for IOException to be thrown from that method and >>>> deal with it in two places: >>>> >>>> - in exportObject() - add it as suppressed exception to exception >>>> thrown from super.exportObject(). >>>> - in targetUnexported() - log it or wrap it into >>>> UncheckedIOException (depending on what are the callers of >>>> targetUnexported()) >>>> >>>> What do you think? >>> Thanks Peter. >>> >>> I agree. I adopt your first suggestion: add log statement to catch >>> block, as I think it's simple/straight and sufficient to help diagnose. >>> >>> And I also add log for catch blocks in other close places. >>> >>> The change is updated in place at: >>> http://cr.openjdk.java.net/~mli/8232446/webrev.00/ >>> >>> >>> Thank you >>> >>> -Hamlin >>> >>>> >>>> Regards, Peter >>>> >>>> >>>> >>>> On 11/6/19 3:07 AM, Hamlin Li wrote: >>>>> Would you please review the patch? >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8232446 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~mli/8232446/webrev.00/ >>>>> >>>>> >>>>> We have some intermittent failures in rmi related to socket >>>>> closing, this is to add more logging to help diagnose the issues. >>>>> >>>>> >>>>> Thanks you >>>>> >>>>> -Hamlin >>>>> >>>> >> From sergei.tsypanov at yandex.ru Tue Nov 26 19:29:06 2019 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Tue, 26 Nov 2019 21:29:06 +0200 Subject: [PATCH] Simplification proposal regarding TYPE-field initialization in primitive wrappers Message-ID: <93310181574796546@vla4-4046ec513d04.qloud-c.yandex.net> Hello, while using java.lang.Integer.TYPE I've found out that currently wrapper classes for primitives initialize their own TYPE-fields by calling native method java.lang.Class.getPrimitiveClass(). This can be simplified by changing existing declaration (here for java.lang.Integer) @SuppressWarnings("unchecked") public static final Class TYPE = (Class) Class.getPrimitiveClass("int"); to public static final Class TYPE = int.class; This is likely to improve start-up time as Class.getPrimitiveClass() is called 9 times (8 primitive type wrappers + java.lang.Void), after the change this method is not called at all and thus can be removed along with its backing C++ code on VM-side. The fields are initialized purely on Java side. I've verified correctness of the substitution with this test run on JDK 11 @Test void name() { assert void.class == Void.TYPE; assert boolean.class == Boolean.TYPE; assert byte.class == Byte.TYPE; assert char.class == Character.TYPE; assert short.class == Short.TYPE; assert int.class == Integer.TYPE; assert long.class == Long.TYPE; assert float.class == Float.TYPE; assert double.class == Double.TYPE; } The patch is attached. Regards, Sergey Tsypanov -------------- next part -------------- A non-text attachment was scrubbed... Name: primitive.patch Type: text/x-diff Size: 7814 bytes Desc: not available URL: From forax at univ-mlv.fr Tue Nov 26 19:45:07 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 26 Nov 2019 20:45:07 +0100 (CET) Subject: [PATCH] Simplification proposal regarding TYPE-field initialization in primitive wrappers In-Reply-To: <93310181574796546@vla4-4046ec513d04.qloud-c.yandex.net> References: <93310181574796546@vla4-4046ec513d04.qloud-c.yandex.net> Message-ID: <1185598046.1059127.1574797507571.JavaMail.zimbra@u-pem.fr> Hi Sergey, hum, it doesn't work :) int.class is compiled by javac as Integer.TYPE, the opcode ldc only works with an object/interface class, not with a primitive type [1]. regards, R?mi [1] https://docs.oracle.com/javase/specs/jvms/se13/html/jvms-6.html#jvms-6.5.ldc ----- Mail original ----- > De: "?????? ???????" > ?: "core-libs-dev" > Envoy?: Mardi 26 Novembre 2019 20:29:06 > Objet: [PATCH] Simplification proposal regarding TYPE-field initialization in primitive wrappers > Hello, > > while using java.lang.Integer.TYPE I've found out that currently wrapper classes > for primitives initialize their own TYPE-fields by calling native method > java.lang.Class.getPrimitiveClass(). > > This can be simplified by changing existing declaration (here for > java.lang.Integer) > > @SuppressWarnings("unchecked") > public static final Class TYPE = (Class) > Class.getPrimitiveClass("int"); > > to > > public static final Class TYPE = int.class; > > This is likely to improve start-up time as Class.getPrimitiveClass() is called 9 > times (8 primitive type wrappers + java.lang.Void), after the change this > method is not called at all and thus can be removed along with its backing C++ > code on VM-side. The fields are initialized purely on Java side. > > I've verified correctness of the substitution with this test run on JDK 11 > > @Test > void name() { > assert void.class == Void.TYPE; > assert boolean.class == Boolean.TYPE; > assert byte.class == Byte.TYPE; > assert char.class == Character.TYPE; > assert short.class == Short.TYPE; > assert int.class == Integer.TYPE; > assert long.class == Long.TYPE; > assert float.class == Float.TYPE; > assert double.class == Double.TYPE; > } > > The patch is attached. > > Regards, > Sergey Tsypanov From sergei.tsypanov at yandex.ru Tue Nov 26 19:56:44 2019 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Tue, 26 Nov 2019 21:56:44 +0200 Subject: [PATCH] Simplification proposal regarding TYPE-field initialization in primitive wrappers In-Reply-To: <1185598046.1059127.1574797507571.JavaMail.zimbra@u-pem.fr> References: <93310181574796546@vla4-4046ec513d04.qloud-c.yandex.net> <1185598046.1059127.1574797507571.JavaMail.zimbra@u-pem.fr> Message-ID: <33216991574798204@iva7-25cfe2cacdf7.qloud-c.yandex.net> Hello Remi, > int.class is compiled by javac as Integer.TYPE so this is the reason why assertion works in the test. > the opcode ldc only works with an object/interface class, not with a primitive type [1]. Thanks for pointing this out, I think I should read that whole chapter again. Regards, Sergey Tsypanov 26.11.2019, 21:45, "Remi Forax" : > Hi Sergey, > hum, it doesn't work :) > > int.class is compiled by javac as Integer.TYPE, > the opcode ldc only works with an object/interface class, not with a primitive type [1]. > > regards, > R?mi > > [1] https://docs.oracle.com/javase/specs/jvms/se13/html/jvms-6.html#jvms-6.5.ldc > > ----- Mail original ----- >> ?De: "?????? ???????" >> ??: "core-libs-dev" >> ?Envoy?: Mardi 26 Novembre 2019 20:29:06 >> ?Objet: [PATCH] Simplification proposal regarding TYPE-field initialization in primitive wrappers > >> ?Hello, >> >> ?while using java.lang.Integer.TYPE I've found out that currently wrapper classes >> ?for primitives initialize their own TYPE-fields by calling native method >> ?java.lang.Class.getPrimitiveClass(). >> >> ?This can be simplified by changing existing declaration (here for >> ?java.lang.Integer) >> >> ?@SuppressWarnings("unchecked") >> ?public static final Class TYPE = (Class) >> ?Class.getPrimitiveClass("int"); >> >> ?to >> >> ?public static final Class TYPE = int.class; >> >> ?This is likely to improve start-up time as Class.getPrimitiveClass() is called 9 >> ?times (8 primitive type wrappers + java.lang.Void), after the change this >> ?method is not called at all and thus can be removed along with its backing C++ >> ?code on VM-side. The fields are initialized purely on Java side. >> >> ?I've verified correctness of the substitution with this test run on JDK 11 >> >> ?@Test >> ?void name() { >> ??assert void.class == Void.TYPE; >> ??assert boolean.class == Boolean.TYPE; >> ??assert byte.class == Byte.TYPE; >> ??assert char.class == Character.TYPE; >> ??assert short.class == Short.TYPE; >> ??assert int.class == Integer.TYPE; >> ??assert long.class == Long.TYPE; >> ??assert float.class == Float.TYPE; >> ??assert double.class == Double.TYPE; >> ?} >> >> ?The patch is attached. >> >> ?Regards, >> ?Sergey Tsypanov From info at j-kuhn.de Tue Nov 26 19:57:17 2019 From: info at j-kuhn.de (Johannes Kuhn) Date: Tue, 26 Nov 2019 20:57:17 +0100 Subject: [PATCH] Simplification proposal regarding TYPE-field initialization in primitive wrappers In-Reply-To: <93310181574796546@vla4-4046ec513d04.qloud-c.yandex.net> References: <93310181574796546@vla4-4046ec513d04.qloud-c.yandex.net> Message-ID: <138E74BC-552C-4972-BFA6-E9A2CC0ED292@j-kuhn.de> On November 26, 2019 8:29:06 PM GMT+01:00, "?????? ???????" wrote: >Hello, > >while using java.lang.Integer.TYPE I've found out that currently >wrapper classes for primitives initialize their own TYPE-fields by >calling native method java.lang.Class.getPrimitiveClass(). > >This can be simplified by changing existing declaration (here for >java.lang.Integer) > >@SuppressWarnings("unchecked") >public static final Class TYPE = (Class) >Class.getPrimitiveClass("int"); > >to > >public static final Class TYPE = int.class; > >This is likely to improve start-up time as Class.getPrimitiveClass() is >called 9 times (8 primitive type wrappers + java.lang.Void), after the >change this method is not called at all and thus can be removed along >with its backing C++ code on VM-side. The fields are initialized purely >on Java side. > >I've verified correctness of the substitution with this test run on JDK >11 > >@Test >void name() { > assert void.class == Void.TYPE; > assert boolean.class == Boolean.TYPE; > assert byte.class == Byte.TYPE; > assert char.class == Character.TYPE; > assert short.class == Short.TYPE; > assert int.class == Integer.TYPE; > assert long.class == Long.TYPE; > assert float.class == Float.TYPE; > assert double.class == Double.TYPE; >} > >The patch is attached. > >Regards, >Sergey Tsypanov Hi, a few questions: What does System.out.println(int.class); with your patch print? "int" or "null"? I suspect that it will print null, because to my knowledge, int.class will be compiled to a getstatic Integer.TYPE, so your test basically tests if Integer.TYPE == Integer.TYPE. Also, do the tier1 tests succeed with your patch? With best regards, Johannes From info at j-kuhn.de Tue Nov 26 20:32:48 2019 From: info at j-kuhn.de (Johannes Kuhn) Date: Tue, 26 Nov 2019 21:32:48 +0100 Subject: New candidate JEP: 370: Foreign-Memory Access API In-Reply-To: References: <20191125172756.29B2330F46E@eggemoggin.niobe.net> Message-ID: Hi, Just had the chance to look at the proposal, and I have a small suggestion: MemorySegmenent::mapFromPath should state that it can throw a SecurityException if a SecurityManager is installed in the javadoc. The description can be copied from FileChannel::open. With best regards, Johannes From alexey.semenyuk at oracle.com Tue Nov 26 20:41:26 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Tue, 26 Nov 2019 15:41:26 -0500 Subject: jpackage ROOTDIR variable in a Windows bat file In-Reply-To: <88728D87-6DE5-4568-8157-9E2925E02855@gmail.com> References: <43ad0e64-f5f1-c0bc-d5b1-7ac6d0589600@oracle.com> <1C99B0A1-9263-4020-B1C9-50E1BC1D1062@gmail.com> <7BC977C3-4176-4814-8BBB-033065B2D561@gmail.com> <81a59597-c7aa-fbee-d3c8-e0a8d855e7f7@oracle.com> <85a38efe-e572-9d79-38f4-abbcfad6c175@oracle.com> <88728D87-6DE5-4568-8157-9E2925E02855@gmail.com> Message-ID: <057b6ef8-dfa3-e832-b009-f27a85120e92@oracle.com> On 11/26/2019 9:48 AM, Michael Hall wrote: > > >> On Nov 25, 2019, at 11:47 AM, Alexey Semenyuk >> > wrote: >> >>>> >>>> --name HalfPipe >>>> --runtime-image "c:/Program Files/Java/jdk-14" >> --runtime-image and --add-modules parameters should not be used together. >> If Java run-time image is specified with --runtime-image parameter, >> jpackage will not run jlink command to create custom run-time from >> the list of modules specified in --add-modules parameter(s). >> So I'd recommend to remove --runtime-image from your input. > > Good catch on this one as well. I must have not had it added at some > point so I had the ?add-modules. Maybe sometime ?runtime-image seemed > to help in running multiple runtimes for the machine and jpackage or > sometime it seemed like a quick fix for a missing modules problem. There are few scenarios when you would use ?runtime-image option: - you want to bundle your app with different version of Java run-time. Say, with Java8. - you have created custom run-time by explicitly running jlink command and want to bundle this Java run-time with your app. jpackage doesn't provide full control on parameters passed to jlink command it runs internally, so if flexibility of jpackage is not sufficient, ?runtime-image option is a workaround. > > After networking errors I did have to include?jdk.crypto.ec as per? > https://stackoverflow.com/questions/54770538/received-fatal-alert-handshake-failure-in-jlinked-jre > > It is not immediately clear to me how I could of anticipated the need > for this module > > (base) Michaels-MBP:halfpipe_jpkg mjh$ jdeps > outputdir/HalfPipe.app/Contents/app/halfpipe.jar | grep jdk.crypto.ec > (base) Michaels-MBP:halfpipe_jpkg mjh$ jdeps > outputdir/HalfPipe.app/Contents/app/httpclient.4.5.6.jar | grep > jdk.crypto.ec > (base) Michaels-MBP:halfpipe_jpkg mjh$ jdeps > outputdir/HalfPipe.app/Contents/app/httpcore.4.4.10.jar | grep > jdk.crypto.ec > > All show nothing. But the app appears to work fine after adding it. > > Before > -rw-r--r--@ 1 mjh??staff??107814191 Nov 26 07:37 HalfPipe-1.0.dmg > > After > -rw-r--r--@ 1 mjh??staff??70825384 Nov 26 07:50 HalfPipe-1.0.dmg > > So the application is seeing some benefit from modular on size now. > > If some options are more or less mutually exclusive would it be an > idea if jpackage issued some warnings/errors? Good catch. I've created https://bugs.openjdk.java.net/browse/JDK-8234867 to track this. - Alexey > > > > > From erik.joelsson at oracle.com Tue Nov 26 20:56:05 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 26 Nov 2019 12:56:05 -0800 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: <2589963b-b10e-7af9-bf1a-208df190fb2a@oracle.com> References: <35372d0e-910a-d8c1-6bf4-88fcb140daee@oracle.com> <2589963b-b10e-7af9-bf1a-208df190fb2a@oracle.com> Message-ID: <2345349e-6658-5d3c-e191-4bfbd79a13ae@oracle.com> (adding build-dev) Build changes look good. /Erik On 2019-11-20 09:37, Andy Herrick wrote: > I posted new composite webrev [7], and git patch [8] after pushing fix > for JDK-8234402 [6]. > > [7] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11/ > > [8] http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-11.git.patch > > /Andy > > On 11/19/2019 3:13 PM, Kevin Rushforth wrote: >> I took the "git diff" patch [5] that you uploaded yesterday, applied >> it, and verified that it is the same as what is in the >> JDK-8200758-branch branch of the sandbox. It builds and runs fine for >> me. >> >> I ran jcheck and it found the following three files with whitespace >> errors that will need to be fixed before you push: >> >> src/jdk.incubator.jpackage/linux/classes/jdk/incubator/jpackage/internal/PackageProperty.java:49: >> Trailing whitespace >> src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/ToolProviderFactory.java:35: >> Trailing whitespace >> test/jdk/tools/jpackage/share/AddLauncherBase.java:137: Trailing >> whitespace >> >> The second of these will go away with the fix for JDK-8234402 [6], so >> you don't need to do anything there. Once the fix for JDK-8234402 is >> pushed to sandbox, I presume you will update the webrev, right? >> >> Pending the fix for JDK-8234402 and the needed white-space fixes, >> this is a +1 from me (although I am not a jdk Project Reviewer, so >> you will need at least one review from someone who is). >> >> -- Kevin >> >> [5] http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-10.git.patch >> [6] https://bugs.openjdk.java.net/browse/JDK-8234402 >> >> >> On 11/13/2019 4:23 PM, Andy Herrick wrote: >>> Please review? changes for [1] which is the implementation bug for >>> JEP-343. >>> >>> The webrev at [2] is the total cumulative webrev of changes for the >>> jpackage tool, currently in the JDK-8200758-branch branch of the >>> open sandbox repository. >>> >>> The webrev at [3] shows the changes since EA-06 (Build >>> 13-jpackage+1-49 ) up to the current point. >>> >>> The latest EA (Build 14-jpackage+1-49 ) is posted at [4]. >>> >>> Please send feedback to core-libs-dev at openjdk.java.net >>> >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8212780 >>> >>> [2] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-10/ >>> >>> [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-10/ >>> >>> [4] http://jdk.java.net/jpackage/ >>> >> From maurizio.cimadamore at oracle.com Tue Nov 26 21:02:56 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 26 Nov 2019 21:02:56 +0000 Subject: New candidate JEP: 370: Foreign-Memory Access API In-Reply-To: References: <20191125172756.29B2330F46E@eggemoggin.niobe.net> Message-ID: Very good suggestion - thanks; I will fix it. Cheers Maurizio On 26/11/2019 20:32, Johannes Kuhn wrote: > Hi, > > Just had the chance to look at the proposal, and I have a small suggestion: > MemorySegmenent::mapFromPath should state that it can throw a SecurityException if a SecurityManager is installed in the javadoc. > The description can be copied from FileChannel::open. > > With best regards, > Johannes From sergei.tsypanov at yandex.ru Tue Nov 26 21:10:02 2019 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Tue, 26 Nov 2019 23:10:02 +0200 Subject: [PATCH] Simplification proposal regarding TYPE-field initialization in primitive wrappers In-Reply-To: <138E74BC-552C-4972-BFA6-E9A2CC0ED292@j-kuhn.de> References: <93310181574796546@vla4-4046ec513d04.qloud-c.yandex.net> <138E74BC-552C-4972-BFA6-E9A2CC0ED292@j-kuhn.de> Message-ID: <34900361574802602@sas1-f8fae029bfc6.qloud-c.yandex.net> Hello, > I suspect that it will print null, because to my knowledge, int.class will be compiled to a getstatic Integer.TYPE, so your test basically tests if Integer.TYPE == Integer.TYPE. right, Remi pointed this out in his response. > Also, do the tier1 tests succeed with your patch? I'm going to do that as far as my work station is fixed, hope tomorrow. Apparently, something is going to go wrong :) Anyway, I'll notify about results when this is done. Regards, Sergey Tsypanov 26.11.2019, 21:57, "Johannes Kuhn" : > On November 26, 2019 8:29:06 PM GMT+01:00, "?????? ???????" wrote: >> Hello, >> >> while using java.lang.Integer.TYPE I've found out that currently >> wrapper classes for primitives initialize their own TYPE-fields by >> calling native method java.lang.Class.getPrimitiveClass(). >> >> This can be simplified by changing existing declaration (here for >> java.lang.Integer) >> >> @SuppressWarnings("unchecked") >> public static final Class TYPE = (Class) >> Class.getPrimitiveClass("int"); >> >> to >> >> public static final Class TYPE = int.class; >> >> This is likely to improve start-up time as Class.getPrimitiveClass() is >> called 9 times (8 primitive type wrappers + java.lang.Void), after the >> change this method is not called at all and thus can be removed along >> with its backing C++ code on VM-side. The fields are initialized purely >> on Java side. >> >> I've verified correctness of the substitution with this test run on JDK >> 11 >> >> @Test >> void name() { >> ??assert void.class == Void.TYPE; >> ??assert boolean.class == Boolean.TYPE; >> ??assert byte.class == Byte.TYPE; >> ??assert char.class == Character.TYPE; >> ??assert short.class == Short.TYPE; >> ??assert int.class == Integer.TYPE; >> ??assert long.class == Long.TYPE; >> ??assert float.class == Float.TYPE; >> ??assert double.class == Double.TYPE; >> } >> >> The patch is attached. >> >> Regards, >> Sergey Tsypanov > > Hi, > a few questions: > What does System.out.println(int.class); with your patch print? "int" or "null"? > > I suspect that it will print null, because to my knowledge, int.class will be compiled to a getstatic Integer.TYPE, so your test basically tests if Integer.TYPE == Integer.TYPE. > > Also, do the tier1 tests succeed with your patch? > > With best regards, > Johannes From naoto.sato at oracle.com Tue Nov 26 21:35:09 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 26 Nov 2019 13:35:09 -0800 Subject: [14] RFR: 8222756: Plural support in CompactNumberFormat In-Reply-To: <350d65d3-1c97-bba9-485c-b393fbbb899d@oracle.com> References: <350d65d3-1c97-bba9-485c-b393fbbb899d@oracle.com> Message-ID: <90096b6b-f652-af97-7651-fa3791795f8e@oracle.com> I modified CompactNumberFormat.java to simplify the syntax parsing: https://cr.openjdk.java.net/~naoto/8222756/webrev.01/ Please review this webrev instead. Naoto On 11/25/19 1:16 PM, naoto.sato at oracle.com wrote: > Hello, > > CompactNumberFormat has been added since JDK 12 to support compact > number formatting, such as 10_000 being formatted as "10K." [1] It works > fine for English, however, not for other languages that take plural > forms in formatted number prefixes/suffixes. In order to fix this, I > filed the following CSR to extend the current CompactNumberFormat spec: > > https://bugs.openjdk.java.net/browse/JDK-8232633 > > It basically accommodates the plural prefix/suffix forms into the > existing compact patterns array, so that the existing compact number > format works compatibly. The plural rules are solely based on the CLDR's > plural language rules [2] > > Here is the implementation of the CSR: > > https://cr.openjdk.java.net/~naoto/8222756/webrev.00/ > > Please review the CSR as well as its implementation. > > Naoto > > > [1] https://bugs.openjdk.java.net/browse/JDK-8177552 > [2] > https://unicode.org/reports/tr35/tr35-numbers.html#Language_Plural_Rules From kevin.rushforth at oracle.com Tue Nov 26 21:36:39 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 26 Nov 2019 13:36:39 -0800 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: <2345349e-6658-5d3c-e191-4bfbd79a13ae@oracle.com> References: <35372d0e-910a-d8c1-6bf4-88fcb140daee@oracle.com> <2589963b-b10e-7af9-bf1a-208df190fb2a@oracle.com> <2345349e-6658-5d3c-e191-4bfbd79a13ae@oracle.com> Message-ID: <281621ac-7a32-6eda-8b16-f35efde450db@oracle.com> This all looks good. +1 -- Kevin On 11/26/2019 12:56 PM, Erik Joelsson wrote: > (adding build-dev) > > Build changes look good. > > /Erik > > On 2019-11-20 09:37, Andy Herrick wrote: >> I posted new composite webrev [7], and git patch [8] after pushing >> fix for JDK-8234402 [6]. >> >> [7] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11/ >> >> [8] http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-11.git.patch >> >> /Andy >> >> On 11/19/2019 3:13 PM, Kevin Rushforth wrote: >>> I took the "git diff" patch [5] that you uploaded yesterday, applied >>> it, and verified that it is the same as what is in the >>> JDK-8200758-branch branch of the sandbox. It builds and runs fine >>> for me. >>> >>> I ran jcheck and it found the following three files with whitespace >>> errors that will need to be fixed before you push: >>> >>> src/jdk.incubator.jpackage/linux/classes/jdk/incubator/jpackage/internal/PackageProperty.java:49: >>> Trailing whitespace >>> src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/ToolProviderFactory.java:35: >>> Trailing whitespace >>> test/jdk/tools/jpackage/share/AddLauncherBase.java:137: Trailing >>> whitespace >>> >>> The second of these will go away with the fix for JDK-8234402 [6], >>> so you don't need to do anything there. Once the fix for JDK-8234402 >>> is pushed to sandbox, I presume you will update the webrev, right? >>> >>> Pending the fix for JDK-8234402 and the needed white-space fixes, >>> this is a +1 from me (although I am not a jdk Project Reviewer, so >>> you will need at least one review from someone who is). >>> >>> -- Kevin >>> >>> [5] http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-10.git.patch >>> [6] https://bugs.openjdk.java.net/browse/JDK-8234402 >>> >>> >>> On 11/13/2019 4:23 PM, Andy Herrick wrote: >>>> Please review? changes for [1] which is the implementation bug for >>>> JEP-343. >>>> >>>> The webrev at [2] is the total cumulative webrev of changes for the >>>> jpackage tool, currently in the JDK-8200758-branch branch of the >>>> open sandbox repository. >>>> >>>> The webrev at [3] shows the changes since EA-06 (Build >>>> 13-jpackage+1-49 ) up to the current point. >>>> >>>> The latest EA (Build 14-jpackage+1-49 ) is posted at [4]. >>>> >>>> Please send feedback to core-libs-dev at openjdk.java.net >>>> >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8212780 >>>> >>>> [2] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-10/ >>>> >>>> [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-10/ >>>> >>>> [4] http://jdk.java.net/jpackage/ >>>> >>> From philip.race at oracle.com Tue Nov 26 21:53:55 2019 From: philip.race at oracle.com (Phil Race) Date: Tue, 26 Nov 2019 13:53:55 -0800 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: <281621ac-7a32-6eda-8b16-f35efde450db@oracle.com> References: <35372d0e-910a-d8c1-6bf4-88fcb140daee@oracle.com> <2589963b-b10e-7af9-bf1a-208df190fb2a@oracle.com> <2345349e-6658-5d3c-e191-4bfbd79a13ae@oracle.com> <281621ac-7a32-6eda-8b16-f35efde450db@oracle.com> Message-ID: <03d92b75-3b3b-bd08-694e-b1d0af2da53f@oracle.com> Andy, I am puzzled by what I see here > The webrev at [3] shows the changes since EA-06 (Build 13-jpackage+1-49 ) up to the current point. > [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-10/ This includes the JNLPConverter which isn't what I expected to see and (correctly) isn't in the cumulative webrev .... Since [3] seemed like the most obvious thing to do a review of the recent changes I'd like to be sure it has the correct content and I am not sure it does ... -phil. On 11/26/19 1:36 PM, Kevin Rushforth wrote: > This all looks good. > > +1 > > -- Kevin > > > On 11/26/2019 12:56 PM, Erik Joelsson wrote: >> (adding build-dev) >> >> Build changes look good. >> >> /Erik >> >> On 2019-11-20 09:37, Andy Herrick wrote: >>> I posted new composite webrev [7], and git patch [8] after pushing >>> fix for JDK-8234402 [6]. >>> >>> [7] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11/ >>> >>> [8] http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-11.git.patch >>> >>> /Andy >>> >>> On 11/19/2019 3:13 PM, Kevin Rushforth wrote: >>>> I took the "git diff" patch [5] that you uploaded yesterday, >>>> applied it, and verified that it is the same as what is in the >>>> JDK-8200758-branch branch of the sandbox. It builds and runs fine >>>> for me. >>>> >>>> I ran jcheck and it found the following three files with whitespace >>>> errors that will need to be fixed before you push: >>>> >>>> src/jdk.incubator.jpackage/linux/classes/jdk/incubator/jpackage/internal/PackageProperty.java:49: >>>> Trailing whitespace >>>> src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/ToolProviderFactory.java:35: >>>> Trailing whitespace >>>> test/jdk/tools/jpackage/share/AddLauncherBase.java:137: Trailing >>>> whitespace >>>> >>>> The second of these will go away with the fix for JDK-8234402 [6], >>>> so you don't need to do anything there. Once the fix for >>>> JDK-8234402 is pushed to sandbox, I presume you will update the >>>> webrev, right? >>>> >>>> Pending the fix for JDK-8234402 and the needed white-space fixes, >>>> this is a +1 from me (although I am not a jdk Project Reviewer, so >>>> you will need at least one review from someone who is). >>>> >>>> -- Kevin >>>> >>>> [5] http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-10.git.patch >>>> [6] https://bugs.openjdk.java.net/browse/JDK-8234402 >>>> >>>> >>>> On 11/13/2019 4:23 PM, Andy Herrick wrote: >>>>> Please review? changes for [1] which is the implementation bug for >>>>> JEP-343. >>>>> >>>>> The webrev at [2] is the total cumulative webrev of changes for >>>>> the jpackage tool, currently in the JDK-8200758-branch branch of >>>>> the open sandbox repository. >>>>> >>>>> The webrev at [3] shows the changes since EA-06 (Build >>>>> 13-jpackage+1-49 ) up to the current point. >>>>> >>>>> The latest EA (Build 14-jpackage+1-49 ) is posted at [4]. >>>>> >>>>> Please send feedback to core-libs-dev at openjdk.java.net >>>>> >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8212780 >>>>> >>>>> [2] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-10/ >>>>> >>>>> [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-10/ >>>>> >>>>> [4] http://jdk.java.net/jpackage/ >>>>> >>>> > From andy.herrick at oracle.com Tue Nov 26 22:17:18 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 26 Nov 2019 17:17:18 -0500 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: <03d92b75-3b3b-bd08-694e-b1d0af2da53f@oracle.com> References: <35372d0e-910a-d8c1-6bf4-88fcb140daee@oracle.com> <2589963b-b10e-7af9-bf1a-208df190fb2a@oracle.com> <2345349e-6658-5d3c-e191-4bfbd79a13ae@oracle.com> <281621ac-7a32-6eda-8b16-f35efde450db@oracle.com> <03d92b75-3b3b-bd08-694e-b1d0af2da53f@oracle.com> Message-ID: yes,? this incremental webrev contains the JNLPConverter code, which it should not. I believe otherwise it is an accurate incremental webrev of the jpackage changes since EA-5. /Andy On 11/26/2019 4:53 PM, Phil Race wrote: > Andy, > > I am puzzled by what I see here > > The webrev at [3] shows the changes since EA-06 (Build > 13-jpackage+1-49 ) up to the current point. > > > [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-10/ > > This includes the JNLPConverter which isn't what I expected to see and > (correctly) isn't in the cumulative webrev .... > > Since [3] seemed like the most obvious thing to do a review of the recent > changes I'd like to be sure it has the correct content and I am not > sure it does ... > > -phil. > > On 11/26/19 1:36 PM, Kevin Rushforth wrote: >> This all looks good. >> >> +1 >> >> -- Kevin >> >> >> On 11/26/2019 12:56 PM, Erik Joelsson wrote: >>> (adding build-dev) >>> >>> Build changes look good. >>> >>> /Erik >>> >>> On 2019-11-20 09:37, Andy Herrick wrote: >>>> I posted new composite webrev [7], and git patch [8] after pushing >>>> fix for JDK-8234402 [6]. >>>> >>>> [7] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11/ >>>> >>>> [8] http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-11.git.patch >>>> >>>> /Andy >>>> >>>> On 11/19/2019 3:13 PM, Kevin Rushforth wrote: >>>>> I took the "git diff" patch [5] that you uploaded yesterday, >>>>> applied it, and verified that it is the same as what is in the >>>>> JDK-8200758-branch branch of the sandbox. It builds and runs fine >>>>> for me. >>>>> >>>>> I ran jcheck and it found the following three files with >>>>> whitespace errors that will need to be fixed before you push: >>>>> >>>>> src/jdk.incubator.jpackage/linux/classes/jdk/incubator/jpackage/internal/PackageProperty.java:49: >>>>> Trailing whitespace >>>>> src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/ToolProviderFactory.java:35: >>>>> Trailing whitespace >>>>> test/jdk/tools/jpackage/share/AddLauncherBase.java:137: Trailing >>>>> whitespace >>>>> >>>>> The second of these will go away with the fix for JDK-8234402 [6], >>>>> so you don't need to do anything there. Once the fix for >>>>> JDK-8234402 is pushed to sandbox, I presume you will update the >>>>> webrev, right? >>>>> >>>>> Pending the fix for JDK-8234402 and the needed white-space fixes, >>>>> this is a +1 from me (although I am not a jdk Project Reviewer, so >>>>> you will need at least one review from someone who is). >>>>> >>>>> -- Kevin >>>>> >>>>> [5] http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-10.git.patch >>>>> [6] https://bugs.openjdk.java.net/browse/JDK-8234402 >>>>> >>>>> >>>>> On 11/13/2019 4:23 PM, Andy Herrick wrote: >>>>>> Please review? changes for [1] which is the implementation bug >>>>>> for JEP-343. >>>>>> >>>>>> The webrev at [2] is the total cumulative webrev of changes for >>>>>> the jpackage tool, currently in the JDK-8200758-branch branch of >>>>>> the open sandbox repository. >>>>>> >>>>>> The webrev at [3] shows the changes since EA-06 (Build >>>>>> 13-jpackage+1-49 ) up to the current point. >>>>>> >>>>>> The latest EA (Build 14-jpackage+1-49 ) is posted at [4]. >>>>>> >>>>>> Please send feedback to core-libs-dev at openjdk.java.net >>>>>> >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8212780 >>>>>> >>>>>> [2] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-10/ >>>>>> >>>>>> [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-10/ >>>>>> >>>>>> [4] http://jdk.java.net/jpackage/ >>>>>> >>>>> >> > From info at j-kuhn.de Tue Nov 26 22:16:35 2019 From: info at j-kuhn.de (Johannes Kuhn) Date: Tue, 26 Nov 2019 23:16:35 +0100 Subject: [PATCH] Simplification proposal regarding TYPE-field initialization in primitive wrappers In-Reply-To: <34900361574802602@sas1-f8fae029bfc6.qloud-c.yandex.net> References: <93310181574796546@vla4-4046ec513d04.qloud-c.yandex.net> <138E74BC-552C-4972-BFA6-E9A2CC0ED292@j-kuhn.de> <34900361574802602@sas1-f8fae029bfc6.qloud-c.yandex.net> Message-ID: Hi, I saw Remi's reply after I sent my reply. The questions I asked were just to confirm that my suspicion (int.class gets compiled into Integer.TYPE) were true - I am currently on mobile, so I couldn't test it myself. In short, my mail doesn't provide any additional value, and if I had seen Remi's reply, I wouldn't have sent mine. Best regards, Johannes On November 26, 2019 10:10:02 PM GMT+01:00, "?????? ???????" wrote: >Hello, > >> I suspect that it will print null, because to my knowledge, int.class >will be compiled to a getstatic Integer.TYPE, so your test basically >tests if Integer.TYPE == Integer.TYPE. > >right, Remi pointed this out in his response. > >> Also, do the tier1 tests succeed with your patch? > >I'm going to do that as far as my work station is fixed, hope tomorrow. >Apparently, something is going to go wrong :) Anyway, I'll notify about >results when this is done. > >Regards, >Sergey Tsypanov > > >26.11.2019, 21:57, "Johannes Kuhn" : >> On November 26, 2019 8:29:06 PM GMT+01:00, "?????? ???????" > wrote: >>> Hello, >>> >>> while using java.lang.Integer.TYPE I've found out that currently >>> wrapper classes for primitives initialize their own TYPE-fields by >>> calling native method java.lang.Class.getPrimitiveClass(). >>> >>> This can be simplified by changing existing declaration (here for >>> java.lang.Integer) >>> >>> @SuppressWarnings("unchecked") >>> public static final Class TYPE = (Class) >>> Class.getPrimitiveClass("int"); >>> >>> to >>> >>> public static final Class TYPE = int.class; >>> >>> This is likely to improve start-up time as Class.getPrimitiveClass() >is >>> called 9 times (8 primitive type wrappers + java.lang.Void), after >the >>> change this method is not called at all and thus can be removed >along >>> with its backing C++ code on VM-side. The fields are initialized >purely >>> on Java side. >>> >>> I've verified correctness of the substitution with this test run on >JDK >>> 11 >>> >>> @Test >>> void name() { >>> ??assert void.class == Void.TYPE; >>> ??assert boolean.class == Boolean.TYPE; >>> ??assert byte.class == Byte.TYPE; >>> ??assert char.class == Character.TYPE; >>> ??assert short.class == Short.TYPE; >>> ??assert int.class == Integer.TYPE; >>> ??assert long.class == Long.TYPE; >>> ??assert float.class == Float.TYPE; >>> ??assert double.class == Double.TYPE; >>> } >>> >>> The patch is attached. >>> >>> Regards, >>> Sergey Tsypanov >> >> Hi, >> a few questions: >> What does System.out.println(int.class); with your patch print? "int" >or "null"? >> >> I suspect that it will print null, because to my knowledge, int.class >will be compiled to a getstatic Integer.TYPE, so your test basically >tests if Integer.TYPE == Integer.TYPE. >> >> Also, do the tier1 tests succeed with your patch? >> >> With best regards, >> Johannes From mik3hall at gmail.com Tue Nov 26 22:36:41 2019 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 26 Nov 2019 16:36:41 -0600 Subject: jpackage ROOTDIR variable in a Windows bat file In-Reply-To: <057b6ef8-dfa3-e832-b009-f27a85120e92@oracle.com> References: <43ad0e64-f5f1-c0bc-d5b1-7ac6d0589600@oracle.com> <1C99B0A1-9263-4020-B1C9-50E1BC1D1062@gmail.com> <7BC977C3-4176-4814-8BBB-033065B2D561@gmail.com> <81a59597-c7aa-fbee-d3c8-e0a8d855e7f7@oracle.com> <85a38efe-e572-9d79-38f4-abbcfad6c175@oracle.com> <88728D87-6DE5-4568-8157-9E2925E02855@gmail.com> <057b6ef8-dfa3-e832-b009-f27a85120e92@oracle.com> Message-ID: <03395941-409F-450D-BDB8-DCABB73237EE@gmail.com> > On Nov 26, 2019, at 2:41 PM, Alexey Semenyuk wrote: > > > > On 11/26/2019 9:48 AM, Michael Hall wrote: >> >> >>> On Nov 25, 2019, at 11:47 AM, Alexey Semenyuk > wrote: >>> >>>>> >>>>> --name HalfPipe >>>>> --runtime-image "c:/Program Files/Java/jdk-14" >>> --runtime-image and --add-modules parameters should not be used together. >>> If Java run-time image is specified with --runtime-image parameter, jpackage will not run jlink command to create custom run-time from the list of modules specified in --add-modules parameter(s). >>> So I'd recommend to remove --runtime-image from your input. >> >> Good catch on this one as well. I must have not had it added at some point so I had the ?add-modules. Maybe sometime ?runtime-image seemed to help in running multiple runtimes for the machine and jpackage or sometime it seemed like a quick fix for a missing modules problem. > There are few scenarios when you would use ?runtime-image option: > - you want to bundle your app with different version of Java run-time. Say, with Java8. > - you have created custom run-time by explicitly running jlink command and want to bundle this Java run-time with your app. jpackage doesn't provide full control on parameters passed to jlink command it runs internally, so if flexibility of jpackage is not sufficient, ?runtime-image option is a workaround. I must of added it. I don?t remember why. > >> >> After networking errors I did have to include jdk.crypto.ec as per? >> https://stackoverflow.com/questions/54770538/received-fatal-alert-handshake-failure-in-jlinked-jre >> >> It is not immediately clear to me how I could of anticipated the need for this module >> >> (base) Michaels-MBP:halfpipe_jpkg mjh$ jdeps outputdir/HalfPipe.app/Contents/app/halfpipe.jar | grep jdk.crypto.ec >> (base) Michaels-MBP:halfpipe_jpkg mjh$ jdeps outputdir/HalfPipe.app/Contents/app/httpclient.4.5.6.jar | grep jdk.crypto.ec >> (base) Michaels-MBP:halfpipe_jpkg mjh$ jdeps outputdir/HalfPipe.app/Contents/app/httpcore.4.4.10.jar | grep jdk.crypto.ec >> >> All show nothing. But the app appears to work fine after adding it. >> >> Before >> -rw-r--r--@ 1 mjh staff 107814191 Nov 26 07:37 HalfPipe-1.0.dmg >> >> After >> -rw-r--r--@ 1 mjh staff 70825384 Nov 26 07:50 HalfPipe-1.0.dmg >> >> So the application is seeing some benefit from modular on size now. >> >> If some options are more or less mutually exclusive would it be an idea if jpackage issued some warnings/errors? > Good catch. I've created https://bugs.openjdk.java.net/browse/JDK-8234867 to track this. > Thank you. Looked like you?re in Java 14. Looking forward to that. From huaming.li at oracle.com Wed Nov 27 01:51:36 2019 From: huaming.li at oracle.com (Hamlin Li) Date: Wed, 27 Nov 2019 09:51:36 +0800 Subject: RFR of JDK-8232446: logging enhancement for rmi when socket closed In-Reply-To: References: <5048d354-a480-ac6d-e46d-a14ce4349691@oracle.com> <9db082f9-6e16-9e5e-1d99-280bbd381e8f@gmail.com> <50bf13f3-f284-f3f4-1256-8ac51929637b@oracle.com> Message-ID: <5ed904a8-cabc-c49a-7e8c-c73d144ea14e@oracle.com> Hi Roger, Thanks for reviewing, I have updated as you suggested: http://cr.openjdk.java.net/~mli/8232446/webrev.01/ Thank you -Hamlin On 2019/11/27 2:47 AM, Roger Riggs wrote: > Hi Hamlin, > > ok, but it looses the logging of the connection close when the socket > is null. > I intended to suggest that the logging happened before/outside the test > for socket != null. > > if (TCPTransport.tcpLog.isLoggable(Log.BRIEF)) { > TCPTransport.tcpLog.log(Log.BRIEF,"close connection, socket: " + socket); > }if (socket != null) { Thanks, Roger > On 11/22/19 2:54 AM, Hamlin Li wrote: >> Hi Roger, >> >> Thank you for reviewing, I have updated as you suggested: >> http://cr.openjdk.java.net/~mli/8232446/webrev.01/ >> >> Thank you >> >> -Hamlin >> >> On 2019/11/18 11:48 PM, Roger Riggs wrote: >>> Hi Hamlin, >>> >>> TCPConnection.java:212: >>> >>> Keep the "close connection" logging and add the socket to the same >>> log message: >>> >>> If anyone is scraping the log, they won't loose this message. >>> TCPTransport.tcpLog.log(Log.BRIEF, "close connection, socket: " + >>> socket); >>> >>> TCPTransport.java >>> >>> 277-278:? combine the message to be one logging call. >>> server socket >>> 289: use Log.BRIEF, avoid creating mixture of and too many log levels. >>> >>> Reword the log messages so they each begin with "server socket...", >>> or "server socket close"... >>> it makes it easier to grep for and coorelate related messages >>> >>> Thanks, Roger >>> >>> >>> On 11/6/19 7:02 AM, Hamlin Li wrote: >>>> >>>> On 2019/11/6 5:36 PM, Peter Levart wrote: >>>>> Hi Hamlin, >>>>> >>>>> in TCPTransport.decrementExportCount(): >>>>> >>>>> ?283???????????? try { >>>>> ?284???????????????? if (tcpLog.isLoggable(Log.BRIEF)) { >>>>> ?285???????????????????? tcpLog.log(Log.BRIEF, "close server >>>>> socket on " + ss); >>>>> ?286???????????????? } >>>>> ?287???????????????? ss.close(); >>>>> ?288???????????? } catch (IOException e) { >>>>> ?289???????????? } >>>>> >>>>> ...you could add a log statement to the catch block too. Or even >>>>> better, rearrange for IOException to be thrown from that method >>>>> and deal with it in two places: >>>>> >>>>> - in exportObject() - add it as suppressed exception to exception >>>>> thrown from super.exportObject(). >>>>> - in targetUnexported() - log it or wrap it into >>>>> UncheckedIOException (depending on what are the callers of >>>>> targetUnexported()) >>>>> >>>>> What do you think? >>>> Thanks Peter. >>>> >>>> I agree. I adopt your first suggestion: add log statement to catch >>>> block, as I think it's simple/straight and sufficient to help >>>> diagnose. >>>> >>>> And I also add log for catch blocks in other close places. >>>> >>>> The change is updated in place at: >>>> http://cr.openjdk.java.net/~mli/8232446/webrev.00/ >>>> >>>> >>>> Thank you >>>> >>>> -Hamlin >>>> >>>>> >>>>> Regards, Peter >>>>> >>>>> >>>>> >>>>> On 11/6/19 3:07 AM, Hamlin Li wrote: >>>>>> Would you please review the patch? >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8232446 >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~mli/8232446/webrev.00/ >>>>>> >>>>>> >>>>>> We have some intermittent failures in rmi related to socket >>>>>> closing, this is to add more logging to help diagnose the issues. >>>>>> >>>>>> >>>>>> Thanks you >>>>>> >>>>>> -Hamlin >>>>>> >>>>> >>> > From philip.race at oracle.com Wed Nov 27 02:01:29 2019 From: philip.race at oracle.com (Philip Race) Date: Tue, 26 Nov 2019 18:01:29 -0800 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: References: <35372d0e-910a-d8c1-6bf4-88fcb140daee@oracle.com> <2589963b-b10e-7af9-bf1a-208df190fb2a@oracle.com> <2345349e-6658-5d3c-e191-4bfbd79a13ae@oracle.com> <281621ac-7a32-6eda-8b16-f35efde450db@oracle.com> <03d92b75-3b3b-bd08-694e-b1d0af2da53f@oracle.com> Message-ID: <5DDDD8F9.3060906@oracle.com> > I believe otherwise it is an accurate incremental webrev of the jpackage changes since EA-5. It is also not very incremental. * *src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/main/Main.java is definitely not "new" ... -phil. On 11/26/19, 2:17 PM, Andy Herrick wrote: > yes, this incremental webrev contains the JNLPConverter code, which > it should not. > > I believe otherwise it is an accurate incremental webrev of the > jpackage changes since EA-5. > > /Andy > > On 11/26/2019 4:53 PM, Phil Race wrote: >> Andy, >> >> I am puzzled by what I see here >> > The webrev at [3] shows the changes since EA-06 (Build >> 13-jpackage+1-49 ) up to the current point. >> >> > [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-10/ >> >> This includes the JNLPConverter which isn't what I expected to see and >> (correctly) isn't in the cumulative webrev .... >> >> Since [3] seemed like the most obvious thing to do a review of the >> recent >> changes I'd like to be sure it has the correct content and I am not >> sure it does ... >> >> -phil. >> >> On 11/26/19 1:36 PM, Kevin Rushforth wrote: >>> This all looks good. >>> >>> +1 >>> >>> -- Kevin >>> >>> >>> On 11/26/2019 12:56 PM, Erik Joelsson wrote: >>>> (adding build-dev) >>>> >>>> Build changes look good. >>>> >>>> /Erik >>>> >>>> On 2019-11-20 09:37, Andy Herrick wrote: >>>>> I posted new composite webrev [7], and git patch [8] after pushing >>>>> fix for JDK-8234402 [6]. >>>>> >>>>> [7] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11/ >>>>> >>>>> [8] http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-11.git.patch >>>>> >>>>> /Andy >>>>> >>>>> On 11/19/2019 3:13 PM, Kevin Rushforth wrote: >>>>>> I took the "git diff" patch [5] that you uploaded yesterday, >>>>>> applied it, and verified that it is the same as what is in the >>>>>> JDK-8200758-branch branch of the sandbox. It builds and runs fine >>>>>> for me. >>>>>> >>>>>> I ran jcheck and it found the following three files with >>>>>> whitespace errors that will need to be fixed before you push: >>>>>> >>>>>> src/jdk.incubator.jpackage/linux/classes/jdk/incubator/jpackage/internal/PackageProperty.java:49: >>>>>> Trailing whitespace >>>>>> src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/ToolProviderFactory.java:35: >>>>>> Trailing whitespace >>>>>> test/jdk/tools/jpackage/share/AddLauncherBase.java:137: Trailing >>>>>> whitespace >>>>>> >>>>>> The second of these will go away with the fix for JDK-8234402 >>>>>> [6], so you don't need to do anything there. Once the fix for >>>>>> JDK-8234402 is pushed to sandbox, I presume you will update the >>>>>> webrev, right? >>>>>> >>>>>> Pending the fix for JDK-8234402 and the needed white-space fixes, >>>>>> this is a +1 from me (although I am not a jdk Project Reviewer, >>>>>> so you will need at least one review from someone who is). >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> [5] http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-10.git.patch >>>>>> [6] https://bugs.openjdk.java.net/browse/JDK-8234402 >>>>>> >>>>>> >>>>>> On 11/13/2019 4:23 PM, Andy Herrick wrote: >>>>>>> Please review changes for [1] which is the implementation bug >>>>>>> for JEP-343. >>>>>>> >>>>>>> The webrev at [2] is the total cumulative webrev of changes for >>>>>>> the jpackage tool, currently in the JDK-8200758-branch branch of >>>>>>> the open sandbox repository. >>>>>>> >>>>>>> The webrev at [3] shows the changes since EA-06 (Build >>>>>>> 13-jpackage+1-49 ) up to the current point. >>>>>>> >>>>>>> The latest EA (Build 14-jpackage+1-49 ) is posted at [4]. >>>>>>> >>>>>>> Please send feedback to core-libs-dev at openjdk.java.net >>>>>>> >>>>>>> >>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8212780 >>>>>>> >>>>>>> [2] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-10/ >>>>>>> >>>>>>> [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-10/ >>>>>>> >>>>>>> [4] http://jdk.java.net/jpackage/ >>>>>>> >>>>>> >>> >> From ivan.gerasimov at oracle.com Wed Nov 27 04:39:28 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 26 Nov 2019 20:39:28 -0800 Subject: RFR 8234147 : Avoid looking up standard charsets in core libraries Message-ID: <8e010258-7a18-3165-1d11-7aa89b996aa4@oracle.com> Hello! It is a cleanup fix with mostly two kinds of changes: - when a standard charset is specified by its name, use a preinitialized Charset constant instead, - replace the usage of StandardCharset.* constants with their sun.nio.cs.* equivalents to avoid accidental early initialization of rarely-used charsets. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8234147 WEBREV: http://cr.openjdk.java.net/~igerasim/8234147/00/webrev/ I also had to modify one regression test that relied on a private auxiliary method, which was removed with the fix. Mach5 control build looks green. Would you please help review the fix? -- With kind regards, Ivan Gerasimov From sureshkumar.mahaliswamy at oracle.com Wed Nov 27 07:45:41 2019 From: sureshkumar.mahaliswamy at oracle.com (Sureshkumar Mahaliswamy) Date: Tue, 26 Nov 2019 23:45:41 -0800 (PST) Subject: RFR(S) : 8234309:LFGarbageCollectedTest.java fails with parse Exception Message-ID: <37c6ccee-8cbe-458b-aa09-2c93289e0d8f@default> Hi All, Kindly review the small patch. Moved @library /lib/testlibrary /java/lang/invoke/common to the top to avoid the parse exception and report as Test ignored. JBS: https://bugs.openjdk.java.net/browse/JDK-8234309 Webrev: http://cr.openjdk.java.net/~vagarwal/8234309/webrev.0/ Testing: tested with jtreg. Thanks, Suresh. From Alan.Bateman at oracle.com Wed Nov 27 07:54:33 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 Nov 2019 07:54:33 +0000 Subject: RFR 8234147 : Avoid looking up standard charsets in core libraries In-Reply-To: <8e010258-7a18-3165-1d11-7aa89b996aa4@oracle.com> References: <8e010258-7a18-3165-1d11-7aa89b996aa4@oracle.com> Message-ID: On 27/11/2019 04:39, Ivan Gerasimov wrote: > Hello! > > It is a cleanup fix with mostly two kinds of changes: > - when a standard charset is specified by its name, use a > preinitialized Charset constant instead, > - replace the usage of StandardCharset.* constants with their > sun.nio.cs.* equivalents to avoid accidental early initialization of > rarely-used charsets. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8234147 > WEBREV: http://cr.openjdk.java.net/~igerasim/8234147/00/webrev/ > > I also had to modify one regression test that relied on a private > auxiliary method, which was removed with the fix. > > Mach5 control build looks green. > > Would you please help review the fix? The motivation is okay and most of the changes are okay but it does create a needless dependency on sun.nio.* classes in places that are unlikely (or impossible) to use during early startup. I think the change to the JDBC CachedRow implementation, prefs, and the jdk.net.httpserver module should be dropped as want fewer classes outside of java.base depending on java.base internals, not more. I also wonder about the NTLM, XML properties and a few more that shouldn't be dependency on sun.nio.* classes if possible. Minot nit but if this is pushed then it would be good to keep the imports consistent with the existing style where you can, e.g. I see several files where the import sun.nio.* is put at the top of source files that already group imports of JDK internal classes together further down. Mandy might want to comment on TrySetAccessibleTest. If I'm not mistaken it should say "non-exported" rather than "exported". Also I think we want this test to have a dependency on a few JDK internal and private methods as possible as it's a maintenance issue to keep it up to date (as you've experienced here with the removal of Perf.getBytes). -Alan From matthias.baesken at sap.com Wed Nov 27 08:56:08 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 27 Nov 2019 08:56:08 +0000 Subject: RFR: 8234821: remove unused functions from libjli Message-ID: Hello, I missed the reference from windows only code to JLI_MemRealloc , new webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8234821.1/ Best regards, Matthias Hello, please review this small change . It removed unneeded functions from libjli (shown by link-time-gc) . libjli contains a few functions that are shown as unused when applying link-time-gc . Those functions fall into 2 categories : - totally unused/uncalled functions (can be deleted ) - functions that are always inlined, but still kept separate when linking (making them static often helps to remove the unneeded duplicate ) ( Similar approach has been done to libnet , see : 8234629: remove unused functions from libnet ) Thanks, Matthias Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8234821 http://cr.openjdk.java.net/~mbaesken/webrevs/8234821.0/ From ivan.gerasimov at oracle.com Wed Nov 27 11:52:03 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 27 Nov 2019 03:52:03 -0800 Subject: RFR 8234147 : Avoid looking up standard charsets in core libraries In-Reply-To: References: <8e010258-7a18-3165-1d11-7aa89b996aa4@oracle.com> Message-ID: <2f1c999e-5d99-e625-644a-399f63b3be27@oracle.com> Thank you Alan for reviewing! Please see the comments inline. On 11/26/19 11:54 PM, Alan Bateman wrote: > On 27/11/2019 04:39, Ivan Gerasimov wrote: >> Hello! >> >> It is a cleanup fix with mostly two kinds of changes: >> - when a standard charset is specified by its name, use a >> preinitialized Charset constant instead, >> - replace the usage of StandardCharset.* constants with their >> sun.nio.cs.* equivalents to avoid accidental early initialization of >> rarely-used charsets. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8234147 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8234147/00/webrev/ >> >> I also had to modify one regression test that relied on a private >> auxiliary method, which was removed with the fix. >> >> Mach5 control build looks green. >> >> Would you please help review the fix? > The motivation is okay and most of the changes are okay but it does > create a needless dependency on sun.nio.* classes in places that are > unlikely (or impossible) to use during early startup. I think the > change to the JDBC CachedRow implementation, prefs, and the > jdk.net.httpserver module should be dropped as want fewer classes > outside of java.base depending on java.base internals, not more. I > also wonder about the NTLM, XML properties and a few more that > shouldn't be dependency on sun.nio.* classes if possible. > Please note that in fact sun.nio.cs.* was not used in java.net.http, java.prefs and java.sql.rowset.? I only used those sun.nio constants inside the java.base module, exactly for the reason of avoiding additional dependencies. It's not clear how to distinguish the classes inside the java.base module that do not have to depend on sun.nio.cs.? If you feel strong about NTLM and XML, I can replace sun.nio.cs.* instances with corresponding java.charset.StandardCharsets.* constants in these classes. > > > Minot nit but if this is pushed then it would be good to keep the > imports consistent with the existing style where you can, e.g. I see > several files where the import sun.nio.* is put at the top of source > files that already group imports of JDK internal classes together > further down. > Thanks, done.? Unfortunately, imports conventions are not very consistent across the JDK code, so I mostly tried to preserve the pre-existing order of imports in each file. > Mandy might want to comment on TrySetAccessibleTest. If I'm not > mistaken it should say "non-exported" rather than "exported". Also I > think we want this test to have a dependency on a few JDK internal and > private methods as possible as it's a maintenance issue to keep it up > to date (as you've experienced here with the removal of Perf.getBytes). > If I got it correct, the test was meant to access a private static method, and after removing Perf.getBytes there were no such methods left in the Perf class.? That's why I had to pick some other method to test, so I chose ModulePath.packageName instead. Here's the updated webrev with reorganized imports: http://cr.openjdk.java.net/~igerasim/8234147/01/webrev/ Thanks again! -- With kind regards, Ivan Gerasimov From david.lloyd at redhat.com Wed Nov 27 14:04:38 2019 From: david.lloyd at redhat.com (David Lloyd) Date: Wed, 27 Nov 2019 08:04:38 -0600 Subject: New candidate JEP: 370: Foreign-Memory Access API In-Reply-To: <20191125172756.29B2330F46E@eggemoggin.niobe.net> References: <20191125172756.29B2330F46E@eggemoggin.niobe.net> Message-ID: On Mon, Nov 25, 2019 at 11:28 AM wrote: > > https://openjdk.java.net/jeps/370 One more question! Well, two I guess. First, in the interim before Panama or something like it comes to the main project, will it be possible to pass MemoryAddress kinds of things to JNI methods (to replace the current "pattern" of sticking pointer values into `long` fields)? Could the JNI API be extended for this purpose? Second, what about an API to allocate memory from the stack? This is really useful in GraalVM (granted they have a sort-of-Panama-ish way of calling C functions already, and they're really quite "loose" when it comes to safety in some regards) and could simplify some things already, particularly if the pointer could then be passed to a JNI method. Given the sensitive nature of stack allocation you'd probably have to add some extra checks (like checking that the thread matches on each access and that it is in scope, and you'd probably have to do the latter via callback like StackWalker does) but it would be pretty useful nonetheless. -- - DML From andy.herrick at oracle.com Wed Nov 27 14:07:19 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 27 Nov 2019 09:07:19 -0500 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: <5DDDD8F9.3060906@oracle.com> References: <35372d0e-910a-d8c1-6bf4-88fcb140daee@oracle.com> <2589963b-b10e-7af9-bf1a-208df190fb2a@oracle.com> <2345349e-6658-5d3c-e191-4bfbd79a13ae@oracle.com> <281621ac-7a32-6eda-8b16-f35efde450db@oracle.com> <03d92b75-3b3b-bd08-694e-b1d0af2da53f@oracle.com> <5DDDD8F9.3060906@oracle.com> Message-ID: <5f88f4a4-4019-db9e-16b1-0efdd9ff0590@oracle.com> yes - The attempted incremental patch is not much use.? The source files were moved several times, and despite using "hg addremove -s 60", many of the files show as a remove and a new file. /Andy On 11/26/2019 9:01 PM, Philip Race wrote: > > I believe otherwise it is an accurate incremental webrev of the > jpackage changes since EA-5. > > It is also not very incremental. > * > *src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/main/Main.java > > is definitely not "new" ... > > -phil. > > On 11/26/19, 2:17 PM, Andy Herrick wrote: >> yes,? this incremental webrev contains the JNLPConverter code, which >> it should not. >> >> I believe otherwise it is an accurate incremental webrev of the >> jpackage changes since EA-5. >> >> /Andy >> >> On 11/26/2019 4:53 PM, Phil Race wrote: >>> Andy, >>> >>> I am puzzled by what I see here >>> > The webrev at [3] shows the changes since EA-06 (Build >>> 13-jpackage+1-49 ) up to the current point. >>> >>> > [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-10/ >>> >>> This includes the JNLPConverter which isn't what I expected to see and >>> (correctly) isn't in the cumulative webrev .... >>> >>> Since [3] seemed like the most obvious thing to do a review of the >>> recent >>> changes I'd like to be sure it has the correct content and I am not >>> sure it does ... >>> >>> -phil. >>> >>> On 11/26/19 1:36 PM, Kevin Rushforth wrote: >>>> This all looks good. >>>> >>>> +1 >>>> >>>> -- Kevin >>>> >>>> >>>> On 11/26/2019 12:56 PM, Erik Joelsson wrote: >>>>> (adding build-dev) >>>>> >>>>> Build changes look good. >>>>> >>>>> /Erik >>>>> >>>>> On 2019-11-20 09:37, Andy Herrick wrote: >>>>>> I posted new composite webrev [7], and git patch [8] after >>>>>> pushing fix for JDK-8234402 [6]. >>>>>> >>>>>> [7] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11/ >>>>>> >>>>>> [8] http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-11.git.patch >>>>>> >>>>>> /Andy >>>>>> >>>>>> On 11/19/2019 3:13 PM, Kevin Rushforth wrote: >>>>>>> I took the "git diff" patch [5] that you uploaded yesterday, >>>>>>> applied it, and verified that it is the same as what is in the >>>>>>> JDK-8200758-branch branch of the sandbox. It builds and runs >>>>>>> fine for me. >>>>>>> >>>>>>> I ran jcheck and it found the following three files with >>>>>>> whitespace errors that will need to be fixed before you push: >>>>>>> >>>>>>> src/jdk.incubator.jpackage/linux/classes/jdk/incubator/jpackage/internal/PackageProperty.java:49: >>>>>>> Trailing whitespace >>>>>>> src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/ToolProviderFactory.java:35: >>>>>>> Trailing whitespace >>>>>>> test/jdk/tools/jpackage/share/AddLauncherBase.java:137: Trailing >>>>>>> whitespace >>>>>>> >>>>>>> The second of these will go away with the fix for JDK-8234402 >>>>>>> [6], so you don't need to do anything there. Once the fix for >>>>>>> JDK-8234402 is pushed to sandbox, I presume you will update the >>>>>>> webrev, right? >>>>>>> >>>>>>> Pending the fix for JDK-8234402 and the needed white-space >>>>>>> fixes, this is a +1 from me (although I am not a jdk Project >>>>>>> Reviewer, so you will need at least one review from someone who >>>>>>> is). >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> [5] http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-10.git.patch >>>>>>> [6] https://bugs.openjdk.java.net/browse/JDK-8234402 >>>>>>> >>>>>>> >>>>>>> On 11/13/2019 4:23 PM, Andy Herrick wrote: >>>>>>>> Please review? changes for [1] which is the implementation bug >>>>>>>> for JEP-343. >>>>>>>> >>>>>>>> The webrev at [2] is the total cumulative webrev of changes for >>>>>>>> the jpackage tool, currently in the JDK-8200758-branch branch >>>>>>>> of the open sandbox repository. >>>>>>>> >>>>>>>> The webrev at [3] shows the changes since EA-06 (Build >>>>>>>> 13-jpackage+1-49 ) up to the current point. >>>>>>>> >>>>>>>> The latest EA (Build 14-jpackage+1-49 ) is posted at [4]. >>>>>>>> >>>>>>>> Please send feedback to core-libs-dev at openjdk.java.net >>>>>>>> >>>>>>>> >>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8212780 >>>>>>>> >>>>>>>> [2] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-10/ >>>>>>>> >>>>>>>> [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-10/ >>>>>>>> >>>>>>>> [4] http://jdk.java.net/jpackage/ >>>>>>>> >>>>>>> >>>> >>> From maurizio.cimadamore at oracle.com Wed Nov 27 14:32:57 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 27 Nov 2019 14:32:57 +0000 Subject: New candidate JEP: 370: Foreign-Memory Access API In-Reply-To: References: <20191125172756.29B2330F46E@eggemoggin.niobe.net> Message-ID: <34b5594d-0a56-c7fb-0906-c585121d6284@oracle.com> Hi David On 27/11/2019 14:04, David Lloyd wrote: > On Mon, Nov 25, 2019 at 11:28 AM wrote: >> https://openjdk.java.net/jeps/370 > One more question! Well, two I guess. > > First, in the interim before Panama or something like it comes to the > main project, will it be possible to pass MemoryAddress kinds of > things to JNI methods (to replace the current "pattern" of sticking > pointer values into `long` fields)? Could the JNI API be extended for > this purpose? Fair point. The second step of the Panama effort will allow you to create 'native' MethodHandles - which you can then call as any other method handle. For an example on how to use them, look here [1]. In other words, a native library accepting a pointer will be modeled as a MethodHandle accepting a MemoryAddress. This step is actually not that far away (we are mostly working on the implementation internals at this point), so I don't think there's enough of a reason to provide an interim solution. > > Second, what about an API to allocate memory from the stack? This is > really useful in GraalVM (granted they have a sort-of-Panama-ish way > of calling C functions already, and they're really quite "loose" when > it comes to safety in some regards) and could simplify some things > already, particularly if the pointer could then be passed to a JNI > method. Given the sensitive nature of stack allocation you'd probably > have to add some extra checks (like checking that the thread matches > on each access and that it is in scope, and you'd probably have to do > the latter via callback like StackWalker does) but it would be pretty > useful nonetheless. I guess it depends on what the goal is here - if the goal is to 'speed up allocation', there are other ways to skin that cat (and we're actually working on what seems like a very promising direction which we should be able to communicate more publicly soon). But, another related goal would be to be able to express stack allocation in Java directly, so that some of the work for e.g. writing bridge code which goes from Java to native can be expressed in Java directly. While something like this would probably be useful, as an implementation tool (e.g. to implement our own programmable invoker [2]), I don't see that being a priority from a public API perspective (assuming we can make allocation fast enough - that is!). Cheers Maurizio [1] - hg.openjdk.java.net/panama/dev/file/foreign-abi/test/jdk/java/foreign/StdLibTest.java [2] - hg.openjdk.java.net/panama/dev/file/foreign-abi/src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/ProgrammableInvoker.java From Roger.Riggs at oracle.com Wed Nov 27 15:09:39 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 27 Nov 2019 10:09:39 -0500 Subject: RFR of JDK-8232446: logging enhancement for rmi when socket closed In-Reply-To: <5ed904a8-cabc-c49a-7e8c-c73d144ea14e@oracle.com> References: <5048d354-a480-ac6d-e46d-a14ce4349691@oracle.com> <9db082f9-6e16-9e5e-1d99-280bbd381e8f@gmail.com> <50bf13f3-f284-f3f4-1256-8ac51929637b@oracle.com> <5ed904a8-cabc-c49a-7e8c-c73d144ea14e@oracle.com> Message-ID: <56ff5561-79a2-c43d-4a0e-0fdfabe2da84@oracle.com> Looks good. Thanks for the revisions,? Roger On 11/26/19 8:51 PM, Hamlin Li wrote: > > Hi Roger, > > Thanks for reviewing, I have updated as you suggested: > http://cr.openjdk.java.net/~mli/8232446/webrev.01/ > > Thank you > > -Hamlin > > On 2019/11/27 2:47 AM, Roger Riggs wrote: >> Hi Hamlin, >> >> ok, but it looses the logging of the connection close when the socket >> is null. >> I intended to suggest that the logging happened before/outside the test >> for socket != null. >> >> if (TCPTransport.tcpLog.isLoggable(Log.BRIEF)) { >> TCPTransport.tcpLog.log(Log.BRIEF,"close connection, socket: " + socket); >> }if (socket != null) { Thanks, Roger >> On 11/22/19 2:54 AM, Hamlin Li wrote: >>> Hi Roger, >>> >>> Thank you for reviewing, I have updated as you suggested: >>> http://cr.openjdk.java.net/~mli/8232446/webrev.01/ >>> >>> Thank you >>> >>> -Hamlin >>> >>> On 2019/11/18 11:48 PM, Roger Riggs wrote: >>>> Hi Hamlin, >>>> >>>> TCPConnection.java:212: >>>> >>>> Keep the "close connection" logging and add the socket to the same >>>> log message: >>>> >>>> If anyone is scraping the log, they won't loose this message. >>>> TCPTransport.tcpLog.log(Log.BRIEF, "close connection, socket: " + >>>> socket); >>>> >>>> TCPTransport.java >>>> >>>> 277-278:? combine the message to be one logging call. >>>> server socket >>>> 289: use Log.BRIEF, avoid creating mixture of and too many log levels. >>>> >>>> Reword the log messages so they each begin with "server socket...", >>>> or "server socket close"... >>>> it makes it easier to grep for and coorelate related messages >>>> >>>> Thanks, Roger >>>> >>>> >>>> On 11/6/19 7:02 AM, Hamlin Li wrote: >>>>> >>>>> On 2019/11/6 5:36 PM, Peter Levart wrote: >>>>>> Hi Hamlin, >>>>>> >>>>>> in TCPTransport.decrementExportCount(): >>>>>> >>>>>> ?283???????????? try { >>>>>> ?284???????????????? if (tcpLog.isLoggable(Log.BRIEF)) { >>>>>> ?285???????????????????? tcpLog.log(Log.BRIEF, "close server >>>>>> socket on " + ss); >>>>>> ?286???????????????? } >>>>>> ?287???????????????? ss.close(); >>>>>> ?288???????????? } catch (IOException e) { >>>>>> ?289???????????? } >>>>>> >>>>>> ...you could add a log statement to the catch block too. Or even >>>>>> better, rearrange for IOException to be thrown from that method >>>>>> and deal with it in two places: >>>>>> >>>>>> - in exportObject() - add it as suppressed exception to exception >>>>>> thrown from super.exportObject(). >>>>>> - in targetUnexported() - log it or wrap it into >>>>>> UncheckedIOException (depending on what are the callers of >>>>>> targetUnexported()) >>>>>> >>>>>> What do you think? >>>>> Thanks Peter. >>>>> >>>>> I agree. I adopt your first suggestion: add log statement to catch >>>>> block, as I think it's simple/straight and sufficient to help >>>>> diagnose. >>>>> >>>>> And I also add log for catch blocks in other close places. >>>>> >>>>> The change is updated in place at: >>>>> http://cr.openjdk.java.net/~mli/8232446/webrev.00/ >>>>> >>>>> >>>>> Thank you >>>>> >>>>> -Hamlin >>>>> >>>>>> >>>>>> Regards, Peter >>>>>> >>>>>> >>>>>> >>>>>> On 11/6/19 3:07 AM, Hamlin Li wrote: >>>>>>> Would you please review the patch? >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8232446 >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~mli/8232446/webrev.00/ >>>>>>> >>>>>>> >>>>>>> We have some intermittent failures in rmi related to socket >>>>>>> closing, this is to add more logging to help diagnose the issues. >>>>>>> >>>>>>> >>>>>>> Thanks you >>>>>>> >>>>>>> -Hamlin >>>>>>> >>>>>> >>>> >> From Roger.Riggs at oracle.com Wed Nov 27 15:27:43 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 27 Nov 2019 10:27:43 -0500 Subject: RFR 8233799 (doc) Review the need for overview.html in the java.time package Message-ID: Please review a trivial removal of a vestigal and unreferenced overview.html for java.time. The same information had been incorporated into the package-info.java. Nothing much to it just the removal of: ???? src/java.base/share/classes/java/time/overview.html Webrev:? http://cr.openjdk.java.net/~rriggs/webrev-overview-8233799/ Thanks, Roger From joe.darcy at oracle.com Wed Nov 27 15:44:51 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 27 Nov 2019 07:44:51 -0800 Subject: JDK 14 RFR of JDK-8234917: "Explicitly discuss java.lang.Enum in Class.isEnum spec" Message-ID: <88cd2223-6197-9e4f-b471-98385ce0e84a@oracle.com> Hello, Please review the small doc RFE to address ??? JDK-8234917: "Explicitly discuss java.lang.Enum in Class.isEnum spec" Patch below; thanks, -Joe --- a/src/java.base/share/classes/java/lang/Class.java??? Wed Nov 27 06:36:41 2019 -0800 +++ b/src/java.base/share/classes/java/lang/Class.java??? Wed Nov 27 06:53:07 2019 -0800 @@ -3503,7 +3503,9 @@ ????? * Returns true if and only if this class was declared as an enum in the ????? * source code. ????? * -???? * Note that if an enum constant is declared with a class body, +???? * Note that {@link java.lang.Enum} is not itself an enum type. +???? * +???? * Also note that if an enum constant is declared with a class body, ????? * the class of that enum constant object is an anonymous class ????? * and not the class of the declaring enum type. The ????? * {@link Enum#getDeclaringClass} method of an enum constant can From jonathan.gibbons at oracle.com Wed Nov 27 15:46:33 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 27 Nov 2019 07:46:33 -0800 Subject: JDK 14 RFR of JDK-8234917: "Explicitly discuss java.lang.Enum in Class.isEnum spec" In-Reply-To: <88cd2223-6197-9e4f-b471-98385ce0e84a@oracle.com> References: <88cd2223-6197-9e4f-b471-98385ce0e84a@oracle.com> Message-ID: <4720b900-9f44-1a0d-fac3-372953b43fae@oracle.com> LGTM -- Jon On 11/27/19 7:44 AM, Joe Darcy wrote: > Hello, > > Please review the small doc RFE to address > > ??? JDK-8234917: "Explicitly discuss java.lang.Enum in Class.isEnum spec" > > Patch below; thanks, > > -Joe > > --- a/src/java.base/share/classes/java/lang/Class.java??? Wed Nov 27 > 06:36:41 2019 -0800 > +++ b/src/java.base/share/classes/java/lang/Class.java??? Wed Nov 27 > 06:53:07 2019 -0800 > @@ -3503,7 +3503,9 @@ > ????? * Returns true if and only if this class was declared as an enum > in the > ????? * source code. > ????? * > -???? * Note that if an enum constant is declared with a class body, > +???? * Note that {@link java.lang.Enum} is not itself an enum type. > +???? * > +???? * Also note that if an enum constant is declared with a class body, > ????? * the class of that enum constant object is an anonymous class > ????? * and not the class of the declaring enum type. The > ????? * {@link Enum#getDeclaringClass} method of an enum constant can > From daniel.fuchs at oracle.com Wed Nov 27 15:59:51 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 27 Nov 2019 15:59:51 +0000 Subject: RFR 8233799 (doc) Review the need for overview.html in the java.time package In-Reply-To: References: Message-ID: Looks good Roger! That was confusing alright. best regards, -- daniel On 27/11/2019 15:27, Roger Riggs wrote: > Please review a trivial removal of a vestigal and unreferenced > overview.html for java.time. > The same information had been incorporated into the package-info.java. > > Nothing much to it just the removal of: > ???? src/java.base/share/classes/java/time/overview.html > > Webrev:? http://cr.openjdk.java.net/~rriggs/webrev-overview-8233799/ > > Thanks, Roger > > > From naoto.sato at oracle.com Wed Nov 27 17:02:40 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 27 Nov 2019 09:02:40 -0800 Subject: RFR 8233799 (doc) Review the need for overview.html in the java.time package In-Reply-To: References: Message-ID: <90167996-99be-7ea2-5081-a71c3c232567@oracle.com> +1 Naoto On 11/27/19 7:59 AM, Daniel Fuchs wrote: > Looks good Roger! > > That was confusing alright. > > best regards, > > -- daniel > > On 27/11/2019 15:27, Roger Riggs wrote: >> Please review a trivial removal of a vestigal and unreferenced >> overview.html for java.time. >> The same information had been incorporated into the package-info.java. >> >> Nothing much to it just the removal of: >> ????? src/java.base/share/classes/java/time/overview.html >> >> Webrev:? http://cr.openjdk.java.net/~rriggs/webrev-overview-8233799/ >> >> Thanks, Roger >> >> >> > From lance.andersen at oracle.com Wed Nov 27 17:12:05 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 27 Nov 2019 12:12:05 -0500 Subject: RFR 8233799 (doc) Review the need for overview.html in the java.time package In-Reply-To: References: Message-ID: <9BB3D7B0-A215-4C8D-9FD2-413BC1ACC1D4@oracle.com> +1 > On Nov 27, 2019, at 10:27 AM, Roger Riggs wrote: > > Please review a trivial removal of a vestigal and unreferenced overview.html for java.time. > The same information had been incorporated into the package-info.java. > > Nothing much to it just the removal of: > src/java.base/share/classes/java/time/overview.html > > Webrev: http://cr.openjdk.java.net/~rriggs/webrev-overview-8233799/ > > Thanks, Roger > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Alan.Bateman at oracle.com Wed Nov 27 20:53:23 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 Nov 2019 20:53:23 +0000 Subject: RFR 8234147 : Avoid looking up standard charsets in core libraries In-Reply-To: <2f1c999e-5d99-e625-644a-399f63b3be27@oracle.com> References: <8e010258-7a18-3165-1d11-7aa89b996aa4@oracle.com> <2f1c999e-5d99-e625-644a-399f63b3be27@oracle.com> Message-ID: On 27/11/2019 11:52, Ivan Gerasimov wrote: > : > > It's not clear how to distinguish the classes inside the java.base > module that do not have to depend on sun.nio.cs.? If you feel strong > about NTLM and XML, I can replace sun.nio.cs.* instances with > corresponding java.charset.StandardCharsets.* constants in these classes. There isn't any way to say what is core and non-core in java.base so you have to use your judgement. My personal view is that the NTLM, XML, SOCKS and several others in this patch should stick to the standard APIs if possible as their performance will likely be dominated by other factors. > > Thanks, done.? Unfortunately, imports conventions are not very > consistent across the JDK code, so I mostly tried to preserve the > pre-existing order of imports in each file. Okay. > > If I got it correct, the test was meant to access a private static > method, and after removing Perf.getBytes there were no such methods > left in the Perf class.? That's why I had to pick some other method to > test, so I chose ModulePath.packageName instead. The test is trying to cover all the possible accessibilities. The "exported package" descriptions are a bit confusing but are explained by the test running--add-exports. My only concern with the change is that it expands the dependences on internals to classes in 3 packages, it means anyone touching those classes may have to fix up this test. So overall I think this patch is okay, just me trying to avoid coupling when we can. -Alan From huaming.li at oracle.com Thu Nov 28 04:10:03 2019 From: huaming.li at oracle.com (Hamlin Li) Date: Thu, 28 Nov 2019 12:10:03 +0800 Subject: RFR of JDK-8232446: logging enhancement for rmi when socket closed In-Reply-To: <56ff5561-79a2-c43d-4a0e-0fdfabe2da84@oracle.com> References: <5048d354-a480-ac6d-e46d-a14ce4349691@oracle.com> <9db082f9-6e16-9e5e-1d99-280bbd381e8f@gmail.com> <50bf13f3-f284-f3f4-1256-8ac51929637b@oracle.com> <5ed904a8-cabc-c49a-7e8c-c73d144ea14e@oracle.com> <56ff5561-79a2-c43d-4a0e-0fdfabe2da84@oracle.com> Message-ID: Hi Roger, Thanks for reviewing. Thank you -Hamlin On 2019/11/27 11:09 PM, Roger Riggs wrote: > Looks good. > > Thanks for the revisions,? Roger > > On 11/26/19 8:51 PM, Hamlin Li wrote: >> >> Hi Roger, >> >> Thanks for reviewing, I have updated as you suggested: >> http://cr.openjdk.java.net/~mli/8232446/webrev.01/ >> >> Thank you >> >> -Hamlin >> >> On 2019/11/27 2:47 AM, Roger Riggs wrote: >>> Hi Hamlin, >>> >>> ok, but it looses the logging of the connection close when the >>> socket is null. >>> I intended to suggest that the logging happened before/outside the test >>> for socket != null. >>> >>> if (TCPTransport.tcpLog.isLoggable(Log.BRIEF)) { >>> TCPTransport.tcpLog.log(Log.BRIEF,"close connection, socket: " + >>> socket); >>> }if (socket != null) { Thanks, Roger >>> On 11/22/19 2:54 AM, Hamlin Li wrote: >>>> Hi Roger, >>>> >>>> Thank you for reviewing, I have updated as you suggested: >>>> http://cr.openjdk.java.net/~mli/8232446/webrev.01/ >>>> >>>> Thank you >>>> >>>> -Hamlin >>>> >>>> On 2019/11/18 11:48 PM, Roger Riggs wrote: >>>>> Hi Hamlin, >>>>> >>>>> TCPConnection.java:212: >>>>> >>>>> Keep the "close connection" logging and add the socket to the same >>>>> log message: >>>>> >>>>> If anyone is scraping the log, they won't loose this message. >>>>> TCPTransport.tcpLog.log(Log.BRIEF, "close connection, socket: " + >>>>> socket); >>>>> >>>>> TCPTransport.java >>>>> >>>>> 277-278:? combine the message to be one logging call. >>>>> server socket >>>>> 289: use Log.BRIEF, avoid creating mixture of and too many log >>>>> levels. >>>>> >>>>> Reword the log messages so they each begin with "server socket...", >>>>> or "server socket close"... >>>>> it makes it easier to grep for and coorelate related messages >>>>> >>>>> Thanks, Roger >>>>> >>>>> >>>>> On 11/6/19 7:02 AM, Hamlin Li wrote: >>>>>> >>>>>> On 2019/11/6 5:36 PM, Peter Levart wrote: >>>>>>> Hi Hamlin, >>>>>>> >>>>>>> in TCPTransport.decrementExportCount(): >>>>>>> >>>>>>> ?283???????????? try { >>>>>>> ?284???????????????? if (tcpLog.isLoggable(Log.BRIEF)) { >>>>>>> ?285???????????????????? tcpLog.log(Log.BRIEF, "close server >>>>>>> socket on " + ss); >>>>>>> ?286???????????????? } >>>>>>> ?287???????????????? ss.close(); >>>>>>> ?288???????????? } catch (IOException e) { >>>>>>> ?289???????????? } >>>>>>> >>>>>>> ...you could add a log statement to the catch block too. Or even >>>>>>> better, rearrange for IOException to be thrown from that method >>>>>>> and deal with it in two places: >>>>>>> >>>>>>> - in exportObject() - add it as suppressed exception to >>>>>>> exception thrown from super.exportObject(). >>>>>>> - in targetUnexported() - log it or wrap it into >>>>>>> UncheckedIOException (depending on what are the callers of >>>>>>> targetUnexported()) >>>>>>> >>>>>>> What do you think? >>>>>> Thanks Peter. >>>>>> >>>>>> I agree. I adopt your first suggestion: add log statement to >>>>>> catch block, as I think it's simple/straight and sufficient to >>>>>> help diagnose. >>>>>> >>>>>> And I also add log for catch blocks in other close places. >>>>>> >>>>>> The change is updated in place at: >>>>>> http://cr.openjdk.java.net/~mli/8232446/webrev.00/ >>>>>> >>>>>> >>>>>> Thank you >>>>>> >>>>>> -Hamlin >>>>>> >>>>>>> >>>>>>> Regards, Peter >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 11/6/19 3:07 AM, Hamlin Li wrote: >>>>>>>> Would you please review the patch? >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8232446 >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~mli/8232446/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> We have some intermittent failures in rmi related to socket >>>>>>>> closing, this is to add more logging to help diagnose the issues. >>>>>>>> >>>>>>>> >>>>>>>> Thanks you >>>>>>>> >>>>>>>> -Hamlin >>>>>>>> >>>>>>> >>>>> >>> > From vicente.romero at oracle.com Thu Nov 28 04:37:21 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 27 Nov 2019 23:37:21 -0500 Subject: RFR: JEP 359: Records (Preview) (full code) Message-ID: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> Hi, Please review the code for the records feature at [1]. This webrev includes all: APIs, runtime, compiler, serialization, javadoc, and more! Must of the code has been reviewed but there have been some changes since reviewers saw it. Also this is the first time an integral webrev is sent out for review. Last changes on top of my mind since last review iterations: On the compiler implementation: - it has been adapted to the last version of the language spec [2], as a reference the JVM spec is at [3]. This implied some changes in determining if a user defined constructor is the canonical or not. Now if a constructor is override-equivalent to a signature derived from the record components, then it is considered the canonical constructor. And any canonical constructor should satisfy a set of restrictions, see section 8.10.4 Record Constructor Declarations of the specification. - It was also added a check to make sure that accessors are not generic. - And that the canonical constructor, if user defined, is not explicitly invoking any other constructor. - The list of forbidden record component names has also been updated. - new error messages have been added APIs: - there have been some API editing in java.lang.Record, java.lang.runtime.ObjectMethods and java.lang.reflect.RecordComponent, java.io.ObjectInputStream, javax.lang.model (some visitors were added) On the JVM implementation: - some logging capabilities have been added to classFileParser.cpp to provide the reason for which the Record attribute has been ignored Reflection: - there are several new changes to the implementation of java.lang.reflect.RecordComponent apart from the spec changes mentioned before. bug fixes in - compiler - serialization, - JVM, etc As a reference the last iteration of the previous reviews can be found at [4] under folders: compiler, hotspot_runtime, javadoc, reflection and serialization, TIA, Vicente [1] http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.00/ [2] http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html [3] http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html [4] http://cr.openjdk.java.net/~vromero/records.review/ From chris.hegarty at oracle.com Thu Nov 28 09:07:55 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 28 Nov 2019 09:07:55 +0000 Subject: JDK 14 RFR of JDK-8234917: "Explicitly discuss java.lang.Enum in Class.isEnum spec" In-Reply-To: <88cd2223-6197-9e4f-b471-98385ce0e84a@oracle.com> References: <88cd2223-6197-9e4f-b471-98385ce0e84a@oracle.com> Message-ID: Looks good Joe. -Chris. > On 27 Nov 2019, at 15:44, Joe Darcy wrote: > > Hello, > > Please review the small doc RFE to address > > JDK-8234917: "Explicitly discuss java.lang.Enum in Class.isEnum spec" > > Patch below; thanks, > > -Joe > > --- a/src/java.base/share/classes/java/lang/Class.java Wed Nov 27 06:36:41 2019 -0800 > +++ b/src/java.base/share/classes/java/lang/Class.java Wed Nov 27 06:53:07 2019 -0800 > @@ -3503,7 +3503,9 @@ > * Returns true if and only if this class was declared as an enum in the > * source code. > * > - * Note that if an enum constant is declared with a class body, > + * Note that {@link java.lang.Enum} is not itself an enum type. > + * > + * Also note that if an enum constant is declared with a class body, > * the class of that enum constant object is an anonymous class > * and not the class of the declaring enum type. The > * {@link Enum#getDeclaringClass} method of an enum constant can > From christoph.langer at sap.com Thu Nov 28 10:34:33 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 28 Nov 2019 10:34:33 +0000 Subject: RFR: 8234821: remove unused functions from libjli In-Reply-To: References: Message-ID: Hi Matthias, overall this looks good to me. The only change to src/java.base/share/native/libjli/jli_util.c is the copyrights, so I guess this should be omitted... Cheers Christoph > -----Original Message----- > From: core-libs-dev On Behalf > Of Baesken, Matthias > Sent: Mittwoch, 27. November 2019 09:56 > To: core-libs-dev at openjdk.java.net > Subject: [CAUTION] RE: RFR: 8234821: remove unused functions from libjli > > Hello, I missed the reference from windows only code to JLI_MemRealloc , > new webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8234821.1/ > > Best regards, Matthias > > > > Hello, please review this small change . > It removed unneeded functions from libjli (shown by link-time-gc) . > > libjli contains a few functions that are shown as unused when applying link- > time-gc . > Those functions fall into 2 categories : > - totally unused/uncalled functions (can be deleted ) > - functions that are always inlined, but still kept separate when linking > (making them static often helps to remove the unneeded duplicate ) > > > ( Similar approach has been done to libnet , see : 8234629: remove unused > functions from libnet ) > > > > Thanks, Matthias > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8234821 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8234821.0/ > From matthias.baesken at sap.com Thu Nov 28 12:02:17 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 28 Nov 2019 12:02:17 +0000 Subject: RFR: 8234821: remove unused functions from libjli In-Reply-To: References: Message-ID: Thanks for the review . I'll adjust the COPYRIGHT . Will push this as XS in case of no objections. Best regards, Matthias > -----Original Message----- > From: Langer, Christoph > Sent: Donnerstag, 28. November 2019 11:35 > To: Baesken, Matthias ; core-libs- > dev at openjdk.java.net > Subject: RE: RFR: 8234821: remove unused functions from libjli > > Hi Matthias, > > overall this looks good to me. > > The only change to src/java.base/share/native/libjli/jli_util.c is the > copyrights, so I guess this should be omitted... > > Cheers > Christoph > > > -----Original Message----- > > From: core-libs-dev On Behalf > > Of Baesken, Matthias > > Sent: Mittwoch, 27. November 2019 09:56 > > To: core-libs-dev at openjdk.java.net > > Subject: [CAUTION] RE: RFR: 8234821: remove unused functions from libjli > > > > Hello, I missed the reference from windows only code to JLI_MemRealloc > , > > new webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8234821.1/ > > > > Best regards, Matthias > > > > > > > > Hello, please review this small change . > > It removed unneeded functions from libjli (shown by link-time-gc) . > > > > libjli contains a few functions that are shown as unused when applying link- > > time-gc . > > Those functions fall into 2 categories : > > - totally unused/uncalled functions (can be deleted ) > > - functions that are always inlined, but still kept separate when linking > > (making them static often helps to remove the unneeded duplicate ) > > > > > > ( Similar approach has been done to libnet , see : 8234629: remove unused > > functions from libnet ) > > > > > > > > Thanks, Matthias > > > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8234821 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8234821.0/ > > From Alan.Bateman at oracle.com Thu Nov 28 12:33:12 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 Nov 2019 12:33:12 +0000 Subject: RFR: 8234821: remove unused functions from libjli In-Reply-To: References: Message-ID: On 28/11/2019 12:02, Baesken, Matthias wrote: > Thanks for the review . I'll adjust the COPYRIGHT . > > Will push this as XS in case of no objections. > I think this look okay. I assume you'll send a job through jdk-submit in case there are any residual launcher or installer code that also need to be fixed. -Alan From vicente.romero at oracle.com Thu Nov 28 16:05:52 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 28 Nov 2019 11:05:52 -0500 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> Message-ID: <32b8c703-523f-ae83-291d-4f1b28fa1d91@oracle.com> Hi again, Sorry but I realized that I forgot to remove some code on the compiler side. The code removed is small, before we were issuing an error if some serialization methods were declared as record members. That section was removed from the spec. I have prepared another iteration with this change at [1] Thanks, Vicente [1] http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.01/ On 11/27/19 11:37 PM, Vicente Romero wrote: > Hi, > > Please review the code for the records feature at [1]. This webrev > includes all: APIs, runtime, compiler, serialization, javadoc, and > more! Must of the code has been reviewed but there have been some > changes since reviewers saw it. Also this is the first time an > integral webrev is sent out for review. Last changes on top of my mind > since last review iterations: > > On the compiler implementation: > - it has been adapted to the last version of the language spec [2], as > a reference the JVM spec is at [3]. This implied some changes in > determining if a user defined constructor is the canonical or not. Now > if a constructor is override-equivalent to a signature derived from > the record components, then it is considered the canonical > constructor. And any canonical constructor should satisfy a set of > restrictions, see section 8.10.4 Record Constructor Declarations of > the specification. > - It was also added a check to make sure that accessors are not generic. > - And that the canonical constructor, if user defined, is not > explicitly invoking any other constructor. > - The list of forbidden record component names has also been updated. > - new error messages have been added > > APIs: > - there have been some API editing in java.lang.Record, > java.lang.runtime.ObjectMethods and java.lang.reflect.RecordComponent, > java.io.ObjectInputStream, javax.lang.model (some visitors were added) > > On the JVM implementation: > - some logging capabilities have been added to classFileParser.cpp to > provide the reason for which the Record attribute has been ignored > > Reflection: > - there are several new changes to the implementation of > java.lang.reflect.RecordComponent apart from the spec changes > mentioned before. > > bug fixes in > - compiler > - serialization, > - JVM, etc > > As a reference the last iteration of the previous reviews can be found > at [4] under folders: compiler, hotspot_runtime, javadoc, reflection > and serialization, > > TIA, > Vicente > > [1] > http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.00/ > [2] > http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html > [3] > http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html > [4] http://cr.openjdk.java.net/~vromero/records.review/ > From vladimir.x.ivanov at oracle.com Thu Nov 28 17:24:42 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 28 Nov 2019 20:24:42 +0300 Subject: New candidate JEP: 370: Foreign-Memory Access API In-Reply-To: <34b5594d-0a56-c7fb-0906-c585121d6284@oracle.com> References: <20191125172756.29B2330F46E@eggemoggin.niobe.net> <34b5594d-0a56-c7fb-0906-c585121d6284@oracle.com> Message-ID: <1e88cab1-a6c7-454b-6cc5-6747c67a80cb@oracle.com> >> Second, what about an API to allocate memory from the stack?? This is >> really useful in GraalVM (granted they have a sort-of-Panama-ish way >> of calling C functions already, and they're really quite "loose" when >> it comes to safety in some regards) and could simplify some things >> already, particularly if the pointer could then be passed to a JNI >> method.? Given the sensitive nature of stack allocation you'd probably >> have to add some extra checks (like checking that the thread matches >> on each access and that it is in scope, and you'd probably have to do >> the latter via callback like StackWalker does) but it would be pretty >> useful nonetheless. > > I guess it depends on what the goal is here - if the goal is to 'speed > up allocation', there are other ways to skin that cat (and we're > actually working on what seems like a very promising direction which we > should be able to communicate more publicly soon). But, another related > goal would be to be able to express stack allocation in Java directly, > so that some of the work for e.g. writing bridge code which goes from > Java to native can be expressed in Java directly. While something like > this would probably be useful, as an implementation tool (e.g. to > implement our own programmable invoker [2]), I don't see that being a > priority from a public API perspective (assuming we can make allocation > fast enough - that is!). Yes, stack allocation looks attractive, but in practice its usability is quite limited. (IMO thread-local arena-style memory allocator is more practical.) And it makes some assumptions about how threads and stacks work which are aren't specified by JVMS, but are implementation details. For example, how will it interact with Project Loom? Leaving high-level considerations aside, there's already a way to build stack allocator without any JVM assistance on top of JNI (though definitely not the most efficient and performant one): - do a native call; - allocate memory on stack inside native frame; - do an upcall to user-provided callback and pass a pointer to allocated memory; On Java level it can be exposed as: native R allocateOnStack(long size, LongFunction task); What Memory Access API can add to it is safety: instead of passing raw pointer to stack memory with all safety concerns associated with it, it can be wrapped into a MemorySegment before returning it to the user and on a way back closed, thus effectively forbidding any illegal accesses (both temporal and spatial) and in completely transparent way: R withSegmentOnStack(long size, Function task); As a performance optimization, JIT can then intrinsify the native method and directly allocate memory on stack without the need for auxiliary native frame. It'll provide alloca-like behavior while considerably simplifying JVM support. It definitely looks very interesting in the context of low-level ABI and native invokers, but IMO stack allocation is not a prerequisite for Memory Access API and the API shouldn't wait for it to be released. After there's more data available from ABI experiments, we'll be in a better position to decide how to proceed (either add it to Memory Access API, build a separate API on top, or even drop it). Best regards, Vladimir Ivanov From julia.boes at oracle.com Thu Nov 28 18:15:51 2019 From: julia.boes at oracle.com (Julia Boes) Date: Thu, 28 Nov 2019 18:15:51 +0000 Subject: RFR: 8234964: failure_handler: gather more environment information on Windows, Solaris and Linux Message-ID: Hi, In the case of test failure, the environment information of 'ifconfig -a' is already gathered on macOS systems. The following enhancement allows the same information to be gathered on Linux, Solaris and Windows systems (in the latter case 'ipconfig /all'). Bug: https://bugs.openjdk.java.net/browse/JDK-8234964 Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8234964/webrev.00/ Regards, Julia From maurizio.cimadamore at oracle.com Thu Nov 28 18:35:26 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 28 Nov 2019 18:35:26 +0000 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: <32b8c703-523f-ae83-291d-4f1b28fa1d91@oracle.com> References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> <32b8c703-523f-ae83-291d-4f1b28fa1d91@oracle.com> Message-ID: Hi Vicente, generally looks good - few comments below; I tried to focus on areas where the compiler code seemed to diverge from the spec, as well on pieces of code which look a leftover from previous spec rounds. * canonical constructors *can* have return statements - compact constructors cant; the spec went a bit back and forth on this, but now it has settled. Since compact constructors are turned into ordinary canonical ones by the parser, I think you need to add an extra check for COMPACT_RECORD_CONSTRUCTOR; in other words, this is ok: record Foo() { ?? Foo() { return; } //canonical } this isn't record Foo() { ?? Foo { return; } //compact } but the compiler rejects both. This probably means tweaking the diagnostic a bit to say "a compact constructor must not contain |return| statements" * in general, all diagnostics speak about 'canonical constructor' regardless of whether the constructor is canonical of compact; while I understand the reason behind what we get now, some of the error messages can be confusing, especially if you look at the spec, where canonical constructor and compact constructor are two different concepts. This should be fixed (even if not immediately, in which case I'd recommend to file a JBS issue to track that) * static accessors are allowed - this means that I can do this: record Foo(int x) { public static int x() {return 0; } public static void main(String[] args) { ?? System.err.println(new Foo(42).x()); } } This will compile and print 0. The classfile will contain the following members: final class Foo extends java.lang.Record { ? public Foo(int); ? public static int x(); ? public static void main(java.lang.String[]); ? public java.lang.String toString(); ? public final int hashCode(); ? public final boolean equals(java.lang.Object); } I believe this is an issue in the compiler, but also in the latest spec draft, if I'm not mistaken. * [optional - style] the env.info.isSerializableLambda could become an enum { NONE, LAMBDA, SERIALIZABLE_LAMBDA } instead of two boolean parameters * this code is still rejected with --enable-preview _disabled_: class X { ??? record R(int i) { ??????? return null; ??? } } class record {} This gives the error: Error: |? records are a preview feature and are disabled by default. |??? (use --enable-preview to enable records) |? record R(int i) { return null } } |? ^ |? Error: |? illegal start of type |? record R(int i) { return null } } |??????????????????? ^ In other words, the parsing logic for members is too aggressive - we shouldn't call isRecordStart() in there. If this is not fixed in this round, we should keep track with a JBS issue. * Are the changes in Tokens really needed? * Check::checkUnique doesn't seem to use the added 'env' parameter - changes should be reverted * Names.jave - the logic for having forbiddenRecordComponentNames could use some refresh - in the latest spec we basically have to ban components that have same name as j.l.Object members - so I think we can implement the check more directly (e.g. w/o having a set of names). Also, the serialization names are not needed (although I guess they will come back at some point). And, not sure what "get" and "set" are needed for? Maurizio On 28/11/2019 16:05, Vicente Romero wrote: > Hi again, > > Sorry but I realized that I forgot to remove some code on the compiler > side. The code removed is small, before we were issuing an error if > some serialization methods were declared as record members. That > section was removed from the spec. I have prepared another iteration > with this change at [1] > > Thanks, > Vicente > > [1] > http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.01/ > > On 11/27/19 11:37 PM, Vicente Romero wrote: >> Hi, >> >> Please review the code for the records feature at [1]. This webrev >> includes all: APIs, runtime, compiler, serialization, javadoc, and >> more! Must of the code has been reviewed but there have been some >> changes since reviewers saw it. Also this is the first time an >> integral webrev is sent out for review. Last changes on top of my >> mind since last review iterations: >> >> On the compiler implementation: >> - it has been adapted to the last version of the language spec [2], >> as a reference the JVM spec is at [3]. This implied some changes in >> determining if a user defined constructor is the canonical or not. >> Now if a constructor is override-equivalent to a signature derived >> from the record components, then it is considered the canonical >> constructor. And any canonical constructor should satisfy a set of >> restrictions, see section 8.10.4 Record Constructor Declarations of >> the specification. >> - It was also added a check to make sure that accessors are not generic. >> - And that the canonical constructor, if user defined, is not >> explicitly invoking any other constructor. >> - The list of forbidden record component names has also been updated. >> - new error messages have been added >> >> APIs: >> - there have been some API editing in java.lang.Record, >> java.lang.runtime.ObjectMethods and >> java.lang.reflect.RecordComponent, java.io.ObjectInputStream, >> javax.lang.model (some visitors were added) >> >> On the JVM implementation: >> - some logging capabilities have been added to classFileParser.cpp to >> provide the reason for which the Record attribute has been ignored >> >> Reflection: >> - there are several new changes to the implementation of >> java.lang.reflect.RecordComponent apart from the spec changes >> mentioned before. >> >> bug fixes in >> - compiler >> - serialization, >> - JVM, etc >> >> As a reference the last iteration of the previous reviews can be >> found at [4] under folders: compiler, hotspot_runtime, javadoc, >> reflection and serialization, >> >> TIA, >> Vicente >> >> [1] >> http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.00/ >> [2] >> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html >> [3] >> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html >> [4] http://cr.openjdk.java.net/~vromero/records.review/ >> > From igor.ignatyev at oracle.com Thu Nov 28 18:47:57 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 28 Nov 2019 10:47:57 -0800 Subject: RFR: 8234964: failure_handler: gather more environment information on Windows, Solaris and Linux In-Reply-To: References: Message-ID: <9EDBFD2B-226D-40DC-96E5-BD41F4976747@oracle.com> Hi Julia, looks good to me. to make it more consistent w/ other tools, I'd move all ifconfig (incl. one on macOS) to 'net' category, i.e. rename them to net.ifconfig, this will require also moving all netstat.* on macOS and solaris to 'net' as well. I don't insist on it, though. -- Igor > On Nov 28, 2019, at 10:15 AM, Julia Boes wrote: > > Hi, > > In the case of test failure, the environment information of 'ifconfig -a' is already gathered on macOS systems. > > The following enhancement allows the same information to be gathered on Linux, Solaris and Windows systems (in the latter case 'ipconfig /all'). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8234964 > > Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8234964/webrev.00/ > > Regards, > > Julia > From vyommani at gmail.com Fri Nov 29 03:53:39 2019 From: vyommani at gmail.com (Vyom Tiwari) Date: Fri, 29 Nov 2019 09:23:39 +0530 Subject: RFR: 8234964: failure_handler: gather more environment information on Windows, Solaris and Linux In-Reply-To: <9EDBFD2B-226D-40DC-96E5-BD41F4976747@oracle.com> References: <9EDBFD2B-226D-40DC-96E5-BD41F4976747@oracle.com> Message-ID: Hi Julia, Changes looks OK to me although i have one question, in case of Solaris you use explicit path to ifconfig(ifconfig.app=/sbin/ifconfig). Does Solaris by default doesn't set the /sbin folder to user's 'PATH' environment variable ?. Thanks, Vyom On Fri, Nov 29, 2019 at 12:18 AM Igor Ignatyev wrote: > Hi Julia, > > looks good to me. > > to make it more consistent w/ other tools, I'd move all ifconfig (incl. > one on macOS) to 'net' category, i.e. rename them to net.ifconfig, this > will require also moving all netstat.* on macOS and solaris to 'net' as > well. I don't insist on it, though. > > -- Igor > > > On Nov 28, 2019, at 10:15 AM, Julia Boes wrote: > > > > Hi, > > > > In the case of test failure, the environment information of 'ifconfig > -a' is already gathered on macOS systems. > > > > The following enhancement allows the same information to be gathered on > Linux, Solaris and Windows systems (in the latter case 'ipconfig /all'). > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8234964 > > > > Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8234964/webrev.00/ > > > > Regards, > > > > Julia > > > > -- Thanks, Vyom From sgehwolf at redhat.com Fri Nov 29 09:05:01 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 29 Nov 2019 10:05:01 +0100 Subject: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so as to recognize unified hierarchy In-Reply-To: <75fc377f8d5ca76b7dac02f55db640cbdd305633.camel@redhat.com> References: <75fc377f8d5ca76b7dac02f55db640cbdd305633.camel@redhat.com> Message-ID: <4bf65380bc26cd3bf684d7994b33e66bcb87927b.camel@redhat.com> On Fri, 2019-11-15 at 17:51 +0100, Severin Gehwolf wrote: > Hi, > > Could I please get reviews of these core-libs, Linux-only, changes to > the Metrics subsystem? This patch implements cgroupv2 support for > Metrics which are currently cgroupv1-only. Fedora 31 switched to > cgroupv2 by default so it's time to get OpenJDK recognize it. > > Note that a couple of metrics are no longer supported with cgroupv2. > Most notably (not an exhaustive list, though): > > Metrics.getKernel*() family of methods. > Metrics.getTcp*() family of methods. > Metrics.getBlkIO*() family of methods. > Metrics.isMemoryOOMKillEnabled() > > A couple of open questions with regards to that: > > 1) > Most API docs of Metrics make no distiction between "unlimited" and > "not supported", both returning -1 for longs, for example. This is a > problem, because output of "java -XshowSettings:system -version" will > not distinguish between unlimited and not supported metrics. Would it > be acceptable to change the API to distinguish those cases so that > LauncherHelper could display them appropriately? > > 2) > How should we deal with "not supported" for booleans/arrays, etc.? > Would it make sense to return record objects from the Metrics API so > that this could be dealt with? E.g. > > Metrics m = ... > MetricResult result = m.getCpuSetCpus(); > switch(result.getType()) { > case NOT_SUPPORTED: /* do something */; break; > case SUPPORTED: int[] val = result.get(); break; > ... > } > > I'm bringing this up, because the proposed patch doesn't deal with the > above open questions as of yet. With that being said, it's mostly > identical to the proposed hotspot changes in [1]. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231111 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/ > > Testing: jdk/submit and platform docker tests on Linux x86_64 (with > hybrid hierarchy, docker/podman) and on Linux x86_64 with unified > hierarchy (podman only). > > Thoughts? Suggestions? Ping? > Thanks, > Severin > > [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-November/039909.html From matthias.baesken at sap.com Fri Nov 29 10:13:54 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 29 Nov 2019 10:13:54 +0000 Subject: RFR: 8234821: remove unused functions from libjli In-Reply-To: References: Message-ID: Thanks for the reviews . jdk-submit is fine so there should be no issues . Best regards, Matthias > -----Original Message----- > From: Alan Bateman > Sent: Donnerstag, 28. November 2019 13:33 > To: Baesken, Matthias ; Langer, Christoph > ; core-libs-dev at openjdk.java.net > Subject: Re: RFR: 8234821: remove unused functions from libjli > > On 28/11/2019 12:02, Baesken, Matthias wrote: > > Thanks for the review . I'll adjust the COPYRIGHT . > > > > Will push this as XS in case of no objections. > > > I think this look okay. I assume you'll send a job through jdk-submit in > case there are any residual launcher or installer code that also need to > be fixed. > > -Alan From raffaello.giulietti at gmail.com Fri Nov 29 12:07:01 2019 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Fri, 29 Nov 2019 13:07:01 +0100 Subject: GENTLE REMINDER of RFR CSR JDK-8202555: Double.toString(double) sometimes produces incorrect results In-Reply-To: <422629ce-e60e-1f81-2203-7dfc43384f8f@gmail.com> References: <9b15b269-1029-d07f-fe47-6b0cb5979e04@gmail.com> <422629ce-e60e-1f81-2203-7dfc43384f8f@gmail.com> Message-ID: <3b46ffe6-0529-ceed-60bd-f6a11eb0ef9c@gmail.com> Yet another monthly reminder. The December rampdown is approaching... Greetings Raffaello On 2019-10-29 20:33, Raffaello Giulietti wrote: > Since nothing seems to have moved, here's the familiar monthly reminder ;-) > > Greetings > Raffaello > > > > > On 2019-08-30 10:47, Raffaello Giulietti wrote: >> Hi, >> >> just a gentle reminder for a RFR of [1] (see [5] for the original >> request). >> >> An efficient implementation can be found on [2] and in Brian >> Burkhalter's webrev area [3]. This also requires a review. The full >> details are discussed in [4]. >> >> >> Greetings >> Raffaello >> >> ---- >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8202555 >> [2] >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-April/059783.html >> >> [3] http://cr.openjdk.java.net/~bpb/4511638/webrev.03/ >> [4] https://drive.google.com/open?id=1KLtG_LaIbK9ETXI290zqCxvBW94dj058 >> [5] >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-July/061548.html >> From david.lloyd at redhat.com Fri Nov 29 12:24:47 2019 From: david.lloyd at redhat.com (David Lloyd) Date: Fri, 29 Nov 2019 06:24:47 -0600 Subject: New candidate JEP: 370: Foreign-Memory Access API In-Reply-To: <1e88cab1-a6c7-454b-6cc5-6747c67a80cb@oracle.com> References: <20191125172756.29B2330F46E@eggemoggin.niobe.net> <34b5594d-0a56-c7fb-0906-c585121d6284@oracle.com> <1e88cab1-a6c7-454b-6cc5-6747c67a80cb@oracle.com> Message-ID: On Thu, Nov 28, 2019 at 11:24 AM Vladimir Ivanov wrote: > > > >> Second, what about an API to allocate memory from the stack? This is > >> really useful in GraalVM (granted they have a sort-of-Panama-ish way > >> of calling C functions already, and they're really quite "loose" when > >> it comes to safety in some regards) and could simplify some things > >> already, particularly if the pointer could then be passed to a JNI > >> method. Given the sensitive nature of stack allocation you'd probably > >> have to add some extra checks (like checking that the thread matches > >> on each access and that it is in scope, and you'd probably have to do > >> the latter via callback like StackWalker does) but it would be pretty > >> useful nonetheless. > > > > I guess it depends on what the goal is here - if the goal is to 'speed > > up allocation', there are other ways to skin that cat (and we're > > actually working on what seems like a very promising direction which we > > should be able to communicate more publicly soon). But, another related > > goal would be to be able to express stack allocation in Java directly, > > so that some of the work for e.g. writing bridge code which goes from > > Java to native can be expressed in Java directly. While something like > > this would probably be useful, as an implementation tool (e.g. to > > implement our own programmable invoker [2]), I don't see that being a > > priority from a public API perspective (assuming we can make allocation > > fast enough - that is!). > > Yes, stack allocation looks attractive, but in practice its usability is > quite limited. (IMO thread-local arena-style memory allocator is more > practical.) And it makes some assumptions about how threads and stacks > work which are aren't specified by JVMS, but are implementation details. > For example, how will it interact with Project Loom? > > Leaving high-level considerations aside, there's already a way to build > stack allocator without any JVM assistance on top of JNI (though > definitely not the most efficient and performant one): > > - do a native call; > - allocate memory on stack inside native frame; > - do an upcall to user-provided callback and pass a pointer to > allocated memory; > > On Java level it can be exposed as: > > native R allocateOnStack(long size, LongFunction task); > > What Memory Access API can add to it is safety: instead of passing raw > pointer to stack memory with all safety concerns associated with it, it > can be wrapped into a MemorySegment before returning it to the user and > on a way back closed, thus effectively forbidding any illegal accesses > (both temporal and spatial) and in completely transparent way: > > R withSegmentOnStack(long size, Function task); > > As a performance optimization, JIT can then intrinsify the native method > and directly allocate memory on stack without the need for auxiliary > native frame. It'll provide alloca-like behavior while considerably > simplifying JVM support. That's exactly what I'm looking for: safety plus speed, for the primary purpose of native invocation. As a bonus, having the memory access API provide this capability could mean that it could, on the back end, do something other than strictly stack-based allocation (e.g. allocating from a TLAB for larger objects). > It definitely looks very interesting in the context of low-level ABI and > native invokers, but IMO stack allocation is not a prerequisite for > Memory Access API and the API shouldn't wait for it to be released. > > After there's more data available from ABI experiments, we'll be in a > better position to decide how to proceed (either add it to Memory Access > API, build a separate API on top, or even drop it). Makes sense, it's still early. But now the seed is planted. :) -- - DML From joe.darcy at oracle.com Fri Nov 29 14:59:00 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 29 Nov 2019 06:59:00 -0800 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: <32b8c703-523f-ae83-291d-4f1b28fa1d91@oracle.com> References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> <32b8c703-523f-ae83-291d-4f1b28fa1d91@oracle.com> Message-ID: <04ab170a-72a3-81e0-c38b-79b9a2533cd1@oracle.com> Hi Vicente, Please change all uses of ??? @compile --enable-preview -source 14 in jtreg tags to to ??? @compile --enable-preview -source ${jdk.version} The former structure will spuriously fail when the JDK 14 -> 15 transition occurs. Also, publishing delta-webrevs between iterations in additional to full webrev would help track the incremental changes. Thanks, -Joe On 11/28/2019 8:05 AM, Vicente Romero wrote: > Hi again, > > Sorry but I realized that I forgot to remove some code on the compiler > side. The code removed is small, before we were issuing an error if > some serialization methods were declared as record members. That > section was removed from the spec. I have prepared another iteration > with this change at [1] > > Thanks, > Vicente > > [1] > http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.01/ > > On 11/27/19 11:37 PM, Vicente Romero wrote: >> Hi, >> >> Please review the code for the records feature at [1]. This webrev >> includes all: APIs, runtime, compiler, serialization, javadoc, and >> more! Must of the code has been reviewed but there have been some >> changes since reviewers saw it. Also this is the first time an >> integral webrev is sent out for review. Last changes on top of my >> mind since last review iterations: >> >> On the compiler implementation: >> - it has been adapted to the last version of the language spec [2], >> as a reference the JVM spec is at [3]. This implied some changes in >> determining if a user defined constructor is the canonical or not. >> Now if a constructor is override-equivalent to a signature derived >> from the record components, then it is considered the canonical >> constructor. And any canonical constructor should satisfy a set of >> restrictions, see section 8.10.4 Record Constructor Declarations of >> the specification. >> - It was also added a check to make sure that accessors are not generic. >> - And that the canonical constructor, if user defined, is not >> explicitly invoking any other constructor. >> - The list of forbidden record component names has also been updated. >> - new error messages have been added >> >> APIs: >> - there have been some API editing in java.lang.Record, >> java.lang.runtime.ObjectMethods and >> java.lang.reflect.RecordComponent, java.io.ObjectInputStream, >> javax.lang.model (some visitors were added) >> >> On the JVM implementation: >> - some logging capabilities have been added to classFileParser.cpp to >> provide the reason for which the Record attribute has been ignored >> >> Reflection: >> - there are several new changes to the implementation of >> java.lang.reflect.RecordComponent apart from the spec changes >> mentioned before. >> >> bug fixes in >> - compiler >> - serialization, >> - JVM, etc >> >> As a reference the last iteration of the previous reviews can be >> found at [4] under folders: compiler, hotspot_runtime, javadoc, >> reflection and serialization, >> >> TIA, >> Vicente >> >> [1] >> http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.00/ >> [2] >> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html >> [3] >> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html >> [4] http://cr.openjdk.java.net/~vromero/records.review/ >> > From vladimir.x.ivanov at oracle.com Fri Nov 29 15:55:43 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 29 Nov 2019 18:55:43 +0300 Subject: [14] RFR (S): 8234923: Missed call_site_target nmethod dependency for non-fully initialized ConstantCallSite instance Message-ID: <7d4c2ab1-f8ec-8ccc-a442-8401a048b353@oracle.com> http://cr.openjdk.java.net/~vlivanov/8234923/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8234923 The fix for 8234401 is incomplete: though it does notify the JVM about call site target update (by calling setTargetNormal [2]), on JVM side JITs skip nmethod dependencies for ConstantCallSites irrespective of whether they are fully initialized or not. So, affected nmethods aren't invalidated. The fix is to make JITs aware about initialization status of ConstantCallSite instance by inspecting its isFrozen field and register proper nmethod dependency if a CallSite is being initialized. Testing: tier1-6 Best regards, Vladimir Ivanov [1] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-November/036019.html [2] https://hg.openjdk.java.net/jdk/jdk/rev/a6e25566cb56#l1.26 From jan.lahoda at oracle.com Fri Nov 29 16:30:57 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 29 Nov 2019 17:30:57 +0100 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> Message-ID: Hi Vcente, Overall, looks fine I think. A few comments on the javac implementation: -in TypeEnter, I believe this: memberEnter.memberEnter(tree.defs.diff(List.convert(JCTree.class, defsBeforeAddingNewMembers)), env); is unnecessary (and fairly slow). defsBeforeAddingNewMembers is initialized to tree.defs a few lines above, and I don't think tree.defs is modified between the point defsBeforeAddingNewMembers and this line. I.e. the diff will be empty, but very slow to compute (basically n^2, unless I am mistaken). Not having this line would also help in not changing: test/langtools/tools/javac/importscope/T8193717.java (If the tree.defs would be changed, I would suggest to keep track of which members were added, and avoid the List.diff - tree.defs can contain a lot of elements, and the diff is fairly slow.) -in test/langtools/tools/javac/expswitch/ExpSwitchNestingTest.java, the --enable-preview should no longer be needed -Flags.COMPACT_RECORD_CONSTRUCTOR says it is only for MethodSymbols, but is also for VarSymbols. Either the comment should be adjusted, or (possibly better), there could be a different/new flag for the fields. (That new flag can reuse the same bit position as COMPACT_RECORD_CONSTRUCTOR, of course.) -nits: --Lower.generateMandatedAccessors: could be rewritten using filter() to avoid having an if in the forEach, or changed even more by using filter-map-collect (and avoid having a manual ListBuffer). For your consideration --AttrContext.java: no need to move the isLambda initialization, correct? (i.e. the actual change is adding isSerializableLambda, but the diff says isLambda is removed and added on a different place). --in src/jdk.compiler/share/classes/com/sun/source/doctree/DocTree.java and src/jdk.compiler/share/classes/com/sun/source/util/DocTreeFactory.java, there are no changes except for a change in the copyright years - these could be presumably stripped. --there is a TODO in: src/java.compiler/share/classes/javax/lang/model/SourceVersion.java presumably, this could be resolved based on the current spec? Jan On 28. 11. 19 5:37, Vicente Romero wrote: > Hi, > > Please review the code for the records feature at [1]. This webrev > includes all: APIs, runtime, compiler, serialization, javadoc, and more! > Must of the code has been reviewed but there have been some changes > since reviewers saw it. Also this is the first time an integral webrev > is sent out for review. Last changes on top of my mind since last review > iterations: > > On the compiler implementation: > - it has been adapted to the last version of the language spec [2], as a > reference the JVM spec is at [3]. This implied some changes in > determining if a user defined constructor is the canonical or not. Now > if a constructor is override-equivalent to a signature derived from the > record components, then it is considered the canonical constructor. And > any canonical constructor should satisfy a set of restrictions, see > section 8.10.4 Record Constructor Declarations of the specification. > - It was also added a check to make sure that accessors are not generic. > - And that the canonical constructor, if user defined, is not explicitly > invoking any other constructor. > - The list of forbidden record component names has also been updated. > - new error messages have been added > > APIs: > - there have been some API editing in java.lang.Record, > java.lang.runtime.ObjectMethods and java.lang.reflect.RecordComponent, > java.io.ObjectInputStream, javax.lang.model (some visitors were added) > > On the JVM implementation: > - some logging capabilities have been added to classFileParser.cpp to > provide the reason for which the Record attribute has been ignored > > Reflection: > - there are several new changes to the implementation of > java.lang.reflect.RecordComponent apart from the spec changes mentioned > before. > > bug fixes in > - compiler > - serialization, > - JVM, etc > > As a reference the last iteration of the previous reviews can be found > at [4] under folders: compiler, hotspot_runtime, javadoc, reflection and > serialization, > > TIA, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.00/ > [2] > http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html > > [3] > http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html > > [4] http://cr.openjdk.java.net/~vromero/records.review/ > From fw at deneb.enyo.de Fri Nov 29 19:32:09 2019 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 29 Nov 2019 20:32:09 +0100 Subject: New candidate JEP: 370: Foreign-Memory Access API In-Reply-To: (Maurizio Cimadamore's message of "Mon, 25 Nov 2019 21:09:03 +0000") References: <20191125172756.29B2330F46E@eggemoggin.niobe.net> Message-ID: <87o8wu8ona.fsf@mid.deneb.enyo.de> * Maurizio Cimadamore: > While this could be done (and it was considered early during the design > phase), we decided against it for two reasons: first, the VarHandle API > is very expressive and already supports. atomic compareAndSwap? > operations out of the box, which are _very_ handy when dealing with > shared memory segments. If we had to add all the methods from the > VarHandle API, multiplied by _each_ possible carrier type, the API > footprint would quickly balloon up. I think some of the atomic operations for VarHandles are currently specified in such a way that they are only implementable within one JVM on certain architectures because some separate lock is needed, or there is no suitable non-writing atomic load. I expect that the foreign-memory access API is also intended for process-shared mappings or read-only mappings, and supporting those scenarios on such architectures will need kernel assists. On the other hand, it doesn't look like any of the current OpenJDK ports suffer from this problem. From maurizio.cimadamore at oracle.com Fri Nov 29 21:07:56 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 29 Nov 2019 21:07:56 +0000 Subject: New candidate JEP: 370: Foreign-Memory Access API In-Reply-To: <87o8wu8ona.fsf@mid.deneb.enyo.de> References: <20191125172756.29B2330F46E@eggemoggin.niobe.net> <87o8wu8ona.fsf@mid.deneb.enyo.de> Message-ID: <13123b60-60e9-3097-fb33-351310e2600f@oracle.com> On 29/11/2019 19:32, Florian Weimer wrote: > * Maurizio Cimadamore: > >> While this could be done (and it was considered early during the design >> phase), we decided against it for two reasons: first, the VarHandle API >> is very expressive and already supports. atomic compareAndSwap >> operations out of the box, which are _very_ handy when dealing with >> shared memory segments. If we had to add all the methods from the >> VarHandle API, multiplied by _each_ possible carrier type, the API >> footprint would quickly balloon up. > I think some of the atomic operations for VarHandles are currently > specified in such a way that they are only implementable within one > JVM on certain architectures because some separate lock is needed, or > there is no suitable non-writing atomic load. > > I expect that the foreign-memory access API is also intended for > process-shared mappings or read-only mappings, and supporting those > scenarios on such architectures will need kernel assists. I was discussing on a similar note with Paul Sandoz - and we agreed that, moving forward - it will be likely for a memory segment to have a bunch of flags (probably a characteristics() bit mask), which might contain OS/platform related details for when a native segment is created; e.g. are write operation supported at all? Is unaligned access supported? Does a segment needs writeback? Right now the API is relatively minimal, but I suspect that if we play with it a bit we will discover a bunch of properties like these which might sense to make available, and allow clients to query them. Maurizio > > On the other hand, it doesn't look like any of the current OpenJDK > ports suffer from this problem. From vicente.romero at oracle.com Fri Nov 29 23:12:30 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 29 Nov 2019 18:12:30 -0500 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: <04ab170a-72a3-81e0-c38b-79b9a2533cd1@oracle.com> References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> <32b8c703-523f-ae83-291d-4f1b28fa1d91@oracle.com> <04ab170a-72a3-81e0-c38b-79b9a2533cd1@oracle.com> Message-ID: <3805c12d-d476-0f09-3344-a0f7e215c34b@oracle.com> Hi Joe, All the tests that have an explicit -source 14 are that way because of, I think to remember, a bug in jtreg that doesn't expand the ${some.property} macro for those tests. I don't remember the details though Thanks, Vicente On 11/29/19 9:59 AM, Joe Darcy wrote: > Hi Vicente, > > Please change all uses of > > ??? @compile --enable-preview -source 14 > > in jtreg tags to to > > ??? @compile --enable-preview -source ${jdk.version} > > The former structure will spuriously fail when the JDK 14 -> 15 > transition occurs. > > Also, publishing delta-webrevs between iterations in additional to > full webrev would help track the incremental changes. > > Thanks, > > -Joe > > On 11/28/2019 8:05 AM, Vicente Romero wrote: >> Hi again, >> >> Sorry but I realized that I forgot to remove some code on the >> compiler side. The code removed is small, before we were issuing an >> error if some serialization methods were declared as record members. >> That section was removed from the spec. I have prepared another >> iteration with this change at [1] >> >> Thanks, >> Vicente >> >> [1] >> http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.01/ >> >> On 11/27/19 11:37 PM, Vicente Romero wrote: >>> Hi, >>> >>> Please review the code for the records feature at [1]. This webrev >>> includes all: APIs, runtime, compiler, serialization, javadoc, and >>> more! Must of the code has been reviewed but there have been some >>> changes since reviewers saw it. Also this is the first time an >>> integral webrev is sent out for review. Last changes on top of my >>> mind since last review iterations: >>> >>> On the compiler implementation: >>> - it has been adapted to the last version of the language spec [2], >>> as a reference the JVM spec is at [3]. This implied some changes in >>> determining if a user defined constructor is the canonical or not. >>> Now if a constructor is override-equivalent to a signature derived >>> from the record components, then it is considered the canonical >>> constructor. And any canonical constructor should satisfy a set of >>> restrictions, see section 8.10.4 Record Constructor Declarations of >>> the specification. >>> - It was also added a check to make sure that accessors are not >>> generic. >>> - And that the canonical constructor, if user defined, is not >>> explicitly invoking any other constructor. >>> - The list of forbidden record component names has also been updated. >>> - new error messages have been added >>> >>> APIs: >>> - there have been some API editing in java.lang.Record, >>> java.lang.runtime.ObjectMethods and >>> java.lang.reflect.RecordComponent, java.io.ObjectInputStream, >>> javax.lang.model (some visitors were added) >>> >>> On the JVM implementation: >>> - some logging capabilities have been added to classFileParser.cpp >>> to provide the reason for which the Record attribute has been ignored >>> >>> Reflection: >>> - there are several new changes to the implementation of >>> java.lang.reflect.RecordComponent apart from the spec changes >>> mentioned before. >>> >>> bug fixes in >>> - compiler >>> - serialization, >>> - JVM, etc >>> >>> As a reference the last iteration of the previous reviews can be >>> found at [4] under folders: compiler, hotspot_runtime, javadoc, >>> reflection and serialization, >>> >>> TIA, >>> Vicente >>> >>> [1] >>> http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.00/ >>> [2] >>> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html >>> [3] >>> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html >>> [4] http://cr.openjdk.java.net/~vromero/records.review/ >>> >> From john.r.rose at oracle.com Fri Nov 29 23:30:42 2019 From: john.r.rose at oracle.com (John Rose) Date: Fri, 29 Nov 2019 15:30:42 -0800 Subject: [14] RFR (S): 8234923: Missed call_site_target nmethod dependency for non-fully initialized ConstantCallSite instance In-Reply-To: <7d4c2ab1-f8ec-8ccc-a442-8401a048b353@oracle.com> References: <7d4c2ab1-f8ec-8ccc-a442-8401a048b353@oracle.com> Message-ID: Reviewed. > On Nov 29, 2019, at 7:55 AM, Vladimir Ivanov wrote: > > http://cr.openjdk.java.net/~vlivanov/8234923/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8234923 From john.r.rose at oracle.com Fri Nov 29 23:34:11 2019 From: john.r.rose at oracle.com (John Rose) Date: Fri, 29 Nov 2019 15:34:11 -0800 Subject: New candidate JEP: 370: Foreign-Memory Access API In-Reply-To: References: <20191125172756.29B2330F46E@eggemoggin.niobe.net> <34b5594d-0a56-c7fb-0906-c585121d6284@oracle.com> <1e88cab1-a6c7-454b-6cc5-6747c67a80cb@oracle.com> Message-ID: <45C77E27-AA9A-4E81-858C-6AE52B3F65BF@oracle.com> On Nov 29, 2019, at 4:24 AM, David Lloyd wrote: > > Makes sense, it's still early. But now the seed is planted. :) (It?s better documented. Most of the points made here were not new.) From vicente.romero at oracle.com Sat Nov 30 18:29:23 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Sat, 30 Nov 2019 13:29:23 -0500 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> <32b8c703-523f-ae83-291d-4f1b28fa1d91@oracle.com> Message-ID: <5cc9da98-3dae-b6c6-7acb-c9a4c3484a3b@oracle.com> Hi, I have created another iteration at [1], this is just a delta from last iteration [2]. Some comments below [1] http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.01_delta.01/ [2] http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.01 On 11/28/19 1:35 PM, Maurizio Cimadamore wrote: > > Hi Vicente, > generally looks good - few comments below; I tried to focus on areas > where the compiler code seemed to diverge from the spec, as well on > pieces of code which look a leftover from previous spec rounds. > > * canonical constructors *can* have return statements - compact > constructors cant; the spec went a bit back and forth on this, but now > it has settled. Since compact constructors are turned into ordinary > canonical ones by the parser, I think you need to add an extra check > for COMPACT_RECORD_CONSTRUCTOR; in other words, this is ok: > > record Foo() { > ?? Foo() { return; } //canonical > } > > this isn't > > record Foo() { > ?? Foo { return; } //compact > } > > but the compiler rejects both. This probably means tweaking the > diagnostic a bit to say "a compact constructor must not contain > |return| statements" > yes I have modified the code so that the error messages can show "canonical" or "compact" depending on the case > * in general, all diagnostics speak about 'canonical constructor' > regardless of whether the constructor is canonical of compact; while I > understand the reason behind what we get now, some of the error > messages can be confusing, especially if you look at the spec, where > canonical constructor and compact constructor are two different > concepts. This should be fixed (even if not immediately, in which case > I'd recommend to file a JBS issue to track that) > > * static accessors are allowed - this means that I can do this: > > record Foo(int x) { > public static int x() {return 0; } > > public static void main(String[] args) { > ?? System.err.println(new Foo(42).x()); > } > } > > This will compile and print 0. The classfile will contain the > following members: > > final class Foo extends java.lang.Record { > ? public Foo(int); > ? public static int x(); > ? public static void main(java.lang.String[]); > ? public java.lang.String toString(); > ? public final int hashCode(); > ? public final boolean equals(java.lang.Object); > } > > I believe this is an issue in the compiler, but also in the latest > spec draft, if I'm not mistaken. > yes this is a bug, we are considering updating both the spec and the compiler. I will submit another iteration as soon as this change is reflected in both > * [optional - style] the env.info.isSerializableLambda could become an > enum { NONE, LAMBDA, SERIALIZABLE_LAMBDA } instead of two boolean > parameters > will do that later, I remember that there were some interactions between these flags, they are not exclusive > > * this code is still rejected with --enable-preview _disabled_: > > class X { > ??? record R(int i) { > ??????? return null; > ??? } > } > class record {} > > This gives the error: > > Error: > |? records are a preview feature and are disabled by default. > |??? (use --enable-preview to enable records) > |? record R(int i) { return null } } > |? ^ > |? Error: > |? illegal start of type > |? record R(int i) { return null } } > |??????????????????? ^ > > In other words, the parsing logic for members is too aggressive - we > shouldn't call isRecordStart() in there. If this is not fixed in this > round, we should keep track with a JBS issue. > I have created a follow up issue: https://bugs.openjdk.java.net/browse/JDK-8235149 > * Are the changes in Tokens really needed? > no removed > > * Check::checkUnique doesn't seem to use the added 'env' parameter - > changes should be reverted > yep done > > * Names.jave - the logic for having forbiddenRecordComponentNames > could use some refresh - in the latest spec we basically have to ban > components that have same name as j.l.Object members - so I think we > can implement the check more directly (e.g. w/o having a set of names). > right done, I have created a method that check if a record component name matches with a parameterless method in Object > Also, the serialization names are not needed (although I guess they > will come back at some point). > yes they will, I can remove them now but I guess we will need them once we implement a lint warning > And, not sure what "get" and "set" are needed for? > removed > > > Maurizio > thanks, Vicente > > On 28/11/2019 16:05, Vicente Romero wrote: >> Hi again, >> >> Sorry but I realized that I forgot to remove some code on the >> compiler side. The code removed is small, before we were issuing an >> error if some serialization methods were declared as record members. >> That section was removed from the spec. I have prepared another >> iteration with this change at [1] >> >> Thanks, >> Vicente >> >> [1] >> http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.01/ >> >> On 11/27/19 11:37 PM, Vicente Romero wrote: >>> Hi, >>> >>> Please review the code for the records feature at [1]. This webrev >>> includes all: APIs, runtime, compiler, serialization, javadoc, and >>> more! Must of the code has been reviewed but there have been some >>> changes since reviewers saw it. Also this is the first time an >>> integral webrev is sent out for review. Last changes on top of my >>> mind since last review iterations: >>> >>> On the compiler implementation: >>> - it has been adapted to the last version of the language spec [2], >>> as a reference the JVM spec is at [3]. This implied some changes in >>> determining if a user defined constructor is the canonical or not. >>> Now if a constructor is override-equivalent to a signature derived >>> from the record components, then it is considered the canonical >>> constructor. And any canonical constructor should satisfy a set of >>> restrictions, see section 8.10.4 Record Constructor Declarations of >>> the specification. >>> - It was also added a check to make sure that accessors are not >>> generic. >>> - And that the canonical constructor, if user defined, is not >>> explicitly invoking any other constructor. >>> - The list of forbidden record component names has also been updated. >>> - new error messages have been added >>> >>> APIs: >>> - there have been some API editing in java.lang.Record, >>> java.lang.runtime.ObjectMethods and >>> java.lang.reflect.RecordComponent, java.io.ObjectInputStream, >>> javax.lang.model (some visitors were added) >>> >>> On the JVM implementation: >>> - some logging capabilities have been added to classFileParser.cpp >>> to provide the reason for which the Record attribute has been ignored >>> >>> Reflection: >>> - there are several new changes to the implementation of >>> java.lang.reflect.RecordComponent apart from the spec changes >>> mentioned before. >>> >>> bug fixes in >>> - compiler >>> - serialization, >>> - JVM, etc >>> >>> As a reference the last iteration of the previous reviews can be >>> found at [4] under folders: compiler, hotspot_runtime, javadoc, >>> reflection and serialization, >>> >>> TIA, >>> Vicente >>> >>> [1] >>> http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.00/ >>> [2] >>> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html >>> [3] >>> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html >>> [4] http://cr.openjdk.java.net/~vromero/records.review/ >>> >> From vicente.romero at oracle.com Sat Nov 30 18:31:57 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Sat, 30 Nov 2019 13:31:57 -0500 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> Message-ID: Hi Jan, I have addressed your comments on delta iteration [1] [1] http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.01_delta.01/ some comments below. On 11/29/19 11:30 AM, Jan Lahoda wrote: > Hi Vcente, > > Overall, looks fine I think. A few comments on the javac implementation: > -in TypeEnter, I believe this: > memberEnter.memberEnter(tree.defs.diff(List.convert(JCTree.class, > defsBeforeAddingNewMembers)), env); > is unnecessary yep removed > (and fairly slow). defsBeforeAddingNewMembers is initialized to > tree.defs a few lines above, and I don't think tree.defs is modified > between the point defsBeforeAddingNewMembers and this line. I.e. the > diff will be empty, but very slow to compute (basically n^2, unless I > am mistaken). Not having this line would also help in not changing: > test/langtools/tools/javac/importscope/T8193717.java > (If the tree.defs would be changed, I would suggest to keep track of > which members were added, and avoid the List.diff - tree.defs can > contain a lot of elements, and the diff is fairly slow.) > > -in test/langtools/tools/javac/expswitch/ExpSwitchNestingTest.java, > the --enable-preview should no longer be needed done > > -Flags.COMPACT_RECORD_CONSTRUCTOR says it is only for MethodSymbols, > but is also for VarSymbols. Either the comment should be adjusted, or > (possibly better), there could be a different/new flag for the fields. > (That new flag can reuse the same bit position as > COMPACT_RECORD_CONSTRUCTOR, of course.) done > > -nits: > --Lower.generateMandatedAccessors: could be rewritten using filter() > to avoid having an if in the forEach, or changed even more by using > filter-map-collect (and avoid having a manual ListBuffer). For your > consideration yep done > --AttrContext.java: no need to move the isLambda initialization, > correct? (i.e. the actual change is adding isSerializableLambda, but > the diff says isLambda is removed and added on a different place). done > --in > src/jdk.compiler/share/classes/com/sun/source/doctree/DocTree.java and > src/jdk.compiler/share/classes/com/sun/source/util/DocTreeFactory.java, > there are no changes except for a change in the copyright years - > these could be presumably stripped. yep done > --there is a TODO in: > src/java.compiler/share/classes/javax/lang/model/SourceVersion.java > presumably, this could be resolved based on the current spec? I think that this comment doesn't apply as there is no need for any additional change. I have removed it > > Jan Thanks, Vicente > > On 28. 11. 19 5:37, Vicente Romero wrote: >> Hi, >> >> Please review the code for the records feature at [1]. This webrev >> includes all: APIs, runtime, compiler, serialization, javadoc, and >> more! Must of the code has been reviewed but there have been some >> changes since reviewers saw it. Also this is the first time an >> integral webrev is sent out for review. Last changes on top of my >> mind since last review iterations: >> >> On the compiler implementation: >> - it has been adapted to the last version of the language spec [2], >> as a reference the JVM spec is at [3]. This implied some changes in >> determining if a user defined constructor is the canonical or not. >> Now if a constructor is override-equivalent to a signature derived >> from the record components, then it is considered the canonical >> constructor. And any canonical constructor should satisfy a set of >> restrictions, see section 8.10.4 Record Constructor Declarations of >> the specification. >> - It was also added a check to make sure that accessors are not generic. >> - And that the canonical constructor, if user defined, is not >> explicitly invoking any other constructor. >> - The list of forbidden record component names has also been updated. >> - new error messages have been added >> >> APIs: >> - there have been some API editing in java.lang.Record, >> java.lang.runtime.ObjectMethods and >> java.lang.reflect.RecordComponent, java.io.ObjectInputStream, >> javax.lang.model (some visitors were added) >> >> On the JVM implementation: >> - some logging capabilities have been added to classFileParser.cpp to >> provide the reason for which the Record attribute has been ignored >> >> Reflection: >> - there are several new changes to the implementation of >> java.lang.reflect.RecordComponent apart from the spec changes >> mentioned before. >> >> bug fixes in >> - compiler >> - serialization, >> - JVM, etc >> >> As a reference the last iteration of the previous reviews can be >> found at [4] under folders: compiler, hotspot_runtime, javadoc, >> reflection and serialization, >> >> TIA, >> Vicente >> >> [1] >> http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.00/ >> [2] >> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html >> >> [3] >> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html >> >> [4] http://cr.openjdk.java.net/~vromero/records.review/ >> From Ulf.Zibis at CoSoCo.de Sat Nov 30 21:32:44 2019 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Sat, 30 Nov 2019 22:32:44 +0100 Subject: RFR 8234147 : Avoid looking up standard charsets in core libraries In-Reply-To: <8e010258-7a18-3165-1d11-7aa89b996aa4@oracle.com> References: <8e010258-7a18-3165-1d11-7aa89b996aa4@oracle.com> Message-ID: Hi Ivan, you may compare your proposal with: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6790402 https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6850361 https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6796087 -Ulf Am 27.11.19 um 05:39 schrieb Ivan Gerasimov: > Hello! > > It is a cleanup fix with mostly two kinds of changes: > - when a standard charset is specified by its name, use a > preinitialized Charset constant instead, > - replace the usage of StandardCharset.* constants with their > sun.nio.cs.* equivalents to avoid accidental early initialization of > rarely-used charsets. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8234147 > WEBREV: http://cr.openjdk.java.net/~igerasim/8234147/00/webrev/ > > I also had to modify one regression test that relied on a private > auxiliary method, which was removed with the fix. > > Mach5 control build looks green. > > Would you please help review the fix? > From maurizio.cimadamore at oracle.com Sat Nov 30 22:51:25 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Sat, 30 Nov 2019 22:51:25 +0000 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: <5cc9da98-3dae-b6c6-7acb-c9a4c3484a3b@oracle.com> References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> <32b8c703-523f-ae83-291d-4f1b28fa1d91@oracle.com> <5cc9da98-3dae-b6c6-7acb-c9a4c3484a3b@oracle.com> Message-ID: <1c81d93e-4fcc-68b5-7e1b-a6b8880a2964@oracle.com> Looks good - but you need diagnostic fragments for the "canonical", "compact" diagnostic bits (no need for re-review). Maurizio On 30/11/2019 18:29, Vicente Romero wrote: > Hi, > > I have created another iteration at [1], this is just a delta from > last iteration [2]. Some comments below > > [1] > http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.01_delta.01/ > [2] http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.01 > > On 11/28/19 1:35 PM, Maurizio Cimadamore wrote: >> >> Hi Vicente, >> generally looks good - few comments below; I tried to focus on areas >> where the compiler code seemed to diverge from the spec, as well on >> pieces of code which look a leftover from previous spec rounds. >> >> * canonical constructors *can* have return statements - compact >> constructors cant; the spec went a bit back and forth on this, but >> now it has settled. Since compact constructors are turned into >> ordinary canonical ones by the parser, I think you need to add an >> extra check for COMPACT_RECORD_CONSTRUCTOR; in other words, this is ok: >> >> record Foo() { >> ?? Foo() { return; } //canonical >> } >> >> this isn't >> >> record Foo() { >> ?? Foo { return; } //compact >> } >> >> but the compiler rejects both. This probably means tweaking the >> diagnostic a bit to say "a compact constructor must not contain >> |return| statements" >> > > yes I have modified the code so that the error messages can show > "canonical" or "compact" depending on the case > >> * in general, all diagnostics speak about 'canonical constructor' >> regardless of whether the constructor is canonical of compact; while >> I understand the reason behind what we get now, some of the error >> messages can be confusing, especially if you look at the spec, where >> canonical constructor and compact constructor are two different >> concepts. This should be fixed (even if not immediately, in which >> case I'd recommend to file a JBS issue to track that) >> >> * static accessors are allowed - this means that I can do this: >> >> record Foo(int x) { >> public static int x() {return 0; } >> >> public static void main(String[] args) { >> ?? System.err.println(new Foo(42).x()); >> } >> } >> >> This will compile and print 0. The classfile will contain the >> following members: >> >> final class Foo extends java.lang.Record { >> ? public Foo(int); >> ? public static int x(); >> ? public static void main(java.lang.String[]); >> ? public java.lang.String toString(); >> ? public final int hashCode(); >> ? public final boolean equals(java.lang.Object); >> } >> >> I believe this is an issue in the compiler, but also in the latest >> spec draft, if I'm not mistaken. >> > > yes this is a bug, we are considering updating both the spec and the > compiler. I will submit another iteration as soon as this change is > reflected in both > >> * [optional - style] the env.info.isSerializableLambda could become >> an enum { NONE, LAMBDA, SERIALIZABLE_LAMBDA } instead of two boolean >> parameters >> > > will do that later, I remember that there were some interactions > between these flags, they are not exclusive >> >> * this code is still rejected with --enable-preview _disabled_: >> >> class X { >> ??? record R(int i) { >> ??????? return null; >> ??? } >> } >> class record {} >> >> This gives the error: >> >> Error: >> |? records are a preview feature and are disabled by default. >> |??? (use --enable-preview to enable records) >> |? record R(int i) { return null } } >> |? ^ >> |? Error: >> |? illegal start of type >> |? record R(int i) { return null } } >> |??????????????????? ^ >> >> In other words, the parsing logic for members is too aggressive - we >> shouldn't call isRecordStart() in there. If this is not fixed in this >> round, we should keep track with a JBS issue. >> > > I have created a follow up issue: > https://bugs.openjdk.java.net/browse/JDK-8235149 > >> * Are the changes in Tokens really needed? >> > no removed >> >> * Check::checkUnique doesn't seem to use the added 'env' parameter - >> changes should be reverted >> > yep done >> >> * Names.jave - the logic for having forbiddenRecordComponentNames >> could use some refresh - in the latest spec we basically have to ban >> components that have same name as j.l.Object members - so I think we >> can implement the check more directly (e.g. w/o having a set of names). >> > > right done, I have created a method that check if a record component > name matches with a parameterless method in Object > >> Also, the serialization names are not needed (although I guess they >> will come back at some point). >> > > yes they will, I can remove them now but I guess we will need them > once we implement a lint warning > >> And, not sure what "get" and "set" are needed for? >> > > removed >> >> >> Maurizio >> > > thanks, > Vicente >> >> On 28/11/2019 16:05, Vicente Romero wrote: >>> Hi again, >>> >>> Sorry but I realized that I forgot to remove some code on the >>> compiler side. The code removed is small, before we were issuing an >>> error if some serialization methods were declared as record members. >>> That section was removed from the spec. I have prepared another >>> iteration with this change at [1] >>> >>> Thanks, >>> Vicente >>> >>> [1] >>> http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.01/ >>> >>> On 11/27/19 11:37 PM, Vicente Romero wrote: >>>> Hi, >>>> >>>> Please review the code for the records feature at [1]. This webrev >>>> includes all: APIs, runtime, compiler, serialization, javadoc, and >>>> more! Must of the code has been reviewed but there have been some >>>> changes since reviewers saw it. Also this is the first time an >>>> integral webrev is sent out for review. Last changes on top of my >>>> mind since last review iterations: >>>> >>>> On the compiler implementation: >>>> - it has been adapted to the last version of the language spec [2], >>>> as a reference the JVM spec is at [3]. This implied some changes in >>>> determining if a user defined constructor is the canonical or not. >>>> Now if a constructor is override-equivalent to a signature derived >>>> from the record components, then it is considered the canonical >>>> constructor. And any canonical constructor should satisfy a set of >>>> restrictions, see section 8.10.4 Record Constructor Declarations of >>>> the specification. >>>> - It was also added a check to make sure that accessors are not >>>> generic. >>>> - And that the canonical constructor, if user defined, is not >>>> explicitly invoking any other constructor. >>>> - The list of forbidden record component names has also been updated. >>>> - new error messages have been added >>>> >>>> APIs: >>>> - there have been some API editing in java.lang.Record, >>>> java.lang.runtime.ObjectMethods and >>>> java.lang.reflect.RecordComponent, java.io.ObjectInputStream, >>>> javax.lang.model (some visitors were added) >>>> >>>> On the JVM implementation: >>>> - some logging capabilities have been added to classFileParser.cpp >>>> to provide the reason for which the Record attribute has been ignored >>>> >>>> Reflection: >>>> - there are several new changes to the implementation of >>>> java.lang.reflect.RecordComponent apart from the spec changes >>>> mentioned before. >>>> >>>> bug fixes in >>>> - compiler >>>> - serialization, >>>> - JVM, etc >>>> >>>> As a reference the last iteration of the previous reviews can be >>>> found at [4] under folders: compiler, hotspot_runtime, javadoc, >>>> reflection and serialization, >>>> >>>> TIA, >>>> Vicente >>>> >>>> [1] >>>> http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.00/ >>>> [2] >>>> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html >>>> [3] >>>> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html >>>> [4] http://cr.openjdk.java.net/~vromero/records.review/ >>>> >>> >