From sverre.moe at gmail.com Mon Sep 2 11:14:32 2019 From: sverre.moe at gmail.com (Sverre Moe) Date: Mon, 2 Sep 2019 13:14:32 +0200 Subject: jdk-14-jpackage+1-33 on jdk.java.net In-Reply-To: References: Message-ID: I am having problem with arguments not being passed to the application. The fix JDK-8224486 in this EA release seems to have something to do with arguments, but it is actually just the JavaOptions. The options in ArgOptions in the jpackage cfg does not seem to be passed to the application [ArgOptions] --log-level=ALL This is not passed to the application. When I add it manually on the command line then it works. ./build/native/application/bin/application --log-level=ALL Is this a known bug with the jpackage? /Sverre tor. 22. aug. 2019 kl. 00:27 skrev Andy Herrick : > The next EA build of JPackage is available at > https://jdk.java.net/jpackage/ > > This build ( jdk-14-jpackage+1-33 ) (2019/8/20) is the next early access > release based on JDK-14 > > This release contains fixes to the following issues: > > JDK-8229788 Error dialog displays with DLL issue when installing > WinChooserTest application > JDK-8225447 Revise Debian packaging > JDK-8213941 Debian linux problems in JavaPackager > JDK-8229334 jpackage .exe packages cannot be executed due to missing > DLL > JDK-8227058 Regressions related to no longer setting user.dir > JDK-8226599 use code coverage results to remove dead code > JDK-8226191 jpackager --license-file option broken on windows for > jdk installers. > JDK-8215381 Investigate if current implementation of --license-file > is correct for Debian packages > JDK-8229138 Add --linux-app-release option for DEB and RPM packages > JDK-8229791 Code clean up regressions > JDK-8229786 No output after WinShortcutTest.exe is launched > JDK-8229750 Fix bad merge of JDK-8215447 patch > JDK-8215446 JPackageCreateInstallerInstallDirTest fails on OLE7 > JDK-8215447 Investigate if current implementation of --license-file > is correct for RPM packages > JDK-8227172 revert JDK-8225569 on windows > JDK-8224788 jpackage fails on OS X when using --runtime-image > JDK-8229252 Add descriptions to Windows jtreg tests > JDK-8228744 file associations broken on linux. > JDK-8227312 Remove pkg bundle from DMG image. > JDK-8228722 jpackage RPM tests fail on some versions of rpmbuild > JDK-8222778 Packaging Tool (JEP 343) on Linux/AArch64 > JDK-8224627 Creating installer with --runtime-image on OS X fails > JDK-8226904 current working directory wrong running jpackage app > JDK-8224486 Arguments from jpackager cfg file not processed correctly > JDK-8226835 Command window pops up building exe package > JDK-8225092 Several jpackage tests failed when run with jcov enabled > > /Andy > > From claes.redestad at oracle.com Mon Sep 2 14:02:56 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 2 Sep 2019 16:02:56 +0200 Subject: RFR: 8230301: Re-examine hardcoded defaults in GenerateJLIClassesPlugin Message-ID: Hi, we should avoid hard-coding the set of dynamically generated j.l.invoke classes to pre-generate into the jlink plugin, instead favoring generating the set of code to use at build-time. Webrev: http://cr.openjdk.java.net/~redestad/8230301/webrev.00/ Several of the hard-coded defaults predate optimizations to remove MH usage in lambda bootstrap and were generated using earlier iterations of ISC. This means many classes/methods generated are actualy never used, and that dropping all the defaults had relatively minimal effect on our set of startup tests. It's easy to create increasingly synthetic applications that suffer marginally. I did some experiments and identified a few small API calls we can add to HelloClasslist to recuperate a fair amount on some key applications, while still significantly reducing size of pre-generated code. Testing: tier1-3 Thanks! /Claes From pavel.rappo at oracle.com Mon Sep 2 15:45:38 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Mon, 2 Sep 2019 16:45:38 +0100 Subject: [PATCH] JDK-8228580 DnsClient TCP socket timeout In-Reply-To: References: <302C7323-55AB-4FC0-8E07-70B9D81E5DD8@oracle.com> Message-ID: <7242314D-F6A5-4514-9CA6-BA7EDA98EC27@oracle.com> > On 21 Aug 2019, at 09:27, Milan Mimica wrote: > > I don't know why main/timeout=20 does not work for me. What do you mean exactly by "does not work for me"? Are there any associated traces/logs from jtreg? Can you post them? From andrew_m_leonard at uk.ibm.com Mon Sep 2 16:10:19 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Mon, 2 Sep 2019 17:10:19 +0100 Subject: RFR: Request for sponsor : 8230436: String.stripIndent() javadoc unclear about LF/CR at end of string Message-ID: Hi, Can I get people's views and sponsor on a small update to the javadoc for String.stripIndent() to make the \n end of block special case more clear please? I've done a proposed patch here: http://cr.openjdk.java.net/~aleonard/8230436/webrev.00/ Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From pavel.rappo at oracle.com Mon Sep 2 17:18:37 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Mon, 2 Sep 2019 18:18:37 +0100 Subject: [PATCH] JDK-8228580 DnsClient TCP socket timeout In-Reply-To: References: <302C7323-55AB-4FC0-8E07-70B9D81E5DD8@oracle.com> Message-ID: <59D307B3-E489-4B35-8B59-63328C475A95@oracle.com> > On 22 Aug 2019, at 08:20, Milan Mimica wrote: > > Hi > > Indeed I have forgotten. Re-attached, with aesthetic fixes to the test. Milan, it seems that there is more work than we might've imagined initially. So as to proceed efficiently I would recommend you create a proper RFR [1] based on your most recent patch. If this is for some reason not possible, ping me and I will help you. At first sight, the code change seems okay. I think you did a really good job mimicking the existing (UDP) code, so much so that it looks like the new code was there all the time. Sure there are some issues like a possible numeric overflow, use of currentTimeMillis instead of monotonic nanoTime, not checking timeout for negative values, etc., but they are present in the UDP code too. If not yet robust, it is at least consistent with what there is today. We might address those issues later, filing separate bugs, but I don't think we are there yet. The attached test is, however, a bit different. I can't tell exactly what kind of issues [2] you've had with it, but there are some visible sources of potential instabilities. Create the RFR and let's discuss them. Thanks, -Pavel ------------------------------------------------------------------------------- [1] https://openjdk.java.net/guide/codeReview.html [2] "main/timeout=20 does not work for me" From milan.mimica at gmail.com Mon Sep 2 17:58:45 2019 From: milan.mimica at gmail.com (Milan Mimica) Date: Mon, 2 Sep 2019 19:58:45 +0200 Subject: [PATCH] JDK-8228580 DnsClient TCP socket timeout In-Reply-To: <7242314D-F6A5-4514-9CA6-BA7EDA98EC27@oracle.com> References: <302C7323-55AB-4FC0-8E07-70B9D81E5DD8@oracle.com> <7242314D-F6A5-4514-9CA6-BA7EDA98EC27@oracle.com> Message-ID: On Mon, 2 Sep 2019 at 17:45, Pavel Rappo wrote: > > > On 21 Aug 2019, at 09:27, Milan Mimica wrote: > > > > I don't know why main/timeout=20 does not work for me. > > What do you mean exactly by "does not work for me"? Are there any associated traces/logs from jtreg? Can you post them? I would expect the test to fail after 20 seconds (without the fix). It seems to fail after 80 seconds or so, I just didn't have the patience previously to wait for that long. Here is the log [1] if you want to take I look. However it's probably not a big deal, IMO. [1] https://pastebin.com/uUbeXfUf -- Milan Mimica From daniel.fuchs at oracle.com Tue Sep 3 09:58:12 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 3 Sep 2019 10:58:12 +0100 Subject: [PATCH] JDK-8228580 DnsClient TCP socket timeout In-Reply-To: References: <302C7323-55AB-4FC0-8E07-70B9D81E5DD8@oracle.com> <7242314D-F6A5-4514-9CA6-BA7EDA98EC27@oracle.com> Message-ID: <544325e0-953c-1810-cd70-48d310c1f0da@oracle.com> Hi Milan, I haven't keep up with this discussion, but your log shows: -J-Dtest.timeout.factor=4.0 \ 20s x 4.0 = 80s : mystery explained - or am I missing something? best regards, -- daniel On 02/09/2019 18:58, Milan Mimica wrote: > I would expect the test to fail after 20 seconds (without the fix). It > seems to fail after 80 seconds or so, I just didn't have the patience > previously to wait for that long. Here is the log [1] if you want to > take I look. However it's probably not a big deal, IMO. > > [1] https://pastebin.com/uUbeXfUf > > From andy.herrick at oracle.com Tue Sep 3 10:46:36 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 3 Sep 2019 06:46:36 -0400 Subject: jdk-14-jpackage+1-33 on jdk.java.net In-Reply-To: References: Message-ID: <4c2c67f6-bd76-4e19-57ab-5e807fab84dd@oracle.com> I can't reproduce this problem. In my manual examples as well as our related automated test cases the arguments specified by "--arguments
" are being delivered to the application when it is invoked without command line arguments. (Note: if there are any arguments given to the command to launch the app, they override the default arguments, not augment them). In the spirit of JDK-8224486 I passed all the following options: > --arguments --log-level=NONE \ > --arguments --log-level=SOME \ > --arguments --log-level=ALL \ to jpackage to package an application that just reported it's arguments, and it reported all three arguments as expected. /Andy On 9/2/2019 7:14 AM, Sverre Moe wrote: > I am having problem with arguments not being passed to the application. > The fix JDK-8224486 in this EA release seems to have something to do > with arguments, but it is actually just the JavaOptions. > > The options in ArgOptions in the jpackage cfg does not seem to be > passed to the application > > [ArgOptions] > --log-level=ALL > > This is not passed to the application. When I add it manually on the > command line then it works. > ./build/native/application/bin/application --log-level=ALL > > Is this a known bug with the jpackage? > > /Sverre > > > > tor. 22. aug. 2019 kl. 00:27 skrev Andy Herrick > >: > > The next EA build of JPackage is available at > https://jdk.java.net/jpackage/ > > This build ( jdk-14-jpackage+1-33 ) (2019/8/20) is the next early > access > release based on JDK-14 > > This release contains fixes to the following issues: > > JDK-8229788???? Error dialog displays with DLL issue when installing > WinChooserTest application > JDK-8225447???? Revise Debian packaging > JDK-8213941???? Debian linux problems in JavaPackager > JDK-8229334???? jpackage .exe packages cannot be executed due to > missing DLL > JDK-8227058???? Regressions related to no longer setting user.dir > JDK-8226599???? use code coverage results to remove dead code > JDK-8226191???? jpackager --license-file option broken on windows for > jdk installers. > JDK-8215381???? Investigate if current implementation of > --license-file > is correct for Debian packages > JDK-8229138???? Add --linux-app-release option for DEB and RPM > packages > JDK-8229791???? Code clean up regressions > JDK-8229786???? No output after WinShortcutTest.exe is launched > JDK-8229750???? Fix bad merge of JDK-8215447 patch > JDK-8215446???? JPackageCreateInstallerInstallDirTest fails on OLE7 > JDK-8215447???? Investigate if current implementation of > --license-file > is correct for RPM packages > JDK-8227172???? revert JDK-8225569 on windows > JDK-8224788???? jpackage fails on OS X when using --runtime-image > JDK-8229252???? Add descriptions to Windows jtreg tests > JDK-8228744???? file associations broken on linux. > JDK-8227312???? Remove pkg bundle from DMG image. > JDK-8228722???? jpackage RPM tests fail on some versions of rpmbuild > JDK-8222778???? Packaging Tool (JEP 343) on Linux/AArch64 > JDK-8224627???? Creating installer with --runtime-image on OS X fails > JDK-8226904???? current working directory wrong running jpackage app > JDK-8224486???? Arguments from jpackager cfg file not processed > correctly > JDK-8226835???? Command window pops up building exe package > JDK-8225092???? Several jpackage tests failed when run with jcov > enabled > > /Andy > From sverre.moe at gmail.com Tue Sep 3 12:05:27 2019 From: sverre.moe at gmail.com (Sverre Moe) Date: Tue, 3 Sep 2019 14:05:27 +0200 Subject: jdk-14-jpackage+1-33 on jdk.java.net In-Reply-To: <4c2c67f6-bd76-4e19-57ab-5e807fab84dd@oracle.com> References: <4c2c67f6-bd76-4e19-57ab-5e807fab84dd@oracle.com> Message-ID: I did not read the help output well enough where it says "used if no command line arguments are given to the launcher". This means we cannot set any default arguments to the application launcher and support manually entered command line arguments by the user. Is there a reason for this limitation? Why not support arguments from both the launcher and command line. I created a small test application on GitHub with similar build script we use on our application: https://github.com/DJViking/test-javafx It has one argument --log-level configured with jpackage. ./gradlew createNative ./build/native/test-javafx/bin/test-javafx --other=argument When running this app the --log-level argument are not passed to the application. /Sverre tir. 3. sep. 2019 kl. 12:46 skrev Andy Herrick : > I can't reproduce this problem. > > In my manual examples as well as our related automated test cases the > arguments specified by "--arguments
" are being > delivered to the application when it is invoked without command line > arguments. (Note: if there are any arguments given to the command to launch > the app, they override the default arguments, not augment them). > > In the spirit of JDK-8224486 I passed all the following options: > > --arguments --log-level=NONE \ > --arguments --log-level=SOME \ > --arguments --log-level=ALL \ > > to jpackage to package an application that just reported it's arguments, > and it reported all three arguments as expected. > > /Andy > On 9/2/2019 7:14 AM, Sverre Moe wrote: > > I am having problem with arguments not being passed to the application. > The fix JDK-8224486 in this EA release seems to have something to do with > arguments, but it is actually just the JavaOptions. > > The options in ArgOptions in the jpackage cfg does not seem to be passed > to the application > > [ArgOptions] > --log-level=ALL > > This is not passed to the application. When I add it manually on the > command line then it works. > ./build/native/application/bin/application --log-level=ALL > > Is this a known bug with the jpackage? > > /Sverre > > > > tor. 22. aug. 2019 kl. 00:27 skrev Andy Herrick : > >> The next EA build of JPackage is available at >> https://jdk.java.net/jpackage/ >> >> This build ( jdk-14-jpackage+1-33 ) (2019/8/20) is the next early access >> release based on JDK-14 >> >> This release contains fixes to the following issues: >> >> JDK-8229788 Error dialog displays with DLL issue when installing >> WinChooserTest application >> JDK-8225447 Revise Debian packaging >> JDK-8213941 Debian linux problems in JavaPackager >> JDK-8229334 jpackage .exe packages cannot be executed due to missing >> DLL >> JDK-8227058 Regressions related to no longer setting user.dir >> JDK-8226599 use code coverage results to remove dead code >> JDK-8226191 jpackager --license-file option broken on windows for >> jdk installers. >> JDK-8215381 Investigate if current implementation of --license-file >> is correct for Debian packages >> JDK-8229138 Add --linux-app-release option for DEB and RPM packages >> JDK-8229791 Code clean up regressions >> JDK-8229786 No output after WinShortcutTest.exe is launched >> JDK-8229750 Fix bad merge of JDK-8215447 patch >> JDK-8215446 JPackageCreateInstallerInstallDirTest fails on OLE7 >> JDK-8215447 Investigate if current implementation of --license-file >> is correct for RPM packages >> JDK-8227172 revert JDK-8225569 on windows >> JDK-8224788 jpackage fails on OS X when using --runtime-image >> JDK-8229252 Add descriptions to Windows jtreg tests >> JDK-8228744 file associations broken on linux. >> JDK-8227312 Remove pkg bundle from DMG image. >> JDK-8228722 jpackage RPM tests fail on some versions of rpmbuild >> JDK-8222778 Packaging Tool (JEP 343) on Linux/AArch64 >> JDK-8224627 Creating installer with --runtime-image on OS X fails >> JDK-8226904 current working directory wrong running jpackage app >> JDK-8224486 Arguments from jpackager cfg file not processed correctly >> JDK-8226835 Command window pops up building exe package >> JDK-8225092 Several jpackage tests failed when run with jcov enabled >> >> /Andy >> >> From pavel.rappo at oracle.com Tue Sep 3 14:33:15 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 3 Sep 2019 15:33:15 +0100 Subject: [PATCH] JDK-8228580 DnsClient TCP socket timeout In-Reply-To: References: <302C7323-55AB-4FC0-8E07-70B9D81E5DD8@oracle.com> <7242314D-F6A5-4514-9CA6-BA7EDA98EC27@oracle.com> Message-ID: There is no reason to wait until you can post your own RFR, this needs to be addressed separately and I've taken some steps to fix it. Here's your latest patch (please correct me if I'm wrong) as a webrev: http://cr.openjdk.java.net/~prappo/8228580/webrev.00/ Let's discuss it. As I said before I'm not yet concerned with the issues that are already present in the UDP case (integer overflow, use of currentTimeMillis, negative timeouts, etc.) so I'd suggest we focus on the test first. 1. I've run the test a couple of hundred times and observed some infrequent failures (the test timed out). Here's an excerpt from the associated thread dump: ... java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(java.base at 14-internal/Native Method) - waiting on <0x00000000e086d3a8> (a java.lang.Thread) at java.lang.Thread.join(java.base at 14-internal/Thread.java:1303) - locked <0x00000000e086d3a8> (a java.lang.Thread) at java.lang.Thread.join(java.base at 14-internal/Thread.java:1371) at TcpTimeout$TcpDnsServer.stopServer(TcpTimeout.java:107) at TcpTimeout.cleanupTest(TcpTimeout.java:76) at TestBase.launch(TestBase.java:88) at TestBase.run(TestBase.java:50) at TcpTimeout.main(TcpTimeout.java:46) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 14-internal/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 14-internal/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 14-internal/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base at 14-internal/Method.java:564) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298) at java.lang.Thread.run(java.base at 14-internal/Thread.java:830) ... I'm not sure yet how that thread ended up being blocked in this place for so long. One possibility would be if `serverSocket` did not react on `close()` (L106). Which is highly unlikely. What is more likely though is that `serverSocket` was found (L105) to be null and thus was never closed. That makes sense given that this field is accessed from more than one thread without sufficient synchronization. I don't know whether that was indeed the case, but we'd better address that issue to rule out that possibility in the future. 2. The way ServerSocket is created on L91 is troublesome for two reasons. The first one is that we don't know which interface this server socket will be bound to. I'd better use serverSocket = new ServerSocket(port, 0, InetAddress.getLoopbackAddress()); which is what UDP DNSServer does, albeit implicitly. Secondly, even though the UDP server got its port from the ephemeral port range, we can't really guarantee that this same port will be simultaneously available for TCP. There are a couple of solutions for this issue. One would be to make the test run inapplicable by throwing jtreg.SkippedException. 3. L34, typo: UDH DNS server; L57, typo: the reponse is -Pavel > On 2 Sep 2019, at 18:58, Milan Mimica wrote: > > On Mon, 2 Sep 2019 at 17:45, Pavel Rappo wrote: >> >>> On 21 Aug 2019, at 09:27, Milan Mimica wrote: >>> >>> I don't know why main/timeout=20 does not work for me. >> >> What do you mean exactly by "does not work for me"? Are there any associated traces/logs from jtreg? Can you post them? > > I would expect the test to fail after 20 seconds (without the fix). It > seems to fail after 80 seconds or so, I just didn't have the patience > previously to wait for that long. Here is the log [1] if you want to > take I look. However it's probably not a big deal, IMO. > > [1] https://pastebin.com/uUbeXfUf > > > -- > Milan Mimica From sgehwolf at redhat.com Tue Sep 3 15:50:29 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 03 Sep 2019 17:50:29 +0200 Subject: [8u] RFR: 8213734: SAXParser.parse(File, ..) does not close resources when Exception occurs. In-Reply-To: <0a64931ab640afd557f4bd46aa7bb05512bc79d6.camel@redhat.com> References: <0a64931ab640afd557f4bd46aa7bb05512bc79d6.camel@redhat.com> Message-ID: On Mon, 2019-08-26 at 17:54 +0200, Severin Gehwolf wrote: > Hi, > > Please review this 8u backport. The OpenJDK 11u patch does not apply > cleanly after path-reshuffeling due to a) test and code for jaxp are > split in JDK 8 b) Some rejects in comments - copyright and last > modified date. I've omitted rejected comments. I can manually add them > if that's preferred. See below. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213734 > webrevs: > jdk: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8213734/jdk8/jdk/01/webrev/ > jaxp: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8213734/jdk8/jaxp/01/webrev/ > > Testing: tier1 on Linux x86_64. javax/xml/jaxp tests. New test on > Windows without the fix fails and passes with it. > > Thanks to Simon Tooke who helped testing this patch on Windows. > > Rejects: > $ cat src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java.rej > --- XMLEntityManager.java > +++ XMLEntityManager.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2009, 2017, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2009, 2018, Oracle and/or its affiliates. All rights reserved. > */ > /* > * Licensed to the Apache Software Foundation (ASF) under one or more > @@ -89,7 +89,7 @@ > * @author K.Venugopal SUN Microsystems > * @author Neeraj Bajaj SUN Microsystems > * @author Sunitha Reddy SUN Microsystems > - * @LastModified: Oct 2017 > + * @LastModified: Nov 2018 > */ > public class XMLEntityManager implements XMLComponent, XMLEntityResolver { > Gentle reminder. Thanks, Severin > Thoughts? > > Thanks, > Severin From milan.mimica at gmail.com Tue Sep 3 14:12:57 2019 From: milan.mimica at gmail.com (Milan Mimica) Date: Tue, 3 Sep 2019 16:12:57 +0200 Subject: [PATCH] JDK-8228580 DnsClient TCP socket timeout In-Reply-To: <544325e0-953c-1810-cd70-48d310c1f0da@oracle.com> References: <302C7323-55AB-4FC0-8E07-70B9D81E5DD8@oracle.com> <7242314D-F6A5-4514-9CA6-BA7EDA98EC27@oracle.com> <544325e0-953c-1810-cd70-48d310c1f0da@oracle.com> Message-ID: Hi Daniel Yes, that explains it. It is a jtreg setting[1], setup in makefile. [1] https://openjdk.java.net/jtreg/command-help.html -timeout: | -timeoutFactor: A scaling factor to extend the default timeout of all tests. Typically used when running on slow file systems. On Tue, 3 Sep 2019 at 11:57, Daniel Fuchs wrote: > > Hi Milan, > > I haven't keep up with this discussion, but your log shows: > > -J-Dtest.timeout.factor=4.0 \ > > 20s x 4.0 = 80s : mystery explained - or am I missing something? > > best regards, > > -- daniel > > > On 02/09/2019 18:58, Milan Mimica wrote: > > I would expect the test to fail after 20 seconds (without the fix). It > > seems to fail after 80 seconds or so, I just didn't have the patience > > previously to wait for that long. Here is the log [1] if you want to > > take I look. However it's probably not a big deal, IMO. > > > > [1] https://pastebin.com/uUbeXfUf > > > > > -- Milan Mimica From mark.reinhold at oracle.com Tue Sep 3 18:58:55 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 3 Sep 2019 11:58:55 -0700 (PDT) Subject: Comments on jpackage (JEP 343) Message-ID: <20190903185855.D9F092BEC49@eggemoggin.niobe.net> I spent some time last week playing with the jpackage tool, using build 14-jpackage+1-35 from https://jdk.java.net/jpackage. Overall, I can see that you?ve made good progress, but there?s still some work to be done. I?ll start with high-level comments and questions, and then comment on my experience using the tool on Debian and then macOS. High-level comments/questions - It?s good that you?re publishing EA builds, but I haven?t seen very much feedback from those builds. It may be better to propose this as an experimental feature when it?s ready to target. That would give you the freedom to improve it incompatibly over one or two release cycles before you commit to a final version. - The tool still generates an image by default, rather than a package. This will surprise many users, especially those who just want to do something simple and straightforward. The least-surprising default behavior would be to generate a package of the type most suitable for the current platform. An option to generate just an image would be fine, for those who want to tweak it before the actual packaging step, but that shouldn?t be the default. - Related to the previous point, I should only have to specify the `--package-type` option if I want something other than the default for the current platform. - The tool assumes that the application being packaged will have a GUI. This isn?t surprising, considering its heritage, but as a consequence it always produces packages that perform GUI-specific actions, such as installing icons and desktop-menu entries. If I?m just packaging a command-line tool then these are unnecessary, and supporting them can pull in lots of additional dependencies (e.g., a ton of Perl scripts on Debian). Consider adding an option (`--gui`?) so that the user can indicate when an application is to be installed for graphical use. - The `--output`/`-o` option is confusing. It doesn?t name the output itself, but rather a directory into which the single item of output will be placed. Typing `-o .` all the time is just annoying. It?d be more logical to rename this option to `--dest`/`-d` and to make it optional, with a default value of `.`. - If my app is modular, and my main module has a version string, then it?d be nice for that to be used as the package version unless a specific version is specified on the command line. - Terminology: For Linux we generally speak of ?packages? rather than ?bundles.? Rename `--linux-bundle-name` to `--linux-package-name`. - The `--temp-root` option could be shortened to `--temp`. - Periods at the ends of error messages are unsightly and unnecessary. We don?t use them in other JDK tools. Please remove them. - It?d be nice to have an option that displays the programs being run by the tool, in a form that can easily be cut-and-pasted into a script for those who need to do a lot of customization. The current verbose output shows (at least some of) this information, but in a difficult-to-use format. - What?s the rationale for copying the entire ?input? directory as-is? Why is its structure important? Couldn?t you just as well limit this to a single directory full of JAR files? Comments on Debian packaging - On a Debian machine I tried to create a package for a trivial, two-module application using the command $ jpackage -o . --package-type deb -p lib -m org.openjdk.hello -n hello which gave me the error message Bundler DEB Installer skipped because of a configuration problem: java.lang.NullPointerException. (Side note: This message is confusing since the tool is creating a Debian package, not an ?installer.?) - On a hunch, I specified a main application class: $ jpackage -o . --package-type deb -p lib -m org.openjdk.hello/org.openjdk.hello.Main -n hello and that created `hello_1.0-1_amd64.deb`. It shouldn?t have been necessary to specify a main class since the main module does have a `ModuleMainClass` attribute in its module descriptor. - The resulting package does not depend upon any others, i.e., the `Depends:` line in its control file is empty. This can?t possibly be right, since the embedded JDK depends on many system libraries for proper operation (`libc`, `libfreetype`, `libpthread`, etc.). - The resulting package would install into `/opt/hello`, as expected, but the `/opt/hello/bin` directory would contain not just the `hello` application launcher but also `hello.desktop`, `hello.png`, and `libapplauncher.so`. These aren?t appropriate for a `bin` directory and should be placed elsewhere, most likely `/opt/hello/lib`. - The resulting package would install `/opt/hello/app` and `/opt/hello/runtime` directories. These are not strictly forbidden by the Linux FHS [1], but it?d be better to put both of them under `/opt/hello/lib`, per convention. - The resulting package does not contain the normal `java` launcher. It?d be helpful to retain this (in `runtime/bin/java`, not in the app?s `bin` directory) for diagnostic purposes. It?s not large. - The resulting package would install the copyright file into `/usr/share/doc/hello/copyright`, which is wrong -- a package that installs into `/opt` should never touch anything under /usr [1]. This file should be at `/opt/hello/share/doc/copyright`. - I attempted to install the package on a fresh Ubuntu 18.04 machine: # dpkg -i hello-1.0.deb Selecting previously unselected package hello. (Reading database ... 135670 files and directories currently installed.) Preparing to unpack hello-1.0.deb ... Unpacking hello (1.0) ... Setting up hello (1.0) ... Adding shortcut to the menu /var/lib/dpkg/info/hello.postinst: 25: /var/lib/dpkg/info/hello.postinst: xdg-desktop-menu: not found dpkg: error processing package hello (--install): installed hello package post-installation script subprocess returned error exit status 127 Errors were encountered while processing: hello mr-dev # uname -a Linux mr-dev 4.15.0-1018-oracle #20-Ubuntu SMP Wed Jul 3 06:46:12 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux mr-dev # cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=18.04 DISTRIB_CODENAME=bionic DISTRIB_DESCRIPTION="Ubuntu 18.04.3 LTS" # Apparently the package should depend upon `xdg-utils`, so that its post-install script can find `xdg-desktop-menu`. Even better, though, would be for this trivial non-graphical application not to depend upon any desktop utilities, per my comment above. - Installing the package succeeded despite the above error. I was successfully able to run my trivial application. Yay! - Then I tried to uninstall it: mr-dev # dpkg --remove hello (Reading database ... 135923 files and directories currently installed.) Removing hello (1.0) ... Removing shortcut /var/lib/dpkg/info/hello.prerm: 25: /var/lib/dpkg/info/hello.prerm: xdg-desktop-menu: not found dpkg: error processing package hello (--remove): installed hello package pre-removal script subprocess returned error exit status 127 Errors were encountered while processing: hello mr-dev # I installed `xdg-utils` by hand to get `xdg-desktop-menu`, but it still didn?t work: mr-dev # dpkg --remove hello (Reading database ... 136878 files and directories currently installed.) Removing hello (1.0) ... Removing shortcut xdg-desktop-menu: No writable system menu directory found. dpkg: error processing package hello (--remove): installed hello package pre-removal script subprocess returned error exit status 3 Errors were encountered while processing: hello mr-dev # I eventually figured out how to create a fake writable system menu directory and was then able to remove the package. - The `--linux-deb-copyright` option is confusing. Its description should mention that if this option is specified then the `--license` option is, so far as I can tell, ignored. - The `--identifier` option appears to have no use for Debian packages. Perhaps this option should be package-type specific? Or at least its description should mention that it?s irrelevant to Debian packages. - I tried to create a package that would install into the `/usr` hierarchy by adding `--install-dir /usr` to the above command line. The resulting package would create a `/usr/hello` directory, with `app`, `bin`, and `runtime` directories under that. That?s not right. To install an application in the `/usr` hierarchy its command should go into `/usr/bin`, and libraries and other files should go into `/usr/lib/$APPNAME`, and documentation and copyright files should go into `/usr/share/doc/$APPNAME`. - Many of the above observations could also apply to RPM packages, but I haven?t checked. Comments on macOS packaging (Warning: I?m not an expert macOS developer!) - On a macOS machine (10.13.6) I tried to create a dmg package: $ jpackage -o . --package-type dmg -p lib -m org.openjdk.hello/org.openjdk.hello.Main -n hello which gave me the error message Exec failed with code 1 command [[/usr/bin/SetFile, -c, icnC, /var/folders/mn/8nt00ldx7dqfrv55wk72mgq80000gr/T/jdk.jpackage9024163201922289964/images/hello/.VolumeIcon.icns] in unspecified directory output: xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun although it exited with status 0 and did produce a valid `.dmg` file. I suppose I?m missing some development tools? If so then please document that dependency, and if possible issue a more helpful error message that tells the user what they need to install. - It?d be nice if the resulting `.dmg` file, when opened, were to show an icon for the Applications folder and an arrow pointing to that from the app icon, so that the user can drag it across. Almost all `.dmg` files that I?ve seen do this. - Mark [1] https://www.debian.org/doc/packaging-manuals/fhs/fhs-3.0.html#optAddonApplicationSoftwarePackages From huaming.li at oracle.com Wed Sep 4 03:01:05 2019 From: huaming.li at oracle.com (Hamlin Li) Date: Wed, 4 Sep 2019 11:01:05 +0800 Subject: RFR of JDK-8134599: TEST_BUG: java/rmi/transport/closeServerSocket/CloseServerSocket.java fails intermittently with Address already in use Message-ID: Hi, Would you please review the following patch? Bug: https://bugs.openjdk.java.net/browse/JDK-8134599 webrev: http://cr.openjdk.java.net/~mli/8134599/webrev.00/ Thank you -Hamlin From huaming.li at oracle.com Wed Sep 4 03:11:03 2019 From: huaming.li at oracle.com (Hamlin Li) Date: Wed, 4 Sep 2019 11:11:03 +0800 Subject: RFR of JDK-8134599: TEST_BUG: java/rmi/transport/closeServerSocket/CloseServerSocket.java fails intermittently with Address already in use In-Reply-To: References: Message-ID: some background & comment: in most of failures, the "test.timeout.factor" is 10.0 or 8.0, so in the test code this factor should be considered in rmi operations such unexporting an object. Thank you -Hamlin On 2019/9/4 11:01 AM, Hamlin Li wrote: > Hi, > > Would you please review the following patch? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8134599 > > webrev: http://cr.openjdk.java.net/~mli/8134599/webrev.00/ > > > Thank you > > -Hamlin > From sha.jiang at oracle.com Wed Sep 4 03:33:37 2019 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Wed, 4 Sep 2019 11:33:37 +0800 Subject: RFR of JDK-8134599: TEST_BUG: java/rmi/transport/closeServerSocket/CloseServerSocket.java fails intermittently with Address already in use In-Reply-To: References: Message-ID: Hi Hamlin, 66???????? Thread.sleep(1000L * (long)TestLibrary.getTimeoutFactor()); Now that the factor has been casted to long, it could just use 1000 instead 1000L. Could the fraction of this factor value be greater than 0? If so, the casting should take effect after the multiplication, like Thread.sleep((long) (1000 * TestLibrary.getTimeoutFactor())); Best regards, John Jiang On 2019/9/4 11:01, Hamlin Li wrote: > Hi, > > Would you please review the following patch? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8134599 > > webrev: http://cr.openjdk.java.net/~mli/8134599/webrev.00/ > > > Thank you > > -Hamlin > > From huaming.li at oracle.com Wed Sep 4 07:16:40 2019 From: huaming.li at oracle.com (Hamlin Li) Date: Wed, 4 Sep 2019 15:16:40 +0800 Subject: RFR of JDK-8134599: Improve the code coverage for ThreadLocal Message-ID: <2294a248-1569-1d3a-85b5-76bff05a4274@oracle.com> Would you please review the following patch? bug: https://bugs.openjdk.java.net/browse/JDK-8209824 webrev: http://cr.openjdk.java.net/~mli/8209824/webrev.00/ Thank you -Hamlin From sverre.moe at gmail.com Wed Sep 4 09:53:19 2019 From: sverre.moe at gmail.com (Sverre Moe) Date: Wed, 4 Sep 2019 11:53:19 +0200 Subject: Comments on jpackage (JEP 343) In-Reply-To: <20190903185855.D9F092BEC49@eggemoggin.niobe.net> References: <20190903185855.D9F092BEC49@eggemoggin.niobe.net> Message-ID: I tired the latest build 14-jpackage+1-35 today. Good to see that debian package file name is finally up to the specification. Noticed something though with building the debian package: When using a control file from the resource directory, jpackage does not use its version and release. Must apply "--app-version" and "--linux-app-release" in order to get the proper version and release on file name. Running dpkg-deb --show and --info has the correct version and release. dpkg-deb --show build/deb/application_1.0-1_amd64.deb application 1.1.0-SNAPSHOT20190904113134 I wonder where it gets the version 1.0 from, since my project.version=1.1.0. The jpackage should at least use the project version if no other version is specified. This is a problem only for the debian package on Linux. When building an RPM, jpackage uses both the Version and Release defined within the spec resource file. Isn't release also applicable for Windows and Mac? What about, instead of calling it "--linux-app-release", why not simply call it "--app-release". That would stand much better together with "--app-version". With "--linux-app-release" it makes it more more verbose when scripting the build, when it needs to check for Windows and Mac in order to omit that flag. /Sverre tir. 3. sep. 2019 kl. 21:01 skrev : > I spent some time last week playing with the jpackage tool, using build > 14-jpackage+1-35 from https://jdk.java.net/jpackage. > > Overall, I can see that you?ve made good progress, but there?s still some > work to be done. I?ll start with high-level comments and questions, and > then comment on my experience using the tool on Debian and then macOS. > > High-level comments/questions > > - It?s good that you?re publishing EA builds, but I haven?t seen very > much feedback from those builds. It may be better to propose this as > an experimental feature when it?s ready to target. That would give > you the freedom to improve it incompatibly over one or two release > cycles before you commit to a final version. > > - The tool still generates an image by default, rather than a package. > This will surprise many users, especially those who just want to do > something simple and straightforward. The least-surprising default > behavior would be to generate a package of the type most suitable for > the current platform. An option to generate just an image would be > fine, for those who want to tweak it before the actual packaging > step, but that shouldn?t be the default. > > - Related to the previous point, I should only have to specify the > `--package-type` option if I want something other than the default > for the current platform. > > - The tool assumes that the application being packaged will have a GUI. > This isn?t surprising, considering its heritage, but as a consequence > it always produces packages that perform GUI-specific actions, such > as installing icons and desktop-menu entries. If I?m just packaging > a command-line tool then these are unnecessary, and supporting them > can pull in lots of additional dependencies (e.g., a ton of Perl > scripts on Debian). Consider adding an option (`--gui`?) so that > the user can indicate when an application is to be installed for > graphical use. > > - The `--output`/`-o` option is confusing. It doesn?t name the output > itself, but rather a directory into which the single item of output > will be placed. Typing `-o .` all the time is just annoying. It?d > be more logical to rename this option to `--dest`/`-d` and to make it > optional, with a default value of `.`. > > - If my app is modular, and my main module has a version string, then > it?d be nice for that to be used as the package version unless a > specific version is specified on the command line. > > - Terminology: For Linux we generally speak of ?packages? rather than > ?bundles.? Rename `--linux-bundle-name` to `--linux-package-name`. > > - The `--temp-root` option could be shortened to `--temp`. > > - Periods at the ends of error messages are unsightly and unnecessary. > We don?t use them in other JDK tools. Please remove them. > > - It?d be nice to have an option that displays the programs being run > by the tool, in a form that can easily be cut-and-pasted into a > script for those who need to do a lot of customization. The current > verbose output shows (at least some of) this information, but in a > difficult-to-use format. > > - What?s the rationale for copying the entire ?input? directory as-is? > Why is its structure important? Couldn?t you just as well limit this > to a single directory full of JAR files? > > Comments on Debian packaging > > - On a Debian machine I tried to create a package for a trivial, > two-module application using the command > > $ jpackage -o . --package-type deb -p lib -m org.openjdk.hello -n > hello > > which gave me the error message > > Bundler DEB Installer skipped because of a configuration problem: > java.lang.NullPointerException. > > (Side note: This message is confusing since the tool is creating a > Debian package, not an ?installer.?) > > - On a hunch, I specified a main application class: > > $ jpackage -o . --package-type deb -p lib -m > org.openjdk.hello/org.openjdk.hello.Main -n hello > > and that created `hello_1.0-1_amd64.deb`. It shouldn?t have been > necessary to specify a main class since the main module does have a > `ModuleMainClass` attribute in its module descriptor. > > - The resulting package does not depend upon any others, i.e., the > `Depends:` line in its control file is empty. This can?t possibly be > right, since the embedded JDK depends on many system libraries for > proper operation (`libc`, `libfreetype`, `libpthread`, etc.). > > - The resulting package would install into `/opt/hello`, as expected, > but the `/opt/hello/bin` directory would contain not just the `hello` > application launcher but also `hello.desktop`, `hello.png`, and > `libapplauncher.so`. These aren?t appropriate for a `bin` directory > and should be placed elsewhere, most likely `/opt/hello/lib`. > > - The resulting package would install `/opt/hello/app` and > `/opt/hello/runtime` directories. These are not strictly forbidden > by the Linux FHS [1], but it?d be better to put both of them under > `/opt/hello/lib`, per convention. > > - The resulting package does not contain the normal `java` launcher. > It?d be helpful to retain this (in `runtime/bin/java`, not in the > app?s `bin` directory) for diagnostic purposes. It?s not large. > > - The resulting package would install the copyright file into > `/usr/share/doc/hello/copyright`, which is wrong -- a package that > installs into `/opt` should never touch anything under /usr [1]. This > file should be at `/opt/hello/share/doc/copyright`. > > - I attempted to install the package on a fresh Ubuntu 18.04 machine: > > # dpkg -i hello-1.0.deb > Selecting previously unselected package hello. > (Reading database ... 135670 files and directories currently > installed.) > Preparing to unpack hello-1.0.deb ... > Unpacking hello (1.0) ... > Setting up hello (1.0) ... > Adding shortcut to the menu > /var/lib/dpkg/info/hello.postinst: 25: > /var/lib/dpkg/info/hello.postinst: xdg-desktop-menu: not found > dpkg: error processing package hello (--install): > installed hello package post-installation script subprocess > returned error exit status 127 > Errors were encountered while processing: > hello > mr-dev # uname -a > Linux mr-dev 4.15.0-1018-oracle #20-Ubuntu SMP Wed Jul 3 06:46:12 > UTC 2019 x86_64 x86_64 x86_64 GNU/Linux > mr-dev # cat /etc/lsb-release > DISTRIB_ID=Ubuntu > DISTRIB_RELEASE=18.04 > DISTRIB_CODENAME=bionic > DISTRIB_DESCRIPTION="Ubuntu 18.04.3 LTS" > # > > Apparently the package should depend upon `xdg-utils`, so that its > post-install script can find `xdg-desktop-menu`. Even better, > though, would be for this trivial non-graphical application not to > depend upon any desktop utilities, per my comment above. > > - Installing the package succeeded despite the above error. I was > successfully able to run my trivial application. Yay! > > - Then I tried to uninstall it: > > mr-dev # dpkg --remove hello > (Reading database ... 135923 files and directories currently > installed.) > Removing hello (1.0) ... > Removing shortcut > /var/lib/dpkg/info/hello.prerm: 25: > /var/lib/dpkg/info/hello.prerm: xdg-desktop-menu: not found > dpkg: error processing package hello (--remove): > installed hello package pre-removal script subprocess returned > error exit status 127 > Errors were encountered while processing: > hello > mr-dev # > > I installed `xdg-utils` by hand to get `xdg-desktop-menu`, but it still > didn?t work: > > mr-dev # dpkg --remove hello > (Reading database ... 136878 files and directories currently > installed.) > Removing hello (1.0) ... > Removing shortcut > xdg-desktop-menu: No writable system menu directory found. > dpkg: error processing package hello (--remove): > installed hello package pre-removal script subprocess returned > error exit status 3 > Errors were encountered while processing: > hello > mr-dev # > > I eventually figured out how to create a fake writable system menu > directory and was then able to remove the package. > > - The `--linux-deb-copyright` option is confusing. Its description > should mention that if this option is specified then the `--license` > option is, so far as I can tell, ignored. > > - The `--identifier` option appears to have no use for Debian packages. > Perhaps this option should be package-type specific? Or at least its > description should mention that it?s irrelevant to Debian packages. > > - I tried to create a package that would install into the `/usr` > hierarchy by adding `--install-dir /usr` to the above command line. > The resulting package would create a `/usr/hello` directory, with > `app`, `bin`, and `runtime` directories under that. That?s not > right. To install an application in the `/usr` hierarchy its command > should go into `/usr/bin`, and libraries and other files should go > into `/usr/lib/$APPNAME`, and documentation and copyright files > should go into `/usr/share/doc/$APPNAME`. > > - Many of the above observations could also apply to RPM packages, but > I haven?t checked. > > Comments on macOS packaging > > (Warning: I?m not an expert macOS developer!) > > - On a macOS machine (10.13.6) I tried to create a dmg package: > > $ jpackage -o . --package-type dmg -p lib -m > org.openjdk.hello/org.openjdk.hello.Main -n hello > > which gave me the error message > > Exec failed with code 1 command [[/usr/bin/SetFile, -c, icnC, > /var/folders/mn/8nt00ldx7dqfrv55wk72mgq80000gr/T/jdk.jpackage9024163201922289964/images/hello/.VolumeIcon.icns] > in unspecified directory output: xcrun: error: invalid active developer > path (/Library/Developer/CommandLineTools), missing xcrun at: > /Library/Developer/CommandLineTools/usr/bin/xcrun > > although it exited with status 0 and did produce a valid `.dmg` file. > I suppose I?m missing some development tools? If so then please > document that dependency, and if possible issue a more helpful error > message that tells the user what they need to install. > > - It?d be nice if the resulting `.dmg` file, when opened, were to show > an icon for the Applications folder and an arrow pointing to that > from the app icon, so that the user can drag it across. Almost all > `.dmg` files that I?ve seen do this. > > - Mark > > > [1] > https://www.debian.org/doc/packaging-manuals/fhs/fhs-3.0.html#optAddonApplicationSoftwarePackages > From sverre.moe at gmail.com Wed Sep 4 12:05:10 2019 From: sverre.moe at gmail.com (Sverre Moe) Date: Wed, 4 Sep 2019 14:05:10 +0200 Subject: jdk-14-jpackage+1-33 on jdk.java.net In-Reply-To: References: <3d92d996-eca0-7971-0716-42b885525295@oracle.com> <36feb3a6-e24c-6239-4563-cada989f20c7@oracle.com> Message-ID: Running WiX failed. The problem it seems is the -dJpAppVendor. It cannot handle special characters in the vendor name. Our company name uses the ampersand (&) instead of "and". Caused by: java.io.IOException: Exec failed with code 104 command [[C:\Program Files (x86)\WiX Toolset v3.11\bin\candle.exe, -nologo, C:\cygwin64\tmp\jdk.jpackage1086156882119031648\config\application.wxs, -ext, WixUtilExtension, -out, C:\cygwin64\tmp\jdk.jpackage1086156882119031648\tmp\application.wixobj, -dJpAppDescription=application, -dJpAppVersion=1.1.0, -dJpWixVersion36OrNewer=yes, -dJpProductCode=2fa37b54-8365-437d-ad34-ceed92844d22, -dJpAppName=application, -dJpProductUpgradeCode=53c0f7f6-75c1-419a-86c5-bef18dda408a, -dJpIsSystemWide=yes, -dJpAppVendor=Kongsberg Defence & Aerospace, -dJpConfigDir=C:\cygwin64\tmp\jdk.jpackage1086156882119031648\config] in C:\cygwin64\tmp\jdk.jpackage1086156882119031648\images\win-msi.image\application output: application.wxsC:\cygwin64\tmp\jdk.jpackage1086156882119031648\config\application.wxs(56) : error CNDL0104 : Not a valid source file; detail: An error occurred while parsing EntityName. Line 9, position 68. Is there anyway to allow special characters in the vendor name? It would be very useful to be able to define the release, in addition to the version. This is currently only possible on Linux with "--linux-app-release". I could have hacked this by setting "--app-version" to VERSION-RELEASE. It would increase the special logic in the build script specific for Windows, but it does not seem to be allowed with release in the version string: Version string is not compatible with MSI rules [1.1.0-SNAPSHOT20190904133731] https://docs.microsoft.com/en-us/windows/win32/msi/productversion Could this potentially cause problems when installing SNAPSHOTs which have the same version? Anyway it does not seem WiX XML schema has any release or build attributes. /Sverre tor. 29. aug. 2019 kl. 17:38 skrev Sverre Moe : > No, have not installed WIX. Had InnoSetup from when we use javapackager. > I will look into the WiX: https://wixtoolset.org > > /Sverre > > tor. 29. aug. 2019 kl. 17:34 skrev Kevin Rushforth < > kevin.rushforth at oracle.com>: > >> Hi Sverre, >> >> Do you have a WiX installed on your machine? That is a prerequisite. >> >> Andy: Do we have a bug filed to produce a better error message in this >> case? If not, we need to file one. >> >> -- Kevin >> >> >> On 8/29/2019 7:30 AM, Sverre Moe wrote: >> >> It is not working creating native installer on Windows. >> >> It will not take neither exe nor msi as --package-type on Windows. >> jdk.jpackage.internal.PackagerException: Error: Invalid or unsupported >> package type: [exe]. >> at >> jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:614) >> at >> jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:513) >> at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:97) >> at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:51) >> >> The jpackage help output on Windows lists both exe and msi as valid >> package types. >> >> The JDK-8228660 is marked as resolved. I reckon it will make it into the >> next build. >> >> /Sverre >> >> >> tor. 22. aug. 2019 kl. 02:03 skrev Kevin Rushforth < >> kevin.rushforth at oracle.com>: >> >>> We believe that we have addressed most of the issues, especially those >>> affecting the generated Linux packages, both .deb and .rpm. There is one >>> open issue around the naming of the Debian packages that we will address >>> in the next EA release. See JDK-8228660 [1] for more information. >>> >>> We would love to get some feedback from Linux developers to make sure >>> that we didn't miss anything else. >>> >>> Thanks. >>> >>> -- Kevin >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8228660 >>> >>> >>> On 8/21/2019 3:27 PM, Andy Herrick wrote: >>> > The next EA build of JPackage is available at >>> > https://jdk.java.net/jpackage/ >>> > >>> > This build ( jdk-14-jpackage+1-33 ) (2019/8/20) is the next early >>> > access release based on JDK-14 >>> > >>> > This release contains fixes to the following issues: >>> > >>> > JDK-8229788 Error dialog displays with DLL issue when installing >>> > WinChooserTest application >>> > JDK-8225447 Revise Debian packaging >>> > JDK-8213941 Debian linux problems in JavaPackager >>> > JDK-8229334 jpackage .exe packages cannot be executed due to >>> > missing DLL >>> > JDK-8227058 Regressions related to no longer setting user.dir >>> > JDK-8226599 use code coverage results to remove dead code >>> > JDK-8226191 jpackager --license-file option broken on windows for >>> > jdk installers. >>> > JDK-8215381 Investigate if current implementation of >>> > --license-file is correct for Debian packages >>> > JDK-8229138 Add --linux-app-release option for DEB and RPM packages >>> > JDK-8229791 Code clean up regressions >>> > JDK-8229786 No output after WinShortcutTest.exe is launched >>> > JDK-8229750 Fix bad merge of JDK-8215447 patch >>> > JDK-8215446 JPackageCreateInstallerInstallDirTest fails on OLE7 >>> > JDK-8215447 Investigate if current implementation of >>> > --license-file is correct for RPM packages >>> > JDK-8227172 revert JDK-8225569 on windows >>> > JDK-8224788 jpackage fails on OS X when using --runtime-image >>> > JDK-8229252 Add descriptions to Windows jtreg tests >>> > JDK-8228744 file associations broken on linux. >>> > JDK-8227312 Remove pkg bundle from DMG image. >>> > JDK-8228722 jpackage RPM tests fail on some versions of rpmbuild >>> > JDK-8222778 Packaging Tool (JEP 343) on Linux/AArch64 >>> > JDK-8224627 Creating installer with --runtime-image on OS X fails >>> > JDK-8226904 current working directory wrong running jpackage app >>> > JDK-8224486 Arguments from jpackager cfg file not processed >>> correctly >>> > JDK-8226835 Command window pops up building exe package >>> > JDK-8225092 Several jpackage tests failed when run with jcov >>> enabled >>> > >>> > /Andy >>> > >>> >>> >> From milan.mimica at gmail.com Wed Sep 4 12:26:40 2019 From: milan.mimica at gmail.com (Milan Mimica) Date: Wed, 4 Sep 2019 14:26:40 +0200 Subject: RFR(s): 8228580: DnsClient TCP socket timeout Message-ID: Hello Continuing in a new thread with a RFR of my own: http://cr.openjdk.java.net/~mmimica/8228580/webrev.00/ It has the fixes applied from the first review of the patch. The test was sporadically failing not because of missing synchronization, but more likely because test was not waiting for the TCP server thread to actually start. Made it throw jtreg.SkippedException if TCP port is in use. We can just hope it does not happen too often. Fixed typos. -- Milan Mimica From fweimer at redhat.com Wed Sep 4 16:35:45 2019 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 04 Sep 2019 18:35:45 +0200 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: (Milan Mimica's message of "Wed, 4 Sep 2019 14:26:40 +0200") References: Message-ID: <87tv9sm332.fsf@oldenburg2.str.redhat.com> * Milan Mimica: > Continuing in a new thread with a RFR of my own: > http://cr.openjdk.java.net/~mmimica/8228580/webrev.00/ I would add a comment why there's no explicit TCP connection timeout in the code. I assume you rely on the TCP stack having its own timeout, right? But I think it can be quite long under some circumstances. The timeout will not be enforced properly if the clock jumps backwards. Thanks, Florian From pavel.rappo at oracle.com Wed Sep 4 17:02:07 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 4 Sep 2019 18:02:07 +0100 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: References: Message-ID: <78AA9395-CD60-414D-8670-91B68F1AC1C5@oracle.com> > On 4 Sep 2019, at 13:26, Milan Mimica wrote: > > Hello > > Continuing in a new thread with a RFR of my own: > http://cr.openjdk.java.net/~mmimica/8228580/webrev.00/ Here's the link to the previous discussion: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/061918.html > It has the fixes applied from the first review of the patch. > > The test was sporadically failing not because of missing > synchronization, but more likely because test was not waiting for the > TCP server thread to actually start. That Thread.sleep + AtomicReference construct seems racy (the exception reading thread might miss it). I suggest using a synchronization aid (CountDownLatch, Phaser, Semaphore, etc.) for that. Or... since you don't do anything with the accepted socket anyway you might as well not bother with creating that thread. Once the ServerSocket has been created the connection can be established even without calling `accept`. This might simplify the code quite a lot. > Made it throw jtreg.SkippedException if TCP port is in use. We can > just hope it does not happen too often. We should probably pass the exception to the jtreg.SkippedException's constructor. Why is there timeout on L45? * @run main/timeout=60 TcpTimeout If you're optimizing for a case where the test fails, then please don't. -Pavel From pavel.rappo at oracle.com Wed Sep 4 17:11:54 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 4 Sep 2019 18:11:54 +0100 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: <87tv9sm332.fsf@oldenburg2.str.redhat.com> References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> Message-ID: > On 4 Sep 2019, at 17:35, Florian Weimer wrote: > > * Milan Mimica: > >> Continuing in a new thread with a RFR of my own: >> http://cr.openjdk.java.net/~mmimica/8228580/webrev.00/ > > I would add a comment why there's no explicit TCP connection timeout in > the code. I assume you rely on the TCP stack having its own timeout, > right? But I think it can be quite long under some circumstances. If I get this right, there's a default timeout of 1,000 ms (1 second) on L70 src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsContext.java which applies to the case where there's no explicit timeout. I agree though that this deserves a comment. > The timeout will not be enforced properly if the clock jumps backwards. Here's the link to the previous discussion: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/061918.html If you're talking about the use of System.currentTimeMillis, then I've already told Milan that we could address that later in a follow-up bug, together with the UDP case. -Pavel From huizhe.wang at oracle.com Wed Sep 4 17:30:38 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 4 Sep 2019 10:30:38 -0700 Subject: RFR [14/java.xml] 8228854: Default ErrorListener reports warnings and errors to the console Message-ID: <57588449-3314-f06e-31e6-e35deb607a33@oracle.com> Please review a patch that removes some warnings and errors printed out to the console. JBS: https://bugs.openjdk.java.net/browse/JDK-8228854 CSR: https://bugs.openjdk.java.net/browse/JDK-8228973 webrev: http://cr.openjdk.java.net/~joehw/jdk14/8228854/webrev/ Thanks, Joe From fweimer at redhat.com Wed Sep 4 17:38:56 2019 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 04 Sep 2019 19:38:56 +0200 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: (Pavel Rappo's message of "Wed, 4 Sep 2019 18:11:54 +0100") References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> Message-ID: <878sr4m05r.fsf@oldenburg2.str.redhat.com> * Pavel Rappo: >> On 4 Sep 2019, at 17:35, Florian Weimer wrote: >> >> * Milan Mimica: >> >>> Continuing in a new thread with a RFR of my own: >>> http://cr.openjdk.java.net/~mmimica/8228580/webrev.00/ >> >> I would add a comment why there's no explicit TCP connection timeout in >> the code. I assume you rely on the TCP stack having its own timeout, >> right? But I think it can be quite long under some circumstances. > > If I get this right, there's a default timeout of 1,000 ms (1 second) > on L70 > src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsContext.java > which applies to the case where there's no explicit timeout. I agree > though that this deserves a comment. Maybe I'm mistaken, but I think this: 692 Tcp(InetAddress server, int port, int timeout) throws IOException { 693 sock = new Socket(server, port); 694 sock.setTcpNoDelay(true); 695 out = new java.io.BufferedOutputStream(sock.getOutputStream()); 696 in = new java.io.BufferedInputStream(sock.getInputStream()); 697 timeoutLeft = timeout; 698 } creates the TCP socket and connects it. This is a potentially blocking operation as well. It would make sense to align the timeout for that with what typical TCP stacks do for SYN segment retransmission. Different TCP stacks have different connection timeouts, ranging from 70 to 130 seconds or even longer. So the defaults are much larger than typical DNS timeouts. (Coincidentally, I'm working on fixing the glibc stub resolver, and I've decided to use a non-blocking connect there because of the long default timeouts.) I agree on the matter of clock warp issues. UDP needs fixing too, but not in this change. Thanks, Florian From pavel.rappo at oracle.com Wed Sep 4 17:52:20 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 4 Sep 2019 18:52:20 +0100 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: <878sr4m05r.fsf@oldenburg2.str.redhat.com> References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> Message-ID: > On 4 Sep 2019, at 18:38, Florian Weimer wrote: > > > > Maybe I'm mistaken, but I think this: > > 692 Tcp(InetAddress server, int port, int timeout) throws IOException { > 693 sock = new Socket(server, port); > 694 sock.setTcpNoDelay(true); > 695 out = new java.io.BufferedOutputStream(sock.getOutputStream()); > 696 in = new java.io.BufferedInputStream(sock.getInputStream()); > 697 timeoutLeft = timeout; > 698 } > > creates the TCP socket and connects it. This is a potentially blocking > operation as well. You are right, it definitely is a blocking operation. I missed it. I was focused on 712 sock.setSoTimeout(timeoutLeft); So I'd suggest we use explicit connect with timeout java.net.Socket#connect(java.net.SocketAddress, int) Are you okay with that? From fweimer at redhat.com Wed Sep 4 17:54:44 2019 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 04 Sep 2019 19:54:44 +0200 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: (Pavel Rappo's message of "Wed, 4 Sep 2019 18:52:20 +0100") References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> Message-ID: <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> * Pavel Rappo: >> On 4 Sep 2019, at 18:38, Florian Weimer wrote: >> >> >> >> Maybe I'm mistaken, but I think this: >> >> 692 Tcp(InetAddress server, int port, int timeout) throws IOException { >> 693 sock = new Socket(server, port); >> 694 sock.setTcpNoDelay(true); >> 695 out = new java.io.BufferedOutputStream(sock.getOutputStream()); >> 696 in = new java.io.BufferedInputStream(sock.getInputStream()); >> 697 timeoutLeft = timeout; >> 698 } >> >> creates the TCP socket and connects it. This is a potentially blocking >> operation as well. > > You are right, it definitely is a blocking operation. I missed it. I was focused on > > 712 sock.setSoTimeout(timeoutLeft); > > So I'd suggest we use explicit connect with timeout > > java.net.Socket#connect(java.net.SocketAddress, int) > > Are you okay with that? Sure. You should use a larger timeout than the initial UDP timeout, though. Can you compute the maximum amount of time the UDP code would wait for reply and use that? Or is that the timeoutLeft value? Thanks, Florian From Alan.Bateman at oracle.com Wed Sep 4 18:21:53 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 4 Sep 2019 19:21:53 +0100 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> Message-ID: On 04/09/2019 18:52, Pavel Rappo wrote: > You are right, it definitely is a blocking operation. I missed it. I was focused on > > 712 sock.setSoTimeout(timeoutLeft); > > So I'd suggest we use explicit connect with timeout > > java.net.Socket#connect(java.net.SocketAddress, int) > > Are you okay with that? > Decomposing timeouts is hard to get right. In this case I think you want to specify the initial timeout to connect, then set timeoutLeft to be the remaining (will be less than "timeout"). -Alan From pavel.rappo at oracle.com Wed Sep 4 18:30:29 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 4 Sep 2019 19:30:29 +0100 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> Message-ID: > On 4 Sep 2019, at 18:54, Florian Weimer wrote: > > You should use a larger timeout than the initial UDP timeout, > though. Could you elaborate on that? From fweimer at redhat.com Wed Sep 4 18:32:55 2019 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 04 Sep 2019 20:32:55 +0200 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: (Pavel Rappo's message of "Wed, 4 Sep 2019 19:30:29 +0100") References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> Message-ID: <87sgpblxns.fsf@oldenburg2.str.redhat.com> * Pavel Rappo: >> On 4 Sep 2019, at 18:54, Florian Weimer wrote: >> >> You should use a larger timeout than the initial UDP timeout, >> though. > > Could you elaborate on that? If you use the initial UDP timeout (one second, I think), the kernel will not complete the TCP handshake if the initial SYN segment is lost because the retransmit delay during the handshake is longer than that. Thanks, Florian From andy.herrick at oracle.com Wed Sep 4 19:01:14 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 4 Sep 2019 15:01:14 -0400 Subject: jdk-14-jpackage+1-33 on jdk.java.net In-Reply-To: References: <3d92d996-eca0-7971-0716-42b885525295@oracle.com> <36feb3a6-e24c-6239-4563-cada989f20c7@oracle.com> Message-ID: This is easily reproducible by putting ampersand in --vendor value on windows. will investigate. /Andy On 9/4/2019 8:05 AM, Sverre Moe wrote: > Running WiX failed. > The problem it seems is the -dJpAppVendor. It cannot handle special > characters in the vendor name. Our company name uses the ampersand (&) > instead of "and". > > Caused by: java.io.IOException: Exec failed with code 104 command > [[C:\Program Files (x86)\WiX Toolset v3.11\bin\candle.exe, -nologo, > C:\cygwin64\tmp\jdk.jpackage1086156882119031648\config\application.wxs, > -ext, WixUtilExtension, -out, > C:\cygwin64\tmp\jdk.jpackage1086156882119031648\tmp\application.wixobj, > -dJpAppDescription=application, -dJpAppVersion=1.1.0, > -dJpWixVersion36OrNewer=yes, > -dJpProductCode=2fa37b54-8365-437d-ad34-ceed92844d22, > -dJpAppName=application, > -dJpProductUpgradeCode=53c0f7f6-75c1-419a-86c5-bef18dda408a, > -dJpIsSystemWide=yes, -dJpAppVendor=Kongsberg Defence & Aerospace, > -dJpConfigDir=C:\cygwin64\tmp\jdk.jpackage1086156882119031648\config] > in > C:\cygwin64\tmp\jdk.jpackage1086156882119031648\images\win-msi.image\application > output: > application.wxsC:\cygwin64\tmp\jdk.jpackage1086156882119031648\config\application.wxs(56) > : error CNDL0104 : Not a valid source file; detail: An error occurred > while parsing EntityName. Line 9, position 68. > > Is there anyway to allow special characters in the vendor name? > > > It would be very useful to be able to define the release, in addition > to the version. This is currently only possible on Linux with > "--linux-app-release". > > I could have hacked this by setting "--app-version" to > VERSION-RELEASE. It would increase the special logic in the build > script specific for Windows, but it does not seem to be allowed with > release in the version string:??Version string is not compatible with > MSI rules [1.1.0-SNAPSHOT20190904133731] > https://docs.microsoft.com/en-us/windows/win32/msi/productversion > > Could this potentially cause problems when installing SNAPSHOTs which > have the same version? > Anyway it does not seem WiX XML schema has any release or build > attributes. > > /Sverre > > > tor. 29. aug. 2019 kl. 17:38 skrev Sverre Moe >: > > No, have not installed WIX. Had InnoSetup from when we use > javapackager. > I will look into the WiX: https://wixtoolset.org > > /Sverre > > tor. 29. aug. 2019 kl. 17:34 skrev Kevin Rushforth > >: > > Hi Sverre, > > Do you have a WiX installed on your machine? That is a > prerequisite. > > Andy: Do we have a bug filed to produce a better error message > in this case? If not, we need to file one. > > -- Kevin > > > On 8/29/2019 7:30 AM, Sverre Moe wrote: >> It is not working creating native installer on Windows. >> >> It will not take neither exe nor msi as --package-type on >> Windows. >> jdk.jpackage.internal.PackagerException: Error: Invalid or >> unsupported package type: [exe]. >> ? ? ? ? at >> jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:614) >> ? ? ? ? at >> jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:513) >> ? ? ? ? at >> jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:97) >> ? ? ? ? at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:51) >> >> The jpackage help output on Windows lists both exe and msi as >> valid package types. >> >> The JDK-8228660 is marked as resolved. I reckon it will make >> it into the next build. >> >> /Sverre >> >> >> tor. 22. aug. 2019 kl. 02:03 skrev Kevin Rushforth >> >: >> >> We believe that we have addressed most of the issues, >> especially those >> affecting the generated Linux packages, both .deb and >> .rpm. There is one >> open issue around the naming of the Debian packages that >> we will address >> in the next EA release. See JDK-8228660 [1] for more >> information. >> >> We would love to get some feedback from Linux developers >> to make sure >> that we didn't miss anything else. >> >> Thanks. >> >> -- Kevin >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8228660 >> >> >> On 8/21/2019 3:27 PM, Andy Herrick wrote: >> > The next EA build of JPackage is available at >> > https://jdk.java.net/jpackage/ >> > >> > This build ( jdk-14-jpackage+1-33 ) (2019/8/20) is the >> next early >> > access release based on JDK-14 >> > >> > This release contains fixes to the following issues: >> > >> > JDK-8229788???? Error dialog displays with DLL issue >> when installing >> > WinChooserTest application >> > JDK-8225447???? Revise Debian packaging >> > JDK-8213941???? Debian linux problems in JavaPackager >> > JDK-8229334???? jpackage .exe packages cannot be >> executed due to >> > missing DLL >> > JDK-8227058???? Regressions related to no longer >> setting user.dir >> > JDK-8226599???? use code coverage results to remove >> dead code >> > JDK-8226191???? jpackager --license-file option broken >> on windows for >> > jdk installers. >> > JDK-8215381???? Investigate if current implementation of >> > --license-file is correct for Debian packages >> > JDK-8229138???? Add --linux-app-release option for DEB >> and RPM packages >> > JDK-8229791???? Code clean up regressions >> > JDK-8229786???? No output after WinShortcutTest.exe is >> launched >> > JDK-8229750???? Fix bad merge of JDK-8215447 patch >> > JDK-8215446 JPackageCreateInstallerInstallDirTest fails >> on OLE7 >> > JDK-8215447???? Investigate if current implementation of >> > --license-file is correct for RPM packages >> > JDK-8227172???? revert JDK-8225569 on windows >> > JDK-8224788???? jpackage fails on OS X when using >> --runtime-image >> > JDK-8229252???? Add descriptions to Windows jtreg tests >> > JDK-8228744???? file associations broken on linux. >> > JDK-8227312???? Remove pkg bundle from DMG image. >> > JDK-8228722???? jpackage RPM tests fail on some >> versions of rpmbuild >> > JDK-8222778???? Packaging Tool (JEP 343) on Linux/AArch64 >> > JDK-8224627???? Creating installer with --runtime-image >> on OS X fails >> > JDK-8226904???? current working directory wrong running >> jpackage app >> > JDK-8224486???? Arguments from jpackager cfg file not >> processed correctly >> > JDK-8226835???? Command window pops up building exe package >> > JDK-8225092???? Several jpackage tests failed when run >> with jcov enabled >> > >> > /Andy >> > >> > From andy.herrick at oracle.com Wed Sep 4 19:01:01 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 4 Sep 2019 15:01:01 -0400 Subject: jdk-14-jpackage+1-33 on jdk.java.net In-Reply-To: References: <3d92d996-eca0-7971-0716-42b885525295@oracle.com> <36feb3a6-e24c-6239-4563-cada989f20c7@oracle.com> Message-ID: <23324744-3cba-9767-e524-3f7694baaa51@oracle.com> This is easily reproducable by putting amperstand in --vendor value on windows. will investigate. /Andy On 9/4/2019 8:05 AM, Sverre Moe wrote: > Running WiX failed. > The problem it seems is the -dJpAppVendor. It cannot handle special > characters in the vendor name. Our company name uses the ampersand (&) > instead of "and". > > Caused by: java.io.IOException: Exec failed with code 104 command > [[C:\Program Files (x86)\WiX Toolset v3.11\bin\candle.exe, -nologo, > C:\cygwin64\tmp\jdk.jpackage1086156882119031648\config\application.wxs, > -ext, WixUtilExtension, -out, > C:\cygwin64\tmp\jdk.jpackage1086156882119031648\tmp\application.wixobj, > -dJpAppDescription=application, -dJpAppVersion=1.1.0, > -dJpWixVersion36OrNewer=yes, > -dJpProductCode=2fa37b54-8365-437d-ad34-ceed92844d22, > -dJpAppName=application, > -dJpProductUpgradeCode=53c0f7f6-75c1-419a-86c5-bef18dda408a, > -dJpIsSystemWide=yes, -dJpAppVendor=Kongsberg Defence & Aerospace, > -dJpConfigDir=C:\cygwin64\tmp\jdk.jpackage1086156882119031648\config] > in > C:\cygwin64\tmp\jdk.jpackage1086156882119031648\images\win-msi.image\application > output: > application.wxsC:\cygwin64\tmp\jdk.jpackage1086156882119031648\config\application.wxs(56) > : error CNDL0104 : Not a valid source file; detail: An error occurred > while parsing EntityName. Line 9, position 68. > > Is there anyway to allow special characters in the vendor name? > > > It would be very useful to be able to define the release, in addition > to the version. This is currently only possible on Linux with > "--linux-app-release". > > I could have hacked this by setting "--app-version" to > VERSION-RELEASE. It would increase the special logic in the build > script specific for Windows, but it does not seem to be allowed with > release in the version string:??Version string is not compatible with > MSI rules [1.1.0-SNAPSHOT20190904133731] > https://docs.microsoft.com/en-us/windows/win32/msi/productversion > > Could this potentially cause problems when installing SNAPSHOTs which > have the same version? > Anyway it does not seem WiX XML schema has any release or build > attributes. > > /Sverre > > > tor. 29. aug. 2019 kl. 17:38 skrev Sverre Moe >: > > No, have not installed WIX. Had InnoSetup from when we use > javapackager. > I will look into the WiX: https://wixtoolset.org > > /Sverre > > tor. 29. aug. 2019 kl. 17:34 skrev Kevin Rushforth > >: > > Hi Sverre, > > Do you have a WiX installed on your machine? That is a > prerequisite. > > Andy: Do we have a bug filed to produce a better error message > in this case? If not, we need to file one. > > -- Kevin > > > On 8/29/2019 7:30 AM, Sverre Moe wrote: >> It is not working creating native installer on Windows. >> >> It will not take neither exe nor msi as --package-type on >> Windows. >> jdk.jpackage.internal.PackagerException: Error: Invalid or >> unsupported package type: [exe]. >> ? ? ? ? at >> jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:614) >> ? ? ? ? at >> jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:513) >> ? ? ? ? at >> jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:97) >> ? ? ? ? at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:51) >> >> The jpackage help output on Windows lists both exe and msi as >> valid package types. >> >> The JDK-8228660 is marked as resolved. I reckon it will make >> it into the next build. >> >> /Sverre >> >> >> tor. 22. aug. 2019 kl. 02:03 skrev Kevin Rushforth >> >: >> >> We believe that we have addressed most of the issues, >> especially those >> affecting the generated Linux packages, both .deb and >> .rpm. There is one >> open issue around the naming of the Debian packages that >> we will address >> in the next EA release. See JDK-8228660 [1] for more >> information. >> >> We would love to get some feedback from Linux developers >> to make sure >> that we didn't miss anything else. >> >> Thanks. >> >> -- Kevin >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8228660 >> >> >> On 8/21/2019 3:27 PM, Andy Herrick wrote: >> > The next EA build of JPackage is available at >> > https://jdk.java.net/jpackage/ >> > >> > This build ( jdk-14-jpackage+1-33 ) (2019/8/20) is the >> next early >> > access release based on JDK-14 >> > >> > This release contains fixes to the following issues: >> > >> > JDK-8229788???? Error dialog displays with DLL issue >> when installing >> > WinChooserTest application >> > JDK-8225447???? Revise Debian packaging >> > JDK-8213941???? Debian linux problems in JavaPackager >> > JDK-8229334???? jpackage .exe packages cannot be >> executed due to >> > missing DLL >> > JDK-8227058???? Regressions related to no longer >> setting user.dir >> > JDK-8226599???? use code coverage results to remove >> dead code >> > JDK-8226191???? jpackager --license-file option broken >> on windows for >> > jdk installers. >> > JDK-8215381???? Investigate if current implementation of >> > --license-file is correct for Debian packages >> > JDK-8229138???? Add --linux-app-release option for DEB >> and RPM packages >> > JDK-8229791???? Code clean up regressions >> > JDK-8229786???? No output after WinShortcutTest.exe is >> launched >> > JDK-8229750???? Fix bad merge of JDK-8215447 patch >> > JDK-8215446 JPackageCreateInstallerInstallDirTest fails >> on OLE7 >> > JDK-8215447???? Investigate if current implementation of >> > --license-file is correct for RPM packages >> > JDK-8227172???? revert JDK-8225569 on windows >> > JDK-8224788???? jpackage fails on OS X when using >> --runtime-image >> > JDK-8229252???? Add descriptions to Windows jtreg tests >> > JDK-8228744???? file associations broken on linux. >> > JDK-8227312???? Remove pkg bundle from DMG image. >> > JDK-8228722???? jpackage RPM tests fail on some >> versions of rpmbuild >> > JDK-8222778???? Packaging Tool (JEP 343) on Linux/AArch64 >> > JDK-8224627???? Creating installer with --runtime-image >> on OS X fails >> > JDK-8226904???? current working directory wrong running >> jpackage app >> > JDK-8224486???? Arguments from jpackager cfg file not >> processed correctly >> > JDK-8226835???? Command window pops up building exe package >> > JDK-8225092???? Several jpackage tests failed when run >> with jcov enabled >> > >> > /Andy >> > >> > From lance.andersen at oracle.com Wed Sep 4 19:12:41 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 4 Sep 2019 15:12:41 -0400 Subject: RFR [14/java.xml] 8228854: Default ErrorListener reports warnings and errors to the console In-Reply-To: <57588449-3314-f06e-31e6-e35deb607a33@oracle.com> References: <57588449-3314-f06e-31e6-e35deb607a33@oracle.com> Message-ID: Hi Joe +1 > On Sep 4, 2019, at 1:30 PM, Joe Wang wrote: > > Please review a patch that removes some warnings and errors printed out to the console. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8228854 > > CSR: https://bugs.openjdk.java.net/browse/JDK-8228973 > > webrev: http://cr.openjdk.java.net/~joehw/jdk14/8228854/webrev/ > > Thanks, > Joe > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From andy.herrick at oracle.com Wed Sep 4 19:36:50 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 4 Sep 2019 15:36:50 -0400 Subject: RFR: JDK-8229840: Add jtreg test for --linux-app-category option In-Reply-To: <41a0e60c-2c95-4e6b-2f80-ed5c17035fc0@oracle.com> References: <39e9b825-6668-af17-c4a3-c584a6ef0647@oracle.com> <41a0e60c-2c95-4e6b-2f80-ed5c17035fc0@oracle.com> Message-ID: looks ok /Andy On 8/30/2019 5:55 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). > > - added jtreg test for --linux-app-category option; > - added jtreg test for --linux-release option; This is to address [3] > issue; > - introduced helper classes to simplify adding new jtreg tests. The > helper classes allow to avoid code duplication between platform > specific jpackage jtreg tests. They also allow to log actions taken by > tests. > Test output for package bundle creation: > --- > TRACE: assertTrue(): Check value of jpackage.test.output property > [/home/asemenyu/jpackage_tests] references a directory > TRACE: assertTrue(): Check value of jpackage.test.output property > [/home/asemenyu/jpackage_tests] references writable directory > TRACE: Bundler deb supported > TRACE: Execute > [/home/asemenyu/work/10_sandbox/64/images/jdk/bin/javac]; args(3)=[-d, > /tmp/jpackage_15808073035885342403, > /media/sf_jds/work/10_sandbox/jdk10/open/test/jdk/tools/jpackage/linux/base/../../apps/image/Hello.java]... > TRACE: Done. Exit code: 0 > TRACE: assertEquals(0): Check command > [/home/asemenyu/work/10_sandbox/64/images/jdk/bin/javac]; args(3)=[-d, > /tmp/jpackage_15808073035885342403, > /media/sf_jds/work/10_sandbox/jdk10/open/test/jdk/tools/jpackage/linux/base/../../apps/image/Hello.java] > exited with 0 code > TRACE: Execute [/home/asemenyu/work/10_sandbox/64/images/jdk/bin/jar]; > args(9)=[-c, -v, -f, /tmp/jpackage_15808073035885342403/foo.jar, -e, > Hello, -C, /tmp/jpackage_15808073035885342403, .]... > TRACE: Done. Exit code: 0 > TRACE: assertEquals(0): Check command > [/home/asemenyu/work/10_sandbox/64/images/jdk/bin/jar]; args(9)=[-c, > -v, -f, /tmp/jpackage_15808073035885342403/foo.jar, -e, Hello, -C, > /tmp/jpackage_15808073035885342403, .] exited with 0 code > TRACE: Execute > [/home/asemenyu/work/10_sandbox/64/images/jdk/bin/jpackage]; > args(14)=[--input, ./input, --output, /home/asemenyu/jpackage_tests, > --name, ReleaseTest, --package-type, deb, --linux-app-release, Rc3, > --main-jar, hello.jar, --main-class, Hello]... > TRACE: Done. Exit code: 0 > TRACE: assertEquals(0): Check command > [/home/asemenyu/work/10_sandbox/64/images/jdk/bin/jpackage]; > args(14)=[--input, ./input, --output, /home/asemenyu/jpackage_tests, > --name, ReleaseTest, --package-type, deb, --linux-app-release, Rc3, > --main-jar, hello.jar, --main-class, Hello] exited with 0 code > TRACE: Execute [dpkg]; args(1)=[--print-architecture]; redirect output > to [/tmp/jpackage_10813571496694787689.out]... > TRACE: Done. Exit code: 0 > TRACE: assertEquals(0): Check command [dpkg]; > args(1)=[--print-architecture] exited with 0 code > TRACE: assertTrue(): Check file > [/home/asemenyu/jpackage_tests/releasetest_1.0-Rc3_amd64.deb] exists > TRACE: Execute [dpkg-deb]; args(3)=[-f, > /home/asemenyu/jpackage_tests/releasetest_1.0-Rc3_amd64.deb, Version]; > redirect output to [/tmp/jpackage_17295015055550147798.out]... > TRACE: Done. Exit code: 0 > TRACE: assertEquals(0): Check command [dpkg-deb]; args(3)=[-f, > /home/asemenyu/jpackage_tests/releasetest_1.0-Rc3_amd64.deb, Version] > exited with 0 code > TRACE: assertTrue(): Check value of Version field [1.0-Rc3] ends with Rc3 > --- > > Test output for package installation verification: > --- > TRACE: assertTrue(): Check value of jpackage.test.output property > [/home/asemenyu/jpackage_tests] references a directory > TRACE: assertTrue(): Check value of jpackage.test.output property > [/home/asemenyu/jpackage_tests] references writable directory > TRACE: Bundler deb supported > TRACE: Execute [dpkg]; args(1)=[--print-architecture]; redirect output > to [/tmp/jpackage_1127921622487705754.out]... > TRACE: Done. Exit code: 0 > TRACE: assertEquals(0): Check command [dpkg]; > args(1)=[--print-architecture] exited with 0 code > TRACE: Execute [dpkg]; args(2)=[--contents, > /home/asemenyu/jpackage_tests/releasetest_1.0-Rc3_amd64.deb]; redirect > output to [/tmp/jpackage_16221854689490241666.out]... > TRACE: Done. Exit code: 0 > TRACE: assertEquals(0): Check command [dpkg]; args(2)=[--contents, > /home/asemenyu/jpackage_tests/releasetest_1.0-Rc3_amd64.deb] exited > with 0 code > TRACE: assertTrue(): Check application launcher > [/opt/releasetest/bin/ReleaseTest] is a file > TRACE: assertTrue(): Check application launcher > [/opt/releasetest/bin/ReleaseTest] can be executed > TRACE: Execute [dpkg]; args(2)=[--contents, > /home/asemenyu/jpackage_tests/releasetest_1.0-Rc3_amd64.deb]; redirect > output to [/tmp/jpackage_12615070579893278257.out]... > TRACE: Done. Exit code: 0 > TRACE: assertEquals(0): Check command [dpkg]; args(2)=[--contents, > /home/asemenyu/jpackage_tests/releasetest_1.0-Rc3_amd64.deb] exited > with 0 code > TRACE: Execute [/opt/releasetest/bin/ReleaseTest]; args(0)=[]; in > directory [.]... > TRACE: Done. Exit code: 0 > TRACE: assertEquals(0): Check command > [/opt/releasetest/bin/ReleaseTest]; args(0)=[] exited with 0 code > TRACE: assertTrue(): Check file [./appOutput.txt] exists > TRACE: assertEquals(2): Check file [./appOutput.txt] contains 2 text > lines > TRACE: assertEquals(jpackage test application): Check contents of the > first text line in [./appOutput.txt] file > TRACE: assertEquals(args.length: 0): Check contents of the second text > line in [./appOutput.txt] file > --- > > Test output for package uninstallation verification: > --- > TRACE: assertTrue(): Check value of jpackage.test.output property > [/home/asemenyu/jpackage_tests] references a directory > TRACE: assertTrue(): Check value of jpackage.test.output property > [/home/asemenyu/jpackage_tests] references writable directory > TRACE: Bundler deb supported > TRACE: Execute [dpkg]; args(1)=[--print-architecture]; redirect output > to [/tmp/jpackage_13235248864123060580.out]... > TRACE: Done. Exit code: 0 > TRACE: assertEquals(0): Check command [dpkg]; > args(1)=[--print-architecture] exited with 0 code > TRACE: Execute [dpkg]; args(2)=[--contents, > /home/asemenyu/jpackage_tests/releasetest_1.0-Rc3_amd64.deb]; redirect > output to [/tmp/jpackage_5913837318202811095.out]... > TRACE: Done. Exit code: 0 > TRACE: assertEquals(0): Check command [dpkg]; args(2)=[--contents, > /home/asemenyu/jpackage_tests/releasetest_1.0-Rc3_amd64.deb] exited > with 0 code > TRACE: assertFalse(): Check application launcher > [/opt/releasetest/bin/ReleaseTest] is not installed > TRACE: assertFalse(): Check application installation directory > [/opt/releasetest] is not available > --- > > [1] https://bugs.openjdk.java.net/browse/JDK-8229840 > > [2] http://cr.openjdk.java.net/~asemenyuk/8229840/webrev.02 > > [3] https://bugs.openjdk.java.net/browse/JDK-8229841 > > Thanks, > Alexey > From andy.herrick at oracle.com Wed Sep 4 19:40:49 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 4 Sep 2019 15:40:49 -0400 Subject: RFR: JDK-8223211: Remove old code from service support In-Reply-To: <6313f87e-f02f-dbc6-8da4-1d11c74d9cc6@oracle.com> References: <6313f87e-f02f-dbc6-8da4-1d11c74d9cc6@oracle.com> Message-ID: <4ae549ab-f92b-5498-fa06-868ce2c9d443@oracle.com> looks good. /Andy On 8/30/2019 7:44 PM, Alexander Matveev wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > 1) This file is not used and was removed. > 2) This file was removed due to JDK-8221333. > 3) Removed unused services code. > > [1] https://bugs.openjdk.java.net/browse/JDK-8223211 > > [2] http://cr.openjdk.java.net/~almatvee/8223211/webrev.00/ > > Thanks, > Alexander From alexey.semenyuk at oracle.com Wed Sep 4 19:47:09 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Wed, 4 Sep 2019 15:47:09 -0400 Subject: Comments on jpackage (JEP 343) In-Reply-To: References: <20190903185855.D9F092BEC49@eggemoggin.niobe.net> Message-ID: Hi Sverre, Thank you for your feedback. I've filed [1] bug to address Debian packaging issue. As for your question regarding release number, it is not supported by WiX on Windows. See [2]. Also product version string should follow quite strict rules [3]. However you can encode release value in the third component of product version (build number) as a workaround on condition release is a number. [1] https://bugs.openjdk.java.net/browse/JDK-8230612 [2] https://wixtoolset.org/documentation/manual/v3/xsd/wix/product.html [3] https://docs.microsoft.com/en-us/windows/win32/msi/productversion - Alexey On 9/4/2019 5:53 AM, Sverre Moe wrote: > I tired the latest build 14-jpackage+1-35 today. Good to see that debian > package file name is finally up to the specification. > > Noticed something though with building the debian package: > When using a control file from the resource directory, jpackage does not > use its version and release. > Must apply "--app-version" and "--linux-app-release" in order to get the > proper version and release on file name. > > Running dpkg-deb --show and --info has the correct version and release. > dpkg-deb --show build/deb/application_1.0-1_amd64.deb > application 1.1.0-SNAPSHOT20190904113134 > > I wonder where it gets the version 1.0 from, since my > project.version=1.1.0. The jpackage should at least use the project version > if no other version is specified. > > This is a problem only for the debian package on Linux. When building an > RPM, jpackage uses both the Version and Release defined within the spec > resource file. > > Isn't release also applicable for Windows and Mac? > What about, instead of calling it "--linux-app-release", why not simply > call it "--app-release". That would stand much better together with > "--app-version". > With "--linux-app-release" it makes it more more verbose when scripting the > build, when it needs to check for Windows and Mac in order to omit that > flag. > > /Sverre > > > tir. 3. sep. 2019 kl. 21:01 skrev : > >> I spent some time last week playing with the jpackage tool, using build >> 14-jpackage+1-35 from https://jdk.java.net/jpackage. >> >> Overall, I can see that you?ve made good progress, but there?s still some >> work to be done. I?ll start with high-level comments and questions, and >> then comment on my experience using the tool on Debian and then macOS. >> >> High-level comments/questions >> >> - It?s good that you?re publishing EA builds, but I haven?t seen very >> much feedback from those builds. It may be better to propose this as >> an experimental feature when it?s ready to target. That would give >> you the freedom to improve it incompatibly over one or two release >> cycles before you commit to a final version. >> >> - The tool still generates an image by default, rather than a package. >> This will surprise many users, especially those who just want to do >> something simple and straightforward. The least-surprising default >> behavior would be to generate a package of the type most suitable for >> the current platform. An option to generate just an image would be >> fine, for those who want to tweak it before the actual packaging >> step, but that shouldn?t be the default. >> >> - Related to the previous point, I should only have to specify the >> `--package-type` option if I want something other than the default >> for the current platform. >> >> - The tool assumes that the application being packaged will have a GUI. >> This isn?t surprising, considering its heritage, but as a consequence >> it always produces packages that perform GUI-specific actions, such >> as installing icons and desktop-menu entries. If I?m just packaging >> a command-line tool then these are unnecessary, and supporting them >> can pull in lots of additional dependencies (e.g., a ton of Perl >> scripts on Debian). Consider adding an option (`--gui`?) so that >> the user can indicate when an application is to be installed for >> graphical use. >> >> - The `--output`/`-o` option is confusing. It doesn?t name the output >> itself, but rather a directory into which the single item of output >> will be placed. Typing `-o .` all the time is just annoying. It?d >> be more logical to rename this option to `--dest`/`-d` and to make it >> optional, with a default value of `.`. >> >> - If my app is modular, and my main module has a version string, then >> it?d be nice for that to be used as the package version unless a >> specific version is specified on the command line. >> >> - Terminology: For Linux we generally speak of ?packages? rather than >> ?bundles.? Rename `--linux-bundle-name` to `--linux-package-name`. >> >> - The `--temp-root` option could be shortened to `--temp`. >> >> - Periods at the ends of error messages are unsightly and unnecessary. >> We don?t use them in other JDK tools. Please remove them. >> >> - It?d be nice to have an option that displays the programs being run >> by the tool, in a form that can easily be cut-and-pasted into a >> script for those who need to do a lot of customization. The current >> verbose output shows (at least some of) this information, but in a >> difficult-to-use format. >> >> - What?s the rationale for copying the entire ?input? directory as-is? >> Why is its structure important? Couldn?t you just as well limit this >> to a single directory full of JAR files? >> >> Comments on Debian packaging >> >> - On a Debian machine I tried to create a package for a trivial, >> two-module application using the command >> >> $ jpackage -o . --package-type deb -p lib -m org.openjdk.hello -n >> hello >> >> which gave me the error message >> >> Bundler DEB Installer skipped because of a configuration problem: >> java.lang.NullPointerException. >> >> (Side note: This message is confusing since the tool is creating a >> Debian package, not an ?installer.?) >> >> - On a hunch, I specified a main application class: >> >> $ jpackage -o . --package-type deb -p lib -m >> org.openjdk.hello/org.openjdk.hello.Main -n hello >> >> and that created `hello_1.0-1_amd64.deb`. It shouldn?t have been >> necessary to specify a main class since the main module does have a >> `ModuleMainClass` attribute in its module descriptor. >> >> - The resulting package does not depend upon any others, i.e., the >> `Depends:` line in its control file is empty. This can?t possibly be >> right, since the embedded JDK depends on many system libraries for >> proper operation (`libc`, `libfreetype`, `libpthread`, etc.). >> >> - The resulting package would install into `/opt/hello`, as expected, >> but the `/opt/hello/bin` directory would contain not just the `hello` >> application launcher but also `hello.desktop`, `hello.png`, and >> `libapplauncher.so`. These aren?t appropriate for a `bin` directory >> and should be placed elsewhere, most likely `/opt/hello/lib`. >> >> - The resulting package would install `/opt/hello/app` and >> `/opt/hello/runtime` directories. These are not strictly forbidden >> by the Linux FHS [1], but it?d be better to put both of them under >> `/opt/hello/lib`, per convention. >> >> - The resulting package does not contain the normal `java` launcher. >> It?d be helpful to retain this (in `runtime/bin/java`, not in the >> app?s `bin` directory) for diagnostic purposes. It?s not large. >> >> - The resulting package would install the copyright file into >> `/usr/share/doc/hello/copyright`, which is wrong -- a package that >> installs into `/opt` should never touch anything under /usr [1]. This >> file should be at `/opt/hello/share/doc/copyright`. >> >> - I attempted to install the package on a fresh Ubuntu 18.04 machine: >> >> # dpkg -i hello-1.0.deb >> Selecting previously unselected package hello. >> (Reading database ... 135670 files and directories currently >> installed.) >> Preparing to unpack hello-1.0.deb ... >> Unpacking hello (1.0) ... >> Setting up hello (1.0) ... >> Adding shortcut to the menu >> /var/lib/dpkg/info/hello.postinst: 25: >> /var/lib/dpkg/info/hello.postinst: xdg-desktop-menu: not found >> dpkg: error processing package hello (--install): >> installed hello package post-installation script subprocess >> returned error exit status 127 >> Errors were encountered while processing: >> hello >> mr-dev # uname -a >> Linux mr-dev 4.15.0-1018-oracle #20-Ubuntu SMP Wed Jul 3 06:46:12 >> UTC 2019 x86_64 x86_64 x86_64 GNU/Linux >> mr-dev # cat /etc/lsb-release >> DISTRIB_ID=Ubuntu >> DISTRIB_RELEASE=18.04 >> DISTRIB_CODENAME=bionic >> DISTRIB_DESCRIPTION="Ubuntu 18.04.3 LTS" >> # >> >> Apparently the package should depend upon `xdg-utils`, so that its >> post-install script can find `xdg-desktop-menu`. Even better, >> though, would be for this trivial non-graphical application not to >> depend upon any desktop utilities, per my comment above. >> >> - Installing the package succeeded despite the above error. I was >> successfully able to run my trivial application. Yay! >> >> - Then I tried to uninstall it: >> >> mr-dev # dpkg --remove hello >> (Reading database ... 135923 files and directories currently >> installed.) >> Removing hello (1.0) ... >> Removing shortcut >> /var/lib/dpkg/info/hello.prerm: 25: >> /var/lib/dpkg/info/hello.prerm: xdg-desktop-menu: not found >> dpkg: error processing package hello (--remove): >> installed hello package pre-removal script subprocess returned >> error exit status 127 >> Errors were encountered while processing: >> hello >> mr-dev # >> >> I installed `xdg-utils` by hand to get `xdg-desktop-menu`, but it still >> didn?t work: >> >> mr-dev # dpkg --remove hello >> (Reading database ... 136878 files and directories currently >> installed.) >> Removing hello (1.0) ... >> Removing shortcut >> xdg-desktop-menu: No writable system menu directory found. >> dpkg: error processing package hello (--remove): >> installed hello package pre-removal script subprocess returned >> error exit status 3 >> Errors were encountered while processing: >> hello >> mr-dev # >> >> I eventually figured out how to create a fake writable system menu >> directory and was then able to remove the package. >> >> - The `--linux-deb-copyright` option is confusing. Its description >> should mention that if this option is specified then the `--license` >> option is, so far as I can tell, ignored. >> >> - The `--identifier` option appears to have no use for Debian packages. >> Perhaps this option should be package-type specific? Or at least its >> description should mention that it?s irrelevant to Debian packages. >> >> - I tried to create a package that would install into the `/usr` >> hierarchy by adding `--install-dir /usr` to the above command line. >> The resulting package would create a `/usr/hello` directory, with >> `app`, `bin`, and `runtime` directories under that. That?s not >> right. To install an application in the `/usr` hierarchy its command >> should go into `/usr/bin`, and libraries and other files should go >> into `/usr/lib/$APPNAME`, and documentation and copyright files >> should go into `/usr/share/doc/$APPNAME`. >> >> - Many of the above observations could also apply to RPM packages, but >> I haven?t checked. >> >> Comments on macOS packaging >> >> (Warning: I?m not an expert macOS developer!) >> >> - On a macOS machine (10.13.6) I tried to create a dmg package: >> >> $ jpackage -o . --package-type dmg -p lib -m >> org.openjdk.hello/org.openjdk.hello.Main -n hello >> >> which gave me the error message >> >> Exec failed with code 1 command [[/usr/bin/SetFile, -c, icnC, >> /var/folders/mn/8nt00ldx7dqfrv55wk72mgq80000gr/T/jdk.jpackage9024163201922289964/images/hello/.VolumeIcon.icns] >> in unspecified directory output: xcrun: error: invalid active developer >> path (/Library/Developer/CommandLineTools), missing xcrun at: >> /Library/Developer/CommandLineTools/usr/bin/xcrun >> >> although it exited with status 0 and did produce a valid `.dmg` file. >> I suppose I?m missing some development tools? If so then please >> document that dependency, and if possible issue a more helpful error >> message that tells the user what they need to install. >> >> - It?d be nice if the resulting `.dmg` file, when opened, were to show >> an icon for the Applications folder and an arrow pointing to that >> from the app icon, so that the user can drag it across. Almost all >> `.dmg` files that I?ve seen do this. >> >> - Mark >> >> >> [1] >> https://www.debian.org/doc/packaging-manuals/fhs/fhs-3.0.html#optAddonApplicationSoftwarePackages >> From Roger.Riggs at oracle.com Wed Sep 4 20:54:41 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 4 Sep 2019 16:54:41 -0400 Subject: [14] RFR: 8229831: Upgrade Character.isUnicodeIdentifierStart/Part() methods to the latest standard In-Reply-To: <13d9f962-9cef-afca-3bdf-eaa93fe6721a@oracle.com> References: <13d9f962-9cef-afca-3bdf-eaa93fe6721a@oracle.com> Message-ID: <5e09f1f2-ef85-8adc-0240-25f03136d6b8@oracle.com> Hi Naoto, The CSR looks ok. In Character.java: In the descriptions mentioning VERTICAL TILDE, I would drop the word "solely". for example, * {@code 'VERTICAL TILDE'} is added to {@code Start} for backward * compatibility. Overall looks like a good update. Roger On 8/29/19 3:42 PM, naoto.sato at oracle.com wrote: > Hi, > > Please review the proposed modifications to the methods in > java.lang.Character class. The CSR is located here: > > https://bugs.openjdk.java.net/browse/JDK-8230188 > > It mainly intends to clarify the spec of the Unicode Identifier > methods, by supplying the corresponding Unicode Standard Annex #31 > explanations. Also, it intends to upgrade the current implementation > to the latest 12.0 level. Here is the proposed implementation changes: > > https://cr.openjdk.java.net/~naoto/8229831/webrev.00/ > > The CSR is intentionally left as draft so that I can gather/reflect > opinions from this list. > > Naoto From naoto.sato at oracle.com Wed Sep 4 21:10:47 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 4 Sep 2019 14:10:47 -0700 Subject: [14] RFR: 8229831: Upgrade Character.isUnicodeIdentifierStart/Part() methods to the latest standard In-Reply-To: <5e09f1f2-ef85-8adc-0240-25f03136d6b8@oracle.com> References: <13d9f962-9cef-afca-3bdf-eaa93fe6721a@oracle.com> <5e09f1f2-ef85-8adc-0240-25f03136d6b8@oracle.com> Message-ID: <077b6bfb-50c4-1273-2bae-a568c2a277d2@oracle.com> Thanks, Roger. I will drop all occurrences of "solely" and finalize the CSR. Naoto On 9/4/19 1:54 PM, Roger Riggs wrote: > Hi Naoto, > > The CSR looks ok. > > In Character.java: > > In the descriptions mentioning VERTICAL TILDE, I would drop the word > "solely". > for example, > > * {@code 'VERTICAL TILDE'} is added to {@code Start} for backward > * compatibility. > > Overall looks like a good update. > > Roger > > > > > On 8/29/19 3:42 PM, naoto.sato at oracle.com wrote: >> Hi, >> >> Please review the proposed modifications to the methods in >> java.lang.Character class. The CSR is located here: >> >> https://bugs.openjdk.java.net/browse/JDK-8230188 >> >> It mainly intends to clarify the spec of the Unicode Identifier >> methods, by supplying the corresponding Unicode Standard Annex #31 >> explanations. Also, it intends to upgrade the current implementation >> to the latest 12.0 level. Here is the proposed implementation changes: >> >> https://cr.openjdk.java.net/~naoto/8229831/webrev.00/ >> >> The CSR is intentionally left as draft so that I can gather/reflect >> opinions from this list. >> >> Naoto > From brent.christian at oracle.com Wed Sep 4 21:12:25 2019 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 4 Sep 2019 14:12:25 -0700 Subject: RFR: 8212117 : Class.forName may return a reference to a loaded but not linked Class Message-ID: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com> Hi, Please review my fix for JDK-8212117[1]. The webrev is here: http://cr.openjdk.java.net/~bchristi/8212117/webrev09/ There is also a CSR[2] in need of review. The spec for the 2-arg and 3-arg Class.forName() methods states they will "locate, load, and link" the class, however the linking part is not ensured to happen. Although the VM spec allows flexibility WRT when classes are linked, this is a corner where the Class.forName() spec is not being upheld. While this is not an issue for most usages, 8181144 [3] demonstrates how this can be a problem (with the debugging interface, in this case). This fix ensures that linking happens during the course of Class.forName(). Class.forName() already @throws LinkageError, so no spec change is needed there. MethodHandles.Lookup.findClass() needs a small spec update, due to calling Class.forName with init=false, Of course Errors are not required to be caught. It is therefore possible that the new behavior could introduce previously unseen, possibly unhandled LinkageErrors. A new VM flag (-XX:+ClassForNameDeferLinking) is introduced to restore the previous behavior (to keep such code running until it can be updated). This change surfaced a couple new "A JNI error has occurred" situations (see 8181033[5]) in the Launcher, by way of test/jdk/tools/launcher/MainClassCantBeLoadedTest.java (using the 3-arg Class::forName, detailed in the bug report[4]), and test/jdk/tools/launcher/modules/basic/LauncherErrors.java (using the 2-arg Class::forName). The Launcher is updated to maintain non-confusing error messages :). The new test included with this fix ensures that 8181144[3] is addressed. Thanks go to Serguei Spitsyn for writing the test. Automated corelibs and hotspot tests pass cleanly. Thanks, -Brent -- 1. https://bugs.openjdk.java.net/browse/JDK-8212117 2. https://bugs.openjdk.java.net/browse/JDK-8222071 3. https://bugs.openjdk.java.net/browse/JDK-8181144 4. https://bugs.openjdk.java.net/browse/JDK-8212117?focusedCommentId=14215986&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14215986 5. https://bugs.openjdk.java.net/browse/JDK-8181033 From huizhe.wang at oracle.com Wed Sep 4 21:47:52 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 4 Sep 2019 14:47:52 -0700 Subject: RFR [14/java.xml] 8228854: Default ErrorListener reports warnings and errors to the console In-Reply-To: References: <57588449-3314-f06e-31e6-e35deb607a33@oracle.com> Message-ID: Thanks Lance!? I did a re-run of all tests and they all passed. -Joe On 9/4/19 12:12 PM, Lance Andersen wrote: > Hi Joe > > +1 >> On Sep 4, 2019, at 1:30 PM, Joe Wang > > wrote: >> >> Please review a patch that removes some warnings and errors printed >> out to the console. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8228854 >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8228973 >> >> webrev: http://cr.openjdk.java.net/~joehw/jdk14/8228854/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 daniel.daugherty at oracle.com Wed Sep 4 22:06:37 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 4 Sep 2019 18:06:37 -0400 Subject: RFR: 8212117 : Class.forName may return a reference to a loaded but not linked Class In-Reply-To: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com> References: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com> Message-ID: <4411374a-0d04-2a65-230f-d0875a981c15@oracle.com> Brent, You currently have '-XX:+ClassForNameDeferLinking' as a 'product' option, but product options are harder to remove down the road. Would it be better as a diagnostic option? A diagnostic option requires '-XX:+UnlockDiagnosticVMOptions' to be specified before it can be used, e.g.: ??? java -XX:+UnlockDiagnosticVMOptions -XX:+ClassForNameDeferLinking Foo so it is a bit harder to use, but maybe that's a Good Thing (TM). Dan On 9/4/19 5:12 PM, Brent Christian wrote: > Hi, > > Please review my fix for JDK-8212117[1].? The webrev is here: > > http://cr.openjdk.java.net/~bchristi/8212117/webrev09/ > > There is also a CSR[2] in need of review. > > The spec for the 2-arg and 3-arg Class.forName() methods states they > will "locate, load, and link" the class, however the linking part is > not ensured to happen. > > Although the VM spec allows flexibility WRT when classes are linked, > this is a corner where the Class.forName() spec is not being upheld. > While this is not an issue for most usages,? 8181144 [3] demonstrates > how this can be a problem (with the debugging interface, in this case). > > This fix ensures that linking happens during the course of > Class.forName().? Class.forName() already @throws LinkageError, so no > spec change is needed there. MethodHandles.Lookup.findClass() needs a > small spec update, due to calling Class.forName with init=false, > > Of course Errors are not required to be caught.? It is therefore > possible that the new behavior could introduce previously unseen, > possibly unhandled LinkageErrors.? A new VM flag > (-XX:+ClassForNameDeferLinking) is introduced to restore the previous > behavior (to keep such code running until it can be updated). > > This change surfaced a couple new "A JNI error has occurred" > situations (see 8181033[5]) in the Launcher, by way of > ? test/jdk/tools/launcher/MainClassCantBeLoadedTest.java > (using the 3-arg Class::forName, detailed in the bug report[4]), > and > ? test/jdk/tools/launcher/modules/basic/LauncherErrors.java > (using the 2-arg Class::forName). > > The Launcher is updated to maintain non-confusing error messages :). > > The new test included with this fix ensures that 8181144[3] is > addressed.? Thanks go to Serguei Spitsyn for writing the test. > > Automated corelibs and hotspot tests pass cleanly. > > Thanks, > -Brent > > -- > 1. https://bugs.openjdk.java.net/browse/JDK-8212117 > > 2. https://bugs.openjdk.java.net/browse/JDK-8222071 > > 3. https://bugs.openjdk.java.net/browse/JDK-8181144 > > 4. > https://bugs.openjdk.java.net/browse/JDK-8212117?focusedCommentId=14215986&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14215986 > > 5. https://bugs.openjdk.java.net/browse/JDK-8181033 > From brian.burkhalter at oracle.com Wed Sep 4 23:07:57 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 4 Sep 2019 16:07:57 -0700 Subject: 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: <843eeca6-e540-1c8f-1f64-d1fa6319dc48@oracle.com> References: <86A0C35F-93C1-4F45-8723-72B723024B39@oracle.com> <2d6a465b-8f1d-6365-42f7-446381197474@oracle.com> <71C745EA-D0C0-44FE-BBF8-0F9119078AD5@oracle.com> <714892D5-194F-4856-95F1-E38C6D7FF714@oracle.com> <91BF9F6F-5969-40AF-8E51-92D5E045F6D9@oracle.com> <532398EA-B7F8-4803-A038-A0F54DCD460F@oracle.com> <426428C0-F710-4262-9E5A-247D0D267059@oracle.com> <3B543968-6426-4FDC-AF27-D3962BA4814E@oracle.com> <8b8eea87-8b5d-8561-7058-633184ce8976@oracle.com> <533DF576-7B8B-4BC7-BB09-50609116AA56@oracle.com> <064ec92d-7e6d-b499-be9f-7578a1a5fb39@oracle.com> <4f71aae6-8250-67aa-c4ee-d206037af50e@oracle.com> <843eeca6-e540-1c8f-1f64-d1fa6319dc48@oracle.com> Message-ID: <1D4646EF-F49E-4300-8AC4-8DDEFC50EF9E@oracle.com> > On Aug 31, 2019, at 12:28 AM, Alan Bateman wrote: > > On 13/08/2019 22:28, Brian Burkhalter wrote: >> Reprising discussion of [1] from last month. I updated the patch [2] which now hopefully accounts for the various comments. Specifically the specification of the PrintStream.write(byte[]) override was clarified as follows: >> >> > I think the spec in the override and the new writeBytes method in webrev-alt.04 look okay. I assume you'll submit a CSR to track this change. Yes, done [1]. I wanted to get the code review over first. Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8230625 From ivan.gerasimov at oracle.com Thu Sep 5 01:49:41 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 4 Sep 2019 18:49:41 -0700 Subject: RFR 8230365 : Pattern for a control-char matches non-control characters In-Reply-To: References: <4f81d7bb-3e2b-337a-2f53-a4bc71049d62@oracle.com> <98993cd0-27f8-cda4-ce3b-52d21564a246@oracle.com> Message-ID: Thank you Martin! On 8/30/19 6:19 PM, Martin Buchholz wrote: > There's a strong expectation that ctrl-A and ctrl-a both map to > \u0001, so I support Ivan's initiative. > I'm surprised java regex gets this wrong. > Might need a transitional system property. > Right.? I think it would be best to introduce two system properties: The first, to turn on/off the restrictions on the control-char names.? This will be enabled by default, and will permit names from the limited list: capital letters and a few other special characters. The second one, to enable mapping of lower-case control-char names to their upper-case counterpart.? This option should be turned off by default for the current release of JDK, and then turned on by default for some subsequent release (when, presumably, most applications that use this kind of regexp are fixed). This all feels like a little bit too much for such a rarely used feature, but probably is a proper thing to do anyway :-) If we have an agreement on these system properties, I can create a separate test to verify all possible combinations. > What's the best bit-twiddle?? Untested: > if ((c ^= 0x40) < 0x20) return c; > if ((c ^=0x20)? <= 26 && c > 0) return c; > > 0x40 is more readable than 64. > `((ch-0x3f)|(0x5f-ch)) >= 0` does the trick for regular (non-lower-case) ids. > Does ctrol-? get mapped to 0x7f ? > Yes. I've got it in the test at the end of the line 4997. Would you please help review the updated webrev: http://cr.openjdk.java.net/~igerasim/8230365/02/webrev/ With kind regards, Ivan From martinrb at google.com Thu Sep 5 04:00:44 2019 From: martinrb at google.com (Martin Buchholz) Date: Wed, 4 Sep 2019 21:00:44 -0700 Subject: RFR 8230365 : Pattern for a control-char matches non-control characters In-Reply-To: References: <4f81d7bb-3e2b-337a-2f53-a4bc71049d62@oracle.com> <98993cd0-27f8-cda4-ce3b-52d21564a246@oracle.com> Message-ID: Thanks, Ivan. We're mostly in agreement. + * If {@code true} then lower-case control-character ids are mapped to the + * their upper-case counterparts. Extra "the". After all these decades I only now realize that c ^= 0x40 moves '?' to the end of the ASCII range and all the other controls to the start! Should we support lower-case controls? Compatibility with perl regex still matters, but a lot less than in 2003. But the key is that we got the WRONG ANSWER previously, so when we restrict the control ids let's just make lower case controls syntax errors. Silently changing behavior is bad for users. ... so let's abandon ALLOW_LOWERCASE_CONTROL_CHAR_IDS. An alternative: int ch = read() ^ 0x40; if (!RESTRICTED_CONTROL_CHAR_IDS || ch < 0x20 || ch == 0x7f) return ch; On Wed, Sep 4, 2019 at 6:49 PM Ivan Gerasimov wrote: > Thank you Martin! > > On 8/30/19 6:19 PM, Martin Buchholz wrote: > > There's a strong expectation that ctrl-A and ctrl-a both map to > > \u0001, so I support Ivan's initiative. > > I'm surprised java regex gets this wrong. > > Might need a transitional system property. > > > Right. I think it would be best to introduce two system properties: > > The first, to turn on/off the restrictions on the control-char names. > This will be enabled by default, and will permit names from the limited > list: capital letters and a few other special characters. > > The second one, to enable mapping of lower-case control-char names to > their upper-case counterpart. This option should be turned off by > default for the current release of JDK, and then turned on by default > for some subsequent release (when, presumably, most applications that > use this kind of regexp are fixed). > > This all feels like a little bit too much for such a rarely used > feature, but probably is a proper thing to do anyway :-) > > If we have an agreement on these system properties, I can create a > separate test to verify all possible combinations. > > > > What's the best bit-twiddle? Untested: > > if ((c ^= 0x40) < 0x20) return c; > > if ((c ^=0x20) <= 26 && c > 0) return c; > > > > 0x40 is more readable than 64. > > > `((ch-0x3f)|(0x5f-ch)) >= 0` does the trick for regular (non-lower-case) > ids. > > > Does ctrol-? get mapped to 0x7f ? > > > Yes. I've got it in the test at the end of the line 4997. > > Would you please help review the updated webrev: > > http://cr.openjdk.java.net/~igerasim/8230365/02/webrev/ > > With kind regards, > > Ivan > > > From 2217232293 at qq.com Thu Sep 5 05:31:30 2019 From: 2217232293 at qq.com (=?gb18030?B?zrTAtNH0ueI=?=) Date: Thu, 5 Sep 2019 13:31:30 +0800 Subject: contribute to core-lib module Message-ID: Hi, leaders. A few days ago, I report a bug in core lib[1]. According to the contribute document[2], I had send oca to oracle and my name has been listed on oca[3]. But I still can't push my changes to jdk, can someone tell me how to do next? thanks very match!! [1]https://bugs.openjdk.java.net/browse/JDK-8230557 [2]http://openjdk.java.net/contribute/ [3]https://www.oracle.com/technetwork/community/oca-486395.html From 2217232293 at qq.com Thu Sep 5 05:35:07 2019 From: 2217232293 at qq.com (=?utf-8?B?5pyq5p2l6Ziz5YWJ?=) Date: Thu, 5 Sep 2019 13:35:07 +0800 Subject: what to do next to fix JDK-8230557. thanks Message-ID: Hi, leaders. A few days ago, I report a bug in core lib[1]. According to the contribute document[2], I had send oca to oracle and my name has been listed on oca[3]. But I still can't push my changes to jdk, can someone tell me how to do next? thanks very match!! [1]https://bugs.openjdk.java.net/browse/JDK-8230557 [2]http://openjdk.java.net/contribute/ [3]https://www.oracle.com/technetwork/community/oca-486395.html ------------------ ???? ------------------ ???: "Bug Report Notification" References: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com> <4411374a-0d04-2a65-230f-d0875a981c15@oracle.com> Message-ID: Hi Dan, With my CSR Group member hat on .... On 5/09/2019 8:06 am, Daniel D. Daugherty wrote: > Brent, > > You currently have '-XX:+ClassForNameDeferLinking' as a 'product' > option, but > product options are harder to remove down the road. Would it be better as a > diagnostic option? A diagnostic option requires Whether a flag is product or diagnostic (or experimental) should be a basic property of the flag based on its purpose. I would not want to see a trend of making new flags diagnostic just because it is easier to get rid of them later. The expectation with this fix and flag (which I've been heavily involved in) is that production code may be impacted by the change and need to use the flag to restore previous behaviour. So it really is a product flag that end users should be comfortable in using if they need it. The removal process for a product flag is phased (deprecate, obsolete, expire) but not particularly onerous. There is an expectation that this flag may be deprecated in 15 as it is intended as a transitional flag. Thanks, David ----- > '-XX:+UnlockDiagnosticVMOptions' > to be specified before it can be used, e.g.: > > ??? java -XX:+UnlockDiagnosticVMOptions -XX:+ClassForNameDeferLinking Foo > > so it is a bit harder to use, but maybe that's a Good Thing (TM). > > Dan > > > On 9/4/19 5:12 PM, Brent Christian wrote: >> Hi, >> >> Please review my fix for JDK-8212117[1].? The webrev is here: >> >> http://cr.openjdk.java.net/~bchristi/8212117/webrev09/ >> >> There is also a CSR[2] in need of review. >> >> The spec for the 2-arg and 3-arg Class.forName() methods states they >> will "locate, load, and link" the class, however the linking part is >> not ensured to happen. >> >> Although the VM spec allows flexibility WRT when classes are linked, >> this is a corner where the Class.forName() spec is not being upheld. >> While this is not an issue for most usages,? 8181144 [3] demonstrates >> how this can be a problem (with the debugging interface, in this case). >> >> This fix ensures that linking happens during the course of >> Class.forName().? Class.forName() already @throws LinkageError, so no >> spec change is needed there. MethodHandles.Lookup.findClass() needs a >> small spec update, due to calling Class.forName with init=false, >> >> Of course Errors are not required to be caught.? It is therefore >> possible that the new behavior could introduce previously unseen, >> possibly unhandled LinkageErrors.? A new VM flag >> (-XX:+ClassForNameDeferLinking) is introduced to restore the previous >> behavior (to keep such code running until it can be updated). >> >> This change surfaced a couple new "A JNI error has occurred" >> situations (see 8181033[5]) in the Launcher, by way of >> ? test/jdk/tools/launcher/MainClassCantBeLoadedTest.java >> (using the 3-arg Class::forName, detailed in the bug report[4]), >> and >> ? test/jdk/tools/launcher/modules/basic/LauncherErrors.java >> (using the 2-arg Class::forName). >> >> The Launcher is updated to maintain non-confusing error messages :). >> >> The new test included with this fix ensures that 8181144[3] is >> addressed.? Thanks go to Serguei Spitsyn for writing the test. >> >> Automated corelibs and hotspot tests pass cleanly. >> >> Thanks, >> -Brent >> >> -- >> 1. https://bugs.openjdk.java.net/browse/JDK-8212117 >> >> 2. https://bugs.openjdk.java.net/browse/JDK-8222071 >> >> 3. https://bugs.openjdk.java.net/browse/JDK-8181144 >> >> 4. >> https://bugs.openjdk.java.net/browse/JDK-8212117?focusedCommentId=14215986&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14215986 >> >> >> 5. https://bugs.openjdk.java.net/browse/JDK-8181033 >> > From david.holmes at oracle.com Thu Sep 5 05:44:01 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 5 Sep 2019 15:44:01 +1000 Subject: what to do next to fix JDK-8230557. thanks In-Reply-To: References: Message-ID: On 5/09/2019 3:35 pm, ???? wrote: > Hi, leaders. Hi, No "leaders" here only developers :) > > A few days ago, I report a bug in core lib[1]. According to the contribute document[2], I had send oca to oracle and my name has been listed on oca[3]. Welcome aboard! > But I still can't push my changes to jdk, can someone tell me how to do next? thanks very match!! You can't push anything until you become a Committer and before that you have to become an Author. The steps for contributing are outlined here: http://openjdk.java.net/contribute/ and you would seem to be up to step 2. :) Cheers, David > > > > > [1]https://bugs.openjdk.java.net/browse/JDK-8230557 > > [2]http://openjdk.java.net/contribute/ > [3]https://www.oracle.com/technetwork/community/oca-486395.html > > > > > > ------------------ ???? ------------------ > ???: "Bug Report Notification" ????: 2019?9?5?(???) ??3:33 > ???: "????"<2217232293 at qq.com>; > > ??: Update Notification: Bug Report - JDK-8230557 > > > > [This is an automated response. Please do not reply.] > Dear Java Developer, > We have finished evaluating your report and have assigned it a Bug ID: JDK-8230557. The issue is visible on bugs.java.com at the following url JDK-8230557. > To provide more information about this issue, click here. > We work to resolve the issues that are submitted to us according to their impact to the community as a whole, and make no promises as to the time or release in which a bug might be fixed. If this issue has a significant impact on your project you may want to consider using one of the technical support offerings available at Oracle Support. > Regards, > Java Developer Support > > > > > > Java SE > Java SE Documentation > Java SE Downloads > Java Developer Forums > Oracle Java SE Advanced > Bug Database > Copyright ? Oracle and/or its affiliates. All rights reserved. > Terms of Use | Privacy > From 2217232293 at qq.com Thu Sep 5 05:46:54 2019 From: 2217232293 at qq.com (=?utf-8?B?5pyq5p2l6Ziz5YWJ?=) Date: Thu, 5 Sep 2019 13:46:54 +0800 Subject: =?utf-8?B?5Zue5aSN77yaIHdoYXQgdG8gZG8gbmV4dCB0byBm?= =?utf-8?B?aXggSkRLLTgyMzA1NTcuIHRoYW5rcw==?= In-Reply-To: References: Message-ID: hi, developers. Can someone help me? thanks very much !! ------------------ ???? ------------------ ???: "David Holmes" References: <4f81d7bb-3e2b-337a-2f53-a4bc71049d62@oracle.com> <98993cd0-27f8-cda4-ce3b-52d21564a246@oracle.com> , Message-ID: Hallo, Since not all combinations make sense (Exception+convert) a multi value might be better: jdk.regex.control=WARN|EXCEPTION|STANDARD|LEGACY With Exception generating an error, Standard beeing the planned new default (treating upper/lower same and error on all undefined chars) and legacy beeing the manual fallback to current behavior and WARN the same fallback but with logging. I guess some form of early feedback like EXCPETION or WARN is needed, even when it is between a rock and a hard place. Maybe have at least one iteration where it defaults to LEGACY (+Release Notes announcement), then WARN and then finally STANDARD? Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev im Auftrag von Ivan Gerasimov Gesendet: Donnerstag, September 5, 2019 4:00 AM An: Martin Buchholz; Stuart Marks Cc: core-libs-dev Betreff: Re: RFR 8230365 : Pattern for a control-char matches non-control characters Thank you Martin! On 8/30/19 6:19 PM, Martin Buchholz wrote: > There's a strong expectation that ctrl-A and ctrl-a both map to > \u0001, so I support Ivan's initiative. > I'm surprised java regex gets this wrong. > Might need a transitional system property. > Right. I think it would be best to introduce two system properties: The first, to turn on/off the restrictions on the control-char names. This will be enabled by default, and will permit names from the limited list: capital letters and a few other special characters. The second one, to enable mapping of lower-case control-char names to their upper-case counterpart. This option should be turned off by default for the current release of JDK, and then turned on by default for some subsequent release (when, presumably, most applications that use this kind of regexp are fixed). This all feels like a little bit too much for such a rarely used feature, but probably is a proper thing to do anyway :-) If we have an agreement on these system properties, I can create a separate test to verify all possible combinations. > What's the best bit-twiddle? Untested: > if ((c ^= 0x40) < 0x20) return c; > if ((c ^=0x20) <= 26 && c > 0) return c; > > 0x40 is more readable than 64. > `((ch-0x3f)|(0x5f-ch)) >= 0` does the trick for regular (non-lower-case) ids. > Does ctrol-? get mapped to 0x7f ? > Yes. I've got it in the test at the end of the line 4997. Would you please help review the updated webrev: http://cr.openjdk.java.net/~igerasim/8230365/02/webrev/ With kind regards, Ivan From david.holmes at oracle.com Thu Sep 5 05:58:23 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 5 Sep 2019 15:58:23 +1000 Subject: contribute to core-lib module In-Reply-To: References: Message-ID: Hi, I responded to your other email. David On 5/09/2019 3:31 pm, ???? wrote: > Hi, leaders. > > > A few days ago, I report a bug in core lib[1]. According to the contribute document[2], I had send oca to oracle and my name has been listed on oca[3]. > But I still can't push my changes to jdk, can someone tell me how to do next? thanks very match!! > > > > > > [1]https://bugs.openjdk.java.net/browse/JDK-8230557 > > [2]http://openjdk.java.net/contribute/ > [3]https://www.oracle.com/technetwork/community/oca-486395.html > From david.holmes at oracle.com Thu Sep 5 06:00:00 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 5 Sep 2019 16:00:00 +1000 Subject: =?UTF-8?B?UmU6IOWbnuWkje+8miB3aGF0IHRvIGRvIG5leHQgdG8gZml4IEpESy04?= =?UTF-8?Q?230557=2e_thanks?= In-Reply-To: References: Message-ID: <1331cc4f-964b-ab27-4e48-4cb102b5e964@oracle.com> On 5/09/2019 3:46 pm, ???? wrote: > > hi, developers. > > Can someone help me? thanks very much !! Help you how exactly. As I stated your are up to step 2 of the how to contribute process. If you have a suggested fix for the bug then put that in an email as described. Thanks, David > > ------------------??????------------------ > *???:*?"David Holmes"; > *????:*?2019?9?5?(???) ??1:44 > *???:*?"????"<2217232293 at qq.com>;"core-libs-dev" dev at openjdk.java.net>; > *??:*?Re: what to do next to fix JDK-8230557. thanks > > On 5/09/2019 3:35 pm, ???? wrote: > > Hi, leaders. > > Hi, > > No "leaders" here only developers :) > > > > > A few days ago, I report a bug in core lib[1]. According to the > contribute document[2], I had send oca to oracle and my name has > been listed on oca[3]. > > Welcome aboard! > > > But I still can't push my changes to jdk, can someone tell me how to > do next? thanks very match!! > > You can't push anything until you become a Committer and before that you > have to become an Author. The steps for contributing are outlined here: > > http://openjdk.java.net/contribute/ > > and you would seem to be up to step 2. :) > > Cheers, > David > > > > > > > > > > > [1]https://bugs.openjdk.java.net/browse/JDK-8230557 > > > > [2]http://openjdk.java.net/contribute/ > > [3]https://www.oracle.com/technetwork/community/oca-486395.html > > > > > > > > > > > > ------------------ ???? ------------------ > > ???: "Bug Report > Notification" > ????: 2019?9?5?(???) ??3:33 > > ???: "????"<2217232293 at qq.com>; > > > > ??: Update Notification: Bug Report? - JDK-8230557 > > > > > > > > > ????????????????????????? [This is an automated response. Please do not > reply.] > > Dear Java Developer, > > We have finished evaluating your report and have assigned it a Bug > ID: JDK-8230557. The issue is visible on bugs.java.com at the following > url JDK-8230557. > >?????????????????? To provide more information about this issue, > click? here. > >????????????????? We work to resolve the issues that are submitted to > us according to their impact to the community as a whole, and make no > promises as to the time or release in which a bug might be fixed. If > this issue has a significant impact on your project you may want to > consider using one of the technical support offerings available at > Oracle Support. > >?????????????????????????????? Regards, > >?????????????????????????????????????? Java Developer Support > > > > > > > > > > > > Java SE > >?????????????????? Java SE Documentation > >?????????????????? Java SE Downloads > >?????????????????? Java Developer Forums > >?????????????????? Oracle Java SE Advanced > >?????????????????? Bug Database > > > ???????? ?????????????????????????????????? Copyright ? Oracle and/or > its affiliates. All rights reserved. > > > ????????????????????????????????? Terms of Use |???????????????? Privacy > > From 2217232293 at qq.com Thu Sep 5 06:11:25 2019 From: 2217232293 at qq.com (=?utf-8?B?5pyq5p2l6Ziz5YWJ?=) Date: Thu, 5 Sep 2019 14:11:25 +0800 Subject: =?utf-8?B?5Zue5aSN77yaIOWbnuWkje+8miB3aGF0IHRvIGRv?= =?utf-8?B?IG5leHQgdG8gZml4IEpESy04MjMwNTU3LiB0aGFu?= =?utf-8?B?a3M=?= In-Reply-To: <1331cc4f-964b-ab27-4e48-4cb102b5e964@oracle.com> References: <1331cc4f-964b-ab27-4e48-4cb102b5e964@oracle.com> Message-ID: Thanks very much. BUG-LINK: https://bugs.openjdk.java.net/browse/JDK-8230557 Describe:  the return type of the method BitSet#size is int, so the method may return a negative value in some case, for example, will return -2147483648.  ```  BitSet bitSet = new BitSet(Integer.MAX_VALUE);  for (int i = 0; i < Integer.MAX_VALUE - 1000; i++) {      bitSet.set(i);  }  System.out.println(bitSet.size());  ```  EXPECTED: 2147483648, but ACTUAL: -2147483648. FIX I have put the patch in the attachment of the mail. ------------------ ???? ------------------ ???: "David Holmes" References: <1331cc4f-964b-ab27-4e48-4cb102b5e964@oracle.com> Message-ID: Hi, On 5/09/2019 4:11 pm, ???? wrote: > > Thanks very much. > > *BUG-LINK:* https://bugs.openjdk.java.net/browse/JDK-8230557 > > *Describe: * > the return type of the method BitSet#size is int, so the method may > return a negative value in some case, for example, will return -2147483648. > ``` > BitSet bitSet = new BitSet(Integer.MAX_VALUE); > for (int i = 0; i < Integer.MAX_VALUE - 1000; i++) { > ????bitSet.set(i); > } > System.out.println(bitSet.size()); > ``` > EXPECTED: 2147483648, but ACTUAL: -2147483648. > > *FIX* > I have put the patch in the attachment of the mail. In case the attachment got stripped form the mailing list the proposed fix is: - public int size() { - return words.length * BITS_PER_WORD; + public long size() { + return (long) words.length * BITS_PER_WORD; Unfortunately this simple fix it not possible. You can't just change the return type of the method to long as that is a source-incompatible change and would not be approved [1]. Instead the return value should be capped at Integer.MAX_VALUE - but I'll leave that for someone from core-libs team to pick up. Also look at the evaluation in: https://bugs.openjdk.java.net/browse/JDK-4213570 Cheers, David [1] https://wiki.openjdk.java.net/display/csr/CSR+FAQs > > ------------------??????------------------ > *???:*?"David Holmes"; > *????:*?2019?9?5?(???) ??2:00 > *???:*?"????"<2217232293 at qq.com>;"core-libs-dev" dev at openjdk.java.net>; > *??:*?Re: ??? what to do next to fix JDK-8230557. thanks > > On 5/09/2019 3:46 pm, ???? wrote: > > > > hi, developers. > > > > Can someone help me? thanks very much !! > > Help you how exactly. As I stated your are up to step 2 of the how to > contribute process. If you have a suggested fix for the bug then put > that in an email as described. > > Thanks, > David > > > > > ------------------??????------------------ > > *???:*?"David Holmes"; > > *????:*?2019?9?5?(???) ??1:44 > > *???:*?"????"<2217232293 at qq.com>;"core-libs-dev" > dev at openjdk.java.net>; > > *??:*?Re: what to do next to fix JDK-8230557. thanks > > > > On 5/09/2019 3:35 pm, ???? wrote: > >? > Hi, leaders. > > > > Hi, > > > > No "leaders" here only developers :) > > > >? > > >? > A few days ago, I report a bug in core lib[1]. According to the > > contribute document[2], I had send oca to oracle and my name has > > been listed on oca[3]. > > > > Welcome aboard! > > > >? > But I still can't push my changes to jdk, can someone tell me how to > > do next? thanks very match!! > > > > You can't push anything until you become a Committer and before that you > > have to become an Author. The steps for contributing are outlined here: > > > > http://openjdk.java.net/contribute/ > > > > and you would seem to be up to step 2. :) > > > > Cheers, > > David > > > >? > > >? > > >? > > >? > > >? > [1]https://bugs.openjdk.java.net/browse/JDK-8230557 > >? > > >? > [2]http://openjdk.java.net/contribute/ > >? > [3]https://www.oracle.com/technetwork/community/oca-486395.html > >? > > >? > > >? > > >? > > >? > > >? > ------------------ ???? ------------------ > >? > ???: "Bug Report > > Notification" >? > ????: 2019?9?5?(???) ??3:33 > >? > ???: "????"<2217232293 at qq.com>; > >? > > >? > ??: Update Notification: Bug Report? - JDK-8230557 > >? > > >? > > >? > > >? > > >? ????????????????????????? [This is an automated response. Please do not > > reply.] > >? > Dear Java Developer, > >? > We have finished evaluating your report and have assigned it a Bug > > ID: JDK-8230557. The issue is visible on bugs.java.com at the following > > url JDK-8230557. > >? >?????????????????? To provide more information about this issue, > > click? here. > >? >????????????????? We work to resolve the issues that are submitted to > > us according to their impact to the community as a whole, and make no > > promises as to the time or release in which a bug might be fixed. If > > this issue has a significant impact on your project you may want to > > consider using one of the technical support offerings available at > > Oracle Support. > >? >?????????????????????????????? Regards, > >? >?????????????????????????????????????? Java Developer Support > >? > > >? > > >? > > >? > > >? > > >? > Java SE > >? >?????????????????? Java SE Documentation > >? >?????????????????? Java SE Downloads > >? >?????????????????? Java Developer Forums > >? >?????????????????? Oracle Java SE Advanced > >? >?????????????????? Bug Database > >? > > >? ???????? ?????????????????????????????????? Copyright ? Oracle and/or > > its affiliates. All rights reserved. > >? > > >? ????????????????????????????????? Terms of Use |???????????????? Privacy > >? > From peter.levart at gmail.com Thu Sep 5 07:51:38 2019 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 5 Sep 2019 09:51:38 +0200 Subject: =?UTF-8?B?UmU6IOWbnuWkje+8miDlm57lpI3vvJogd2hhdCB0byBkbyBuZXh0IHRv?= =?UTF-8?Q?_fix_JDK-8230557=2e_thanks?= In-Reply-To: References: <1331cc4f-964b-ab27-4e48-4cb102b5e964@oracle.com> Message-ID: <10d071e9-f84c-52a7-68d5-f680f44034b5@gmail.com> Hi ????, As David has pointed out, your proposed fix would break binary and source compatibility of BitSet.size() method, so it is not acceptable. BitSet API allows addressing individual bits using non-negative 'int' typed indexes (analogous to indexes of Java arrays). The range of indexes is: 0 ... 2^31 - 1 (0 ... Integer.MAX_VALUE). The maximum "size" of BitSet is therefore 2^31. Unfortunately, this value can't be "corectly" represented with signed 32 bit integer (int). Only in this corner case, - 2^31 (Integer.MIN_VALUE) is the interpreted value returned from size(). If one would interpret it as unsigned 32 bit integer value, it is entirely correct. For example, this holds: Integer.toUnsignedLong(new BitSet(Integer.MAX_VALUE).size()) == 1L << 31 It is also always true what javadoc says about size(): "The maximum element in the set is the size - 1st element" The following holds also for this corner case: new BitSet(Integer.MAX_VALUE).size() - 1 == Integer.MAX_VALUE; So perhaps, the fix could be just to describe this corner case in the spec. And perhaps, to support the following use case in the corner case: BitSet set1 = ... ... BitSet set2 = new BitSet(set1.size()); ... by modifying the BitSet constructor to accept the Integer.MIN_VALUE in addition to all the non-negative values as the 'nbits' parameter. What do you think? Regards, Peter On 9/5/19 8:31 AM, David Holmes wrote: > Hi, > > On 5/09/2019 4:11 pm, ???? wrote: >> >> Thanks very much. >> >> *BUG-LINK:* https://bugs.openjdk.java.net/browse/JDK-8230557 >> >> *Describe: * >> the return type of the method BitSet#size is int, so the method may >> return a negative value in some case, for example, will return >> -2147483648. >> ``` >> BitSet bitSet = new BitSet(Integer.MAX_VALUE); >> for (int i = 0; i < Integer.MAX_VALUE - 1000; i++) { >> ?????bitSet.set(i); >> } >> System.out.println(bitSet.size()); >> ``` >> EXPECTED: 2147483648, but ACTUAL: -2147483648. >> >> *FIX* >> I have put the patch in the attachment of the mail. > > In case the attachment got stripped form the mailing list the proposed > fix is: > > -??? public int size() { > -??????? return words.length * BITS_PER_WORD; > +??? public long size() { > +??????? return (long) words.length * BITS_PER_WORD; > > Unfortunately this simple fix it not possible. You can't just change > the return type of the method to long as that is a source-incompatible > change and would not be approved [1]. Instead the return value should > be capped at Integer.MAX_VALUE - but I'll leave that for someone from > core-libs team to pick up. Also look at the evaluation in: > > https://bugs.openjdk.java.net/browse/JDK-4213570 > > Cheers, > David > > [1] https://wiki.openjdk.java.net/display/csr/CSR+FAQs > > > >> >> ------------------??????------------------ >> *???:*?"David Holmes"; >> *????:*?2019?9?5?(???) ??2:00 >> *???:*?"????"<2217232293 at qq.com>;"core-libs-dev"> dev at openjdk.java.net>; >> *??:*?Re: ??? what to do next to fix JDK-8230557. thanks >> >> On 5/09/2019 3:46 pm, ???? wrote: >> ?> >> ?> hi, developers. >> ?> >> ?> Can someone help me? thanks very much !! >> >> Help you how exactly. As I stated your are up to step 2 of the how to >> contribute process. If you have a suggested fix for the bug then put >> that in an email as described. >> >> Thanks, >> David >> >> ?> >> ?> ------------------??????------------------ >> ?> *???:*?"David Holmes"; >> ?> *????:*?2019?9?5?(???) ??1:44 >> ?> *???:*?"????"<2217232293 at qq.com>;"core-libs-dev"> ?> dev at openjdk.java.net>; >> ?> *??:*?Re: what to do next to fix JDK-8230557. thanks >> ?> >> ?> On 5/09/2019 3:35 pm, ???? wrote: >> ?>? > Hi, leaders. >> ?> >> ?> Hi, >> ?> >> ?> No "leaders" here only developers :) >> ?> >> ?>? > >> ?>? > A few days ago, I report a bug in core lib[1]. According to the >> ?> contribute document[2], I had send oca to oracle and my name has >> ?> been listed on oca[3]. >> ?> >> ?> Welcome aboard! >> ?> >> ?>? > But I still can't push my changes to jdk, can someone tell me >> how to >> ?> do next? thanks very match!! >> ?> >> ?> You can't push anything until you become a Committer and before >> that you >> ?> have to become an Author. The steps for contributing are outlined >> here: >> ?> >> ?> http://openjdk.java.net/contribute/ >> ?> >> ?> and you would seem to be up to step 2. :) >> ?> >> ?> Cheers, >> ?> David >> ?> >> ?>? > >> ?>? > >> ?>? > >> ?>? > >> ?>? > [1]https://bugs.openjdk.java.net/browse/JDK-8230557 >> ?>? > >> ?>? > [2]http://openjdk.java.net/contribute/ >> ?>? > [3]https://www.oracle.com/technetwork/community/oca-486395.html >> ?>? > >> ?>? > >> ?>? > >> ?>? > >> ?>? > >> ?>? > ------------------ ???? ------------------ >> ?>? > ???: "Bug Report >> ?> Notification"> ?>? > ????: 2019?9?5?(???) ??3:33 >> ?>? > ???: "????"<2217232293 at qq.com>; >> ?>? > >> ?>? > ??: Update Notification: Bug Report? - JDK-8230557 >> ?>? > >> ?>? > >> ?>? > >> ?>? > >> ?>? ????????????????????????? [This is an automated response. Please >> do not >> ?> reply.] >> ?>? > Dear Java Developer, >> ?>? > We have finished evaluating your report and have assigned it a Bug >> ?> ID: JDK-8230557. The issue is visible on bugs.java.com at the >> following >> ?> url JDK-8230557. >> ?>? >?????????????????? To provide more information about this issue, >> ?> click? here. >> ?>? >????????????????? We work to resolve the issues that are >> submitted to >> ?> us according to their impact to the community as a whole, and make no >> ?> promises as to the time or release in which a bug might be fixed. If >> ?> this issue has a significant impact on your project you may want to >> ?> consider using one of the technical support offerings available at >> ?> Oracle Support. >> ?>? >?????????????????????????????? Regards, >> ?>? >?????????????????????????????????????? Java Developer Support >> ?>? > >> ?>? > >> ?>? > >> ?>? > >> ?>? > >> ?>? > Java SE >> ?>? >?????????????????? Java SE Documentation >> ?>? >?????????????????? Java SE Downloads >> ?>? >?????????????????? Java Developer Forums >> ?>? >?????????????????? Oracle Java SE Advanced >> ?>? >?????????????????? Bug Database >> ?>? > >> ?>? ???????? ?????????????????????????????????? Copyright ? Oracle >> and/or >> ?> its affiliates. All rights reserved. >> ?>? > >> ?>? ????????????????????????????????? Terms of Use |???????????????? >> Privacy >> ?>? > From david.holmes at oracle.com Thu Sep 5 07:52:29 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 5 Sep 2019 17:52:29 +1000 Subject: RFR: 8212117 : Class.forName may return a reference to a loaded but not linked Class In-Reply-To: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com> References: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com> Message-ID: <6d1691eb-220c-ceaf-1302-be2d285f4968@oracle.com> Hi Brent, Good to see this all come together :) A couple of comments below. On 5/09/2019 7:12 am, Brent Christian wrote: > Hi, > > Please review my fix for JDK-8212117[1].? The webrev is here: > > http://cr.openjdk.java.net/~bchristi/8212117/webrev09/ So to clarify for others any current caller to find_class_from_class_loader that passes true for "init" was already implicitly asking for a linked class (as you must be linked before you can be initialized). With that in mind I would suggest that in find_class_from_class_loader you add an assert: ! jclass find_class_from_class_loader(JNIEnv* env, Symbol* name, jboolean init, jboolean link, Handle loader, Handle protection_domain, jboolean throwError, TRAPS) { +assert((init && link) || !init, "incorrect use of init/link arguments"); just to ensure the callers understand this. Aside: in looking at this I've spotted another existing bug. JNI FindClass is not specified to perform class initialization, but the implementation passes init=true! --- src/java.base/share/classes/java/lang/invoke/MethodHandles.java I don't see the need for the new note given it already has * @throws LinkageError if the linkage fails --- src/java.base/share/classes/sun/launcher/LauncherHelper.java So to clarify, the launcher would previously load the main class without linking via: mainClass = LoadMainClass(env, mode, what); CHECK_EXCEPTION_NULL_LEAVE(mainClass); and then it would invoke the main method which implicitly initialized which implicitly linked and so any exceptions related to linking would be handled when the main thread detaches, and it all gets reported nicely. But now that we link earlier the exception could be pending after LoadMainClass and so we would "abort". So you catch that unexpected exception in the LauncherHelper. Is AccessControlException the only exception, that is not a LinkageError, that might be thrown when linking? I would think a number of others are possible - in particular IllegalAccessError might occur during verification. Other than the fact a test obviously triggered this, it's not clear why ACE should be singled out here. ?? --- test/hotspot/jtreg/serviceability/jvmti/ClassStatus/ClassStatus.java 45 // public static void foo(Foo f) { } Unclear why this exists. Also the test refers initially to class Foo but then uses Foo2 and Foo3. ?? Otherwise all seems good. > There is also a CSR[2] in need of review. I've added a couple of comments and will add myself as a reviewer once things are near finalized. Thanks, David ----- > > The spec for the 2-arg and 3-arg Class.forName() methods states they > will "locate, load, and link" the class, however the linking part is not > ensured to happen. > > Although the VM spec allows flexibility WRT when classes are linked, > this is a corner where the Class.forName() spec is not being upheld. > While this is not an issue for most usages,? 8181144 [3] demonstrates > how this can be a problem (with the debugging interface, in this case). > > This fix ensures that linking happens during the course of > Class.forName().? Class.forName() already @throws LinkageError, so no > spec change is needed there. MethodHandles.Lookup.findClass() needs a > small spec update, due to calling Class.forName with init=false, > > Of course Errors are not required to be caught.? It is therefore > possible that the new behavior could introduce previously unseen, > possibly unhandled LinkageErrors.? A new VM flag > (-XX:+ClassForNameDeferLinking) is introduced to restore the previous > behavior (to keep such code running until it can be updated). > > This change surfaced a couple new "A JNI error has occurred" situations > (see 8181033[5]) in the Launcher, by way of > ? test/jdk/tools/launcher/MainClassCantBeLoadedTest.java > (using the 3-arg Class::forName, detailed in the bug report[4]), > and > ? test/jdk/tools/launcher/modules/basic/LauncherErrors.java > (using the 2-arg Class::forName). > > The Launcher is updated to maintain non-confusing error messages :). > > The new test included with this fix ensures that 8181144[3] is > addressed.? Thanks go to Serguei Spitsyn for writing the test. > > Automated corelibs and hotspot tests pass cleanly. > > Thanks, > -Brent > > -- > 1. https://bugs.openjdk.java.net/browse/JDK-8212117 > > 2. https://bugs.openjdk.java.net/browse/JDK-8222071 > > 3. https://bugs.openjdk.java.net/browse/JDK-8181144 > > 4. > https://bugs.openjdk.java.net/browse/JDK-8212117?focusedCommentId=14215986&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14215986 > > > 5. https://bugs.openjdk.java.net/browse/JDK-8181033 > From 2217232293 at qq.com Thu Sep 5 08:16:56 2019 From: 2217232293 at qq.com (=?gb18030?B?zrTAtNH0ueI=?=) Date: Thu, 5 Sep 2019 16:16:56 +0800 Subject: =?gb18030?B?UmVwbHmjuiB3aGF0IHRvIGRvIG5leHQgdG8gZml4?= =?gb18030?B?IEpESy04MjMwNTU3LiB0aGFua3M=?= In-Reply-To: <10d071e9-f84c-52a7-68d5-f680f44034b5@gmail.com> References: <1331cc4f-964b-ab27-4e48-4cb102b5e964@oracle.com> <10d071e9-f84c-52a7-68d5-f680f44034b5@gmail.com> Message-ID: Hi, Peter. I understand your point, but I think it's unreasonable for the reason that source code compatibility problem, it's really a bug. User can't understand why the size method return a negative number.   Best, lamber-ken ------------------ ???? ------------------ ???: "Peter Levart" Hi, Peter. the length method return a negative number too   Best, lamber-ken ------------------ ???? ------------------ ???: "Peter Levart" References: <1331cc4f-964b-ab27-4e48-4cb102b5e964@oracle.com> <10d071e9-f84c-52a7-68d5-f680f44034b5@gmail.com> Message-ID: Hello! BitSet is known to be flawed in many ways:? its size(), length(), cardinality() and nextClearBit?() can return meaningless negative values. I was thinking about disallowing setting any index greater than (Integer.MAX_VALUE - 63), for example by throwing OutOfMemoryError. We could do it without changing the specification. With kind regards, Ivan On 9/5/19 1:16 AM, ???? wrote: > Hi, Peter. > > > I understand your point, but I think it's unreasonable for the reason that source code compatibility problem, it's really a bug. > > > User can't understand why the size method return a negative number. > > > >   > > > Best, lamber-ken > > > > > ------------------ ???? ------------------ > ???: "Peter Levart" ????: 2019?9?5?(???) ??3:51 > ???: "????"<2217232293 at qq.com>;"core-libs-dev" ??: "David Holmes" ??: Re: ??? ??? what to do next to fix JDK-8230557. thanks > > > > Hi ????, > > As David has pointed out, your proposed fix would break binary and > source compatibility of BitSet.size() method, so it is not acceptable. > > BitSet API allows addressing individual bits using non-negative 'int' > typed indexes (analogous to indexes of Java arrays). The range of > indexes is: 0 ... 2^31 - 1 (0 ... Integer.MAX_VALUE). The maximum "size" > of BitSet is therefore 2^31. Unfortunately, this value can't be > "corectly" represented with signed 32 bit integer (int). Only in this > corner case, - 2^31 (Integer.MIN_VALUE) is the interpreted value > returned from size(). If one would interpret it as unsigned 32 bit > integer value, it is entirely correct. For example, this holds: > > Integer.toUnsignedLong(new BitSet(Integer.MAX_VALUE).size()) == 1L << 31 > > It is also always true what javadoc says about size(): "The maximum > element in the set is the size - 1st element" > > The following holds also for this corner case: > > new BitSet(Integer.MAX_VALUE).size() - 1 == Integer.MAX_VALUE; > > So perhaps, the fix could be just to describe this corner case in the > spec. And perhaps, to support the following use case in the corner case: > > BitSet set1 = ... > ... > > BitSet set2 = new BitSet(set1.size()); > > ... by modifying the BitSet constructor to accept the Integer.MIN_VALUE > in addition to all the non-negative values as the 'nbits' parameter. > > What do you think? > > Regards, Peter > > On 9/5/19 8:31 AM, David Holmes wrote: > > Hi, > > > > On 5/09/2019 4:11 pm, ???? wrote: > >> > >> Thanks very much. > >> > >> *BUG-LINK:* https://bugs.openjdk.java.net/browse/JDK-8230557 > >> > >> *Describe: * > >> the return type of the method BitSet#size is int, so the method may > >> return a negative value in some case, for example, will return > >> -2147483648. > >> ``` > >> BitSet bitSet = new BitSet(Integer.MAX_VALUE); > >> for (int i = 0; i < Integer.MAX_VALUE - 1000; i++) { > >>      bitSet.set(i); > >> } > >> System.out.println(bitSet.size()); > >> ``` > >> EXPECTED: 2147483648, but ACTUAL: -2147483648. > >> > >> *FIX* > >> I have put the patch in the attachment of the mail. > > > > In case the attachment got stripped form the mailing list the proposed > > fix is: > > > > -    public int size() { > > -        return words.length * BITS_PER_WORD; > > +    public long size() { > > +        return (long) words.length * BITS_PER_WORD; > > > > Unfortunately this simple fix it not possible. You can't just change > > the return type of the method to long as that is a source-incompatible > > change and would not be approved [1]. Instead the return value should > > be capped at Integer.MAX_VALUE - but I'll leave that for someone from > > core-libs team to pick up. Also look at the evaluation in: > > > > https://bugs.openjdk.java.net/browse/JDK-4213570 > > > > Cheers, > > David > > > > [1] https://wiki.openjdk.java.net/display/csr/CSR+FAQs > > > > > > > >> > >> ------------------ ???? ------------------ > >> *???:* "David Holmes" >> *????:* 2019?9?5?(???) ??2:00 > >> *???:* "????"<2217232293 at qq.com>;"core-libs-dev" >> dev at openjdk.java.net>; > >> *??:* Re: ??? what to do next to fix JDK-8230557. thanks > >> > >> On 5/09/2019 3:46 pm, ???? wrote: > >>  > > >>  > hi, developers. > >>  > > >>  > Can someone help me? thanks very much !! > >> > >> Help you how exactly. As I stated your are up to step 2 of the how to > >> contribute process. If you have a suggested fix for the bug then put > >> that in an email as described. > >> > >> Thanks, > >> David > >> > >>  > > >>  > ------------------ ???? ------------------ > >>  > *???:* "David Holmes" >>  > *????:* 2019?9?5?(???) ??1:44 > >>  > *???:* "????"<2217232293 at qq.com>;"core-libs-dev" >>  > dev at openjdk.java.net>; > >>  > *??:* Re: what to do next to fix JDK-8230557. thanks > >>  > > >>  > On 5/09/2019 3:35 pm, ???? wrote: > >>  >  > Hi, leaders. > >>  > > >>  > Hi, > >>  > > >>  > No "leaders" here only developers :) > >>  > > >>  >  > > >>  >  > A few days ago, I report a bug in core lib[1]. According to the > >>  > contribute document[2], I had send oca to oracle and&nbsp;my name has > >>  > been listed on&nbsp;oca[3]. > >>  > > >>  > Welcome aboard! > >>  > > >>  >  > But I still can't push my changes to jdk, can someone tell me > >> how to > >>  > do next? thanks very match!! > >>  > > >>  > You can't push anything until you become a Committer and before > >> that you > >>  > have to become an Author. The steps for contributing are outlined > >> here: > >>  > > >>  > http://openjdk.java.net/contribute/ > >>  > > >>  > and you would seem to be up to step 2. :) > >>  > > >>  > Cheers, > >>  > David > >>  > > >>  >  > > >>  >  > > >>  >  > > >>  >  > > >>  >  > [1]https://bugs.openjdk.java.net/browse/JDK-8230557 > >>  >  > > >>  >  > [2]http://openjdk.java.net/contribute/ > >>  >  > [3]https://www.oracle.com/technetwork/community/oca-486395.html > >>  >  > > >>  >  > > >>  >  > > >>  >  > > >>  >  > > >>  >  > ------------------&nbsp;????&nbsp;------------------ > >>  >  > ???:&nbsp;"Bug Report > >>  > Notification" >>  >  > ????:&nbsp;2019?9?5?(???) ??3:33 > >>  >  > ???:&nbsp;"????"<2217232293 at qq.com&gt;; > >>  >  > > >>  >  > ??:&nbsp;Update Notification: Bug Report  - JDK-8230557 > >>  >  > > >>  >  > > >>  >  > > >>  >  > > >>  >                            [This is an automated response. Please > >> do not > >>  > reply.] > >>  >  > Dear Java Developer, > >>  >  > We have finished evaluating your report and have assigned it a Bug > >>  > ID: JDK-8230557. The issue is visible on bugs.java.com at the > >> following > >>  > url JDK-8230557. > >>  >  >                   To provide more information about this issue, > >>  > click  here. > >>  >  >                  We work to resolve the issues that are > >> submitted to > >>  > us according to their impact to the community as a whole, and make no > >>  > promises as to the time or release in which a bug might be fixed. If > >>  > this issue has a significant impact on your project you may want to > >>  > consider using one of the technical support offerings available at > >>  > Oracle Support. > >>  >  >                               Regards, > >>  >  >                                       Java Developer Support > >>  >  > > >>  >  > > >>  >  > > >>  >  > > >>  >  > > >>  >  > Java SE > >>  >  >                   Java SE Documentation > >>  >  >                   Java SE Downloads > >>  >  >                   Java Developer Forums > >>  >  >                   Oracle Java SE Advanced > >>  >  >                   Bug Database > >>  >  > > >>  >                                              Copyright ? Oracle > >> and/or > >>  > its affiliates. All rights reserved. > >>  >  > > >>  >                                    Terms of Use |                 > >> Privacy > >>  >  > -- With kind regards, Ivan Gerasimov From lenborje at gmail.com Thu Sep 5 09:53:09 2019 From: lenborje at gmail.com (=?utf-8?Q?Lennart_B=C3=B6rjeson?=) Date: Thu, 5 Sep 2019 11:53:09 +0200 Subject: Comments on jpackage (JEP 343) Message-ID: Could you please also revive the UserJvmOptionsService, that (for very unclear reasons) was removed together with JavaFX? Since the functionality provided by the UserJvmOptionsService requires some cooperation with the launcher created by jpackage, I can't see how I could implement some work-around myself. (I raised this question already in https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-March/059419.html, but without response.) Best regards, Lennart B?rjeson From julia.boes at oracle.com Thu Sep 5 10:40:55 2019 From: julia.boes at oracle.com (Julia Boes) Date: Thu, 5 Sep 2019 11:40:55 +0100 Subject: RFR: 8230648: Replace @exception tag with @throws in java.base In-Reply-To: <358c8542-6fdf-fce4-bd77-0a51f81d9d64@oracle.com> References: <358c8542-6fdf-fce4-bd77-0a51f81d9d64@oracle.com> Message-ID: <38ab81e8-2042-2b57-238d-61553e8bdf40@oracle.com> Hi, This change replaces all occurrences of the @exception tag in java.base with the @throws tag. The tags are synonyms but @throws is the newer preferred option [1]. Bug: https://bugs.openjdk.java.net/browse/JDK-8230648 Webrev: http://corelibs-linux-1.ie.oracle.com/~jboes/webrevs/8230648/webrev.00/ Regards, Julia [1] https://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#throws From julia.boes at oracle.com Thu Sep 5 10:59:01 2019 From: julia.boes at oracle.com (Julia Boes) Date: Thu, 5 Sep 2019 11:59:01 +0100 Subject: RFR: 8230648: Replace @exception tag with @throws in java.base In-Reply-To: <38ab81e8-2042-2b57-238d-61553e8bdf40@oracle.com> References: <358c8542-6fdf-fce4-bd77-0a51f81d9d64@oracle.com> <38ab81e8-2042-2b57-238d-61553e8bdf40@oracle.com> Message-ID: ..this time with the right link! On 05/09/2019 11:40, Julia Boes wrote: > Hi, > > This change replaces all occurrences of the @exception tag in > java.base with the @throws tag. The tags are synonyms but @throws is > the newer preferred option [1]. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8230648 Webrev: http://cr.openjdk.java.net/~dfuchs/jboes/8230648/webrev.00/ > > > > Regards, > > Julia > > [1] > https://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#throws > From pavel.rappo at oracle.com Thu Sep 5 11:37:30 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 5 Sep 2019 12:37:30 +0100 Subject: RFR: 8230648: Replace @exception tag with @throws in java.base In-Reply-To: <38ab81e8-2042-2b57-238d-61553e8bdf40@oracle.com> References: <358c8542-6fdf-fce4-bd77-0a51f81d9d64@oracle.com> <38ab81e8-2042-2b57-238d-61553e8bdf40@oracle.com> Message-ID: Julia, Trivially update the copyright years and pay attention to not-so-trivial things like: 8157682: @inheritDoc doesn't work with @exception I'd suggest comparing "before" and "after" javadoc visually to make sure no funny business is going on. -Pavel > On 5 Sep 2019, at 11:40, Julia Boes wrote: > > Hi, > > This change replaces all occurrences of the @exception tag in java.base with the @throws tag. The tags are synonyms but @throws is the newer preferred option [1]. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8230648 > > Webrev: http://corelibs-linux-1.ie.oracle.com/~jboes/webrevs/8230648/webrev.00/ > > > Regards, > > Julia > > [1] https://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#throws > From lance.andersen at oracle.com Thu Sep 5 11:53:00 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 5 Sep 2019 07:53:00 -0400 Subject: RFR: 8230648: Replace @exception tag with @throws in java.base In-Reply-To: References: <358c8542-6fdf-fce4-bd77-0a51f81d9d64@oracle.com> <38ab81e8-2042-2b57-238d-61553e8bdf40@oracle.com> Message-ID: Hi Julia, I think the fix is fine overall I noticed that the copyright was not updated in all of the files modified, which may be OK in this case, but I typically change it when I made minor changes as well. Not a big deal. The only other question is I am wondering if we want to align the text better with the rest of the javadocs (maybe a separate bug) as for example you look at ZipOutputStream.java, the change on line 144 is slightly off. Its not a big deal but a minor hiccup from probably using a script which is understandable HTH lance > On Sep 5, 2019, at 6:59 AM, Julia Boes > wrote: > > ..this time with the right link! > > > On 05/09/2019 11:40, Julia Boes wrote: >> Hi, >> >> This change replaces all occurrences of the @exception tag in java.base with the @throws tag. The tags are synonyms but @throws is the newer preferred option [1]. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8230648 > Webrev: http://cr.openjdk.java.net/~dfuchs/jboes/8230648/webrev.00/ >> >> >> >> Regards, >> >> Julia >> >> [1] https://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#throws >> 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 Thu Sep 5 11:57:55 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Thu, 5 Sep 2019 07:57:55 -0400 Subject: Comments on jpackage (JEP 343) In-Reply-To: <20190903185855.D9F092BEC49@eggemoggin.niobe.net> References: <20190903185855.D9F092BEC49@eggemoggin.niobe.net> Message-ID: <80789e1a-3592-781a-2989-a5ba0978bb35@oracle.com> Thank you very much for the detailed feedback. see inline for Change Requests created or associated with each point . /Andy On 9/3/2019 2:58 PM, mark.reinhold at oracle.com wrote: > I spent some time last week playing with the jpackage tool, using build > 14-jpackage+1-35 from https://jdk.java.net/jpackage. > > Overall, I can see that you?ve made good progress, but there?s still some > work to be done. I?ll start with high-level comments and questions, and > then comment on my experience using the tool on Debian and then macOS. > > High-level comments/questions > > - It?s good that you?re publishing EA builds, but I haven?t seen very > much feedback from those builds. It may be better to propose this as > an experimental feature when it?s ready to target. That would give > you the freedom to improve it incompatibly over one or two release > cycles before you commit to a final version. We like the suggestion to release as an experimental feature. see: JDK-8230649 > > - The tool still generates an image by default, rather than a package. > This will surprise many users, especially those who just want to do > something simple and straightforward. The least-surprising default > behavior would be to generate a package of the type most suitable for > the current platform. An option to generate just an image would be > fine, for those who want to tweak it before the actual packaging > step, but that shouldn?t be the default. > > - Related to the previous point, I should only have to specify the > `--package-type` option if I want something other than the default > for the current platform. We will add "app-image" as an explicit type and change the --package-type default to be type most suitable for the current platform. see: JDK-8230519 > > - The tool assumes that the application being packaged will have a GUI. > This isn?t surprising, considering its heritage, but as a consequence > it always produces packages that perform GUI-specific actions, such > as installing icons and desktop-menu entries. If I?m just packaging > a command-line tool then these are unnecessary, and supporting them > can pull in lots of additional dependencies (e.g., a ton of Perl > scripts on Debian). Consider adding an option (`--gui`?) so that > the user can indicate when an application is to be installed for > graphical use. For giving the developer the control of shortcuts we have created : JDK-8229779 If an application does not request shortcut(s) there should be no need for gui code. > > - The `--output`/`-o` option is confusing. It doesn?t name the output > itself, but rather a directory into which the single item of output > will be placed. Typing `-o .` all the time is just annoying. It?d > be more logical to rename this option to `--dest`/`-d` and to make it > optional, with a default value of `.`. We will change name of option and default as suggested see: JDK-8230521 > > - If my app is modular, and my main module has a version string, then > it?d be nice for that to be used as the package version unless a > specific version is specified on the command line. see: JDK-8230651 > - Terminology: For Linux we generally speak of ?packages? rather than > ?bundles.? Rename `--linux-bundle-name` to `--linux-package-name`. this will be fixed as part of: JDK-8230522 > > - The `--temp-root` option could be shortened to `--temp`. see: JDK-8230522 > > - Periods at the ends of error messages are unsightly and unnecessary. > We don?t use them in other JDK tools. Please remove them. This is also included in: JDK-8230522 > > - It?d be nice to have an option that displays the programs being run > by the tool, in a form that can easily be cut-and-pasted into a > script for those who need to do a lot of customization. The current > verbose output shows (at least some of) this information, but in a > difficult-to-use format. see:JDK-8230652 > > - What?s the rationale for copying the entire ?input? directory as-is? > Why is its structure important? Couldn?t you just as well limit this > to a single directory full of JAR files? After discussion , I will look for use case where this existing behavior is desirable. > > Comments on Debian packaging All of the below comments on Debian packaging? are reflected in JDK-8230507 They may or may not be split up into individual CR's as they are addressed. > > - On a Debian machine I tried to create a package for a trivial, > two-module application using the command > > $ jpackage -o . --package-type deb -p lib -m org.openjdk.hello -n hello > > which gave me the error message > > Bundler DEB Installer skipped because of a configuration problem: java.lang.NullPointerException. > > (Side note: This message is confusing since the tool is creating a > Debian package, not an ?installer.?) > > - On a hunch, I specified a main application class: > > $ jpackage -o . --package-type deb -p lib -m org.openjdk.hello/org.openjdk.hello.Main -n hello > > and that created `hello_1.0-1_amd64.deb`. It shouldn?t have been > necessary to specify a main class since the main module does have a > `ModuleMainClass` attribute in its module descriptor. > > - The resulting package does not depend upon any others, i.e., the > `Depends:` line in its control file is empty. This can?t possibly be > right, since the embedded JDK depends on many system libraries for > proper operation (`libc`, `libfreetype`, `libpthread`, etc.). > > - The resulting package would install into `/opt/hello`, as expected, > but the `/opt/hello/bin` directory would contain not just the `hello` > application launcher but also `hello.desktop`, `hello.png`, and > `libapplauncher.so`. These aren?t appropriate for a `bin` directory > and should be placed elsewhere, most likely `/opt/hello/lib`. > > - The resulting package would install `/opt/hello/app` and > `/opt/hello/runtime` directories. These are not strictly forbidden > by the Linux FHS [1], but it?d be better to put both of them under > `/opt/hello/lib`, per convention. > > - The resulting package does not contain the normal `java` launcher. > It?d be helpful to retain this (in `runtime/bin/java`, not in the > app?s `bin` directory) for diagnostic purposes. It?s not large. > > - The resulting package would install the copyright file into > `/usr/share/doc/hello/copyright`, which is wrong -- a package that > installs into `/opt` should never touch anything under /usr [1]. This > file should be at `/opt/hello/share/doc/copyright`. > > - I attempted to install the package on a fresh Ubuntu 18.04 machine: > > # dpkg -i hello-1.0.deb > Selecting previously unselected package hello. > (Reading database ... 135670 files and directories currently installed.) > Preparing to unpack hello-1.0.deb ... > Unpacking hello (1.0) ... > Setting up hello (1.0) ... > Adding shortcut to the menu > /var/lib/dpkg/info/hello.postinst: 25: /var/lib/dpkg/info/hello.postinst: xdg-desktop-menu: not found > dpkg: error processing package hello (--install): > installed hello package post-installation script subprocess returned error exit status 127 > Errors were encountered while processing: > hello > mr-dev # uname -a > Linux mr-dev 4.15.0-1018-oracle #20-Ubuntu SMP Wed Jul 3 06:46:12 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux > mr-dev # cat /etc/lsb-release > DISTRIB_ID=Ubuntu > DISTRIB_RELEASE=18.04 > DISTRIB_CODENAME=bionic > DISTRIB_DESCRIPTION="Ubuntu 18.04.3 LTS" > # > > Apparently the package should depend upon `xdg-utils`, so that its > post-install script can find `xdg-desktop-menu`. Even better, > though, would be for this trivial non-graphical application not to > depend upon any desktop utilities, per my comment above. > > - Installing the package succeeded despite the above error. I was > successfully able to run my trivial application. Yay! > > - Then I tried to uninstall it: > > mr-dev # dpkg --remove hello > (Reading database ... 135923 files and directories currently installed.) > Removing hello (1.0) ... > Removing shortcut > /var/lib/dpkg/info/hello.prerm: 25: /var/lib/dpkg/info/hello.prerm: xdg-desktop-menu: not found > dpkg: error processing package hello (--remove): > installed hello package pre-removal script subprocess returned error exit status 127 > Errors were encountered while processing: > hello > mr-dev # > > I installed `xdg-utils` by hand to get `xdg-desktop-menu`, but it still > didn?t work: > > mr-dev # dpkg --remove hello > (Reading database ... 136878 files and directories currently installed.) > Removing hello (1.0) ... > Removing shortcut > xdg-desktop-menu: No writable system menu directory found. > dpkg: error processing package hello (--remove): > installed hello package pre-removal script subprocess returned error exit status 3 > Errors were encountered while processing: > hello > mr-dev # > > I eventually figured out how to create a fake writable system menu > directory and was then able to remove the package. > > - The `--linux-deb-copyright` option is confusing. Its description > should mention that if this option is specified then the `--license` > option is, so far as I can tell, ignored. > > - The `--identifier` option appears to have no use for Debian packages. > Perhaps this option should be package-type specific? Or at least its > description should mention that it?s irrelevant to Debian packages. > > - I tried to create a package that would install into the `/usr` > hierarchy by adding `--install-dir /usr` to the above command line. > The resulting package would create a `/usr/hello` directory, with > `app`, `bin`, and `runtime` directories under that. That?s not > right. To install an application in the `/usr` hierarchy its command > should go into `/usr/bin`, and libraries and other files should go > into `/usr/lib/$APPNAME`, and documentation and copyright files > should go into `/usr/share/doc/$APPNAME`. > > - Many of the above observations could also apply to RPM packages, but > I haven?t checked. > > Comments on macOS packaging > > (Warning: I?m not an expert macOS developer!) > > - On a macOS machine (10.13.6) I tried to create a dmg package: > > $ jpackage -o . --package-type dmg -p lib -m org.openjdk.hello/org.openjdk.hello.Main -n hello > > which gave me the error message > > Exec failed with code 1 command [[/usr/bin/SetFile, -c, icnC, /var/folders/mn/8nt00ldx7dqfrv55wk72mgq80000gr/T/jdk.jpackage9024163201922289964/images/hello/.VolumeIcon.icns] in unspecified directory output: xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun > > although it exited with status 0 and did produce a valid `.dmg` file. > I suppose I?m missing some development tools? If so then please > document that dependency, and if possible issue a more helpful error > message that tells the user what they need to install. see: JDK-8230653 > > - It?d be nice if the resulting `.dmg` file, when opened, were to show > an icon for the Applications folder and an arrow pointing to that > from the app icon, so that the user can drag it across. Almost all > `.dmg` files that I?ve seen do this. see: JDK-8230654 > > - Mark > > > [1] https://www.debian.org/doc/packaging-manuals/fhs/fhs-3.0.html#optAddonApplicationSoftwarePackages Again, thanks for the detailed feedback. /Andy From rachel at strangenoises.org Thu Sep 5 12:50:21 2019 From: rachel at strangenoises.org (Rachel Greenham) Date: Thu, 5 Sep 2019 13:50:21 +0100 Subject: Comments on jpackage (JEP 343) Message-ID: <7893861a-5295-a497-1282-51afe128f7bb@strangenoises.org> (Sorry for non-threading, i read the digest) As you've been lacking feedback from people using the jpackage EA builds, here's mine FWIW. I've been quiet because it's been working well enough for us. That said, our needs and process probably simplify matters in that: 1. We're only producing Windows installers 2. We've been lucky in having patient clients during this post-webstart, post-javapackager disruption. 3. We were happy to modify our versioning to match Windows standards 4. Our application is non-modular 5. We do it in three steps: jlink to make a JRE, then jpackage to make an app image, then jpackage again to make both an exe and msi installer based on that image. (client slow to reply which one they'd actually prefer!) Not trying to do everything in one step. Since the fix that made new versions of our app correctly replace older ones I've mostly just been testing new EA builds to make sure they don't break it! They do sometimes, usually because of changes in the parameter names, and of course we lost our Inno Setup customisations. I haven't yet made any attempt to customise the EXE setup installer since then. Would be nice: 1. For it to use the supplied app icon for the installer, or be able to supply another specifically for the installer. For it to be shown in the installer in some fashion. Other exe customisations of straightforward branding and/or flags to control what questions they're asked would be very nice. 2. For it to be able to sign the installer in the fashion of, or actually using, signtool. (Ideally internalised as installing signtool itself is a pain.) Currently that's an extra step after the installers are built But I can wait for them, I want it in a release so I can use it via ToolProvider rather than execing an external JDK. All the while it's the way it is it massively complicates the build. Later would-be-nices, not for this desktop app, but ability to use it to package background service-type apps, as a service for windows, using launchd for osx, and systemd for linux. -- Rachel From daniel.daugherty at oracle.com Thu Sep 5 13:33:02 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 5 Sep 2019 09:33:02 -0400 Subject: RFR: 8212117 : Class.forName may return a reference to a loaded but not linked Class In-Reply-To: References: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com> <4411374a-0d04-2a65-230f-d0875a981c15@oracle.com> Message-ID: <25bb09b5-bd93-d59f-863b-41594629b06c@oracle.com> On 9/5/19 1:36 AM, David Holmes wrote: > Hi Dan, > > With my CSR Group member hat on .... > > On 5/09/2019 8:06 am, Daniel D. Daugherty wrote: >> Brent, >> >> You currently have '-XX:+ClassForNameDeferLinking' as a 'product' >> option, but >> product options are harder to remove down the road. Would it be >> better as a >> diagnostic option? A diagnostic option requires > > Whether a flag is product or diagnostic (or experimental) should be a > basic property of the flag based on its purpose. I would not want to > see a trend of making new flags diagnostic just because it is easier > to get rid of them later. The expectation with this fix and flag > (which I've been heavily involved in) is that production code may be > impacted by the change and need to use the flag to restore previous > behaviour. So it really is a product flag that end users should be > comfortable in using if they need > it. This is the key phrase: > production code may be impacted by the change and need to > use the flag to restore previous behaviour. Thanks for making that clear. Maybe I missed it in what I read, but it is now clear that this should be a product flag. Dan > > The removal process for a product flag is phased (deprecate, obsolete, > expire) but not particularly onerous. There is an expectation that > this flag may be deprecated in 15 as it is intended as a transitional > flag. > > Thanks, > David > ----- > >> '-XX:+UnlockDiagnosticVMOptions' >> to be specified before it can be used, e.g.: >> >> ???? java -XX:+UnlockDiagnosticVMOptions >> -XX:+ClassForNameDeferLinking Foo >> >> so it is a bit harder to use, but maybe that's a Good Thing (TM). >> >> Dan >> >> >> On 9/4/19 5:12 PM, Brent Christian wrote: >>> Hi, >>> >>> Please review my fix for JDK-8212117[1].? The webrev is here: >>> >>> http://cr.openjdk.java.net/~bchristi/8212117/webrev09/ >>> >>> There is also a CSR[2] in need of review. >>> >>> The spec for the 2-arg and 3-arg Class.forName() methods states they >>> will "locate, load, and link" the class, however the linking part is >>> not ensured to happen. >>> >>> Although the VM spec allows flexibility WRT when classes are linked, >>> this is a corner where the Class.forName() spec is not being upheld. >>> While this is not an issue for most usages, 8181144 [3] demonstrates >>> how this can be a problem (with the debugging interface, in this case). >>> >>> This fix ensures that linking happens during the course of >>> Class.forName().? Class.forName() already @throws LinkageError, so >>> no spec change is needed there. MethodHandles.Lookup.findClass() >>> needs a small spec update, due to calling Class.forName with >>> init=false, >>> >>> Of course Errors are not required to be caught.? It is therefore >>> possible that the new behavior could introduce previously unseen, >>> possibly unhandled LinkageErrors.? A new VM flag >>> (-XX:+ClassForNameDeferLinking) is introduced to restore the >>> previous behavior (to keep such code running until it can be updated). >>> >>> This change surfaced a couple new "A JNI error has occurred" >>> situations (see 8181033[5]) in the Launcher, by way of >>> ? test/jdk/tools/launcher/MainClassCantBeLoadedTest.java >>> (using the 3-arg Class::forName, detailed in the bug report[4]), >>> and >>> ? test/jdk/tools/launcher/modules/basic/LauncherErrors.java >>> (using the 2-arg Class::forName). >>> >>> The Launcher is updated to maintain non-confusing error messages :). >>> >>> The new test included with this fix ensures that 8181144[3] is >>> addressed.? Thanks go to Serguei Spitsyn for writing the test. >>> >>> Automated corelibs and hotspot tests pass cleanly. >>> >>> Thanks, >>> -Brent >>> >>> -- >>> 1. https://bugs.openjdk.java.net/browse/JDK-8212117 >>> >>> 2. https://bugs.openjdk.java.net/browse/JDK-8222071 >>> >>> 3. https://bugs.openjdk.java.net/browse/JDK-8181144 >>> >>> 4. >>> https://bugs.openjdk.java.net/browse/JDK-8212117?focusedCommentId=14215986&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14215986 >>> >>> >>> 5. https://bugs.openjdk.java.net/browse/JDK-8181033 >>> >> From peter.levart at gmail.com Thu Sep 5 13:40:17 2019 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 5 Sep 2019 15:40:17 +0200 Subject: =?UTF-8?Q?Re=3a_Reply=ef=bc=9a_what_to_do_next_to_fix_JDK-8230557?= =?UTF-8?Q?=2e_thanks?= In-Reply-To: References: <1331cc4f-964b-ab27-4e48-4cb102b5e964@oracle.com> <10d071e9-f84c-52a7-68d5-f680f44034b5@gmail.com> Message-ID: <3ecdd746-ba23-d138-ba0b-32be0ec6878d@gmail.com> Hi ????, On 9/5/19 10:16 AM, ???? wrote: > > Hi, Peter. > > I understand your point, but I think it's unreasonable for the reason > that source code compatibility problem, it's really a bug. Unfortunately, when such bug is out in the wild for so long, it becomes a feature. It would be unreasonable to fix it the way you propose now, because all programs that use BitSet.size() method would break by such fix. It is not only source incompatible fix, but binary incompatible too. > > User can't understand why the size method return a negative number. Perhaps, if the javadoc of the method described this corner case, he/she would understand? Regards, Peter > > > Best, lamber-ken > > > ------------------??????------------------ > *???:*?"Peter Levart"; > *????:*?2019?9?5?(???) ??3:51 > *???:*?"????"<2217232293 at qq.com>;"core-libs-dev"; > *??:*?"David Holmes"; > *??:*?Re: ??? ??? what to do next to fix JDK-8230557. thanks > > Hi ????, > > As David has pointed out, your proposed fix would break binary and > source compatibility of BitSet.size() method, so it is not acceptable. > > BitSet API allows addressing individual bits using non-negative 'int' > typed indexes (analogous to indexes of Java arrays). The range of > indexes is: 0 ... 2^31 - 1 (0 ... Integer.MAX_VALUE). The maximum "size" > of BitSet is therefore 2^31. Unfortunately, this value can't be > "corectly" represented with signed 32 bit integer (int). Only in this > corner case, - 2^31 (Integer.MIN_VALUE) is the interpreted value > returned from size(). If one would interpret it as unsigned 32 bit > integer value, it is entirely correct. For example, this holds: > > Integer.toUnsignedLong(new BitSet(Integer.MAX_VALUE).size()) == 1L << 31 > > It is also always true what javadoc says about size(): "The maximum > element in the set is the size - 1st element" > > The following holds also for this corner case: > > new BitSet(Integer.MAX_VALUE).size() - 1 == Integer.MAX_VALUE; > > So perhaps, the fix could be just to describe this corner case in the > spec. And perhaps, to support the following use case in the corner case: > > BitSet set1 = ... > ... > > BitSet set2 = new BitSet(set1.size()); > > ... by modifying the BitSet constructor to accept the Integer.MIN_VALUE > in addition to all the non-negative values as the 'nbits' parameter. > > What do you think? > > Regards, Peter > > On 9/5/19 8:31 AM, David Holmes wrote: > > Hi, > > > > On 5/09/2019 4:11 pm, ???? wrote: > >> > >> Thanks very much. > >> > >> *BUG-LINK:* https://bugs.openjdk.java.net/browse/JDK-8230557 > >> > >> *Describe: * > >> the return type of the method BitSet#size is int, so the method may > >> return a negative value in some case, for example, will return > >> -2147483648. > >> ``` > >> BitSet bitSet = new BitSet(Integer.MAX_VALUE); > >> for (int i = 0; i < Integer.MAX_VALUE - 1000; i++) { > >> ?????bitSet.set(i); > >> } > >> System.out.println(bitSet.size()); > >> ``` > >> EXPECTED: 2147483648, but ACTUAL: -2147483648. > >> > >> *FIX* > >> I have put the patch in the attachment of the mail. > > > > In case the attachment got stripped form the mailing list the proposed > > fix is: > > > > -??? public int size() { > > -??????? return words.length * BITS_PER_WORD; > > +??? public long size() { > > +??????? return (long) words.length * BITS_PER_WORD; > > > > Unfortunately this simple fix it not possible. You can't just change > > the return type of the method to long as that is a source-incompatible > > change and would not be approved [1]. Instead the return value should > > be capped at Integer.MAX_VALUE - but I'll leave that for someone from > > core-libs team to pick up. Also look at the evaluation in: > > > > https://bugs.openjdk.java.net/browse/JDK-4213570 > > > > Cheers, > > David > > > > [1] https://wiki.openjdk.java.net/display/csr/CSR+FAQs > > > > > > > >> > >> ------------------??????------------------ > >> *???:*?"David Holmes"; > >> *????:*?2019?9?5?(???) ??2:00 > >> *???:*?"????"<2217232293 at qq.com>;"core-libs-dev" >> dev at openjdk.java.net>; > >> *??:*?Re: ??? what to do next to fix JDK-8230557. thanks > >> > >> On 5/09/2019 3:46 pm, ???? wrote: > >> ?> > >> ?> hi, developers. > >> ?> > >> ?> Can someone help me? thanks very much !! > >> > >> Help you how exactly. As I stated your are up to step 2 of the how to > >> contribute process. If you have a suggested fix for the bug then put > >> that in an email as described. > >> > >> Thanks, > >> David > >> > >> ?> > >> ?> ------------------??????------------------ > >> ?> *???:*?"David Holmes"; > >> ?> *????:*?2019?9?5?(???) ??1:44 > >> ?> *???:*?"????"<2217232293 at qq.com>;"core-libs-dev" >> ?> dev at openjdk.java.net>; > >> ?> *??:*?Re: what to do next to fix JDK-8230557. thanks > >> ?> > >> ?> On 5/09/2019 3:35 pm, ???? wrote: > >> ?>? > Hi, leaders. > >> ?> > >> ?> Hi, > >> ?> > >> ?> No "leaders" here only developers :) > >> ?> > >> ?>? > > >> ?>? > A few days ago, I report a bug in core lib[1]. According to the > >> ?> contribute document[2], I had send oca to oracle and my > name has > >> ?> been listed on oca[3]. > >> ?> > >> ?> Welcome aboard! > >> ?> > >> ?>? > But I still can't push my changes to jdk, can someone tell me > >> how to > >> ?> do next? thanks very match!! > >> ?> > >> ?> You can't push anything until you become a Committer and before > >> that you > >> ?> have to become an Author. The steps for contributing are outlined > >> here: > >> ?> > >> ?> http://openjdk.java.net/contribute/ > >> ?> > >> ?> and you would seem to be up to step 2. :) > >> ?> > >> ?> Cheers, > >> ?> David > >> ?> > >> ?>? > > >> ?>? > > >> ?>? > > >> ?>? > > >> ?>? > [1]https://bugs.openjdk.java.net/browse/JDK-8230557 > >> ?>? > > >> ?>? > [2]http://openjdk.java.net/contribute/ > >> ?>? > [3]https://www.oracle.com/technetwork/community/oca-486395.html > >> ?>? > > >> ?>? > > >> ?>? > > >> ?>? > > >> ?>? > > >> ?>? > ------------------ ???? ------------------ > >> ?>? > ???: "Bug Report > >> ?> Notification" >> ?>? > ????: 2019?9?5?(???) ??3:33 > >> ?>? > ???: "????"<2217232293 at qq.com>; > >> ?>? > > >> ?>? > ??: Update Notification: Bug Report - JDK-8230557 > >> ?>? > > >> ?>? > > >> ?>? > > >> ?>? > > >> ?>? ????????????????????????? [This is an automated response. Please > >> do not > >> ?> reply.] > >> ?>? > Dear Java Developer, > >> ?>? > We have finished evaluating your report and have assigned it > a Bug > >> ?> ID: JDK-8230557. The issue is visible on bugs.java.com at the > >> following > >> ?> url JDK-8230557. > >> ?>? >?????????????????? To provide more information about this issue, > >> ?> click? here. > >> ?>? >????????????????? We work to resolve the issues that are > >> submitted to > >> ?> us according to their impact to the community as a whole, and > make no > >> ?> promises as to the time or release in which a bug might be fixed. If > >> ?> this issue has a significant impact on your project you may want to > >> ?> consider using one of the technical support offerings available at > >> ?> Oracle Support. > >> ?>? >?????????????????????????????? Regards, > >> ?>? >?????????????????????????????????????? Java Developer Support > >> ?>? > > >> ?>? > > >> ?>? > > >> ?>? > > >> ?>? > > >> ?>? > Java SE > >> ?>? >?????????????????? Java SE Documentation > >> ?>? >?????????????????? Java SE Downloads > >> ?>? >?????????????????? Java Developer Forums > >> ?>? >?????????????????? Oracle Java SE Advanced > >> ?>? >?????????????????? Bug Database > >> ?>? > > >> ?> Copyright ? Oracle > >> and/or > >> ?> its affiliates. All rights reserved. > >> ?>? > > >> ?>? ????????????????????????????????? Terms of Use | > >> Privacy > >> ?>? > > From peter.levart at gmail.com Thu Sep 5 14:24:55 2019 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 5 Sep 2019 16:24:55 +0200 Subject: =?UTF-8?Q?Re=3a_Reply=ef=bc=9a_what_to_do_next_to_fix_JDK-8230557?= =?UTF-8?Q?=2e_thanks?= In-Reply-To: References: <1331cc4f-964b-ab27-4e48-4cb102b5e964@oracle.com> <10d071e9-f84c-52a7-68d5-f680f44034b5@gmail.com> Message-ID: <636ef7ed-b201-448d-59ac-f31456588315@gmail.com> Hi Ivan, On 9/5/19 11:22 AM, Ivan Gerasimov wrote: > Hello! > > BitSet is known to be flawed in many ways:? its size(), length(), > cardinality() and nextClearBit?() can return meaningless negative values. > > I was thinking about disallowing setting any index greater than > (Integer.MAX_VALUE - 63), for example by throwing OutOfMemoryError. An index of Integer.MAX_VALUE - 64 would be the greatest index then, an index of Integer.MAX_VALUE - 63 already needs an array of longs of length 2^25 which results in BitSet size() of 2^31 ... > > We could do it without changing the specification. The calls to: new BitSet(Integer.MAX_VALUE - 63) ... new BitSet(Integer.MAX_VALUE) would also have to throw then. BitSet.valueOf(...) methods don't even check the passed in arguments lengths, so size() can really return a meaningless negative or positive number. They all would have to throw if the passed-in length of array/buffer is too large. So would you not specify when those methods throw? Regards, Peter > > With kind regards, > > Ivan > > > On 9/5/19 1:16 AM, ???? wrote: >> Hi, Peter. >> >> >> I understand your point, but I think it's unreasonable for the reason >> that source code compatibility problem, it's really a bug. >> >> >> User can't understand why the size method return a negative number. >> >> >> >>   >> >> >> Best, lamber-ken >> >> >> >> >> ------------------ ???? ------------------ >> ???: "Peter Levart"> ????: 2019?9?5?(???) ??3:51 >> ???: "????"<2217232293 at qq.com>;"core-libs-dev"> >> ??: "David Holmes"> ??: Re: ??? ??? what to do next to fix JDK-8230557. thanks >> >> >> >> Hi ????, >> >> As David has pointed out, your proposed fix would break binary and >> source compatibility of BitSet.size() method, so it is not acceptable. >> >> BitSet API allows addressing individual bits using non-negative 'int' >> typed indexes (analogous to indexes of Java arrays). The range of >> indexes is: 0 ... 2^31 - 1 (0 ... Integer.MAX_VALUE). The maximum "size" >> of BitSet is therefore 2^31. Unfortunately, this value can't be >> "corectly" represented with signed 32 bit integer (int). Only in this >> corner case, - 2^31 (Integer.MIN_VALUE) is the interpreted value >> returned from size(). If one would interpret it as unsigned 32 bit >> integer value, it is entirely correct. For example, this holds: >> >> Integer.toUnsignedLong(new BitSet(Integer.MAX_VALUE).size()) == 1L << 31 >> >> It is also always true what javadoc says about size(): "The maximum >> element in the set is the size - 1st element" >> >> The following holds also for this corner case: >> >> new BitSet(Integer.MAX_VALUE).size() - 1 == Integer.MAX_VALUE; >> >> So perhaps, the fix could be just to describe this corner case in the >> spec. And perhaps, to support the following use case in the corner case: >> >> BitSet set1 = ... >> ... >> >> BitSet set2 = new BitSet(set1.size()); >> >> ... by modifying the BitSet constructor to accept the Integer.MIN_VALUE >> in addition to all the non-negative values as the 'nbits' parameter. >> >> What do you think? >> >> Regards, Peter >> >> On 9/5/19 8:31 AM, David Holmes wrote: >> > Hi, >> > >> > On 5/09/2019 4:11 pm, ???? wrote: >> >> >> >> Thanks very much. >> >> >> >> *BUG-LINK:* https://bugs.openjdk.java.net/browse/JDK-8230557 >> >> >> >> *Describe: * >> >> the return type of the method BitSet#size is int, so the >> method may >> >> return a negative value in some case, for example, will return >> >> -2147483648. >> >> ``` >> >> BitSet bitSet = new BitSet(Integer.MAX_VALUE); >> >> for (int i = 0; i < Integer.MAX_VALUE - 1000; i++) { >> >>      bitSet.set(i); >> >> } >> >> System.out.println(bitSet.size()); >> >> ``` >> >> EXPECTED: 2147483648, but ACTUAL: -2147483648. >> >> >> >> *FIX* >> >> I have put the patch in the attachment of the mail. >> > >> > In case the attachment got stripped form the mailing list the >> proposed >> > fix is: >> > >> > -    public int size() { >> > -        return words.length >> * BITS_PER_WORD; >> > +    public long size() { >> > +        return (long) >> words.length * BITS_PER_WORD; >> > >> > Unfortunately this simple fix it not possible. You can't just >> change >> > the return type of the method to long as that is a >> source-incompatible >> > change and would not be approved [1]. Instead the return value >> should >> > be capped at Integer.MAX_VALUE - but I'll leave that for someone >> from >> > core-libs team to pick up. Also look at the evaluation in: >> > >> > https://bugs.openjdk.java.net/browse/JDK-4213570 >> > >> > Cheers, >> > David >> > >> > [1] https://wiki.openjdk.java.net/display/csr/CSR+FAQs >> > >> > >> > >> >> >> >> ------------------ ???? ------------------ >> >> *???:* "David Holmes"> >> *????:* 2019?9?5?(???) ??2:00 >> >> >> *???:* "????"<2217232293 at qq.com>;"core-libs-dev"> >> dev at openjdk.java.net>; >> >> *??:* Re: ??? what to do next to fix JDK-8230557. >> thanks >> >> >> >> On 5/09/2019 3:46 pm, ???? wrote: >> >>  > >> >>  > hi, developers. >> >>  > >> >>  > Can someone help me? thanks very much !! >> >> >> >> Help you how exactly. As I stated your are up to step 2 of >> the how to >> >> contribute process. If you have a suggested fix for the bug >> then put >> >> that in an email as described. >> >> >> >> Thanks, >> >> David >> >> >> >>  > >> >>  > >> ------------------ ???? ------------------ >> >>  > *???:* "David >> Holmes"> >>  > *????:* 2019?9?5?(???) ??1:44 >> >>  > >> *???:* "????"<2217232293 at qq.com>;"core-libs-dev"> >>  > dev at openjdk.java.net>; >> >>  > *??:* Re: what to do next to fix >> JDK-8230557. thanks >> >>  > >> >>  > On 5/09/2019 3:35 pm, ???? wrote: >> >>  >  > Hi, leaders. >> >>  > >> >>  > Hi, >> >>  > >> >>  > No "leaders" here only developers :) >> >>  > >> >>  >  > >> >>  >  > A few days ago, I report a bug in core >> lib[1]. According to the >> >>  > contribute document[2], I had send oca to oracle >> and&nbsp;my name has >> >>  > been listed on&nbsp;oca[3]. >> >>  > >> >>  > Welcome aboard! >> >>  > >> >>  >  > But I still can't push my changes to >> jdk, can someone tell me >> >> how to >> >>  > do next? thanks very match!! >> >>  > >> >>  > You can't push anything until you become a >> Committer and before >> >> that you >> >>  > have to become an Author. The steps for >> contributing are outlined >> >> here: >> >>  > >> >>  > http://openjdk.java.net/contribute/ >> >>  > >> >>  > and you would seem to be up to step 2. :) >> >>  > >> >>  > Cheers, >> >>  > David >> >>  > >> >>  >  > >> >>  >  > >> >>  >  > >> >>  >  > >> >>  >  > >> [1]https://bugs.openjdk.java.net/browse/JDK-8230557 >> >>  >  > >> >>  >  > [2]http://openjdk.java.net/contribute/ >> >>  >  > >> [3]https://www.oracle.com/technetwork/community/oca-486395.html >> >>  >  > >> >>  >  > >> >>  >  > >> >>  >  > >> >>  >  > >> >>  >  > >> ------------------&nbsp;????&nbsp;------------------ >> >>  >  > ???:&nbsp;"Bug Report >> >>  > >> Notification"> >>  >  > ????:&nbsp;2019?9?5?(???) >> ??3:33 >> >>  >  > >> ???:&nbsp;"????"<2217232293 at qq.com&gt;; >> >>  >  > >> >>  >  > ??:&nbsp;Update Notification: Bug >> Report  - JDK-8230557 >> >>  >  > >> >>  >  > >> >>  >  > >> >>  >  > >> >>  >  >>                           >> [This is an automated response. Please >> >> do not >> >>  > reply.] >> >>  >  > Dear Java Developer, >> >>  >  > We have finished evaluating your >> report and have assigned it a Bug >> >>  > ID: JDK-8230557. The issue is visible on >> bugs.java.com at the >> >> following >> >>  > url JDK-8230557. >> >>  >  >> >                   >> To provide more information about this issue, >> >>  > click  here. >> >>  >  >> >                  >> We work to resolve the issues that are >> >> submitted to >> >>  > us according to their impact to the community as >> a whole, and make no >> >>  > promises as to the time or release in which a bug >> might be fixed. If >> >>  > this issue has a significant impact on your >> project you may want to >> >>  > consider using one of the technical support >> offerings available at >> >>  > Oracle Support. >> >>  >  >> >                               >> Regards, >> >>  >  >> >                                       >> Java Developer Support >> >>  >  > >> >>  >  > >> >>  >  > >> >>  >  > >> >>  >  > >> >>  >  > Java SE >> >>  >  >> >                   >> Java SE Documentation >> >>  >  >> >                   >> Java SE Downloads >> >>  >  >> >                   >> Java Developer Forums >> >>  >  >> >                   >> Oracle Java SE Advanced >> >>  >  >> >                   >> Bug Database >> >>  >  > >> >>  >  >>          >>                                    >> Copyright ? Oracle >> >> and/or >> >>  > its affiliates. All rights reserved. >> >>  >  > >> >>  >  >>                                   >> Terms of Use >> |                 >> >> Privacy >> >>  >  > > From claes.redestad at oracle.com Thu Sep 5 14:41:43 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 5 Sep 2019 16:41:43 +0200 Subject: RFR: 8230662: Remove dead code from MethodTypeForm Message-ID: <780b1e41-0de7-e7c4-a1e4-57f182f12b79@oracle.com> Hi, I noticed some unused methods in java.lang.invoke.MethodTypeForm and ended up with a rather substantial cleanup after pulling that particular thread for a bit: http://cr.openjdk.java.net/~redestad/8230662/jdk.00/ https://bugs.openjdk.java.net/browse/JDK-8230662 Testing: tier1-3 Thanks! /Claes From pavel.rappo at oracle.com Thu Sep 5 15:02:43 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 5 Sep 2019 16:02:43 +0100 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> <87sgpblxns.fsf@oldenburg2.str.redhat.com> Message-ID: <7A46485C-E250-4E57-9FB0-B9D18CA70632@oracle.com> I think we are almost there. What do you think of the following incremental (i.e. on top of your latest webrev) change? http://cr.openjdk.java.net/~prappo/8228580/webrev.01/ I fixed a couple of trivial typos and addressed the socket relinquishing issue. Initializing a socket is not an atomic "all-or-nothing" operation now. Someone needs to take care of the socket in case things go not as planned. -Pavel > On 5 Sep 2019, at 11:20, Milan Mimica wrote: > > On Wed, 4 Sep 2019 at 20:32, Florian Weimer wrote: >> >> If you use the initial UDP timeout (one second, I think), the kernel >> will not complete the TCP handshake if the initial SYN segment is lost >> because the retransmit delay during the handshake is longer than that. > > We could set a higher timeout value, but I would not prefer that. > After all, 1 second is just default value, and can be changed. If the > user wants us to give up on DNS query after the specified timeout then > lets do just that. True, some queries that previously worked might > start failing, but that is true even for slow socket.read() > operations. > > New webrev: http://cr.openjdk.java.net/~mmimica/8228580/webrev.01/ > > * simplified test with no thread (nice catch Pavel) > * set connect timeout and account for it > > -- > Milan Mimica From brian.burkhalter at oracle.com Thu Sep 5 15:11:43 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 5 Sep 2019 08:11:43 -0700 Subject: 8230342: LineNumberReader.getLineNumber() returns inconsistent results after EOF Message-ID: <553C9BEC-AC7D-4263-B785-E3C703D09819@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8230342 http://cr.openjdk.java.net/~bpb/8230342/webrev.00/ When the last line is read by readLine() the line number is incremented due to the EOF but not when read() or read(char[]) is used. The specification states it is incremented on line terminators only. The alternative solution would be to change the specification to state that the line number is also incremented on EOF even if there is no line terminator at the end of the stream. That would entail a different implementation change. Thanks, Brian From sverre.moe at gmail.com Thu Sep 5 15:12:05 2019 From: sverre.moe at gmail.com (Sverre Moe) Date: Thu, 5 Sep 2019 17:12:05 +0200 Subject: jdk-14-jpackage+1-33 on jdk.java.net In-Reply-To: References: <3d92d996-eca0-7971-0716-42b885525295@oracle.com> <36feb3a6-e24c-6239-4563-cada989f20c7@oracle.com> Message-ID: I have done some investigation myself. Found this blog post regarding ampersand in WiX: http://robmensching.com/blog/posts/2008/4/21/how-to-escape-the-ampersand-in-wix-and-msi-ui/ I tried the solution suggested there. The build works, but the vendor is not display correctly in Windows. The Publisher name shows the text "&". Same goes for using "&". Both of these seems to work on Linux for RPM and DEB package. It does not pass the escaped ampersand to jpackage, but Gradle processResourcess task seems to replace the escape ampersand with the ampersand in my DEB control resource file and RPM spec resource file. Well, the Publisher does not display correctly on Windows, but the build works, the application works. So at least we can move forward, but I hope to find the proper solution to get this working and displaying correctly. /Sverre ons. 4. sep. 2019 kl. 21:01 skrev Andy Herrick : > This is easily reproducible by putting ampersand in --vendor value on > windows. > > will investigate. > > /Andy > On 9/4/2019 8:05 AM, Sverre Moe wrote: > > Running WiX failed. > The problem it seems is the -dJpAppVendor. It cannot handle special > characters in the vendor name. Our company name uses the ampersand (&) > instead of "and". > > Caused by: java.io.IOException: Exec failed with code 104 command > [[C:\Program Files (x86)\WiX Toolset v3.11\bin\candle.exe, -nologo, > C:\cygwin64\tmp\jdk.jpackage1086156882119031648\config\application.wxs, > -ext, WixUtilExtension, -out, > C:\cygwin64\tmp\jdk.jpackage1086156882119031648\tmp\application.wixobj, > -dJpAppDescription=application, -dJpAppVersion=1.1.0, > -dJpWixVersion36OrNewer=yes, > -dJpProductCode=2fa37b54-8365-437d-ad34-ceed92844d22, > -dJpAppName=application, > -dJpProductUpgradeCode=53c0f7f6-75c1-419a-86c5-bef18dda408a, > -dJpIsSystemWide=yes, -dJpAppVendor=Kongsberg Defence & Aerospace, > -dJpConfigDir=C:\cygwin64\tmp\jdk.jpackage1086156882119031648\config] in > C:\cygwin64\tmp\jdk.jpackage1086156882119031648\images\win-msi.image\application > output: > application.wxsC:\cygwin64\tmp\jdk.jpackage1086156882119031648\config\application.wxs(56) > : error CNDL0104 : Not a valid source file; detail: An error occurred while > parsing EntityName. Line 9, position 68. > > Is there anyway to allow special characters in the vendor name? > > > It would be very useful to be able to define the release, in addition to > the version. This is currently only possible on Linux with > "--linux-app-release". > > I could have hacked this by setting "--app-version" to VERSION-RELEASE. It > would increase the special logic in the build script specific for Windows, > but it does not seem to be allowed with release in the version > string: Version string is not compatible with MSI rules > [1.1.0-SNAPSHOT20190904133731] > https://docs.microsoft.com/en-us/windows/win32/msi/productversion > > Could this potentially cause problems when installing SNAPSHOTs which have > the same version? > Anyway it does not seem WiX XML schema has any release or build attributes. > > /Sverre > > > tor. 29. aug. 2019 kl. 17:38 skrev Sverre Moe : > >> No, have not installed WIX. Had InnoSetup from when we use javapackager. >> I will look into the WiX: https://wixtoolset.org >> >> /Sverre >> >> tor. 29. aug. 2019 kl. 17:34 skrev Kevin Rushforth < >> kevin.rushforth at oracle.com>: >> >>> Hi Sverre, >>> >>> Do you have a WiX installed on your machine? That is a prerequisite. >>> >>> Andy: Do we have a bug filed to produce a better error message in this >>> case? If not, we need to file one. >>> >>> -- Kevin >>> >>> >>> On 8/29/2019 7:30 AM, Sverre Moe wrote: >>> >>> It is not working creating native installer on Windows. >>> >>> It will not take neither exe nor msi as --package-type on Windows. >>> jdk.jpackage.internal.PackagerException: Error: Invalid or unsupported >>> package type: [exe]. >>> at >>> jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:614) >>> at >>> jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:513) >>> at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:97) >>> at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:51) >>> >>> The jpackage help output on Windows lists both exe and msi as valid >>> package types. >>> >>> The JDK-8228660 is marked as resolved. I reckon it will make it into the >>> next build. >>> >>> /Sverre >>> >>> >>> tor. 22. aug. 2019 kl. 02:03 skrev Kevin Rushforth < >>> kevin.rushforth at oracle.com>: >>> >>>> We believe that we have addressed most of the issues, especially those >>>> affecting the generated Linux packages, both .deb and .rpm. There is >>>> one >>>> open issue around the naming of the Debian packages that we will >>>> address >>>> in the next EA release. See JDK-8228660 [1] for more information. >>>> >>>> We would love to get some feedback from Linux developers to make sure >>>> that we didn't miss anything else. >>>> >>>> Thanks. >>>> >>>> -- Kevin >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8228660 >>>> >>>> >>>> On 8/21/2019 3:27 PM, Andy Herrick wrote: >>>> > The next EA build of JPackage is available at >>>> > https://jdk.java.net/jpackage/ >>>> > >>>> > This build ( jdk-14-jpackage+1-33 ) (2019/8/20) is the next early >>>> > access release based on JDK-14 >>>> > >>>> > This release contains fixes to the following issues: >>>> > >>>> > JDK-8229788 Error dialog displays with DLL issue when installing >>>> > WinChooserTest application >>>> > JDK-8225447 Revise Debian packaging >>>> > JDK-8213941 Debian linux problems in JavaPackager >>>> > JDK-8229334 jpackage .exe packages cannot be executed due to >>>> > missing DLL >>>> > JDK-8227058 Regressions related to no longer setting user.dir >>>> > JDK-8226599 use code coverage results to remove dead code >>>> > JDK-8226191 jpackager --license-file option broken on windows for >>>> > jdk installers. >>>> > JDK-8215381 Investigate if current implementation of >>>> > --license-file is correct for Debian packages >>>> > JDK-8229138 Add --linux-app-release option for DEB and RPM >>>> packages >>>> > JDK-8229791 Code clean up regressions >>>> > JDK-8229786 No output after WinShortcutTest.exe is launched >>>> > JDK-8229750 Fix bad merge of JDK-8215447 patch >>>> > JDK-8215446 JPackageCreateInstallerInstallDirTest fails on OLE7 >>>> > JDK-8215447 Investigate if current implementation of >>>> > --license-file is correct for RPM packages >>>> > JDK-8227172 revert JDK-8225569 on windows >>>> > JDK-8224788 jpackage fails on OS X when using --runtime-image >>>> > JDK-8229252 Add descriptions to Windows jtreg tests >>>> > JDK-8228744 file associations broken on linux. >>>> > JDK-8227312 Remove pkg bundle from DMG image. >>>> > JDK-8228722 jpackage RPM tests fail on some versions of rpmbuild >>>> > JDK-8222778 Packaging Tool (JEP 343) on Linux/AArch64 >>>> > JDK-8224627 Creating installer with --runtime-image on OS X fails >>>> > JDK-8226904 current working directory wrong running jpackage app >>>> > JDK-8224486 Arguments from jpackager cfg file not processed >>>> correctly >>>> > JDK-8226835 Command window pops up building exe package >>>> > JDK-8225092 Several jpackage tests failed when run with jcov >>>> enabled >>>> > >>>> > /Andy >>>> > >>>> >>>> >>> From milan.mimica at gmail.com Thu Sep 5 10:20:59 2019 From: milan.mimica at gmail.com (Milan Mimica) Date: Thu, 5 Sep 2019 12:20:59 +0200 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: <87sgpblxns.fsf@oldenburg2.str.redhat.com> References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> <87sgpblxns.fsf@oldenburg2.str.redhat.com> Message-ID: On Wed, 4 Sep 2019 at 20:32, Florian Weimer wrote: > > If you use the initial UDP timeout (one second, I think), the kernel > will not complete the TCP handshake if the initial SYN segment is lost > because the retransmit delay during the handshake is longer than that. We could set a higher timeout value, but I would not prefer that. After all, 1 second is just default value, and can be changed. If the user wants us to give up on DNS query after the specified timeout then lets do just that. True, some queries that previously worked might start failing, but that is true even for slow socket.read() operations. New webrev: http://cr.openjdk.java.net/~mmimica/8228580/webrev.01/ * simplified test with no thread (nice catch Pavel) * set connect timeout and account for it -- Milan Mimica From 2217232293 at qq.com Thu Sep 5 16:07:03 2019 From: 2217232293 at qq.com (=?utf-8?B?5pyq5p2l6Ziz5YWJ?=) Date: Fri, 6 Sep 2019 00:07:03 +0800 Subject: =?utf-8?B?UmVwbHnvvJogd2hhdCB0byBkbyBuZXh0IHRvIGZp?= =?utf-8?B?eCBKREstODIzMDU1Ny4gdGhhbmtz?= In-Reply-To: <636ef7ed-b201-448d-59ac-f31456588315@gmail.com> References: <1331cc4f-964b-ab27-4e48-4cb102b5e964@oracle.com> <10d071e9-f84c-52a7-68d5-f680f44034b5@gmail.com> <636ef7ed-b201-448d-59ac-f31456588315@gmail.com> Message-ID: Hi, can we make `size()` and `length()` as deprecated, then write new methods ? Best. ------------------ ???? ------------------ ???: "Peter Levart" References: <7893861a-5295-a497-1282-51afe128f7bb@strangenoises.org> Message-ID: Hi Rachel, Thank you for your feedback. I created https://bugs.openjdk.java.net/browse/JDK-8230668 record to track work on your suggestions. - Alexey On 9/5/2019 8:50 AM, Rachel Greenham wrote: > (Sorry for non-threading, i read the digest) > > As you've been lacking feedback from people using the jpackage EA > builds, here's mine FWIW. > > I've been quiet because it's been working well enough for us. That > said, our needs and process probably simplify matters in that: > > 1. We're only producing Windows installers > 2. We've been lucky in having patient clients during this > post-webstart, post-javapackager disruption. > 3. We were happy to modify our versioning to match Windows standards > 4. Our application is non-modular > 5. We do it in three steps: jlink to make a JRE, then jpackage to make > an app image, then jpackage again to make both an exe and msi > installer based on that image. (client slow to reply which one they'd > actually prefer!) Not trying to do everything in one step. > > Since the fix that made new versions of our app correctly replace > older ones I've mostly just been testing new EA builds to make sure > they don't break it! They do sometimes, usually because of changes in > the parameter names, and of course we lost our Inno Setup > customisations. I haven't yet made any attempt to customise the EXE > setup installer since then. > > Would be nice: > > 1. For it to use the supplied app icon for the installer, or be able > to supply another specifically for the installer. For it to be shown > in the installer in some fashion. Other exe customisations of > straightforward branding and/or flags to control what questions > they're asked would be very nice. > 2. For it to be able to sign the installer in the fashion of, or > actually using, signtool. (Ideally internalised as installing signtool > itself is a pain.) Currently that's an extra step after the installers > are built > > But I can wait for them, I want it in a release so I can use it via > ToolProvider rather than execing an external JDK. All the while it's > the way it is it massively complicates the build. > > Later would-be-nices, not for this desktop app, but ability to use it > to package background service-type apps, as a service for windows, > using launchd for osx, and systemd for linux. > From fweimer at redhat.com Thu Sep 5 16:59:16 2019 From: fweimer at redhat.com (Florian Weimer) Date: Thu, 05 Sep 2019 18:59:16 +0200 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: (Milan Mimica's message of "Thu, 5 Sep 2019 12:20:59 +0200") References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> <87sgpblxns.fsf@oldenburg2.str.redhat.com> Message-ID: <87woemhe6z.fsf@oldenburg2.str.redhat.com> * Milan Mimica: > On Wed, 4 Sep 2019 at 20:32, Florian Weimer wrote: >> >> If you use the initial UDP timeout (one second, I think), the kernel >> will not complete the TCP handshake if the initial SYN segment is lost >> because the retransmit delay during the handshake is longer than that. > > We could set a higher timeout value, but I would not prefer that. > After all, 1 second is just default value, and can be changed. If the > user wants us to give up on DNS query after the specified timeout then > lets do just that. But I think in the UDP case, the client will retry. I think the total timeout in the TCP case should equal the total timeout in the UDP case. That's what I'm going to implement for glibc. The difference is that in the TCP case, the TCP stack will take care of the retries, not the application code. Thanks, Florian From ivan.gerasimov at oracle.com Thu Sep 5 17:20:29 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 5 Sep 2019 10:20:29 -0700 Subject: =?UTF-8?Q?Re=3a_Reply=ef=bc=9a_what_to_do_next_to_fix_JDK-8230557?= =?UTF-8?Q?=2e_thanks?= In-Reply-To: <636ef7ed-b201-448d-59ac-f31456588315@gmail.com> References: <1331cc4f-964b-ab27-4e48-4cb102b5e964@oracle.com> <10d071e9-f84c-52a7-68d5-f680f44034b5@gmail.com> <636ef7ed-b201-448d-59ac-f31456588315@gmail.com> Message-ID: <31836150-90ac-7c22-9339-f34e4b39e38d@oracle.com> Hi Peter! On 9/5/19 7:24 AM, Peter Levart wrote: > Hi Ivan, > > On 9/5/19 11:22 AM, Ivan Gerasimov wrote: >> Hello! >> >> BitSet is known to be flawed in many ways:? its size(), length(), >> cardinality() and nextClearBit?() can return meaningless negative >> values. >> >> I was thinking about disallowing setting any index greater than >> (Integer.MAX_VALUE - 63), for example by throwing OutOfMemoryError. > > An index of Integer.MAX_VALUE - 64 would be the greatest index then, > an index of Integer.MAX_VALUE - 63 already needs an array of longs of > length 2^25 which results in BitSet size() of 2^31 ... > >> >> We could do it without changing the specification. > > The calls to: new BitSet(Integer.MAX_VALUE - 63) ... new > BitSet(Integer.MAX_VALUE) would also have to throw then. > BitSet.valueOf(...) methods don't even check the passed in arguments > lengths, so size() can really return a meaningless negative or > positive number. They all would have to throw if the passed-in length > of array/buffer is too large. > > So would you not specify when those methods throw? > Yes.? My point was that any method that requires memory allocation should be expected to possibly throw OOM, so we don't have to specify it explicitly. A similar thing happened with compact Strings, for example.? When the internal storage was changed to byte[] array, all of a sudden, it became impossible to create UTF16 Strings (or StringBuilders) of length > (Integer.MAX_VALUE / 2). W.r.t. BitSet, personally, I would rather not fix its current behavior unless there is a very strong demand for the change. Just wanted to mention one approach, which would limit usage of this class to the boundaries it was originally designed for. With kind regards, Ivan > Regards, Peter > >> >> With kind regards, >> >> Ivan >> >> >> On 9/5/19 1:16 AM, ???? wrote: >>> Hi, Peter. >>> >>> >>> I understand your point, but I think it's unreasonable for the >>> reason that source code compatibility problem, it's really a bug. >>> >>> >>> User can't understand why the size method return a negative number. >>> >>> >>> >>>   >>> >>> >>> Best, lamber-ken >>> >>> >>> >>> >>> ------------------ ???? ------------------ >>> ???: "Peter Levart">> ????: 2019?9?5?(???) ??3:51 >>> ???: "????"<2217232293 at qq.com>;"core-libs-dev">> >>> ??: "David Holmes">> ??: Re: ??? ??? what to do next to fix JDK-8230557. thanks >>> >>> >>> >>> Hi ????, >>> >>> As David has pointed out, your proposed fix would break binary and >>> source compatibility of BitSet.size() method, so it is not acceptable. >>> >>> BitSet API allows addressing individual bits using non-negative 'int' >>> typed indexes (analogous to indexes of Java arrays). The range of >>> indexes is: 0 ... 2^31 - 1 (0 ... Integer.MAX_VALUE). The maximum >>> "size" >>> of BitSet is therefore 2^31. Unfortunately, this value can't be >>> "corectly" represented with signed 32 bit integer (int). Only in this >>> corner case, - 2^31 (Integer.MIN_VALUE) is the interpreted value >>> returned from size(). If one would interpret it as unsigned 32 bit >>> integer value, it is entirely correct. For example, this holds: >>> >>> Integer.toUnsignedLong(new BitSet(Integer.MAX_VALUE).size()) == 1L >>> << 31 >>> >>> It is also always true what javadoc says about size(): "The maximum >>> element in the set is the size - 1st element" >>> >>> The following holds also for this corner case: >>> >>> new BitSet(Integer.MAX_VALUE).size() - 1 == Integer.MAX_VALUE; >>> >>> So perhaps, the fix could be just to describe this corner case in the >>> spec. And perhaps, to support the following use case in the corner >>> case: >>> >>> BitSet set1 = ... >>> ... >>> >>> BitSet set2 = new BitSet(set1.size()); >>> >>> ... by modifying the BitSet constructor to accept the Integer.MIN_VALUE >>> in addition to all the non-negative values as the 'nbits' parameter. >>> >>> What do you think? >>> >>> Regards, Peter >>> >>> On 9/5/19 8:31 AM, David Holmes wrote: >>> > Hi, >>> > >>> > On 5/09/2019 4:11 pm, ???? wrote: >>> >> >>> >> Thanks very much. >>> >> >>> >> *BUG-LINK:* https://bugs.openjdk.java.net/browse/JDK-8230557 >>> >> >>> >> *Describe: * >>> >> the return type of the method BitSet#size is int, so the >>> method may >>> >> return a negative value in some case, for example, will return >>> >> -2147483648. >>> >> ``` >>> >> BitSet bitSet = new BitSet(Integer.MAX_VALUE); >>> >> for (int i = 0; i < Integer.MAX_VALUE - 1000; i++) { >>> >>      bitSet.set(i); >>> >> } >>> >> System.out.println(bitSet.size()); >>> >> ``` >>> >> EXPECTED: 2147483648, but ACTUAL: -2147483648. >>> >> >>> >> *FIX* >>> >> I have put the patch in the attachment of the mail. >>> > >>> > In case the attachment got stripped form the mailing list the >>> proposed >>> > fix is: >>> > >>> > -    public int size() { >>> > -        return words.length >>> * BITS_PER_WORD; >>> > +    public long size() { >>> > +        return (long) >>> words.length * BITS_PER_WORD; >>> > >>> > Unfortunately this simple fix it not possible. You can't just >>> change >>> > the return type of the method to long as that is a >>> source-incompatible >>> > change and would not be approved [1]. Instead the return value >>> should >>> > be capped at Integer.MAX_VALUE - but I'll leave that for >>> someone from >>> > core-libs team to pick up. Also look at the evaluation in: >>> > >>> > https://bugs.openjdk.java.net/browse/JDK-4213570 >>> > >>> > Cheers, >>> > David >>> > >>> > [1] https://wiki.openjdk.java.net/display/csr/CSR+FAQs >>> > >>> > >>> > >>> >> >>> >> ------------------ ???? ------------------ >>> >> *???:* "David Holmes">> >> *????:* 2019?9?5?(???) ??2:00 >>> >> >>> *???:* "????"<2217232293 at qq.com>;"core-libs-dev">> >> dev at openjdk.java.net>; >>> >> *??:* Re: ??? what to do next to fix JDK-8230557. >>> thanks >>> >> >>> >> On 5/09/2019 3:46 pm, ???? wrote: >>> >>  > >>> >>  > hi, developers. >>> >>  > >>> >>  > Can someone help me? thanks very much !! >>> >> >>> >> Help you how exactly. As I stated your are up to step 2 of >>> the how to >>> >> contribute process. If you have a suggested fix for the bug >>> then put >>> >> that in an email as described. >>> >> >>> >> Thanks, >>> >> David >>> >> >>> >>  > >>> >>  > >>> ------------------ ???? ------------------ >>> >>  > *???:* "David >>> Holmes">> >>  > *????:* 2019?9?5?(???) ??1:44 >>> >>  > >>> *???:* "????"<2217232293 at qq.com>;"core-libs-dev">> >>  > dev at openjdk.java.net>; >>> >>  > *??:* Re: what to do next to fix >>> JDK-8230557. thanks >>> >>  > >>> >>  > On 5/09/2019 3:35 pm, ???? wrote: >>> >>  >  > Hi, leaders. >>> >>  > >>> >>  > Hi, >>> >>  > >>> >>  > No "leaders" here only developers :) >>> >>  > >>> >>  >  > >>> >>  >  > A few days ago, I report a bug in >>> core lib[1]. According to the >>> >>  > contribute document[2], I had send oca to oracle >>> and&nbsp;my name has >>> >>  > been listed on&nbsp;oca[3]. >>> >>  > >>> >>  > Welcome aboard! >>> >>  > >>> >>  >  > But I still can't push my changes to >>> jdk, can someone tell me >>> >> how to >>> >>  > do next? thanks very match!! >>> >>  > >>> >>  > You can't push anything until you become a >>> Committer and before >>> >> that you >>> >>  > have to become an Author. The steps for >>> contributing are outlined >>> >> here: >>> >>  > >>> >>  > http://openjdk.java.net/contribute/ >>> >>  > >>> >>  > and you would seem to be up to step 2. :) >>> >>  > >>> >>  > Cheers, >>> >>  > David >>> >>  > >>> >>  >  > >>> >>  >  > >>> >>  >  > >>> >>  >  > >>> >>  >  > >>> [1]https://bugs.openjdk.java.net/browse/JDK-8230557 >>> >>  >  > >>> >>  >  > [2]http://openjdk.java.net/contribute/ >>> >>  >  > >>> [3]https://www.oracle.com/technetwork/community/oca-486395.html >>> >>  >  > >>> >>  >  > >>> >>  >  > >>> >>  >  > >>> >>  >  > >>> >>  >  > >>> ------------------&nbsp;????&nbsp;------------------ >>> >>  >  > ???:&nbsp;"Bug Report >>> >>  > >>> Notification">> >>  >  > ????:&nbsp;2019?9?5?(???) >>> ??3:33 >>> >>  >  > >>> ???:&nbsp;"????"<2217232293 at qq.com&gt;; >>> >>  >  > >>> >>  >  > ??:&nbsp;Update Notification: Bug >>> Report  - JDK-8230557 >>> >>  >  > >>> >>  >  > >>> >>  >  > >>> >>  >  > >>> >>  >  >>>                           >>> [This is an automated response. Please >>> >> do not >>> >>  > reply.] >>> >>  >  > Dear Java Developer, >>> >>  >  > We have finished evaluating your >>> report and have assigned it a Bug >>> >>  > ID: JDK-8230557. The issue is visible on >>> bugs.java.com at the >>> >> following >>> >>  > url JDK-8230557. >>> >>  >  >>> >                   >>> To provide more information about this issue, >>> >>  > click  here. >>> >>  >  >>> >                  >>> We work to resolve the issues that are >>> >> submitted to >>> >>  > us according to their impact to the community as >>> a whole, and make no >>> >>  > promises as to the time or release in which a >>> bug might be fixed. If >>> >>  > this issue has a significant impact on your >>> project you may want to >>> >>  > consider using one of the technical support >>> offerings available at >>> >>  > Oracle Support. >>> >>  >  >>> >                               >>> Regards, >>> >>  >  >>> >                                       >>> Java Developer Support >>> >>  >  > >>> >>  >  > >>> >>  >  > >>> >>  >  > >>> >>  >  > >>> >>  >  > Java SE >>> >>  >  >>> >                   >>> Java SE Documentation >>> >>  >  >>> >                   >>> Java SE Downloads >>> >>  >  >>> >                   >>> Java Developer Forums >>> >>  >  >>> >                   >>> Oracle Java SE Advanced >>> >>  >  >>> >                   >>> Bug Database >>> >>  >  > >>> >>  >  >>>          >>>                                    >>> Copyright ? Oracle >>> >> and/or >>> >>  > its affiliates. All rights reserved. >>> >>  >  > >>> >>  >  >>>                                   >>> Terms of Use >>> |                 >>> >> Privacy >>> >>  >  > >> > > -- With kind regards, Ivan Gerasimov From julia.boes at oracle.com Thu Sep 5 18:28:05 2019 From: julia.boes at oracle.com (Julia Boes) Date: Thu, 5 Sep 2019 19:28:05 +0100 Subject: RFR: 8230648: Replace @exception tag with @throws in java.base In-Reply-To: References: <358c8542-6fdf-fce4-bd77-0a51f81d9d64@oracle.com> <38ab81e8-2042-2b57-238d-61553e8bdf40@oracle.com> Message-ID: <7ca98a57-d4c5-f841-7c5b-bb24a9e58434@oracle.com> Hi, Thanks for your comments, Lance and Pavel. The copyright will be updated before pushing, as Daniel suggested. To address the tag alignment, I adjusted the replacement from '@exception' -> '@throws' to '@exception' -> 'throws?? ', where the added whitespace preserves the original alignment. This doesn't improve the alignment (which is not consistent in many places) but at least doesn't make it worse. Updated webrev: http://cr.openjdk.java.net/~dfuchs/jboes/8230648/webrev.02/ Regarding Pavel's comment: 8157682: @inheritDoc doesn't work with @exception I ran specdiff on the whole JDK and it didn't flag any differences but I'll look into additional comparison options. Cheers, Julia From sverre.moe at gmail.com Thu Sep 5 19:00:43 2019 From: sverre.moe at gmail.com (Sverre Moe) Date: Thu, 5 Sep 2019 21:00:43 +0200 Subject: jdk-14-jpackage+1-33 on jdk.java.net In-Reply-To: References: <3d92d996-eca0-7971-0716-42b885525295@oracle.com> <36feb3a6-e24c-6239-4563-cada989f20c7@oracle.com> Message-ID: Problem with running WiX through a Continuous Integration Build System. It works perfectly fine logging into the Windows desktop with remote desktop, open my Cygwin console and execute Gradle. Our Jenkins CI runs into a problem at the end when WiX is running validation on the built installer. > WiX v3, Light automatically runs validation-- Windows Installer Internal Consistency Evaluators (ICEs) --after every successful build. https://stackoverflow.com/questions/1064580/wix-3-0-throws-error-217-while-being-executed-by-continuous-integration Some has suggested to disable the validation, but that is not a good solution in my opinion. A workaround I attempted which works without meddling with the WiX configuration, was to change the build user Jenkins uses to log onto the Windows build agent. I changed its user type from Standard to Administrator. Not sure why it would work, as I had run the jpackage+wix using the same standard user through remote desktop. Perhaps some permissions it didn't get while running in a headless environment. Generating MSI: C:\Users\build\jdk.jpackage4130052721241789652\images\win-exe.image\application-1.1.0.msi. Running [C:\Program Files (x86)\WiX Toolset v3.11\bin\light.exe, -nologo, -spdb, C:\Users\build\jdk.jpackage4130052721241789652\tmp\application.wixobj, -ext, WixUtilExtension, -loc, C:\Users\build\jdk.jpackage4130052721241789652\config\MsiInstallerStrings_en.wxl, -out, C:\Users\build\jdk.jpackage4130052721241789652\images\win-exe.image\application-1.1.0.msi] in C:\Users\build\jdk.jpackage4130052721241789652\images\win-msi.image\application light.exe : error LGHT0217 : Error executing ICE action 'ICE01'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wixtoolset.org/documentation/error217/ for details and how to solve this problem. The following string format was not expected by the external UI message logger: "The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.". Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.".light.exe : error LGHT0216 : An unexpected Win32 exception with error code 0x643 occurred: Action - 'ICE09' Fatal error during installation at jdk.jpackage/jdk.jpackage.internal.IOUtils.exec(IOUtils.java:211) at jdk.jpackage/jdk.jpackage.internal.IOUtils.exec(IOUtils.java:181) at jdk.jpackage/jdk.jpackage.internal.WinMsiBundler.buildMSI(WinMsiBundler.java:1093) at jdk.jpackage/jdk.jpackage.internal.WinMsiBundler.bundle(WinMsiBundler.java:518) at jdk.jpackage/jdk.jpackage.internal.WinExeBundler.bundle(WinExeBundler.java:105) at jdk.jpackage/jdk.jpackage.internal.WinExeBundler.execute(WinExeBundler.java:83) at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:620) at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:513) at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:97) at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:51) tor. 5. sep. 2019 kl. 17:12 skrev Sverre Moe : > I have done some investigation myself. > > Found this blog post regarding ampersand in WiX: > > http://robmensching.com/blog/posts/2008/4/21/how-to-escape-the-ampersand-in-wix-and-msi-ui/ > > I tried the solution suggested there. The build works, but the vendor is > not display correctly in Windows. > The Publisher name shows the text "&". Same goes for using "&". > > Both of these seems to work on Linux for RPM and DEB package. It does not > pass the escaped ampersand to jpackage, but Gradle processResourcess task > seems to replace the escape ampersand with the ampersand in my DEB control > resource file and RPM spec resource file. > > Well, the Publisher does not display correctly on Windows, but the build > works, the application works. So at least we can move forward, but I hope > to find the proper solution to get this working and displaying correctly. > > /Sverre > > > ons. 4. sep. 2019 kl. 21:01 skrev Andy Herrick : > >> This is easily reproducible by putting ampersand in --vendor value on >> windows. >> >> will investigate. >> >> /Andy >> On 9/4/2019 8:05 AM, Sverre Moe wrote: >> >> Running WiX failed. >> The problem it seems is the -dJpAppVendor. It cannot handle special >> characters in the vendor name. Our company name uses the ampersand (&) >> instead of "and". >> >> Caused by: java.io.IOException: Exec failed with code 104 command >> [[C:\Program Files (x86)\WiX Toolset v3.11\bin\candle.exe, -nologo, >> C:\cygwin64\tmp\jdk.jpackage1086156882119031648\config\application.wxs, >> -ext, WixUtilExtension, -out, >> C:\cygwin64\tmp\jdk.jpackage1086156882119031648\tmp\application.wixobj, >> -dJpAppDescription=application, -dJpAppVersion=1.1.0, >> -dJpWixVersion36OrNewer=yes, >> -dJpProductCode=2fa37b54-8365-437d-ad34-ceed92844d22, >> -dJpAppName=application, >> -dJpProductUpgradeCode=53c0f7f6-75c1-419a-86c5-bef18dda408a, >> -dJpIsSystemWide=yes, -dJpAppVendor=Kongsberg Defence & Aerospace, >> -dJpConfigDir=C:\cygwin64\tmp\jdk.jpackage1086156882119031648\config] in >> C:\cygwin64\tmp\jdk.jpackage1086156882119031648\images\win-msi.image\application >> output: >> application.wxsC:\cygwin64\tmp\jdk.jpackage1086156882119031648\config\application.wxs(56) >> : error CNDL0104 : Not a valid source file; detail: An error occurred while >> parsing EntityName. Line 9, position 68. >> >> Is there anyway to allow special characters in the vendor name? >> >> >> It would be very useful to be able to define the release, in addition to >> the version. This is currently only possible on Linux with >> "--linux-app-release". >> >> I could have hacked this by setting "--app-version" to VERSION-RELEASE. >> It would increase the special logic in the build script specific for >> Windows, but it does not seem to be allowed with release in the version >> string: Version string is not compatible with MSI rules >> [1.1.0-SNAPSHOT20190904133731] >> https://docs.microsoft.com/en-us/windows/win32/msi/productversion >> >> Could this potentially cause problems when installing SNAPSHOTs which >> have the same version? >> Anyway it does not seem WiX XML schema has any release or build >> attributes. >> >> /Sverre >> >> >> tor. 29. aug. 2019 kl. 17:38 skrev Sverre Moe : >> >>> No, have not installed WIX. Had InnoSetup from when we use javapackager. >>> I will look into the WiX: https://wixtoolset.org >>> >>> /Sverre >>> >>> tor. 29. aug. 2019 kl. 17:34 skrev Kevin Rushforth < >>> kevin.rushforth at oracle.com>: >>> >>>> Hi Sverre, >>>> >>>> Do you have a WiX installed on your machine? That is a prerequisite. >>>> >>>> Andy: Do we have a bug filed to produce a better error message in this >>>> case? If not, we need to file one. >>>> >>>> -- Kevin >>>> >>>> >>>> On 8/29/2019 7:30 AM, Sverre Moe wrote: >>>> >>>> It is not working creating native installer on Windows. >>>> >>>> It will not take neither exe nor msi as --package-type on Windows. >>>> jdk.jpackage.internal.PackagerException: Error: Invalid or unsupported >>>> package type: [exe]. >>>> at >>>> jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:614) >>>> at >>>> jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:513) >>>> at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:97) >>>> at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:51) >>>> >>>> The jpackage help output on Windows lists both exe and msi as valid >>>> package types. >>>> >>>> The JDK-8228660 is marked as resolved. I reckon it will make it into >>>> the next build. >>>> >>>> /Sverre >>>> >>>> >>>> tor. 22. aug. 2019 kl. 02:03 skrev Kevin Rushforth < >>>> kevin.rushforth at oracle.com>: >>>> >>>>> We believe that we have addressed most of the issues, especially those >>>>> affecting the generated Linux packages, both .deb and .rpm. There is >>>>> one >>>>> open issue around the naming of the Debian packages that we will >>>>> address >>>>> in the next EA release. See JDK-8228660 [1] for more information. >>>>> >>>>> We would love to get some feedback from Linux developers to make sure >>>>> that we didn't miss anything else. >>>>> >>>>> Thanks. >>>>> >>>>> -- Kevin >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8228660 >>>>> >>>>> >>>>> On 8/21/2019 3:27 PM, Andy Herrick wrote: >>>>> > The next EA build of JPackage is available at >>>>> > https://jdk.java.net/jpackage/ >>>>> > >>>>> > This build ( jdk-14-jpackage+1-33 ) (2019/8/20) is the next early >>>>> > access release based on JDK-14 >>>>> > >>>>> > This release contains fixes to the following issues: >>>>> > >>>>> > JDK-8229788 Error dialog displays with DLL issue when installing >>>>> > WinChooserTest application >>>>> > JDK-8225447 Revise Debian packaging >>>>> > JDK-8213941 Debian linux problems in JavaPackager >>>>> > JDK-8229334 jpackage .exe packages cannot be executed due to >>>>> > missing DLL >>>>> > JDK-8227058 Regressions related to no longer setting user.dir >>>>> > JDK-8226599 use code coverage results to remove dead code >>>>> > JDK-8226191 jpackager --license-file option broken on windows >>>>> for >>>>> > jdk installers. >>>>> > JDK-8215381 Investigate if current implementation of >>>>> > --license-file is correct for Debian packages >>>>> > JDK-8229138 Add --linux-app-release option for DEB and RPM >>>>> packages >>>>> > JDK-8229791 Code clean up regressions >>>>> > JDK-8229786 No output after WinShortcutTest.exe is launched >>>>> > JDK-8229750 Fix bad merge of JDK-8215447 patch >>>>> > JDK-8215446 JPackageCreateInstallerInstallDirTest fails on OLE7 >>>>> > JDK-8215447 Investigate if current implementation of >>>>> > --license-file is correct for RPM packages >>>>> > JDK-8227172 revert JDK-8225569 on windows >>>>> > JDK-8224788 jpackage fails on OS X when using --runtime-image >>>>> > JDK-8229252 Add descriptions to Windows jtreg tests >>>>> > JDK-8228744 file associations broken on linux. >>>>> > JDK-8227312 Remove pkg bundle from DMG image. >>>>> > JDK-8228722 jpackage RPM tests fail on some versions of rpmbuild >>>>> > JDK-8222778 Packaging Tool (JEP 343) on Linux/AArch64 >>>>> > JDK-8224627 Creating installer with --runtime-image on OS X fails >>>>> > JDK-8226904 current working directory wrong running jpackage app >>>>> > JDK-8224486 Arguments from jpackager cfg file not processed >>>>> correctly >>>>> > JDK-8226835 Command window pops up building exe package >>>>> > JDK-8225092 Several jpackage tests failed when run with jcov >>>>> enabled >>>>> > >>>>> > /Andy >>>>> > >>>>> >>>>> >>>> From ivan.gerasimov at oracle.com Thu Sep 5 20:16:46 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 5 Sep 2019 13:16:46 -0700 Subject: RFR 8230365 : Pattern for a control-char matches non-control characters In-Reply-To: References: <4f81d7bb-3e2b-337a-2f53-a4bc71049d62@oracle.com> <98993cd0-27f8-cda4-ce3b-52d21564a246@oracle.com> Message-ID: Hello Bernd! Thank you for your comments! I'm going to proceed with only the restriction part of the change for now, so no blind conversion of lower-case control chars will happen. A system property will allow the users to return to the previous less restrictive behavior, should they decide to keep malformed patterns unchanged. I'll post the updated webrev and CSR request shortly. With kind regards, Ivan On 9/4/19 10:54 PM, Bernd Eckenfels wrote: > Hallo, > > Since not all combinations make sense (Exception+convert) a multi value might be better: > > jdk.regex.control=WARN|EXCEPTION|STANDARD|LEGACY > > With Exception generating an error, Standard beeing the planned new default (treating upper/lower same and error on all undefined chars) and legacy beeing the manual fallback to current behavior and WARN the same fallback but with logging. > > I guess some form of early feedback like EXCPETION or WARN is needed, even when it is between a rock and a hard place. Maybe have at least one iteration where it defaults to LEGACY (+Release Notes announcement), then WARN and then finally STANDARD? > > Gruss > Bernd > > > -- > http://bernd.eckenfels.net > > ________________________________ > Von: core-libs-dev im Auftrag von Ivan Gerasimov > Gesendet: Donnerstag, September 5, 2019 4:00 AM > An: Martin Buchholz; Stuart Marks > Cc: core-libs-dev > Betreff: Re: RFR 8230365 : Pattern for a control-char matches non-control characters > > Thank you Martin! > > On 8/30/19 6:19 PM, Martin Buchholz wrote: >> There's a strong expectation that ctrl-A and ctrl-a both map to >> \u0001, so I support Ivan's initiative. >> I'm surprised java regex gets this wrong. >> Might need a transitional system property. >> > Right. I think it would be best to introduce two system properties: > > The first, to turn on/off the restrictions on the control-char names. > This will be enabled by default, and will permit names from the limited > list: capital letters and a few other special characters. > > The second one, to enable mapping of lower-case control-char names to > their upper-case counterpart. This option should be turned off by > default for the current release of JDK, and then turned on by default > for some subsequent release (when, presumably, most applications that > use this kind of regexp are fixed). > > This all feels like a little bit too much for such a rarely used > feature, but probably is a proper thing to do anyway :-) > > If we have an agreement on these system properties, I can create a > separate test to verify all possible combinations. > > >> What's the best bit-twiddle? Untested: >> if ((c ^= 0x40) < 0x20) return c; >> if ((c ^=0x20) <= 26 && c > 0) return c; >> >> 0x40 is more readable than 64. >> > `((ch-0x3f)|(0x5f-ch)) >= 0` does the trick for regular (non-lower-case) > ids. > >> Does ctrol-? get mapped to 0x7f ? >> > Yes. I've got it in the test at the end of the line 4997. > > Would you please help review the updated webrev: > > http://cr.openjdk.java.net/~igerasim/8230365/02/webrev/ > > With kind regards, > > Ivan > > > -- With kind regards, Ivan Gerasimov From stuart.marks at oracle.com Thu Sep 5 20:18:54 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 5 Sep 2019 13:18:54 -0700 Subject: RFR 8230365 : Pattern for a control-char matches non-control characters In-Reply-To: References: <4f81d7bb-3e2b-337a-2f53-a4bc71049d62@oracle.com> <98993cd0-27f8-cda4-ce3b-52d21564a246@oracle.com> Message-ID: <0953495a-082b-afad-0822-393d2d7a26e4@oracle.com> Conceptually I think having the restriction is fine. If we were designing this as a new feature, I'd recommend putting in the restrictions from the very beginning. However, since the old behavior has been out there for 20 years, my main concern is compatibility. Having system properties to control this is ... ok ... I guess. I wish there were a better way, but it seems the simplest. However, I'd strongly advise making the behavior change and the compatibility mode(s) as simple as possible. Having more configuration options complicates the code and complicates the testing, and I really don't see the need for it. So yes, I agree with abandoning ALLOW_LOWERCASE_CONTROL_CHAR_IDS. I guess now we get to have a bikeshed on the property name. Does this apply only to mapping of control characters, or is there some other form of pattern syntax that could be made more strict? Ivan, I seem to recall you talking to me about making some changes in the syntax or interpretation of the construct that enables/disables various flags. This one: |(?idmsuxU-idmsuxU)| Would it make sense to have a single property, e.g. jdk.util.regex.strictSyntax, that governs this one as well? And are there other possibilities for tuning up the parsing behavior that we should be taking? I'd rather not have a situation where we fix up one area of syntax and add a property for it, fix up another area and add a different property, leading to property proliferation. s'marks On 9/4/19 9:00 PM, Martin Buchholz wrote: > Thanks, Ivan.? We're mostly in agreement. > > + * If {@code true} then lower-case control-character ids are mapped to the > + * their upper-case counterparts. > Extra "the". > > After all these decades I only now realize that c ^= 0x40 moves '?' to the end > of the ASCII range and all the other controls to the start! > > Should we support lower-case controls?? Compatibility?with perl regex still > matters, but a lot less than in 2003.? But the key is that we got the WRONG > ANSWER previously, so when we restrict the control ids let's just make lower > case controls syntax errors.? Silently changing behavior is bad for?users. ... > so let's abandon ALLOW_LOWERCASE_CONTROL_CHAR_IDS. > An alternative: > int ch = read() ^ 0x40; > if (!RESTRICTED_CONTROL_CHAR_IDS || ch < 0x20 || ch == 0x7f) return ch; > > > > On Wed, Sep 4, 2019 at 6:49 PM Ivan Gerasimov > wrote: > > Thank you Martin! > > On 8/30/19 6:19 PM, Martin Buchholz wrote: > > There's a strong expectation that ctrl-A and ctrl-a both map to > > \u0001, so I support Ivan's initiative. > > I'm surprised java regex gets this wrong. > > Might need a transitional system property. > > > Right.? I think it would be best to introduce two system properties: > > The first, to turn on/off the restrictions on the control-char names. > This will be enabled by default, and will permit names from the limited > list: capital letters and a few other special characters. > > The second one, to enable mapping of lower-case control-char names to > their upper-case counterpart.? This option should be turned off by > default for the current release of JDK, and then turned on by default > for some subsequent release (when, presumably, most applications that > use this kind of regexp are fixed). > > This all feels like a little bit too much for such a rarely used > feature, but probably is a proper thing to do anyway :-) > > If we have an agreement on these system properties, I can create a > separate test to verify all possible combinations. > > > > What's the best bit-twiddle?? Untested: > > if ((c ^= 0x40) < 0x20) return c; > > if ((c ^=0x20)? <= 26 && c > 0) return c; > > > > 0x40 is more readable than 64. > > > `((ch-0x3f)|(0x5f-ch)) >= 0` does the trick for regular (non-lower-case) > ids. > > > Does ctrol-? get mapped to 0x7f ? > > > Yes. I've got it in the test at the end of the line 4997. > > Would you please help review the updated webrev: > > http://cr.openjdk.java.net/~igerasim/8230365/02/webrev/ > > With kind regards, > > Ivan > > From ivan.gerasimov at oracle.com Thu Sep 5 20:29:16 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 5 Sep 2019 13:29:16 -0700 Subject: RFR 8230365 : Pattern for a control-char matches non-control characters In-Reply-To: References: <4f81d7bb-3e2b-337a-2f53-a4bc71049d62@oracle.com> <98993cd0-27f8-cda4-ce3b-52d21564a246@oracle.com> Message-ID: Thank you Martin again! Here's the updated webrev without the lower-case control char ids: http://cr.openjdk.java.net/~igerasim/8230365/03/webrev/ I've also filed a CSR to record the changes in bahavior: https://bugs.openjdk.java.net/browse/JDK-8230675 Could you please help review it? On 9/4/19 9:00 PM, Martin Buchholz wrote: > Thanks, Ivan.? We're mostly in agreement. > > + * If {@code true} then lower-case control-character ids are mapped to the > + * their upper-case counterparts. > Extra "the". > > After all these decades I only now realize that c ^= 0x40 moves '?' to > the end of the ASCII range and all the other controls to the start! > > Should we support lower-case controls?? Compatibility?with perl regex > still matters, but a lot less than in 2003.? But the key is that we > got the WRONG ANSWER previously, so when we restrict the control ids > let's just make lower case controls syntax errors.? Silently changing > behavior is bad for?users. ... so let's abandon > ALLOW_LOWERCASE_CONTROL_CHAR_IDS. > An alternative: > int ch = read() ^ 0x40; > if (!RESTRICTED_CONTROL_CHAR_IDS || ch < 0x20 || ch == 0x7f) return ch; > > This code will probably be most efficient for the common case. However, I'd prefer to use the auxiliary method isCntrlId() in this case, as it is self-documenting and still efficient enough. With kind regards, Ivan From ivan.gerasimov at oracle.com Thu Sep 5 20:43:53 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 5 Sep 2019 13:43:53 -0700 Subject: RFR 8230365 : Pattern for a control-char matches non-control characters In-Reply-To: <0953495a-082b-afad-0822-393d2d7a26e4@oracle.com> References: <4f81d7bb-3e2b-337a-2f53-a4bc71049d62@oracle.com> <98993cd0-27f8-cda4-ce3b-52d21564a246@oracle.com> <0953495a-082b-afad-0822-393d2d7a26e4@oracle.com> Message-ID: Hi Stuart! Thanks for the comments, and please see my answers inline: On 9/5/19 1:18 PM, Stuart Marks wrote: > > Conceptually I think having the restriction is fine. If we were > designing this as a new feature, I'd recommend putting in the > restrictions from the very beginning. > > However, since the old behavior has been out there for 20 years,? my > main concern is compatibility. Having system properties to control > this is ... ok ... I guess. I wish there were a better way, but it > seems the simplest. However, I'd strongly advise making the behavior > change and the compatibility mode(s) as simple as possible. Having > more configuration options complicates the code and complicates the > testing, and I really don't see the need for it. > > So yes, I agree with abandoning ALLOW_LOWERCASE_CONTROL_CHAR_IDS. > > Okay.? I've just sent out the updated webrev without this option: http://cr.openjdk.java.net/~igerasim/8230365/03/webrev/ And filed the CSR for the spec change and the new property: https://bugs.openjdk.java.net/browse/JDK-8230675 > I guess now we get to have a bikeshed on the property name. Does this > apply only to mapping of control characters, or is there some other > form of pattern syntax that could be made more strict? Ivan, I seem to > recall you talking to me about making some changes in the syntax or > interpretation of the construct that enables/disables various flags. > This one: > > |(?idmsuxU-idmsuxU)| > > Would it make sense to have a single property, e.g. > jdk.util.regex.strictSyntax, that governs this one as well? And are > there other possibilities for tuning up the parsing behavior that we > should be taking? > Yes, that was this bug: https://bugs.openjdk.java.net/browse/JDK-8225021 (Treat ambiguous embedded flags as parse syntax errors) And actually I have yet another bug of similar flavor: https://bugs.openjdk.java.net/browse/JDK-8214245 (Case insensitive matching doesn't work correctly for some character classes) However, this last one is about changing the matching rules, and not about the syntax (And it is still waiting for review!). > > I'd rather not have a situation where we fix up one area of syntax and > add a property for it, fix up another area and add a different > property, leading to property proliferation. > Personally, I don't have a strong preference here. The compatibility property are meant to be temporary anyways. Maybe if we have a single option that will control several different aspects of behavior, it will be harder to get rid of it? Partially, because it will be tempting to reuse it for other similar changes, should they be needed. With kind regards, Ivan > s'marks > > > On 9/4/19 9:00 PM, Martin Buchholz wrote: >> Thanks, Ivan.? We're mostly in agreement. >> >> + * If {@code true} then lower-case control-character ids are mapped to the >> + * their upper-case counterparts. >> Extra "the". >> >> After all these decades I only now realize that c ^= 0x40 moves '?' >> to the end of the ASCII range and all the other controls to the start! >> >> Should we support lower-case controls? Compatibility?with perl regex >> still matters, but a lot less than in 2003.? But the key is that we >> got the WRONG ANSWER previously, so when we restrict the control ids >> let's just make lower case controls syntax errors.? Silently changing >> behavior is bad for?users.? ... so let's abandon >> ALLOW_LOWERCASE_CONTROL_CHAR_IDS. >> An alternative: >> int ch = read() ^ 0x40; >> if (!RESTRICTED_CONTROL_CHAR_IDS || ch < 0x20 || ch == 0x7f) return ch; >> >> >> >> On Wed, Sep 4, 2019 at 6:49 PM Ivan Gerasimov >> > wrote: >> >> Thank you Martin! >> >> On 8/30/19 6:19 PM, Martin Buchholz wrote: >> > There's a strong expectation that ctrl-A and ctrl-a both map to >> > \u0001, so I support Ivan's initiative. >> > I'm surprised java regex gets this wrong. >> > Might need a transitional system property. >> > >> Right.? I think it would be best to introduce two system properties: >> >> The first, to turn on/off the restrictions on the control-char >> names. >> This will be enabled by default, and will permit names from the >> limited >> list: capital letters and a few other special characters. >> >> The second one, to enable mapping of lower-case control-char >> names to >> their upper-case counterpart.? This option should be turned off by >> default for the current release of JDK, and then turned on by >> default >> for some subsequent release (when, presumably, most applications >> that >> use this kind of regexp are fixed). >> >> This all feels like a little bit too much for such a rarely used >> feature, but probably is a proper thing to do anyway :-) >> >> If we have an agreement on these system properties, I can create a >> separate test to verify all possible combinations. >> >> >> > What's the best bit-twiddle?? Untested: >> > if ((c ^= 0x40) < 0x20) return c; >> > if ((c ^=0x20)? <= 26 && c > 0) return c; >> > >> > 0x40 is more readable than 64. >> > >> `((ch-0x3f)|(0x5f-ch)) >= 0` does the trick for regular >> (non-lower-case) >> ids. >> >> > Does ctrol-? get mapped to 0x7f ? >> > >> Yes. I've got it in the test at the end of the line 4997. >> >> Would you please help review the updated webrev: >> >> http://cr.openjdk.java.net/~igerasim/8230365/02/webrev/ >> >> With kind regards, >> >> Ivan >> >> -- With kind regards, Ivan Gerasimov From joe.darcy at oracle.com Thu Sep 5 22:30:56 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 5 Sep 2019 15:30:56 -0700 Subject: RFR: 8212117 : Class.forName may return a reference to a loaded but not linked Class In-Reply-To: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com> References: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com> Message-ID: <40495d79-fa13-2f98-0fb9-8ef5a44bab6c@oracle.com> Hello, For the doc changes in MethodHandle, please supplement the paragraph 1937????????? *

1938????????? * Note that this method throws errors related to loading and linking as 1939????????? * specified in Sections 12.2 and 12.3 of The Java Language 1940????????? * Specification. with @jls tags like @jls 12.2 Loading of Classes and Interfaces @jsl 12.3 Linking of Classes and Interfaces as done elsewhere in the base module. I think it would be slightly better to remove the section numbers from the main text but keep them in the @jls tags since it is now possible to check that the listed name of the section matches what is in the JLS. Thanks, -Joe On 9/4/2019 2:12 PM, Brent Christian wrote: > Hi, > > Please review my fix for JDK-8212117[1].? The webrev is here: > > http://cr.openjdk.java.net/~bchristi/8212117/webrev09/ > > There is also a CSR[2] in need of review. > > The spec for the 2-arg and 3-arg Class.forName() methods states they > will "locate, load, and link" the class, however the linking part is > not ensured to happen. > > Although the VM spec allows flexibility WRT when classes are linked, > this is a corner where the Class.forName() spec is not being upheld. > While this is not an issue for most usages,? 8181144 [3] demonstrates > how this can be a problem (with the debugging interface, in this case). > > This fix ensures that linking happens during the course of > Class.forName().? Class.forName() already @throws LinkageError, so no > spec change is needed there. MethodHandles.Lookup.findClass() needs a > small spec update, due to calling Class.forName with init=false, > > Of course Errors are not required to be caught.? It is therefore > possible that the new behavior could introduce previously unseen, > possibly unhandled LinkageErrors.? A new VM flag > (-XX:+ClassForNameDeferLinking) is introduced to restore the previous > behavior (to keep such code running until it can be updated). > > This change surfaced a couple new "A JNI error has occurred" > situations (see 8181033[5]) in the Launcher, by way of > ? test/jdk/tools/launcher/MainClassCantBeLoadedTest.java > (using the 3-arg Class::forName, detailed in the bug report[4]), > and > ? test/jdk/tools/launcher/modules/basic/LauncherErrors.java > (using the 2-arg Class::forName). > > The Launcher is updated to maintain non-confusing error messages :). > > The new test included with this fix ensures that 8181144[3] is > addressed.? Thanks go to Serguei Spitsyn for writing the test. > > Automated corelibs and hotspot tests pass cleanly. > > Thanks, > -Brent > > -- > 1. https://bugs.openjdk.java.net/browse/JDK-8212117 > > 2. https://bugs.openjdk.java.net/browse/JDK-8222071 > > 3. https://bugs.openjdk.java.net/browse/JDK-8181144 > > 4. > https://bugs.openjdk.java.net/browse/JDK-8212117?focusedCommentId=14215986&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14215986 > > 5. https://bugs.openjdk.java.net/browse/JDK-8181033 > From joe.darcy at oracle.com Thu Sep 5 22:43:33 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 5 Sep 2019 15:43:33 -0700 Subject: JDK 14 RFR of JDK-8230681: Add @since tag to java.io.Serial Message-ID: Hello, As spotted by Martin, please review the addition of an @since tag to the new-in-JDK-14 java.io.Serial type; patch below. Thanks, -Joe diff -r 06f3d5092832 src/java.base/share/classes/java/io/Serial.java --- a/src/java.base/share/classes/java/io/Serial.java??? Thu Sep 05 11:12:12 2019 -0700 +++ b/src/java.base/share/classes/java/io/Serial.java??? Thu Sep 05 15:24:42 2019 -0700 @@ -95,6 +95,7 @@ ? * ? * @see Serializable ? * @see Externalizable + * @since 14 ? */ ?@Target({ElementType.METHOD, ElementType.FIELD}) ?@Retention(RetentionPolicy.SOURCE) From lance.andersen at oracle.com Thu Sep 5 23:00:52 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 5 Sep 2019 19:00:52 -0400 Subject: JDK 14 RFR of JDK-8230681: Add @since tag to java.io.Serial In-Reply-To: References: Message-ID: +1 > On Sep 5, 2019, at 6:43 PM, Joe Darcy wrote: > > Hello, > > As spotted by Martin, please review the addition of an @since tag to the new-in-JDK-14 java.io.Serial type; patch below. > > Thanks, > > -Joe > > diff -r 06f3d5092832 src/java.base/share/classes/java/io/Serial.java > --- a/src/java.base/share/classes/java/io/Serial.java Thu Sep 05 11:12:12 2019 -0700 > +++ b/src/java.base/share/classes/java/io/Serial.java Thu Sep 05 15:24:42 2019 -0700 > @@ -95,6 +95,7 @@ > * > * @see Serializable > * @see Externalizable > + * @since 14 > */ > @Target({ElementType.METHOD, ElementType.FIELD}) > @Retention(RetentionPolicy.SOURCE) > 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 brian.burkhalter at oracle.com Thu Sep 5 23:04:18 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 5 Sep 2019 16:04:18 -0700 Subject: JDK 14 RFR of JDK-8230681: Add @since tag to java.io.Serial In-Reply-To: References: Message-ID: <0A9E4EF2-0D35-4B19-BF6A-E1F6D841860D@oracle.com> ++1 > On Sep 5, 2019, at 4:00 PM, Lance Andersen wrote: > > +1 >> On Sep 5, 2019, at 6:43 PM, Joe Darcy wrote: >> >> Hello, >> >> As spotted by Martin, please review the addition of an @since tag to the new-in-JDK-14 java.io.Serial type; patch below. >> >> Thanks, >> >> -Joe >> >> diff -r 06f3d5092832 src/java.base/share/classes/java/io/Serial.java >> --- a/src/java.base/share/classes/java/io/Serial.java Thu Sep 05 11:12:12 2019 -0700 >> +++ b/src/java.base/share/classes/java/io/Serial.java Thu Sep 05 15:24:42 2019 -0700 >> @@ -95,6 +95,7 @@ >> * >> * @see Serializable >> * @see Externalizable >> + * @since 14 >> */ >> @Target({ElementType.METHOD, ElementType.FIELD}) >> @Retention(RetentionPolicy.SOURCE) >> > > > > 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 Fri Sep 6 00:09:19 2019 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 5 Sep 2019 17:09:19 -0700 Subject: RFR: 8212117 : Class.forName may return a reference to a loaded but not linked Class In-Reply-To: <6d1691eb-220c-ceaf-1302-be2d285f4968@oracle.com> References: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com> <6d1691eb-220c-ceaf-1302-be2d285f4968@oracle.com> Message-ID: <5751ee27-2e15-ad38-0a6a-cf3ad4298ffc@oracle.com> Hi, David On 9/5/19 12:52 AM, David Holmes wrote: > > Good to see this all come together :) :) > So to clarify for others any current caller to > find_class_from_class_loader that passes true for "init" was already > implicitly asking for a linked class (as you must be linked before you > can be initialized). With that in mind I would suggest that in > find_class_from_class_loader you add an assert: > > ! jclass find_class_from_class_loader(JNIEnv* env, Symbol* name, > jboolean init, jboolean link, > ????????????????????????????????????? Handle loader, Handle > protection_domain, > ????????????????????????????????????? jboolean throwError, TRAPS) { > +assert((init && link) || !init, "incorrect use of init/link arguments"); > > just to ensure the callers understand this. I'm good with adding an assert to check for coherent arguments. (Another interpretation is that if 'init' is set, then the 'link' argument is ignored, since linking is implied). > Aside: in looking at this I've spotted another existing bug. JNI > FindClass is not specified to perform class initialization, but the > implementation passes init=true! OK, thanks. I've noted this in JDK-8226540. > src/java.base/share/classes/java/lang/invoke/MethodHandles.java > > I don't see the need for the new note given it already has > > * @throws LinkageError if the linkage fails (Discussed in the CSR) > src/java.base/share/classes/sun/launcher/LauncherHelper.java > ... > Is AccessControlException the only exception, that is not a > LinkageError, that might be thrown when linking? I would think a number > of others are possible - in particular IllegalAccessError might occur > during verification. Other than the fact a test obviously triggered > this, it's not clear why ACE should be singled out here. ?? Also discussed in the CSR[1]. > test/hotspot/jtreg/serviceability/jvmti/ClassStatus/ClassStatus.java > > 45???? // public static void foo(Foo f) { } > > Unclear why this exists. Also the test refers initially to class Foo but > then uses Foo2 and Foo3. ?? I'm guessing it's just a leftover from an earlier version of the test. I've removed the comment, and updated the test @summary. Serguei, anything to add? >> There is also a CSR[2] in need of review. > > I've added a couple of comments and will add myself as a reviewer once > things are near finalized. Thanks for taking a look. Updated webrev at: http://cr.openjdk.java.net/~bchristi/8212117/webrev10/ -Brent 1. https://bugs.openjdk.java.net/browse/JDK-8222071?focusedCommentId=14288303&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14288303 >> >> The spec for the 2-arg and 3-arg Class.forName() methods states they >> will "locate, load, and link" the class, however the linking part is >> not ensured to happen. >> >> Although the VM spec allows flexibility WRT when classes are linked, >> this is a corner where the Class.forName() spec is not being upheld. >> While this is not an issue for most usages,? 8181144 [3] demonstrates >> how this can be a problem (with the debugging interface, in this case). >> >> This fix ensures that linking happens during the course of >> Class.forName().? Class.forName() already @throws LinkageError, so no >> spec change is needed there. MethodHandles.Lookup.findClass() needs a >> small spec update, due to calling Class.forName with init=false, >> >> Of course Errors are not required to be caught.? It is therefore >> possible that the new behavior could introduce previously unseen, >> possibly unhandled LinkageErrors.? A new VM flag >> (-XX:+ClassForNameDeferLinking) is introduced to restore the previous >> behavior (to keep such code running until it can be updated). >> >> This change surfaced a couple new "A JNI error has occurred" >> situations (see 8181033[5]) in the Launcher, by way of >> ?? test/jdk/tools/launcher/MainClassCantBeLoadedTest.java >> (using the 3-arg Class::forName, detailed in the bug report[4]), >> and >> ?? test/jdk/tools/launcher/modules/basic/LauncherErrors.java >> (using the 2-arg Class::forName). >> >> The Launcher is updated to maintain non-confusing error messages :). >> >> The new test included with this fix ensures that 8181144[3] is >> addressed.? Thanks go to Serguei Spitsyn for writing the test. >> >> Automated corelibs and hotspot tests pass cleanly. >> >> Thanks, >> -Brent >> >> -- >> 1. https://bugs.openjdk.java.net/browse/JDK-8212117 >> >> 2. https://bugs.openjdk.java.net/browse/JDK-8222071 >> >> 3. https://bugs.openjdk.java.net/browse/JDK-8181144 >> >> 4. >> https://bugs.openjdk.java.net/browse/JDK-8212117?focusedCommentId=14215986&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14215986 >> >> >> 5. https://bugs.openjdk.java.net/browse/JDK-8181033 >> From brent.christian at oracle.com Fri Sep 6 00:09:29 2019 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 5 Sep 2019 17:09:29 -0700 Subject: RFR: 8212117 : Class.forName may return a reference to a loaded but not linked Class In-Reply-To: <40495d79-fa13-2f98-0fb9-8ef5a44bab6c@oracle.com> References: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com> <40495d79-fa13-2f98-0fb9-8ef5a44bab6c@oracle.com> Message-ID: <436955a8-0145-c7f1-95d0-b71b1d228b11@oracle.com> Hi, Joe @jls tags added (and as long as we're in Class.java, I added @jls to the 3-arg Class.forName(), which has an equivalent paragraph). Updated webrev: http://cr.openjdk.java.net/~bchristi/8212117/webrev10/ Thanks, -Brent On 9/5/19 3:30 PM, Joe Darcy wrote: > Hello, > > For the doc changes in MethodHandle, please supplement the paragraph > > 1937????????? *

> 1938????????? * Note that this method throws errors related to loading > and linking as > 1939????????? * specified in Sections 12.2 and 12.3 of The Java > Language > 1940????????? * Specification. > > with @jls tags like > > @jls 12.2 Loading of Classes and Interfaces > @jsl 12.3 Linking of Classes and Interfaces > > as done elsewhere in the base module. I think it would be slightly > better to remove the section numbers from the main text but keep them in > the @jls tags since it is now possible to check that the listed name of > the section matches what is in the JLS. > > Thanks, > > -Joe > > > On 9/4/2019 2:12 PM, Brent Christian wrote: >> Hi, >> >> Please review my fix for JDK-8212117[1].? The webrev is here: >> >> http://cr.openjdk.java.net/~bchristi/8212117/webrev09/ >> >> There is also a CSR[2] in need of review. >> >> The spec for the 2-arg and 3-arg Class.forName() methods states they >> will "locate, load, and link" the class, however the linking part is >> not ensured to happen. >> >> Although the VM spec allows flexibility WRT when classes are linked, >> this is a corner where the Class.forName() spec is not being upheld. >> While this is not an issue for most usages,? 8181144 [3] demonstrates >> how this can be a problem (with the debugging interface, in this case). >> >> This fix ensures that linking happens during the course of >> Class.forName().? Class.forName() already @throws LinkageError, so no >> spec change is needed there. MethodHandles.Lookup.findClass() needs a >> small spec update, due to calling Class.forName with init=false, >> >> Of course Errors are not required to be caught.? It is therefore >> possible that the new behavior could introduce previously unseen, >> possibly unhandled LinkageErrors.? A new VM flag >> (-XX:+ClassForNameDeferLinking) is introduced to restore the previous >> behavior (to keep such code running until it can be updated). >> >> This change surfaced a couple new "A JNI error has occurred" >> situations (see 8181033[5]) in the Launcher, by way of >> ? test/jdk/tools/launcher/MainClassCantBeLoadedTest.java >> (using the 3-arg Class::forName, detailed in the bug report[4]), >> and >> ? test/jdk/tools/launcher/modules/basic/LauncherErrors.java >> (using the 2-arg Class::forName). >> >> The Launcher is updated to maintain non-confusing error messages :). >> >> The new test included with this fix ensures that 8181144[3] is >> addressed.? Thanks go to Serguei Spitsyn for writing the test. >> >> Automated corelibs and hotspot tests pass cleanly. >> >> Thanks, >> -Brent >> >> -- >> 1. https://bugs.openjdk.java.net/browse/JDK-8212117 >> >> 2. https://bugs.openjdk.java.net/browse/JDK-8222071 >> >> 3. https://bugs.openjdk.java.net/browse/JDK-8181144 >> >> 4. >> https://bugs.openjdk.java.net/browse/JDK-8212117?focusedCommentId=14215986&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14215986 >> >> >> 5. https://bugs.openjdk.java.net/browse/JDK-8181033 >> From serguei.spitsyn at oracle.com Fri Sep 6 00:25:12 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 5 Sep 2019 17:25:12 -0700 Subject: RFR: 8212117 : Class.forName may return a reference to a loaded but not linked Class In-Reply-To: <5751ee27-2e15-ad38-0a6a-cf3ad4298ffc@oracle.com> References: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com> <6d1691eb-220c-ceaf-1302-be2d285f4968@oracle.com> <5751ee27-2e15-ad38-0a6a-cf3ad4298ffc@oracle.com> Message-ID: <2fe54043-df9e-4a21-bf3a-4aad7b5cb76d@oracle.com> Hi Brent, Some quick reply below. On 9/5/19 5:09 PM, Brent Christian wrote: > Hi, David > > On 9/5/19 12:52 AM, David Holmes wrote: >> >> Good to see this all come together :) > > :) > >> So to clarify for others any current caller to >> find_class_from_class_loader that passes true for "init" was already >> implicitly asking for a linked class (as you must be linked before >> you can be initialized). With that in mind I would suggest that in >> find_class_from_class_loader you add an assert: >> >> ! jclass find_class_from_class_loader(JNIEnv* env, Symbol* name, >> jboolean init, jboolean link, >> ?????????????????????????????????????? Handle loader, Handle >> protection_domain, >> ?????????????????????????????????????? jboolean throwError, TRAPS) { >> +assert((init && link) || !init, "incorrect use of init/link >> arguments"); >> >> just to ensure the callers understand this. > > I'm good with adding an assert to check for coherent arguments. > > (Another interpretation is that if 'init' is set, then the 'link' > argument is ignored, since linking is implied). > >> Aside: in looking at this I've spotted another existing bug. JNI >> FindClass is not specified to perform class initialization, but the >> implementation passes init=true! > > OK, thanks.? I've noted this in JDK-8226540. > >> src/java.base/share/classes/java/lang/invoke/MethodHandles.java >> >> I don't see the need for the new note given it already has >> >> * @throws LinkageError if the linkage fails > > (Discussed in the CSR) > >> src/java.base/share/classes/sun/launcher/LauncherHelper.java >> ... > Is AccessControlException the only exception, that is not a >> LinkageError, that might be thrown when linking? I would think a >> number of others are possible - in particular IllegalAccessError >> might occur during verification. Other than the fact a test obviously >> triggered this, it's not clear why ACE should be singled out here. ?? > > Also discussed in the CSR[1]. > >> test/hotspot/jtreg/serviceability/jvmti/ClassStatus/ClassStatus.java >> >> 45???? // public static void foo(Foo f) { } >> >> Unclear why this exists. Also the test refers initially to class Foo >> but then uses Foo2 and Foo3. ?? > > I'm guessing it's just a leftover from an earlier version of the test. > I've removed the comment, and updated the test @summary. Yes, it is just a left over from earlier version of the test. > Serguei, anything to add? I'm happy this test got used and included into the webrev, thanks! >>> There is also a CSR[2] in need of review. >> >> I've added a couple of comments and will add myself as a reviewer >> once things are near finalized. > > Thanks for taking a look. > > Updated webrev at: > http://cr.openjdk.java.net/~bchristi/8212117/webrev10/ Will look at the webrev soon. Thanks, serguei > -Brent > > 1. > https://bugs.openjdk.java.net/browse/JDK-8222071?focusedCommentId=14288303&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14288303 > >>> >>> The spec for the 2-arg and 3-arg Class.forName() methods states they >>> will "locate, load, and link" the class, however the linking part is >>> not ensured to happen. >>> >>> Although the VM spec allows flexibility WRT when classes are linked, >>> this is a corner where the Class.forName() spec is not being upheld. >>> While this is not an issue for most usages, 8181144 [3] demonstrates >>> how this can be a problem (with the debugging interface, in this case). >>> >>> This fix ensures that linking happens during the course of >>> Class.forName().? Class.forName() already @throws LinkageError, so >>> no spec change is needed there. MethodHandles.Lookup.findClass() >>> needs a small spec update, due to calling Class.forName with >>> init=false, >>> >>> Of course Errors are not required to be caught.? It is therefore >>> possible that the new behavior could introduce previously unseen, >>> possibly unhandled LinkageErrors.? A new VM flag >>> (-XX:+ClassForNameDeferLinking) is introduced to restore the >>> previous behavior (to keep such code running until it can be updated). >>> >>> This change surfaced a couple new "A JNI error has occurred" >>> situations (see 8181033[5]) in the Launcher, by way of >>> ?? test/jdk/tools/launcher/MainClassCantBeLoadedTest.java >>> (using the 3-arg Class::forName, detailed in the bug report[4]), >>> and >>> ?? test/jdk/tools/launcher/modules/basic/LauncherErrors.java >>> (using the 2-arg Class::forName). >>> >>> The Launcher is updated to maintain non-confusing error messages :). >>> >>> The new test included with this fix ensures that 8181144[3] is >>> addressed.? Thanks go to Serguei Spitsyn for writing the test. >>> >>> Automated corelibs and hotspot tests pass cleanly. >>> >>> Thanks, >>> -Brent >>> >>> -- >>> 1. https://bugs.openjdk.java.net/browse/JDK-8212117 >>> >>> 2. https://bugs.openjdk.java.net/browse/JDK-8222071 >>> >>> 3. https://bugs.openjdk.java.net/browse/JDK-8181144 >>> >>> 4. >>> https://bugs.openjdk.java.net/browse/JDK-8212117?focusedCommentId=14215986&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14215986 >>> >>> >>> 5. https://bugs.openjdk.java.net/browse/JDK-8181033 >>> From mandy.chung at oracle.com Fri Sep 6 00:26:35 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 5 Sep 2019 17:26:35 -0700 Subject: RFR: 8212117 : Class.forName may return a reference to a loaded but not linked Class In-Reply-To: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com> References: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com> Message-ID: <4b9974c9-3782-1558-9027-92b38ba1485b@oracle.com> On 9/4/19 2:12 PM, Brent Christian wrote: > > > There is also a CSR[2] in need of review. The javadoc for Lookup::findClass: "In particular, the method first attempts to load the requested class" I think this sentence is no longer needed together with your change.? What about: /** - * Looks up a class by name from the lookup context defined by this {@code Lookup} object. The static - * initializer of the class is not run. + * Looks up a class by name from the lookup context defined by this {@code Lookup} object. + * This method attempts to locate, load, and link the class, and then determines whether + * the class is accessible to this {@code Lookup} object. + * The static initializer of the class is not run. *

* The lookup context here is determined by the {@linkplain #lookupClass() lookup class}, its class - * loader, and the {@linkplain #lookupModes() lookup modes}. In particular, the method first attempts to - * load the requested class, and then determines whether the class is accessible to this lookup object. + * loader, and the {@linkplain #lookupModes() lookup modes}. The note you added in this method should also be added to 2-arg Class::forName for consistency. We should add @jls as Joe suggests. Mandy From swpalmer at gmail.com Fri Sep 6 00:37:59 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 5 Sep 2019 20:37:59 -0400 Subject: Comments on jpackage (JEP 343) In-Reply-To: <7893861a-5295-a497-1282-51afe128f7bb@strangenoises.org> References: <7893861a-5295-a497-1282-51afe128f7bb@strangenoises.org> Message-ID: <2AE1796B-29E1-4C4A-B085-F4AA99073500@gmail.com> I use a very similar workflow, but I?m building for all platforms. I want the image to produce a simple zipped version of the app, and I want all the installer/bundles/packages as well. I also agree with all of the ?would be nice to haves? - Particularly service/daemon support. I also agree with the recent comments here about getting back the user options support and having a way for args in the configure file to stay and be augmented by arguments added on the command line by the user. Scott > On Sep 5, 2019, at 8:51 AM, Rachel Greenham wrote: > > ?(Sorry for non-threading, i read the digest) > > As you've been lacking feedback from people using the jpackage EA builds, here's mine FWIW. > > I've been quiet because it's been working well enough for us. That said, our needs and process probably simplify matters in that: > > 1. We're only producing Windows installers > 2. We've been lucky in having patient clients during this post-webstart, post-javapackager disruption. > 3. We were happy to modify our versioning to match Windows standards > 4. Our application is non-modular > 5. We do it in three steps: jlink to make a JRE, then jpackage to make an app image, then jpackage again to make both an exe and msi installer based on that image. (client slow to reply which one they'd actually prefer!) Not trying to do everything in one step. > > Since the fix that made new versions of our app correctly replace older ones I've mostly just been testing new EA builds to make sure they don't break it! They do sometimes, usually because of changes in the parameter names, and of course we lost our Inno Setup customisations. I haven't yet made any attempt to customise the EXE setup installer since then. > > Would be nice: > > 1. For it to use the supplied app icon for the installer, or be able to supply another specifically for the installer. For it to be shown in the installer in some fashion. Other exe customisations of straightforward branding and/or flags to control what questions they're asked would be very nice. > 2. For it to be able to sign the installer in the fashion of, or actually using, signtool. (Ideally internalised as installing signtool itself is a pain.) Currently that's an extra step after the installers are built > > But I can wait for them, I want it in a release so I can use it via ToolProvider rather than execing an external JDK. All the while it's the way it is it massively complicates the build. > > Later would-be-nices, not for this desktop app, but ability to use it to package background service-type apps, as a service for windows, using launchd for osx, and systemd for linux. > > -- > Rachel From mandy.chung at oracle.com Fri Sep 6 01:03:40 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 5 Sep 2019 18:03:40 -0700 Subject: RFR: 8212117 : Class.forName may return a reference to a loaded but not linked Class In-Reply-To: <436955a8-0145-c7f1-95d0-b71b1d228b11@oracle.com> References: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com> <40495d79-fa13-2f98-0fb9-8ef5a44bab6c@oracle.com> <436955a8-0145-c7f1-95d0-b71b1d228b11@oracle.com> Message-ID: <7cd5ca60-9532-fdd7-5baa-39b4a88e5015@oracle.com> On 9/5/19 5:09 PM, Brent Christian wrote: > Updated webrev: > http://cr.openjdk.java.net/~bchristi/8212117/webrev10/ jvm.h 349 * Link the 'arg' class (unless ClassForNameDeferLinking is set) I suggest to drop "(unless ...)" phrase because the flag is temporary. jni.cpp The implementation of JNI FindClass has the same behavior as 1-arg Class.forName(name). The JNI spec needs fixing but it's a separate issue. find_class_from_class_loader I like David's suggestion to assert that if init == true, link must be true. Alternatively, pass an enum instead of two booleans clearly tell linking or initializing. Lookup::findClass: "In particular, the method first attempts to load the requested class" I think this sentence is no longer needed together with your change. What about: /** - * Looks up a class by name from the lookup context defined by this {@code Lookup} object. The static - * initializer of the class is not run. + * Looks up a class by name from the lookup context defined by this {@code Lookup} object. + * This method attempts to locate, load, and link the class, and then determines whether + * the class is accessible to this {@code Lookup} object. + * The static initializer of the class is not run. *

* The lookup context here is determined by the {@linkplain #lookupClass() lookup class}, its class - * loader, and the {@linkplain #lookupModes() lookup modes}. In particular, the method first attempts to - * load the requested class, and then determines whether the class is accessible to this lookup object. + * loader, and the {@linkplain #lookupModes() lookup modes}. The note you added in this method should also be added to 2-arg Class::forName for consistency. Otherwise, the fix looks good. Mandy From andrew_m_leonard at uk.ibm.com Fri Sep 6 08:55:40 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Fri, 6 Sep 2019 09:55:40 +0100 Subject: RFR: Request for sponsor : 8230436: String.stripIndent() javadoc unclear about LF/CR at end of string In-Reply-To: References: Message-ID: Hi, Anyone able to review please? Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Andrew Leonard/UK/IBM To: core-libs-dev at openjdk.java.net Cc: james.laskey at oracle.com Date: 02/09/2019 17:10 Subject: RFR: Request for sponsor : 8230436: String.stripIndent() javadoc unclear about LF/CR at end of string Hi, Can I get people's views and sponsor on a small update to the javadoc for String.stripIndent() to make the \n end of block special case more clear please? I've done a proposed patch here: http://cr.openjdk.java.net/~aleonard/8230436/webrev.00/ Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU 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 lance.andersen at oracle.com Fri Sep 6 11:23:23 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 6 Sep 2019 07:23:23 -0400 Subject: RFR: 8230648: Replace @exception tag with @throws in java.base In-Reply-To: <7ca98a57-d4c5-f841-7c5b-bb24a9e58434@oracle.com> References: <358c8542-6fdf-fce4-bd77-0a51f81d9d64@oracle.com> <38ab81e8-2042-2b57-238d-61553e8bdf40@oracle.com> <7ca98a57-d4c5-f841-7c5b-bb24a9e58434@oracle.com> Message-ID: <27B8D59B-26C9-460F-89C1-33CAA3A0B1E0@oracle.com> Hi Julia, It looks fine., thank you for doing this Best Lance > On Sep 5, 2019, at 2:28 PM, Julia Boes wrote: > > Hi, > > Thanks for your comments, Lance and Pavel. > > The copyright will be updated before pushing, as Daniel suggested. > > To address the tag alignment, I adjusted the replacement from '@exception' -> '@throws' to '@exception' -> 'throws ', where the added whitespace preserves the original alignment. This doesn't improve the alignment (which is not consistent in many places) but at least doesn't make it worse. > > Updated webrev: http://cr.openjdk.java.net/~dfuchs/jboes/8230648/webrev.02/ > > Regarding Pavel's comment: > > 8157682: @inheritDoc doesn't work with @exception > > I ran specdiff on the whole JDK and it didn't flag any differences but I'll look into additional comparison options. > > Cheers, > > 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 pavel.rappo at oracle.com Fri Sep 6 11:31:18 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 6 Sep 2019 12:31:18 +0100 Subject: RFR [14] 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect In-Reply-To: References: <97114AA9-A44A-4C36-843C-1E6933348096@oracle.com> <026e37eb-3da6-5f39-ac8d-99ad26bba3d0@oracle.com> <81060A81-D77F-4F49-A131-DE79F66FE29B@oracle.com> <6db710f3-dff6-f6ea-5922-242516769ed8@oracle.com> Message-ID: <1A766DB0-E937-438A-BDE1-26DC29FC25EC@oracle.com> Martin, thanks for having a look at it. I'd appreciate if you could have a look at the timeout measuring mechanics in assertCompletion/assertIncompletion specifically, maybe to spot something that is grossly inadequate. I tried to accommodate some usual suspects of timeout measurements failures. I understand that since we're not working with real-time systems, my attempts to build bullet-proof measurement mechanics are futile. -Pavel > On 30 Aug 2019, at 18:19, Martin Buchholz wrote: > > Not really a review, but: > > For many years we've been using 10 seconds (scaled by timeout factor) as a duration long enough that a timeout is a real failure. > Which is close to your own 20 seconds. Of course, no value is surely safe. > > Probably, parallel testing infrastructure for timeouts should be a test library method. I do something similar in JSR166TestCase > > /** > * Runs all the given actions in parallel, failing if any fail. > * Useful for running multiple variants of tests that are > * necessarily individually slow because they must block. > */ > void testInParallel(Action ... actions) { > ExecutorService pool = Executors.newCachedThreadPool(); > try (PoolCleaner cleaner = cleaner(pool)) { > > On Fri, Aug 30, 2019 at 6:23 AM Daniel Fuchs wrote: > On 30/08/2019 13:54, Pavel Rappo wrote: > > Updated, > > > > http://cr.openjdk.java.net/~prappo/8151678/webrev.01/ > > > > Changes look good! > > best regards, > > -- daniel From pavel.rappo at oracle.com Fri Sep 6 11:33:21 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 6 Sep 2019 12:33:21 +0100 Subject: RFR: 8230648: Replace @exception tag with @throws in java.base In-Reply-To: <7ca98a57-d4c5-f841-7c5b-bb24a9e58434@oracle.com> References: <358c8542-6fdf-fce4-bd77-0a51f81d9d64@oracle.com> <38ab81e8-2042-2b57-238d-61553e8bdf40@oracle.com> <7ca98a57-d4c5-f841-7c5b-bb24a9e58434@oracle.com> Message-ID: <2E13095E-33D9-444C-9364-7E2648F3537E@oracle.com> If you ran the specdiff and saw nothing, I'm fine with that. Looks good. > On 5 Sep 2019, at 19:28, Julia Boes wrote: > > Hi, > > Thanks for your comments, Lance and Pavel. > > The copyright will be updated before pushing, as Daniel suggested. > > To address the tag alignment, I adjusted the replacement from '@exception' -> '@throws' to '@exception' -> 'throws ', where the added whitespace preserves the original alignment. This doesn't improve the alignment (which is not consistent in many places) but at least doesn't make it worse. > > Updated webrev: http://cr.openjdk.java.net/~dfuchs/jboes/8230648/webrev.02/ > > Regarding Pavel's comment: > > 8157682: @inheritDoc doesn't work with @exception > > I ran specdiff on the whole JDK and it didn't flag any differences but I'll look into additional comparison options. > > Cheers, > > Julia > From pavel.rappo at oracle.com Fri Sep 6 13:20:12 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 6 Sep 2019 14:20:12 +0100 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> <87sgpblxns.fsf@oldenburg2.str.redhat.com> Message-ID: Milan, In order to simulate the "Address already in use" scenario I did this: TcpDnsServer(int port) { try { * new ServerSocket(port, 0, InetAddress.getLoopbackAddress()); serverSocket = new ServerSocket(port, 0, InetAddress.getLoopbackAddress()); } catch (BindException ex) { The test failed, instead of being skipped. That's what I saw in the logs: jtreg.SkippedException: Cannot start TCP server at TcpTimeout$TcpDnsServer.(TcpTimeout.java:97) at TcpTimeout.initTest(TcpTimeout.java:71) at TestBase.run(TestBase.java:48) at TcpTimeout.main(TcpTimeout.java:47) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298) at java.base/java.lang.Thread.run(Thread.java:830) Caused by: java.net.BindException: Address already in use: bind at java.base/sun.nio.ch.Net.bind0(Native Method) at java.base/sun.nio.ch.Net.bind(Net.java:469) at java.base/sun.nio.ch.Net.bind(Net.java:458) at java.base/sun.nio.ch.NioSocketImpl.bind(NioSocketImpl.java:643) at java.base/java.net.ServerSocket.bind(ServerSocket.java:355) at java.base/java.net.ServerSocket.(ServerSocket.java:241) at TcpTimeout$TcpDnsServer.(TcpTimeout.java:91) ... 9 more JavaTest Message: Test threw exception: jtreg.SkippedException JavaTest Message: shutting down test JavaTest Message: Problem cleaning up the following threads: Thread-0 at java.base at 14-internal/java.net.DualStackPlainDatagramSocketImpl.socketReceiveOrPeekData(Native Method) at java.base at 14-internal/java.net.DualStackPlainDatagramSocketImpl.peekData(DualStackPlainDatagramSocketImpl.java:113) at java.base at 14-internal/java.net.DatagramSocket.receive(DatagramSocket.java:746) at DNSServer.receiveQuery(DNSServer.java:178) at DNSServer.run(DNSServer.java:119) What's going on here? It looks like the test didn't call `cleanupTest()` (and therefore `server.stopServer()`) because the exception was thrown before it had reached `runTest()`. I think we must address this, otherwise our jtreg.SkippedException is only half measure. I thought about how to do that. I'm thinking of going the full way up to TestBase as I believe it makes the most sense. Having said that, we'd better ask the original author (cc'ed), Chris Yin, what he thinks about it. Here's the proposal: diff -r 53e139e55605 test/jdk/com/sun/jndi/dns/lib/TestBase.java --- a/test/jdk/com/sun/jndi/dns/lib/TestBase.java Thu Sep 05 14:59:29 2019 +0100 +++ b/test/jdk/com/sun/jndi/dns/lib/TestBase.java Fri Sep 06 14:08:48 2019 +0100 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2018, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -44,10 +44,14 @@ * @throws Exception if any exception */ public void run(String[] args) throws Exception { - initRes(); - initTest(args); - setupTest(); - launch(); + try { + initRes(); + initTest(args); + setupTest(); + launch(); + } finally { + cleanupTest(); + } } /** @@ -84,8 +88,6 @@ if (!handleException(e)) { throw e; } - } finally { - cleanupTest(); } } @@ -108,6 +110,11 @@ /** * Cleanup test. + * + * This method may be called by the test at any time, including before all + * the resources, initialization, and setup have been completed. This might + * require careful attention. For example, before closing a resource this + * method should check that resource for being {@code null}. */ public abstract void cleanupTest(); } -Pavel > On 5 Sep 2019, at 11:20, Milan Mimica wrote: > > On Wed, 4 Sep 2019 at 20:32, Florian Weimer wrote: >> >> If you use the initial UDP timeout (one second, I think), the kernel >> will not complete the TCP handshake if the initial SYN segment is lost >> because the retransmit delay during the handshake is longer than that. > > We could set a higher timeout value, but I would not prefer that. > After all, 1 second is just default value, and can be changed. If the > user wants us to give up on DNS query after the specified timeout then > lets do just that. True, some queries that previously worked might > start failing, but that is true even for slow socket.read() > operations. > > New webrev: http://cr.openjdk.java.net/~mmimica/8228580/webrev.01/ > > * simplified test with no thread (nice catch Pavel) > * set connect timeout and account for it > > -- > Milan Mimica From vladimir.x.ivanov at oracle.com Fri Sep 6 13:48:40 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 6 Sep 2019 16:48:40 +0300 Subject: RFR: 8230662: Remove dead code from MethodTypeForm In-Reply-To: <780b1e41-0de7-e7c4-a1e4-57f182f12b79@oracle.com> References: <780b1e41-0de7-e7c4-a1e4-57f182f12b79@oracle.com> Message-ID: <34404d87-206d-828d-aa11-089b6f218ea8@oracle.com> Looks good. Best regards, Vladimir Ivanov On 05/09/2019 17:41, Claes Redestad wrote: > Hi, > > I noticed some unused methods in java.lang.invoke.MethodTypeForm and > ended up with a rather substantial cleanup after pulling that particular > thread for a bit: > > http://cr.openjdk.java.net/~redestad/8230662/jdk.00/ > https://bugs.openjdk.java.net/browse/JDK-8230662 > > Testing: tier1-3 > > Thanks! > > /Claes From claes.redestad at oracle.com Fri Sep 6 13:51:15 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 6 Sep 2019 15:51:15 +0200 Subject: RFR: 8230662: Remove dead code from MethodTypeForm In-Reply-To: <34404d87-206d-828d-aa11-089b6f218ea8@oracle.com> References: <780b1e41-0de7-e7c4-a1e4-57f182f12b79@oracle.com> <34404d87-206d-828d-aa11-089b6f218ea8@oracle.com> Message-ID: <8aab541f-7777-ce5b-c11e-413468d8d932@oracle.com> Vladimir, thanks for reviewing! /Claes On 2019-09-06 15:48, Vladimir Ivanov wrote: > Looks good. > > Best regards, > Vladimir Ivanov > > On 05/09/2019 17:41, Claes Redestad wrote: >> Hi, >> >> I noticed some unused methods in java.lang.invoke.MethodTypeForm and >> ended up with a rather substantial cleanup after pulling that particular >> thread for a bit: >> >> http://cr.openjdk.java.net/~redestad/8230662/jdk.00/ >> https://bugs.openjdk.java.net/browse/JDK-8230662 >> >> Testing: tier1-3 >> >> Thanks! >> >> /Claes From martinrb at google.com Fri Sep 6 14:59:56 2019 From: martinrb at google.com (Martin Buchholz) Date: Fri, 6 Sep 2019 07:59:56 -0700 Subject: RFR [14] 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect In-Reply-To: <1A766DB0-E937-438A-BDE1-26DC29FC25EC@oracle.com> References: <97114AA9-A44A-4C36-843C-1E6933348096@oracle.com> <026e37eb-3da6-5f39-ac8d-99ad26bba3d0@oracle.com> <81060A81-D77F-4F49-A131-DE79F66FE29B@oracle.com> <6db710f3-dff6-f6ea-5922-242516769ed8@oracle.com> <1A766DB0-E937-438A-BDE1-26DC29FC25EC@oracle.com> Message-ID: I took another look at LdapTimeoutTest.java. I was surprised to see RIGHT_MARGIN. In jsr166 we succeed in having one timeout that is long enough to "never happen". I'm still advocating the 10 second value. I was surprised to see LEFT_MARGIN. We just fixed Thread.sleep, so we have no known problems with JDK methods returning early - you can trust timed get! You start measuring, by calling nanoTime, before you start the activity you are measuring, so there should be no need for LEFT_MARGIN. We have some fresh thread-awaiting code here: http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/tck/JSR166TestCase.java?view=markup#l1443 Instead of communicating startTime from the test thread back to the main thread, I would do my loMillis checking in the test thread, and hiMillis checking in the main thread, like e.g. compare with a fresh test method testTimedOffer http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/tck/ArrayBlockingQueueTest.java?view=markup#l394 Timeouts should be adjusted via Utils.adjustTimeout On Fri, Sep 6, 2019 at 4:31 AM Pavel Rappo wrote: > Martin, thanks for having a look at it. > > I'd appreciate if you could have a look at the timeout measuring mechanics > in assertCompletion/assertIncompletion specifically, maybe to spot > something that is grossly inadequate. > > I tried to accommodate some usual suspects of timeout measurements > failures. I understand that since we're not working with real-time systems, > my attempts to build bullet-proof measurement mechanics are futile. > > -Pavel > > > On 30 Aug 2019, at 18:19, Martin Buchholz wrote: > > > > Not really a review, but: > > > > For many years we've been using 10 seconds (scaled by timeout factor) as > a duration long enough that a timeout is a real failure. > > Which is close to your own 20 seconds. Of course, no value is surely > safe. > > > > Probably, parallel testing infrastructure for timeouts should be a test > library method. I do something similar in JSR166TestCase > > > > /** > > * Runs all the given actions in parallel, failing if any fail. > > * Useful for running multiple variants of tests that are > > * necessarily individually slow because they must block. > > */ > > void testInParallel(Action ... actions) { > > ExecutorService pool = Executors.newCachedThreadPool(); > > try (PoolCleaner cleaner = cleaner(pool)) { > > > > On Fri, Aug 30, 2019 at 6:23 AM Daniel Fuchs > wrote: > > On 30/08/2019 13:54, Pavel Rappo wrote: > > > Updated, > > > > > > http://cr.openjdk.java.net/~prappo/8151678/webrev.01/ > > > > > > > Changes look good! > > > > best regards, > > > > -- daniel > > From martinrb at google.com Fri Sep 6 16:11:21 2019 From: martinrb at google.com (Martin Buchholz) Date: Fri, 6 Sep 2019 09:11:21 -0700 Subject: RFR [14] 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect In-Reply-To: References: <97114AA9-A44A-4C36-843C-1E6933348096@oracle.com> <026e37eb-3da6-5f39-ac8d-99ad26bba3d0@oracle.com> <81060A81-D77F-4F49-A131-DE79F66FE29B@oracle.com> <6db710f3-dff6-f6ea-5922-242516769ed8@oracle.com> <1A766DB0-E937-438A-BDE1-26DC29FC25EC@oracle.com> Message-ID: Bigger picture: all of this timeout-fiddling infrastructure should be in a test library. It's not easy! test/jdk/java/util/concurrent/tck effectively has its own test library, for historical reasons. On Fri, Sep 6, 2019 at 7:59 AM Martin Buchholz wrote: > I took another look at LdapTimeoutTest.java. > > I was surprised to see RIGHT_MARGIN. In jsr166 we succeed in having one > timeout that is long enough to "never happen". I'm still advocating the 10 > second value. > > I was surprised to see LEFT_MARGIN. We just fixed Thread.sleep, so we > have no known problems with JDK methods returning early - you can trust > timed get! > You start measuring, by calling nanoTime, before you start the activity > you are measuring, so there should be no need for LEFT_MARGIN. > > We have some fresh thread-awaiting code here: > > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/tck/JSR166TestCase.java?view=markup#l1443 > > Instead of communicating startTime from the test thread back to the main > thread, I would do my loMillis checking in the test thread, and hiMillis > checking in the main thread, like e.g. compare with a fresh test > method testTimedOffer > > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/tck/ArrayBlockingQueueTest.java?view=markup#l394 > > Timeouts should be adjusted via Utils.adjustTimeout > > > On Fri, Sep 6, 2019 at 4:31 AM Pavel Rappo wrote: > >> Martin, thanks for having a look at it. >> >> I'd appreciate if you could have a look at the timeout measuring >> mechanics in assertCompletion/assertIncompletion specifically, maybe to >> spot something that is grossly inadequate. >> >> I tried to accommodate some usual suspects of timeout measurements >> failures. I understand that since we're not working with real-time systems, >> my attempts to build bullet-proof measurement mechanics are futile. >> >> -Pavel >> >> > On 30 Aug 2019, at 18:19, Martin Buchholz wrote: >> > >> > Not really a review, but: >> > >> > For many years we've been using 10 seconds (scaled by timeout factor) >> as a duration long enough that a timeout is a real failure. >> > Which is close to your own 20 seconds. Of course, no value is surely >> safe. >> > >> > Probably, parallel testing infrastructure for timeouts should be a test >> library method. I do something similar in JSR166TestCase >> > >> > /** >> > * Runs all the given actions in parallel, failing if any fail. >> > * Useful for running multiple variants of tests that are >> > * necessarily individually slow because they must block. >> > */ >> > void testInParallel(Action ... actions) { >> > ExecutorService pool = Executors.newCachedThreadPool(); >> > try (PoolCleaner cleaner = cleaner(pool)) { >> > >> > On Fri, Aug 30, 2019 at 6:23 AM Daniel Fuchs >> wrote: >> > On 30/08/2019 13:54, Pavel Rappo wrote: >> > > Updated, >> > > >> > > http://cr.openjdk.java.net/~prappo/8151678/webrev.01/ >> > > >> > >> > Changes look good! >> > >> > best regards, >> > >> > -- daniel >> >> From pavel.rappo at oracle.com Fri Sep 6 16:33:11 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 6 Sep 2019 17:33:11 +0100 Subject: RFR [14] 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect In-Reply-To: References: <97114AA9-A44A-4C36-843C-1E6933348096@oracle.com> <026e37eb-3da6-5f39-ac8d-99ad26bba3d0@oracle.com> <81060A81-D77F-4F49-A131-DE79F66FE29B@oracle.com> <6db710f3-dff6-f6ea-5922-242516769ed8@oracle.com> <1A766DB0-E937-438A-BDE1-26DC29FC25EC@oracle.com> Message-ID: <0911E28D-E382-4A0E-A7DB-F775C522BFB4@oracle.com> > On 6 Sep 2019, at 15:59, Martin Buchholz wrote: > > I took another look at LdapTimeoutTest.java. Many thanks! > I was surprised to see RIGHT_MARGIN. In jsr166 we succeed in having one timeout that is long enough to "never happen". I'm still advocating the 10 second value. > > I was surprised to see LEFT_MARGIN. We just fixed Thread.sleep, so we have no known problems with JDK methods returning early - you can trust timed get! > You start measuring, by calling nanoTime, before you start the activity you are measuring, so there should be no need for LEFT_MARGIN. You raised many good points. Let me try to address them. 1. RIGHT_MARGIN is not used for checking that the activity has stuck infinitely (assertIncompletion). INFINITY_MILLIS is used for that. RIGHT_MARGIN is used for checking that the activity takes some predefined amount of time (roughly). 2. As for the numeric value of INFINITY_MILLIS, the reason I chose 20 seconds is twofold. Firstly, the code under test is subject to different timeouts. Every timeout value should be distinctive. Otherwise, how would I differentiate between them? For example, if I chose INFINITY_MILLIS to be 10 seconds how would I know if the code is stuck due to the read timeout of 10 seconds or the "infinite timeout"? Secondly, I must take into account slow machines. Really slow virtual machines. Hence, minimal timeouts (read/connect) have a magnitude of seconds and tens of seconds and the "rightmost", infinite timeout, is 20 seconds. 3. LEFT_MARGIN might no longer be needed due to the fact that no timed methods return early (actually there is a comment about it inside those two assert methods). > We have some fresh thread-awaiting code here: > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/tck/JSR166TestCase.java?view=markup#l1443 Interesting. > Instead of communicating startTime from the test thread back to the main thread, I would do my loMillis checking in the test thread, and hiMillis checking in the main thread, like e.g. compare with a fresh test method testTimedOffer > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/tck/ArrayBlockingQueueTest.java?view=markup#l394 Understood. However, that might be a matter of taste. I prefer to have all the calculations and error handling in one place. Unless there's a good reason I wouldn't change it. > Timeouts should be adjusted via Utils.adjustTimeout That makes perfect sense. I never knew this method existed. Thanks! > On Fri, Sep 6, 2019 at 4:31 AM Pavel Rappo wrote: > Martin, thanks for having a look at it. > > I'd appreciate if you could have a look at the timeout measuring mechanics in assertCompletion/assertIncompletion specifically, maybe to spot something that is grossly inadequate. > > I tried to accommodate some usual suspects of timeout measurements failures. I understand that since we're not working with real-time systems, my attempts to build bullet-proof measurement mechanics are futile. > > -Pavel > > > On 30 Aug 2019, at 18:19, Martin Buchholz wrote: > > > > Not really a review, but: > > > > For many years we've been using 10 seconds (scaled by timeout factor) as a duration long enough that a timeout is a real failure. > > Which is close to your own 20 seconds. Of course, no value is surely safe. > > > > Probably, parallel testing infrastructure for timeouts should be a test library method. I do something similar in JSR166TestCase > > > > /** > > * Runs all the given actions in parallel, failing if any fail. > > * Useful for running multiple variants of tests that are > > * necessarily individually slow because they must block. > > */ > > void testInParallel(Action ... actions) { > > ExecutorService pool = Executors.newCachedThreadPool(); > > try (PoolCleaner cleaner = cleaner(pool)) { > > > > On Fri, Aug 30, 2019 at 6:23 AM Daniel Fuchs wrote: > > On 30/08/2019 13:54, Pavel Rappo wrote: > > > Updated, > > > > > > http://cr.openjdk.java.net/~prappo/8151678/webrev.01/ > > > > > > > Changes look good! > > > > best regards, > > > > -- daniel > From brian.burkhalter at oracle.com Fri Sep 6 16:36:39 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 6 Sep 2019 09:36:39 -0700 Subject: 8229333: java/io/File/SetLastModified.java timed out In-Reply-To: References: Message-ID: An alternative would be to increase the required memory: @@ -23,6 +23,7 @@ /* @test @bug 4091757 6652379 8177809 + @requires os.maxMemory >= 16G @summary Basic test for setLastModified method */ Thanks, Brian > On Aug 28, 2019, at 10:51 AM, Lance Andersen wrote: > > Looks fine Brian, fingers crossed the little bugger does not come back :-) > >> On Aug 27, 2019, at 2:00 PM, Brian Burkhalter > wrote: >> >> The failure reported in [1] was observed to occur on two Mac minis with HDDs. Given the large file access it is possibly due to slow disk access. The suggested fix is to increase the timeout [2]. If it is still observed at a later date a new issue can be filed. >> >> Thanks, >> >> Brian >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8229333 >> [2] diff: >> >> @@ -22,11 +22,13 @@ >> */ >> >> /* @test >> - @bug 4091757 6652379 8177809 >> - @summary Basic test for setLastModified method >> + * @bug 4091757 6652379 8177809 >> + * @summary Basic test for setLastModified method >> + * @run main/timeout=180 SetLastModified >> */ >> >> -import java.io .*; >> +import java.io.File; >> +import java.io.FileOutputStream; >> import java.nio.ByteBuffer; >> import java.nio.channels.FileChannel; > > > > 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 pavel.rappo at oracle.com Fri Sep 6 16:38:13 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 6 Sep 2019 17:38:13 +0100 Subject: RFR [14] 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect In-Reply-To: References: <97114AA9-A44A-4C36-843C-1E6933348096@oracle.com> <026e37eb-3da6-5f39-ac8d-99ad26bba3d0@oracle.com> <81060A81-D77F-4F49-A131-DE79F66FE29B@oracle.com> <6db710f3-dff6-f6ea-5922-242516769ed8@oracle.com> <1A766DB0-E937-438A-BDE1-26DC29FC25EC@oracle.com> Message-ID: <3F67C24D-3037-4C2D-ACF5-174FD0D58FCF@oracle.com> > On 6 Sep 2019, at 17:11, Martin Buchholz wrote: > > Bigger picture: all of this timeout-fiddling infrastructure should be in a test library. It's not easy! > > test/jdk/java/util/concurrent/tck effectively has its own test library, for historical reasons. Agreed. It is not an easy task. I'd address this concern of having library level support for measuring timeouts and asserting threads blocking in a separate bug. For now, I'm afraid I have to reinvent the wheel. From milan.mimica at gmail.com Fri Sep 6 10:40:04 2019 From: milan.mimica at gmail.com (Milan Mimica) Date: Fri, 6 Sep 2019 12:40:04 +0200 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: <87woemhe6z.fsf@oldenburg2.str.redhat.com> References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> <87sgpblxns.fsf@oldenburg2.str.redhat.com> <87woemhe6z.fsf@oldenburg2.str.redhat.com> Message-ID: On Thu, 5 Sep 2019 at 18:59, Florian Weimer wrote: > > But I think in the UDP case, the client will retry. I think the total > timeout in the TCP case should equal the total timeout in the UDP case. > That's what I'm going to implement for glibc. The difference is that in > the TCP case, the TCP stack will take care of the retries, not the > application code. I understand that, and it does make sense, but we have to put it in context of how current DnsClient.java works: // // The UDP retry strategy is to try the 1st server, and then // each server in order. If no answer, double the timeout // and try each server again. // Fallback to TCP happens within this process. Going immediately with timeout*2^maxRetry could yield significantly larger delays, if there happens to be some other server on the list that works better. I would rather look into reusing TCP connections, not to close them immediately. What about read() and non-handshake TCP retransmissions? Do those usually happen faster? -- Milan Mimica From andvolkov at gmail.com Fri Sep 6 12:49:32 2019 From: andvolkov at gmail.com (Andrey Volkov) Date: Fri, 6 Sep 2019 15:49:32 +0300 Subject: jpackage on MacOs: app from pkg cannot write files and create directories inside itself Message-ID: Hello. I use jpackage (Build 14-jpackage+1-35) to bundle my Swing-based app for MacOS. Whereas DMG format works pretty well, PGK bundle has a serious issue. When I install the app from PKG, it cannot write files or create directories inside itself. I have /resource directory for my app that has a few settings and temp directory for file processing. For the app from PKG I get "File not Found (Permission Denied)" when the app tries to create a directory like "/Application/MyApp.app/Contents/Java/resources/temp" or any write/create any file inside "/Application/MyApp.app/Contents/Java/resources/" Do you have any clue how to fix it for PKG bundle? I would prefer to use it because it has a more user-friendly installation. BTW, Windows has a similar issue when per-user installation works fine, but a system-wide installation in "Program Files" lack permissions to write files inside "Program File/MyApp". -- Best regards, Andrey Volkov From naoto.sato at oracle.com Fri Sep 6 17:59:08 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 6 Sep 2019 10:59:08 -0700 Subject: [14] RFR: 8230284: Accounting currency format support does not cope with explicit number system. Message-ID: Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8230284 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8230284/webrev.00/ The original enhancement for the accounting currency format support (https://bugs.openjdk.java.net/browse/JDK-8215181) did not account for the explicit/implicit numbering script. The above change made it to share the same code with NumberElements which properly deals with the numbering script. Naoto From joe.darcy at oracle.com Fri Sep 6 18:12:31 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 6 Sep 2019 11:12:31 -0700 Subject: JDK 14 RFR of JDK-8230723: Remove default constructors from java.lang and java.io Message-ID: <51410963-20e8-04c2-72f1-f3245cacd2de@oracle.com> Hello, First part of a multi-part cleanup effort please review ??? JDK-8230723: Remove default constructors from java.lang and java.io ??? webrev: http://cr.openjdk.java.net/~darcy/8230723.0/ ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8230724 Patch below. The default constructors on Modifier and ConstantBootstraps seem clearly accidental so I deprecated them for removal. The PrimitiveSlot and Factory classes are public classes within non-public classes so I made the constructors package private rather than public. However, this is not a spec change for the Java SE API. I'll update the any copyright years as appropriate before pushing. Thanks, -Joe --- old/src/java.base/share/classes/java/io/InputStream.java 2019-09-06 11:11:22.330589001 -0700 +++ new/src/java.base/share/classes/java/io/InputStream.java 2019-09-06 11:11:22.146589001 -0700 @@ -56,6 +56,11 @@ ???? private static final int DEFAULT_BUFFER_SIZE = 8192; ???? /** +???? * Constructor for subclasses to call. +???? */ +??? public InputStream() {} + +??? /** ????? * Returns a new {@code InputStream} that reads no bytes. The returned ????? * stream is initially open.? The stream is closed by calling the ????? * {@code close()} method.? Subsequent calls to {@code close()} have no --- old/src/java.base/share/classes/java/io/ObjectInputStream.java 2019-09-06 11:11:22.838589001 -0700 +++ new/src/java.base/share/classes/java/io/ObjectInputStream.java 2019-09-06 11:11:22.646589001 -0700 @@ -1321,6 +1321,10 @@ ????? * Provide access to the persistent fields read from the input stream. ????? */ ???? public abstract static class GetField { +??????? /** +???????? * Constructor for subclasses to call. +???????? */ +??????? public GetField() {} ???????? /** ????????? * Get the ObjectStreamClass that describes the fields in the stream. --- old/src/java.base/share/classes/java/io/ObjectOutputStream.java 2019-09-06 11:11:23.346589001 -0700 +++ new/src/java.base/share/classes/java/io/ObjectOutputStream.java 2019-09-06 11:11:23.162589001 -0700 @@ -879,6 +879,10 @@ ????? * @since 1.2 ????? */ ???? public abstract static class PutField { +??????? /** +???????? * Constructor for subclasses to call. +???????? */ +??????? public PutField() {} ???????? /** ????????? * Put the value of the named boolean field into the persistent field. --- old/src/java.base/share/classes/java/io/OutputStream.java 2019-09-06 11:11:23.866589001 -0700 +++ new/src/java.base/share/classes/java/io/OutputStream.java 2019-09-06 11:11:23.674589001 -0700 @@ -47,6 +47,11 @@ ? */ ?public abstract class OutputStream implements Closeable, Flushable { ???? /** +???? * Constructor for subclasses to call. +???? */ +??? public OutputStream() {} + +??? /** ????? * Returns a new {@code OutputStream} which discards all bytes.? The ????? * returned stream is initially open.? The stream is closed by calling ????? * the {@code close()} method.? Subsequent calls to {@code close()} have --- old/src/java.base/share/classes/java/lang/InheritableThreadLocal.java 2019-09-06 11:11:24.394589001 -0700 +++ new/src/java.base/share/classes/java/lang/InheritableThreadLocal.java 2019-09-06 11:11:24.182589001 -0700 @@ -52,6 +52,11 @@ ?public class InheritableThreadLocal extends ThreadLocal { ???? /** +???? * Creates an inheritable thread local variable. +???? */ +??? public InheritableThreadLocal() {} + +??? /** ????? * Computes the child's initial value for this inheritable thread-local ????? * variable as a function of the parent's value at the time the child ????? * thread is created.? This method is called from within the parent --- old/src/java.base/share/classes/java/lang/LiveStackFrame.java 2019-09-06 11:11:24.894589001 -0700 +++ new/src/java.base/share/classes/java/lang/LiveStackFrame.java 2019-09-06 11:11:24.690589001 -0700 @@ -116,6 +116,11 @@ ????? */ ???? public abstract class PrimitiveSlot { ???????? /** +???????? * Constructor. +???????? */ +??????? PrimitiveSlot() {} + +??????? /** ????????? * Returns the size, in bytes, of the slot. ????????? */ ???????? public abstract int size(); --- old/src/java.base/share/classes/java/lang/ThreadDeath.java 2019-09-06 11:11:25.486589001 -0700 +++ new/src/java.base/share/classes/java/lang/ThreadDeath.java 2019-09-06 11:11:25.234589001 -0700 @@ -49,4 +49,9 @@ ?public class ThreadDeath extends Error { ???? @java.io.Serial ???? private static final long serialVersionUID = -4417128565033088268L; + +??? /** +???? * Constructs a {@code ThreadDeath}. +???? */ +??? public ThreadDeath() {} ?} --- old/src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java 2019-09-06 11:11:26.150589001 -0700 +++ new/src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java 2019-09-06 11:11:25.882589001 -0700 @@ -459,6 +459,11 @@ ????? */ ???? public class Factory { ???????? /** +???????? * Construct a factory. +???????? */ +??????? Factory() {} + +??????? /** ????????? * Get a concrete subclass of the top class for a given combination of bound types. ????????? * ????????? * @param speciesData the species requiring the class, not yet linked --- old/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java 2019-09-06 11:11:26.846589001 -0700 +++ new/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java 2019-09-06 11:11:26.582589001 -0700 @@ -40,6 +40,12 @@ ? * @since 11 ? */ ?public final class ConstantBootstraps { +??? /** +???? * Do not call. +???? */ +??? @Deprecated(forRemoval=true, since="14") +??? public ConstantBootstraps() {} + ???? // implements the upcall from the JVM, MethodHandleNatives.linkDynamicConstant: ???? /*non-public*/ ???? static Object makeConstant(MethodHandle bootstrapMethod, --- old/src/java.base/share/classes/java/lang/reflect/Modifier.java 2019-09-06 11:11:27.538589001 -0700 +++ new/src/java.base/share/classes/java/lang/reflect/Modifier.java 2019-09-06 11:11:27.274589001 -0700 @@ -43,6 +43,12 @@ ? * @since 1.1 ? */ ?public class Modifier { +??? /** +???? * Do not call. +???? */ +??? @Deprecated(forRemoval=true, since="14") +??? public Modifier() {} + ???? /** ????? * Return {@code true} if the integer argument includes the From mandy.chung at oracle.com Fri Sep 6 18:22:14 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 6 Sep 2019 11:22:14 -0700 Subject: RFR: 8230662: Remove dead code from MethodTypeForm In-Reply-To: <780b1e41-0de7-e7c4-a1e4-57f182f12b79@oracle.com> References: <780b1e41-0de7-e7c4-a1e4-57f182f12b79@oracle.com> Message-ID: Looks good.? This is a good simplification. thanks Mandy On 9/5/19 7:41 AM, Claes Redestad wrote: > Hi, > > I noticed some unused methods in java.lang.invoke.MethodTypeForm and > ended up with a rather substantial cleanup after pulling that particular > thread for a bit: > > http://cr.openjdk.java.net/~redestad/8230662/jdk.00/ > https://bugs.openjdk.java.net/browse/JDK-8230662 > > Testing: tier1-3 > > Thanks! > > /Claes From martinrb at google.com Fri Sep 6 19:02:38 2019 From: martinrb at google.com (Martin Buchholz) Date: Fri, 6 Sep 2019 12:02:38 -0700 Subject: RFR [14] 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect In-Reply-To: <0911E28D-E382-4A0E-A7DB-F775C522BFB4@oracle.com> References: <97114AA9-A44A-4C36-843C-1E6933348096@oracle.com> <026e37eb-3da6-5f39-ac8d-99ad26bba3d0@oracle.com> <81060A81-D77F-4F49-A131-DE79F66FE29B@oracle.com> <6db710f3-dff6-f6ea-5922-242516769ed8@oracle.com> <1A766DB0-E937-438A-BDE1-26DC29FC25EC@oracle.com> <0911E28D-E382-4A0E-A7DB-F775C522BFB4@oracle.com> Message-ID: Martin's rules for test methods: - never have more than 100 millisecond total expected runtime - never have more than 12 millisecond blocking time for any single operation - yet be able to survive a one-time 5 second thread suspension at any time --- adjusting wait time looks like an anti-pattern to me. You can't stop a rare 5-second thread suspension at line 387. 385 final long waitTime = hiMillis - 386 NANOSECONDS.toMillis(System.nanoTime() - startNanos); // (2) adjust wait time 387 388 try { 389 T r = task.get(waitTime, MILLISECONDS); // (3) wait for the task to complete On Fri, Sep 6, 2019 at 9:33 AM Pavel Rappo wrote: > > On 6 Sep 2019, at 15:59, Martin Buchholz wrote: > > > > I took another look at LdapTimeoutTest.java. > > Many thanks! > > > I was surprised to see RIGHT_MARGIN. In jsr166 we succeed in having one > timeout that is long enough to "never happen". I'm still advocating the 10 > second value. > > > > I was surprised to see LEFT_MARGIN. We just fixed Thread.sleep, so we > have no known problems with JDK methods returning early - you can trust > timed get! > > You start measuring, by calling nanoTime, before you start the activity > you are measuring, so there should be no need for LEFT_MARGIN. > > You raised many good points. Let me try to address them. > > 1. RIGHT_MARGIN is not used for checking that the activity has stuck > infinitely (assertIncompletion). INFINITY_MILLIS is used for that. > RIGHT_MARGIN is used for checking that the activity takes some predefined > amount of time (roughly). > > 2. As for the numeric value of INFINITY_MILLIS, the reason I chose 20 > seconds is twofold. Firstly, the code under test is subject to different > timeouts. Every timeout value should be distinctive. Otherwise, how would I > differentiate between them? For example, if I chose INFINITY_MILLIS to be > 10 seconds how would I know if the code is stuck due to the read timeout of > 10 seconds or the "infinite timeout"? Secondly, I must take into account > slow machines. Really slow virtual machines. Hence, minimal timeouts > (read/connect) have a magnitude of seconds and tens of seconds and the > "rightmost", infinite timeout, is 20 seconds. > > 3. LEFT_MARGIN might no longer be needed due to the fact that no timed > methods return early (actually there is a comment about it inside those two > assert methods). > > > We have some fresh thread-awaiting code here: > > > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/tck/JSR166TestCase.java?view=markup#l1443 > > Interesting. > > > Instead of communicating startTime from the test thread back to the main > thread, I would do my loMillis checking in the test thread, and hiMillis > checking in the main thread, like e.g. compare with a fresh test method > testTimedOffer > > > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/tck/ArrayBlockingQueueTest.java?view=markup#l394 > > Understood. However, that might be a matter of taste. I prefer to have all > the calculations and error handling in one place. Unless there's a good > reason I wouldn't change it. > > > Timeouts should be adjusted via Utils.adjustTimeout > > That makes perfect sense. I never knew this method existed. Thanks! > > > On Fri, Sep 6, 2019 at 4:31 AM Pavel Rappo > wrote: > > Martin, thanks for having a look at it. > > > > I'd appreciate if you could have a look at the timeout measuring > mechanics in assertCompletion/assertIncompletion specifically, maybe to > spot something that is grossly inadequate. > > > > I tried to accommodate some usual suspects of timeout measurements > failures. I understand that since we're not working with real-time systems, > my attempts to build bullet-proof measurement mechanics are futile. > > > > -Pavel > > > > > On 30 Aug 2019, at 18:19, Martin Buchholz wrote: > > > > > > Not really a review, but: > > > > > > For many years we've been using 10 seconds (scaled by timeout factor) > as a duration long enough that a timeout is a real failure. > > > Which is close to your own 20 seconds. Of course, no value is surely > safe. > > > > > > Probably, parallel testing infrastructure for timeouts should be a > test library method. I do something similar in JSR166TestCase > > > > > > /** > > > * Runs all the given actions in parallel, failing if any fail. > > > * Useful for running multiple variants of tests that are > > > * necessarily individually slow because they must block. > > > */ > > > void testInParallel(Action ... actions) { > > > ExecutorService pool = Executors.newCachedThreadPool(); > > > try (PoolCleaner cleaner = cleaner(pool)) { > > > > > > On Fri, Aug 30, 2019 at 6:23 AM Daniel Fuchs > wrote: > > > On 30/08/2019 13:54, Pavel Rappo wrote: > > > > Updated, > > > > > > > > http://cr.openjdk.java.net/~prappo/8151678/webrev.01/ > > > > > > > > > > Changes look good! > > > > > > best regards, > > > > > > -- daniel > > > > From mandy.chung at oracle.com Fri Sep 6 19:07:08 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 6 Sep 2019 12:07:08 -0700 Subject: RFR: 8230301: Re-examine hardcoded defaults in GenerateJLIClassesPlugin In-Reply-To: References: Message-ID: <38408c62-76f5-3ff0-b4e3-04035f35c9c3@oracle.com> Hi Claes, The patch looks much straightforward than I expected. The original default hardcoded list includes many more forms.? What is the diff of the jlink-plugin generated classes before and after this patch? I wonder if we should include a few other method types in HelloClassList like float parameter.? While they are not used in the startup benchmarks, they may be used for some other application runtime which has been benefit from jlink-time generated classes. Mandy On 9/2/19 7:02 AM, Claes Redestad wrote: > Hi, > > we should avoid hard-coding the set of dynamically generated j.l.invoke > classes to pre-generate into the jlink plugin, instead favoring > generating the set of code to use at build-time. > > Webrev: http://cr.openjdk.java.net/~redestad/8230301/webrev.00/ > > Several of the hard-coded defaults predate optimizations to remove MH > usage in lambda bootstrap and were generated using earlier iterations of > ISC. This means many classes/methods generated are actualy never used, > and that dropping all the defaults had relatively minimal effect on our > set of startup tests. > > It's easy to create increasingly synthetic applications that suffer > marginally. I did some experiments and identified a few small API calls > we can add to HelloClasslist to recuperate a fair amount on some key > applications, while still significantly reducing size of pre-generated > code. > > Testing: tier1-3 > > Thanks! > > /Claes From brian.burkhalter at oracle.com Fri Sep 6 20:14:15 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 6 Sep 2019 13:14:15 -0700 Subject: JDK 14 RFR of JDK-8230723: Remove default constructors from java.lang and java.io In-Reply-To: <51410963-20e8-04c2-72f1-f3245cacd2de@oracle.com> References: <51410963-20e8-04c2-72f1-f3245cacd2de@oracle.com> Message-ID: <48A00516-C7FD-4D73-967B-095A6AFCF0D0@oracle.com> Hi Joe, > On Sep 6, 2019, at 11:12 AM, Joe Darcy wrote: > > First part of a multi-part cleanup effort please review > > JDK-8230723: Remove default constructors from java.lang and java.io > webrev: http://cr.openjdk.java.net/~darcy/8230723.0/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8230724 CSR reviewed. > Patch below. > > The default constructors on Modifier and ConstantBootstraps seem clearly accidental so I deprecated them for removal. > > The PrimitiveSlot and Factory classes are public classes within non-public classes so I made the constructors package private rather than public. However, this is not a spec change for the Java SE API. On Factory I think the doc might be better as ?Contructs? instead of ?Construct? (like for ThreadDeath). > I'll update the any copyright years as appropriate before pushing. +1 Brian From alexander.matveev at oracle.com Fri Sep 6 21:11:04 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Fri, 6 Sep 2019 14:11:04 -0700 Subject: jpackage on MacOs: app from pkg cannot write files and create directories inside itself In-Reply-To: References: Message-ID: <2441e8bb-5ecc-983e-514d-a032f7545d8d@oracle.com> Hi Andrey, Writing to? /Application on macOS or "Program Files" on Windows requires admin privileges. It is very uncommon when application stores temp files or setting files modifiable by user inside installation folder. For temp files I will recommend to use system provided temp folder. For setting it will depend on OS type. Thanks, Alexander On 9/6/2019 5:49 AM, Andrey Volkov wrote: > Hello. > > I use jpackage (Build 14-jpackage+1-35) to bundle my Swing-based app for > MacOS. Whereas DMG format works pretty well, PGK bundle has a serious > issue. When I install the app from PKG, it cannot write files or create > directories inside itself. > I have /resource directory for my app that has a few settings and temp > directory for file processing. For the app from PKG I get "File not Found > (Permission Denied)" when the app tries to create a directory like > "/Application/MyApp.app/Contents/Java/resources/temp" or any write/create > any file inside "/Application/MyApp.app/Contents/Java/resources/" > Do you have any clue how to fix it for PKG bundle? I would prefer to use it > because it has a more user-friendly installation. > > BTW, Windows has a similar issue when per-user installation works fine, but > a system-wide installation in "Program Files" lack permissions to write > files inside "Program File/MyApp". > From brent.christian at oracle.com Fri Sep 6 21:20:01 2019 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 6 Sep 2019 14:20:01 -0700 Subject: RFR: 8212117 : Class.forName may return a reference to a loaded but not linked Class In-Reply-To: <7cd5ca60-9532-fdd7-5baa-39b4a88e5015@oracle.com> References: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com> <40495d79-fa13-2f98-0fb9-8ef5a44bab6c@oracle.com> <436955a8-0145-c7f1-95d0-b71b1d228b11@oracle.com> <7cd5ca60-9532-fdd7-5baa-39b4a88e5015@oracle.com> Message-ID: <59f97847-6da5-1828-4678-47629c1d4fdf@oracle.com> Hi, Mandy On 9/5/19 6:03 PM, Mandy Chung wrote: > On 9/5/19 5:09 PM, Brent Christian wrote: > > jvm.h > > 349 * Link the 'arg' class (unless ClassForNameDeferLinking is set) > > I suggest to drop "(unless ...)" phrase because the flag is temporary. Sure, good idea. > jni.cpp > > The implementation of JNI FindClass has the same behavior as 1-arg > Class.forName(name). The JNI spec needs fixing but it's a separate > issue. Right - looks like David filed JDK-8230685. > find_class_from_class_loader > I like David's suggestion to assert that if init == true, link > must be true. Alternatively, pass an enum instead of two booleans > clearly tell linking or initializing. Yup, assert added. > Lookup::findClass: > > "In particular, the method first attempts to load the requested class" > > I think this sentence is no longer needed together with your change. What about: > > /** > - * Looks up a class by name from the lookup context defined by this {@code Lookup} object. The static > - * initializer of the class is not run. > + * Looks up a class by name from the lookup context defined by this {@code Lookup} object. > + * This method attempts to locate, load, and link the class, and then determines whether > + * the class is accessible to this {@code Lookup} object. > + * The static initializer of the class is not run. > *

> * The lookup context here is determined by the {@linkplain #lookupClass() lookup class}, its class > - * loader, and the {@linkplain #lookupModes() lookup modes}. In particular, the method first attempts to > - * load the requested class, and then determines whether the class is accessible to this lookup object. > + * loader, and the {@linkplain #lookupModes() lookup modes}. Looks good to me. > The note you added in this method should also be added to 2-arg > Class::forName for consistency. OK, sure. Update webrev is here: http://cr.openjdk.java.net/~bchristi/8212117/webrev11/ with changes to jvm.h, MethodHandles.java, and Class.java. I went ahead and put together a specdiff[1] for the changed methods ([2][3][4]). I've updated and finalized the CSR. Thanks for the review, -Brent 1. http://cr.openjdk.java.net/~bchristi/8212117/webrev11-specdiff/specdiff-summary.html 2. http://cr.openjdk.java.net/~bchristi/8212117/webrev11-specdiff/Class-report.html#forName(java.lang.String,boolean,java.lang.ClassLoader) 3. http://cr.openjdk.java.net/~bchristi/8212117/webrev11-specdiff/Class-report.html#forName(java.lang.Module,java.lang.String) 4. http://cr.openjdk.java.net/~bchristi/8212117/webrev11-specdiff/invoke/MethodHandles.Lookup-report.html#findClass(java.lang.String) From mandy.chung at oracle.com Fri Sep 6 21:30:00 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 6 Sep 2019 14:30:00 -0700 Subject: RFR: 8212117 : Class.forName may return a reference to a loaded but not linked Class In-Reply-To: <59f97847-6da5-1828-4678-47629c1d4fdf@oracle.com> References: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com> <40495d79-fa13-2f98-0fb9-8ef5a44bab6c@oracle.com> <436955a8-0145-c7f1-95d0-b71b1d228b11@oracle.com> <7cd5ca60-9532-fdd7-5baa-39b4a88e5015@oracle.com> <59f97847-6da5-1828-4678-47629c1d4fdf@oracle.com> Message-ID: On 9/6/19 2:20 PM, Brent Christian wrote: > Update webrev is here: > http://cr.openjdk.java.net/~bchristi/8212117/webrev11/ > with changes to jvm.h, MethodHandles.java, and Class.java. Looks good. Mandy From philip.race at oracle.com Fri Sep 6 22:58:50 2019 From: philip.race at oracle.com (Philip Race) Date: Fri, 06 Sep 2019 15:58:50 -0700 Subject: Comments on jpackage (JEP 343) In-Reply-To: References: Message-ID: <5D72E4AA.2050703@oracle.com> Please see https://bugs.openjdk.java.net/browse/JDK-8211182 IIRC there were also concerns that jpackage was not the right place to be defining this, and also I think Andy wrote some boiler plate code that demonstrated it was not needed for at least some of these use cases. Andy (?) So not being revived soon. -phil. On 9/5/19, 2:53 AM, Lennart B?rjeson wrote: > Could you please also revive the UserJvmOptionsService, that (for very unclear reasons) was removed together with JavaFX? > > Since the functionality provided by the UserJvmOptionsService requires some cooperation with the launcher created by jpackage, I can't see how I could implement some work-around myself. > > (I raised this question already in https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-March/059419.html, but without response.) > > Best regards, > > Lennart B?rjeson From claes.redestad at oracle.com Sat Sep 7 01:29:23 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Sat, 7 Sep 2019 03:29:23 +0200 Subject: RFR: 8230301: Re-examine hardcoded defaults in GenerateJLIClassesPlugin In-Reply-To: <38408c62-76f5-3ff0-b4e3-04035f35c9c3@oracle.com> References: <38408c62-76f5-3ff0-b4e3-04035f35c9c3@oracle.com> Message-ID: <9572effe-5e30-9e10-c9fc-f78d75917c85@oracle.com> Hi Mandy, On 2019-09-06 21:07, Mandy Chung wrote: > Hi Claes, > > The patch looks much straightforward than I expected. thanks? :-) > > The original default hardcoded list includes many more forms.? What is > the diff of the jlink-plugin generated classes before and after this patch? > > I wonder if we should include a few other method types in HelloClassList > like float parameter.? While they are not used in the startup > benchmarks, they may be used for some other application runtime which > has been benefit from jlink-time generated classes. Yes, there's a reduction of forms pre-generated by this, but that's sort of the point since the list of defaults was picked by me during JDK 9 development to fit the needs of the lambda metafactory the ISC we had back then. Since both have been refactored over the last 4 feature releases, many of the shapes herein now can never be requested by the current ISC implementation, and are likely dead weight. So I think of this cleanup as reclaiming some footprint that we can spend on widening the API coverage in HelloClasslist to include things that are more likely to be used by a large set of applications. I do think there's a small risk this cleanup removes a handful of oft- used shapes, but I'm not sure if it'll ever register as a measurable regression. It's possible, sure, so I'd prefer to do an exploratory tuning round to patch this up as a follow-up RFE, and have that effort be guided by any regressions we (or others) may be able to detect due this cleanup. Thanks! /Claes From mandy.chung at oracle.com Sat Sep 7 05:29:14 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 6 Sep 2019 22:29:14 -0700 Subject: RFR: 8230301: Re-examine hardcoded defaults in GenerateJLIClassesPlugin In-Reply-To: <9572effe-5e30-9e10-c9fc-f78d75917c85@oracle.com> References: <38408c62-76f5-3ff0-b4e3-04035f35c9c3@oracle.com> <9572effe-5e30-9e10-c9fc-f78d75917c85@oracle.com> Message-ID: <960ed01c-6bd8-516a-4635-2702cb6c975e@oracle.com> On 9/6/19 6:29 PM, Claes Redestad wrote: >> >> The original default hardcoded list includes many more forms. What is >> the diff of the jlink-plugin generated classes before and after this >> patch? >> >> I wonder if we should include a few other method types in >> HelloClassList like float parameter.? While they are not used in the >> startup benchmarks, they may be used for some other application >> runtime which has been benefit from jlink-time generated classes. > Yes, there's a reduction of forms pre-generated by this, but that's sort > of the point since the list of defaults was picked by me during JDK 9 > development to fit the needs of the lambda metafactory the ISC we had > back then. Since both have been refactored over the last 4 feature > releases, many of the shapes herein now can never be requested by the > current ISC implementation, and are likely dead weight. > > So I think of this cleanup as reclaiming some footprint that we can > spend on widening the API coverage in HelloClasslist to include things > that are more likely to be used by a large set of applications. > > I do think there's a small risk this cleanup removes a handful of oft- > used shapes, but I'm not sure if it'll ever register as a measurable > regression. It's possible, sure, so I'd prefer to do an exploratory > tuning round to patch this up as a follow-up RFE, and have that effort > be guided by any regressions we (or others) may be able to detect due > this cleanup. I'm okay with this patch. It'd be help to add a comment in the plugin what criteria to determine the shapes be pre-generated and give examples how to extend the pre-generated list in the future. Mandy From joe.darcy at oracle.com Sat Sep 7 17:13:01 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Sat, 7 Sep 2019 10:13:01 -0700 Subject: JDK 14 RFR of JDK-8230723: Remove default constructors from java.lang and java.io In-Reply-To: <48A00516-C7FD-4D73-967B-095A6AFCF0D0@oracle.com> References: <51410963-20e8-04c2-72f1-f3245cacd2de@oracle.com> <48A00516-C7FD-4D73-967B-095A6AFCF0D0@oracle.com> Message-ID: Hi Brian, On 9/6/2019 1:14 PM, Brian Burkhalter wrote: > Hi Joe, > >> On Sep 6, 2019, at 11:12 AM, Joe Darcy > > wrote: >> >> First part of a multi-part cleanup effort please review >> >> ??? JDK-8230723: Remove default constructors from java.lang >> andjava.io >> ??? webrev:http://cr.openjdk.java.net/~darcy/8230723.0/ >> ??? CSR:https://bugs.openjdk.java.net/browse/JDK-8230724 > > CSR reviewed. > >> Patch below. >> >> The default constructors on Modifier and ConstantBootstraps seem >> clearly accidental so I deprecated them for removal. >> >> The PrimitiveSlot and Factory classes are public classes within >> non-public classes so I made the constructors package private rather >> than public. However, this is not a spec change for the Java SE API. > > On Factory I think the doc might be better as ?Contructs? instead of > ?Construct? (like for ThreadDeath). Agreed; will change before pushing. Thanks for the review, -Joe From t.kitynski at gmail.com Sat Sep 7 21:58:06 2019 From: t.kitynski at gmail.com (=?UTF-8?Q?Tomis=c5=82aw_Kity=c5=84ski?=) Date: Sat, 7 Sep 2019 23:58:06 +0200 Subject: jpackage and java.lang.OutOfMemoryError: Java heap space Message-ID: Hello, I've been trying to run jpackage with different heap sizes, as I get exception as in the subject from jlink: java.io.IOException: jlink failed with: Error: Java heap space java.lang.OutOfMemoryError: Java heap space ??????? at java.base/java.io.InputStream.readNBytes(InputStream.java:437) ??????? at java.base/java.io.InputStream.readAllBytes(InputStream.java:341) ??????? at jdk.jlink/jdk.tools.jlink.plugin.ResourcePoolEntry.contentBytes(ResourcePoolEntry.java:127) ??????? at jdk.jlink/jdk.tools.jlink.plugin.ResourcePoolEntry.write(ResourcePoolEntry.java:140) ??????? at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.lambda$generateJImage$4(ImageFileCreator.java:239) ??????? at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator$$Lambda$368/0x0000000800c49c40.accept(Unknown Source) ??????? at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1621) ??????? at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658) ??????? at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.generateJImage(ImageFileCreator.java:238) ??????? at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.writeImage(ImageFileCreator.java:161) ??????? at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.create(ImageFileCreator.java:100) ??????? at jdk.jlink/jdk.tools.jlink.internal.JlinkTask$ImageHelper.retrieve(JlinkTask.java:851) ??????? at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.operate(ImagePluginStack.java:206) ??????? at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:408) ??????? at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:272) ??????? at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:54) ??????? at jdk.jlink/jdk.tools.jlink.internal.Main$JlinkToolProvider.run(Main.java:63) ??????? at jdk.jpackage/jdk.jpackage.internal.JLinkBundlerHelper.runJLink(JLinkBundlerHelper.java:382) ??????? at jdk.jpackage/jdk.jpackage.internal.JLinkBundlerHelper.execute(JLinkBundlerHelper.java:187) ??????? at jdk.jpackage/jdk.jpackage.internal.WinAppBundler.doAppBundle(WinAppBundler.java:178) ??????? at jdk.jpackage/jdk.jpackage.internal.WinAppBundler.doBundle(WinAppBundler.java:166) ??????? at jdk.jpackage/jdk.jpackage.internal.WinMsiBundler.prepareProto(WinMsiBundler.java:425) ??????? at jdk.jpackage/jdk.jpackage.internal.WinMsiBundler.bundle(WinMsiBundler.java:499) ??????? at jdk.jpackage/jdk.jpackage.internal.WinMsiBundler.execute(WinMsiBundler.java:233) ??????? at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:620) ??????? at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:513) ??????? at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:97) ??????? at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:51) ??????? at jdk.jpackage/jdk.jpackage.internal.JLinkBundlerHelper.runJLink(JLinkBundlerHelper.java:386) ??????? at jdk.jpackage/jdk.jpackage.internal.JLinkBundlerHelper.execute(JLinkBundlerHelper.java:187) ??????? at jdk.jpackage/jdk.jpackage.internal.WinAppBundler.doAppBundle(WinAppBundler.java:178) ??????? at jdk.jpackage/jdk.jpackage.internal.WinAppBundler.doBundle(WinAppBundler.java:166) ??????? at jdk.jpackage/jdk.jpackage.internal.WinMsiBundler.prepareProto(WinMsiBundler.java:425) ??????? at jdk.jpackage/jdk.jpackage.internal.WinMsiBundler.bundle(WinMsiBundler.java:499) ??????? at jdk.jpackage/jdk.jpackage.internal.WinMsiBundler.execute(WinMsiBundler.java:233) ??????? at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:620) ??????? at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:513) ??????? at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:97) ??????? at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:51) e.g. with -Xmx4g or -Xmx:4g, but i get Error: Invalid Option: [-Xmx4g]. What can I do to increase heap size? Greetings TK From david.holmes at oracle.com Sun Sep 8 04:17:54 2019 From: david.holmes at oracle.com (David Holmes) Date: Sun, 8 Sep 2019 14:17:54 +1000 Subject: jpackage and java.lang.OutOfMemoryError: Java heap space In-Reply-To: References: Message-ID: Hi TK, Try -J-Xmx4g David On 8/09/2019 7:58 am, Tomis?aw Kity?ski wrote: > Hello, > > I've been trying to run jpackage with different heap sizes, as I get > exception as in the subject from jlink: > > java.io.IOException: jlink failed with: Error: Java heap space > java.lang.OutOfMemoryError: Java heap space > ??????? at java.base/java.io.InputStream.readNBytes(InputStream.java:437) > ??????? at > java.base/java.io.InputStream.readAllBytes(InputStream.java:341) > ??????? at > jdk.jlink/jdk.tools.jlink.plugin.ResourcePoolEntry.contentBytes(ResourcePoolEntry.java:127) > > ??????? at > jdk.jlink/jdk.tools.jlink.plugin.ResourcePoolEntry.write(ResourcePoolEntry.java:140) > > ??????? at > jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.lambda$generateJImage$4(ImageFileCreator.java:239) > > ??????? at > jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator$$Lambda$368/0x0000000800c49c40.accept(Unknown > Source) > ??????? at > java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1621) > > ??????? at > java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658) > > ??????? at > jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.generateJImage(ImageFileCreator.java:238) > > ??????? at > jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.writeImage(ImageFileCreator.java:161) > > ??????? at > jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.create(ImageFileCreator.java:100) > > ??????? at > jdk.jlink/jdk.tools.jlink.internal.JlinkTask$ImageHelper.retrieve(JlinkTask.java:851) > > ??????? at > jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.operate(ImagePluginStack.java:206) > > ??????? at > jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:408) > > ??????? at > jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:272) > ??????? at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:54) > ??????? at > jdk.jlink/jdk.tools.jlink.internal.Main$JlinkToolProvider.run(Main.java:63) > ??????? at > jdk.jpackage/jdk.jpackage.internal.JLinkBundlerHelper.runJLink(JLinkBundlerHelper.java:382) > > ??????? at > jdk.jpackage/jdk.jpackage.internal.JLinkBundlerHelper.execute(JLinkBundlerHelper.java:187) > > ??????? at > jdk.jpackage/jdk.jpackage.internal.WinAppBundler.doAppBundle(WinAppBundler.java:178) > > ??????? at > jdk.jpackage/jdk.jpackage.internal.WinAppBundler.doBundle(WinAppBundler.java:166) > > ??????? at > jdk.jpackage/jdk.jpackage.internal.WinMsiBundler.prepareProto(WinMsiBundler.java:425) > > ??????? at > jdk.jpackage/jdk.jpackage.internal.WinMsiBundler.bundle(WinMsiBundler.java:499) > > ??????? at > jdk.jpackage/jdk.jpackage.internal.WinMsiBundler.execute(WinMsiBundler.java:233) > > ??????? at > jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:620) > > ??????? at > jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:513) > > ??????? at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:97) > ??????? at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:51) > > ??????? at > jdk.jpackage/jdk.jpackage.internal.JLinkBundlerHelper.runJLink(JLinkBundlerHelper.java:386) > > ??????? at > jdk.jpackage/jdk.jpackage.internal.JLinkBundlerHelper.execute(JLinkBundlerHelper.java:187) > > ??????? at > jdk.jpackage/jdk.jpackage.internal.WinAppBundler.doAppBundle(WinAppBundler.java:178) > > ??????? at > jdk.jpackage/jdk.jpackage.internal.WinAppBundler.doBundle(WinAppBundler.java:166) > > ??????? at > jdk.jpackage/jdk.jpackage.internal.WinMsiBundler.prepareProto(WinMsiBundler.java:425) > > ??????? at > jdk.jpackage/jdk.jpackage.internal.WinMsiBundler.bundle(WinMsiBundler.java:499) > > ??????? at > jdk.jpackage/jdk.jpackage.internal.WinMsiBundler.execute(WinMsiBundler.java:233) > > ??????? at > jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:620) > > ??????? at > jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:513) > > ??????? at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:97) > ??????? at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:51) > > e.g. with -Xmx4g or -Xmx:4g, but i get Error: Invalid Option: [-Xmx4g]. > > What can I do to increase heap size? > > Greetings > > TK > From andy.herrick at oracle.com Sun Sep 8 21:50:38 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Sun, 8 Sep 2019 17:50:38 -0400 Subject: RFR: JDK-8230519: jpackage "--package-type" values and default Message-ID: <12ea1a11-8be5-178b-beba-6fda2b5cc18a@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: Adds "app-image" as a valid value for "--package-type" options, meaning build an application image instead of a package. Changes the default value of "--package-type" to a platform dependent default package type. [1] https://bugs.openjdk.java.net/browse/JDK-8230519 [2] http://cr.openjdk.java.net/~herrick/8230519/webrev.01/ Thanks Andy, From amaembo at gmail.com Mon Sep 9 03:58:01 2019 From: amaembo at gmail.com (Tagir Valeev) Date: Mon, 9 Sep 2019 10:58:01 +0700 Subject: RFR (s): 8176894 Provide specialized implementation for default methods putIfAbsent, computeIfAbsent, computeIfPresent, compute, merge in TreeMap In-Reply-To: References: Message-ID: Hello everybody! Another one gentle reminder: please review the changeset and the CSR. Please note that the change is not that big: it's only several new methods in single TreeMap class, a few new unit-tests, and a benchmark. Here's issue: https://bugs.openjdk.java.net/browse/JDK-8176894 Webrev: http://cr.openjdk.java.net/~tvaleev/webrev/8176894/r2/ CSR: https://bugs.openjdk.java.net/browse/JDK-8227666 Thanks! The original e-mail follows. > Please review the following patch: > http://cr.openjdk.java.net/~tvaleev/webrev/8176894/r2/ > https://bugs.openjdk.java.net/browse/JDK-8176894 > > Also please review the associated CSR: > https://bugs.openjdk.java.net/browse/JDK-8227666 > > 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 From xu.y.yin at oracle.com Mon Sep 9 08:22:23 2019 From: xu.y.yin at oracle.com (Chris Yin) Date: Mon, 9 Sep 2019 16:22:23 +0800 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> <87sgpblxns.fsf@oldenburg2.str.redhat.com> Message-ID: > On 6 Sep 2019, at 9:20 PM, Pavel Rappo wrote: > > Milan, > > In order to simulate the "Address already in use" scenario I did this: > > TcpDnsServer(int port) { > try { > * new ServerSocket(port, 0, InetAddress.getLoopbackAddress()); > serverSocket = new ServerSocket(port, 0, InetAddress.getLoopbackAddress()); > } > catch (BindException ex) { > > The test failed, instead of being skipped. That's what I saw in the logs: > > > jtreg.SkippedException: Cannot start TCP server > at TcpTimeout$TcpDnsServer.(TcpTimeout.java:97) > at TcpTimeout.initTest(TcpTimeout.java:71) > at TestBase.run(TestBase.java:48) > at TcpTimeout.main(TcpTimeout.java:47) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:564) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298) > at java.base/java.lang.Thread.run(Thread.java:830) > Caused by: java.net.BindException: Address already in use: bind > at java.base/sun.nio.ch.Net.bind0(Native Method) > at java.base/sun.nio.ch.Net.bind(Net.java:469) > at java.base/sun.nio.ch.Net.bind(Net.java:458) > at java.base/sun.nio.ch.NioSocketImpl.bind(NioSocketImpl.java:643) > at java.base/java.net.ServerSocket.bind(ServerSocket.java:355) > at java.base/java.net.ServerSocket.(ServerSocket.java:241) > at TcpTimeout$TcpDnsServer.(TcpTimeout.java:91) > ... 9 more > > JavaTest Message: Test threw exception: jtreg.SkippedException > JavaTest Message: shutting down test > > > JavaTest Message: Problem cleaning up the following threads: > Thread-0 > at java.base at 14-internal/java.net.DualStackPlainDatagramSocketImpl.socketReceiveOrPeekData(Native Method) > at java.base at 14-internal/java.net.DualStackPlainDatagramSocketImpl.peekData(DualStackPlainDatagramSocketImpl.java:113) > at java.base at 14-internal/java.net.DatagramSocket.receive(DatagramSocket.java:746) > at DNSServer.receiveQuery(DNSServer.java:178) > at DNSServer.run(DNSServer.java:119) > > > What's going on here? It looks like the test didn't call `cleanupTest()` (and therefore `server.stopServer()`) because the exception was thrown before it had reached `runTest()`. I think we must address this, otherwise our jtreg.SkippedException is only half measure. > > I thought about how to do that. I'm thinking of going the full way up to TestBase as I believe it makes the most sense. Having said that, we'd better ask the original author (cc'ed), Chris Yin, what he thinks about it. Here's the proposal: The change to TestBase looks good to me. Just after try to understand what you want to achieve, some other thoughts in my mind: 1. Whether we give up too earlier when the Tcp port been used 2. Whether we put too many init related check logic in TcpDnsServer Here is just pseudo code for your reference. First, we may have a few tries on different ports by reinit DNSServer, if all failed, then give up and skip test. Second, move socket check and throw SkppedExpection logic to initTest method, that looks more clear and TcpDnsServer could simply focus on server logic. Third, explicit cleanup for each retry fails, no need to hide cleanup in TestBase @Override public void initTest(String[] args) { for (loop a few times as you prefer as max retries) { super.initTest(args); var udpServer = (Server) env().get(DNSTestUtils.TEST_DNS_SERVER_THREAD); try { var serverSocket = new ServerSocket(udpServer.getPort(), 0, InetAddress.getLoopbackAddress()); tcpDnsServer = new TcpDnsServer(serverSocket); break; } catch (BindException be) { DNSTestUtils.debug("Failed to bind server socket on port " + udpServer.getPort() + ", retry ..."); } catch (Exception ex) { throw new RuntimeException("Unexpected exception during initTest", ex); } finally { if (tcpDnsServer == null) { super.cleanupTest(); } } } if (tcpDnsServer == null) { throw new SkippedException("Cannot start TCP server after a few tries, skip test"); } } Thanks, Chris > > > diff -r 53e139e55605 test/jdk/com/sun/jndi/dns/lib/TestBase.java > --- a/test/jdk/com/sun/jndi/dns/lib/TestBase.java Thu Sep 05 14:59:29 2019 +0100 > +++ b/test/jdk/com/sun/jndi/dns/lib/TestBase.java Fri Sep 06 14:08:48 2019 +0100 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2018, 2019, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -44,10 +44,14 @@ > * @throws Exception if any exception > */ > public void run(String[] args) throws Exception { > - initRes(); > - initTest(args); > - setupTest(); > - launch(); > + try { > + initRes(); > + initTest(args); > + setupTest(); > + launch(); > + } finally { > + cleanupTest(); > + } > } > > /** > @@ -84,8 +88,6 @@ > if (!handleException(e)) { > throw e; > } > - } finally { > - cleanupTest(); > } > } > > @@ -108,6 +110,11 @@ > > /** > * Cleanup test. > + * > + * This method may be called by the test at any time, including before all > + * the resources, initialization, and setup have been completed. This might > + * require careful attention. For example, before closing a resource this > + * method should check that resource for being {@code null}. > */ > public abstract void cleanupTest(); > } > > > -Pavel > >> On 5 Sep 2019, at 11:20, Milan Mimica wrote: >> >> On Wed, 4 Sep 2019 at 20:32, Florian Weimer wrote: >>> >>> If you use the initial UDP timeout (one second, I think), the kernel >>> will not complete the TCP handshake if the initial SYN segment is lost >>> because the retransmit delay during the handshake is longer than that. >> >> We could set a higher timeout value, but I would not prefer that. >> After all, 1 second is just default value, and can be changed. If the >> user wants us to give up on DNS query after the specified timeout then >> lets do just that. True, some queries that previously worked might >> start failing, but that is true even for slow socket.read() >> operations. >> >> New webrev: http://cr.openjdk.java.net/~mmimica/8228580/webrev.01/ >> >> * simplified test with no thread (nice catch Pavel) >> * set connect timeout and account for it >> >> -- >> Milan Mimica > From peter.levart at gmail.com Mon Sep 9 10:31:17 2019 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 9 Sep 2019 12:31:17 +0200 Subject: RFR: 8230662: Remove dead code from MethodTypeForm In-Reply-To: <780b1e41-0de7-e7c4-a1e4-57f182f12b79@oracle.com> References: <780b1e41-0de7-e7c4-a1e4-57f182f12b79@oracle.com> Message-ID: <4beeac51-8473-d8f4-34ae-b45d2f9c91e9@gmail.com> Hi Claes, Your changes look good. But I spotted a pre-existing and unusual use of @Stable annotation in java.lang.invoke.MethodTypeForm class: ??? // Cached adapter information: ??? @Stable final SoftReference[] methodHandles; ??? // Cached lambda form information, for basic types only: ??? final @Stable SoftReference[] lambdaForms; This declarations are paired with the following caching logic that returns pre-existing entry if it is already set and not yet cleared or cache new entry and return it: ??? public synchronized MethodHandle setCachedMethodHandle(int which, MethodHandle mh) { ??????? // Simulate a CAS, to avoid racy duplication of results. ??????? SoftReference entry = methodHandles[which]; ??????? if (entry != null) { ??????????? MethodHandle prev = entry.get(); ??????????? if (prev != null) { ??????????????? return prev; ??????????? } ??????? } ??????? methodHandles[which] = new SoftReference<>(mh); ??????? return mh; ??? } and: ??? public synchronized LambdaForm setCachedLambdaForm(int which, LambdaForm form) { ??????? // Simulate a CAS, to avoid racy duplication of results. ??????? SoftReference entry = lambdaForms[which]; ??????? if (entry != null) { ??????????? LambdaForm prev = entry.get(); ??????????? if (prev != null) { ??????????????? return prev; ??????????? } ??????? } ??????? lambdaForms[which] = new SoftReference<>(form); ??????? return form; ??? } If these two @Stable annotations had any effect on JIT optimization, then I think the caching logic would become ineffective for slots in which SoftReference(s) got cleared by GC. In that case, such slots would constantly be overwritten with new SoftReference(s) only to see old constant-folded SoftReference(s) next time around. So I think that these @Stable annotations do no good here. Either they are ineffective in cases where MethodTypeForm instances are not constant-folded, or they render caching ineffective when MethodTypeForm instances are constant-folder and SoftReference(s) are cleared. In either case it would be better without them. What do you think? Regards, Peter On 9/5/19 4:41 PM, Claes Redestad wrote: > Hi, > > I noticed some unused methods in java.lang.invoke.MethodTypeForm and > ended up with a rather substantial cleanup after pulling that particular > thread for a bit: > > http://cr.openjdk.java.net/~redestad/8230662/jdk.00/ > https://bugs.openjdk.java.net/browse/JDK-8230662 > > Testing: tier1-3 > > Thanks! > > /Claes From claes.redestad at oracle.com Mon Sep 9 11:56:22 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 9 Sep 2019 13:56:22 +0200 Subject: RFR: 8230662: Remove dead code from MethodTypeForm In-Reply-To: <4beeac51-8473-d8f4-34ae-b45d2f9c91e9@gmail.com> References: <780b1e41-0de7-e7c4-a1e4-57f182f12b79@oracle.com> <4beeac51-8473-d8f4-34ae-b45d2f9c91e9@gmail.com> Message-ID: On 2019-09-09 12:31, Peter Levart wrote: > Hi Claes, > > Your changes look good. Thanks! Already pushed, though. > But I spotted a pre-existing and unusual use of > @Stable annotation in java.lang.invoke.MethodTypeForm class: > > ??? // Cached adapter information: > ??? @Stable final SoftReference[] methodHandles; > > ??? // Cached lambda form information, for basic types only: > ??? final @Stable SoftReference[] lambdaForms; > > This declarations are paired with the following caching logic that > returns pre-existing entry if it is already set and not yet cleared or > cache new entry and return it: > > ??? public synchronized MethodHandle setCachedMethodHandle(int which, > MethodHandle mh) { > ??????? // Simulate a CAS, to avoid racy duplication of results. > ??????? SoftReference entry = methodHandles[which]; > ??????? if (entry != null) { > ??????????? MethodHandle prev = entry.get(); > ??????????? if (prev != null) { > ??????????????? return prev; > ??????????? } > ??????? } > ??????? methodHandles[which] = new SoftReference<>(mh); > ??????? return mh; > ??? } > > and: > > ??? public synchronized LambdaForm setCachedLambdaForm(int which, > LambdaForm form) { > ??????? // Simulate a CAS, to avoid racy duplication of results. > ??????? SoftReference entry = lambdaForms[which]; > ??????? if (entry != null) { > ??????????? LambdaForm prev = entry.get(); > ??????????? if (prev != null) { > ??????????????? return prev; > ??????????? } > ??????? } > ??????? lambdaForms[which] = new SoftReference<>(form); > ??????? return form; > ??? } > > > If these two @Stable annotations had any effect on JIT optimization, > then I think the caching logic would become ineffective for slots in > which SoftReference(s) got cleared by GC. In that case, such slots would > constantly be overwritten with new SoftReference(s) only to see old > constant-folded SoftReference(s) next time around. > > So I think that these @Stable annotations do no good here. Either they > are ineffective in cases where MethodTypeForm instances are not > constant-folded, or they render caching ineffective when MethodTypeForm > instances are constant-folder and SoftReference(s) are cleared. In > either case it would be better without them. > > What do you think? You might be right, and this should be examined. It seems the @Stable dates from an earlier version of MethodTypeForm that didn't use SoftReferences: https://bugs.openjdk.java.net/browse/JDK-8057020 Thanks! /Claes From fweimer at redhat.com Mon Sep 9 13:04:17 2019 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 09 Sep 2019 15:04:17 +0200 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: (Milan Mimica's message of "Fri, 6 Sep 2019 12:40:04 +0200") References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> <87sgpblxns.fsf@oldenburg2.str.redhat.com> <87woemhe6z.fsf@oldenburg2.str.redhat.com> Message-ID: <87ftl562pa.fsf@oldenburg2.str.redhat.com> * Milan Mimica: > On Thu, 5 Sep 2019 at 18:59, Florian Weimer wrote: >> >> But I think in the UDP case, the client will retry. I think the total >> timeout in the TCP case should equal the total timeout in the UDP case. >> That's what I'm going to implement for glibc. The difference is that in >> the TCP case, the TCP stack will take care of the retries, not the >> application code. > > I understand that, and it does make sense, but we have to put it in > context of how current DnsClient.java works: > // > // The UDP retry strategy is to try the 1st server, and then > // each server in order. If no answer, double the timeout > // and try each server again. > // Ahh. The other option is to stick with one server and keep resending with larger and larger timeouts. Switching has the advantage that in case of a server problem, you get to a working server more quickly. Staying means that if the answer is delayed and you resend exactly the same query, you might still pick up the answer to the original query and process it, after the first timeout. > Fallback to TCP happens within this process. Going immediately with > timeout*2^maxRetry could yield significantly larger delays, if there > happens to be some other server on the list that works better. > I would rather look into reusing TCP connections, not to close them immediately. But we know that the server is up because it responded our UDP, so waiting more than one second for the TCP handshake to succeed might worthwhile, yes. > What about read() and non-handshake TCP retransmissions? Do those > usually happen faster? I think so, yes. Thanks, Florian From claes.redestad at oracle.com Mon Sep 9 14:14:11 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 9 Sep 2019 16:14:11 +0200 Subject: RFR: 8230662: Remove dead code from MethodTypeForm In-Reply-To: References: <780b1e41-0de7-e7c4-a1e4-57f182f12b79@oracle.com> <4beeac51-8473-d8f4-34ae-b45d2f9c91e9@gmail.com> Message-ID: On 2019-09-09 13:56, Claes Redestad wrote: > On 2019-09-09 12:31, Peter Levart wrote: >> Hi Claes,>> So I think that these @Stable annotations do no good here. Either they >> are ineffective in cases where MethodTypeForm instances are not >> constant-folded, or they render caching ineffective when >> MethodTypeForm instances are constant-folder and SoftReference(s) are >> cleared. In either case it would be better without them. >> >> What do you think? > > You might be right, and this should be examined. I agree the @Stable should be removed here, and filed a bug to that effect: https://bugs.openjdk.java.net/browse/JDK-8230768 /Claes From Roger.Riggs at oracle.com Mon Sep 9 14:35:22 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 9 Sep 2019 10:35:22 -0400 Subject: 8230342: LineNumberReader.getLineNumber() returns inconsistent results after EOF In-Reply-To: <553C9BEC-AC7D-4263-B785-E3C703D09819@oracle.com> References: <553C9BEC-AC7D-4263-B785-E3C703D09819@oracle.com> Message-ID: <96566b30-af50-b264-abf2-6067d07e17e2@oracle.com> Hi Brian, I would lean toward updating the spec to reflect the current implementation. A simple program that uses readline and prints the line number and line would show a duplicate line number. try (LineNumberReader r = new LineNumberReader(Files.newBufferedReader(Path.of(args[0])))) { String s; while ((s = r.readLine()) !=null) { System.out.printf("%3d: %s%n", r.getLineNumber(), s); } } ? 1: 123 ? 1: ABC Other questions and comments: - Is the use of AtomicBoolean due to concurrency concerns? ? If not, a new boolean[1] would be less overhead - BufferedReader also keeps track of CR/LF pairs and I've thought it would simpler ? not to duplicate the line number counting logic in LineNumberReader. ? If BufferedReader kept track of the line number, it could expose a package private field ? to LineNumberReader to make it visible to the get/SetLineNumber methods of LineNumberReader. Regards, Roger On 9/5/19 11:11 AM, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8230342 > http://cr.openjdk.java.net/~bpb/8230342/webrev.00/ > > When the last line is read by readLine() the line number is incremented due to the EOF but not when read() or read(char[]) is used. The specification states it is incremented on line terminators only. The alternative solution would be to change the specification to state that the line number is also incremented on EOF even if there is no line terminator at the end of the stream. That would entail a different implementation change. > > Thanks, > > Brian From Roger.Riggs at oracle.com Mon Sep 9 14:41:34 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 9 Sep 2019 10:41:34 -0400 Subject: JDK 14 RFR of JDK-8230723: Remove default constructors from java.lang and java.io In-Reply-To: References: <51410963-20e8-04c2-72f1-f3245cacd2de@oracle.com> <48A00516-C7FD-4D73-967B-095A6AFCF0D0@oracle.com> Message-ID: Looks good Joe, +1 On 9/7/19 1:13 PM, Joe Darcy wrote: > Hi Brian, > > On 9/6/2019 1:14 PM, Brian Burkhalter wrote: >> Hi Joe, >> >>> On Sep 6, 2019, at 11:12 AM, Joe Darcy >> > wrote: >>> >>> First part of a multi-part cleanup effort please review >>> >>> ??? JDK-8230723: Remove default constructors from java.lang >>> andjava.io >>> ??? webrev:http://cr.openjdk.java.net/~darcy/8230723.0/ >>> ??? CSR:https://bugs.openjdk.java.net/browse/JDK-8230724 >> >> CSR reviewed. >> >>> Patch below. >>> >>> The default constructors on Modifier and ConstantBootstraps seem >>> clearly accidental so I deprecated them for removal. >>> >>> The PrimitiveSlot and Factory classes are public classes within >>> non-public classes so I made the constructors package private rather >>> than public. However, this is not a spec change for the Java SE API. >> >> On Factory I think the doc might be better as ?Contructs? instead of >> ?Construct? (like for ThreadDeath). > > > Agreed; will change before pushing. > > Thanks for the review, > > -Joe > From martinrb at google.com Mon Sep 9 15:06:28 2019 From: martinrb at google.com (Martin Buchholz) Date: Mon, 9 Sep 2019 08:06:28 -0700 Subject: RFR: jsr166 integration 2019-09 Message-ID: https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html 8229442: AQS and lock classes refresh https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/lock-classes-refresh/index.html https://bugs.openjdk.java.net/browse/JDK-8229442 Lock classes refresh is a small step towards loom. Loom folk, how about adding Doug and I as Loom Project Committers, even though we have no concrete plans to submit to the loom repo yet? Another round of stress testing at Google allowed us to fix a handful of very rare test failures. 8227235: rare failures in testForkHelpQuiesce tck tests https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/ForkJoin-quiesce/index.html https://bugs.openjdk.java.net/browse/JDK-8227235 8221168: java/util/concurrent/CountDownLatch/Basic.java fails https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/CountDownLatch-Basic/index.html https://bugs.openjdk.java.net/browse/JDK-8221168 8145138: CyclicBarrier/Basic.java failed with "3 not equal to 4" https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/CyclicBarrier-Basic/index.html https://bugs.openjdk.java.net/browse/JDK-8145138 8225490: Miscellaneous changes imported from jsr166 CVS 2019-09 https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/miscellaneous/index.html https://bugs.openjdk.java.net/browse/JDK-8225490 From Roger.Riggs at oracle.com Mon Sep 9 15:12:34 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 9 Sep 2019 11:12:34 -0400 Subject: [14] RFR: 8230284: Accounting currency format support does not cope with explicit number system. In-Reply-To: References: Message-ID: <5fae8e71-2ac0-e9d2-72ba-cee05cfafcfb@oracle.com> Hi Naoto, Bundle.java: ?- 28: Explicit import are preferred,? (if the IDE make the change, fix the settings in the IDE). ?- 763, the indentation of the nested getOrDefault calls doesn't look conventional. ? (It might be interesting to have an API that allows one or more defaults to be tried in turn. ?? It will call each of the methods so there is no shortcutting if the value is found early in the list). CLDRConverter: ?- 513, 1169...: Debugging code can be removed Otherwise looks ok. Thanks, Roger On 9/6/19 1:59 PM, naoto.sato at oracle.com wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8230284 > > The proposed changeset is located at: > > https://cr.openjdk.java.net/~naoto/8230284/webrev.00/ > > The original enhancement for the accounting currency format support > (https://bugs.openjdk.java.net/browse/JDK-8215181) did not account for > the explicit/implicit numbering script. The above change made it to > share the same code with NumberElements which properly deals with the > numbering script. > > Naoto From naoto.sato at oracle.com Mon Sep 9 15:15:29 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 9 Sep 2019 08:15:29 -0700 Subject: [14] RFR: 8229960: Remove sun.nio.cs.map system property Message-ID: <992b60f8-6741-31b4-f1bf-09764eeff359@oracle.com> Hi, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8229960 Here are the links to its CSR and proposed changeset: https://bugs.openjdk.java.net/browse/JDK-8230405 https://cr.openjdk.java.net/~naoto/8229960/webrev.00/ The subject system property was provided in JDK 1.4.1 for applications to help migrate from old Shift_JIS charset definition to IANA charset definition. As reported in the bug, it is now partially broken since JDK9. Instead of fixing it, we are proposing removing the system property as this property should have been removed years ago. Naoto From kevin.rushforth at oracle.com Mon Sep 9 17:14:23 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 9 Sep 2019 10:14:23 -0700 Subject: RFR: JDK-8230519: jpackage "--package-type" values and default In-Reply-To: <12ea1a11-8be5-178b-beba-6fda2b5cc18a@oracle.com> References: <12ea1a11-8be5-178b-beba-6fda2b5cc18a@oracle.com> Message-ID: <9020ae17-36ad-3e13-d54b-420aaab3c5bc@oracle.com> Looks good with one question: In Arguments.java: +???????????????????? if (bundler.isDefault()) { +???????????????????????? return bundler; +???????????????????? } else { +???????????????????????? savedBundler = bundler; +???????????????????? } When would there be a valid case where you loop through the list of bundlers and don't find a default? It may be better to throw an error in that case rather than just return the last one found. -- Kevin On 9/8/2019 2:50 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 fix: > > Adds "app-image" as a valid value for "--package-type" options, > meaning build an application image instead of a package. > > Changes the default value of "--package-type" to a platform dependent > default package type. > > [1] https://bugs.openjdk.java.net/browse/JDK-8230519 > [2] http://cr.openjdk.java.net/~herrick/8230519/webrev.01/ > > Thanks > > Andy, > From alexey.semenyuk at oracle.com Mon Sep 9 17:14:20 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Mon, 9 Sep 2019 13:14:20 -0400 Subject: RFR: JDK-8230726: Improve jpackage jtreg tests In-Reply-To: <39e9b825-6668-af17-c4a3-c584a6ef0647@oracle.com> References: <39e9b825-6668-af17-c4a3-c584a6ef0647@oracle.com> Message-ID: <14a0e3be-662f-d2c1-5d03-cff519a1b66d@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). - reworked jpackage tests that produce platform specific packages to get rid of code duplication; - replaced install.sh/uninstall.sh scripts on Linux and Windows with shared manage_packages.sh script that will batch install/uninstall packages. Support for dmg, pkg and exe installers TBD. [1] https://bugs.openjdk.java.net/browse/JDK-8230726 [2] http://cr.openjdk.java.net/~asemenyuk/8230726/webrev.03 Thanks, Alexey From alexey.semenyuk at oracle.com Mon Sep 9 17:25:43 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Mon, 9 Sep 2019 13:25:43 -0400 Subject: RFR: JDK-8230519: jpackage "--package-type" values and default In-Reply-To: <12ea1a11-8be5-178b-beba-6fda2b5cc18a@oracle.com> References: <12ea1a11-8be5-178b-beba-6fda2b5cc18a@oracle.com> Message-ID: <76da82a3-6298-9f8a-5ef2-079b4f4b1b92@oracle.com> http://cr.openjdk.java.net/~herrick/8230519/webrev.01/test/jdk/tools/jpackage/share/RuntimeTest.java.sdiff.html: --- 37???????? "--package-type", "app-image", 38???????? "--package-type", "app-image", --- Duplication by accident? http://cr.openjdk.java.net/~herrick/8230519/webrev.01/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebBundler.java.sdiff.html: --- // we are just going to run "dpkg -s coreutils" ans assume Debian --- "ans" - typo? Should it be "and"? - Alexey On 9/8/2019 5:50 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 fix: > > Adds "app-image" as a valid value for "--package-type" options, > meaning build an application image instead of a package. > > Changes the default value of "--package-type" to a platform dependent > default package type. > > [1] https://bugs.openjdk.java.net/browse/JDK-8230519 > [2] http://cr.openjdk.java.net/~herrick/8230519/webrev.01/ > > Thanks > > Andy, > From andy.herrick at oracle.com Mon Sep 9 17:28:48 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 9 Sep 2019 13:28:48 -0400 Subject: RFR: JDK-8230519: jpackage "--package-type" values and default In-Reply-To: <9020ae17-36ad-3e13-d54b-420aaab3c5bc@oracle.com> References: <12ea1a11-8be5-178b-beba-6fda2b5cc18a@oracle.com> <9020ae17-36ad-3e13-d54b-420aaab3c5bc@oracle.com> Message-ID: <7344966a-3b2c-b6c2-23b1-82b71ccfc461@oracle.com> On 9/9/19 1:14 PM, Kevin Rushforth wrote: > Looks good with one question: > > In Arguments.java: > > +???????????????????? if (bundler.isDefault()) { > +???????????????????????? return bundler; > +???????????????????? } else { > +???????????????????????? savedBundler = bundler; > +???????????????????? } > > When would there be a valid case where you loop through the list of > bundlers and don't find a default? It may be better to throw an error > in that case rather than just return the last one found. > > -- Kevin > This left the possibility that if the default were not supported but another form was, then it became the default. On Windows, the two package types, msi and exe now require the same tools, and on linux, deb is only the default if (among other things) it is supported. So that leaves only macOS.? here dmg is default but required hdmiutil and osascript. If either of these are missing dmg is not supported, so this code would build pkg package if --package-type not specified.? Would it be better to just get error and only build pkg if it is explicitly specified as --package-type pkg ? /Andy > > On 9/8/2019 2:50 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 fix: >> >> Adds "app-image" as a valid value for "--package-type" options, >> meaning build an application image instead of a package. >> >> Changes the default value of "--package-type" to a platform dependent >> default package type. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8230519 >> [2] http://cr.openjdk.java.net/~herrick/8230519/webrev.01/ >> >> Thanks >> >> Andy, >> > From alexey.semenyuk at oracle.com Mon Sep 9 17:32:35 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Mon, 9 Sep 2019 13:32:35 -0400 Subject: RFR: JDK-8230519: jpackage "--package-type" values and default In-Reply-To: <7344966a-3b2c-b6c2-23b1-82b71ccfc461@oracle.com> References: <12ea1a11-8be5-178b-beba-6fda2b5cc18a@oracle.com> <9020ae17-36ad-3e13-d54b-420aaab3c5bc@oracle.com> <7344966a-3b2c-b6c2-23b1-82b71ccfc461@oracle.com> Message-ID: <65bbf4a9-3666-6658-5c4e-700895da9161@oracle.com> On 9/9/2019 1:28 PM, Andy Herrick wrote: > > On 9/9/19 1:14 PM, Kevin Rushforth wrote: >> Looks good with one question: >> >> In Arguments.java: >> >> +???????????????????? if (bundler.isDefault()) { >> +???????????????????????? return bundler; >> +???????????????????? } else { >> +???????????????????????? savedBundler = bundler; >> +???????????????????? } >> >> When would there be a valid case where you loop through the list of >> bundlers and don't find a default? It may be better to throw an error >> in that case rather than just return the last one found. >> >> -- Kevin >> > This left the possibility that if the default were not supported but > another form was, then it became the default. > > On Windows, the two package types, msi and exe now require the same > tools, and on linux, deb is only the default if (among other things) > it is supported. > > So that leaves only macOS.? here dmg is default but required hdmiutil > and osascript. > > If either of these are missing dmg is not supported, so this code > would build pkg package if --package-type not specified.? Would it be > better to just get error and only build pkg if it is explicitly > specified as --package-type pkg ? I think exiting with error if dmg tools are not available on macOS would be better. This would be more predictable. - Alexet > > > /Andy > >> >> On 9/8/2019 2:50 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 fix: >>> >>> Adds "app-image" as a valid value for "--package-type" options, >>> meaning build an application image instead of a package. >>> >>> Changes the default value of "--package-type" to a platform >>> dependent default package type. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8230519 >>> [2] http://cr.openjdk.java.net/~herrick/8230519/webrev.01/ >>> >>> Thanks >>> >>> Andy, >>> >> From naoto.sato at oracle.com Mon Sep 9 18:23:12 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 9 Sep 2019 11:23:12 -0700 Subject: [14] RFR: 8230284: Accounting currency format support does not cope with explicit number system. In-Reply-To: <5fae8e71-2ac0-e9d2-72ba-cee05cfafcfb@oracle.com> References: <5fae8e71-2ac0-e9d2-72ba-cee05cfafcfb@oracle.com> Message-ID: <6c441a14-ed21-b7ba-6e4a-f19402be6d31@oracle.com> Hi Roger, Thanks for the review. On 9/9/19 8:12 AM, Roger Riggs wrote: > Hi Naoto, > > Bundle.java: > ?- 28: Explicit import are preferred,? (if the IDE make the change, fix > the settings in the IDE). Corrected. > > ?- 763, the indentation of the nested getOrDefault calls doesn't look > conventional. > ? (It might be interesting to have an API that allows one or more > defaults to be tried in turn. > ?? It will call each of the methods so there is no shortcutting if the > value is found early in the list). The code meant to short cut if a value is found early, as this implements the fallback. I corrected the indentation of getOrDefault() methods. > > CLDRConverter: > ?- 513, 1169...: Debugging code can be removed I removed the one around line 513, but kept the 1169 as this is useful. It does not affect the JDK image as this is the code for the build tool. > > Otherwise looks ok. Updated webrev is here: http://cr.openjdk.java.net/~naoto/8230284/webrev.01/ Naoto > > Thanks, Roger > > > > On 9/6/19 1:59 PM, naoto.sato at oracle.com wrote: >> Hello, >> >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8230284 >> >> The proposed changeset is located at: >> >> https://cr.openjdk.java.net/~naoto/8230284/webrev.00/ >> >> The original enhancement for the accounting currency format support >> (https://bugs.openjdk.java.net/browse/JDK-8215181) did not account for >> the explicit/implicit numbering script. The above change made it to >> share the same code with NumberElements which properly deals with the >> numbering script. >> >> Naoto > From brian.burkhalter at oracle.com Mon Sep 9 19:02:48 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 9 Sep 2019 12:02:48 -0700 Subject: 8230342: LineNumberReader.getLineNumber() returns inconsistent results after EOF In-Reply-To: <96566b30-af50-b264-abf2-6067d07e17e2@oracle.com> References: <553C9BEC-AC7D-4263-B785-E3C703D09819@oracle.com> <96566b30-af50-b264-abf2-6067d07e17e2@oracle.com> Message-ID: <3D17F646-6BDD-4F22-B17B-AE04F09EA763@oracle.com> Hi Roger, Thanks for the review. > On Sep 9, 2019, at 7:35 AM, Roger Riggs wrote: > > I would lean toward updating the spec to reflect the current implementation. It seems strange however that if one read an entire stream using read() in one case and readLine() in another that the results would differ. > A simple program that uses readline and prints the line number and line would show a duplicate line number. > > try (LineNumberReader r = > new LineNumberReader(Files.newBufferedReader(Path.of(args[0])))) { > String s; > while ((s = r.readLine()) !=null) { > System.out.printf("%3d: %s%n", r.getLineNumber(), s); > } > } > > 1: 123 > 1: ABC For a file with this contents (two lines) 123 ABC I see the same result for the above code both with and without my patch: 1: 123 2: ABC > Other questions and comments: > > - Is the use of AtomicBoolean due to concurrency concerns? > If not, a new boolean[1] would be less overhead No concurrency so that would be better. > - BufferedReader also keeps track of CR/LF pairs and I've thought it would simpler > not to duplicate the line number counting logic in LineNumberReader. > If BufferedReader kept track of the line number, it could expose a package private field > to LineNumberReader to make it visible to the get/SetLineNumber methods of LineNumberReader. That could be a good simplification. Thanks, Brian From Roger.Riggs at oracle.com Mon Sep 9 19:07:51 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 9 Sep 2019 15:07:51 -0400 Subject: [14] RFR: 8230284: Accounting currency format support does not cope with explicit number system. In-Reply-To: <6c441a14-ed21-b7ba-6e4a-f19402be6d31@oracle.com> References: <5fae8e71-2ac0-e9d2-72ba-cee05cfafcfb@oracle.com> <6c441a14-ed21-b7ba-6e4a-f19402be6d31@oracle.com> Message-ID: Hi, Looks fine. [The code is clear as is; but the shortcuts in Bundle.java (770-775) won't actually be a shortcut because for each method it has to compute the value of the argument before it can call the method. There isn't an API that accepts a supplier that would not be evaluated until the value was needed.] Thanks, Roger On 9/9/19 2:23 PM, naoto.sato at oracle.com wrote: > Hi Roger, > > Thanks for the review. > > On 9/9/19 8:12 AM, Roger Riggs wrote: >> Hi Naoto, >> >> Bundle.java: >> ??- 28: Explicit import are preferred,? (if the IDE make the change, >> fix the settings in the IDE). > > Corrected. > >> >> ??- 763, the indentation of the nested getOrDefault calls doesn't >> look conventional. >> ?? (It might be interesting to have an API that allows one or more >> defaults to be tried in turn. >> ??? It will call each of the methods so there is no shortcutting if >> the value is found early in the list). > > The code meant to short cut if a value is found early, as this > implements the fallback. I corrected the indentation of getOrDefault() > methods. > >> >> CLDRConverter: >> ??- 513, 1169...: Debugging code can be removed > > I removed the one around line 513, but kept the 1169 as this is > useful. It does not affect the JDK image as this is the code for the > build tool. > >> >> Otherwise looks ok. > > Updated webrev is here: > > http://cr.openjdk.java.net/~naoto/8230284/webrev.01/ > > Naoto > >> >> Thanks, Roger >> >> >> >> On 9/6/19 1:59 PM, naoto.sato at oracle.com wrote: >>> Hello, >>> >>> Please review the fix to the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8230284 >>> >>> The proposed changeset is located at: >>> >>> https://cr.openjdk.java.net/~naoto/8230284/webrev.00/ >>> >>> The original enhancement for the accounting currency format support >>> (https://bugs.openjdk.java.net/browse/JDK-8215181) did not account >>> for the explicit/implicit numbering script. The above change made it >>> to share the same code with NumberElements which properly deals with >>> the numbering script. >>> >>> Naoto >> From andy.herrick at oracle.com Mon Sep 9 19:15:18 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 9 Sep 2019 15:15:18 -0400 Subject: RFR: JDK-8230522: rename "--linux-bundle-name", and "--temp-root" options. Message-ID: <8c645d78-983d-9414-d502-5053fc1c6960@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: modifies the name of options: --temp-root, --linux-bundle-name , --mac-bundle-name, --mac-bundle-identifier, and --mac-bundle-signing-prefix. new names: --temp, --linux-package-name , --mac-package-name, --mac-package-identifier, and --mac-package-signing-prefix. This change also also removes the period at the end of all error messages. [1] https://bugs.openjdk.java.net/browse/JDK-8230522 [2] http://cr.openjdk.java.net/~herrick/8230522 Thanks Andy, From andy.herrick at oracle.com Mon Sep 9 19:17:10 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 9 Sep 2019 15:17:10 -0400 Subject: RFR: JDK-8230519: jpackage "--package-type" values and default In-Reply-To: <76da82a3-6298-9f8a-5ef2-079b4f4b1b92@oracle.com> References: <12ea1a11-8be5-178b-beba-6fda2b5cc18a@oracle.com> <76da82a3-6298-9f8a-5ef2-079b4f4b1b92@oracle.com> Message-ID: <7e98074e-6504-685d-13a0-190c37229544@oracle.com> On 9/9/2019 1:25 PM, Alexey Semenyuk wrote: > http://cr.openjdk.java.net/~herrick/8230519/webrev.01/test/jdk/tools/jpackage/share/RuntimeTest.java.sdiff.html: > > --- > 37???????? "--package-type", "app-image", > 38???????? "--package-type", "app-image", > --- > Duplication by accident? yes - will fix. > > http://cr.openjdk.java.net/~herrick/8230519/webrev.01/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebBundler.java.sdiff.html: > > --- > // we are just going to run "dpkg -s coreutils" ans assume Debian > --- > "ans" - typo? Should it be "and"? yes - will fix > > - Alexey > > On 9/8/2019 5:50 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 fix: >> >> Adds "app-image" as a valid value for "--package-type" options, >> meaning build an application image instead of a package. >> >> Changes the default value of "--package-type" to a platform dependent >> default package type. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8230519 >> [2] http://cr.openjdk.java.net/~herrick/8230519/webrev.01/ >> >> Thanks >> >> Andy, >> > From naoto.sato at oracle.com Mon Sep 9 19:21:57 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 9 Sep 2019 12:21:57 -0700 Subject: [14] RFR: 8230284: Accounting currency format support does not cope with explicit number system. In-Reply-To: References: <5fae8e71-2ac0-e9d2-72ba-cee05cfafcfb@oracle.com> <6c441a14-ed21-b7ba-6e4a-f19402be6d31@oracle.com> Message-ID: Thanks again, Roger. I now get what you meant. Yes, the current code does calculate each value before getting the correct one. Naoto On 9/9/19 12:07 PM, Roger Riggs wrote: > Hi, > > Looks fine. > > [The code is clear as is; but the shortcuts in Bundle.java (770-775) > won't actually be a shortcut > because for each method it has to compute the value of the argument > before it can call the method. > There isn't an API that accepts a supplier that would not be evaluated > until the value was needed.] > > Thanks, Roger > > > On 9/9/19 2:23 PM, naoto.sato at oracle.com wrote: >> Hi Roger, >> >> Thanks for the review. >> >> On 9/9/19 8:12 AM, Roger Riggs wrote: >>> Hi Naoto, >>> >>> Bundle.java: >>> ??- 28: Explicit import are preferred,? (if the IDE make the change, >>> fix the settings in the IDE). >> >> Corrected. >> >>> >>> ??- 763, the indentation of the nested getOrDefault calls doesn't >>> look conventional. >>> ?? (It might be interesting to have an API that allows one or more >>> defaults to be tried in turn. >>> ??? It will call each of the methods so there is no shortcutting if >>> the value is found early in the list). >> >> The code meant to short cut if a value is found early, as this >> implements the fallback. I corrected the indentation of getOrDefault() >> methods. >> > > > >>> >>> CLDRConverter: >>> ??- 513, 1169...: Debugging code can be removed >> >> I removed the one around line 513, but kept the 1169 as this is >> useful. It does not affect the JDK image as this is the code for the >> build tool. >> >>> >>> Otherwise looks ok. >> >> Updated webrev is here: >> >> http://cr.openjdk.java.net/~naoto/8230284/webrev.01/ >> >> Naoto >> >>> >>> Thanks, Roger >>> >>> >>> >>> On 9/6/19 1:59 PM, naoto.sato at oracle.com wrote: >>>> Hello, >>>> >>>> Please review the fix to the following issue: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8230284 >>>> >>>> The proposed changeset is located at: >>>> >>>> https://cr.openjdk.java.net/~naoto/8230284/webrev.00/ >>>> >>>> The original enhancement for the accounting currency format support >>>> (https://bugs.openjdk.java.net/browse/JDK-8215181) did not account >>>> for the explicit/implicit numbering script. The above change made it >>>> to share the same code with NumberElements which properly deals with >>>> the numbering script. >>>> >>>> Naoto >>> > From swpalmer at gmail.com Mon Sep 9 19:36:33 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 9 Sep 2019 15:36:33 -0400 Subject: jpackage on MacOs: app from pkg cannot write files and create directories inside itself In-Reply-To: References: Message-ID: <2E979288-5259-4116-948D-B8B956115F59@gmail.com> You should never write inside an application bundle. (Thank the malware writers for these restrictions.) On macOS your writable files should go somewhere under /Library/Application Support/ or ~/Library/Application Support/ On Windows you should write to somewhere under %ProgramData%, %APPDATA%, or %LOCALAPPDATA% Scott > On Sep 6, 2019, at 8:49 AM, Andrey Volkov wrote: > > Hello. > > I use jpackage (Build 14-jpackage+1-35) to bundle my Swing-based app for > MacOS. Whereas DMG format works pretty well, PGK bundle has a serious > issue. When I install the app from PKG, it cannot write files or create > directories inside itself. > I have /resource directory for my app that has a few settings and temp > directory for file processing. For the app from PKG I get "File not Found > (Permission Denied)" when the app tries to create a directory like > "/Application/MyApp.app/Contents/Java/resources/temp" or any write/create > any file inside "/Application/MyApp.app/Contents/Java/resources/" > Do you have any clue how to fix it for PKG bundle? I would prefer to use it > because it has a more user-friendly installation. > > BTW, Windows has a similar issue when per-user installation works fine, but > a system-wide installation in "Program Files" lack permissions to write > files inside "Program File/MyApp". > > -- > Best regards, > Andrey Volkov From mrjarviscraft at gmail.com Mon Sep 9 19:36:54 2019 From: mrjarviscraft at gmail.com (JARvis PROgrammer) Date: Mon, 9 Sep 2019 22:36:54 +0300 Subject: [PATCH] Allow LambdaMetaFactory generate direct field access instructions Message-ID: Hi there, according to the latest sources of JDK, LambdaMetafactory is unable to create Lambdas for field-access instructions (getstatic, putstatic, getfield, setfield). While on Java 9+ this is not a serious issue (as we already have VarHandle API for this), this is nice for backporting to Java 8 where this would allow framework developers use this for generating field access implementations at runtime. Here is the diff-file: https://gist.github.com/JarvisCraft/d66e69d47be56451a0f74cd9208457f6 It is made to be minimal in its changes thus modifying only AbstractValidatingLambdaMetaFactory (originally prohibiting the creation of Lambdas for REF_getStatic, REF_putStatic, REF_getField, REF_getField) changing the switch in the constructor and adding a boolean field indicating whether the generated code should be for a method or a field and modyfying InnerClassLambdaMetaFactory.ForwardingMethodGenerator#generate() adding ASM-code generation for field access. It seems that there is nothing more needed to implement this change according to the source code of the changed classes. Yet, I expect this change to be inappropriate for here and thus ask you to forward me (if possible) to any other mailing list or explain what else is needed to have this patched. Thanks in advance, Peter From mrjarviscraft at gmail.com Mon Sep 9 19:48:35 2019 From: mrjarviscraft at gmail.com (JARvis PROgrammer) Date: Mon, 9 Sep 2019 22:48:35 +0300 Subject: [PATCH] Allow LambdaMetaFactory generate direct field access instructions In-Reply-To: References: Message-ID: This may be considered related to https://bugs.openjdk.java.net/browse/JDK-8222744 according to which the creation of MethodHandles was allowed for fields. ??, 9 ????. 2019 ?. ? 22:36, JARvis PROgrammer : > Hi there, according to the latest sources of JDK, LambdaMetafactory is > unable to create Lambdas for field-access instructions (getstatic, > putstatic, getfield, setfield). While on Java 9+ this is not a > serious issue (as we already have VarHandle API for this), this is nice > for backporting to Java 8 where this would allow framework developers use > this for generating field access implementations at runtime. > > Here is the diff-file: > https://gist.github.com/JarvisCraft/d66e69d47be56451a0f74cd9208457f6 > It is made to be minimal in its changes thus modifying only > AbstractValidatingLambdaMetaFactory (originally prohibiting the creation > of Lambdas for REF_getStatic, REF_putStatic, REF_getField, REF_getField) > changing the switch in the constructor and adding a boolean field > indicating whether the generated code should be for a method or a field and > modyfying > InnerClassLambdaMetaFactory.ForwardingMethodGenerator#generate() adding > ASM-code generation for field access. > It seems that there is nothing more needed to implement this change > according to the source code of the changed classes. > > Yet, I expect this change to be inappropriate for here and thus ask you to > forward me (if possible) to any other mailing list or explain what else is > needed to have this patched. > > Thanks in advance, > Peter > From alexey.semenyuk at oracle.com Mon Sep 9 20:43:35 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Mon, 9 Sep 2019 16:43:35 -0400 Subject: RFR: JDK-8230522: rename "--linux-bundle-name", and "--temp-root" options. In-Reply-To: <8c645d78-983d-9414-d502-5053fc1c6960@oracle.com> References: <8c645d78-983d-9414-d502-5053fc1c6960@oracle.com> Message-ID: <28b828d2-a75f-a19f-f90e-b20c91e6cad5@oracle.com> Looks good. - Alexey On 9/9/2019 3:15 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 fix: > > modifies the name of options: > > --temp-root, --linux-bundle-name , --mac-bundle-name, > --mac-bundle-identifier, and --mac-bundle-signing-prefix. > > new names: > > --temp, --linux-package-name , --mac-package-name, > --mac-package-identifier, and --mac-package-signing-prefix. > > This change also also removes the period at the end of all error > messages. > > [1] https://bugs.openjdk.java.net/browse/JDK-8230522 > [2] http://cr.openjdk.java.net/~herrick/8230522 > > Thanks > > Andy, > From brian.burkhalter at oracle.com Mon Sep 9 21:02:39 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 9 Sep 2019 14:02:39 -0700 Subject: 8230342: LineNumberReader.getLineNumber() returns inconsistent results after EOF In-Reply-To: <3D17F646-6BDD-4F22-B17B-AE04F09EA763@oracle.com> References: <553C9BEC-AC7D-4263-B785-E3C703D09819@oracle.com> <96566b30-af50-b264-abf2-6067d07e17e2@oracle.com> <3D17F646-6BDD-4F22-B17B-AE04F09EA763@oracle.com> Message-ID: If we wanted to go the route of changing the spec to match the behavior, the additional verbiage below is one possibility. Thanks, Brian +++ b/src/java.base/share/classes/java/io/LineNumberReader.java @@ -35,19 +35,20 @@ *

By default, line numbering begins at 0. This number increments at every * line terminator as the data is read, and can be changed * with a call to {@code setLineNumber(int)}. Note however, that * {@code setLineNumber(int)} does not actually change the current position in * the stream; it only changes the value that will be returned by * {@code getLineNumber()}. * *

A line is considered to be terminated by any one of a * line feed ('\n'), a carriage return ('\r'), or a carriage return followed - * immediately by a linefeed. + * immediately by a linefeed. For {@link #readLine()} only, the end of the + * stream is also considered to be a line terminator. public class LineNumberReader extends BufferedReader { /** The current line number */ private int lineNumber = 0; @@ -183,19 +184,21 @@ } } return n; } } /** * Read a line of text. Whenever a line terminator is - * read the current line number is incremented. + * read the current line number is incremented. Unlike for the other + * {@code read} methods of this class, reaching the end of the stream + * will also increment the current line number. * * @return A String containing the contents of the line, not including * any line termination characters, or * {@code null} if the end of the stream has been reached * * @throws IOException * If an I/O error occurs */ public String readLine() throws IOException { > On Sep 9, 2019, at 12:02 PM, Brian Burkhalter wrote: > >> On Sep 9, 2019, at 7:35 AM, Roger Riggs > wrote: >> >> I would lean toward updating the spec to reflect the current implementation. > > It seems strange however that if one read an entire stream using read() in one case and readLine() in another that the results would differ. From Alan.Bateman at oracle.com Mon Sep 9 21:00:47 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 9 Sep 2019 22:00:47 +0100 Subject: [14] RFR: 8229960: Remove sun.nio.cs.map system property In-Reply-To: <992b60f8-6741-31b4-f1bf-09764eeff359@oracle.com> References: <992b60f8-6741-31b4-f1bf-09764eeff359@oracle.com> Message-ID: <8c8ce946-01a9-df08-41c1-d0f0f34a42d5@oracle.com> On 09/09/2019 16:15, naoto.sato at oracle.com wrote: > Hi, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8229960 > > Here are the links to its CSR and proposed changeset: > > https://bugs.openjdk.java.net/browse/JDK-8230405 > https://cr.openjdk.java.net/~naoto/8229960/webrev.00/ > I assume the -Dsun.nio.cs.map= can be removed from test/jdk/java/nio/charset/coders/Check.java. Everything else looks good, I think you've got everything. -Alan. From mandy.chung at oracle.com Mon Sep 9 21:03:35 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 9 Sep 2019 14:03:35 -0700 Subject: RFR JDK-8229785: MethodType::fromMethodDescriptorString should require security permission if loader is null Message-ID: MethodType::fromMethodDescriptorString default to use the system class loader in resolving classes per the given descriptor string if the loader parameter is null.? Since this method accesses the system class loader on behalf of the caller, it should do a security permission check as ClassLoader::getSystemClassLoader. Webrev: ?? http://cr.openjdk.java.net/~mchung/jdk14/8229785/webrev.00/ CSR: ?? https://bugs.openjdk.java.net/browse/JDK-8230777 Thanks Mandy From vicente.romero at oracle.com Mon Sep 9 21:46:38 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 9 Sep 2019 17:46:38 -0400 Subject: RFR JDK-8229785: MethodType::fromMethodDescriptorString should require security permission if loader is null In-Reply-To: References: Message-ID: looks good, Vicente On 9/9/19 5:03 PM, Mandy Chung wrote: > MethodType::fromMethodDescriptorString default to use the system class > loader in resolving classes per the given descriptor string if the > loader parameter is null.? Since this method accesses the system class > loader on behalf of the caller, it should do a security permission > check as ClassLoader::getSystemClassLoader. > > Webrev: > ?? http://cr.openjdk.java.net/~mchung/jdk14/8229785/webrev.00/ > CSR: > ?? https://bugs.openjdk.java.net/browse/JDK-8230777 > > Thanks > Mandy From rafael.wth at gmail.com Mon Sep 9 22:12:13 2019 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Tue, 10 Sep 2019 00:12:13 +0200 Subject: RFR: JDK-8202469 - Type annotations on type variable bounds are not computed correctly for generic types Message-ID: Hi, the type annotation parser does not currently resolve the type path of type variable bounds correctly. If a type variable bound is itself a parameterized type, the index is not computed correctly. This patch adds checks for the type variable bound types to correct the index computation. Webrev: http://cr.openjdk.java.net/~winterhalter/8202469/ The patch includes tests for all different scenarios. The reported issue is only one symptom of the problem but correcting the index computation also solves JDK-8202473. Thank you for the review! Rafael From rafael.wth at gmail.com Mon Sep 9 22:14:53 2019 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Tue, 10 Sep 2019 00:14:53 +0200 Subject: RFR: 8228988 - Type annotation parser throws null pointer upon incompatible attribute type Message-ID: Hello, the type annotation parser does not currently check if a member type for an enum or annotation type is actually still an enum or annotation type at runtime upon resolving an annotation. This causes a null pointer exception while it should yield an incompatibility exception upon resolving the property instead. Webrev: http://cr.openjdk.java.net/~winterhalter/8228988/ Best regards, Rafael From alexander.matveev at oracle.com Mon Sep 9 22:19:53 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Mon, 9 Sep 2019 15:19:53 -0700 Subject: RFR: JDK-8230726: Improve jpackage jtreg tests In-Reply-To: <14a0e3be-662f-d2c1-5d03-cff519a1b66d@oracle.com> References: <39e9b825-6668-af17-c4a3-c584a6ef0647@oracle.com> <14a0e3be-662f-d2c1-5d03-cff519a1b66d@oracle.com> Message-ID: Looks good. On 9/9/2019 10:14 AM, 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). > > - reworked jpackage tests that produce platform specific packages to > get rid of code duplication; > - replaced install.sh/uninstall.sh scripts on Linux and Windows with > shared manage_packages.sh script that will batch install/uninstall > packages. Support for dmg, pkg and exe installers TBD. > > [1] https://bugs.openjdk.java.net/browse/JDK-8230726 > > [2] http://cr.openjdk.java.net/~asemenyuk/8230726/webrev.03 > > Thanks, > Alexey > From andy.herrick at oracle.com Mon Sep 9 22:25:55 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 9 Sep 2019 18:25:55 -0400 Subject: RFR: JDK-8230519: jpackage "--package-type" values and default In-Reply-To: <12ea1a11-8be5-178b-beba-6fda2b5cc18a@oracle.com> References: <12ea1a11-8be5-178b-beba-6fda2b5cc18a@oracle.com> Message-ID: <199dc73b-4389-0a32-3374-78dce64b1400@oracle.com> Please review the updated jpackage fix for bug [1] at [3]. Functional change:? If the default package type is called for, but for some reason the default package type is not supported on this machine, it will be an error (we will not try to build any other package type) Typo fixed in comment, and small fix to RuntimeTest.java. [3] http://cr.openjdk.java.net/~herrick/8230519/webrev.02/ /Andy On 9/8/2019 5:50 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 fix: > > Adds "app-image" as a valid value for "--package-type" options, > meaning build an application image instead of a package. > > Changes the default value of "--package-type" to a platform dependent > default package type. > > [1] https://bugs.openjdk.java.net/browse/JDK-8230519 > [2] http://cr.openjdk.java.net/~herrick/8230519/webrev.01/ > > Thanks > > Andy, > From alexander.matveev at oracle.com Mon Sep 9 22:31:32 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Mon, 9 Sep 2019 15:31:32 -0700 Subject: RFR: JDK-8230522: rename "--linux-bundle-name", and "--temp-root" options. In-Reply-To: <8c645d78-983d-9414-d502-5053fc1c6960@oracle.com> References: <8c645d78-983d-9414-d502-5053fc1c6960@oracle.com> Message-ID: <14ad9c41-72e4-b4d2-7179-9c1a30a35578@oracle.com> Hi Andy, http://cr.openjdk.java.net/~herrick/8230522/webrev.01/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/LinuxResources.properties.frames.html Line 44 "mp." -> "map" http://cr.openjdk.java.net/~herrick/8230522/webrev.01/src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java.frames.html Do we want to rename internal names like MAC_BUNDLE_NAME? -> MAC_PACKAGE_NAME? I think we should at least as follow up cleanup issue, to make code less confusing with different name. Otherwise looks fine. Thanks, Alexander On 9/9/2019 12:15 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 fix: > > modifies the name of options: > > --temp-root, --linux-bundle-name , --mac-bundle-name, > --mac-bundle-identifier, and --mac-bundle-signing-prefix. > > new names: > > --temp, --linux-package-name , --mac-package-name, > --mac-package-identifier, and --mac-package-signing-prefix. > > This change also also removes the period at the end of all error > messages. > > [1] https://bugs.openjdk.java.net/browse/JDK-8230522 > [2] http://cr.openjdk.java.net/~herrick/8230522 > > Thanks > > Andy, > From naoto.sato at oracle.com Mon Sep 9 22:36:32 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 9 Sep 2019 15:36:32 -0700 Subject: [14] RFR: 8229960: Remove sun.nio.cs.map system property In-Reply-To: <8c8ce946-01a9-df08-41c1-d0f0f34a42d5@oracle.com> References: <992b60f8-6741-31b4-f1bf-09764eeff359@oracle.com> <8c8ce946-01a9-df08-41c1-d0f0f34a42d5@oracle.com> Message-ID: Thanks for the review, Alan. I left the -Dsun.nio.cs.map= so that it ensures "Shift_JIS" designates IANA charset, not the code page 932, even if the property is specified. Naoto On 9/9/19 2:00 PM, Alan Bateman wrote: > On 09/09/2019 16:15, naoto.sato at oracle.com wrote: >> Hi, >> >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8229960 >> >> Here are the links to its CSR and proposed changeset: >> >> https://bugs.openjdk.java.net/browse/JDK-8230405 >> https://cr.openjdk.java.net/~naoto/8229960/webrev.00/ >> > I assume the -Dsun.nio.cs.map= can be removed from > test/jdk/java/nio/charset/coders/Check.java. Everything else looks good, > I think you've got everything. > > -Alan. From andy.herrick at oracle.com Mon Sep 9 22:48:56 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 9 Sep 2019 18:48:56 -0400 Subject: RFR: JDK-8230522: rename "--linux-bundle-name", and "--temp-root" options. In-Reply-To: <14ad9c41-72e4-b4d2-7179-9c1a30a35578@oracle.com> References: <8c645d78-983d-9414-d502-5053fc1c6960@oracle.com> <14ad9c41-72e4-b4d2-7179-9c1a30a35578@oracle.com> Message-ID: On 9/9/2019 6:31 PM, Alexander Matveev wrote: > Hi Andy, > > http://cr.openjdk.java.net/~herrick/8230522/webrev.01/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/LinuxResources.properties.frames.html > > Line 44 "mp." -> "map" This is a typo I will fix. > > http://cr.openjdk.java.net/~herrick/8230522/webrev.01/src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java.frames.html > > Do we want to rename internal names like MAC_BUNDLE_NAME? -> > MAC_PACKAGE_NAME? Generally, I didn't want to change anything but the CLI option name, and that includes the deploy parameter name used internally. If we want a follow up issue to make all internal deploy parameter identifiers correspond more closely to the CLI options they reflect, I have no problem with that, but it would apply to a lot more than the 4-5 options being renamed here. > I think we should at least as follow up cleanup issue, to make code > less confusing with different name. > > Otherwise looks fine. > > Thanks, > Alexander > > On 9/9/2019 12:15 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 fix: >> >> modifies the name of options: >> >> --temp-root, --linux-bundle-name , --mac-bundle-name, >> --mac-bundle-identifier, and --mac-bundle-signing-prefix. >> >> new names: >> >> --temp, --linux-package-name , --mac-package-name, >> --mac-package-identifier, and --mac-package-signing-prefix. >> >> This change also also removes the period at the end of all error >> messages. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8230522 >> [2] http://cr.openjdk.java.net/~herrick/8230522 >> >> Thanks >> >> Andy, >> > From alexander.matveev at oracle.com Mon Sep 9 23:09:36 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Mon, 9 Sep 2019 16:09:36 -0700 Subject: RFR: JDK-8230519: jpackage "--package-type" values and default In-Reply-To: <199dc73b-4389-0a32-3374-78dce64b1400@oracle.com> References: <12ea1a11-8be5-178b-beba-6fda2b5cc18a@oracle.com> <199dc73b-4389-0a32-3374-78dce64b1400@oracle.com> Message-ID: Hi Andy, http://cr.openjdk.java.net/~herrick/8230519/webrev.02/test/jdk/tools/jpackage/share/ErrorTest.java.frames.html Line 90: Add space before ARG2. Looks good. Thanks, Alexander On 9/9/2019 3:25 PM, Andy Herrick wrote: > Please review the updated jpackage fix for bug [1] at [3]. > > Functional change:? If the default package type is called for, but for > some reason the default package type is not supported on this machine, > it will be an error (we will not try to build any other package type) > > Typo fixed in comment, and small fix to RuntimeTest.java. > > [3] http://cr.openjdk.java.net/~herrick/8230519/webrev.02/ > > /Andy > > On 9/8/2019 5:50 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 fix: >> >> Adds "app-image" as a valid value for "--package-type" options, >> meaning build an application image instead of a package. >> >> Changes the default value of "--package-type" to a platform dependent >> default package type. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8230519 >> [2] http://cr.openjdk.java.net/~herrick/8230519/webrev.01/ >> >> Thanks >> >> Andy, >> From stuart.marks at oracle.com Mon Sep 9 23:39:06 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 9 Sep 2019 16:39:06 -0700 Subject: RFR 8230365 : Pattern for a control-char matches non-control characters In-Reply-To: References: <4f81d7bb-3e2b-337a-2f53-a4bc71049d62@oracle.com> <98993cd0-27f8-cda4-ce3b-52d21564a246@oracle.com> <0953495a-082b-afad-0822-393d2d7a26e4@oracle.com> Message-ID: <3a2efd9c-68e0-6094-ef58-7295b1e7bd6b@oracle.com> On 9/5/19 1:43 PM, Ivan Gerasimov wrote: > Personally, I don't have a strong preference here. > > The compatibility property are meant to be temporary anyways. > > Maybe if we have a single option that will control several different aspects of > behavior, it will be harder to get rid of it? > > Partially, because it will be tempting to reuse it for other similar changes, > should they be needed. OK, let's take an inventory of what behavior changes are being contemplated for regexes: JDK-8230675 restrict IDs for control chars JDK-xxxxxxx allow case-insensitive IDs for control chars *NOTE* JDK-8225021 Treat ambiguous embedded flags as parse syntax errors JDK-8214245 Case insensitive matching doesn't work correctly for some character classes *NOTE* this was part of the original JDK-8230675 proposal, but you removed it after discussion. I don't know if we decided never to do this, or whether we're merely considering it separately. It seemed to me that there was a possibility that we'd do this in the future. Is this all the behavior changes being contemplated, or is this simply the set that we happened to have stumbled across recently? Put another way, if we decided to do some further analysis of regexes, would we run across other issues where we might say, "Yeah, we ought to fix that, but that would be a potentially incompatible behavior change, so we need to add another property." ? In practice, such properties are only removed after a very long time, or perhaps even "never." It's not like this change would be added in this release (JDK 14), with backward compatibility support removed in a year (say, JDK 16) along with the property. The property, and the backward compatibility mode, would stick around in the code for many years. What I want to avoid doing is to introduce behavior changes -- and properties to control them -- in a piecemeal fashion. It looks like we might have three or four candidates already. Would we want to live with three or four properties? If we did this and continued with additional changes, we might end up with six or eight or ten properties over time. I'd like to see us look ahead a bit and take stock of what changes we're contemplating, and then decided how to deal with compatibility and migration based on that. I'd like to avoid making individual changes (and adding properties) one at a time, with decisions made in isolation, because that will lead to a proliferation of properties. s'marks From ivan.gerasimov at oracle.com Tue Sep 10 03:20:12 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 9 Sep 2019 20:20:12 -0700 Subject: RFR 8230365 : Pattern for a control-char matches non-control characters In-Reply-To: <3a2efd9c-68e0-6094-ef58-7295b1e7bd6b@oracle.com> References: <4f81d7bb-3e2b-337a-2f53-a4bc71049d62@oracle.com> <98993cd0-27f8-cda4-ce3b-52d21564a246@oracle.com> <0953495a-082b-afad-0822-393d2d7a26e4@oracle.com> <3a2efd9c-68e0-6094-ef58-7295b1e7bd6b@oracle.com> Message-ID: <658ef3e3-0c60-7451-0daa-0e846da88fb0@oracle.com> Thank you Stuart for the analysis! Please see my comments inline. On 9/9/19 4:39 PM, Stuart Marks wrote: > > > On 9/5/19 1:43 PM, Ivan Gerasimov wrote: >> Personally, I don't have a strong preference here. >> >> The compatibility property are meant to be temporary anyways. >> >> Maybe if we have a single option that will control several different >> aspects of behavior, it will be harder to get rid of it? >> >> Partially, because it will be tempting to reuse it for other similar >> changes, should they be needed. > > OK, let's take an inventory of what behavior changes are being > contemplated for regexes: > > JDK-8230675 restrict IDs for control chars > JDK-xxxxxxx allow case-insensitive IDs for control chars *NOTE* > JDK-8225021 Treat ambiguous embedded flags as parse syntax errors > JDK-8214245 Case insensitive matching doesn't work correctly for some > character classes > I quickly searched JBS and found several more bugs/enhancements requests that, if implemented, may result in the behavior changes. Here's (presumably incomplete) list: JDK-8218146? $ matches before end of line, even without MULTILINE mode JDK-8217977? Matcher matching trailing high surrogate reports false for requireEnd() JDK-8217501? Matcher.hitEnd returns false for incomplete surrogate pairs JDK-8217496? Matcher.group() can return null after usePattern JDK-8216332? Grapheme regex does not work with emoji sequences JDK-8199594? Regex Pattern class improperly ignores spaces in character classes JDK-8187083? Regex: Capturing groups inside a lookahead aren't backtracked JDK-8187082? Regex: Nested capturing groups under lazy repetition aren't backtracked JDK-8183391? Regex: End of line found more than once for non-multiline regex JDK-8179668? Valid regex patterns match the latter half of complete surrogate pairs JDK-8029966? Broken supplementary character support in regex JDK-6919621? Matcher find returns wrong result in java 1.6 for certain patterns All of them are of low priorities, so I don't anticipate active work on these bugs in the near future. Though at least some of them, if fixed, would make the Java regexp engine better, so it probably wouldn't make sense to just abandon these request because of the compatibility reasons. > *NOTE* this was part of the original JDK-8230675 proposal, but you > removed it after discussion. I don't know if we decided never to do > this, or whether we're merely considering it separately. It seemed to > me that there was a possibility that we'd do this in the future. > I was thinking of filling an enhancement request with the fix version set to TBD, so we can return to this proposal in some future release, if desirable. > Is this all the behavior changes being contemplated, or is this simply > the set that we happened to have stumbled across recently? Put another > way, if we decided to do some further analysis of regexes, would we > run across other issues where we might say, "Yeah, we ought to fix > that, but that would be a potentially incompatible behavior change, so > we need to add another property." ? > > In practice, such properties are only removed after a very long time, > or perhaps even "never." It's not like this change would be added in > this release (JDK 14), with backward compatibility support removed in > a year (say, JDK 16) along with the property. The property, and the > backward compatibility mode, would stick around in the code for many > years. > > What I want to avoid doing is to introduce behavior changes -- and > properties to control them -- in a piecemeal fashion. It looks like we > might have three or four candidates already. Would we want to live > with three or four properties? If we did this and continued with > additional changes, we might end up with six or eight or ten > properties over time. > > I'd like to see us look ahead a bit and take stock of what changes > we're contemplating, and then decided how to deal with compatibility > and migration based on that. I'd like to avoid making individual > changes (and adding properties) one at a time, with decisions made in > isolation, because that will lead to a proliferation of properties. > So, there are two alternatives at the table at this time: 1) A single compatibility property to revert to the old behavior; The property is reused for each of listed above bugs, so with each fix a portion of revert logic is added to the property. PROS:? Easy to implement and maintain. CONS:? Over time, can become hard to track, what exactly the property controls, so may be hard to use.? For example, if a user turns on this property to revert a single aspect of behavior, one will get all other behavior oddities. 2) Individual properties for every change of behavior. PROS:? If needed, the behavior can be fine-grained.? Easier to understand what the expected behavior would be with every set of properties set. CONS:? Complex to maintain.? For the majority of cases would be just an overkill.? Also, can greatly increase number of testing (naively up to 2^{# of properties}). One possible compromise might be to introduce one umbrella property + set of individual properties as desired.? This all can be plugged into one string property, of course: jdk.util.regex.mode=strict? # default jdk.util.regex.mode=compatibility? #? turns on all compatibility properties at once jdk.util.regex.mode=restrictCntrlCharIds=yes,rejectAmbiguousEmbeddedFlags=no # fine grained settings If the changes implemented carefully, so that the individual properties are "orthogonal", then we wouldn't need to test all possible combinations, but only two opposite modes: strict and compatibility. Do you think it's a viable approach? -- With kind regards, Ivan Gerasimov From heiko.wagner at apis.de Tue Sep 10 08:55:11 2019 From: heiko.wagner at apis.de (Heiko Wagner) Date: Tue, 10 Sep 2019 10:55:11 +0200 Subject: Feedback JEP 343: Packaging Tool Message-ID: <9baf915a4b95c49fb519f09929441f6a@apis.de> I am sending this feedback as suggested by the jpackage project (https://jdk.java.net/jpackage/). I hope this is considered helpful information. I have tried the current build "14-jpackage+1-35" on Windows. It pretty much worked out of the box for me. Here are a few observations I make: - creating a image of the application is great for building protable applications. Sometime it is realy great to have the application on a thumb drive an just run it on any machine; currently i do this manually via jlink and use launch4j as a native launcher - MSI installation packages are great when deploying a application into a controlled it infrastructure, but in turn impose some restictions e.g. on application updates - my application is currently a portable app and does not use any native installer like MSI. Automatic updates are handled by the application by just in place updating the jar files. Deploying the application as a MSI would require to change the update behaviour. Even if automatic updates are out of the scope of the current JEP it would be helpful to have a common solution for this in the long run - Currently my app has a splash screen, since launch4j has support for a native splash screen. I have no tried it on jpackage, but the JEP states that there is no support for native splash screen. Does this also mean that the functionality of "-splash: fileName" and its manifest file counter part will not work when using the launcher generated jpackage? - Wher creating a image on Windows pretty much all .DLL from the bin folder in the runtime are duplicated into the application folder. Is this intended? When using the generic java.exe launcher it is not required to this. It just works fine with all .DLL/.EXE files in the runtime bin folder Thanks for making such a great tool. Keep up the good work. Regards, Heiko From goetz.lindenmaier at sap.com Tue Sep 10 09:47:36 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 10 Sep 2019 09:47:36 +0000 Subject: RFR (L, final): 8218626: Add detailed message to NullPointerException describing what is null. Message-ID: Hi, this is the implementation of JEP 358: Helpful NullPointerExceptions. The JEP is in status "Candidate". Coleen (many, many thanks!) ran it through the Oracle-internal processes. Now I please need final reviews for this change so that I can propose it to target jdk 14. JEP: https://bugs.openjdk.java.net/browse/JDK-8220715 Enhancement: https://bugs.openjdk.java.net/browse/JDK-8218628 webrev: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/16/ The change ran through a lot of testing, all jtreg and jck tests to name only some. The webrev points to patch http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/16/enable_NPE_message.patch that enables the change by default, which was useful for testing to assure the code is used in the tests. I just pushed the change to jdk/submit once more. Please review. Thanks! Goetz. From pavel.rappo at oracle.com Tue Sep 10 12:38:44 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 10 Sep 2019 13:38:44 +0100 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: <7A46485C-E250-4E57-9FB0-B9D18CA70632@oracle.com> References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> <87sgpblxns.fsf@oldenburg2.str.redhat.com> <7A46485C-E250-4E57-9FB0-B9D18CA70632@oracle.com> Message-ID: <60FD933F-51A5-4438-83AF-B3427CFDE60D@oracle.com> Milan, ping? > On 5 Sep 2019, at 16:02, Pavel Rappo wrote: > > I think we are almost there. What do you think of the following incremental (i.e. on top of your latest webrev) change? > > http://cr.openjdk.java.net/~prappo/8228580/webrev.01/ > > I fixed a couple of trivial typos and addressed the socket relinquishing issue. Initializing a socket is not an atomic "all-or-nothing" operation now. Someone needs to take care of the socket in case things go not as planned. > > -Pavel > >> On 5 Sep 2019, at 11:20, Milan Mimica wrote: >> >> On Wed, 4 Sep 2019 at 20:32, Florian Weimer wrote: >>> >>> If you use the initial UDP timeout (one second, I think), the kernel >>> will not complete the TCP handshake if the initial SYN segment is lost >>> because the retransmit delay during the handshake is longer than that. >> >> We could set a higher timeout value, but I would not prefer that. >> After all, 1 second is just default value, and can be changed. If the >> user wants us to give up on DNS query after the specified timeout then >> lets do just that. True, some queries that previously worked might >> start failing, but that is true even for slow socket.read() >> operations. >> >> New webrev: http://cr.openjdk.java.net/~mmimica/8228580/webrev.01/ >> >> * simplified test with no thread (nice catch Pavel) >> * set connect timeout and account for it >> >> -- >> Milan Mimica > From andy.herrick at oracle.com Tue Sep 10 12:51:38 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 10 Sep 2019 08:51:38 -0400 Subject: RFR: JDK-8230726: Improve jpackage jtreg tests In-Reply-To: <14a0e3be-662f-d2c1-5d03-cff519a1b66d@oracle.com> References: <39e9b825-6668-af17-c4a3-c584a6ef0647@oracle.com> <14a0e3be-662f-d2c1-5d03-cff519a1b66d@oracle.com> Message-ID: <39ae6435-9bef-4a31-c21e-8022f3d25ef1@oracle.com> This looks OK - I want it integrated before upcoming CLI changes so the test changes for the CLI changes will be done using the new test helpers. /Andy On 9/9/2019 1:14 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). > > - reworked jpackage tests that produce platform specific packages to > get rid of code duplication; > - replaced install.sh/uninstall.sh scripts on Linux and Windows with > shared manage_packages.sh script that will batch install/uninstall > packages. Support for dmg, pkg and exe installers TBD. > > [1] https://bugs.openjdk.java.net/browse/JDK-8230726 > > [2] http://cr.openjdk.java.net/~asemenyuk/8230726/webrev.03 > > Thanks, > Alexey > From pavel.rappo at oracle.com Tue Sep 10 14:25:04 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 10 Sep 2019 15:25:04 +0100 Subject: RFR [14] 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect In-Reply-To: References: <97114AA9-A44A-4C36-843C-1E6933348096@oracle.com> <026e37eb-3da6-5f39-ac8d-99ad26bba3d0@oracle.com> <81060A81-D77F-4F49-A131-DE79F66FE29B@oracle.com> <6db710f3-dff6-f6ea-5922-242516769ed8@oracle.com> <1A766DB0-E937-438A-BDE1-26DC29FC25EC@oracle.com> <0911E28D-E382-4A0E-A7DB-F775C522BFB4@oracle.com> Message-ID: <564053B0-6FC9-468A-B75D-94F796015BB6@oracle.com> > On 6 Sep 2019, at 20:02, Martin Buchholz wrote: > > Martin's rules for test methods: > - never have more than 100 millisecond total expected runtime > - never have more than 12 millisecond blocking time for any single operation > - yet be able to survive a one-time 5 second thread suspension at any time No doubt these are reputable numbers however magic they seem. I expect these make sense in a highly focused code, which j.u.c might be an example of. LDAP, on the other hand, does everything but the kitchen sink. So much so that I cannot guarantee any of those metrics to hold. The latter one is of particular interest to me. Could you maybe elaborate on what "a rare 5-second thread suspension" is? (Not that it will make me change the code, but out of pure curiosity.) > adjusting wait time looks like an anti-pattern to me. You can't stop a rare 5-second thread suspension at line 387. > > 385 final long waitTime = hiMillis - > 386 NANOSECONDS.toMillis(System.nanoTime() - startNanos); // (2) adjust wait time > 387 > 388 try { > 389 T r = task.get(waitTime, MILLISECONDS); // (3) wait for the task to complete > I agree it might make the code look more complicated, but it doesn't deserve the name "anti-pattern". Is it a bad solution? Should I expect it to backfire? The reason for using that is to make sure the code accommodates for a given timeout once, not many times. Yes, I agree I can't stop a thread suspension at line 387 or anywhere else for that matter, but I shouldn't account for it either. Maybe just once -- in the value of the timeout. Again, many thanks for looking at it! Thoughts? > On Fri, Sep 6, 2019 at 9:33 AM Pavel Rappo wrote: > > On 6 Sep 2019, at 15:59, Martin Buchholz wrote: > > > > I took another look at LdapTimeoutTest.java. > > Many thanks! > > > I was surprised to see RIGHT_MARGIN. In jsr166 we succeed in having one timeout that is long enough to "never happen". I'm still advocating the 10 second value. > > > > I was surprised to see LEFT_MARGIN. We just fixed Thread.sleep, so we have no known problems with JDK methods returning early - you can trust timed get! > > You start measuring, by calling nanoTime, before you start the activity you are measuring, so there should be no need for LEFT_MARGIN. > > You raised many good points. Let me try to address them. > > 1. RIGHT_MARGIN is not used for checking that the activity has stuck infinitely (assertIncompletion). INFINITY_MILLIS is used for that. RIGHT_MARGIN is used for checking that the activity takes some predefined amount of time (roughly). > > 2. As for the numeric value of INFINITY_MILLIS, the reason I chose 20 seconds is twofold. Firstly, the code under test is subject to different timeouts. Every timeout value should be distinctive. Otherwise, how would I differentiate between them? For example, if I chose INFINITY_MILLIS to be 10 seconds how would I know if the code is stuck due to the read timeout of 10 seconds or the "infinite timeout"? Secondly, I must take into account slow machines. Really slow virtual machines. Hence, minimal timeouts (read/connect) have a magnitude of seconds and tens of seconds and the "rightmost", infinite timeout, is 20 seconds. > > 3. LEFT_MARGIN might no longer be needed due to the fact that no timed methods return early (actually there is a comment about it inside those two assert methods). > > > We have some fresh thread-awaiting code here: > > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/tck/JSR166TestCase.java?view=markup#l1443 > > Interesting. > > > Instead of communicating startTime from the test thread back to the main thread, I would do my loMillis checking in the test thread, and hiMillis checking in the main thread, like e.g. compare with a fresh test method testTimedOffer > > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/tck/ArrayBlockingQueueTest.java?view=markup#l394 > > Understood. However, that might be a matter of taste. I prefer to have all the calculations and error handling in one place. Unless there's a good reason I wouldn't change it. > > > Timeouts should be adjusted via Utils.adjustTimeout > > That makes perfect sense. I never knew this method existed. Thanks! > > > On Fri, Sep 6, 2019 at 4:31 AM Pavel Rappo wrote: > > Martin, thanks for having a look at it. > > > > I'd appreciate if you could have a look at the timeout measuring mechanics in assertCompletion/assertIncompletion specifically, maybe to spot something that is grossly inadequate. > > > > I tried to accommodate some usual suspects of timeout measurements failures. I understand that since we're not working with real-time systems, my attempts to build bullet-proof measurement mechanics are futile. > > > > -Pavel > > > > > On 30 Aug 2019, at 18:19, Martin Buchholz wrote: > > > > > > Not really a review, but: > > > > > > For many years we've been using 10 seconds (scaled by timeout factor) as a duration long enough that a timeout is a real failure. > > > Which is close to your own 20 seconds. Of course, no value is surely safe. > > > > > > Probably, parallel testing infrastructure for timeouts should be a test library method. I do something similar in JSR166TestCase > > > > > > /** > > > * Runs all the given actions in parallel, failing if any fail. > > > * Useful for running multiple variants of tests that are > > > * necessarily individually slow because they must block. > > > */ > > > void testInParallel(Action ... actions) { > > > ExecutorService pool = Executors.newCachedThreadPool(); > > > try (PoolCleaner cleaner = cleaner(pool)) { > > > > > > On Fri, Aug 30, 2019 at 6:23 AM Daniel Fuchs wrote: > > > On 30/08/2019 13:54, Pavel Rappo wrote: > > > > Updated, > > > > > > > > http://cr.openjdk.java.net/~prappo/8151678/webrev.01/ > > > > > > > > > > Changes look good! > > > > > > best regards, > > > > > > -- daniel > > > From Roger.Riggs at oracle.com Tue Sep 10 14:33:14 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 10 Sep 2019 10:33:14 -0400 Subject: 8230342: LineNumberReader.getLineNumber() returns inconsistent results after EOF In-Reply-To: References: <553C9BEC-AC7D-4263-B785-E3C703D09819@oracle.com> <96566b30-af50-b264-abf2-6067d07e17e2@oracle.com> <3D17F646-6BDD-4F22-B17B-AE04F09EA763@oracle.com> Message-ID: Hi Brian, Reconsidering... If the current line number starts at zero and is incremented only by CR/LF then my example program is wrong.? It called getLineNumber *after* reading the line and it should have called it *before*. So I can support your original patch (modulo not using AtomicBoolean). (Though my suggestion about doing all the work of keeping track of the line number in BufferedReader is still a valid though separate suggestion). Roger On 9/9/19 5:02 PM, Brian Burkhalter wrote: > If we wanted to go the route of changing the spec to match the behavior, the additional verbiage below is one possibility. > > Thanks, > > Brian > > +++ b/src/java.base/share/classes/java/io/LineNumberReader.java > @@ -35,19 +35,20 @@ > *

By default, line numbering begins at 0. This number increments at every > * line terminator as the data is read, and can be changed > * with a call to {@code setLineNumber(int)}. Note however, that > * {@code setLineNumber(int)} does not actually change the current position in > * the stream; it only changes the value that will be returned by > * {@code getLineNumber()}. > * > *

A line is considered to be terminated by any one of a > * line feed ('\n'), a carriage return ('\r'), or a carriage return followed > - * immediately by a linefeed. > + * immediately by a linefeed. For {@link #readLine()} only, the end of the > + * stream is also considered to be a line terminator. > > > public class LineNumberReader extends BufferedReader { > > /** The current line number */ > private int lineNumber = 0; > @@ -183,19 +184,21 @@ > } > } > > return n; > } > } > > /** > * Read a line of text. Whenever a line terminator is > - * read the current line number is incremented. > + * read the current line number is incremented. Unlike for the other > + * {@code read} methods of this class, reaching the end of the stream > + * will also increment the current line number. > * > * @return A String containing the contents of the line, not including > * any line termination characters, or > * {@code null} if the end of the stream has been reached > * > * @throws IOException > * If an I/O error occurs > */ > public String readLine() throws IOException { > >> On Sep 9, 2019, at 12:02 PM, Brian Burkhalter wrote: >> >>> On Sep 9, 2019, at 7:35 AM, Roger Riggs > wrote: >>> >>> I would lean toward updating the spec to reflect the current implementation. >> It seems strange however that if one read an entire stream using read() in one case and readLine() in another that the results would differ. From brian.burkhalter at oracle.com Tue Sep 10 14:40:15 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 10 Sep 2019 07:40:15 -0700 Subject: 8230342: LineNumberReader.getLineNumber() returns inconsistent results after EOF In-Reply-To: References: <553C9BEC-AC7D-4263-B785-E3C703D09819@oracle.com> <96566b30-af50-b264-abf2-6067d07e17e2@oracle.com> <3D17F646-6BDD-4F22-B17B-AE04F09EA763@oracle.com> Message-ID: Hi Roger, > On Sep 10, 2019, at 7:33 AM, Roger Riggs wrote: > > Reconsidering... > > If the current line number starts at zero and is incremented only by CR/LF > then my example program is wrong. It called getLineNumber *after* reading > the line and it should have called it *before*. After the previous exchange I actually wondered about that and tested it. > So I can support your original patch (modulo not using AtomicBoolean). I?ll change that. > (Though my suggestion about doing all the work of keeping track of the line number in BufferedReader > is still a valid though separate suggestion). I?ll look into this before reposting anything. Thanks, Brian From goetz.lindenmaier at sap.com Tue Sep 10 14:44:51 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 10 Sep 2019 14:44:51 +0000 Subject: RFR (L, final): 8218626: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: Message-ID: Hi, the subject should mention 8218628. (Not 8218626). Sorry for this! Best regards, Goetz. From: Lindenmaier, Goetz Sent: Dienstag, 10. September 2019 11:48 To: 'Hotspot dev runtime' ; Java Core Libs Subject: RFR (L, final): 8218626: Add detailed message to NullPointerException describing what is null. Hi, this is the implementation of JEP 358: Helpful NullPointerExceptions. The JEP is in status "Candidate". Coleen (many, many thanks!) ran it through the Oracle-internal processes. Now I please need final reviews for this change so that I can propose it to target jdk 14. JEP: https://bugs.openjdk.java.net/browse/JDK-8220715 Enhancement: https://bugs.openjdk.java.net/browse/JDK-8218628 webrev: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/16/ The change ran through a lot of testing, all jtreg and jck tests to name only some. The webrev points to patch http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/16/enable_NPE_message.patch that enables the change by default, which was useful for testing to assure the code is used in the tests. I just pushed the change to jdk/submit once more. Please review. Thanks! Goetz. From daniel.fuchs at oracle.com Tue Sep 10 14:57:44 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 10 Sep 2019 15:57:44 +0100 Subject: 8230342: LineNumberReader.getLineNumber() returns inconsistent results after EOF In-Reply-To: <96566b30-af50-b264-abf2-6067d07e17e2@oracle.com> References: <553C9BEC-AC7D-4263-B785-E3C703D09819@oracle.com> <96566b30-af50-b264-abf2-6067d07e17e2@oracle.com> Message-ID: Hi, On 09/09/2019 15:35, Roger Riggs wrote: > - Is the use of AtomicBoolean due to concurrency concerns? > ? If not, a new boolean[1] would be less overhead Alternatively, BufferedReader could define an empty package method called e.g. void endOfLine() { }; that LineNumberReader could override to increment lineNumber. So: 351 if (term != null) term.set(true); would simply become 351 endOfLine(); which would be a no-op for BufferedReader but would increment lineNumber for LineNumberReader. Wouldn't that work too? best regards -- daniel From martinrb at google.com Tue Sep 10 15:21:49 2019 From: martinrb at google.com (Martin Buchholz) Date: Tue, 10 Sep 2019 08:21:49 -0700 Subject: RFR [14] 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect In-Reply-To: <564053B0-6FC9-468A-B75D-94F796015BB6@oracle.com> References: <97114AA9-A44A-4C36-843C-1E6933348096@oracle.com> <026e37eb-3da6-5f39-ac8d-99ad26bba3d0@oracle.com> <81060A81-D77F-4F49-A131-DE79F66FE29B@oracle.com> <6db710f3-dff6-f6ea-5922-242516769ed8@oracle.com> <1A766DB0-E937-438A-BDE1-26DC29FC25EC@oracle.com> <0911E28D-E382-4A0E-A7DB-F775C522BFB4@oracle.com> <564053B0-6FC9-468A-B75D-94F796015BB6@oracle.com> Message-ID: On Tue, Sep 10, 2019 at 7:25 AM Pavel Rappo wrote: > > On 6 Sep 2019, at 20:02, Martin Buchholz wrote: > > > > Martin's rules for test methods: > > - never have more than 100 millisecond total expected runtime > > - never have more than 12 millisecond blocking time for any single > operation > > - yet be able to survive a one-time 5 second thread suspension at any > time > > No doubt these are reputable numbers however magic they seem. I expect > these make sense in a highly focused code, which j.u.c might be an example > of. LDAP, on the other hand, does everything but the kitchen sink. So much > so that I cannot guarantee any of those metrics to hold. > > The latter one is of particular interest to me. Could you maybe elaborate > on what "a rare 5-second thread suspension" is? (Not that it will make me > change the code, but out of pure curiosity.) > Suppose you are waiting for some other thread to complete some trivial observable operation, like counting down a latch. At some point you want to time out and report failure. How long before spurious failures disappear entirely? We used to use 250ms and see rare failures - too small! After switching to 10 seconds (scaled by timeout factor) spurious failures due to thread suspension have disappeared in practice. The longest thread suspension I ever actually observed was 4 seconds. Of course, no guarantees - higher priority processes can always hog the cpu. If you are waiting for a less trivial operation, you may need a higher value than our magic 10 seconds. An alternative is to wait "forever" and rely on jtreg's own timeout handler to kick in and fail the test for you. public void await(Semaphore semaphore) { boolean timedOut = false; try { timedOut = !semaphore.tryAcquire(LONG_DELAY_MS, MILLISECONDS); } catch (Throwable fail) { threadUnexpectedException(fail); } if (timedOut) fail("timed out waiting for Semaphore for " + (LONG_DELAY_MS/1000) + " sec"); } From martinrb at google.com Tue Sep 10 16:40:05 2019 From: martinrb at google.com (Martin Buchholz) Date: Tue, 10 Sep 2019 09:40:05 -0700 Subject: RFR [14] 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect In-Reply-To: References: <97114AA9-A44A-4C36-843C-1E6933348096@oracle.com> <026e37eb-3da6-5f39-ac8d-99ad26bba3d0@oracle.com> <81060A81-D77F-4F49-A131-DE79F66FE29B@oracle.com> <6db710f3-dff6-f6ea-5922-242516769ed8@oracle.com> <1A766DB0-E937-438A-BDE1-26DC29FC25EC@oracle.com> <0911E28D-E382-4A0E-A7DB-F775C522BFB4@oracle.com> <564053B0-6FC9-468A-B75D-94F796015BB6@oracle.com> Message-ID: Here's a canonical example of an "expected timeout" test that seems natural and readable to me. timeoutMillis() returns 12ms, adjusted by timeout factor. Ldap might need a bigger value. /** * timed await times out if not counted down before timeout */ public void testAwaitTimeout() throws InterruptedException { final CountDownLatch l = new CountDownLatch(1); Thread t = newStartedThread(new CheckedRunnable() { public void realRun() throws InterruptedException { assertEquals(1, l.getCount()); long startTime = System.nanoTime(); assertFalse(l.await(timeoutMillis(), MILLISECONDS)); assertTrue(millisElapsedSince(startTime) >= timeoutMillis()); assertEquals(1, l.getCount()); }}); awaitTermination(t); assertEquals(1, l.getCount()); } From milan.mimica at gmail.com Tue Sep 10 14:50:46 2019 From: milan.mimica at gmail.com (Milan Mimica) Date: Tue, 10 Sep 2019 16:50:46 +0200 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: <87ftl562pa.fsf@oldenburg2.str.redhat.com> References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> <87sgpblxns.fsf@oldenburg2.str.redhat.com> <87woemhe6z.fsf@oldenburg2.str.redhat.com> <87ftl562pa.fsf@oldenburg2.str.redhat.com> Message-ID: Hi Florian On Mon, 9 Sep 2019 at 15:04, Florian Weimer wrote: > > Ahh. The other option is to stick with one server and keep resending > with larger and larger timeouts. Switching has the advantage that in > case of a server problem, you get to a working server more quickly. > Staying means that if the answer is delayed and you resend exactly the > same query, you might still pick up the answer to the original query and > process it, after the first timeout. Furthermore, the behaviour is documented [1][2] and thus can't be just changed. > > But we know that the server is up because it responded our UDP, so > waiting more than one second for the TCP handshake to succeed might > worthwhile, yes. Heh, except the ticket we are trying to solve here is exactly about the TCP server not being up. So what do you suggest exactly? Should we set a lower cap? Something like: Math.max(timeout, 2000 /* or some other value?*/) The rationale is, if the client requests a initial timeout larger than 1 second (how much larger?) then we can use it as-is. For lower values (default included) we need to override it to some value that, at the end of the day, is platform-specific. Sorry, I just don't see how I can get this right without introducing a bunch of arbitrary constants to the code. [1] https://docs.oracle.com/javase/7/docs/technotes/guides/jndi/jndi-dns.html#TIMEOUT [2] https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4630910 -- Milan Mimica From milan.mimica at gmail.com Tue Sep 10 15:33:04 2019 From: milan.mimica at gmail.com (Milan Mimica) Date: Tue, 10 Sep 2019 17:33:04 +0200 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: <60FD933F-51A5-4438-83AF-B3427CFDE60D@oracle.com> References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> <87sgpblxns.fsf@oldenburg2.str.redhat.com> <7A46485C-E250-4E57-9FB0-B9D18CA70632@oracle.com> <60FD933F-51A5-4438-83AF-B3427CFDE60D@oracle.com> Message-ID: > > On 5 Sep 2019, at 16:02, Pavel Rappo wrote: > > > > I think we are almost there. What do you think of the following incremental (i.e. on top of your latest webrev) change? > > > > http://cr.openjdk.java.net/~prappo/8228580/webrev.01/ > > > > I fixed a couple of trivial typos and addressed the socket relinquishing issue. Initializing a socket is not an atomic "all-or-nothing" operation now. Someone needs to take care of the socket in case things go not as planned. Right. Thanks. Here is the merged version: http://cr.openjdk.java.net/~mmimica/8228580/webrev.02/ Plus, I have added TCP server init retry code from Chris. Works fine without changes to TestBase. -- Milan Mimica From james.laskey at oracle.com Tue Sep 10 18:04:55 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 10 Sep 2019 15:04:55 -0300 Subject: RFR: Request for sponsor : 8230436: String.stripIndent() javadoc unclear about LF/CR at end of string In-Reply-To: References: Message-ID: Andrew, I'll take it on, but it will have to go through a CSR review and thus will take some time. https://bugs.openjdk.java.net/browse/JDK-8230800 Cheers, -- Jim > On Sep 6, 2019, at 5:55 AM, Andrew Leonard wrote: > > Hi, > Anyone able to review please? > Thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > > > > From: Andrew Leonard/UK/IBM > To: core-libs-dev at openjdk.java.net > Cc: james.laskey at oracle.com > Date: 02/09/2019 17:10 > Subject: RFR: Request for sponsor : 8230436: String.stripIndent() javadoc unclear about LF/CR at end of string > > > Hi, > Can I get people's views and sponsor on a small update to the javadoc for String.stripIndent() to make the \n end of block special case more clear please? > I've done a proposed patch here: http://cr.openjdk.java.net/~aleonard/8230436/webrev.00/ > Thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > 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 Sergey.Bylokhov at oracle.com Tue Sep 10 18:45:55 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 10 Sep 2019 11:45:55 -0700 Subject: JDK 14 RFR of JDK-8202385: Annotation to mark serial-related fields and methods In-Reply-To: References: Message-ID: <77016bee-06dd-d7a4-9c81-802253edf2e9@oracle.com> Hi, Joe. Can we as part of this effort improve validation of javadocs tags: @serial, @serialField, etc. I am sure that we use these tags here and there incorrectly. BTW probably we should consider all serialized fields/methods/etc, as kind of public API, and validates it by doclint accordingly. On 7/9/19 4:14 pm, Joe Darcy wrote: > Hello, > > Returning to some old work [1], please review the addition of a java.io.Serial annotation type for JDK 14 to mark serial-related fields and methods: > > ??? webrev: http://cr.openjdk.java.net/~darcy/8202385.3/ > ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8217698 > > Thanks, > > -Joe > > [1] Previous review threads: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053055.html > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054801.html > -- Best regards, Sergey. From brian.burkhalter at oracle.com Tue Sep 10 18:46:50 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 10 Sep 2019 11:46:50 -0700 Subject: 8230342: LineNumberReader.getLineNumber() returns inconsistent results after EOF In-Reply-To: References: <553C9BEC-AC7D-4263-B785-E3C703D09819@oracle.com> <96566b30-af50-b264-abf2-6067d07e17e2@oracle.com> Message-ID: <0EC8B223-271E-45E3-9DE2-7A2CA8F93BBD@oracle.com> Hi Daniel, Thanks for the idea. It seems a little strange to me though to have the incrementing being done in a separate method. It feels a little disconnected. I wrote up an alternative [1] which instead passes a functional interface to the readLine() in BufferedReader. This eliminates creating an AtomicBoolean and avoids using a boolean[] parameter like a pseudo-pointer. Thanks, Brian [1] http://cr.openjdk.java.net/~bpb/8230342/webrev.01/ > On Sep 10, 2019, at 7:57 AM, Daniel Fuchs wrote: > > On 09/09/2019 15:35, Roger Riggs wrote: >> - Is the use of AtomicBoolean due to concurrency concerns? >> If not, a new boolean[1] would be less overhead > > Alternatively, BufferedReader could define an empty package > method called e.g. > > void endOfLine() { }; > > that LineNumberReader could override to increment lineNumber. > > So: > > 351 if (term != null) term.set(true); > > would simply become > > 351 endOfLine(); > > which would be a no-op for BufferedReader but would increment > lineNumber for LineNumberReader. > > Wouldn't that work too? From jonathan.gibbons at oracle.com Tue Sep 10 20:11:08 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 10 Sep 2019 13:11:08 -0700 Subject: JDK 14 RFR of JDK-8202385: Annotation to mark serial-related fields and methods In-Reply-To: <77016bee-06dd-d7a4-9c81-802253edf2e9@oracle.com> References: <77016bee-06dd-d7a4-9c81-802253edf2e9@oracle.com> Message-ID: Sergey, While it might be reasonable to improve doclint support with better checks for serialization, I think that is better done as a separate task, and not conflated with Joe's work here. -- Jon On 09/10/2019 11:45 AM, Sergey Bylokhov wrote: > Hi, Joe. > > Can we as part of this effort improve validation of javadocs tags: > @serial, @serialField, etc. > I am sure that we use these tags here and there incorrectly. > > BTW probably we should consider all serialized fields/methods/etc, as > kind > of public API, and validates it by doclint accordingly. > > On 7/9/19 4:14 pm, Joe Darcy wrote: >> Hello, >> >> Returning to some old work [1], please review the addition of a >> java.io.Serial annotation type for JDK 14 to mark serial-related >> fields and methods: >> >> ???? webrev: http://cr.openjdk.java.net/~darcy/8202385.3/ >> ???? CSR: https://bugs.openjdk.java.net/browse/JDK-8217698 >> >> Thanks, >> >> -Joe >> >> [1] Previous review threads: >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053055.html >> >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054801.html >> >> > > From naoto.sato at oracle.com Tue Sep 10 21:20:36 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 10 Sep 2019 14:20:36 -0700 Subject: [14] RFR: 8230136: DateTimeFormatterBuilder.FractionPrinterParser#parse fails to verify minWidth Message-ID: Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8230136 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8230136/webrev.00/ The fix is to correct the condition of the invalid case, as suggested in the bug report. Naoto From huizhe.wang at oracle.com Tue Sep 10 22:41:44 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 10 Sep 2019 15:41:44 -0700 Subject: [14] RFR: 8230136: DateTimeFormatterBuilder.FractionPrinterParser#parse fails to verify minWidth In-Reply-To: References: Message-ID: <7f1b1ca3-c9ba-8211-8884-3ca5c6719edb@oracle.com> +1, looks good to me. Best regards, Joe On 9/10/19 2:20 PM, naoto.sato at oracle.com wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8230136 > > The proposed changeset is located at: > > http://cr.openjdk.java.net/~naoto/8230136/webrev.00/ > > The fix is to correct the condition of the invalid case, as suggested > in the bug report. > > Naoto From ivan.gerasimov at oracle.com Wed Sep 11 04:13:37 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 10 Sep 2019 21:13:37 -0700 Subject: RFR 8230829 : Matcher matches a surrogate pair that crosses border of the region Message-ID: <5ab65db6-701a-937e-e93c-6ee4ef6fd159@oracle.com> Hello! When the regex.Matcher matches a supplementary codepoint, it may inadvertently cross the border of the explicitly specified region without noticing. Would you please help review a simple fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8230829 WEBREV: http://cr.openjdk.java.net/~igerasim/8230829/00/webrev/ Thanks in advance! -- With kind regards, Ivan Gerasimov From serguei.spitsyn at oracle.com Wed Sep 11 07:22:40 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 11 Sep 2019 00:22:40 -0700 Subject: RFR: 8212117 : Class.forName may return a reference to a loaded but not linked Class In-Reply-To: <5751ee27-2e15-ad38-0a6a-cf3ad4298ffc@oracle.com> References: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com> <6d1691eb-220c-ceaf-1302-be2d285f4968@oracle.com> <5751ee27-2e15-ad38-0a6a-cf3ad4298ffc@oracle.com> Message-ID: <798ab1c2-c099-2b19-e0fa-f2877f52d5cc@oracle.com> Hi Brent, The updated webrev looks good to me. At least, I do not see any issues. Thanks, Serguei On 9/5/19 17:09, Brent Christian wrote: > Hi, David > > On 9/5/19 12:52 AM, David Holmes wrote: >> >> Good to see this all come together :) > > :) > >> So to clarify for others any current caller to >> find_class_from_class_loader that passes true for "init" was already >> implicitly asking for a linked class (as you must be linked before >> you can be initialized). With that in mind I would suggest that in >> find_class_from_class_loader you add an assert: >> >> ! jclass find_class_from_class_loader(JNIEnv* env, Symbol* name, >> jboolean init, jboolean link, >> ?????????????????????????????????????? Handle loader, Handle >> protection_domain, >> ?????????????????????????????????????? jboolean throwError, TRAPS) { >> +assert((init && link) || !init, "incorrect use of init/link >> arguments"); >> >> just to ensure the callers understand this. > > I'm good with adding an assert to check for coherent arguments. > > (Another interpretation is that if 'init' is set, then the 'link' > argument is ignored, since linking is implied). > >> Aside: in looking at this I've spotted another existing bug. JNI >> FindClass is not specified to perform class initialization, but the >> implementation passes init=true! > > OK, thanks.? I've noted this in JDK-8226540. > >> src/java.base/share/classes/java/lang/invoke/MethodHandles.java >> >> I don't see the need for the new note given it already has >> >> * @throws LinkageError if the linkage fails > > (Discussed in the CSR) > >> src/java.base/share/classes/sun/launcher/LauncherHelper.java >> ... > Is AccessControlException the only exception, that is not a >> LinkageError, that might be thrown when linking? I would think a >> number of others are possible - in particular IllegalAccessError >> might occur during verification. Other than the fact a test obviously >> triggered this, it's not clear why ACE should be singled out here. ?? > > Also discussed in the CSR[1]. > >> test/hotspot/jtreg/serviceability/jvmti/ClassStatus/ClassStatus.java >> >> 45???? // public static void foo(Foo f) { } >> >> Unclear why this exists. Also the test refers initially to class Foo >> but then uses Foo2 and Foo3. ?? > > I'm guessing it's just a leftover from an earlier version of the test. > I've removed the comment, and updated the test @summary. > > Serguei, anything to add? > >>> There is also a CSR[2] in need of review. >> >> I've added a couple of comments and will add myself as a reviewer >> once things are near finalized. > > Thanks for taking a look. > > Updated webrev at: > http://cr.openjdk.java.net/~bchristi/8212117/webrev10/ > > -Brent > > 1. > https://bugs.openjdk.java.net/browse/JDK-8222071?focusedCommentId=14288303&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14288303 > >>> >>> The spec for the 2-arg and 3-arg Class.forName() methods states they >>> will "locate, load, and link" the class, however the linking part is >>> not ensured to happen. >>> >>> Although the VM spec allows flexibility WRT when classes are linked, >>> this is a corner where the Class.forName() spec is not being upheld. >>> While this is not an issue for most usages, 8181144 [3] demonstrates >>> how this can be a problem (with the debugging interface, in this case). >>> >>> This fix ensures that linking happens during the course of >>> Class.forName().? Class.forName() already @throws LinkageError, so >>> no spec change is needed there. MethodHandles.Lookup.findClass() >>> needs a small spec update, due to calling Class.forName with >>> init=false, >>> >>> Of course Errors are not required to be caught.? It is therefore >>> possible that the new behavior could introduce previously unseen, >>> possibly unhandled LinkageErrors.? A new VM flag >>> (-XX:+ClassForNameDeferLinking) is introduced to restore the >>> previous behavior (to keep such code running until it can be updated). >>> >>> This change surfaced a couple new "A JNI error has occurred" >>> situations (see 8181033[5]) in the Launcher, by way of >>> ?? test/jdk/tools/launcher/MainClassCantBeLoadedTest.java >>> (using the 3-arg Class::forName, detailed in the bug report[4]), >>> and >>> ?? test/jdk/tools/launcher/modules/basic/LauncherErrors.java >>> (using the 2-arg Class::forName). >>> >>> The Launcher is updated to maintain non-confusing error messages :). >>> >>> The new test included with this fix ensures that 8181144[3] is >>> addressed.? Thanks go to Serguei Spitsyn for writing the test. >>> >>> Automated corelibs and hotspot tests pass cleanly. >>> >>> Thanks, >>> -Brent >>> >>> -- >>> 1. https://bugs.openjdk.java.net/browse/JDK-8212117 >>> >>> 2. https://bugs.openjdk.java.net/browse/JDK-8222071 >>> >>> 3. https://bugs.openjdk.java.net/browse/JDK-8181144 >>> >>> 4. >>> https://bugs.openjdk.java.net/browse/JDK-8212117?focusedCommentId=14215986&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14215986 >>> >>> >>> 5. https://bugs.openjdk.java.net/browse/JDK-8181033 >>> From scolebourne at joda.org Wed Sep 11 09:01:54 2019 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 11 Sep 2019 10:01:54 +0100 Subject: [14] RFR: 8230136: DateTimeFormatterBuilder.FractionPrinterParser#parse fails to verify minWidth In-Reply-To: <7f1b1ca3-c9ba-8211-8884-3ca5c6719edb@oracle.com> References: <7f1b1ca3-c9ba-8211-8884-3ca5c6719edb@oracle.com> Message-ID: The bug references parseStrict() but the test does not. Is the builder already set to parseStrict() ? Anyway, if the bug is to be clearly squished, parseStrict() should appear somewhere. Stephen On Tue, 10 Sep 2019 at 23:42, Joe Wang wrote: > > +1, looks good to me. > > Best regards, > Joe > > On 9/10/19 2:20 PM, naoto.sato at oracle.com wrote: > > Hello, > > > > Please review the fix to the following issue: > > > > https://bugs.openjdk.java.net/browse/JDK-8230136 > > > > The proposed changeset is located at: > > > > http://cr.openjdk.java.net/~naoto/8230136/webrev.00/ > > > > The fix is to correct the condition of the invalid case, as suggested > > in the bug report. > > > > Naoto > From sean.coffey at oracle.com Wed Sep 11 10:50:00 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 11 Sep 2019 10:50:00 +0000 Subject: RFR: 8223490: Optimize search algorithm for determining default time zone Message-ID: The current algorithm for determining the default timezone on (non-AIX) unix systems goes something like : 1. If TZ environment variable is defined, use it 2. else if /etc/timezone exists, use the value contained within it 3. else if /etc/localtime exists and is a symbolic link, use the name pointed to 4. else if /etc/localtime is a binary, find the first identical time zone binary file in /usr/share/zoneinfo/ Step 4 is a bit crude in that the zoneinfo directory can contain over 1,800 files on today's systems. I'd like to change the logic so that common timezones are first checked for buffer matching before a full directory traversal is performed. It should be a performance gain and it should also lead to more consistent results for reasons outlined in the bug report. https://bugs.openjdk.java.net/browse/JDK-8223490 webrev: http://cr.openjdk.java.net/~coffeys/webrev.8223490/webrev/ -- Regards, Sean. From pavel.rappo at oracle.com Wed Sep 11 12:26:24 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 11 Sep 2019 13:26:24 +0100 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> <87sgpblxns.fsf@oldenburg2.str.redhat.com> <7A46485C-E250-4E57-9FB0-B9D18CA70632@oracle.com> <60FD933F-51A5-4438-83AF-B3427CFDE60D@oracle.com> Message-ID: <8A9E3066-E6F6-4E65-BD02-DF0ACFF02FAD@oracle.com> I'm happy with the overall changeset. I have (once again) made some tiny changes, you can see them here: http://cr.openjdk.java.net/~prappo/8228580/webrev.02/ If you are okay with them, then we wait for a *R*eviewer. If the Reviewer(s) are okay with them, we push. For the record, I'm not really happy with how we used the DNSTestBase/TestBase infrastructure, however I'm totally fine with the retrying logic. Test results are pending. -Pavel > On 10 Sep 2019, at 16:33, Milan Mimica wrote: > >>> On 5 Sep 2019, at 16:02, Pavel Rappo wrote: >>> >>> I think we are almost there. What do you think of the following incremental (i.e. on top of your latest webrev) change? >>> >>> http://cr.openjdk.java.net/~prappo/8228580/webrev.01/ >>> >>> I fixed a couple of trivial typos and addressed the socket relinquishing issue. Initializing a socket is not an atomic "all-or-nothing" operation now. Someone needs to take care of the socket in case things go not as planned. > > Right. Thanks. Here is the merged version: > http://cr.openjdk.java.net/~mmimica/8228580/webrev.02/ > Plus, I have added TCP server init retry code from Chris. Works fine > without changes to TestBase. > > > -- > Milan Mimica From naoto.sato at oracle.com Wed Sep 11 12:38:09 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 11 Sep 2019 05:38:09 -0700 Subject: [14] RFR: 8230136: DateTimeFormatterBuilder.FractionPrinterParser#parse fails to verify minWidth In-Reply-To: References: <7f1b1ca3-c9ba-8211-8884-3ca5c6719edb@oracle.com> Message-ID: <28db6b4f-3a0d-5d5f-366c-a59e1d51e2be@oracle.com> Hi Stephen, I confirmed that issuing parseStrict() was irrelevant. The incorrect text won't throw the exception in "lenient" mode as well. In addition, "builder" is always instantiated in AbstractTestPrinterParser on each TestNG invocation and "strict" is the default mode. Thus I did not explicitly issue parseStrict() in the test. BTW, I found typos wrt the default parse mode. Included the corrections in this webrev as well: http://cr.openjdk.java.net/~naoto/8230136/webrev.01/ Naoto On 9/11/19 2:01 AM, Stephen Colebourne wrote: > The bug references parseStrict() but the test does not. Is the builder > already set to parseStrict() ? Anyway, if the bug is to be clearly > squished, parseStrict() should appear somewhere. > Stephen > > On Tue, 10 Sep 2019 at 23:42, Joe Wang wrote: >> >> +1, looks good to me. >> >> Best regards, >> Joe >> >> On 9/10/19 2:20 PM, naoto.sato at oracle.com wrote: >>> Hello, >>> >>> Please review the fix to the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8230136 >>> >>> The proposed changeset is located at: >>> >>> http://cr.openjdk.java.net/~naoto/8230136/webrev.00/ >>> >>> The fix is to correct the condition of the invalid case, as suggested >>> in the bug report. >>> >>> Naoto >> From scolebourne at joda.org Wed Sep 11 12:48:24 2019 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 11 Sep 2019 13:48:24 +0100 Subject: [14] RFR: 8230136: DateTimeFormatterBuilder.FractionPrinterParser#parse fails to verify minWidth In-Reply-To: <28db6b4f-3a0d-5d5f-366c-a59e1d51e2be@oracle.com> References: <7f1b1ca3-c9ba-8211-8884-3ca5c6719edb@oracle.com> <28db6b4f-3a0d-5d5f-366c-a59e1d51e2be@oracle.com> Message-ID: +1 On Wed, 11 Sep 2019 at 13:38, wrote: > > Hi Stephen, > > I confirmed that issuing parseStrict() was irrelevant. The incorrect > text won't throw the exception in "lenient" mode as well. In addition, > "builder" is always instantiated in AbstractTestPrinterParser on each > TestNG invocation and "strict" is the default mode. Thus I did not > explicitly issue parseStrict() in the test. > > BTW, I found typos wrt the default parse mode. Included the corrections > in this webrev as well: > > http://cr.openjdk.java.net/~naoto/8230136/webrev.01/ > > Naoto > > On 9/11/19 2:01 AM, Stephen Colebourne wrote: > > The bug references parseStrict() but the test does not. Is the builder > > already set to parseStrict() ? Anyway, if the bug is to be clearly > > squished, parseStrict() should appear somewhere. > > Stephen > > > > On Tue, 10 Sep 2019 at 23:42, Joe Wang wrote: > >> > >> +1, looks good to me. > >> > >> Best regards, > >> Joe > >> > >> On 9/10/19 2:20 PM, naoto.sato at oracle.com wrote: > >>> Hello, > >>> > >>> Please review the fix to the following issue: > >>> > >>> https://bugs.openjdk.java.net/browse/JDK-8230136 > >>> > >>> The proposed changeset is located at: > >>> > >>> http://cr.openjdk.java.net/~naoto/8230136/webrev.00/ > >>> > >>> The fix is to correct the condition of the invalid case, as suggested > >>> in the bug report. > >>> > >>> Naoto > >> From milan.mimica at gmail.com Wed Sep 11 13:01:13 2019 From: milan.mimica at gmail.com (Milan Mimica) Date: Wed, 11 Sep 2019 15:01:13 +0200 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: <8A9E3066-E6F6-4E65-BD02-DF0ACFF02FAD@oracle.com> References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> <87sgpblxns.fsf@oldenburg2.str.redhat.com> <7A46485C-E250-4E57-9FB0-B9D18CA70632@oracle.com> <60FD933F-51A5-4438-83AF-B3427CFDE60D@oracle.com> <8A9E3066-E6F6-4E65-BD02-DF0ACFF02FAD@oracle.com> Message-ID: Hi Pavel Your changes look good to me. On Wed, 11 Sep 2019 at 14:26, Pavel Rappo wrote: > > I'm happy with the overall changeset. I have (once again) made some tiny changes, you can see them here: > > http://cr.openjdk.java.net/~prappo/8228580/webrev.02/ > > If you are okay with them, then we wait for a *R*eviewer. If the Reviewer(s) are okay with them, we push. For the record, I'm not really happy with how we used the DNSTestBase/TestBase infrastructure, however I'm totally fine with the retrying logic. > > Test results are pending. > > -Pavel > > > On 10 Sep 2019, at 16:33, Milan Mimica wrote: > > > >>> On 5 Sep 2019, at 16:02, Pavel Rappo wrote: > >>> > >>> I think we are almost there. What do you think of the following incremental (i.e. on top of your latest webrev) change? > >>> > >>> http://cr.openjdk.java.net/~prappo/8228580/webrev.01/ > >>> > >>> I fixed a couple of trivial typos and addressed the socket relinquishing issue. Initializing a socket is not an atomic "all-or-nothing" operation now. Someone needs to take care of the socket in case things go not as planned. > > > > Right. Thanks. Here is the merged version: > > http://cr.openjdk.java.net/~mmimica/8228580/webrev.02/ > > Plus, I have added TCP server init retry code from Chris. Works fine > > without changes to TestBase. > > > > > > -- > > Milan Mimica > -- Milan Mimica From Alan.Bateman at oracle.com Wed Sep 11 13:58:17 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 11 Sep 2019 14:58:17 +0100 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: <8A9E3066-E6F6-4E65-BD02-DF0ACFF02FAD@oracle.com> References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> <87sgpblxns.fsf@oldenburg2.str.redhat.com> <7A46485C-E250-4E57-9FB0-B9D18CA70632@oracle.com> <60FD933F-51A5-4438-83AF-B3427CFDE60D@oracle.com> <8A9E3066-E6F6-4E65-BD02-DF0ACFF02FAD@oracle.com> Message-ID: On 11/09/2019 13:26, Pavel Rappo wrote: > I'm happy with the overall changeset. I have (once again) made some tiny changes, you can see them here: > > http://cr.openjdk.java.net/~prappo/8228580/webrev.02/ > > If you are okay with them, then we wait for a *R*eviewer. If the Reviewer(s) are okay with them, we push. For the record, I'm not really happy with how we used the DNSTestBase/TestBase infrastructure, however I'm totally fine with the retrying logic. > Would it be possible to write a clear description for the com.sun.jndi.dns.timeout and com.sun.jndi.dns.retries properties? The current description in the JNDI docs describes them for UDP only. I realize this is may be out of date but new descriptions would be useful when the docs are updated. Also I think would be useful for potential Reviewers. -Alan From Roger.Riggs at oracle.com Wed Sep 11 14:05:01 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 11 Sep 2019 10:05:01 -0400 Subject: [14] RFR: 8230136: DateTimeFormatterBuilder.FractionPrinterParser#parse fails to verify minWidth In-Reply-To: References: <7f1b1ca3-c9ba-8211-8884-3ca5c6719edb@oracle.com> <28db6b4f-3a0d-5d5f-366c-a59e1d51e2be@oracle.com> Message-ID: +1 On 9/11/19 8:48 AM, Stephen Colebourne wrote: > +1 > > On Wed, 11 Sep 2019 at 13:38, wrote: >> Hi Stephen, >> >> I confirmed that issuing parseStrict() was irrelevant. The incorrect >> text won't throw the exception in "lenient" mode as well. In addition, >> "builder" is always instantiated in AbstractTestPrinterParser on each >> TestNG invocation and "strict" is the default mode. Thus I did not >> explicitly issue parseStrict() in the test. >> >> BTW, I found typos wrt the default parse mode. Included the corrections >> in this webrev as well: >> >> http://cr.openjdk.java.net/~naoto/8230136/webrev.01/ >> >> Naoto >> >> On 9/11/19 2:01 AM, Stephen Colebourne wrote: >>> The bug references parseStrict() but the test does not. Is the builder >>> already set to parseStrict() ? Anyway, if the bug is to be clearly >>> squished, parseStrict() should appear somewhere. >>> Stephen >>> >>> On Tue, 10 Sep 2019 at 23:42, Joe Wang wrote: >>>> +1, looks good to me. >>>> >>>> Best regards, >>>> Joe >>>> >>>> On 9/10/19 2:20 PM, naoto.sato at oracle.com wrote: >>>>> Hello, >>>>> >>>>> Please review the fix to the following issue: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8230136 >>>>> >>>>> The proposed changeset is located at: >>>>> >>>>> http://cr.openjdk.java.net/~naoto/8230136/webrev.00/ >>>>> >>>>> The fix is to correct the condition of the invalid case, as suggested >>>>> in the bug report. >>>>> >>>>> Naoto From Alan.Bateman at oracle.com Wed Sep 11 14:46:01 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 11 Sep 2019 15:46:01 +0100 Subject: RFR: jsr166 integration 2019-09 In-Reply-To: References: Message-ID: <56743e2f-6735-289a-0e34-5442e5580d16@oracle.com> On 09/09/2019 16:06, Martin Buchholz wrote: > : > > Another round of stress testing at Google allowed us to fix a handful of > very rare test failures. > > 8227235: rare failures in testForkHelpQuiesce tck tests > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/ForkJoin-quiesce/index.html > https://bugs.openjdk.java.net/browse/JDK-8227235 > > 8221168: java/util/concurrent/CountDownLatch/Basic.java fails > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/CountDownLatch-Basic/index.html > https://bugs.openjdk.java.net/browse/JDK-8221168 > > 8145138: CyclicBarrier/Basic.java failed with "3 not equal to 4" > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/CyclicBarrier-Basic/index.html > https://bugs.openjdk.java.net/browse/JDK-8145138 > > 8225490: Miscellaneous changes imported from jsr166 CVS 2019-09 > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/miscellaneous/index.html > https://bugs.openjdk.java.net/browse/JDK-8225490 I read through the test updates and other misc. changes and don't see anything obviously wrong (the discussion in JIRA on the test failures was useful). At some point I could imagine Joe suggesting add "@key randomness" to more of these tests. -Alan. From pavel.rappo at oracle.com Wed Sep 11 14:56:47 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 11 Sep 2019 15:56:47 +0100 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> <87sgpblxns.fsf@oldenburg2.str.redhat.com> <7A46485C-E250-4E57-9FB0-B9D18CA70632@oracle.com> <60FD933F-51A5-4438-83AF-B3427CFDE60D@oracle.com> <8A9E3066-E6F6-4E65-BD02-DF0ACFF02FAD@oracle.com> Message-ID: <633A0CE3-C771-493B-89E3-7FA843C85183@oracle.com> Sure, from https://docs.oracle.com/javase/8/docs/technotes/guides/jndi/jndi-dns.html: "Each lookup is initially performed using UDP. If the response is too long to be returned in a UDP packet without being truncated, the lookup is repeated using TCP." and "com.example.jndi.dns.timeout.initial com.example.jndi.dns.timeout.retries These properties are used to alter the timeout-related defaults that the DNS provider uses when submitting UDP queries. The DNS provider submits UDP queries using the following exponential backoff algorithm. The provider submits a query to a DNS server and waits for a response to arrive within a timeout period (1 second by default). If it receives no response within the timeout period, it queries the next server, and so on. If the provider receives no response from any server, it doubles the timeout period and repeats the process of submitting the query to each server, up to a maximum number of retries (4 by default). The "com.example.jndi.dns.timeout.initial" property, if set, specifies the number of milliseconds to use as the initial timeout period (i.e., before any doubling). If this property has not been set, the default initial timeout is 1000 milliseconds. The "com.example.jndi.dns.timeout.retries" property, if set, specifies the number of times to retry each server using the exponential backoff algorithm described previously. If this property has not been set, the default number of retries is 4." I cannot seem to find a newer version of that document though. > On 11 Sep 2019, at 14:58, Alan Bateman wrote: > > On 11/09/2019 13:26, Pavel Rappo wrote: >> I'm happy with the overall changeset. I have (once again) made some tiny changes, you can see them here: >> >> http://cr.openjdk.java.net/~prappo/8228580/webrev.02/ >> >> If you are okay with them, then we wait for a *R*eviewer. If the Reviewer(s) are okay with them, we push. For the record, I'm not really happy with how we used the DNSTestBase/TestBase infrastructure, however I'm totally fine with the retrying logic. >> > Would it be possible to write a clear description for the com.sun.jndi.dns.timeout and com.sun.jndi.dns.retries properties? The current description in the JNDI docs describes them for UDP only. I realize this is may be out of date but new descriptions would be useful when the docs are updated. Also I think would be useful for potential Reviewers. > > -Alan From alexey.semenyuk at oracle.com Wed Sep 11 15:05:37 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Wed, 11 Sep 2019 11:05:37 -0400 Subject: Feedback JEP 343: Packaging Tool In-Reply-To: <9baf915a4b95c49fb519f09929441f6a@apis.de> References: <9baf915a4b95c49fb519f09929441f6a@apis.de> Message-ID: Hi Heiko, Thank you for giving a try to jpackage and for your feedback! Please find comments inlined. On 9/10/2019 4:55 AM, Heiko Wagner wrote: > I am sending this feedback as suggested by the jpackage project > (https://jdk.java.net/jpackage/). I hope this is considered helpful > information. > > I have tried the current build "14-jpackage+1-35" on Windows. It pretty > much worked out of the box for me. Here are a few observations I make: > > - creating a image of the application is great for building protable > applications. Sometime it is realy great to have the application on a > thumb drive an just run it on any machine; currently i do this manually > via jlink and use launch4j as a native launcher > > - MSI installation packages are great when deploying a application into > a controlled it infrastructure, but in turn impose some restictions e.g. > on application updates Correct. That is why jpackage supports creation of an application image not bundled in MSI on Windows to give maximum flexibility. > - my application is currently a portable app and does not use any native > installer like MSI. Automatic updates are handled by the application by > just in place updating the jar files. Deploying the application as a MSI > would require to change the update behaviour. Even if automatic updates > are out of the scope of the current JEP it would be helpful to have a > common solution for this in the long run > > - Currently my app has a splash screen, since launch4j has support for a > native splash screen. I have no tried it on jpackage, but the JEP states > that there is no support for native splash screen. That is correct, jpackage is not offering native splash screen support. > Does this also mean that the functionality of "-splash: fileName" and > its manifest file counter part will not work when using the launcher > generated jpackage? Right now it is not working as far as I can say from running the simple test. This looks like a bug in app launcher generated by jpackage. I've filed https://bugs.openjdk.java.net/browse/JDK-8230862 to track this. > > - Wher creating a image on Windows pretty much all .DLL from the bin > folder in the runtime are duplicated into the application folder. Is > this intended? App launcher is linked dynamically with MS run-time libs so we have MS run-time dlls in the folder next to the launcher. There is no bold reason to keep it this way, we can link app launcher statically with MS run-time and get rid of all these dlls. Created https://bugs.openjdk.java.net/browse/JDK-8230863 to track this. - Alexey > When using the generic java.exe launcher it is not > required to this. It just works fine with all .DLL/.EXE files in the > runtime bin folder > > Thanks for making such a great tool. Keep up the good work. > > Regards, > > Heiko From Alan.Bateman at oracle.com Wed Sep 11 15:10:08 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 11 Sep 2019 16:10:08 +0100 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: <633A0CE3-C771-493B-89E3-7FA843C85183@oracle.com> References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> <87sgpblxns.fsf@oldenburg2.str.redhat.com> <7A46485C-E250-4E57-9FB0-B9D18CA70632@oracle.com> <60FD933F-51A5-4438-83AF-B3427CFDE60D@oracle.com> <8A9E3066-E6F6-4E65-BD02-DF0ACFF02FAD@oracle.com> <633A0CE3-C771-493B-89E3-7FA843C85183@oracle.com> Message-ID: <6b209e36-686f-7852-7fb8-3a0ef0e8423a@oracle.com> On 11/09/2019 15:56, Pavel Rappo wrote: > Sure, from https://docs.oracle.com/javase/8/docs/technotes/guides/jndi/jndi-dns.html: > > "Each lookup is initially performed using UDP. If the response is too long to be returned in a UDP packet without being truncated, the lookup is repeated using TCP." > > and > > "com.example.jndi.dns.timeout.initial > com.example.jndi.dns.timeout.retries > > These properties are used to alter the timeout-related defaults that the DNS provider uses when submitting UDP queries. The DNS provider submits UDP queries using the following exponential backoff algorithm. The provider submits a query to a DNS server and waits for a response to arrive within a timeout period (1 second by default). If it receives no response within the timeout period, it queries the next server, and so on. If the provider receives no response from any server, it doubles the timeout period and repeats the process of submitting the query to each server, up to a maximum number of retries (4 by default). > > The "com.example.jndi.dns.timeout.initial" property, if set, specifies the number of milliseconds to use as the initial timeout period (i.e., before any doubling). If this property has not been set, the default initial timeout is 1000 milliseconds. > > The "com.example.jndi.dns.timeout.retries" property, if set, specifies the number of times to retry each server using the exponential backoff algorithm described previously. If this property has not been set, the default number of retries is 4." > > I cannot seem to find a newer version of that document though. > I assume extending the timeout to TCP will require at least some minimal updates to the descriptions. That will help reviewers and help decide if a CSR is needed or not. Ideally the authoritative descriptions of these properties would be in the javadoc, probably in the jdk.naming.dns module description. -Alan From pavel.rappo at oracle.com Wed Sep 11 15:16:38 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 11 Sep 2019 16:16:38 +0100 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: <6b209e36-686f-7852-7fb8-3a0ef0e8423a@oracle.com> References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> <87sgpblxns.fsf@oldenburg2.str.redhat.com> <7A46485C-E250-4E57-9FB0-B9D18CA70632@oracle.com> <60FD933F-51A5-4438-83AF-B3427CFDE60D@oracle.com> <8A9E3066-E6F6-4E65-BD02-DF0ACFF02FAD@oracle.com> <633A0CE3-C771-493B-89E3-7FA843C85183@oracle.com> <6b209e36-686f-7852-7fb8-3a0ef0e8423a@oracle.com> Message-ID: > On 11 Sep 2019, at 16:10, Alan Bateman wrote: > > I assume extending the timeout to TCP will require at least some minimal updates to the descriptions. Which descriptions do you have in mind? I cannot seem to find that text anywhere in the current repo (jdk/jdk) $ hg tip changeset: 56237:cddef3bde924 tag: tip user: lkorinth date: Wed Sep 11 14:16:30 2019 +0200 summary: 8230398: Remove NULL checks before FREE_C_HEAP_ARRAY. From Alan.Bateman at oracle.com Wed Sep 11 15:55:56 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 11 Sep 2019 16:55:56 +0100 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> <87sgpblxns.fsf@oldenburg2.str.redhat.com> <7A46485C-E250-4E57-9FB0-B9D18CA70632@oracle.com> <60FD933F-51A5-4438-83AF-B3427CFDE60D@oracle.com> <8A9E3066-E6F6-4E65-BD02-DF0ACFF02FAD@oracle.com> <633A0CE3-C771-493B-89E3-7FA843C85183@oracle.com> <6b209e36-686f-7852-7fb8-3a0ef0e8423a@oracle.com> Message-ID: On 11/09/2019 16:16, Pavel Rappo wrote: > >> On 11 Sep 2019, at 16:10, Alan Bateman wrote: >> >> I assume extending the timeout to TCP will require at least some minimal updates to the descriptions. > Which descriptions do you have in mind? I cannot seem to find that text anywhere in the current repo (jdk/jdk) I don't think the jndi-dns docs page is in the jdk repo. Since JDK 9, a good place for service providers to document capability and configuration is their module description and I think at least some of the documentation from that page should move into the jdk.naming.dns module description (that's for another issue of course). However, for the changes under discussion here then I don't think it's unreasonable to provide an updated description of the timeout property. -Alan From andrew_m_leonard at uk.ibm.com Wed Sep 11 15:56:47 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Wed, 11 Sep 2019 16:56:47 +0100 Subject: RFR: Request for sponsor : 8230436: String.stripIndent() javadoc unclear about LF/CR at end of string In-Reply-To: References: Message-ID: Thanks Jim, no worries time wise. Cheers Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Jim Laskey To: Andrew Leonard Cc: core-libs-dev at openjdk.java.net Date: 10/09/2019 19:05 Subject: Re: RFR: Request for sponsor : 8230436: String.stripIndent() javadoc unclear about LF/CR at end of string Andrew, I'll take it on, but it will have to go through a CSR review and thus will take some time. https://bugs.openjdk.java.net/browse/JDK-8230800 Cheers, -- Jim On Sep 6, 2019, at 5:55 AM, Andrew Leonard wrote: Hi, Anyone able to review please? Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Andrew Leonard/UK/IBM To: core-libs-dev at openjdk.java.net Cc: james.laskey at oracle.com Date: 02/09/2019 17:10 Subject: RFR: Request for sponsor : 8230436: String.stripIndent() javadoc unclear about LF/CR at end of string Hi, Can I get people's views and sponsor on a small update to the javadoc for String.stripIndent() to make the \n end of block special case more clear please? I've done a proposed patch here: http://cr.openjdk.java.net/~aleonard/8230436/webrev.00/ Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU 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 pavel.rappo at oracle.com Wed Sep 11 16:25:24 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 11 Sep 2019 17:25:24 +0100 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> <87sgpblxns.fsf@oldenburg2.str.redhat.com> <7A46485C-E250-4E57-9FB0-B9D18CA70632@oracle.com> <60FD933F-51A5-4438-83AF-B3427CFDE60D@oracle.com> <8A9E3066-E6F6-4E65-BD02-DF0ACFF02FAD@oracle.com> <633A0CE3-C771-493B-89E3-7FA843C85183@oracle.com> <6b209e36-686f-7852-7fb8-3a0ef0e8423a@oracle.com> Message-ID: <74E26830-C31C-45F3-8F9E-519C24C76CBD@oracle.com> > On 11 Sep 2019, at 16:55, Alan Bateman wrote: > > I don't think the jndi-dns docs page is in the jdk repo. Could you kindly point me to the location of the current jndi-dns docs page? I can't seem to be able to even find anything related to that on the web. You might want to try to use your favorite search engine. > > > However, for the changes under discussion here then I don't think it's unreasonable to provide an updated description of the timeout property. It might be reasonable. What wording would you suggest? To me it already *vaguely* addresses the TCP case by saying that "Each lookup is initially performed using UDP. If the response is too long to be returned in a UDP packet without being truncated, the lookup is repeated using TCP." -Pavel From brian.burkhalter at oracle.com Wed Sep 11 16:58:04 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 11 Sep 2019 09:58:04 -0700 Subject: 8230342: LineNumberReader.getLineNumber() returns inconsistent results after EOF In-Reply-To: <0EC8B223-271E-45E3-9DE2-7A2CA8F93BBD@oracle.com> References: <553C9BEC-AC7D-4263-B785-E3C703D09819@oracle.com> <96566b30-af50-b264-abf2-6067d07e17e2@oracle.com> <0EC8B223-271E-45E3-9DE2-7A2CA8F93BBD@oracle.com> Message-ID: <373A2168-F7D3-4A05-ABDC-1610C58BD523@oracle.com> Although I rather like [1] it is probably too expensive to use a lambda just to increment the line number. Therefore I am proposing to modify [2] to replace the AtomicBoolean with a boolean[] as in [3]. Thanks, Brian [1] http://cr.openjdk.java.net/~bpb/8230342/webrev.01/ [2] http://cr.openjdk.java.net/~bpb/8230342/webrev.00/ [3] http://cr.openjdk.java.net/~bpb/8230342/webrev.02/ > On Sep 10, 2019, at 11:46 AM, Brian Burkhalter wrote: > > Hi Daniel, > > Thanks for the idea. It seems a little strange to me though to have the incrementing being done in a separate method. It feels a little disconnected. > > I wrote up an alternative [1] which instead passes a functional interface to the readLine() in BufferedReader. This eliminates creating an AtomicBoolean and avoids using a boolean[] parameter like a pseudo-pointer. > > Thanks, > > Brian > > [1] http://cr.openjdk.java.net/~bpb/8230342/webrev.01/ > >> On Sep 10, 2019, at 7:57 AM, Daniel Fuchs wrote: >> >> On 09/09/2019 15:35, Roger Riggs wrote: >>> - Is the use of AtomicBoolean due to concurrency concerns? >>> If not, a new boolean[1] would be less overhead >> >> Alternatively, BufferedReader could define an empty package >> method called e.g. >> >> void endOfLine() { }; >> >> that LineNumberReader could override to increment lineNumber. >> >> So: >> >> 351 if (term != null) term.set(true); >> >> would simply become >> >> 351 endOfLine(); >> >> which would be a no-op for BufferedReader but would increment >> lineNumber for LineNumberReader. >> >> Wouldn't that work too? > From Roger.Riggs at oracle.com Wed Sep 11 17:41:49 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 11 Sep 2019 13:41:49 -0400 Subject: 8230342: LineNumberReader.getLineNumber() returns inconsistent results after EOF In-Reply-To: <373A2168-F7D3-4A05-ABDC-1610C58BD523@oracle.com> References: <553C9BEC-AC7D-4263-B785-E3C703D09819@oracle.com> <96566b30-af50-b264-abf2-6067d07e17e2@oracle.com> <0EC8B223-271E-45E3-9DE2-7A2CA8F93BBD@oracle.com> <373A2168-F7D3-4A05-ABDC-1610C58BD523@oracle.com> Message-ID: <4cc2f5b8-17a0-a52a-61a7-93d7539884bc@oracle.com> Looks good. Thanks for the alternative investigations,? Roger On 9/11/19 12:58 PM, Brian Burkhalter wrote: > Although I rather like [1] it is probably too expensive to use a lambda just to increment the line number. Therefore I am proposing to modify [2] to replace the AtomicBoolean with a boolean[] as in [3]. > > Thanks, > > Brian > > [1] http://cr.openjdk.java.net/~bpb/8230342/webrev.01/ > [2] http://cr.openjdk.java.net/~bpb/8230342/webrev.00/ > [3] http://cr.openjdk.java.net/~bpb/8230342/webrev.02/ > >> On Sep 10, 2019, at 11:46 AM, Brian Burkhalter wrote: >> >> Hi Daniel, >> >> Thanks for the idea. It seems a little strange to me though to have the incrementing being done in a separate method. It feels a little disconnected. >> >> I wrote up an alternative [1] which instead passes a functional interface to the readLine() in BufferedReader. This eliminates creating an AtomicBoolean and avoids using a boolean[] parameter like a pseudo-pointer. >> >> Thanks, >> >> Brian >> >> [1] http://cr.openjdk.java.net/~bpb/8230342/webrev.01/ >> >>> On Sep 10, 2019, at 7:57 AM, Daniel Fuchs wrote: >>> >>> On 09/09/2019 15:35, Roger Riggs wrote: >>>> - Is the use of AtomicBoolean due to concurrency concerns? >>>> If not, a new boolean[1] would be less overhead >>> Alternatively, BufferedReader could define an empty package >>> method called e.g. >>> >>> void endOfLine() { }; >>> >>> that LineNumberReader could override to increment lineNumber. >>> >>> So: >>> >>> 351 if (term != null) term.set(true); >>> >>> would simply become >>> >>> 351 endOfLine(); >>> >>> which would be a no-op for BufferedReader but would increment >>> lineNumber for LineNumberReader. >>> >>> Wouldn't that work too? From pavel.rappo at oracle.com Wed Sep 11 18:02:50 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 11 Sep 2019 19:02:50 +0100 Subject: RFR [14] 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect In-Reply-To: References: <97114AA9-A44A-4C36-843C-1E6933348096@oracle.com> <026e37eb-3da6-5f39-ac8d-99ad26bba3d0@oracle.com> <81060A81-D77F-4F49-A131-DE79F66FE29B@oracle.com> <6db710f3-dff6-f6ea-5922-242516769ed8@oracle.com> <1A766DB0-E937-438A-BDE1-26DC29FC25EC@oracle.com> <0911E28D-E382-4A0E-A7DB-F775C522BFB4@oracle.com> <564053B0-6FC9-468A-B75D-94F796015BB6@oracle.com> Message-ID: Martin, > On 10 Sep 2019, at 17:40, Martin Buchholz wrote: > > Here's a canonical example of an "expected timeout" test that seems natural and readable to me. > timeoutMillis() returns 12ms, adjusted by timeout factor. Ldap might need a bigger value. > > > /** > * timed await times out if not counted down before timeout > */ > public void testAwaitTimeout() throws InterruptedException { > final CountDownLatch l = new CountDownLatch(1); > Thread t = newStartedThread(new CheckedRunnable() { > public void realRun() throws InterruptedException { > assertEquals(1, l.getCount()); > > long startTime = System.nanoTime(); > assertFalse(l.await(timeoutMillis(), MILLISECONDS)); > assertTrue(millisElapsedSince(startTime) >= timeoutMillis()); > > assertEquals(1, l.getCount()); > }}); > > awaitTermination(t); > assertEquals(1, l.getCount()); > } I agree that this example [1] looks readable (depending on a reader, of course). I think it looks readable mostly because it is very explicit. However, in a domain other than concurrency we are not usually concerned with this level of detail. In such cases I would prefer to have a small set of focused methods that would allow me to explain my intentions succinctly and only once, taking care of all the low-level details. As for the internal mechanics, I can see that this example [2]: a. is not using any synchronization aid to make sure both threads wait for each other (probably, the timeout value accommodates that) b. uses a number of tiny low-level methods like newStartedThread, awaitTermination, millisElapsedSince, manual time assertions, etc. c. has assertions spread across 2 threads (b) probably allows you to reuse components in places unrelated to timeouts. At the same time you don't seem to have any higher-level reusable component (i.e. my guess is that this code is more or less repeated in other places in that test suite, which is not necessarily a bad thing). However, I fully agree with you that this functionality should be a utility method of the test library. ------------------------- [1] I assume this is an excerpt from CountDownLatchTest.java. If so, then for the reader's convenience this method could be seen in its context at http://hg.openjdk.java.net/jdk/jdk/file/d52f77f0acb5/test/jdk/java/util/concurrent/tck/CountDownLatchTest.java#l198 [2] I'm not saying that those things are wrong or that I disagree with any of that. It's just an observation from reading this example. From andy.herrick at oracle.com Thu Sep 12 01:07:49 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 11 Sep 2019 21:07:49 -0400 Subject: RFR: JDK-8229779: Shortcut creation policy Message-ID: <583dc9b6-6b2b-a04b-f209-9ce2a851d007@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: 1.) adds the new option --linux-shortcut, and now only creates a shortcut on linux if specified 2.) only creates a shortcut on windows if win-menu or win-shortcut is specified. /Andy [1] https://bugs.openjdk.java.net/browse/JDK-8229779 [2] http://cr.openjdk.java.net/~herrick/8229779 From alexander.matveev at oracle.com Thu Sep 12 01:47:30 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Wed, 11 Sep 2019 18:47:30 -0700 Subject: RFR: JDK-8229779: Shortcut creation policy In-Reply-To: <583dc9b6-6b2b-a04b-f209-9ce2a851d007@oracle.com> References: <583dc9b6-6b2b-a04b-f209-9ce2a851d007@oracle.com> Message-ID: <8aac4206-b898-45cc-44a3-797b7d96bd7d@oracle.com> Looks good. On 9/11/2019 6:07 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 fix: > > 1.) adds the new option --linux-shortcut, and now only creates a > shortcut on linux if specified > > 2.) only creates a shortcut on windows if win-menu or win-shortcut is > specified. > > /Andy > > > [1] https://bugs.openjdk.java.net/browse/JDK-8229779 > > [2] http://cr.openjdk.java.net/~herrick/8229779 > From alexey.semenyuk at oracle.com Thu Sep 12 02:09:37 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Wed, 11 Sep 2019 22:09:37 -0400 Subject: RFR: JDK-8229779: Shortcut creation policy In-Reply-To: <583dc9b6-6b2b-a04b-f209-9ce2a851d007@oracle.com> References: <583dc9b6-6b2b-a04b-f209-9ce2a851d007@oracle.com> Message-ID: <22a04895-ff64-55ad-963f-26d49e11a0a8@oracle.com> SimplePackageTest.java: I'd suggest to put "Installer should not create any shortcuts" in the description or simply remove notice about shortcuts. Did you omit adding shortcuts to LinuxDebBundler.java on purpose? - Alexey On 9/11/2019 9:07 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 fix: > > 1.) adds the new option --linux-shortcut, and now only creates a > shortcut on linux if specified > > 2.) only creates a shortcut on windows if win-menu or win-shortcut is > specified. > > /Andy > > > [1] https://bugs.openjdk.java.net/browse/JDK-8229779 > > [2] http://cr.openjdk.java.net/~herrick/8229779 > From martinrb at google.com Thu Sep 12 02:54:41 2019 From: martinrb at google.com (Martin Buchholz) Date: Wed, 11 Sep 2019 19:54:41 -0700 Subject: RFR [14] 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect In-Reply-To: References: <97114AA9-A44A-4C36-843C-1E6933348096@oracle.com> <026e37eb-3da6-5f39-ac8d-99ad26bba3d0@oracle.com> <81060A81-D77F-4F49-A131-DE79F66FE29B@oracle.com> <6db710f3-dff6-f6ea-5922-242516769ed8@oracle.com> <1A766DB0-E937-438A-BDE1-26DC29FC25EC@oracle.com> <0911E28D-E382-4A0E-A7DB-F775C522BFB4@oracle.com> <564053B0-6FC9-468A-B75D-94F796015BB6@oracle.com> Message-ID: We're mostly in agreement. (Also, I'm not actually an ldap reviewer.) On Wed, Sep 11, 2019 at 11:02 AM Pavel Rappo wrote: > I agree that this example [1] looks readable (depending on a reader, of > course). I think it looks readable mostly because it is very explicit. > However, in a domain other than concurrency we are not usually concerned > with this level of detail. I think you *are* in the domain of concurrency! > a. is not using any synchronization aid to make sure both threads wait for > each other (probably, the timeout value accommodates that) > Thread.join is a synchronization aid! But there's no shortage of others. We typically use a CountDownLatch to synchronize with another thread. > b. uses a number of tiny low-level methods like newStartedThread, > awaitTermination, millisElapsedSince, manual time assertions, etc. > c. has assertions spread across 2 threads > I don't see that as a problem, as long as every assertion failure propagates properly to become a test failure. > > (b) probably allows you to reuse components in places unrelated to > timeouts. At the same time you don't seem to have any higher-level reusable > component (i.e. my guess is that this code is more or less repeated in > other places in that test suite, which is not necessarily a bad thing). > > However, I fully agree with you that this functionality should be a > utility method of the test library. > > ------------------------- > [1] I assume this is an excerpt from CountDownLatchTest.java. If so, then > for the reader's convenience this method could be seen in its context at > http://hg.openjdk.java.net/jdk/jdk/file/d52f77f0acb5/test/jdk/java/util/concurrent/tck/CountDownLatchTest.java#l198 > [2] I'm not saying that those things are wrong or that I disagree with any > of that. It's just an observation from reading this example. > > From alexander.matveev at oracle.com Thu Sep 12 03:46:02 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Wed, 11 Sep 2019 20:46:02 -0700 Subject: RFR: JDK-8230653: jpackage error on macOS system without xcode 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). - Error mentioned in bug report was due to missing Xcode when running SetFile. Fixed by not running SetFile if Xcode is not available. This tool used to set custom icon on DMG file and we do not consider it as real error. Verbose output will indicate that custom icon is skipped for DMG. - Signing will fail if Xcode is not installed. Added check for Xcode availability if signing is requested. If Xcode is not available and signing is specified we will fail with error. [1] https://bugs.openjdk.java.net/browse/JDK-8230653 [2] http://cr.openjdk.java.net/~almatvee/8230653/webrev.00 Thanks, Alexander From alexander.matveev at oracle.com Thu Sep 12 03:53:37 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Wed, 11 Sep 2019 20:53:37 -0700 Subject: RFR: JDK-8230629: jpackage signing on macOS does not work as expected Message-ID: <943112e8-922f-b711-887d-ce157463881f@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). - Binaries in runtime and Frameworks will not be signed directly using user provided certificate. - libapplauncher.dylib will be signed with user provided certificate only if it is unsigned. - When signing is enabled app and pkg will be signed, but not dmg. App inside pkg and dmg will be signed as well. [1] https://bugs.openjdk.java.net/browse/JDK-8230629 [2] http://cr.openjdk.java.net/~almatvee/8230629/webrev.00/ Thanks, Alexander From forax at univ-mlv.fr Thu Sep 12 08:48:49 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 12 Sep 2019 10:48:49 +0200 (CEST) Subject: RFR: jsr166 integration 2019-09 In-Reply-To: References: Message-ID: <517197737.1773850.1568278129180.JavaMail.zimbra@u-pem.fr> This remember me something, we should refactor most of the the package-private final methods (and the corresponding constructors) at least inside java.lang/java.util to make them private, there is no need to make them package-private anymore given that since Java 11 the compiler emits nestmate attributes instead of generating the method access$XXX. Maybe i should write a bytecode analyzer for that ? R?mi ----- Mail original ----- > De: "Martin Buchholz" > ?: "core-libs-dev" , "loom-dev" , "David Holmes" > > Envoy?: Lundi 9 Septembre 2019 17:06:28 > Objet: RFR: jsr166 integration 2019-09 > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html > > 8229442: AQS and lock classes refresh > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/lock-classes-refresh/index.html > https://bugs.openjdk.java.net/browse/JDK-8229442 > > Lock classes refresh is a small step towards loom. > Loom folk, how about adding Doug and I as Loom Project Committers, even > though we have no concrete plans to submit to the loom repo yet? > > Another round of stress testing at Google allowed us to fix a handful of > very rare test failures. > > 8227235: rare failures in testForkHelpQuiesce tck tests > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/ForkJoin-quiesce/index.html > https://bugs.openjdk.java.net/browse/JDK-8227235 > > 8221168: java/util/concurrent/CountDownLatch/Basic.java fails > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/CountDownLatch-Basic/index.html > https://bugs.openjdk.java.net/browse/JDK-8221168 > > 8145138: CyclicBarrier/Basic.java failed with "3 not equal to 4" > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/CyclicBarrier-Basic/index.html > https://bugs.openjdk.java.net/browse/JDK-8145138 > > 8225490: Miscellaneous changes imported from jsr166 CVS 2019-09 > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/miscellaneous/index.html > https://bugs.openjdk.java.net/browse/JDK-8225490 From thomas.stuefe at gmail.com Thu Sep 12 10:40:53 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 12 Sep 2019 12:40:53 +0200 Subject: RFR(T): 8230910: libsspi_bridge does not build on Windows 32bit Message-ID: Hi all, may I please have reviews for the following trivial build fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8230910 webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8230910-libsspi_bridge_does_not_build_on_windows_32bit/webrev.00/webrev/ Thanks, Thomas From alexey.semenyuk at oracle.com Thu Sep 12 11:05:00 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Thu, 12 Sep 2019 07:05:00 -0400 Subject: RFR: JDK-8230653: jpackage error on macOS system without xcode In-Reply-To: References: Message-ID: <321205dd-511d-1863-53c2-7087ec0a9fa7@oracle.com> Looks good. - Alexey On 9/11/2019 11:46 PM, Alexander Matveev wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > - Error mentioned in bug report was due to missing Xcode when running > SetFile. Fixed by not running SetFile if Xcode is not available. This > tool used to set custom icon on DMG file and we do not consider it as > real error. Verbose output will indicate that custom icon is skipped > for DMG. > - Signing will fail if Xcode is not installed. Added check for Xcode > availability if signing is requested. If Xcode is not available and > signing is specified we will fail with error. > > [1] https://bugs.openjdk.java.net/browse/JDK-8230653 > > [2] http://cr.openjdk.java.net/~almatvee/8230653/webrev.00 > > Thanks, > Alexander From andy.herrick at oracle.com Thu Sep 12 11:13:01 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Thu, 12 Sep 2019 07:13:01 -0400 Subject: RFR: JDK-8230653: jpackage error on macOS system without xcode In-Reply-To: References: Message-ID: <053eb415-fa25-df10-17dc-d80c29e36dda@oracle.com> looks good. /Andy On 9/11/2019 11:46 PM, Alexander Matveev wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > - Error mentioned in bug report was due to missing Xcode when running > SetFile. Fixed by not running SetFile if Xcode is not available. This > tool used to set custom icon on DMG file and we do not consider it as > real error. Verbose output will indicate that custom icon is skipped > for DMG. > - Signing will fail if Xcode is not installed. Added check for Xcode > availability if signing is requested. If Xcode is not available and > signing is specified we will fail with error. > > [1] https://bugs.openjdk.java.net/browse/JDK-8230653 > > [2] http://cr.openjdk.java.net/~almatvee/8230653/webrev.00 > > Thanks, > Alexander From alexey.semenyuk at oracle.com Thu Sep 12 11:13:16 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Thu, 12 Sep 2019 07:13:16 -0400 Subject: RFR: JDK-8230629: jpackage signing on macOS does not work as expected In-Reply-To: <943112e8-922f-b711-887d-ce157463881f@oracle.com> References: <943112e8-922f-b711-887d-ce157463881f@oracle.com> Message-ID: <11e4701f-4b6e-19a3-81e7-bd28dbace273@oracle.com> Looks good, though --- List args = new ArrayList<>(); ?940???????? args.addAll(Arrays.asList("codesign", ?941???????????????? "--verify", ?942???????????????? file.toString())); ?943 ?944???????? ProcessBuilder pb ?945???????????????? = new ProcessBuilder(args.toArray(new String[args.size()])); --- can be as simple as: --- ProcessBuilder pb = new ProcessBuilder("codesign", "--verify", file.toString()); --- - Alexey On 9/11/2019 11:53 PM, Alexander Matveev wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > - Binaries in runtime and Frameworks will not be signed directly using > user provided certificate. > - libapplauncher.dylib will be signed with user provided certificate > only if it is unsigned. > - When signing is enabled app and pkg will be signed, but not dmg. App > inside pkg and dmg will be signed as well. > > [1] https://bugs.openjdk.java.net/browse/JDK-8230629 > > [2] http://cr.openjdk.java.net/~almatvee/8230629/webrev.00/ > > Thanks, > Alexander From andy.herrick at oracle.com Thu Sep 12 11:11:12 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Thu, 12 Sep 2019 07:11:12 -0400 Subject: RFR: JDK-8229779: Shortcut creation policy In-Reply-To: <22a04895-ff64-55ad-963f-26d49e11a0a8@oracle.com> References: <583dc9b6-6b2b-a04b-f209-9ce2a851d007@oracle.com> <22a04895-ff64-55ad-963f-26d49e11a0a8@oracle.com> Message-ID: Revised with webrev.03. Changed SimplePackageTest instructions as suggested and added LinuxDebBundler.java to file list (double checked file list used to create webrev contains all changed files). /ANdy On 9/11/2019 10:09 PM, Alexey Semenyuk wrote: > SimplePackageTest.java: > I'd suggest to put "Installer should not create any shortcuts" in the > description or simply remove notice about shortcuts. > > Did you omit adding shortcuts to LinuxDebBundler.java on purpose? > > - Alexey > > On 9/11/2019 9:07 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 fix: >> >> 1.) adds the new option --linux-shortcut, and now only creates a >> shortcut on linux if specified >> >> 2.) only creates a shortcut on windows if win-menu or win-shortcut is >> specified. >> >> /Andy >> >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8229779 >> >> [2] http://cr.openjdk.java.net/~herrick/8229779 >> > From pavel.rappo at oracle.com Thu Sep 12 11:36:51 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 12 Sep 2019 12:36:51 +0100 Subject: RFR [14] 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect In-Reply-To: References: <97114AA9-A44A-4C36-843C-1E6933348096@oracle.com> <026e37eb-3da6-5f39-ac8d-99ad26bba3d0@oracle.com> <81060A81-D77F-4F49-A131-DE79F66FE29B@oracle.com> <6db710f3-dff6-f6ea-5922-242516769ed8@oracle.com> <1A766DB0-E937-438A-BDE1-26DC29FC25EC@oracle.com> <0911E28D-E382-4A0E-A7DB-F775C522BFB4@oracle.com> <564053B0-6FC9-468A-B75D-94F796015BB6@oracle.com> Message-ID: > On 12 Sep 2019, at 03:54, Martin Buchholz wrote: > > We're mostly in agreement. Good to hear and I agree! > On Wed, Sep 11, 2019 at 11:02 AM Pavel Rappo > wrote: > > > a. is not using any synchronization aid to make sure both threads wait for each other (probably, the timeout value accommodates that) > > Thread.join is a synchronization aid! But there's no shortage of others. We typically use a CountDownLatch to synchronize with another thread. I should have expressed myself more clear. I meant that the main thread and the thread created (and started) by `newStartedThread` (the test tread) do not wait for *each other* before they begin. This might be needed to make sure that they start at the same time (loosely speaking, of course). One might argue that the importance of this diminishes with the increase of the timeout that the main thread uses to wait for the test thread to die and the accuracy of measurements one agrees to tolerate. I'm seeing differences in our timeout-measuring routines as just a difference in tastes. Since a particular behavior here is not guaranteed anyway (as it's not a hard real-time system), all we can hope for in both cases is adequate timeout values and useful diagnostic output. Thanks for patiently staying with this thread for so long, Martin. *** Here's the updated version of the RFR based on the discussion so far: http://cr.openjdk.java.net/~prappo/8151678/webrev.02/ For the reviewers. I totally forgot to explain why there's a multiplier of 2 in some of the timeout calculations. The reason is the current behavior of InitialDirContext. The supplied connect timeout seems to be used twice. Once for making the actual TCP connection [1] and the second time while waiting for the server to respond to the BIND message [2]. Thus, the total time spent in that InitialDirContext ctor may be twice the expected. I believe it's a bug, but the bug that is not related to the issue in question. The current issue (8151678) is about intermittent failures of LdapTimeoutTest. -Pavel --------------------------------------------------- [1] http://hg.openjdk.java.net/jdk/jdk/file/79186d82463e/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#l296, http://hg.openjdk.java.net/jdk/jdk/file/79186d82463e/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#l320 [2] http://hg.openjdk.java.net/jdk/jdk/file/79186d82463e/src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java#l154, http://hg.openjdk.java.net/jdk/jdk/file/79186d82463e/src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java#l365 From chris.hegarty at oracle.com Thu Sep 12 11:41:46 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 12 Sep 2019 12:41:46 +0100 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> <87sgpblxns.fsf@oldenburg2.str.redhat.com> <7A46485C-E250-4E57-9FB0-B9D18CA70632@oracle.com> <60FD933F-51A5-4438-83AF-B3427CFDE60D@oracle.com> <8A9E3066-E6F6-4E65-BD02-DF0ACFF02FAD@oracle.com> <633A0CE3-C771-493B-89E3-7FA843C85183@oracle.com> <6b209e36-686f-7852-7fb8-3a0ef0e8423a@oracle.com> Message-ID: <4CAC6E8D-9198-4701-99C0-49901D72A396@oracle.com> Here is an initial attempt to document these timeout/retry properties. It?s effectively the wording lifted from the tech notes [1], with ?UDP? removed. I deliberately avoided describing the implementation. It serves little purpose, and in fact will greatly complicate the description, as well as constrain the implementation. I personally dislike parts of the existing implementation ( which I will ignore ), so baking them into the spec would be a mistake. There are clearly a lot more properties that could be specified, that is far far beyond the scope of this change. If we add such documentation, then a CSR ( with JDK-scope ) will be needed. --- a/src/jdk.naming.dns/share/classes/module-info.java +++ b/src/jdk.naming.dns/share/classes/module-info.java @@ -26,7 +26,38 @@ /** * Provides the implementation of the DNS Java Naming provider. * + * <2>Environment Properties + * + *

The following JNDI environment properties are relevant to the DNS + * provider. + * + *

    + *
  • com.sun.jndi.dns.timeout.initial
    • + *
  • com.sun.jndi.dns.timeout.retries
    • + *
+ * + *

These properties are used to alter the timeout-related defaults that the + * DNS provider uses when submitting queries. The DNS provider submits queries + * using the following exponential backoff algorithm. The provider submits a + * query to a DNS server and waits for a response to arrive within a timeout + * period (1 second by default). If it receives no response within the timeout + * period, it queries the next server, and so on. If the provider receives no + * response from any server, it doubles the timeout period and repeats the + * process of submitting the query to each server, up to a maximum number of + * retries (4 by default). + * + *

The {@code com.sun.jndi.dns.timeout.initial} property, if set, specifies + * the number of milliseconds to use as the initial timeout period (i.e., before + * any doubling). If this property has not been set, the default initial timeout + * is 1000 milliseconds. + * + *

The {@code com.sun.jndi.dns.timeout.retries} property, if set, specifies + * the number of times to retry each server using the exponential backoff + * algorithm described previously. If this property has not been set, the + * default number of retries is 4. + * * @provides javax.naming.spi.InitialContextFactory + * * @moduleGraph * @since 9 */ -Chris. [1] https://docs.oracle.com/javase/6/docs/technotes/guides/jndi/jndi-dns.html > On 11 Sep 2019, at 16:55, Alan Bateman wrote: > > On 11/09/2019 16:16, Pavel Rappo wrote: >> >>> On 11 Sep 2019, at 16:10, Alan Bateman wrote: >>> >>> I assume extending the timeout to TCP will require at least some minimal updates to the descriptions. >> Which descriptions do you have in mind? I cannot seem to find that text anywhere in the current repo (jdk/jdk) > I don't think the jndi-dns docs page is in the jdk repo. Since JDK 9, a good place for service providers to document capability and configuration is their module description and I think at least some of the documentation from that page should move into the jdk.naming.dns module description (that's for another issue of course). However, for the changes under discussion here then I don't think it's unreasonable to provide an updated description of the timeout property. > > -Alan > From alexey.semenyuk at oracle.com Thu Sep 12 11:48:02 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Thu, 12 Sep 2019 07:48:02 -0400 Subject: RFR: JDK-8229779: Shortcut creation policy In-Reply-To: References: <583dc9b6-6b2b-a04b-f209-9ce2a851d007@oracle.com> <22a04895-ff64-55ad-963f-26d49e11a0a8@oracle.com> Message-ID: Looks good. Would you mind creating a follow up CR to add jtreg test(s) for the new command line option. - Alexey On 9/12/2019 7:11 AM, Andy Herrick wrote: > Revised with webrev.03. > > Changed SimplePackageTest instructions as suggested and added > LinuxDebBundler.java to file list (double checked file list used to > create webrev contains all changed files). > > /ANdy > > On 9/11/2019 10:09 PM, Alexey Semenyuk wrote: >> SimplePackageTest.java: >> I'd suggest to put "Installer should not create any shortcuts" in the >> description or simply remove notice about shortcuts. >> >> Did you omit adding shortcuts to LinuxDebBundler.java on purpose? >> >> - Alexey >> >> On 9/11/2019 9:07 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 fix: >>> >>> 1.) adds the new option --linux-shortcut, and now only creates a >>> shortcut on linux if specified >>> >>> 2.) only creates a shortcut on windows if win-menu or win-shortcut >>> is specified. >>> >>> /Andy >>> >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8229779 >>> >>> [2] http://cr.openjdk.java.net/~herrick/8229779 >>> >> From rob.mckenna at oracle.com Thu Sep 12 12:26:56 2019 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 12 Sep 2019 13:26:56 +0100 Subject: RFR [14] 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect In-Reply-To: References: <1A766DB0-E937-438A-BDE1-26DC29FC25EC@oracle.com> <0911E28D-E382-4A0E-A7DB-F775C522BFB4@oracle.com> <564053B0-6FC9-468A-B75D-94F796015BB6@oracle.com> Message-ID: <20190912122656.GA13233@vimes> This looks great to me. Thanks for taking a look at it. -Rob On 12/09/19 12:36, Pavel Rappo wrote: > > On 12 Sep 2019, at 03:54, Martin Buchholz wrote: > > > > We're mostly in agreement. > > Good to hear and I agree! > > > On Wed, Sep 11, 2019 at 11:02 AM Pavel Rappo > wrote: > > > > > > a. is not using any synchronization aid to make sure both threads wait for each other (probably, the timeout value accommodates that) > > > > Thread.join is a synchronization aid! But there's no shortage of others. We typically use a CountDownLatch to synchronize with another thread. > > > I should have expressed myself more clear. I meant that the main thread and the thread created (and started) by `newStartedThread` (the test tread) do not wait for *each other* before they begin. This might be needed to make sure that they start at the same time (loosely speaking, of course). One might argue that the importance of this diminishes with the increase of the timeout that the main thread uses to wait for the test thread to die and the accuracy of measurements one agrees to tolerate. > > I'm seeing differences in our timeout-measuring routines as just a difference in tastes. Since a particular behavior here is not guaranteed anyway (as it's not a hard real-time system), all we can hope for in both cases is adequate timeout values and useful diagnostic output. > > Thanks for patiently staying with this thread for so long, Martin. > > > *** > > > Here's the updated version of the RFR based on the discussion so far: > > http://cr.openjdk.java.net/~prappo/8151678/webrev.02/ > > For the reviewers. I totally forgot to explain why there's a multiplier of 2 in some of the timeout calculations. The reason is the current behavior of InitialDirContext. The supplied connect timeout seems to be used twice. Once for making the actual TCP connection [1] and the second time while waiting for the server to respond to the BIND message [2]. Thus, the total time spent in that InitialDirContext ctor may be twice the expected. I believe it's a bug, but the bug that is not related to the issue in question. The current issue (8151678) is about intermittent failures of LdapTimeoutTest. > > -Pavel > > --------------------------------------------------- > [1] http://hg.openjdk.java.net/jdk/jdk/file/79186d82463e/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#l296, http://hg.openjdk.java.net/jdk/jdk/file/79186d82463e/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#l320 > [2] http://hg.openjdk.java.net/jdk/jdk/file/79186d82463e/src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java#l154, http://hg.openjdk.java.net/jdk/jdk/file/79186d82463e/src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java#l365 > From pavel.rappo at oracle.com Thu Sep 12 12:27:58 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 12 Sep 2019 13:27:58 +0100 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: <4CAC6E8D-9198-4701-99C0-49901D72A396@oracle.com> References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> <87sgpblxns.fsf@oldenburg2.str.redhat.com> <7A46485C-E250-4E57-9FB0-B9D18CA70632@oracle.com> <60FD933F-51A5-4438-83AF-B3427CFDE60D@oracle.com> <8A9E3066-E6F6-4E65-BD02-DF0ACFF02FAD@oracle.com> <633A0CE3-C771-493B-89E3-7FA843C85183@oracle.com> <6b209e36-686f-7852-7fb8-3a0ef0e8423a@oracle.com> <4CAC6E8D-9198-4701-99C0-49901D72A396@oracle.com> Message-ID: <9D166682-9477-4872-B933-0852DF4B7305@oracle.com> I like the wording, it's concise. Thanks a lot for helping us with this, Chris! Trivially, there's a typo: <2> instead of

. > On 12 Sep 2019, at 12:41, Chris Hegarty wrote: > > Here is an initial attempt to document these timeout/retry properties. It?s effectively the wording lifted from the tech notes [1], with ?UDP? removed. > > I deliberately avoided describing the implementation. It serves little purpose, and in fact will greatly complicate the description, as well as constrain the implementation. I personally dislike parts of the existing implementation ( which I will ignore ), so baking them into the spec would be a mistake. > > There are clearly a lot more properties that could be specified, that is far far beyond the scope of this change. > > If we add such documentation, then a CSR ( with JDK-scope ) will be needed. > > --- a/src/jdk.naming.dns/share/classes/module-info.java > +++ b/src/jdk.naming.dns/share/classes/module-info.java > @@ -26,7 +26,38 @@ > /** > * Provides the implementation of the DNS Java Naming provider. > * > + * <2>Environment Properties

> + * > + *

The following JNDI environment properties are relevant to the DNS > + * provider. > + * > + *

    > + *
  • com.sun.jndi.dns.timeout.initial
    • > + *
  • com.sun.jndi.dns.timeout.retries
    • > + *
> + * > + *

These properties are used to alter the timeout-related defaults that the > + * DNS provider uses when submitting queries. The DNS provider submits queries > + * using the following exponential backoff algorithm. The provider submits a > + * query to a DNS server and waits for a response to arrive within a timeout > + * period (1 second by default). If it receives no response within the timeout > + * period, it queries the next server, and so on. If the provider receives no > + * response from any server, it doubles the timeout period and repeats the > + * process of submitting the query to each server, up to a maximum number of > + * retries (4 by default). > + * > + *

The {@code com.sun.jndi.dns.timeout.initial} property, if set, specifies > + * the number of milliseconds to use as the initial timeout period (i.e., before > + * any doubling). If this property has not been set, the default initial timeout > + * is 1000 milliseconds. > + * > + *

The {@code com.sun.jndi.dns.timeout.retries} property, if set, specifies > + * the number of times to retry each server using the exponential backoff > + * algorithm described previously. If this property has not been set, the > + * default number of retries is 4. > + * > * @provides javax.naming.spi.InitialContextFactory > + * > * @moduleGraph > * @since 9 > */ > > -Chris. > > [1] https://docs.oracle.com/javase/6/docs/technotes/guides/jndi/jndi-dns.html > >> On 11 Sep 2019, at 16:55, Alan Bateman wrote: >> >> On 11/09/2019 16:16, Pavel Rappo wrote: >>> >>>> On 11 Sep 2019, at 16:10, Alan Bateman wrote: >>>> >>>> I assume extending the timeout to TCP will require at least some minimal updates to the descriptions. >>> Which descriptions do you have in mind? I cannot seem to find that text anywhere in the current repo (jdk/jdk) >> I don't think the jndi-dns docs page is in the jdk repo. Since JDK 9, a good place for service providers to document capability and configuration is their module description and I think at least some of the documentation from that page should move into the jdk.naming.dns module description (that's for another issue of course). However, for the changes under discussion here then I don't think it's unreasonable to provide an updated description of the timeout property. >> >> -Alan >> > From chris.l.merrill at gmail.com Thu Sep 12 13:54:15 2019 From: chris.l.merrill at gmail.com (Christopher Merrill) Date: Thu, 12 Sep 2019 09:54:15 -0400 Subject: Feedback JEP 343: jpackage --win-menu Message-ID: I am using build 14-jpackage+1-35 with WiX 3.11.1.2318 to build an MSI installer. If I am understanding the comments in thread "RFR: JDK-8229779: Shortcut creation policy", a start menu entry (and desktop shortcut?) should always be produced with this version of jpackage command line options? The MSI installer I've created does not create a start menu entry, even when I include the --win-menu option. Other people seem to have the opposite problem (start menu item when they don't want it), so clearly I'm doing something wrong... C:\Apps\OpenJDKs\jdk-14/bin/jpackage --package-type msi --output D:\Work\MuseProject\ide\closed\install\build\jpackage --name MuseIDE-launcher --app-image D:\Work\MuseProject\ide\closed\install\build\jpackage/MuseIDE-launcher --win-per-user-install --win-menu --app-version 3.1 --name MuseIDE-Launcher Other than this message, which I assume is a warning, the execution is successful: Multiple launchers found in predefined app-image. jvm will be used as primary launcher. Are there other options that would influence getting a start menu item added by the installer? FWIW, I am using gradle with the org.beryx.runtime plugin to create the image and installer. Are there settings/options/stuff in the image that would affect creation of the start menu item? TIA! Chris -- ????o ?? llo? 's??? p??? u?? no? ?? From martinrb at google.com Thu Sep 12 14:20:12 2019 From: martinrb at google.com (Martin Buchholz) Date: Thu, 12 Sep 2019 07:20:12 -0700 Subject: RFR: jsr166 integration 2019-09 In-Reply-To: <517197737.1773850.1568278129180.JavaMail.zimbra@u-pem.fr> References: <517197737.1773850.1568278129180.JavaMail.zimbra@u-pem.fr> Message-ID: On Thu, Sep 12, 2019 at 1:48 AM Remi Forax wrote: > This remember me something, > we should refactor most of the the package-private final methods (and the > corresponding constructors) at least inside java.lang/java.util to make > them private, there is no need to make them package-private anymore given > that since Java 11 the compiler emits nestmate attributes instead of > generating the method access$XXX. > > Maybe i should write a bytecode analyzer for that ? > Right! Going the other way it was fairly easy to trawl through the generated bytecode using javap looking for "access$". I don't think the nestmates feature is really complete until there is an easy tool to find all the package-private elements accessed only within their nest. From andy.herrick at oracle.com Thu Sep 12 14:32:33 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Thu, 12 Sep 2019 10:32:33 -0400 Subject: Feedback JEP 343: jpackage --win-menu In-Reply-To: References: Message-ID: <96d88a7d-e256-6fbf-5d6a-1ffee4c97835@oracle.com> Strange ... I can't seem to reproduce any scenario where msi installer created by jpackage won't install a shortcut, but from the message: "Multiple launchers found in predefined app-image. jvm will be used as primary launcher." It seems that? you are using a predefined app-image? and there are multiple launchers in the app-image, and the code is choosing "jvm" as the primary one (the one a shortcut will be created for). This may be the wrong launcher.? When an installer is built for an existing app-image, it doesn't know the name of the app, it looks for the config file? in /app/ If there are multiple cfg files (like you built the app-image with --add-launcher jvm=jvm-launcher.properties) it is just taking the first one. Is it possible this is what is happening in your case ? /Andy On 9/12/2019 9:54 AM, Christopher Merrill wrote: > I am using build 14-jpackage+1-35 with WiX 3.11.1.2318 to build an MSI > installer. If I am understanding the comments in thread "RFR: JDK-8229779: > Shortcut creation policy", a start menu entry (and desktop shortcut?) > should always be produced with this version of jpackage command line > options? The MSI installer I've created does not create a start menu entry, > even when I include the --win-menu option. Other people seem to have the > opposite problem (start menu item when they don't want it), so clearly I'm > doing something wrong... > > C:\Apps\OpenJDKs\jdk-14/bin/jpackage --package-type msi --output > D:\Work\MuseProject\ide\closed\install\build\jpackage --name > MuseIDE-launcher --app-image > D:\Work\MuseProject\ide\closed\install\build\jpackage/MuseIDE-launcher > --win-per-user-install --win-menu --app-version 3.1 --name MuseIDE-Launcher > > Other than this message, which I assume is a warning, the execution is > successful: > Multiple launchers found in predefined app-image. jvm will be used as > primary launcher. > > Are there other options that would influence getting a start menu item > added by the installer? > > FWIW, I am using gradle with the org.beryx.runtime plugin to create the > image and installer. Are there settings/options/stuff in the image that > would affect creation of the start menu item? > > TIA! > Chris > From naoto.sato at oracle.com Thu Sep 12 15:02:15 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 12 Sep 2019 08:02:15 -0700 Subject: RFR 8230829 : Matcher matches a surrogate pair that crosses border of the region In-Reply-To: <5ab65db6-701a-937e-e93c-6ee4ef6fd159@oracle.com> References: <5ab65db6-701a-937e-e93c-6ee4ef6fd159@oracle.com> Message-ID: <6f948520-17f5-0f5e-5fb7-01b6f5670c63@oracle.com> Looks good to me, Ivan. Naoto On 9/10/19 9:13 PM, Ivan Gerasimov wrote: > Hello! > > When the regex.Matcher matches a supplementary codepoint, it may > inadvertently cross the border of the explicitly specified region > without noticing. > > Would you please help review a simple fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8230829 > WEBREV: http://cr.openjdk.java.net/~igerasim/8230829/00/webrev/ > > Thanks in advance! > From chris.l.merrill at gmail.com Thu Sep 12 15:08:47 2019 From: chris.l.merrill at gmail.com (Christopher Merrill) Date: Thu, 12 Sep 2019 11:08:47 -0400 Subject: Feedback JEP 343: jpackage --win-menu In-Reply-To: <96d88a7d-e256-6fbf-5d6a-1ffee4c97835@oracle.com> References: <96d88a7d-e256-6fbf-5d6a-1ffee4c97835@oracle.com> Message-ID: Thanks Andy. Ok, so the image was created in the previous step using: C:\Apps\OpenJDKs\jdk-14/bin/jpackage.exe --input D:\Work\MuseProject\ide\closed\install\build\image\lib --main-jar MuseIDE-launcher-3.1.jar --main-class org.musetest.ide.launcher.Bootstrap --output D:\Work\MuseProject\ide\closed\install\build\jpackage --name MuseIDE-launcher --identifier org.musetest.ide.launcher.Bootstrap --runtime-image D:\Work\MuseProject\ide\closed\install\build\image There is only one .cfg file in the .../build/image folder, 'jvm.cfg', which contains: -server KNOWN -client IGNORE However, the output folder (../build/jpackage/MuseIDE-launcher/app) of the second jpackage step which I referenced in the previous message contains a MuseIDE-launcher.cfg file with: [Application] app.name=MuseIDE-launcher app.version=1.0 app.runtime=$APPDIR\runtime app.identifier=org.musetest.ide.launcher.Bootstrap app.classpath=$APPDIR\app\MuseIDE-launcher-3.1.jar;$APPDIR\app\dynamic-classloader-0.2.jar;$APPDIR\app\IdeLaunchUpdate-2.3.jar;$APPDIR\app\jrt-fs.jar;$APPDIR\app\update4j-1.2.2.jar app.mainjar=$APPDIR\app\MuseIDE-launcher-3.1.jar app.mainclass=org.musetest.ide.launcher.Bootstrap [JavaOptions] [ArgOptions] I didn't create or supply that file...so I assume jpackage did. Could it be the missing windows start menu item be affected by the location of the main class? In my case, it isn't in the main jar. In fact, the main jar is empty except for the manifest, which contains only the manifest version declaration. The main class is located in one of the other jar files, which are correctly included in the resulting image and installer. The .cfg correctly includes those JARs on the classpath (and it all works fine when installed). I don't really see how that should affect the creation of a shortcut to the .exe, but thought I would mention it. TIA! Chris On Thu, Sep 12, 2019 at 10:34 AM Andy Herrick wrote: > Strange ... > > I can't seem to reproduce any scenario where msi installer created by > jpackage won't install a shortcut, but from the message: > > "Multiple launchers found in predefined app-image. jvm will be used as > primary launcher." > > It seems that you are using a predefined app-image and there are > multiple launchers in the app-image, and the code is choosing "jvm" as > the primary one (the one a shortcut will be created for). > > This may be the wrong launcher. When an installer is built for an > existing app-image, it doesn't know the name of the app, it looks for > the config file in /app/ > > If there are multiple cfg files (like you built the app-image with > --add-launcher jvm=jvm-launcher.properties) it is just taking the first > one. > > Is it possible this is what is happening in your case ? > > /Andy > > On 9/12/2019 9:54 AM, Christopher Merrill wrote: > > I am using build 14-jpackage+1-35 with WiX 3.11.1.2318 to build an MSI > > installer. If I am understanding the comments in thread "RFR: > JDK-8229779: > > Shortcut creation policy", a start menu entry (and desktop shortcut?) > > should always be produced with this version of jpackage command line > > options? The MSI installer I've created does not create a start menu > entry, > > even when I include the --win-menu option. Other people seem to have the > > opposite problem (start menu item when they don't want it), so clearly > I'm > > doing something wrong... > > > > C:\Apps\OpenJDKs\jdk-14/bin/jpackage --package-type msi --output > > D:\Work\MuseProject\ide\closed\install\build\jpackage --name > > MuseIDE-launcher --app-image > > D:\Work\MuseProject\ide\closed\install\build\jpackage/MuseIDE-launcher > > --win-per-user-install --win-menu --app-version 3.1 --name > MuseIDE-Launcher > > > > Other than this message, which I assume is a warning, the execution is > > successful: > > Multiple launchers found in predefined app-image. jvm will be used as > > primary launcher. > > > > Are there other options that would influence getting a start menu item > > added by the installer? > > > > FWIW, I am using gradle with the org.beryx.runtime plugin to create the > > image and installer. Are there settings/options/stuff in the image that > > would affect creation of the start menu item? > > > > TIA! > > Chris > > > -- ????o ?? llo? 's??? p??? u?? no? ?? From martinrb at google.com Thu Sep 12 15:21:56 2019 From: martinrb at google.com (Martin Buchholz) Date: Thu, 12 Sep 2019 08:21:56 -0700 Subject: RFR [14] 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect In-Reply-To: References: <97114AA9-A44A-4C36-843C-1E6933348096@oracle.com> <026e37eb-3da6-5f39-ac8d-99ad26bba3d0@oracle.com> <81060A81-D77F-4F49-A131-DE79F66FE29B@oracle.com> <6db710f3-dff6-f6ea-5922-242516769ed8@oracle.com> <1A766DB0-E937-438A-BDE1-26DC29FC25EC@oracle.com> <0911E28D-E382-4A0E-A7DB-F775C522BFB4@oracle.com> <564053B0-6FC9-468A-B75D-94F796015BB6@oracle.com> Message-ID: On Thu, Sep 12, 2019 at 4:36 AM Pavel Rappo wrote: > > I should have expressed myself more clear. I meant that the main thread > and the thread created (and started) by `newStartedThread` (the test tread) > do not wait for *each other* before they begin. This might be needed to > make sure that they start at the same time (loosely speaking, of course). > One might argue that the importance of this diminishes with the increase of > the timeout that the main thread uses to wait for the test thread to die > and the accuracy of measurements one agrees to tolerate. > > You want coordination? We got coordination. Here's some infrastructure that uses a threadsStarted latch: void assertThrowInterruptedExceptionWhenInterrupted(Action[] actions) { int n = actions.length; Future[] futures = new Future[n]; CountDownLatch threadsStarted = new CountDownLatch(n); CountDownLatch done = new CountDownLatch(n); for (int i = 0; i < n; i++) { Action action = actions[i]; futures[i] = cachedThreadPool.submit(new CheckedRunnable() { public void realRun() throws Throwable { threadsStarted.countDown(); try { action.run(); shouldThrow(); } catch (InterruptedException success) {} catch (Throwable fail) { threadUnexpectedException(fail); } assertFalse(Thread.interrupted()); done.countDown(); }}); } await(threadsStarted); assertEquals(n, done.getCount()); for (Future future : futures) // Interrupt all the tasks future.cancel(true); await(done); } When communicating a request, just like in real life, you can't force others to do anything, so be politely Canadian and use "please" in the name of your latch /** * await throws InterruptedException if interrupted before counted down */ public void testAwait_Interruptible() { final CountDownLatch l = new CountDownLatch(1); final CountDownLatch pleaseInterrupt = new CountDownLatch(1); Thread t = newStartedThread(new CheckedRunnable() { public void realRun() throws InterruptedException { Thread.currentThread().interrupt(); try { l.await(); shouldThrow(); } catch (InterruptedException success) {} assertFalse(Thread.interrupted()); pleaseInterrupt.countDown(); try { l.await(); shouldThrow(); } catch (InterruptedException success) {} assertFalse(Thread.interrupted()); assertEquals(1, l.getCount()); }}); await(pleaseInterrupt); if (randomBoolean()) assertThreadBlocks(t, Thread.State.WAITING); t.interrupt(); awaitTermination(t); } From yano-masanori at jp.fujitsu.com Thu Sep 12 07:16:15 2019 From: yano-masanori at jp.fujitsu.com (Yano, Masanori) Date: Thu, 12 Sep 2019 07:16:15 +0000 Subject: 8229471: Calendar under a specific timezone changes HOUR field when MILLISECOND field is changed Message-ID: <3A451B05B742C24B92BEAC7B802BC85C2A0A626C@g01jpexmbkw06> Hello. I think JDK-8229471 occurs because a change of TimeZone is not considered in getTime(). To resolve this problem, isTimeSet flag must be set to false when setTimeZone() is called. Please review the following change. diff -r e1269de19aa5 src/java.base/share/classes/java/util/Calendar.java --- a/src/java.base/share/classes/java/util/Calendar.java Thu Aug 22 14:09:36 2019 -0700 +++ b/src/java.base/share/classes/java/util/Calendar.java Thu Sep 12 11:45:37 2019 +0900 @@ -2901,7 +2901,7 @@ * generally, a call to setTimeZone() affects calls to set() BEFORE AND * AFTER it up to the next call to complete(). */ - areAllFieldsSet = areFieldsSet = false; + isTimeSet = areAllFieldsSet = areFieldsSet = false; } /** diff -r e1269de19aa5 test/jdk/java/util/Calendar/Bug8229471.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/jdk/java/util/Calendar/Bug8229471.java Thu Sep 12 11:45:37 2019 +0900 @@ -0,0 +1,22 @@ +/* + *@test + *@bug 8229471 + *@summary test for recompute when Calendar.setTimeZone() + */ + +import java.util.Calendar; +import java.util.Date; +import java.util.Locale; +import java.util.TimeZone; + +public class Bug8229471 { + public static void main(String[] args) throws Exception { + Calendar calendar = Calendar.getInstance(new Locale("en", "US")); + Date date1 = calendar.getTime(); + calendar.setTimeZone(TimeZone.getTimeZone("Europe/Budapest")); + Date date2 = calendar.getTime(); + if (date1.equals(date2)) { + throw new RuntimeException("Bug8229471: failed. TimeZone is not applied."); + } + } +} Regards, Masanori Yano From sean.mullan at oracle.com Thu Sep 12 11:31:48 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 12 Sep 2019 07:31:48 -0400 Subject: RFR(T): 8230910: libsspi_bridge does not build on Windows 32bit In-Reply-To: References: Message-ID: This is in the security-libs area, not core-libs. Cross-posting to security-dev and bcc-ing core-libs-dev. --Sean On 9/12/19 6:40 AM, Thomas St?fe wrote: > Hi all, > > may I please have reviews for the following trivial build fix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8230910 > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8230910-libsspi_bridge_does_not_build_on_windows_32bit/webrev.00/webrev/ > > Thanks, > > Thomas > From andy.herrick at oracle.com Thu Sep 12 15:26:16 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Thu, 12 Sep 2019 11:26:16 -0400 Subject: Feedback JEP 343: jpackage --win-menu In-Reply-To: References: <96d88a7d-e256-6fbf-5d6a-1ffee4c97835@oracle.com> Message-ID: yes - clearly something wrong here - it is supposed to find MuseIDE-launcher.cfg and create shortcut to MuseIDE-launcher - but it has come up with jvm.cfg - a completely unrelated file. lets see - your input dir is the lib dir of your runtime-image. the app dir will be populated with everything in the input dir, so it gets jvm.cfg which is in every runtime's lib dir. Not sure why you want to do this, but I think it points out we should not be satisfied that a file has extension "cfg", we should also look at it and confirm it looks like a valid jpackage app-image .cfg file, before deriving the name of the app from the name of the cfg file. /Andy On 9/12/2019 11:08 AM, Christopher Merrill wrote: > Thanks Andy. > > Ok, so the image was created in the previous step using: > C:\Apps\OpenJDKs\jdk-14/bin/jpackage.exe --input > D:\Work\MuseProject\ide\closed\install\build\image\lib --main-jar > MuseIDE-launcher-3.1.jar --main-class > org.musetest.ide.launcher.Bootstrap --output > D:\Work\MuseProject\ide\closed\install\build\jpackage --name > MuseIDE-launcher --identifier org.musetest.ide.launcher.Bootstrap > --runtime-image D:\Work\MuseProject\ide\closed\install\build\image > > There is only one .cfg file in the .../build/image folder, 'jvm.cfg', > which contains: > -server KNOWN > -client IGNORE > > However, the output folder (../build/jpackage/MuseIDE-launcher/app) of > the second jpackage step which I referenced in the previous message > contains a MuseIDE-launcher.cfg file with: > [Application] > app.name =MuseIDE-launcher > app.version=1.0 > app.runtime=$APPDIR\runtime > app.identifier=org.musetest.ide.launcher.Bootstrap > app.classpath=$APPDIR\app\MuseIDE-launcher-3.1.jar;$APPDIR\app\dynamic-classloader-0.2.jar;$APPDIR\app\IdeLaunchUpdate-2.3.jar;$APPDIR\app\jrt-fs.jar;$APPDIR\app\update4j-1.2.2.jar > app.mainjar=$APPDIR\app\MuseIDE-launcher-3.1.jar > app.mainclass=org.musetest.ide.launcher.Bootstrap > [JavaOptions] > [ArgOptions] > > I didn't create or supply that file...so I assume jpackage did. > > Could it be the missing windows start menu item be affected by the > location of the main class?? In my case, it isn't in the main jar. In > fact, the main jar is empty except for the manifest, which contains > only the manifest version declaration. The main class is located in > one of the other jar files, which are correctly included in the > resulting image and installer. The .cfg correctly includes those JARs > on the classpath (and it all works fine when installed). I don't > really see how that should affect the creation of a shortcut to the > .exe, but thought I would mention it. > > TIA! > Chris > > > > On Thu, Sep 12, 2019 at 10:34 AM Andy Herrick > wrote: > > Strange ... > > I can't seem to reproduce any scenario where msi installer created by > jpackage won't install a shortcut, but from the message: > > "Multiple launchers found in predefined app-image. jvm will be > used as > primary launcher." > > It seems that? you are using a predefined app-image? and there are > multiple launchers in the app-image, and the code is choosing > "jvm" as > the primary one (the one a shortcut will be created for). > > This may be the wrong launcher.? When an installer is built for an > existing app-image, it doesn't know the name of the app, it looks for > the config file? in /app/ > > If there are multiple cfg files (like you built the app-image with > --add-launcher jvm=jvm-launcher.properties) it is just taking the > first one. > > Is it possible this is what is happening in your case ? > > /Andy > > On 9/12/2019 9:54 AM, Christopher Merrill wrote: > > I am using build 14-jpackage+1-35 with WiX 3.11.1.2318 to build > an MSI > > installer. If I am understanding the comments in thread "RFR: > JDK-8229779: > > Shortcut creation policy", a start menu entry (and desktop > shortcut?) > > should always be produced with this version of jpackage command line > > options? The MSI installer I've created does not create a start > menu entry, > > even when I include the --win-menu option. Other people seem to > have the > > opposite problem (start menu item when they don't want it), so > clearly I'm > > doing something wrong... > > > > C:\Apps\OpenJDKs\jdk-14/bin/jpackage --package-type msi --output > > D:\Work\MuseProject\ide\closed\install\build\jpackage --name > > MuseIDE-launcher --app-image > > > D:\Work\MuseProject\ide\closed\install\build\jpackage/MuseIDE-launcher > > --win-per-user-install --win-menu --app-version 3.1 --name > MuseIDE-Launcher > > > > Other than this message, which I assume is a warning, the > execution is > > successful: > >? ? Multiple launchers found in predefined app-image. jvm will be > used as > > primary launcher. > > > > Are there other options that would influence getting a start > menu item > > added by the installer? > > > > FWIW, I am using gradle with the org.beryx.runtime plugin to > create the > > image and installer. Are there settings/options/stuff in the > image that > > would affect creation of the start menu item? > > > > TIA! > > Chris > > > > > > -- > ????o ?? llo? 's??? p??? u?? no? ?? From andy.herrick at oracle.com Thu Sep 12 15:53:17 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Thu, 12 Sep 2019 11:53:17 -0400 Subject: Feedback JEP 343: jpackage --win-menu In-Reply-To: References: <96d88a7d-e256-6fbf-5d6a-1ffee4c97835@oracle.com> Message-ID: I filed https://bugs.openjdk.java.net/browse/JDK-8230920 to fix this. /Andy On 9/12/2019 11:26 AM, Andy Herrick wrote: > yes - clearly something wrong here - it is supposed to find > MuseIDE-launcher.cfg and create shortcut to MuseIDE-launcher - but it > has come up with jvm.cfg - a completely unrelated file. > > lets see - your input dir is the lib dir of your runtime-image. the > app dir will be populated with everything in the input dir, so it gets > jvm.cfg which is in every runtime's lib dir. > > Not sure why you want to do this, but I think it points out we should > not be satisfied that a file has extension "cfg", we should also look > at it and confirm it looks like a valid jpackage app-image .cfg > file, before deriving the name of the app from the name of the cfg file. > > /Andy > > On 9/12/2019 11:08 AM, Christopher Merrill wrote: >> Thanks Andy. >> >> Ok, so the image was created in the previous step using: >> C:\Apps\OpenJDKs\jdk-14/bin/jpackage.exe --input >> D:\Work\MuseProject\ide\closed\install\build\image\lib --main-jar >> MuseIDE-launcher-3.1.jar --main-class >> org.musetest.ide.launcher.Bootstrap --output >> D:\Work\MuseProject\ide\closed\install\build\jpackage --name >> MuseIDE-launcher --identifier org.musetest.ide.launcher.Bootstrap >> --runtime-image D:\Work\MuseProject\ide\closed\install\build\image >> >> There is only one .cfg file in the .../build/image folder, 'jvm.cfg', >> which contains: >> -server KNOWN >> -client IGNORE >> >> However, the output folder (../build/jpackage/MuseIDE-launcher/app) >> of the second jpackage step which I referenced in the previous >> message contains a MuseIDE-launcher.cfg file with: >> [Application] >> app.name =MuseIDE-launcher >> app.version=1.0 >> app.runtime=$APPDIR\runtime >> app.identifier=org.musetest.ide.launcher.Bootstrap >> app.classpath=$APPDIR\app\MuseIDE-launcher-3.1.jar;$APPDIR\app\dynamic-classloader-0.2.jar;$APPDIR\app\IdeLaunchUpdate-2.3.jar;$APPDIR\app\jrt-fs.jar;$APPDIR\app\update4j-1.2.2.jar >> >> app.mainjar=$APPDIR\app\MuseIDE-launcher-3.1.jar >> app.mainclass=org.musetest.ide.launcher.Bootstrap >> [JavaOptions] >> [ArgOptions] >> >> I didn't create or supply that file...so I assume jpackage did. >> >> Could it be the missing windows start menu item be affected by the >> location of the main class?? In my case, it isn't in the main jar. In >> fact, the main jar is empty except for the manifest, which contains >> only the manifest version declaration. The main class is located in >> one of the other jar files, which are correctly included in the >> resulting image and installer. The .cfg correctly includes those JARs >> on the classpath (and it all works fine when installed). I don't >> really see how that should affect the creation of a shortcut to the >> .exe, but thought I would mention it. >> >> TIA! >> Chris >> >> >> >> On Thu, Sep 12, 2019 at 10:34 AM Andy Herrick >> > wrote: >> >> ??? Strange ... >> >> ??? I can't seem to reproduce any scenario where msi installer >> created by >> ??? jpackage won't install a shortcut, but from the message: >> >> ??? "Multiple launchers found in predefined app-image. jvm will be >> ??? used as >> ??? primary launcher." >> >> ??? It seems that? you are using a predefined app-image? and there are >> ??? multiple launchers in the app-image, and the code is choosing >> ??? "jvm" as >> ??? the primary one (the one a shortcut will be created for). >> >> ??? This may be the wrong launcher.? When an installer is built for an >> ??? existing app-image, it doesn't know the name of the app, it looks >> for >> ??? the config file? in /app/ >> >> ??? If there are multiple cfg files (like you built the app-image with >> ??? --add-launcher jvm=jvm-launcher.properties) it is just taking the >> ??? first one. >> >> ??? Is it possible this is what is happening in your case ? >> >> ??? /Andy >> >> ??? On 9/12/2019 9:54 AM, Christopher Merrill wrote: >> ??? > I am using build 14-jpackage+1-35 with WiX 3.11.1.2318 to build >> ??? an MSI >> ??? > installer. If I am understanding the comments in thread "RFR: >> ??? JDK-8229779: >> ??? > Shortcut creation policy", a start menu entry (and desktop >> ??? shortcut?) >> ??? > should always be produced with this version of jpackage command >> line >> ??? > options? The MSI installer I've created does not create a start >> ??? menu entry, >> ??? > even when I include the --win-menu option. Other people seem to >> ??? have the >> ??? > opposite problem (start menu item when they don't want it), so >> ??? clearly I'm >> ??? > doing something wrong... >> ??? > >> ??? > C:\Apps\OpenJDKs\jdk-14/bin/jpackage --package-type msi --output >> ??? > D:\Work\MuseProject\ide\closed\install\build\jpackage --name >> ??? > MuseIDE-launcher --app-image >> ??? > >> D:\Work\MuseProject\ide\closed\install\build\jpackage/MuseIDE-launcher >> ??? > --win-per-user-install --win-menu --app-version 3.1 --name >> ??? MuseIDE-Launcher >> ??? > >> ??? > Other than this message, which I assume is a warning, the >> ??? execution is >> ??? > successful: >> ??? >? ? Multiple launchers found in predefined app-image. jvm will be >> ??? used as >> ??? > primary launcher. >> ??? > >> ??? > Are there other options that would influence getting a start >> ??? menu item >> ??? > added by the installer? >> ??? > >> ??? > FWIW, I am using gradle with the org.beryx.runtime plugin to >> ??? create the >> ??? > image and installer. Are there settings/options/stuff in the >> ??? image that >> ??? > would affect creation of the start menu item? >> ??? > >> ??? > TIA! >> ??? > Chris >> ??? > >> >> >> >> -- >> ????o ?? llo? 's??? p??? u?? no? ?? From naoto.sato at oracle.com Thu Sep 12 16:42:51 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 12 Sep 2019 09:42:51 -0700 Subject: RFR: 8223490: Optimize search algorithm for determining default time zone In-Reply-To: References: Message-ID: Hi Se?n, I like your approach to provide the fast path to determine the system time zone. One general question is, is UTC/GMT the right set of fast path candidates? Should we add some more common ones? Other comments to the code: TimeZone_md.c - Should fast path search come after "dir" validation, i.e., line 146-148? - Line 126: "statbuf" can be removed. - Line 134: 'i' is not size_of_something, so 'int' type should suffice (and its initialization is done in the for-loop). - Line 138: the fast path search should "continue" with the next name, instead of "break". - Line 142, 182: I'd wrap this line with parens for the if statement. - Line 232-242: "pathname" is an argument to this function, so freeing it inside the function seems odd. Also, no need to reset dbuf/fd since they are no longer reused in the loop. Naoto On 9/11/19 3:50 AM, Se?n Coffey wrote: > The current algorithm for determining the default timezone on (non-AIX) > unix systems goes something like : > > 1. If TZ environment variable is defined, use it > 2. else if /etc/timezone exists, use the value contained within it > 3. else if /etc/localtime exists and is a symbolic link, use the name > pointed to > 4. else if /etc/localtime is a binary, find the first identical time > zone binary file in /usr/share/zoneinfo/ > > Step 4 is a bit crude in that the zoneinfo directory can contain over > 1,800 files on today's systems. I'd like to change the logic so that > common timezones are first checked for buffer matching before a full > directory traversal is performed. It should be a performance gain and it > should also lead to more consistent results for reasons outlined in the > bug report. > > https://bugs.openjdk.java.net/browse/JDK-8223490 > webrev: http://cr.openjdk.java.net/~coffeys/webrev.8223490/webrev/ > > From daniel.fuchs at oracle.com Thu Sep 12 17:35:38 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 12 Sep 2019 18:35:38 +0100 Subject: RFR [14] 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect In-Reply-To: <20190912122656.GA13233@vimes> References: <1A766DB0-E937-438A-BDE1-26DC29FC25EC@oracle.com> <0911E28D-E382-4A0E-A7DB-F775C522BFB4@oracle.com> <564053B0-6FC9-468A-B75D-94F796015BB6@oracle.com> <20190912122656.GA13233@vimes> Message-ID: Hi Pavel, The changes in webrev.02 look good to me as well. Thanks for renaming the constants in the test (I mean TOLERANCE vs RIGHT_MARGIN and LEFT_MARGIN) - that makes for a much better read. best regards, -- daniel On 12/09/2019 13:26, Rob McKenna wrote: > Here's the updated version of the RFR based on the discussion so far: > > http://cr.openjdk.java.net/~prappo/8151678/webrev.02/ > > For the reviewers. I totally forgot to explain why there's a multiplier of 2 in some of the timeout calculations. The reason is the current behavior of InitialDirContext. The supplied connect timeout seems to be used twice. Once for making the actual TCP connection [1] and the second time while waiting for the server to respond to the BIND message [2]. Thus, the total time spent in that InitialDirContext ctor may be twice the expected. I believe it's a bug, but the bug that is not related to the issue in question. The current issue (8151678) is about intermittent failures of LdapTimeoutTest. > > -Pavel > > --------------------------------------------------- > [1]http://hg.openjdk.java.net/jdk/jdk/file/79186d82463e/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#l296,http://hg.openjdk.java.net/jdk/jdk/file/79186d82463e/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#l320 > [2]http://hg.openjdk.java.net/jdk/jdk/file/79186d82463e/src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java#l154,http://hg.openjdk.java.net/jdk/jdk/file/79186d82463e/src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java#l365 > From Roger.Riggs at oracle.com Thu Sep 12 17:47:57 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 12 Sep 2019 13:47:57 -0400 Subject: RFR: 8223490: Optimize search algorithm for determining default time zone In-Reply-To: References: Message-ID: <22036f17-ef74-e79b-be17-978bbe18bcb2@oracle.com> Hi Sean, In addition to Naoto's comments. The change to TimeZone_md.h should not be needed. A 'static' declaration doesn't need to be visible outside its source file. Roger On 9/12/19 12:42 PM, naoto.sato at oracle.com wrote: > Hi Se?n, > > I like your approach to provide the fast path to determine the system > time zone. One general question is, is UTC/GMT the right set of fast > path candidates? Should we add some more common ones? > > Other comments to the code: > > TimeZone_md.c > > - Should fast path search come after "dir" validation, i.e., line > 146-148? > - Line 126: "statbuf" can be removed. > - Line 134: 'i' is not size_of_something, so 'int' type should suffice > (and its initialization is done in the for-loop). > - Line 138: the fast path search should "continue" with the next name, > instead of "break". > - Line 142, 182: I'd wrap this line with parens for the if statement. > - Line 232-242: "pathname" is an argument to this function, so freeing > it inside the function seems odd. Also, no need to reset dbuf/fd since > they are no longer reused in the loop. > > Naoto > > On 9/11/19 3:50 AM, Se?n Coffey wrote: >> The current algorithm for determining the default timezone on >> (non-AIX) unix systems goes something like : >> >> 1. If TZ environment variable is defined, use it >> 2. else if /etc/timezone exists, use the value contained within it >> 3. else if /etc/localtime exists and is a symbolic link, use the name >> pointed to >> 4. else if /etc/localtime is a binary, find the first identical time >> zone binary file in /usr/share/zoneinfo/ >> >> Step 4 is a bit crude in that the zoneinfo directory can contain over >> 1,800 files on today's systems. I'd like to change the logic so that >> common timezones are first checked for buffer matching before a full >> directory traversal is performed. It should be a performance gain and >> it should also lead to more consistent results for reasons outlined >> in the bug report. >> >> https://bugs.openjdk.java.net/browse/JDK-8223490 >> webrev: http://cr.openjdk.java.net/~coffeys/webrev.8223490/webrev/ >> >> From pavel.rappo at oracle.com Thu Sep 12 17:51:42 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 12 Sep 2019 18:51:42 +0100 Subject: RFR [14] 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect In-Reply-To: References: <97114AA9-A44A-4C36-843C-1E6933348096@oracle.com> <026e37eb-3da6-5f39-ac8d-99ad26bba3d0@oracle.com> <81060A81-D77F-4F49-A131-DE79F66FE29B@oracle.com> <6db710f3-dff6-f6ea-5922-242516769ed8@oracle.com> <1A766DB0-E937-438A-BDE1-26DC29FC25EC@oracle.com> <0911E28D-E382-4A0E-A7DB-F775C522BFB4@oracle.com> <564053B0-6FC9-468A-B75D-94F796015BB6@oracle.com> Message-ID: <22B6F989-D0D7-4055-B43D-248576CF3C13@oracle.com> Martin, May I add you to the list of people who reviewed this change? I mean the concurrency-related portion of the change, specifically in the test. Not the LDAP part. > On 12 Sep 2019, at 16:21, Martin Buchholz wrote: > > > > On Thu, Sep 12, 2019 at 4:36 AM Pavel Rappo wrote: > > I should have expressed myself more clear. I meant that the main thread and the thread created (and started) by `newStartedThread` (the test tread) do not wait for *each other* before they begin. This might be needed to make sure that they start at the same time (loosely speaking, of course). One might argue that the importance of this diminishes with the increase of the timeout that the main thread uses to wait for the test thread to die and the accuracy of measurements one agrees to tolerate. > > > You want coordination? We got coordination. > > Here's some infrastructure that uses a threadsStarted latch: > > void assertThrowInterruptedExceptionWhenInterrupted(Action[] actions) { > int n = actions.length; > Future[] futures = new Future[n]; > CountDownLatch threadsStarted = new CountDownLatch(n); > CountDownLatch done = new CountDownLatch(n); > > for (int i = 0; i < n; i++) { > Action action = actions[i]; > futures[i] = cachedThreadPool.submit(new CheckedRunnable() { > public void realRun() throws Throwable { > threadsStarted.countDown(); > try { > action.run(); > shouldThrow(); > } > catch (InterruptedException success) {} > catch (Throwable fail) { threadUnexpectedException(fail); } > assertFalse(Thread.interrupted()); > done.countDown(); > }}); > } > > await(threadsStarted); > assertEquals(n, done.getCount()); > for (Future future : futures) // Interrupt all the tasks > future.cancel(true); > await(done); > } > > When communicating a request, just like in real life, you can't force others to do anything, so be politely Canadian and use "please" in the name of your latch > > /** > * await throws InterruptedException if interrupted before counted down > */ > public void testAwait_Interruptible() { > final CountDownLatch l = new CountDownLatch(1); > final CountDownLatch pleaseInterrupt = new CountDownLatch(1); > Thread t = newStartedThread(new CheckedRunnable() { > public void realRun() throws InterruptedException { > Thread.currentThread().interrupt(); > try { > l.await(); > shouldThrow(); > } catch (InterruptedException success) {} > assertFalse(Thread.interrupted()); > > pleaseInterrupt.countDown(); > try { > l.await(); > shouldThrow(); > } catch (InterruptedException success) {} > assertFalse(Thread.interrupted()); > > assertEquals(1, l.getCount()); > }}); > > await(pleaseInterrupt); > if (randomBoolean()) assertThreadBlocks(t, Thread.State.WAITING); > t.interrupt(); > awaitTermination(t); > } > From martinrb at google.com Thu Sep 12 17:55:39 2019 From: martinrb at google.com (Martin Buchholz) Date: Thu, 12 Sep 2019 10:55:39 -0700 Subject: RFR [14] 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect In-Reply-To: <22B6F989-D0D7-4055-B43D-248576CF3C13@oracle.com> References: <97114AA9-A44A-4C36-843C-1E6933348096@oracle.com> <026e37eb-3da6-5f39-ac8d-99ad26bba3d0@oracle.com> <81060A81-D77F-4F49-A131-DE79F66FE29B@oracle.com> <6db710f3-dff6-f6ea-5922-242516769ed8@oracle.com> <1A766DB0-E937-438A-BDE1-26DC29FC25EC@oracle.com> <0911E28D-E382-4A0E-A7DB-F775C522BFB4@oracle.com> <564053B0-6FC9-468A-B75D-94F796015BB6@oracle.com> <22B6F989-D0D7-4055-B43D-248576CF3C13@oracle.com> Message-ID: On Thu, Sep 12, 2019 at 10:53 AM Pavel Rappo wrote: > Martin, > > May I add you to the list of people who reviewed this change? I mean the > concurrency-related portion of the change, specifically in the test. Not > the LDAP part. > Sure! From chris.l.merrill at gmail.com Thu Sep 12 18:04:42 2019 From: chris.l.merrill at gmail.com (Christopher Merrill) Date: Thu, 12 Sep 2019 14:04:42 -0400 Subject: Feedback JEP 343: jpackage --win-menu In-Reply-To: References: <96d88a7d-e256-6fbf-5d6a-1ffee4c97835@oracle.com> Message-ID: On Thu, Sep 12, 2019 at 11:28 AM Andy Herrick wrote: > yes - clearly something wrong here - it is supposed to find > MuseIDE-launcher.cfg and create shortcut to MuseIDE-launcher - but it has > come up with jvm.cfg - a completely unrelated file. > > lets see - your input dir is the lib dir of your runtime-image. the app > dir will be populated with everything in the input dir, so it gets jvm.cfg > which is in every runtime's lib dir. > > Not sure why you want to do this, but I think it points out we should not > be satisfied that a file has extension "cfg", we should also look at it and > confirm it looks like a valid jpackage app-image .cfg file, before > deriving the name of the app from the name of the cfg file. > It is entirely possible I *don't* want to do that. I'm admittedly a newbie on this. I'm upgrading an app that used the old packager, via a Gradle plugin, to bundles our app. I'm using a new gradle plugin that is likely less finished, since jpackager is so new :) I've been using https://bugs.openjdk.java.net/browse/JDK-8200758 as a reference, but it is not clear what is and is not yet implemented, thus far. Is there a better source for current docs? What should the input dir point to? Perhaps just the lib folder of my distribution, which contains all the JARs? (I don't need command-line launchers). Thanks again! Chris > /Andy > On 9/12/2019 11:08 AM, Christopher Merrill wrote: > > Thanks Andy. > > Ok, so the image was created in the previous step using: > C:\Apps\OpenJDKs\jdk-14/bin/jpackage.exe --input > D:\Work\MuseProject\ide\closed\install\build\image\lib --main-jar > MuseIDE-launcher-3.1.jar --main-class org.musetest.ide.launcher.Bootstrap > --output D:\Work\MuseProject\ide\closed\install\build\jpackage --name > MuseIDE-launcher --identifier org.musetest.ide.launcher.Bootstrap > --runtime-image D:\Work\MuseProject\ide\closed\install\build\image > > There is only one .cfg file in the .../build/image folder, 'jvm.cfg', > which contains: > -server KNOWN > -client IGNORE > > However, the output folder (../build/jpackage/MuseIDE-launcher/app) of the > second jpackage step which I referenced in the previous message contains a > MuseIDE-launcher.cfg file with: > [Application] > app.name=MuseIDE-launcher > app.version=1.0 > app.runtime=$APPDIR\runtime > app.identifier=org.musetest.ide.launcher.Bootstrap > > app.classpath=$APPDIR\app\MuseIDE-launcher-3.1.jar;$APPDIR\app\dynamic-classloader-0.2.jar;$APPDIR\app\IdeLaunchUpdate-2.3.jar;$APPDIR\app\jrt-fs.jar;$APPDIR\app\update4j-1.2.2.jar > app.mainjar=$APPDIR\app\MuseIDE-launcher-3.1.jar > app.mainclass=org.musetest.ide.launcher.Bootstrap > [JavaOptions] > [ArgOptions] > > I didn't create or supply that file...so I assume jpackage did. > > Could it be the missing windows start menu item be affected by the > location of the main class? In my case, it isn't in the main jar. In fact, > the main jar is empty except for the manifest, which contains only the > manifest version declaration. The main class is located in one of the other > jar files, which are correctly included in the resulting image and > installer. The .cfg correctly includes those JARs on the classpath (and it > all works fine when installed). I don't really see how that should affect > the creation of a shortcut to the .exe, but thought I would mention it. > > TIA! > Chris > > > > On Thu, Sep 12, 2019 at 10:34 AM Andy Herrick > wrote: > >> Strange ... >> >> I can't seem to reproduce any scenario where msi installer created by >> jpackage won't install a shortcut, but from the message: >> >> "Multiple launchers found in predefined app-image. jvm will be used as >> primary launcher." >> >> It seems that you are using a predefined app-image and there are >> multiple launchers in the app-image, and the code is choosing "jvm" as >> the primary one (the one a shortcut will be created for). >> >> This may be the wrong launcher. When an installer is built for an >> existing app-image, it doesn't know the name of the app, it looks for >> the config file in /app/ >> >> If there are multiple cfg files (like you built the app-image with >> --add-launcher jvm=jvm-launcher.properties) it is just taking the first >> one. >> >> Is it possible this is what is happening in your case ? >> >> /Andy >> >> On 9/12/2019 9:54 AM, Christopher Merrill wrote: >> > I am using build 14-jpackage+1-35 with WiX 3.11.1.2318 to build an MSI >> > installer. If I am understanding the comments in thread "RFR: >> JDK-8229779: >> > Shortcut creation policy", a start menu entry (and desktop shortcut?) >> > should always be produced with this version of jpackage command line >> > options? The MSI installer I've created does not create a start menu >> entry, >> > even when I include the --win-menu option. Other people seem to have the >> > opposite problem (start menu item when they don't want it), so clearly >> I'm >> > doing something wrong... >> > >> > C:\Apps\OpenJDKs\jdk-14/bin/jpackage --package-type msi --output >> > D:\Work\MuseProject\ide\closed\install\build\jpackage --name >> > MuseIDE-launcher --app-image >> > D:\Work\MuseProject\ide\closed\install\build\jpackage/MuseIDE-launcher >> > --win-per-user-install --win-menu --app-version 3.1 --name >> MuseIDE-Launcher >> > >> > Other than this message, which I assume is a warning, the execution is >> > successful: >> > Multiple launchers found in predefined app-image. jvm will be used as >> > primary launcher. >> > >> > Are there other options that would influence getting a start menu item >> > added by the installer? >> > >> > FWIW, I am using gradle with the org.beryx.runtime plugin to create the >> > image and installer. Are there settings/options/stuff in the image that >> > would affect creation of the start menu item? >> > >> > TIA! >> > Chris >> > >> > > > -- > ????o ?? llo? 's??? p??? u?? no? ?? > > -- ????o ?? llo? 's??? p??? u?? no? ?? From ivan.gerasimov at oracle.com Thu Sep 12 18:37:32 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 12 Sep 2019 11:37:32 -0700 Subject: RFR 8230829 : Matcher matches a surrogate pair that crosses border of the region In-Reply-To: <6f948520-17f5-0f5e-5fb7-01b6f5670c63@oracle.com> References: <5ab65db6-701a-937e-e93c-6ee4ef6fd159@oracle.com> <6f948520-17f5-0f5e-5fb7-01b6f5670c63@oracle.com> Message-ID: Thank you Naoto for reviewing! With kind regards, Ivan On 9/12/19 8:02 AM, naoto.sato at oracle.com wrote: > Looks good to me, Ivan. > > Naoto > > On 9/10/19 9:13 PM, Ivan Gerasimov wrote: >> Hello! >> >> When the regex.Matcher matches a supplementary codepoint, it may >> inadvertently cross the border of the explicitly specified region >> without noticing. >> >> Would you please help review a simple fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8230829 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8230829/00/webrev/ >> >> Thanks in advance! >> > -- With kind regards, Ivan Gerasimov From Alan.Bateman at oracle.com Thu Sep 12 19:06:56 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 12 Sep 2019 20:06:56 +0100 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: <4CAC6E8D-9198-4701-99C0-49901D72A396@oracle.com> References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> <87sgpblxns.fsf@oldenburg2.str.redhat.com> <7A46485C-E250-4E57-9FB0-B9D18CA70632@oracle.com> <60FD933F-51A5-4438-83AF-B3427CFDE60D@oracle.com> <8A9E3066-E6F6-4E65-BD02-DF0ACFF02FAD@oracle.com> <633A0CE3-C771-493B-89E3-7FA843C85183@oracle.com> <6b209e36-686f-7852-7fb8-3a0ef0e8423a@oracle.com> <4CAC6E8D-9198-4701-99C0-49901D72A396@oracle.com> Message-ID: <47acbb78-806f-2951-3b22-de6e7965f461@oracle.com> On 12/09/2019 12:41, Chris Hegarty wrote: > Here is an initial attempt to document these timeout/retry properties. > It?s effectively the wording lifted from the tech notes [1], with > ?UDP? removed. Thanks, this look and dropping the reference to "UDP" make sense. One minor nit is that "are relevant to the DNSprovider" might be better worded as "may be used when creating the initial context". This will fit nicely if/when someone adds a description to the @provides tag. At some point I hope the other properties can be used too but that is beyond the scope of JDK-8228580. -Alan From naoto.sato at oracle.com Thu Sep 12 20:24:38 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 12 Sep 2019 13:24:38 -0700 Subject: 8229471: Calendar under a specific timezone changes HOUR field when MILLISECOND field is changed In-Reply-To: <3A451B05B742C24B92BEAC7B802BC85C2A0A626C@g01jpexmbkw06> References: <3A451B05B742C24B92BEAC7B802BC85C2A0A626C@g01jpexmbkw06> Message-ID: <6bcfefbe-ffb9-a33d-23c3-3bffbae7dbbb@oracle.com> Hi Masanori, Thank you for looking at the issue and your contribution. I am also investigating it (as an assignee of the bug), and looking at this old issue: https://bugs.openjdk.java.net/browse/JDK-4177484 The comment suggests that the existing behavior is the expected one. In fact, your fix would break some regression test cases in jdk/java/util/Calendar/CalendarRegression.java. I will need some more archaeological investigation, but I am inclined to close it as not an issue at the moment. Naoto On 9/12/19 12:16 AM, Yano, Masanori wrote: > Hello. > > I think JDK-8229471 occurs because a change of TimeZone is not considered in getTime(). > To resolve this problem, isTimeSet flag must be set to false when setTimeZone() is called. > > Please review the following change. > > diff -r e1269de19aa5 src/java.base/share/classes/java/util/Calendar.java > --- a/src/java.base/share/classes/java/util/Calendar.java Thu Aug 22 14:09:36 2019 -0700 > +++ b/src/java.base/share/classes/java/util/Calendar.java Thu Sep 12 11:45:37 2019 +0900 > @@ -2901,7 +2901,7 @@ > * generally, a call to setTimeZone() affects calls to set() BEFORE AND > * AFTER it up to the next call to complete(). > */ > - areAllFieldsSet = areFieldsSet = false; > + isTimeSet = areAllFieldsSet = areFieldsSet = false; > } > > /** > diff -r e1269de19aa5 test/jdk/java/util/Calendar/Bug8229471.java > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/test/jdk/java/util/Calendar/Bug8229471.java Thu Sep 12 11:45:37 2019 +0900 > @@ -0,0 +1,22 @@ > +/* > + *@test > + *@bug 8229471 > + *@summary test for recompute when Calendar.setTimeZone() > + */ > + > +import java.util.Calendar; > +import java.util.Date; > +import java.util.Locale; > +import java.util.TimeZone; > + > +public class Bug8229471 { > + public static void main(String[] args) throws Exception { > + Calendar calendar = Calendar.getInstance(new Locale("en", "US")); > + Date date1 = calendar.getTime(); > + calendar.setTimeZone(TimeZone.getTimeZone("Europe/Budapest")); > + Date date2 = calendar.getTime(); > + if (date1.equals(date2)) { > + throw new RuntimeException("Bug8229471: failed. TimeZone is not applied."); > + } > + } > +} > > Regards, > Masanori Yano > From alexander.matveev at oracle.com Thu Sep 12 21:29:03 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Thu, 12 Sep 2019 14:29:03 -0700 Subject: RFR: JDK-8229779: Shortcut creation policy In-Reply-To: References: <583dc9b6-6b2b-a04b-f209-9ce2a851d007@oracle.com> <22a04895-ff64-55ad-963f-26d49e11a0a8@oracle.com> Message-ID: Looks good. Thanks, Alexander On 9/12/2019 4:11 AM, Andy Herrick wrote: > Revised with webrev.03. > > Changed SimplePackageTest instructions as suggested and added > LinuxDebBundler.java to file list (double checked file list used to > create webrev contains all changed files). > > /ANdy > > On 9/11/2019 10:09 PM, Alexey Semenyuk wrote: >> SimplePackageTest.java: >> I'd suggest to put "Installer should not create any shortcuts" in the >> description or simply remove notice about shortcuts. >> >> Did you omit adding shortcuts to LinuxDebBundler.java on purpose? >> >> - Alexey >> >> On 9/11/2019 9:07 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 fix: >>> >>> 1.) adds the new option --linux-shortcut, and now only creates a >>> shortcut on linux if specified >>> >>> 2.) only creates a shortcut on windows if win-menu or win-shortcut >>> is specified. >>> >>> /Andy >>> >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8229779 >>> >>> [2] http://cr.openjdk.java.net/~herrick/8229779 >>> >> From alexander.matveev at oracle.com Thu Sep 12 21:44:54 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Thu, 12 Sep 2019 14:44:54 -0700 Subject: RFR: JDK-8230629: jpackage signing on macOS does not work as expected In-Reply-To: <11e4701f-4b6e-19a3-81e7-bd28dbace273@oracle.com> References: <943112e8-922f-b711-887d-ce157463881f@oracle.com> <11e4701f-4b6e-19a3-81e7-bd28dbace273@oracle.com> Message-ID: Hi Alexey, http://cr.openjdk.java.net/~almatvee/8230629/webrev.01 I simplified isFileSigned() as you suggested. Thanks, Alexander On 9/12/2019 4:13 AM, Alexey Semenyuk wrote: > Looks good, though > --- > List args = new ArrayList<>(); > ?940???????? args.addAll(Arrays.asList("codesign", > ?941???????????????? "--verify", > ?942???????????????? file.toString())); > ?943 > ?944???????? ProcessBuilder pb > ?945???????????????? = new ProcessBuilder(args.toArray(new > String[args.size()])); > --- > > can be as simple as: > --- > ProcessBuilder pb = new ProcessBuilder("codesign", "--verify", > file.toString()); > --- > > - Alexey > > On 9/11/2019 11:53 PM, Alexander Matveev wrote: >> Please review the jpackage fix for bug [1] at [2]. >> >> This is a fix for the JDK-8200758-branch branch of the open sandbox >> repository (jpackage). >> >> - Binaries in runtime and Frameworks will not be signed directly >> using user provided certificate. >> - libapplauncher.dylib will be signed with user provided certificate >> only if it is unsigned. >> - When signing is enabled app and pkg will be signed, but not dmg. >> App inside pkg and dmg will be signed as well. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8230629 >> >> [2] http://cr.openjdk.java.net/~almatvee/8230629/webrev.00/ >> >> Thanks, >> Alexander > From alexey.semenyuk at oracle.com Thu Sep 12 21:57:57 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Thu, 12 Sep 2019 17:57:57 -0400 Subject: RFR: JDK-8230629: jpackage signing on macOS does not work as expected In-Reply-To: References: <943112e8-922f-b711-887d-ce157463881f@oracle.com> <11e4701f-4b6e-19a3-81e7-bd28dbace273@oracle.com> Message-ID: Thank you, looks good. - Alexey On 9/12/2019 5:44 PM, Alexander Matveev wrote: > Hi Alexey, > > http://cr.openjdk.java.net/~almatvee/8230629/webrev.01 > I simplified isFileSigned() as you suggested. > > Thanks, > Alexander > > On 9/12/2019 4:13 AM, Alexey Semenyuk wrote: >> Looks good, though >> --- >> List args = new ArrayList<>(); >> ?940???????? args.addAll(Arrays.asList("codesign", >> ?941???????????????? "--verify", >> ?942???????????????? file.toString())); >> ?943 >> ?944???????? ProcessBuilder pb >> ?945???????????????? = new ProcessBuilder(args.toArray(new >> String[args.size()])); >> --- >> >> can be as simple as: >> --- >> ProcessBuilder pb = new ProcessBuilder("codesign", "--verify", >> file.toString()); >> --- >> >> - Alexey >> >> On 9/11/2019 11:53 PM, Alexander Matveev wrote: >>> Please review the jpackage fix for bug [1] at [2]. >>> >>> This is a fix for the JDK-8200758-branch branch of the open sandbox >>> repository (jpackage). >>> >>> - Binaries in runtime and Frameworks will not be signed directly >>> using user provided certificate. >>> - libapplauncher.dylib will be signed with user provided certificate >>> only if it is unsigned. >>> - When signing is enabled app and pkg will be signed, but not dmg. >>> App inside pkg and dmg will be signed as well. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8230629 >>> >>> [2] http://cr.openjdk.java.net/~almatvee/8230629/webrev.00/ >>> >>> Thanks, >>> Alexander >> > From andy.herrick at oracle.com Thu Sep 12 22:27:59 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Thu, 12 Sep 2019 18:27:59 -0400 Subject: RFR: JDK-8230629: jpackage signing on macOS does not work as expected In-Reply-To: References: <943112e8-922f-b711-887d-ce157463881f@oracle.com> <11e4701f-4b6e-19a3-81e7-bd28dbace273@oracle.com> Message-ID: <88ce01d0-a8eb-09f7-702c-89fd7463c2b5@oracle.com> looks good. /Andy On 9/12/2019 5:44 PM, Alexander Matveev wrote: > Hi Alexey, > > http://cr.openjdk.java.net/~almatvee/8230629/webrev.01 > I simplified isFileSigned() as you suggested. > > Thanks, > Alexander > > On 9/12/2019 4:13 AM, Alexey Semenyuk wrote: >> Looks good, though >> --- >> List args = new ArrayList<>(); >> ?940???????? args.addAll(Arrays.asList("codesign", >> ?941???????????????? "--verify", >> ?942???????????????? file.toString())); >> ?943 >> ?944???????? ProcessBuilder pb >> ?945???????????????? = new ProcessBuilder(args.toArray(new >> String[args.size()])); >> --- >> >> can be as simple as: >> --- >> ProcessBuilder pb = new ProcessBuilder("codesign", "--verify", >> file.toString()); >> --- >> >> - Alexey >> >> On 9/11/2019 11:53 PM, Alexander Matveev wrote: >>> Please review the jpackage fix for bug [1] at [2]. >>> >>> This is a fix for the JDK-8200758-branch branch of the open sandbox >>> repository (jpackage). >>> >>> - Binaries in runtime and Frameworks will not be signed directly >>> using user provided certificate. >>> - libapplauncher.dylib will be signed with user provided certificate >>> only if it is unsigned. >>> - When signing is enabled app and pkg will be signed, but not dmg. >>> App inside pkg and dmg will be signed as well. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8230629 >>> >>> [2] http://cr.openjdk.java.net/~almatvee/8230629/webrev.00/ >>> >>> Thanks, >>> Alexander >> > From brent.christian at oracle.com Thu Sep 12 23:02:53 2019 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 12 Sep 2019 16:02:53 -0700 Subject: RFR 8230937 : Update bugid in ProblemList for vmTestbase/nsk/jdb/eval/eval001/eval001.java Message-ID: <17152ac6-6902-f56e-a187-0ce0d4662391@oracle.com> Hi, From the bug report: "The ProblemList indicates that vmTestbase/nsk/jdb/eval/eval001/eval001.java was added due to JDK-8212117. That bug has been fixed, but this test still fails. That line in the ProblemList should instead use 8221503." The change is: diff -r 85e1de070bef test/hotspot/jtreg/ProblemList.txt --- a/test/hotspot/jtreg/ProblemList.txt Thu Sep 12 09:59:19 2019 -0700 +++ b/test/hotspot/jtreg/ProblemList.txt Thu Sep 12 15:52:07 2019 -0700 @@ -167,7 +167,7 @@ vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java 8065773 generic-all -vmTestbase/nsk/jdb/eval/eval001/eval001.java 8212117 generic-all +vmTestbase/nsk/jdb/eval/eval001/eval001.java 8221503 generic-all vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 generic-all Thanks, -Brent From mandy.chung at oracle.com Fri Sep 13 00:30:19 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 12 Sep 2019 17:30:19 -0700 Subject: RFR 8230937 : Update bugid in ProblemList for vmTestbase/nsk/jdb/eval/eval001/eval001.java In-Reply-To: <17152ac6-6902-f56e-a187-0ce0d4662391@oracle.com> References: <17152ac6-6902-f56e-a187-0ce0d4662391@oracle.com> Message-ID: +1 Mandy On 9/12/19 4:02 PM, Brent Christian wrote: > Hi, > > From the bug report: > > "The ProblemList indicates that > vmTestbase/nsk/jdb/eval/eval001/eval001.java was added due to > JDK-8212117. That bug has been fixed, but this test still fails. That > line in the ProblemList should instead use 8221503." > > The change is: > > diff -r 85e1de070bef test/hotspot/jtreg/ProblemList.txt > --- a/test/hotspot/jtreg/ProblemList.txt??? Thu Sep 12 09:59:19 2019 > -0700 > +++ b/test/hotspot/jtreg/ProblemList.txt??? Thu Sep 12 15:52:07 2019 > -0700 > @@ -167,7 +167,7 @@ > > vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java > 8065773 generic-all > > -vmTestbase/nsk/jdb/eval/eval001/eval001.java 8212117 generic-all > +vmTestbase/nsk/jdb/eval/eval001/eval001.java 8221503 generic-all > > ?vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 > generic-all > > Thanks, > -Brent From david.holmes at oracle.com Fri Sep 13 01:04:50 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Sep 2019 11:04:50 +1000 Subject: RFR 8230937 : Update bugid in ProblemList for vmTestbase/nsk/jdb/eval/eval001/eval001.java In-Reply-To: <17152ac6-6902-f56e-a187-0ce0d4662391@oracle.com> References: <17152ac6-6902-f56e-a187-0ce0d4662391@oracle.com> Message-ID: <1179284f-d71e-1e89-b243-635e0fc152cd@oracle.com> Looks good. Thanks for updating. David On 13/09/2019 9:02 am, Brent Christian wrote: > Hi, > > From the bug report: > > "The ProblemList indicates that > vmTestbase/nsk/jdb/eval/eval001/eval001.java was added due to > JDK-8212117. That bug has been fixed, but this test still fails. That > line in the ProblemList should instead use 8221503." > > The change is: > > diff -r 85e1de070bef test/hotspot/jtreg/ProblemList.txt > --- a/test/hotspot/jtreg/ProblemList.txt??? Thu Sep 12 09:59:19 2019 -0700 > +++ b/test/hotspot/jtreg/ProblemList.txt??? Thu Sep 12 15:52:07 2019 -0700 > @@ -167,7 +167,7 @@ > > vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java > 8065773 generic-all > > -vmTestbase/nsk/jdb/eval/eval001/eval001.java 8212117 generic-all > +vmTestbase/nsk/jdb/eval/eval001/eval001.java 8221503 generic-all > > ?vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 > generic-all > > Thanks, > -Brent From alexander.matveev at oracle.com Fri Sep 13 01:34:32 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Thu, 12 Sep 2019 18:34:32 -0700 Subject: RFR: JDK-8230521: rename --output/-o option and add default value (".") 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). - Renamed "--output" to "--dest" and made it optional with default to ".". [1] https://bugs.openjdk.java.net/browse/JDK-8230521 [2] http://cr.openjdk.java.net/~almatvee/8230629/webrev.00/ Thanks, Alexander From alexey.semenyuk at oracle.com Fri Sep 13 02:47:10 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Thu, 12 Sep 2019 22:47:10 -0400 Subject: RFR: JDK-8230521: rename --output/-o option and add default value (".") In-Reply-To: References: Message-ID: <4e0a19fa-d1ed-0953-dc66-e1ffacb126a8@oracle.com> http://cr.openjdk.java.net/~almatvee/8230521/webrev.00/src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java.sdiff.html: --- 126???????? Path destPath = Paths.get(".").toAbsolutePath(); ?127???????? if (destPath.getFileName().toString().equals(".")) { ?128???????????? dest = destPath.getParent().toString(); ?129???????? } else { ?130???????????? dest = destPath.toString(); ?131???????? } --- Are you trying to get rid of trailing "." path component in the above code fragment? If yes, then this can be simplified as follows: --- Path destPath = Paths.get(".").normalize().toAbsolutePath(); --- In general I don't like the idea of renaming variables and method names from `output` to `dest`. This doesn't add much value to the code and is incomplete and thus confusing (e.g.: in all the tests OUTPUT variable remains unnamed). I suggest to change only `--output` to `--dest` tokens in the code. Slightly unrelated thing. macOS tests --- test/jdk/tools/jpackage/macosx/base/Base.java test/jdk/tools/jpackage/macosx/base/FileAssociationsBase.java test/jdk/tools/jpackage/macosx/base/InstallDirBase.java test/jdk/tools/jpackage/macosx/base/LicenseBase.java --- duplicate corresponding shared tests that have been added in the patch for https://bugs.openjdk.java.net/browse/JDK-8230726. I didn't touch them as I didn't have MAC to try the replacements. Could you please just drop these obsolete tests and also run the new tests to make sure they work as expected. I mean not just run the tests to create package bundles, but also install these bundles and run the tests in a mode when they verify packages are properly installed. - Alexey On 9/12/2019 9:34 PM, Alexander Matveev wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > - Renamed "--output" to "--dest" and made it optional with default to > ".". > > [1] https://bugs.openjdk.java.net/browse/JDK-8230521 > > [2] http://cr.openjdk.java.net/~almatvee/8230629/webrev.00/ > > Thanks, > Alexander From alexey.semenyuk at oracle.com Fri Sep 13 03:16:08 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Thu, 12 Sep 2019 23:16:08 -0400 Subject: RFR: JDK-8230521: rename --output/-o option and add default value (".") In-Reply-To: <4e0a19fa-d1ed-0953-dc66-e1ffacb126a8@oracle.com> References: <4e0a19fa-d1ed-0953-dc66-e1ffacb126a8@oracle.com> Message-ID: <773a5318-1dea-9f21-039d-29823b4dc7c8@oracle.com> On 9/12/2019 10:47 PM, Alexey Semenyuk wrote: > http://cr.openjdk.java.net/~almatvee/8230521/webrev.00/src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java.sdiff.html: > > --- > 126???????? Path destPath = Paths.get(".").toAbsolutePath(); > ?127???????? if (destPath.getFileName().toString().equals(".")) { > ?128???????????? dest = destPath.getParent().toString(); > ?129???????? } else { > ?130???????????? dest = destPath.toString(); > ?131???????? } > --- > Are you trying to get rid of trailing "." path component in the above > code fragment? If yes, then this can be simplified as follows: > --- > Path destPath = Paths.get(".").normalize().toAbsolutePath(); > --- Or even simpler: --- Path destPath = Paths.get("").toAbsolutePath(); --- - Alexey > > In general I don't like the idea of renaming variables and method > names from `output` to `dest`. This doesn't add much value to the code > and is incomplete and thus confusing (e.g.: in all the tests OUTPUT > variable remains unnamed). > I suggest to change only `--output` to `--dest` tokens in the code. > > Slightly unrelated thing. macOS tests > --- > test/jdk/tools/jpackage/macosx/base/Base.java > test/jdk/tools/jpackage/macosx/base/FileAssociationsBase.java > test/jdk/tools/jpackage/macosx/base/InstallDirBase.java > test/jdk/tools/jpackage/macosx/base/LicenseBase.java > --- > duplicate corresponding shared tests that have been added in the patch > for https://bugs.openjdk.java.net/browse/JDK-8230726. I didn't touch > them as I didn't have MAC to try the replacements. Could you please > just drop these obsolete tests and also run the new tests to make sure > they work as expected. I mean not just run the tests to create package > bundles, but also install these bundles and run the tests in a mode > when they verify packages are properly installed. > > - Alexey > > On 9/12/2019 9:34 PM, Alexander Matveev wrote: >> Please review the jpackage fix for bug [1] at [2]. >> >> This is a fix for the JDK-8200758-branch branch of the open sandbox >> repository (jpackage). >> >> - Renamed "--output" to "--dest" and made it optional with default to >> ".". >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8230521 >> >> [2] http://cr.openjdk.java.net/~almatvee/8230629/webrev.00/ >> >> Thanks, >> Alexander > From sean.coffey at oracle.com Fri Sep 13 08:32:00 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 13 Sep 2019 09:32:00 +0100 Subject: RFR: 8223490: Optimize search algorithm for determining default time zone In-Reply-To: References: Message-ID: <38fcea76-12c9-b2da-960a-118ed396c190@oracle.com> Thanks for the review Naoto. The edits certainly did need some tidying up. Comments inline. On 12/09/2019 17:42, naoto.sato at oracle.com wrote: > Hi Se?n, > > I like your approach to provide the fast path to determine the system > time zone. One general question is, is UTC/GMT the right set of fast > path candidates? Should we add some more common ones? > I'm open to suggestions. I think these two are very common and good for starting with. > Other comments to the code: > > TimeZone_md.c > > - Should fast path search come after "dir" validation, i.e., line > 146-148? > - Line 126: "statbuf" can be removed. > - Line 134: 'i' is not size_of_something, so 'int' type should suffice > (and its initialization is done in the for-loop). > - Line 138: the fast path search should "continue" with the next name, > instead of "break". > - Line 142, 182: I'd wrap this line with parens for the if statement. All above corrected. > - Line 232-242: "pathname" is an argument to this function, so freeing > it inside the function seems odd. Also, no need to reset dbuf/fd since > they are no longer reused in the loop. > I thought it was a useful approach given that it's the last function to use 'pathname'. However, it's not in keeping with normal design I guess. I've reverted and now free pathname at other call sites instead. new webrev at http://cr.openjdk.java.net/~coffeys/webrev.8223490.v2/webrev/ regards, Sean. > Naoto > > On 9/11/19 3:50 AM, Se?n Coffey wrote: >> The current algorithm for determining the default timezone on >> (non-AIX) unix systems goes something like : >> >> 1. If TZ environment variable is defined, use it >> 2. else if /etc/timezone exists, use the value contained within it >> 3. else if /etc/localtime exists and is a symbolic link, use the name >> pointed to >> 4. else if /etc/localtime is a binary, find the first identical time >> zone binary file in /usr/share/zoneinfo/ >> >> Step 4 is a bit crude in that the zoneinfo directory can contain over >> 1,800 files on today's systems. I'd like to change the logic so that >> common timezones are first checked for buffer matching before a full >> directory traversal is performed. It should be a performance gain and >> it should also lead to more consistent results for reasons outlined >> in the bug report. >> >> https://bugs.openjdk.java.net/browse/JDK-8223490 >> webrev: http://cr.openjdk.java.net/~coffeys/webrev.8223490/webrev/ >> >> From sean.coffey at oracle.com Fri Sep 13 08:34:31 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 13 Sep 2019 09:34:31 +0100 Subject: RFR: 8223490: Optimize search algorithm for determining default time zone In-Reply-To: <22036f17-ef74-e79b-be17-978bbe18bcb2@oracle.com> References: <22036f17-ef74-e79b-be17-978bbe18bcb2@oracle.com> Message-ID: <7c63218a-25dc-b82e-9ccc-88d019b0abfa@oracle.com> Thanks for the review Roger. I run into compiler issues if I don't declare the new function in the header file. /ws/jdk-jdk/open/src/java.base/unix/native/libjava/TimeZone_md.c:143:18: error: implicit declaration of function ?isFileIdentical? [-Werror=implicit-function-declaration] ???????????? tz = isFileIdentical(buf, size, pathname); If I try to declare it earlier in the main code,? I also run into issues since this new function calls other implicitly declared functions. regards, Sean. On 12/09/2019 18:47, Roger Riggs wrote: > Hi Sean, > > In addition to Naoto's comments. > > The change to TimeZone_md.h should not be needed. > A 'static' declaration doesn't need to be visible outside its source > file. > > Roger > > > On 9/12/19 12:42 PM, naoto.sato at oracle.com wrote: >> Hi Se?n, >> >> I like your approach to provide the fast path to determine the system >> time zone. One general question is, is UTC/GMT the right set of fast >> path candidates? Should we add some more common ones? >> >> Other comments to the code: >> >> TimeZone_md.c >> >> - Should fast path search come after "dir" validation, i.e., line >> 146-148? >> - Line 126: "statbuf" can be removed. >> - Line 134: 'i' is not size_of_something, so 'int' type should >> suffice (and its initialization is done in the for-loop). >> - Line 138: the fast path search should "continue" with the next >> name, instead of "break". >> - Line 142, 182: I'd wrap this line with parens for the if statement. >> - Line 232-242: "pathname" is an argument to this function, so >> freeing it inside the function seems odd. Also, no need to reset >> dbuf/fd since they are no longer reused in the loop. >> >> Naoto >> >> On 9/11/19 3:50 AM, Se?n Coffey wrote: >>> The current algorithm for determining the default timezone on >>> (non-AIX) unix systems goes something like : >>> >>> 1. If TZ environment variable is defined, use it >>> 2. else if /etc/timezone exists, use the value contained within it >>> 3. else if /etc/localtime exists and is a symbolic link, use the >>> name pointed to >>> 4. else if /etc/localtime is a binary, find the first identical time >>> zone binary file in /usr/share/zoneinfo/ >>> >>> Step 4 is a bit crude in that the zoneinfo directory can contain >>> over 1,800 files on today's systems. I'd like to change the logic so >>> that common timezones are first checked for buffer matching before a >>> full directory traversal is performed. It should be a performance >>> gain and it should also lead to more consistent results for reasons >>> outlined in the bug report. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8223490 >>> webrev: http://cr.openjdk.java.net/~coffeys/webrev.8223490/webrev/ >>> >>> > From pavel.rappo at oracle.com Fri Sep 13 10:21:31 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 13 Sep 2019 11:21:31 +0100 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: <47acbb78-806f-2951-3b22-de6e7965f461@oracle.com> References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> <87sgpblxns.fsf@oldenburg2.str.redhat.com> <7A46485C-E250-4E57-9FB0-B9D18CA70632@oracle.com> <60FD933F-51A5-4438-83AF-B3427CFDE60D@oracle.com> <8A9E3066-E6F6-4E65-BD02-DF0ACFF02FAD@oracle.com> <633A0CE3-C771-493B-89E3-7FA843C85183@oracle.com> <6b209e36-686f-7852-7fb8-3a0ef0e8423a@oracle.com> <4CAC6E8D-9198-4701-99C0-49901D72A396@oracle.com> <47acbb78-806f-2951-3b22-de6e7965f461@oracle.com> Message-ID: <275EC96C-CC39-41C8-9B9C-B917F25FAB70@oracle.com> Here's the latest webrev accumulating all the changes we've discussed so far: http://cr.openjdk.java.net/~prappo/8228580/webrev.03/ If people are okay with that I will proceed to creating a CSR. > On 12 Sep 2019, at 20:06, Alan Bateman wrote: > > On 12/09/2019 12:41, Chris Hegarty wrote: >> Here is an initial attempt to document these timeout/retry properties. It?s effectively the wording lifted from the tech notes [1], with ?UDP? removed. > Thanks, this look and dropping the reference to "UDP" make sense. > > One minor nit is that "are relevant to the DNS provider" might be better worded as "may be used when creating the initial context". This will fit nicely if/when someone adds a description to the @provides tag. At some point I hope the other properties can be used too but that is beyond the scope of JDK-8228580. > > -Alan From andy.herrick at oracle.com Fri Sep 13 12:10:44 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 13 Sep 2019 08:10:44 -0400 Subject: RFR: JDK-8230521: rename --output/-o option and add default value (".") In-Reply-To: References: Message-ID: <7925b25f-ed21-2d39-1ae2-81968ab118e4@oracle.com> On 9/12/2019 9:34 PM, Alexander Matveev wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > - Renamed "--output" to "--dest" and made it optional with default to > ".". > > [1] https://bugs.openjdk.java.net/browse/JDK-8230521 > > [2] http://cr.openjdk.java.net/~almatvee/8230629/webrev.00/ I think this is wrong pointer to webrev, should be: http://cr.openjdk.java.net/~almatvee/8230521 Overall looks good - I think we need a little reworking of examples in help text. When implementing other CLI changes, I didn't try to re-align the text of the examples because I knew this was coming. If dest is optional, we should not use it in every example.? I was thinking of removing the option from all the examples except the first one. This would also fix the excessively long line in the second example (caused by me adding "--package-type app-image".? check that it fits in 80 columns after dest is removed. (note - there is also an excessively long line in "MSG_Help_default_install_dir". can you re-layout this one to fit in 80 columns ?) /Andy > > Thanks, > Alexander From Roger.Riggs at oracle.com Fri Sep 13 13:01:06 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 13 Sep 2019 06:01:06 -0700 (PDT) Subject: RFR: 8223490: Optimize search algorithm for determining default time zone In-Reply-To: <7c63218a-25dc-b82e-9ccc-88d019b0abfa@oracle.com> References: <22036f17-ef74-e79b-be17-978bbe18bcb2@oracle.com> <7c63218a-25dc-b82e-9ccc-88d019b0abfa@oracle.com> Message-ID: <44d5e621-b587-91b5-fa11-4f9d3dc58409@oracle.com> Hi Sean, The declaration can be up in the _md.c file to satify the compiler about forward declarations. $.02, Roger On 9/13/19 4:34 AM, Se?n Coffey wrote: > Thanks for the review Roger. I run into compiler issues if I don't > declare the new function in the header file. > > /ws/jdk-jdk/open/src/java.base/unix/native/libjava/TimeZone_md.c:143:18: > error: implicit declaration of function ?isFileIdentical? > [-Werror=implicit-function-declaration] > ???????????? tz = isFileIdentical(buf, size, pathname); > > If I try to declare it earlier in the main code,? I also run into > issues since this new function calls other implicitly declared functions. > > regards, > Sean. > > On 12/09/2019 18:47, Roger Riggs wrote: >> Hi Sean, >> >> In addition to Naoto's comments. >> >> The change to TimeZone_md.h should not be needed. >> A 'static' declaration doesn't need to be visible outside its source >> file. >> >> Roger >> >> >> On 9/12/19 12:42 PM, naoto.sato at oracle.com wrote: >>> Hi Se?n, >>> >>> I like your approach to provide the fast path to determine the >>> system time zone. One general question is, is UTC/GMT the right set >>> of fast path candidates? Should we add some more common ones? >>> >>> Other comments to the code: >>> >>> TimeZone_md.c >>> >>> - Should fast path search come after "dir" validation, i.e., line >>> 146-148? >>> - Line 126: "statbuf" can be removed. >>> - Line 134: 'i' is not size_of_something, so 'int' type should >>> suffice (and its initialization is done in the for-loop). >>> - Line 138: the fast path search should "continue" with the next >>> name, instead of "break". >>> - Line 142, 182: I'd wrap this line with parens for the if statement. >>> - Line 232-242: "pathname" is an argument to this function, so >>> freeing it inside the function seems odd. Also, no need to reset >>> dbuf/fd since they are no longer reused in the loop. >>> >>> Naoto >>> >>> On 9/11/19 3:50 AM, Se?n Coffey wrote: >>>> The current algorithm for determining the default timezone on >>>> (non-AIX) unix systems goes something like : >>>> >>>> 1. If TZ environment variable is defined, use it >>>> 2. else if /etc/timezone exists, use the value contained within it >>>> 3. else if /etc/localtime exists and is a symbolic link, use the >>>> name pointed to >>>> 4. else if /etc/localtime is a binary, find the first identical >>>> time zone binary file in /usr/share/zoneinfo/ >>>> >>>> Step 4 is a bit crude in that the zoneinfo directory can contain >>>> over 1,800 files on today's systems. I'd like to change the logic >>>> so that common timezones are first checked for buffer matching >>>> before a full directory traversal is performed. It should be a >>>> performance gain and it should also lead to more consistent results >>>> for reasons outlined in the bug report. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8223490 >>>> webrev: http://cr.openjdk.java.net/~coffeys/webrev.8223490/webrev/ >>>> >>>> >> From sean.coffey at oracle.com Fri Sep 13 13:44:57 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 13 Sep 2019 13:44:57 +0000 Subject: RFR: 8223490: Optimize search algorithm for determining default time zone In-Reply-To: <44d5e621-b587-91b5-fa11-4f9d3dc58409@oracle.com> References: <22036f17-ef74-e79b-be17-978bbe18bcb2@oracle.com> <7c63218a-25dc-b82e-9ccc-88d019b0abfa@oracle.com> <44d5e621-b587-91b5-fa11-4f9d3dc58409@oracle.com> Message-ID: <2b8bec61-1db3-c79c-d601-2b19da304404@oracle.com> Thanks Roger, I've reverted the header file changes then and added this to the .c file: @@ -42,6 +42,8 @@ #include "jvm.h" #include "TimeZone_md.h" +static char *isFileIdentical(char* buf, size_t size, char *pathname); + #define SKIP_SPACE(p) while (*p == ' ' || *p == '\t') p++; #define RESTARTABLE(_cmd, _result) do { \ Regards, Sean. On 13/09/19 13:01, Roger Riggs wrote: > Hi Sean, > > The declaration can be up in the _md.c file to satify the compiler > about forward declarations. > > $.02, Roger > > On 9/13/19 4:34 AM, Se?n Coffey wrote: >> Thanks for the review Roger. I run into compiler issues if I don't >> declare the new function in the header file. >> >> /ws/jdk-jdk/open/src/java.base/unix/native/libjava/TimeZone_md.c:143:18: >> error: implicit declaration of function ?isFileIdentical? >> [-Werror=implicit-function-declaration] >> tz = isFileIdentical(buf, size, pathname); >> >> If I try to declare it earlier in the main code, I also run into >> issues since this new function calls other implicitly declared >> functions. >> >> regards, >> Sean. >> >> On 12/09/2019 18:47, Roger Riggs wrote: >>> Hi Sean, >>> >>> In addition to Naoto's comments. >>> >>> The change to TimeZone_md.h should not be needed. >>> A 'static' declaration doesn't need to be visible outside its source >>> file. >>> >>> Roger >>> >>> >>> On 9/12/19 12:42 PM, naoto.sato at oracle.com wrote: >>>> Hi Se?n, >>>> >>>> I like your approach to provide the fast path to determine the >>>> system time zone. One general question is, is UTC/GMT the right set >>>> of fast path candidates? Should we add some more common ones? >>>> >>>> Other comments to the code: >>>> >>>> TimeZone_md.c >>>> >>>> - Should fast path search come after "dir" validation, i.e., line >>>> 146-148? >>>> - Line 126: "statbuf" can be removed. >>>> - Line 134: 'i' is not size_of_something, so 'int' type should >>>> suffice (and its initialization is done in the for-loop). >>>> - Line 138: the fast path search should "continue" with the next >>>> name, instead of "break". >>>> - Line 142, 182: I'd wrap this line with parens for the if statement. >>>> - Line 232-242: "pathname" is an argument to this function, so >>>> freeing it inside the function seems odd. Also, no need to reset >>>> dbuf/fd since they are no longer reused in the loop. >>>> >>>> Naoto >>>> >>>> On 9/11/19 3:50 AM, Se?n Coffey wrote: >>>>> The current algorithm for determining the default timezone on >>>>> (non-AIX) unix systems goes something like : >>>>> >>>>> 1. If TZ environment variable is defined, use it >>>>> 2. else if /etc/timezone exists, use the value contained within it >>>>> 3. else if /etc/localtime exists and is a symbolic link, use the >>>>> name pointed to >>>>> 4. else if /etc/localtime is a binary, find the first identical >>>>> time zone binary file in /usr/share/zoneinfo/ >>>>> >>>>> Step 4 is a bit crude in that the zoneinfo directory can contain >>>>> over 1,800 files on today's systems. I'd like to change the logic >>>>> so that common timezones are first checked for buffer matching >>>>> before a full directory traversal is performed. It should be a >>>>> performance gain and it should also lead to more consistent >>>>> results for reasons outlined in the bug report. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8223490 >>>>> webrev: http://cr.openjdk.java.net/~coffeys/webrev.8223490/webrev/ >>>>> >>>>> >>> > From forax at univ-mlv.fr Fri Sep 13 15:10:11 2019 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 13 Sep 2019 17:10:11 +0200 (CEST) Subject: RFR: jsr166 integration 2019-09 In-Reply-To: References: <517197737.1773850.1568278129180.JavaMail.zimbra@u-pem.fr> Message-ID: <738837959.2535658.1568387411851.JavaMail.zimbra@u-pem.fr> > De: "Martin Buchholz" > ?: "Remi Forax" > Cc: "core-libs-dev" , "loom-dev" > , "David Holmes" , "Doug > Lea"

> Envoy?: Jeudi 12 Septembre 2019 16:20:12 > Objet: Re: RFR: jsr166 integration 2019-09 > On Thu, Sep 12, 2019 at 1:48 AM Remi Forax < [ mailto:forax at univ-mlv.fr | > forax at univ-mlv.fr ] > wrote: >> This remember me something, >> we should refactor most of the the package-private final methods (and the >> corresponding constructors) at least inside java.lang/java.util to make them >> private, there is no need to make them package-private anymore given that since >> Java 11 the compiler emits nestmate attributes instead of generating the method >> access$XXX. >> Maybe i should write a bytecode analyzer for that ? > Right! Going the other way it was fairly easy to trawl through the generated > bytecode using javap looking for "access$". > I don't think the nestmates feature is really complete until there is an easy > tool to find all the package-private elements accessed only within their nest. [ https://github.com/forax/nestmate-tidyup/blob/master/NestMateTidyUp.java | https://github.com/forax/nestmate-tidyup/blob/master/NestMateTidyUp.java ] To reduce the number of dependencies to 0, it uses the jdk internal version of ASM, so the command line is java --add-exports java.base/jdk.internal.org.objectweb.asm=ALL-UNNAMED NestMateTidyUp.java It crawles java.base to find the fields/methods/constructors that should be declared private. weirdly, the compiler (javac) also generates some package private fields (those pesky this$0) if the class itself is package private (i believe). R?mi From dl at cs.oswego.edu Fri Sep 13 15:19:21 2019 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 13 Sep 2019 11:19:21 -0400 Subject: RFR: jsr166 integration 2019-09 In-Reply-To: <738837959.2535658.1568387411851.JavaMail.zimbra@u-pem.fr> References: <517197737.1773850.1568278129180.JavaMail.zimbra@u-pem.fr> <738837959.2535658.1568387411851.JavaMail.zimbra@u-pem.fr> Message-ID: <16d7944e-4b61-7ed9-aeea-fca44e970016@cs.oswego.edu> Would doing this make anything better enough to outweigh Martin and I needing to deal with one more incompatible codebase? -Doug On 9/13/19 11:10 AM, forax at univ-mlv.fr wrote: > > > ------------------------------------------------------------------------ > > *De: *"Martin Buchholz" > *?: *"Remi Forax" > *Cc: *"core-libs-dev" , "loom-dev" > , "David Holmes" > , "Doug Lea"
> *Envoy?: *Jeudi 12 Septembre 2019 16:20:12 > *Objet: *Re: RFR: jsr166 integration 2019-09 > > > > On Thu, Sep 12, 2019 at 1:48 AM Remi Forax > wrote: > > This remember me something, > we should refactor most of the the package-private final methods > (and the corresponding constructors) at least inside > java.lang/java.util to make them private, there is no need to > make them package-private anymore given that since Java 11 the > compiler emits nestmate attributes instead of generating the > method access$XXX. > > Maybe i should write a bytecode analyzer for that ? > > > Right! Going the other way it was fairly easy to trawl through the > generated bytecode using javap looking for "access$". > I don't think the nestmates feature is really complete until there > is an easy tool to find all the package-private elements accessed > only within their nest. > > > https://github.com/forax/nestmate-tidyup/blob/master/NestMateTidyUp.java > > To reduce the number of dependencies to 0, it uses the jdk internal > version of ASM, so the command line is > ?? java --add-exports > java.base/jdk.internal.org.objectweb.asm=ALL-UNNAMED NestMateTidyUp.java > > It crawles java.base to find the fields/methods/constructors that should > be declared private. > > weirdly, the compiler (javac) also generates some package private fields > (those pesky this$0) if the class itself is package private (i believe). > > R?mi > From forax at univ-mlv.fr Fri Sep 13 16:43:56 2019 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 13 Sep 2019 18:43:56 +0200 (CEST) Subject: RFR: jsr166 integration 2019-09 In-Reply-To: <16d7944e-4b61-7ed9-aeea-fca44e970016@cs.oswego.edu> References: <517197737.1773850.1568278129180.JavaMail.zimbra@u-pem.fr> <738837959.2535658.1568387411851.JavaMail.zimbra@u-pem.fr> <16d7944e-4b61-7ed9-aeea-fca44e970016@cs.oswego.edu> Message-ID: <1150861893.2564720.1568393036106.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Doug Lea"
> ?: "Remi Forax" , "Martin Buchholz" > Cc: "core-libs-dev" , "loom-dev" , "David Holmes" > > Envoy?: Vendredi 13 Septembre 2019 17:19:21 > Objet: Re: RFR: jsr166 integration 2019-09 > Would doing this make anything better enough to outweigh Martin and I > needing to deal with one more incompatible codebase ? I believe the answer is the question :) Android (d8 in fact) is able to desugar private access with nestmates since last April, your latest backport target 9 which is not supported anymore, so when you will move the backport to support Java 11, this tool can become handy. > > -Doug R?mi > > On 9/13/19 11:10 AM, forax at univ-mlv.fr wrote: >> >> >> ------------------------------------------------------------------------ >> >> *De: *"Martin Buchholz" >> *?: *"Remi Forax" >> *Cc: *"core-libs-dev" , "loom-dev" >> , "David Holmes" >> , "Doug Lea"
>> *Envoy?: *Jeudi 12 Septembre 2019 16:20:12 >> *Objet: *Re: RFR: jsr166 integration 2019-09 >> >> >> >> On Thu, Sep 12, 2019 at 1:48 AM Remi Forax > > wrote: >> >> This remember me something, >> we should refactor most of the the package-private final methods >> (and the corresponding constructors) at least inside >> java.lang/java.util to make them private, there is no need to >> make them package-private anymore given that since Java 11 the >> compiler emits nestmate attributes instead of generating the >> method access$XXX. >> >> Maybe i should write a bytecode analyzer for that ? >> >> >> Right! Going the other way it was fairly easy to trawl through the >> generated bytecode using javap looking for "access$". >> I don't think the nestmates feature is really complete until there >> is an easy tool to find all the package-private elements accessed >> only within their nest. >> >> >> https://github.com/forax/nestmate-tidyup/blob/master/NestMateTidyUp.java >> >> To reduce the number of dependencies to 0, it uses the jdk internal >> version of ASM, so the command line is >> ?? java --add-exports >> java.base/jdk.internal.org.objectweb.asm=ALL-UNNAMED NestMateTidyUp.java >> >> It crawles java.base to find the fields/methods/constructors that should >> be declared private. >> >> weirdly, the compiler (javac) also generates some package private fields >> (those pesky this$0) if the class itself is package private (i believe). >> >> R?mi From martinrb at google.com Fri Sep 13 17:23:33 2019 From: martinrb at google.com (Martin Buchholz) Date: Fri, 13 Sep 2019 10:23:33 -0700 Subject: RFR: jsr166 integration 2019-09 In-Reply-To: <1150861893.2564720.1568393036106.JavaMail.zimbra@u-pem.fr> References: <517197737.1773850.1568278129180.JavaMail.zimbra@u-pem.fr> <738837959.2535658.1568387411851.JavaMail.zimbra@u-pem.fr> <16d7944e-4b61-7ed9-aeea-fca44e970016@cs.oswego.edu> <1150861893.2564720.1568393036106.JavaMail.zimbra@u-pem.fr> Message-ID: Thank you! On Fri, Sep 13, 2019 at 9:44 AM wrote: > > Android (d8 in fact) is able to desugar private access with nestmates > since last April, > your latest backport target 9 which is not supported anymore, so when you > will move the backport to support Java 11, > this tool can become handy. > In fact, jsr166 CVS has already abandoned support for jdk9 (and jdk10) so there's absolutely no reason not to apply the suggestions made by R?mi's program. https://bugs.openjdk.java.net/browse/JDK-8230966 From naoto.sato at oracle.com Fri Sep 13 18:05:49 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 13 Sep 2019 11:05:49 -0700 Subject: RFR: 8223490: Optimize search algorithm for determining default time zone In-Reply-To: <38fcea76-12c9-b2da-960a-118ed396c190@oracle.com> References: <38fcea76-12c9-b2da-960a-118ed396c190@oracle.com> Message-ID: Much better now. One nit: label "freedata" at line 236 should not be indented. As to the fastpath candidate zones, I was just curious. UTC/GMT is fine by me. Naoto On 9/13/19 1:32 AM, Se?n Coffey wrote: > Thanks for the review Naoto. The edits certainly did need some tidying > up. Comments inline. > > On 12/09/2019 17:42, naoto.sato at oracle.com wrote: >> Hi Se?n, >> >> I like your approach to provide the fast path to determine the system >> time zone. One general question is, is UTC/GMT the right set of fast >> path candidates? Should we add some more common ones? >> > I'm open to suggestions. I think these two are very common and good for > starting with. > >> Other comments to the code: >> >> TimeZone_md.c >> >> - Should fast path search come after "dir" validation, i.e., line >> 146-148? >> - Line 126: "statbuf" can be removed. >> - Line 134: 'i' is not size_of_something, so 'int' type should suffice >> (and its initialization is done in the for-loop). >> - Line 138: the fast path search should "continue" with the next name, >> instead of "break". >> - Line 142, 182: I'd wrap this line with parens for the if statement. > All above corrected. >> - Line 232-242: "pathname" is an argument to this function, so freeing >> it inside the function seems odd. Also, no need to reset dbuf/fd since >> they are no longer reused in the loop. >> > I thought it was a useful approach given that it's the last function to > use 'pathname'. However, it's not in keeping with normal design I guess. > I've reverted and now free pathname at other call sites instead. > > new webrev at http://cr.openjdk.java.net/~coffeys/webrev.8223490.v2/webrev/ > > regards, > Sean. > >> Naoto >> >> On 9/11/19 3:50 AM, Se?n Coffey wrote: >>> The current algorithm for determining the default timezone on >>> (non-AIX) unix systems goes something like : >>> >>> 1. If TZ environment variable is defined, use it >>> 2. else if /etc/timezone exists, use the value contained within it >>> 3. else if /etc/localtime exists and is a symbolic link, use the name >>> pointed to >>> 4. else if /etc/localtime is a binary, find the first identical time >>> zone binary file in /usr/share/zoneinfo/ >>> >>> Step 4 is a bit crude in that the zoneinfo directory can contain over >>> 1,800 files on today's systems. I'd like to change the logic so that >>> common timezones are first checked for buffer matching before a full >>> directory traversal is performed. It should be a performance gain and >>> it should also lead to more consistent results for reasons outlined >>> in the bug report. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8223490 >>> webrev: http://cr.openjdk.java.net/~coffeys/webrev.8223490/webrev/ >>> >>> From huizhe.wang at oracle.com Fri Sep 13 18:53:40 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 13 Sep 2019 11:53:40 -0700 Subject: RFR [14/java.xml] 8230814: Enable SAX ContentHandler to handle XML Declaration Message-ID: Please review a new method addition to SAX ContentHandler that allows a SAX parser to send back information about the declaration of the input document. JBS: https://bugs.openjdk.java.net/browse/JDK-8230814 CSR: https://bugs.openjdk.java.net/browse/JDK-8230824 webrev: http://cr.openjdk.java.net/~joehw/jdk14/8230814/webrev/ Thanks, Joe From Alan.Bateman at oracle.com Fri Sep 13 19:20:04 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 13 Sep 2019 20:20:04 +0100 Subject: RFR [14/java.xml] 8230814: Enable SAX ContentHandler to handle XML Declaration In-Reply-To: References: Message-ID: <5fa47e8d-4512-0e13-f5c3-d315807fe32d@oracle.com> On 13/09/2019 19:53, Joe Wang wrote: > Please review a new method addition to SAX ContentHandler that allows > a SAX parser to send back information about the declaration of the > input document. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8230814 > > CSR: https://bugs.openjdk.java.net/browse/JDK-8230824 This adds a method to an API that was originally developed by the SAX project. Can you summarize the relationship to that project? Is that project dead and the API subsumed by Java SE? Just asking as I don't recall API additions being done here (I remember the work in JDK-8152912 to deprecate XMLReaderFactory but I don't recall any additional or removals). -Alan. From lance.andersen at oracle.com Fri Sep 13 19:23:51 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 13 Sep 2019 15:23:51 -0400 Subject: RFR [14/java.xml] 8230814: Enable SAX ContentHandler to handle XML Declaration In-Reply-To: References: Message-ID: <86989FA8-42BE-40DC-8F56-A4233B46C3C8@oracle.com> Hi Joe, The proposed change look fine. > On Sep 13, 2019, at 2:53 PM, Joe Wang wrote: > > Please review a new method addition to SAX ContentHandler that allows a SAX parser to send back information about the declaration of the input document. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8230814 > > CSR: https://bugs.openjdk.java.net/browse/JDK-8230824 > > webrev: http://cr.openjdk.java.net/~joehw/jdk14/8230814/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 Sep 13 20:50:06 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 13 Sep 2019 13:50:06 -0700 Subject: RFR [14/java.xml] 8230814: Enable SAX ContentHandler to handle XML Declaration In-Reply-To: <5fa47e8d-4512-0e13-f5c3-d315807fe32d@oracle.com> References: <5fa47e8d-4512-0e13-f5c3-d315807fe32d@oracle.com> Message-ID: On 9/13/19 12:20 PM, Alan Bateman wrote: > On 13/09/2019 19:53, Joe Wang wrote: >> Please review a new method addition to SAX ContentHandler that allows >> a SAX parser to send back information about the declaration of the >> input document. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8230814 >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8230824 > This adds a method to an API that was originally developed by the SAX > project. Can you summarize the relationship to that project? Is that > project dead and the API subsumed by Java SE? Just asking as I don't > recall API additions being done here (I remember the work in > JDK-8152912 to deprecate XMLReaderFactory but I don't recall any > additional or removals). It can be said that the SAX project, in terms of the API work, was dead a long time ago. There hasn't been any updates/changes since SAX 2.0.2 released in 2004[1]. SAX is in public domain [2]. Sun/Oracle incorporated SAX2 in Java SE with a GPL license. I assume we're free to make changes. Please let me know if you think otherwise. [1] http://sax.sourceforge.net/ [2] http://sax.sourceforge.net/copying.html Thanks Joe > > -Alan. From peter.firmstone at zeus.net.au Fri Sep 13 22:07:15 2019 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sat, 14 Sep 2019 08:07:15 +1000 Subject: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: <5D571F0A.8020709@zeus.net.au> References: <5D55DA9F.5050807@zeus.net.au> <8ce427f1-5473-9e2f-af85-ceb7b08ed419@oracle.com> <5D568810.8060503@zeus.net.au> <1d1ea235-77bc-9517-9f00-4053c71be759@oracle.com> <5D571F0A.8020709@zeus.net.au> Message-ID: <5D7C1313.9060709@zeus.net.au> Hi Claes, So this security manager is part of a much larger program, (a fork of Jini / Apache River), I've almost finished the transition from Java 8 to Java 11... One change I noticed is permissions granted to the java extension directory are now granted to every domain in our policy provider as the java.ext.dirs property is now blank, I also had to grant permissions to a number of jdk modules, after fixing these, everthing running as expected, except for a few minor test failures. Next step will be to test against the EA builds. On 17/08/2019 7:24 AM, Peter Firmstone wrote: > Thanks Claes, > > I'll run some tests :) > > Cheers, > > Peter. > > On 16/08/2019 9:14 PM, Claes Redestad wrote: >> Hi Peter, >> >> by explicitly ensuring the file system has been initialized before >> installing a SecurityManager using a hook in System.setSecurityManager, >> the patch at hand takes step to ensure things stay neutral w.r.t. >> Permission initialization order when using any SecurityManager. It's not >> perfectly identical, so while unlikely, there's a theoretical >> possibility some implementation scenario not covered by our regression >> tests might run into issues. Any help testing custom implementation on >> coming EA builds would be greatly appreciated! >> >> One thing we could do on the JDK end to reduce fragility somewhat in >> this area is to provoke initialization of >> sun.security.util.SecurityConstants before installing the first SM. >> >> /Claes >> >> On 2019-08-16 12:40, Peter Firmstone wrote: >>> Hello Alan, >>> >>> Yes, we are aware of those issues. >>> >>> I mean documenting that system Permission classes should be loaded >>> before setting a custom SecurityManager, accessing the file system >>> is important, so if you haven't loaded the necessary classes before >>> setting a custom SecurityManager, it won't be gracefull... The >>> simplest way of ensuring classes are loaded is by creating object >>> instances of them. >>> >>> Perhaps just a note to beware of ensuring necessary classes are >>> loaded and let developers figure out what they need. >>> >>> The recursive calls are easy enough to deal with to avoid any stack >>> overflows using ThreadLocal. >>> >>> inTrustedCodeRecursiveCall.set(Boolean.TRUE); >>> try { >>> delegateContext = AccessController.doPrivileged( >>> new PrivilegedAction(){ >>> public AccessControlContext run() { >>> return new >>> AccessControlContext(finalExecutionContext, dc); >>> } >>> } >>> ); >>> }finally { >>> inTrustedCodeRecursiveCall.set(Boolean.FALSE); // >>> Must always happen, no matter what. >>> } >>> >>> We've only really been caught out once with some jvm bootstrap >>> changes, otherwise it's been rock solid. >>> >>> The other thing we do is once we've got more than three >>> ProtectionDomains on the stack is execute the ProtectionDomain >>> implies checks in parallel. Really helps when you're making a lot >>> of network calls. >>> >>> Cheers, >>> >>> Peter. >>> >>> On 16/08/2019 5:04 PM, Alan Bateman wrote: >>>> On 15/08/2019 23:20, Peter Firmstone wrote: >>>>> : >>>>> >>>>> The following code is included in the constructor of our >>>>> SecurityManager implementation, I suspect we may need to add some >>>>> classes to this list, perhaps this is something that needs >>>>> documenting? >>>> The checkPermission method of custom security manager can run >>>> arbitrary code so recursive initialization, stack overflow, >>>> bootstrap method errors, ... are always hazards. I don't know what >>>> documentation you have in mind but I don't think there is a >>>> definite list of classes that need to be loaded/initialized before >>>> the custom security manager is set because it will come down to the >>>> code that it executes in its checkPermission method. >>>> >>>> -Alan. >>>> >>>> >>> > From brent.christian at oracle.com Fri Sep 13 22:07:40 2019 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 13 Sep 2019 15:07:40 -0700 Subject: RFR 8221623 : Add StackWalker micro benchmarks to jdk repo Message-ID: Hi, Please review these StackWalker and Throwable benchmarks for addition into the JDK microbenchmarks. Bug: https://bugs.openjdk.java.net/browse/JDK-8221623 Webrev: http://cr.openjdk.java.net/~bchristi/8221623/webrev07/ The StackWalker benchmarks use StackWalker's forEach(), walk(), and Options to measure retrieval of various types of information from the call stack. The Throwable benchmarks do corresponding exercises; there are also a couple of Logging benchmarks. A JMH @Param is used to test a variety of call stack depths. In the future, we might consider a benchmark for Reflection.getCallerClass(). (It is more involved today to benchmark that method than at the time these benchmarks were originally written, so that one's commented out.) See JDK-8230976. Thanks, -Brent 1. https://bugs.openjdk.java.net/browse/JDK-8230976 From alexander.matveev at oracle.com Sat Sep 14 00:20:35 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Fri, 13 Sep 2019 17:20:35 -0700 Subject: RFR: JDK-8230521: rename --output/-o option and add default value (".") In-Reply-To: <773a5318-1dea-9f21-039d-29823b4dc7c8@oracle.com> References: <4e0a19fa-d1ed-0953-dc66-e1ffacb126a8@oracle.com> <773a5318-1dea-9f21-039d-29823b4dc7c8@oracle.com> Message-ID: http://cr.openjdk.java.net/~almatvee/8230521/webrev.01/ - Simplified setting default value for destination folder. - Undo renaming of output variables to dest. - Modified help messages as per Andy suggestion. - Removed obsolete tests as per Alexey suggestion. Thanks, Alexander On 9/12/2019 8:16 PM, Alexey Semenyuk wrote: > > > On 9/12/2019 10:47 PM, Alexey Semenyuk wrote: >> http://cr.openjdk.java.net/~almatvee/8230521/webrev.00/src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java.sdiff.html: >> >> --- >> 126???????? Path destPath = Paths.get(".").toAbsolutePath(); >> ?127???????? if (destPath.getFileName().toString().equals(".")) { >> ?128???????????? dest = destPath.getParent().toString(); >> ?129???????? } else { >> ?130???????????? dest = destPath.toString(); >> ?131???????? } >> --- >> Are you trying to get rid of trailing "." path component in the above >> code fragment? If yes, then this can be simplified as follows: >> --- >> Path destPath = Paths.get(".").normalize().toAbsolutePath(); >> --- > Or even simpler: > --- > Path destPath = Paths.get("").toAbsolutePath(); > --- > > - Alexey >> >> In general I don't like the idea of renaming variables and method >> names from `output` to `dest`. This doesn't add much value to the >> code and is incomplete and thus confusing (e.g.: in all the tests >> OUTPUT variable remains unnamed). >> I suggest to change only `--output` to `--dest` tokens in the code. >> >> Slightly unrelated thing. macOS tests >> --- >> test/jdk/tools/jpackage/macosx/base/Base.java >> test/jdk/tools/jpackage/macosx/base/FileAssociationsBase.java >> test/jdk/tools/jpackage/macosx/base/InstallDirBase.java >> test/jdk/tools/jpackage/macosx/base/LicenseBase.java >> --- >> duplicate corresponding shared tests that have been added in the >> patch for https://bugs.openjdk.java.net/browse/JDK-8230726. I didn't >> touch them as I didn't have MAC to try the replacements. Could you >> please just drop these obsolete tests and also run the new tests to >> make sure they work as expected. I mean not just run the tests to >> create package bundles, but also install these bundles and run the >> tests in a mode when they verify packages are properly installed. >> >> - Alexey >> >> On 9/12/2019 9:34 PM, Alexander Matveev wrote: >>> Please review the jpackage fix for bug [1] at [2]. >>> >>> This is a fix for the JDK-8200758-branch branch of the open sandbox >>> repository (jpackage). >>> >>> - Renamed "--output" to "--dest" and made it optional with default >>> to ".". >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8230521 >>> >>> [2] http://cr.openjdk.java.net/~almatvee/8230629/webrev.00/ >>> >>> Thanks, >>> Alexander >> > From alexey.semenyuk at oracle.com Sat Sep 14 01:03:50 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Fri, 13 Sep 2019 21:03:50 -0400 Subject: RFR: JDK-8230521: rename --output/-o option and add default value (".") In-Reply-To: References: <4e0a19fa-d1ed-0953-dc66-e1ffacb126a8@oracle.com> <773a5318-1dea-9f21-039d-29823b4dc7c8@oracle.com> Message-ID: Looks good. - Alexey On 9/13/2019 8:20 PM, Alexander Matveev wrote: > http://cr.openjdk.java.net/~almatvee/8230521/webrev.01/ > > - Simplified setting default value for destination folder. > - Undo renaming of output variables to dest. > - Modified help messages as per Andy suggestion. > - Removed obsolete tests as per Alexey suggestion. > > Thanks, > Alexander > > On 9/12/2019 8:16 PM, Alexey Semenyuk wrote: >> >> >> On 9/12/2019 10:47 PM, Alexey Semenyuk wrote: >>> http://cr.openjdk.java.net/~almatvee/8230521/webrev.00/src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java.sdiff.html: >>> >>> --- >>> 126???????? Path destPath = Paths.get(".").toAbsolutePath(); >>> ?127???????? if (destPath.getFileName().toString().equals(".")) { >>> ?128???????????? dest = destPath.getParent().toString(); >>> ?129???????? } else { >>> ?130???????????? dest = destPath.toString(); >>> ?131???????? } >>> --- >>> Are you trying to get rid of trailing "." path component in the >>> above code fragment? If yes, then this can be simplified as follows: >>> --- >>> Path destPath = Paths.get(".").normalize().toAbsolutePath(); >>> --- >> Or even simpler: >> --- >> Path destPath = Paths.get("").toAbsolutePath(); >> --- >> >> - Alexey >>> >>> In general I don't like the idea of renaming variables and method >>> names from `output` to `dest`. This doesn't add much value to the >>> code and is incomplete and thus confusing (e.g.: in all the tests >>> OUTPUT variable remains unnamed). >>> I suggest to change only `--output` to `--dest` tokens in the code. >>> >>> Slightly unrelated thing. macOS tests >>> --- >>> test/jdk/tools/jpackage/macosx/base/Base.java >>> test/jdk/tools/jpackage/macosx/base/FileAssociationsBase.java >>> test/jdk/tools/jpackage/macosx/base/InstallDirBase.java >>> test/jdk/tools/jpackage/macosx/base/LicenseBase.java >>> --- >>> duplicate corresponding shared tests that have been added in the >>> patch for https://bugs.openjdk.java.net/browse/JDK-8230726. I didn't >>> touch them as I didn't have MAC to try the replacements. Could you >>> please just drop these obsolete tests and also run the new tests to >>> make sure they work as expected. I mean not just run the tests to >>> create package bundles, but also install these bundles and run the >>> tests in a mode when they verify packages are properly installed. >>> >>> - Alexey >>> >>> On 9/12/2019 9:34 PM, Alexander Matveev wrote: >>>> Please review the jpackage fix for bug [1] at [2]. >>>> >>>> This is a fix for the JDK-8200758-branch branch of the open sandbox >>>> repository (jpackage). >>>> >>>> - Renamed "--output" to "--dest" and made it optional with default >>>> to ".". >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8230521 >>>> >>>> [2] http://cr.openjdk.java.net/~almatvee/8230629/webrev.00/ >>>> >>>> Thanks, >>>> Alexander >>> >> > From Alan.Bateman at oracle.com Sat Sep 14 07:22:17 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 14 Sep 2019 08:22:17 +0100 Subject: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: <5D7C1313.9060709@zeus.net.au> References: <5D55DA9F.5050807@zeus.net.au> <8ce427f1-5473-9e2f-af85-ceb7b08ed419@oracle.com> <5D568810.8060503@zeus.net.au> <1d1ea235-77bc-9517-9f00-4053c71be759@oracle.com> <5D571F0A.8020709@zeus.net.au> <5D7C1313.9060709@zeus.net.au> Message-ID: On 13/09/2019 23:07, Peter Firmstone wrote: > : > > One change I noticed is permissions granted to the java extension > directory are now granted to every domain in our policy provider as > the java.ext.dirs property is now blank, I also had to grant > permissions to a number of jdk modules, after fixing these, everthing > running as expected, except for a few minor test failures. The extension mechanism was deprecated in one of the maintenance releases of the JSR for Java SE 8 so hopefully not a surprise that the system property java.ext.dirs is no longer set. Since JDK 9, the VM will will not start if this system property is set on the command line and there is also a XX option in JDK 8 to help find usages of this mechanism. So I think I'm surprised that permissions are being granted when the property isn't set. Also surprised to hear that you need to grant permissions to the java.* or jdk.* modules. Are you saying that that the permissions granted in the default JDK policy file are incomplete or that there are code is missing a call to doPrivileged somewhere? Part of the reason for asking is that the both "-Djava.security.policy=" and "-Djava.security.policy==" will augment rather than override the default permissions. Maybe you are doing something that doesn't use this mechanism and you are always overriding the permissions granted to the modules in the run-time image? -Alan From Alan.Bateman at oracle.com Sat Sep 14 08:08:20 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 14 Sep 2019 09:08:20 +0100 Subject: RFR [14/java.xml] 8230814: Enable SAX ContentHandler to handle XML Declaration In-Reply-To: References: <5fa47e8d-4512-0e13-f5c3-d315807fe32d@oracle.com> Message-ID: <55d6fd3d-470d-d548-7f9f-b8dc8533944a@oracle.com> On 13/09/2019 21:50, Joe Wang wrote: > : > > It can be said that the SAX project, in terms of the API work, was > dead a long time ago. There hasn't been any updates/changes since SAX > 2.0.2 released in 2004[1]. SAX is in public domain [2]. Sun/Oracle > incorporated SAX2 in Java SE with a GPL license. I assume we're free > to make changes. Please let me know if you think otherwise. I'm not objecting to notifying the content handler of declarations. I'm also not discussing licenses. I'm mostly concerned that ContentHandler and all the other classes in this API point the reader to the SAX project as the place to go for documentation and more information. Has there been any effort to find a contact for the SAX project on soucreforge and get them to put an EOL notice on the main page? Alternatively, if the SAX API in Java SE is getting a second wind then maybe the links to the SAX project could be reduced to a historical note. -Alan From andy.herrick at oracle.com Sat Sep 14 12:15:46 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Sat, 14 Sep 2019 08:15:46 -0400 Subject: RFR: JDK-8230521: rename --output/-o option and add default value (".") In-Reply-To: References: <4e0a19fa-d1ed-0953-dc66-e1ffacb126a8@oracle.com> <773a5318-1dea-9f21-039d-29823b4dc7c8@oracle.com> Message-ID: <5b938797-085a-4bd1-2b95-6d2c52b232ab@oracle.com> This looks good. /Andy On 9/13/2019 8:20 PM, Alexander Matveev wrote: > http://cr.openjdk.java.net/~almatvee/8230521/webrev.01/ > > - Simplified setting default value for destination folder. > - Undo renaming of output variables to dest. > - Modified help messages as per Andy suggestion. > - Removed obsolete tests as per Alexey suggestion. > > Thanks, > Alexander > > On 9/12/2019 8:16 PM, Alexey Semenyuk wrote: >> >> >> On 9/12/2019 10:47 PM, Alexey Semenyuk wrote: >>> http://cr.openjdk.java.net/~almatvee/8230521/webrev.00/src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java.sdiff.html: >>> >>> --- >>> 126???????? Path destPath = Paths.get(".").toAbsolutePath(); >>> ?127???????? if (destPath.getFileName().toString().equals(".")) { >>> ?128???????????? dest = destPath.getParent().toString(); >>> ?129???????? } else { >>> ?130???????????? dest = destPath.toString(); >>> ?131???????? } >>> --- >>> Are you trying to get rid of trailing "." path component in the >>> above code fragment? If yes, then this can be simplified as follows: >>> --- >>> Path destPath = Paths.get(".").normalize().toAbsolutePath(); >>> --- >> Or even simpler: >> --- >> Path destPath = Paths.get("").toAbsolutePath(); >> --- >> >> - Alexey >>> >>> In general I don't like the idea of renaming variables and method >>> names from `output` to `dest`. This doesn't add much value to the >>> code and is incomplete and thus confusing (e.g.: in all the tests >>> OUTPUT variable remains unnamed). >>> I suggest to change only `--output` to `--dest` tokens in the code. >>> >>> Slightly unrelated thing. macOS tests >>> --- >>> test/jdk/tools/jpackage/macosx/base/Base.java >>> test/jdk/tools/jpackage/macosx/base/FileAssociationsBase.java >>> test/jdk/tools/jpackage/macosx/base/InstallDirBase.java >>> test/jdk/tools/jpackage/macosx/base/LicenseBase.java >>> --- >>> duplicate corresponding shared tests that have been added in the >>> patch for https://bugs.openjdk.java.net/browse/JDK-8230726. I didn't >>> touch them as I didn't have MAC to try the replacements. Could you >>> please just drop these obsolete tests and also run the new tests to >>> make sure they work as expected. I mean not just run the tests to >>> create package bundles, but also install these bundles and run the >>> tests in a mode when they verify packages are properly installed. >>> >>> - Alexey >>> >>> On 9/12/2019 9:34 PM, Alexander Matveev wrote: >>>> Please review the jpackage fix for bug [1] at [2]. >>>> >>>> This is a fix for the JDK-8200758-branch branch of the open sandbox >>>> repository (jpackage). >>>> >>>> - Renamed "--output" to "--dest" and made it optional with default >>>> to ".". >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8230521 >>>> >>>> [2] http://cr.openjdk.java.net/~almatvee/8230629/webrev.00/ >>>> >>>> Thanks, >>>> Alexander >>> >> > From peter.firmstone at zeus.net.au Sat Sep 14 20:21:13 2019 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sun, 15 Sep 2019 06:21:13 +1000 Subject: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: References: <5D55DA9F.5050807@zeus.net.au> <8ce427f1-5473-9e2f-af85-ceb7b08ed419@oracle.com> <5D568810.8060503@zeus.net.au> <1d1ea235-77bc-9517-9f00-4053c71be759@oracle.com> <5D571F0A.8020709@zeus.net.au> <5D7C1313.9060709@zeus.net.au> Message-ID: <5D7D4BB9.1010408@zeus.net.au> Hi Alan, We've got a bunch of very old policy files in our test suite, so they still had policy grants using the extension directory property. The grant for the extension directory property was followed by a forward slash and asterix. Oddly when the property was missing the grant became a wildcard URL. Note this isn't the sun PolicyFile implementation, but our policy provider also augments, rather than replace, maybe there's a new policy file our provider isn't aware of? From memory there was something special about the way the extension directory property was treated by the policy provider, but I don't recall the details, the same problems don't appear to exist when other properties in policy files cannot be resolved. Modules that required permissions, seem to be service providers: grant codebase "jrt:/jdk.security.auth" { permission java.security.AllPermission "", ""; }; grant codebase "jrt:/jdk.crypto.cryptoki" { permission java.security.AllPermission "", ""; }; grant codebase "jrt:/java.smartcardio" { permission java.security.AllPermission "", ""; }; grant codebase "jrt:/java.xml.crypto" { permission java.security.AllPermission "", ""; }; grant codebase "jrt:/java.security.jgss" { permission java.security.AllPermission "", ""; }; grant codebase "jrt:/jdk.crypto.ec" { permission java.security.AllPermission "", ""; }; grant codebase "jrt:/jdk.crypto.mscapi" { permission java.security.AllPermission "", ""; }; grant codebase "jrt:/jdk.localedata" { permission java.security.AllPermission "", ""; }; grant codebase "jrt:/jdk.security.jgss" { permission java.security.AllPermission "", ""; }; Regards, Peter. On 14/09/2019 5:22 PM, Alan Bateman wrote: > On 13/09/2019 23:07, Peter Firmstone wrote: >> : >> >> One change I noticed is permissions granted to the java extension >> directory are now granted to every domain in our policy provider as >> the java.ext.dirs property is now blank, I also had to grant >> permissions to a number of jdk modules, after fixing these, everthing >> running as expected, except for a few minor test failures. > The extension mechanism was deprecated in one of the maintenance > releases of the JSR for Java SE 8 so hopefully not a surprise that the > system property java.ext.dirs is no longer set. Since JDK 9, the VM > will will not start if this system property is set on the command line > and there is also a XX option in JDK 8 to help find usages of this > mechanism. So I think I'm surprised that permissions are being granted > when the property isn't set. > > Also surprised to hear that you need to grant permissions to the > java.* or jdk.* modules. Are you saying that that the permissions > granted in the default JDK policy file are incomplete or that there > are code is missing a call to doPrivileged somewhere? Part of the > reason for asking is that the both "-Djava.security.policy=" and > "-Djava.security.policy==" will augment rather than override the > default permissions. Maybe you are doing something that doesn't use > this mechanism and you are always overriding the permissions granted > to the modules in the run-time image? > > -Alan > From Alan.Bateman at oracle.com Sun Sep 15 12:58:56 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 15 Sep 2019 13:58:56 +0100 Subject: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: <5D7D4BB9.1010408@zeus.net.au> References: <5D55DA9F.5050807@zeus.net.au> <8ce427f1-5473-9e2f-af85-ceb7b08ed419@oracle.com> <5D568810.8060503@zeus.net.au> <1d1ea235-77bc-9517-9f00-4053c71be759@oracle.com> <5D571F0A.8020709@zeus.net.au> <5D7C1313.9060709@zeus.net.au> <5D7D4BB9.1010408@zeus.net.au> Message-ID: On 14/09/2019 21:21, Peter Firmstone wrote: > Hi Alan, > > We've got a bunch of very old policy files in our test suite, so they > still had policy grants using the extension directory property.? The > grant for the extension directory property was followed by a forward > slash and asterix.? Oddly when the property was missing the grant > became a wildcard URL.? Note this isn't the sun PolicyFile > implementation, but our policy provider also augments, rather than > replace, maybe there's a new policy file our provider isn't aware of? > > From memory there was something special about the way the extension > directory property was treated by the policy provider, but I don't > recall the details, the same problems don't appear to exist when other > properties in policy files cannot be resolved. > > > Modules that required permissions, seem to be service providers: In jdk/jdk repo, the following policy files are merged in the build to create the default policy: src/java.base/windows/lib/security/default.policy src/java.base/solaris/lib/security/default.policy src/java.base/share/lib/security/default.policy The default policy goes into a JDK internal location in the run-time image and used by the PolicyFile implementation. If you look in there you should see the permissions that are granted to the modules that map to the platform class loader. The intention is that deployments that are setting their own policy files don't need to be concerned about the permissions of modules in the run-time image. I suspect you are looking for a custom PolicyFile implementation to make use of these defaults to avoid needing to be concerned with the specific permissions that the modules in the run-time image. -Alan From andy.herrick at oracle.com Sun Sep 15 13:58:46 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Sun, 15 Sep 2019 09:58:46 -0400 Subject: RFR: JDK-8230649: Make jpackage tool an experimental feature Message-ID: <49310c6b-b546-84a7-0f5a-d8aeb4a456f5@oracle.com> Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). This is the at least the first small set of changes that need to be make to make jpackage an experimental package. ?- Add flags to the build so the module jdk.jpackage is built as an experimental module. ?- Modify test programs to tolerate the warning emitted when jpackage is run. [1]? https://bugs.openjdk.java.net/browse/JDK-8230649 [2]? http://cr.openjdk.java.net/~herrick/8230649 /Andy From Alan.Bateman at oracle.com Sun Sep 15 16:35:23 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 15 Sep 2019 17:35:23 +0100 Subject: RFR: JDK-8230649: Make jpackage tool an experimental feature In-Reply-To: <49310c6b-b546-84a7-0f5a-d8aeb4a456f5@oracle.com> References: <49310c6b-b546-84a7-0f5a-d8aeb4a456f5@oracle.com> Message-ID: <402ff52f-7ce4-821c-1620-da2ff709b972@oracle.com> On 15/09/2019 14:58, Andy Herrick wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > This is the at least the first small set of changes that need to be > make to make jpackage an experimental package. > > ?- Add flags to the build so the module jdk.jpackage is built as an > experimental module. > > ?- Modify test programs to tolerate the warning emitted when jpackage > is run. I think this change will need discussion. Can you provide a summary on what you mean by "experimental package"? I remember seeing Mark's comment go by where he suggested that the tool should be an experimental feature but I'm not sure if this translates to a warning or a configure option. I see the JIRA issue references the JEP for Incubating Modules but I'm not sure that it makes sense here as jdk.jpackage doesn't export an API and will eagerly participate in service binding because it `provides java.util.spi.ToolProvider`. There are subtle issues around incubating modules that want to provide services that were not worked out in the JDK 9 time frame. In this case, java.base uses ToolProvider so jdk.jpackage will be resolved when it is observable. I assum `java -version` will print a warning and that will not be welcomed. -Alan From andy.herrick at oracle.com Sun Sep 15 20:05:50 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Sun, 15 Sep 2019 16:05:50 -0400 Subject: RFR: JDK-8230649: Make jpackage tool an experimental feature In-Reply-To: <402ff52f-7ce4-821c-1620-da2ff709b972@oracle.com> References: <49310c6b-b546-84a7-0f5a-d8aeb4a456f5@oracle.com> <402ff52f-7ce4-821c-1620-da2ff709b972@oracle.com> Message-ID: <7c238d94-7450-5776-7af2-ec1d8f859db4@oracle.com> yes - result of this change is as you suggest, everything shows this warning, so we will need further discussions as to what it might mean to make jpackage "experimental". /Andy On 9/15/2019 12:35 PM, Alan Bateman wrote: > On 15/09/2019 14:58, Andy Herrick wrote: >> Please review the jpackage fix for bug [1] at [2]. >> >> This is a fix for the JDK-8200758-branch branch of the open sandbox >> repository (jpackage). >> >> This is the at least the first small set of changes that need to be >> make to make jpackage an experimental package. >> >> ?- Add flags to the build so the module jdk.jpackage is built as an >> experimental module. >> >> ?- Modify test programs to tolerate the warning emitted when jpackage >> is run. > I think this change will need discussion. Can you provide a summary on > what you mean by "experimental package"? I remember seeing Mark's > comment go by where he suggested that the tool should be an > experimental feature but I'm not sure if this translates to a warning > or a configure option. > > I see the JIRA issue references the JEP for Incubating Modules but I'm > not sure that it makes sense here as jdk.jpackage doesn't export an > API and will eagerly participate in service binding because it > `provides java.util.spi.ToolProvider`. There are subtle issues around > incubating modules that want to provide services that were not worked > out in the JDK 9 time frame. In this case, java.base uses ToolProvider > so jdk.jpackage will be resolved when it is observable. I assum `java > -version` will print a warning and that will not be welcomed. > > -Alan > From mrjarviscraft at gmail.com Sun Sep 15 20:22:24 2019 From: mrjarviscraft at gmail.com (JARvis PROgrammer) Date: Sun, 15 Sep 2019 23:22:24 +0300 Subject: [PATCH] Add *.iml to .hgignore and .gitignore Message-ID: This is a small patch to disable tracking of configuration files of Intellij-based IDEs (.iml) Diff: diff -r a6f653312b19 .gitignore --- a/.gitignore Sun Sep 15 08:41:48 2019 +0200 +++ b/.gitignore Sun Sep 15 21:11:13 2019 +0100 @@ -1,6 +1,7 @@ /build/ /dist/ /.idea/ +*.iml nbproject/private/ /webrev /.src-rev diff -r a6f653312b19 .hgignore --- a/.hgignore Sun Sep 15 08:41:48 2019 +0200 +++ b/.hgignore Sun Sep 15 21:11:13 2019 +0100 @@ -1,6 +1,7 @@ ^build/ ^dist/ ^.idea/ +*.iml nbproject/private/ ^webrev ^.src-rev$ Hosted diff-file: https://gist.github.com/JarvisCraft/d016d39a0342d09ce3a0a22a1893841d PS: if it is an unneeded patch or a wrong mailing list, please inform me Thanks, Peter From david.holmes at oracle.com Sun Sep 15 22:14:14 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 16 Sep 2019 08:14:14 +1000 Subject: RFR: jsr166 integration 2019-09 In-Reply-To: References: <517197737.1773850.1568278129180.JavaMail.zimbra@u-pem.fr> <738837959.2535658.1568387411851.JavaMail.zimbra@u-pem.fr> <16d7944e-4b61-7ed9-aeea-fca44e970016@cs.oswego.edu> <1150861893.2564720.1568393036106.JavaMail.zimbra@u-pem.fr> Message-ID: <1a4c7ebd-78bd-de5b-7053-cff63f13bdeb@oracle.com> Hi Martin, These changes have caused a number of tests to break and wreaked havoc in our CI system (as those tests get executed a lot in different configs). The problem seems to be changes to stack use and contents: - vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/SynchronizerLockingThreads/SynchronizerLockingThreads* - vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi* - runtime/ReservedStack/ReservedStackTest.java - java/lang/management/ThreadMXBean/LockedSynchronizers.java I'm filing bugs for each test group, but we may need to problem-list them in the meantime. David ----- On 14/09/2019 3:23 am, Martin Buchholz wrote: > Thank you! > > On Fri, Sep 13, 2019 at 9:44 AM > wrote: > > > Android (d8 in fact) is able to desugar private access with > nestmates since last April, > your latest backport target 9 which is not supported anymore, so > when you will move the backport to support Java 11, > this tool can become handy. > > > In fact, jsr166 CVS has already?abandoned support for jdk9 (and jdk10) > so there's absolutely no reason not to apply the suggestions made > by??R?mi's program. > > https://bugs.openjdk.java.net/browse/JDK-8230966 From martinrb at google.com Sun Sep 15 23:29:45 2019 From: martinrb at google.com (Martin Buchholz) Date: Sun, 15 Sep 2019 16:29:45 -0700 Subject: RFR: jsr166 integration 2019-09 In-Reply-To: <1a4c7ebd-78bd-de5b-7053-cff63f13bdeb@oracle.com> References: <517197737.1773850.1568278129180.JavaMail.zimbra@u-pem.fr> <738837959.2535658.1568387411851.JavaMail.zimbra@u-pem.fr> <16d7944e-4b61-7ed9-aeea-fca44e970016@cs.oswego.edu> <1150861893.2564720.1568393036106.JavaMail.zimbra@u-pem.fr> <1a4c7ebd-78bd-de5b-7053-cff63f13bdeb@oracle.com> Message-ID: Sorry about the breakage. In retrospect, this is one jsr166 integration where we should have run more tests from other areas of the jdk. Especially monitoring tests are sensitive to implementation changes in j.u.c.locks. (but we've never run nsk tests) On Sun, Sep 15, 2019 at 3:14 PM David Holmes wrote: > Hi Martin, > > These changes have caused a number of tests to break and wreaked havoc > in our CI system (as those tests get executed a lot in different > configs). The problem seems to be changes to stack use and contents: > > - > > vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/SynchronizerLockingThreads/SynchronizerLockingThreads* > - vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi* > - runtime/ReservedStack/ReservedStackTest.java > - java/lang/management/ThreadMXBean/LockedSynchronizers.java > > I'm filing bugs for each test group, but we may need to problem-list > them in the meantime. > > David > ----- > > On 14/09/2019 3:23 am, Martin Buchholz wrote: > > Thank you! > > > > On Fri, Sep 13, 2019 at 9:44 AM > > wrote: > > > > > > Android (d8 in fact) is able to desugar private access with > > nestmates since last April, > > your latest backport target 9 which is not supported anymore, so > > when you will move the backport to support Java 11, > > this tool can become handy. > > > > > > In fact, jsr166 CVS has already abandoned support for jdk9 (and jdk10) > > so there's absolutely no reason not to apply the suggestions made > > by R?mi's program. > > > > https://bugs.openjdk.java.net/browse/JDK-8230966 > From david.holmes at oracle.com Sun Sep 15 23:49:09 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 16 Sep 2019 09:49:09 +1000 Subject: Urgent RFR: 8231034/8231033 Problem list tetss failing after JSR-166 refresh Message-ID: Bugs: https://bugs.openjdk.java.net/browse/JDK-8231033 https://bugs.openjdk.java.net/browse/JDK-8231034 webrev: http://cr.openjdk.java.net/~dholmes/8231033-8231034/webrev/ (inline below) A bunch of mainly management tests (mostly in hotspot repo) are failing after the JSR-166 refresh to due changes in stack information and usage. These are causing significant disruption to our CI and so need to be ProblemListed while the tests are investigated and fixed. Testing: tier 1 - 3 (in progress) Thanks, David --- old/test/hotspot/jtreg/ProblemList.txt 2019-09-15 19:41:48.446127451 -0400 +++ new/test/hotspot/jtreg/ProblemList.txt 2019-09-15 19:41:47.344115881 -0400 @@ -90,6 +90,7 @@ # :hotspot_runtime runtime/jni/terminatedThread/TestTerminatedThread.java 8219652 aix-ppc64 +runtime/ReservedStack/ReservedStackTest.java 8231031 generic-all ############################################################################# @@ -204,4 +205,16 @@ vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn001/forceEarlyReturn001.java 7199837 generic-all +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/SynchronizerLockingThreads/SynchronizerLockingThreads001/TestDescription.java 8231032 generic-all +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/SynchronizerLockingThreads/SynchronizerLockingThreads002/TestDescription.java 8231032 generic-all +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/SynchronizerLockingThreads/SynchronizerLockingThreads003/TestDescription.java 8231032 generic-all +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/SynchronizerLockingThreads/SynchronizerLockingThreads004/TestDescription.java 8231032 generic-all +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/SynchronizerLockingThreads/SynchronizerLockingThreads005/TestDescription.java 8231032 generic-all + +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi001/Multi001.java 8231032 generic-all +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi002/TestDescription.java 8231032 generic-all +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi003/TestDescription.java 8231032 generic-all +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi004/TestDescription.java 8231032 generic-all +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi005/TestDescription.java 8231032 generic-all + ############################################################################# --- old/test/jdk/ProblemList.txt 2019-09-15 19:41:51.817162845 -0400 +++ new/test/jdk/ProblemList.txt 2019-09-15 19:41:50.703151149 -0400 @@ -564,6 +564,8 @@ javax/management/monitor/DerivedGaugeMonitorTest.java 8042211 generic-all javax/management/remote/mandatory/connection/MultiThreadDeadLockTest.java 8042215 generic-all +java/lang/management/ThreadMXBean/LockedSynchronizers.java 8231032 generic-all + ############################################################################ # jdk_io From joe.darcy at oracle.com Sun Sep 15 23:54:01 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 15 Sep 2019 16:54:01 -0700 Subject: Urgent RFR: 8231034/8231033 Problem list tetss failing after JSR-166 refresh In-Reply-To: References: Message-ID: <40a30e97-5ebc-8ece-47d2-96804afb022c@oracle.com> Looks fine David; thanks, -Joe On 9/15/2019 4:49 PM, David Holmes wrote: > Bugs: https://bugs.openjdk.java.net/browse/JDK-8231033 > ????? https://bugs.openjdk.java.net/browse/JDK-8231034 > > webrev: http://cr.openjdk.java.net/~dholmes/8231033-8231034/webrev/ > (inline below) > > A bunch of mainly management tests (mostly in hotspot repo) are > failing after the JSR-166 refresh to due changes in stack information > and usage. These are causing significant disruption to our CI and so > need to be ProblemListed while the tests are investigated and fixed. > > Testing: tier 1 - 3 (in progress) > > Thanks, > David > > --- old/test/hotspot/jtreg/ProblemList.txt??? 2019-09-15 > 19:41:48.446127451 -0400 > +++ new/test/hotspot/jtreg/ProblemList.txt??? 2019-09-15 > 19:41:47.344115881 -0400 > @@ -90,6 +90,7 @@ > ?# :hotspot_runtime > > ?runtime/jni/terminatedThread/TestTerminatedThread.java 8219652 aix-ppc64 > +runtime/ReservedStack/ReservedStackTest.java 8231031 generic-all > > > ############################################################################# > > > @@ -204,4 +205,16 @@ > > > vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn001/forceEarlyReturn001.java > 7199837 generic-all > > +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/SynchronizerLockingThreads/SynchronizerLockingThreads001/TestDescription.java > 8231032 generic-all > +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/SynchronizerLockingThreads/SynchronizerLockingThreads002/TestDescription.java > 8231032 generic-all > +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/SynchronizerLockingThreads/SynchronizerLockingThreads003/TestDescription.java > 8231032 generic-all > +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/SynchronizerLockingThreads/SynchronizerLockingThreads004/TestDescription.java > 8231032 generic-all > +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/SynchronizerLockingThreads/SynchronizerLockingThreads005/TestDescription.java > 8231032 generic-all > + > +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi001/Multi001.java > 8231032 generic-all > +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi002/TestDescription.java > ?8231032 generic-all > +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi003/TestDescription.java > ?8231032 generic-all > +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi004/TestDescription.java > ?8231032 generic-all > +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi005/TestDescription.java > ?8231032 generic-all > + > > ############################################################################# > > --- old/test/jdk/ProblemList.txt??? 2019-09-15 19:41:51.817162845 -0400 > +++ new/test/jdk/ProblemList.txt??? 2019-09-15 19:41:50.703151149 -0400 > @@ -564,6 +564,8 @@ > ?javax/management/monitor/DerivedGaugeMonitorTest.java 8042211 > generic-all > > javax/management/remote/mandatory/connection/MultiThreadDeadLockTest.java > 8042215 generic-all > > +java/lang/management/ThreadMXBean/LockedSynchronizers.java 8231032 > generic-all > + > > ############################################################################ > > > ?# jdk_io > From david.holmes at oracle.com Sun Sep 15 23:57:01 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 16 Sep 2019 09:57:01 +1000 Subject: Urgent RFR: 8231034/8231033 Problem list tetss failing after JSR-166 refresh In-Reply-To: <40a30e97-5ebc-8ece-47d2-96804afb022c@oracle.com> References: <40a30e97-5ebc-8ece-47d2-96804afb022c@oracle.com> Message-ID: Thanks Joe. Will push once CI testing is verified. David On 16/09/2019 9:54 am, Joe Darcy wrote: > Looks fine David; thanks, > > -Joe > > On 9/15/2019 4:49 PM, David Holmes wrote: >> Bugs: https://bugs.openjdk.java.net/browse/JDK-8231033 >> ????? https://bugs.openjdk.java.net/browse/JDK-8231034 >> >> webrev: http://cr.openjdk.java.net/~dholmes/8231033-8231034/webrev/ >> (inline below) >> >> A bunch of mainly management tests (mostly in hotspot repo) are >> failing after the JSR-166 refresh to due changes in stack information >> and usage. These are causing significant disruption to our CI and so >> need to be ProblemListed while the tests are investigated and fixed. >> >> Testing: tier 1 - 3 (in progress) >> >> Thanks, >> David >> >> --- old/test/hotspot/jtreg/ProblemList.txt??? 2019-09-15 >> 19:41:48.446127451 -0400 >> +++ new/test/hotspot/jtreg/ProblemList.txt??? 2019-09-15 >> 19:41:47.344115881 -0400 >> @@ -90,6 +90,7 @@ >> ?# :hotspot_runtime >> >> ?runtime/jni/terminatedThread/TestTerminatedThread.java 8219652 aix-ppc64 >> +runtime/ReservedStack/ReservedStackTest.java 8231031 generic-all >> >> >> ############################################################################# >> >> >> @@ -204,4 +205,16 @@ >> >> >> vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn001/forceEarlyReturn001.java >> 7199837 generic-all >> >> +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/SynchronizerLockingThreads/SynchronizerLockingThreads001/TestDescription.java >> 8231032 generic-all >> +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/SynchronizerLockingThreads/SynchronizerLockingThreads002/TestDescription.java >> 8231032 generic-all >> +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/SynchronizerLockingThreads/SynchronizerLockingThreads003/TestDescription.java >> 8231032 generic-all >> +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/SynchronizerLockingThreads/SynchronizerLockingThreads004/TestDescription.java >> 8231032 generic-all >> +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/SynchronizerLockingThreads/SynchronizerLockingThreads005/TestDescription.java >> 8231032 generic-all >> + >> +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi001/Multi001.java >> 8231032 generic-all >> +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi002/TestDescription.java >> ?8231032 generic-all >> +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi003/TestDescription.java >> ?8231032 generic-all >> +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi004/TestDescription.java >> ?8231032 generic-all >> +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi005/TestDescription.java >> ?8231032 generic-all >> + >> >> ############################################################################# >> >> --- old/test/jdk/ProblemList.txt??? 2019-09-15 19:41:51.817162845 -0400 >> +++ new/test/jdk/ProblemList.txt??? 2019-09-15 19:41:50.703151149 -0400 >> @@ -564,6 +564,8 @@ >> ?javax/management/monitor/DerivedGaugeMonitorTest.java 8042211 >> generic-all >> >> javax/management/remote/mandatory/connection/MultiThreadDeadLockTest.java >> 8042215 generic-all >> >> +java/lang/management/ThreadMXBean/LockedSynchronizers.java 8231032 >> generic-all >> + >> >> ############################################################################ >> >> >> ?# jdk_io >> From Alan.Bateman at oracle.com Mon Sep 16 06:33:49 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 Sep 2019 07:33:49 +0100 Subject: [PATCH] Add *.iml to .hgignore and .gitignore In-Reply-To: References: Message-ID: <377456cc-caf5-d678-0b64-ce11d608959b@oracle.com> I think the .ignore files are maintained on build-dev. Note that .idea is already excluded and it contains the .iml and other workspace files are created for the IntelliJ project, maybe your setup might be different? -Alan. On 15/09/2019 21:22, JARvis PROgrammer wrote: > This is a small patch to disable tracking of configuration files of > Intellij-based IDEs (.iml) > Diff: > diff -r a6f653312b19 .gitignore > --- a/.gitignore Sun Sep 15 08:41:48 2019 +0200 > +++ b/.gitignore Sun Sep 15 21:11:13 2019 +0100 > @@ -1,6 +1,7 @@ > /build/ > /dist/ > /.idea/ > +*.iml > nbproject/private/ > /webrev > /.src-rev > diff -r a6f653312b19 .hgignore > --- a/.hgignore Sun Sep 15 08:41:48 2019 +0200 > +++ b/.hgignore Sun Sep 15 21:11:13 2019 +0100 > @@ -1,6 +1,7 @@ > ^build/ > ^dist/ > ^.idea/ > +*.iml > nbproject/private/ > ^webrev > ^.src-rev$ > Hosted diff-file: > https://gist.github.com/JarvisCraft/d016d39a0342d09ce3a0a22a1893841d > > PS: if it is an unneeded patch or a wrong mailing list, please inform me > > Thanks, > Peter From daniel.fuchs at oracle.com Mon Sep 16 10:40:02 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 16 Sep 2019 11:40:02 +0100 Subject: RFR 8221623 : Add StackWalker micro benchmarks to jdk repo In-Reply-To: References: Message-ID: <1408b71b-bf20-eb45-376d-bcd8dc2d3e3d@oracle.com> Hi Brent, The StackWalker benchmark look good to me. However I have some doubts about the the logging benchmark. Is the benchmark run in a single thread? If not then there doesn't seem any guarantee that each call to publish() will be immediately followed by a call to reset(), but instead, if you have two threads, you could see things like: T1: publish(); T2: publish(); => T1 record would be lost here T1: reset(); T2: reset(); => reset() would return null here best regards, -- daniel On 13/09/2019 23:07, Brent Christian wrote: > Hi, > > Please review these StackWalker and Throwable benchmarks for addition > into the JDK microbenchmarks. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8221623 > Webrev: > http://cr.openjdk.java.net/~bchristi/8221623/webrev07/ > > The StackWalker benchmarks use StackWalker's forEach(), walk(), and > Options to measure retrieval of various types of information from the > call stack. > > The Throwable benchmarks do corresponding exercises; there are also a > couple of Logging benchmarks. > > A JMH @Param is used to test a variety of call stack depths. > > > In the future, we might consider a benchmark for > Reflection.getCallerClass().? (It is more involved today to benchmark > that method than at the time these benchmarks were originally written, > so that one's commented out.) See JDK-8230976. > > Thanks, > -Brent > > 1. https://bugs.openjdk.java.net/browse/JDK-8230976 From thomas.stuefe at gmail.com Mon Sep 16 12:53:25 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 16 Sep 2019 14:53:25 +0200 Subject: RFR (L, final): 8218626: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: Message-ID: Hi Goetz, not a full review, just a small suggestion. In jvm.cpp you could just access ss->base() instead of ss->as_string() since the internal buffer is already NULL terminated and result_string does not outlive the stringStream object. Also it misses including ostream.hpp. Cheers, Thomas On Tue, Sep 10, 2019 at 4:46 PM Lindenmaier, Goetz < goetz.lindenmaier at sap.com> wrote: > Hi, > > the subject should mention 8218628. (Not 8218626). > Sorry for this! > > Best regards, > Goetz. > > From: Lindenmaier, Goetz > Sent: Dienstag, 10. September 2019 11:48 > To: 'Hotspot dev runtime' ; Java > Core Libs > Subject: RFR (L, final): 8218626: Add detailed message to > NullPointerException describing what is null. > > Hi, > > this is the implementation of JEP 358: Helpful NullPointerExceptions. > > The JEP is in status "Candidate". Coleen (many, many thanks!) ran > it through the Oracle-internal processes. Now I please need final reviews > for this change so that I can propose it to target jdk 14. > > JEP: https://bugs.openjdk.java.net/browse/JDK-8220715 > Enhancement: https://bugs.openjdk.java.net/browse/JDK-8218628 > webrev: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/16/ > > The change ran through a lot of testing, all jtreg and jck tests to name > only some. The webrev points to patch > > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/16/enable_NPE_message.patch > that enables the change by default, which was useful for testing to > assure the code is used in the tests. > I just pushed the change to jdk/submit once more. > > Please review. > > Thanks! > Goetz. > From kevin.rushforth at oracle.com Mon Sep 16 12:56:56 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 16 Sep 2019 05:56:56 -0700 Subject: RFR: JDK-8230649: Make jpackage tool an experimental feature In-Reply-To: <7c238d94-7450-5776-7af2-ec1d8f859db4@oracle.com> References: <49310c6b-b546-84a7-0f5a-d8aeb4a456f5@oracle.com> <402ff52f-7ce4-821c-1620-da2ff709b972@oracle.com> <7c238d94-7450-5776-7af2-ec1d8f859db4@oracle.com> Message-ID: <0d99a4b4-026f-b00a-724b-604b6ba71740@oracle.com> In that case, it may be better to issue any warnings about it being experimental directly from jpackage instead of relying on the incubating modules. -- Kevin On 9/15/2019 1:05 PM, Andy Herrick wrote: > yes - result of this change is as you suggest, everything shows this > warning, so we will need further discussions as to what it might mean > to make jpackage "experimental". > > /Andy > > On 9/15/2019 12:35 PM, Alan Bateman wrote: >> On 15/09/2019 14:58, Andy Herrick wrote: >>> Please review the jpackage fix for bug [1] at [2]. >>> >>> This is a fix for the JDK-8200758-branch branch of the open sandbox >>> repository (jpackage). >>> >>> This is the at least the first small set of changes that need to be >>> make to make jpackage an experimental package. >>> >>> ?- Add flags to the build so the module jdk.jpackage is built as an >>> experimental module. >>> >>> ?- Modify test programs to tolerate the warning emitted when >>> jpackage is run. >> I think this change will need discussion. Can you provide a summary >> on what you mean by "experimental package"? I remember seeing Mark's >> comment go by where he suggested that the tool should be an >> experimental feature but I'm not sure if this translates to a warning >> or a configure option. >> >> I see the JIRA issue references the JEP for Incubating Modules but >> I'm not sure that it makes sense here as jdk.jpackage doesn't export >> an API and will eagerly participate in service binding because it >> `provides java.util.spi.ToolProvider`. There are subtle issues around >> incubating modules that want to provide services that were not worked >> out in the JDK 9 time frame. In this case, java.base uses >> ToolProvider so jdk.jpackage will be resolved when it is observable. >> I assum `java -version` will print a warning and that will not be >> welcomed. >> >> -Alan >> From Alan.Bateman at oracle.com Mon Sep 16 13:06:18 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 Sep 2019 14:06:18 +0100 Subject: RFR: JDK-8230649: Make jpackage tool an experimental feature In-Reply-To: <0d99a4b4-026f-b00a-724b-604b6ba71740@oracle.com> References: <49310c6b-b546-84a7-0f5a-d8aeb4a456f5@oracle.com> <402ff52f-7ce4-821c-1620-da2ff709b972@oracle.com> <7c238d94-7450-5776-7af2-ec1d8f859db4@oracle.com> <0d99a4b4-026f-b00a-724b-604b6ba71740@oracle.com> Message-ID: <1b30c0e3-1a87-5c5d-ae34-c1c6634748b1@oracle.com> On 16/09/2019 13:56, Kevin Rushforth wrote: > In that case, it may be better to issue any warnings about it being > experimental directly from jpackage instead of relying on the > incubating modules. Incubating modules are incubating non-final APIs so I don't think it's the right solution here. I suspect what is needed is a combination of a warning message (from the tool) and documentation to make it clear that that the feature and CLI options aren't yet final. -Alan. From kevin.rushforth at oracle.com Mon Sep 16 13:58:16 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 16 Sep 2019 06:58:16 -0700 Subject: RFR: JDK-8230649: Make jpackage tool an experimental feature In-Reply-To: <1b30c0e3-1a87-5c5d-ae34-c1c6634748b1@oracle.com> References: <49310c6b-b546-84a7-0f5a-d8aeb4a456f5@oracle.com> <402ff52f-7ce4-821c-1620-da2ff709b972@oracle.com> <7c238d94-7450-5776-7af2-ec1d8f859db4@oracle.com> <0d99a4b4-026f-b00a-724b-604b6ba71740@oracle.com> <1b30c0e3-1a87-5c5d-ae34-c1c6634748b1@oracle.com> Message-ID: On 9/16/2019 6:06 AM, Alan Bateman wrote: > On 16/09/2019 13:56, Kevin Rushforth wrote: >> In that case, it may be better to issue any warnings about it being >> experimental directly from jpackage instead of relying on the >> incubating modules. > Incubating modules are incubating non-final APIs so I don't think it's > the right solution here. I suspect what is needed is a combination of > a warning message (from the tool) and documentation to make it clear > that that the feature and CLI options aren't yet final. Yes, that's what I was thinking as well, now that it's clear that the incubating module approach isn't the right one to use. -- Kevin From erik.joelsson at oracle.com Mon Sep 16 15:41:38 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 16 Sep 2019 08:41:38 -0700 Subject: [PATCH] Add *.iml to .hgignore and .gitignore In-Reply-To: <377456cc-caf5-d678-0b64-ce11d608959b@oracle.com> References: <377456cc-caf5-d678-0b64-ce11d608959b@oracle.com> Message-ID: <3de6b85c-6085-dbe5-8ac3-be714c973298@oracle.com> Hello, The .ignore file is currently in regexp format so new additions should probably be in that format. I don't object to ignoring .iml files. /Erik On 2019-09-15 23:33, Alan Bateman wrote: > > I think the .ignore files are maintained on build-dev. Note that .idea > is already excluded and it contains the .iml and other workspace files > are created for the IntelliJ project, maybe your setup might be > different? > > -Alan. > > > On 15/09/2019 21:22, JARvis PROgrammer wrote: >> This is a small patch to disable tracking of configuration files of >> Intellij-based IDEs (.iml) >> Diff: >> diff -r a6f653312b19 .gitignore >> --- a/.gitignore??????? Sun Sep 15 08:41:48 2019 +0200 >> +++ b/.gitignore??????? Sun Sep 15 21:11:13 2019 +0100 >> @@ -1,6 +1,7 @@ >> ? /build/ >> ? /dist/ >> ? /.idea/ >> +*.iml >> ? nbproject/private/ >> ? /webrev >> ? /.src-rev >> diff -r a6f653312b19 .hgignore >> --- a/.hgignore Sun Sep 15 08:41:48 2019 +0200 >> +++ b/.hgignore Sun Sep 15 21:11:13 2019 +0100 >> @@ -1,6 +1,7 @@ >> ? ^build/ >> ? ^dist/ >> ? ^.idea/ >> +*.iml >> ? nbproject/private/ >> ? ^webrev >> ? ^.src-rev$ >> Hosted diff-file: >> https://gist.github.com/JarvisCraft/d016d39a0342d09ce3a0a22a1893841d >> >> PS: if it is an unneeded patch or a wrong mailing list, please inform me >> >> Thanks, >> Peter > From TobiasDiez at gmx.de Sun Sep 15 09:33:20 2019 From: TobiasDiez at gmx.de (Tobias Diez) Date: Sun, 15 Sep 2019 11:33:20 +0200 Subject: [jpackage] Customize msi installer Message-ID: <000001d56ba8$9d862670$d8927350$@gmx.de> Hi, after experimenting with jpackage for creating a msi installer, I would like to suggest the following improvements: 1. Set the ARPPRODUCTICON property, that controls the icon displayed in Add/Remove Programs for your application. https://wixtoolset.org/documentation/manual/v3/howtos/ui_and_localization/co nfigure_arp_appearance.html e.g: (btw: it's strange that the icon ids end on exe) 2. Make it possible to customize the appearance of the installer. At least make it possible to specify WixUIBannerBmp and WixUIDialogBmp. I guess most people want to replace the default icons with their own ones. https://wixtoolset.org//documentation/manual/v3/wixui/wixui_customizations.h tml Best Tobias From yano-masanori at jp.fujitsu.com Fri Sep 13 03:41:34 2019 From: yano-masanori at jp.fujitsu.com (Yano, Masanori) Date: Fri, 13 Sep 2019 03:41:34 +0000 Subject: 8229471: Calendar under a specific timezone changes HOUR field when MILLISECOND field is changed In-Reply-To: <6bcfefbe-ffb9-a33d-23c3-3bffbae7dbbb@oracle.com> References: <3A451B05B742C24B92BEAC7B802BC85C2A0A626C@g01jpexmbkw06> <6bcfefbe-ffb9-a33d-23c3-3bffbae7dbbb@oracle.com> Message-ID: <3A451B05B742C24B92BEAC7B802BC85C2A0A6C9A@g01jpexmbkw06> Hi Naoto, Thank you for replying. I understand that this behavior is expected. I will consider the existing behavior. Regards, Masanori Yano > -----Original Message----- > From: naoto.sato at oracle.com [mailto:naoto.sato at oracle.com] > Sent: Friday, September 13, 2019 5:25 AM > To: Yano, Masanori ; > 'core-libs-dev at openjdk.java.net' > Cc: i18n-dev at openjdk.java.net > Subject: Re: 8229471: Calendar under a specific timezone changes HOUR field > when MILLISECOND field is changed > > Hi Masanori, > > Thank you for looking at the issue and your contribution. I am also > investigating it (as an assignee of the bug), and looking at this old > issue: > > https://bugs.openjdk.java.net/browse/JDK-4177484 > > The comment suggests that the existing behavior is the expected one. In > fact, your fix would break some regression test cases in > jdk/java/util/Calendar/CalendarRegression.java. > > I will need some more archaeological investigation, but I am inclined to > close it as not an issue at the moment. > > Naoto > > On 9/12/19 12:16 AM, Yano, Masanori wrote: > > Hello. > > > > I think JDK-8229471 occurs because a change of TimeZone is not considered > in getTime(). > > To resolve this problem, isTimeSet flag must be set to false when > setTimeZone() is called. > > > > Please review the following change. > > > > diff -r e1269de19aa5 > src/java.base/share/classes/java/util/Calendar.java > > --- a/src/java.base/share/classes/java/util/Calendar.java Thu Aug > 22 14:09:36 2019 -0700 > > +++ b/src/java.base/share/classes/java/util/Calendar.java Thu Sep > 12 11:45:37 2019 +0900 > > @@ -2901,7 +2901,7 @@ > > * generally, a call to setTimeZone() affects calls to set() > BEFORE AND > > * AFTER it up to the next call to complete(). > > */ > > - areAllFieldsSet = areFieldsSet = false; > > + isTimeSet = areAllFieldsSet = areFieldsSet = false; > > } > > > > /** > > diff -r e1269de19aa5 test/jdk/java/util/Calendar/Bug8229471.java > > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > > +++ b/test/jdk/java/util/Calendar/Bug8229471.java Thu Sep 12 > 11:45:37 2019 +0900 > > @@ -0,0 +1,22 @@ > > +/* > > + *@test > > + *@bug 8229471 > > + *@summary test for recompute when Calendar.setTimeZone() */ > > + > > +import java.util.Calendar; > > +import java.util.Date; > > +import java.util.Locale; > > +import java.util.TimeZone; > > + > > +public class Bug8229471 { > > + public static void main(String[] args) throws Exception { > > + Calendar calendar = Calendar.getInstance(new Locale("en", > "US")); > > + Date date1 = calendar.getTime(); > > + > calendar.setTimeZone(TimeZone.getTimeZone("Europe/Budapest")); > > + Date date2 = calendar.getTime(); > > + if (date1.equals(date2)) { > > + throw new RuntimeException("Bug8229471: failed. TimeZone > is not applied."); > > + } > > + } > > +} > > > > Regards, > > Masanori Yano > > From mrjarviscraft at gmail.com Mon Sep 16 17:58:48 2019 From: mrjarviscraft at gmail.com (JARvis PROgrammer) Date: Mon, 16 Sep 2019 20:58:48 +0300 Subject: [PATCH] Add *.iml to .hgignore and .gitignore In-Reply-To: <377456cc-caf5-d678-0b64-ce11d608959b@oracle.com> References: <377456cc-caf5-d678-0b64-ce11d608959b@oracle.com> Message-ID: Intellij configuration files may appear in directories other than /.idea/. For example the script suggested by AdoptOpenJDK generates such in the root directory. ??, 16 ????. 2019 ?., 9:33 Alan Bateman : > > I think the .ignore files are maintained on build-dev. Note that .idea > is already excluded and it contains the .iml and other workspace files > are created for the IntelliJ project, maybe your setup might be different? > > -Alan. > > > On 15/09/2019 21:22, JARvis PROgrammer wrote: > > This is a small patch to disable tracking of configuration files of > > Intellij-based IDEs (.iml) > > Diff: > > diff -r a6f653312b19 .gitignore > > --- a/.gitignore Sun Sep 15 08:41:48 2019 +0200 > > +++ b/.gitignore Sun Sep 15 21:11:13 2019 +0100 > > @@ -1,6 +1,7 @@ > > /build/ > > /dist/ > > /.idea/ > > +*.iml > > nbproject/private/ > > /webrev > > /.src-rev > > diff -r a6f653312b19 .hgignore > > --- a/.hgignore Sun Sep 15 08:41:48 2019 +0200 > > +++ b/.hgignore Sun Sep 15 21:11:13 2019 +0100 > > @@ -1,6 +1,7 @@ > > ^build/ > > ^dist/ > > ^.idea/ > > +*.iml > > nbproject/private/ > > ^webrev > > ^.src-rev$ > > Hosted diff-file: > > https://gist.github.com/JarvisCraft/d016d39a0342d09ce3a0a22a1893841d > > > > PS: if it is an unneeded patch or a wrong mailing list, please inform me > > > > Thanks, > > Peter > > From huizhe.wang at oracle.com Mon Sep 16 18:25:49 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 16 Sep 2019 11:25:49 -0700 Subject: RFR [14/java.xml] 8230814: Enable SAX ContentHandler to handle XML Declaration In-Reply-To: <55d6fd3d-470d-d548-7f9f-b8dc8533944a@oracle.com> References: <5fa47e8d-4512-0e13-f5c3-d315807fe32d@oracle.com> <55d6fd3d-470d-d548-7f9f-b8dc8533944a@oracle.com> Message-ID: <04bed9ba-8657-4b54-d604-1e40373a0bf6@oracle.com> On 9/14/19 1:08 AM, Alan Bateman wrote: > On 13/09/2019 21:50, Joe Wang wrote: >> : >> >> It can be said that the SAX project, in terms of the API work, was >> dead a long time ago. There hasn't been any updates/changes since SAX >> 2.0.2 released in 2004[1]. SAX is in public domain [2]. Sun/Oracle >> incorporated SAX2 in Java SE with a GPL license. I assume we're free >> to make changes. Please let me know if you think otherwise. > I'm not objecting to notifying the content handler of declarations. > I'm also not discussing licenses. I'm mostly concerned that > ContentHandler and all the other classes in this API point the reader > to the SAX project as the place to go for documentation and more > information. Has there been any effort to find a contact for the SAX > project on soucreforge and get them to put an EOL notice on the main > page? Alternatively, if the SAX API in Java SE is getting a second > wind then maybe the links to the SAX project could be reduced to a > historical note. I deliberately left the javadoc in the SAX package as they are. But I agree it may be worth it to address this aspect of the document. I suggest we do so with a separate doc-only request[1] to clarify the relationship with the SAX project, likely adding a short note in the package description and removing all other references. If you are okay, I'll keep this changeset the way it is, limiting it to the new method. [1] https://bugs.openjdk.java.net/browse/JDK-8231083 -Joe > > -Alan > > > > From peter.firmstone at zeus.net.au Mon Sep 16 21:15:26 2019 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Tue, 17 Sep 2019 07:15:26 +1000 Subject: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: References: <5D55DA9F.5050807@zeus.net.au> <8ce427f1-5473-9e2f-af85-ceb7b08ed419@oracle.com> <5D568810.8060503@zeus.net.au> <1d1ea235-77bc-9517-9f00-4053c71be759@oracle.com> <5D571F0A.8020709@zeus.net.au> <5D7C1313.9060709@zeus.net.au> <5D7D4BB9.1010408@zeus.net.au> Message-ID: <5D7FFB6E.9060907@zeus.net.au> Hi Alan, Your suspicion is correct. :) Thanks for the leads, I'll look into it further. Currently the policy implementation finds policy url's in system properties, "java.security.policy" and numbered policy locations with the prefix "policy.url." if the "java.security.policy" property doesn't begin with "=" (which represents java.security.policy==). Cheers, Peter. On 15/09/2019 10:58 PM, Alan Bateman wrote: > On 14/09/2019 21:21, Peter Firmstone wrote: >> Hi Alan, >> >> We've got a bunch of very old policy files in our test suite, so they >> still had policy grants using the extension directory property. The >> grant for the extension directory property was followed by a forward >> slash and asterix. Oddly when the property was missing the grant >> became a wildcard URL. Note this isn't the sun PolicyFile >> implementation, but our policy provider also augments, rather than >> replace, maybe there's a new policy file our provider isn't aware of? >> >> From memory there was something special about the way the extension >> directory property was treated by the policy provider, but I don't >> recall the details, the same problems don't appear to exist when >> other properties in policy files cannot be resolved. >> >> >> Modules that required permissions, seem to be service providers: > In jdk/jdk repo, the following policy files are merged in the build to > create the default policy: > > src/java.base/windows/lib/security/default.policy > src/java.base/solaris/lib/security/default.policy > src/java.base/share/lib/security/default.policy > > The default policy goes into a JDK internal location in the run-time > image and used by the PolicyFile implementation. If you look in there > you should see the permissions that are granted to the modules that > map to the platform class loader. The intention is that deployments > that are setting their own policy files don't need to be concerned > about the permissions of modules in the run-time image. I suspect you > are looking for a custom PolicyFile implementation to make use of > these defaults to avoid needing to be concerned with the specific > permissions that the modules in the run-time image. > > -Alan From philip.race at oracle.com Tue Sep 17 03:13:14 2019 From: philip.race at oracle.com (Philip Race) Date: Mon, 16 Sep 2019 20:13:14 -0700 Subject: Comments on jpackage (JEP 343) In-Reply-To: <20190903185855.D9F092BEC49@eggemoggin.niobe.net> References: <20190903185855.D9F092BEC49@eggemoggin.niobe.net> Message-ID: <5D804F4A.3010103@oracle.com> I've been thinking about this. output is nicely symmetrical with input and in the case of a default app-image it is more than a single item and personally I'd much rather it not clutter my working directory and again you get symmetry with input which you really want to specify but I'd concede it to be "." as a default over changing the name to dest ... There is also precedent : jlink uses -output and these two tools are going to be frequently used together. So I would like to see the status quo. -phil. On 9/3/19, 11:58 AM, mark.reinhold at oracle.com wrote: > - The `--output`/`-o` option is confusing. It doesn?t name the output > itself, but rather a directory into which the single item of output > will be placed. Typing `-o .` all the time is just annoying. It?d > be more logical to rename this option to `--dest`/`-d` and to make it > optional, with a default value of `.`. From philip.race at oracle.com Tue Sep 17 03:24:15 2019 From: philip.race at oracle.com (Philip Race) Date: Mon, 16 Sep 2019 20:24:15 -0700 Subject: Comments on jpackage (JEP 343) In-Reply-To: <5D804F4A.3010103@oracle.com> References: <20190903185855.D9F092BEC49@eggemoggin.niobe.net> <5D804F4A.3010103@oracle.com> Message-ID: <5D8051DF.2070903@oracle.com> > but I'd concede it to be "." as a default On second thoughts I am not sure about that either. I find it much cleaner to know what was generated by looking in a new directory rather than hunting in my current directory, especially for the default app-image case which will dump a bunch of unfamiliar files. -phil. On 9/16/19, 8:13 PM, Philip Race wrote: > I've been thinking about this. > output is nicely symmetrical with input and in the case of a default > app-image it is more than a single item > and personally I'd much rather it not clutter my working directory and > again you get symmetry with input > which you really want to specify but I'd concede it to be "." as a > default over changing the name to dest ... > > There is also precedent : > jlink uses -output and these two tools are going to be frequently used > together. > > So I would like to see the status quo. > > -phil. > > > On 9/3/19, 11:58 AM, mark.reinhold at oracle.com wrote: >> - The `--output`/`-o` option is confusing. It doesn?t name the >> output >> itself, but rather a directory into which the single item of output >> will be placed. Typing `-o .` all the time is just annoying. It?d >> be more logical to rename this option to `--dest`/`-d` and to >> make it >> optional, with a default value of `.`. From thomas.stuefe at gmail.com Tue Sep 17 07:06:07 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 17 Sep 2019 09:06:07 +0200 Subject: RFR (L, final): 8218626: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: Message-ID: Additionally, since 8224193, stringStream does not use RA anymore, so you do not need ResourceMarks for the backing buffer. 8224193 has been backported to 11, btw. On Mon, Sep 16, 2019 at 2:53 PM Thomas St?fe wrote: > Hi Goetz, > > not a full review, just a small suggestion. In jvm.cpp you could just > access ss->base() instead of ss->as_string() since the internal buffer is > already NULL terminated and result_string does not outlive the stringStream > object. Also it misses including ostream.hpp. > > Cheers, Thomas > > On Tue, Sep 10, 2019 at 4:46 PM Lindenmaier, Goetz < > goetz.lindenmaier at sap.com> wrote: > >> Hi, >> >> the subject should mention 8218628. (Not 8218626). >> Sorry for this! >> >> Best regards, >> Goetz. >> >> From: Lindenmaier, Goetz >> Sent: Dienstag, 10. September 2019 11:48 >> To: 'Hotspot dev runtime' ; Java >> Core Libs >> Subject: RFR (L, final): 8218626: Add detailed message to >> NullPointerException describing what is null. >> >> Hi, >> >> this is the implementation of JEP 358: Helpful NullPointerExceptions. >> >> The JEP is in status "Candidate". Coleen (many, many thanks!) ran >> it through the Oracle-internal processes. Now I please need final reviews >> for this change so that I can propose it to target jdk 14. >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8220715 >> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8218628 >> webrev: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/16/ >> >> The change ran through a lot of testing, all jtreg and jck tests to name >> only some. The webrev points to patch >> >> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/16/enable_NPE_message.patch >> that enables the change by default, which was useful for testing to >> assure the code is used in the tests. >> I just pushed the change to jdk/submit once more. >> >> Please review. >> >> Thanks! >> Goetz. >> > From ramanand.patil at oracle.com Tue Sep 17 08:18:37 2019 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Tue, 17 Sep 2019 01:18:37 -0700 (PDT) Subject: RFR: 8231098: (tz) Upgrade time-zone data to tzdata2019c Message-ID: <80fa7966-1731-4941-9343-2ee7428587fd@default> Hi all, Please review the patch for tzdata2019c integration into jdk project(jdk-14). Webrev: http://cr.openjdk.java.net/~rpatil/8231098/14/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8231098 The patch has passed all the related testing including JCK. Regards, Ramanand. From sverre.moe at gmail.com Tue Sep 17 08:25:40 2019 From: sverre.moe at gmail.com (Sverre Moe) Date: Tue, 17 Sep 2019 10:25:40 +0200 Subject: Comments on jpackage (JEP 343) In-Reply-To: <5D8051DF.2070903@oracle.com> References: <20190903185855.D9F092BEC49@eggemoggin.niobe.net> <5D804F4A.3010103@oracle.com> <5D8051DF.2070903@oracle.com> Message-ID: I have built many times with the new jpackage, but actually just now tried to install the package built by it. The new jpackage adds a lot of Requires to the built RPM package. We had the same problem with the old javapackager. Its default RPM spec file had a lot of Requires that made it difficult for us to install our package on different Linux distributions. We circumvented this by packaging the application image with the Gradle ospackage plugin for RPM and DEB packages. Only the last one of these requires is actually in our RPM spec file provided with --resource-dir. I cannot even install the package on the system I built it, because it cannot find libavcodec-ffmpeg.so.56 For OpenSUSE Leap 15.1, my Linux distribution there is no package that provides the libavcodec-ffmpeg. Are all these Requires actually necessary for running a JavaFX application on Linux? As mentioned we had packaged our JavaFX 8 application with Gradle ospackage plugin without all these Requires, and it has worked fine on RPM Linux distributions. ld-linux-x86-64.so.2()(64bit) ld-linux-x86-64.so.2(GLIBC_2.3)(64bit) libGL.so.1()(64bit) libX11.so.6()(64bit) libXext.so.6()(64bit) libXi.so.6()(64bit) libXrender.so.1()(64bit) libXtst.so.6()(64bit) libasound.so.2()(64bit) libasound.so.2(ALSA_0.9)(64bit) libasound.so.2(ALSA_0.9.0rc4)(64bit) libavcodec-ffmpeg.so.56()(64bit) libavcodec-ffmpeg.so.56(LIBAVCODEC_FFMPEG_56)(64bit) libavcodec.so.54()(64bit) libavcodec.so.54(LIBAVCODEC_54)(64bit) libavcodec.so.56()(64bit) libavcodec.so.56(LIBAVCODEC_56)(64bit) libavcodec.so.57()(64bit) libavcodec.so.57(LIBAVCODEC_57)(64bit) libavformat-ffmpeg.so.56()(64bit) libavformat-ffmpeg.so.56(LIBAVFORMAT_FFMPEG_56)(64bit) libavformat.so.54()(64bit) libavformat.so.54(LIBAVFORMAT_54)(64bit) libavformat.so.56()(64bit) libavformat.so.56(LIBAVFORMAT_56)(64bit) libavformat.so.57()(64bit) libavformat.so.57(LIBAVFORMAT_57)(64bit) libawt.so()(64bit) libawt_xawt.so()(64bit) libc.so.6()(64bit) libc.so.6(GLIBC_2.11)(64bit) libc.so.6(GLIBC_2.14)(64bit) libc.so.6(GLIBC_2.15)(64bit) libc.so.6(GLIBC_2.17)(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3)(64bit) libc.so.6(GLIBC_2.3.2)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.4)(64bit) libc.so.6(GLIBC_2.6)(64bit) libc.so.6(GLIBC_2.7)(64bit) libcairo.so.2()(64bit) libdl.so.2()(64bit) libdl.so.2(GLIBC_2.2.5)(64bit) libfreetype.so()(64bit) libfreetype.so.6()(64bit) libgdk-3.so.0()(64bit) libgdk-x11-2.0.so.0()(64bit) libgdk_pixbuf-2.0.so.0()(64bit) libgio-2.0.so.0()(64bit) libglib-2.0.so.0()(64bit) libgmodule-2.0.so.0()(64bit) libgobject-2.0.so.0()(64bit) libgstreamer-lite.so()(64bit) libgthread-2.0.so.0()(64bit) libgtk-3.so.0()(64bit) libgtk-x11-2.0.so.0()(64bit) libjava.so()(64bit) libjli.so()(64bit) libjvm.so()(64bit) libjvm.so(SUNWprivate_1.1)(64bit) libm.so.6()(64bit) libm.so.6(GLIBC_2.15)(64bit) libm.so.6(GLIBC_2.2.5)(64bit) libnet.so()(64bit) libpango-1.0.so.0()(64bit) libpangoft2-1.0.so.0()(64bit) libpthread.so.0()(64bit) libpthread.so.0(GLIBC_2.2.5)(64bit) libpthread.so.0(GLIBC_2.3.2)(64bit) librt.so.1()(64bit) librt.so.1(GLIBC_2.2.5)(64bit) libverify.so()(64bit) libz.so.1()(64bit) rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsXz) <= 5.2-1 rtld(GNU_HASH) xdg-utils From christoph.langer at sap.com Tue Sep 17 08:50:22 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 17 Sep 2019 08:50:22 +0000 Subject: RFR: 8228482: fix xlc16/xlclang comparison of distinct pointer types and string literal conversion warnings In-Reply-To: References: Message-ID: Hi Matthias, this seems fine to me. The change in NetworkInterface.c is correct, too. Best regards Christoph > -----Original Message----- > From: core-libs-dev On Behalf > Of Baesken, Matthias > Sent: Donnerstag, 25. Juli 2019 15:45 > To: Doerr, Martin ; 'hotspot- > dev at openjdk.java.net' ; core-libs- > dev at openjdk.java.net; net-dev at openjdk.java.net > Cc: 'ppc-aix-port-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: [CAUTION] RE: RFR: 8228482: fix xlc16/xlclang comparison of distinct > pointer types and string literal conversion warnings > > Thanks Martin . > May I get a second review ? > > Best regards, Matthias > > > From: Doerr, Martin > Sent: Mittwoch, 24. Juli 2019 12:14 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' ; core-libs- > dev at openjdk.java.net; net-dev at openjdk.java.net > Cc: 'ppc-aix-port-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: RE: RFR: 8228482: fix xlc16/xlclang comparison of distinct pointer > types and string literal conversion warnings > > Hi Matthias, > > I wouldn?t say ?looks good?, but I think it?s the right thing to do ?? > The type casts look correct to fit to the AIX headers. > > libodm_aix: > Good. Maybe we should open a new issue for freeing what?s returned by > odm_set_path and we could also remove the AIX 5 support. > > NetworkInterface.c: > Strange, but ok. Should be reviewed by somebody else in addition. > > Other files: > No comments. > > Best regards, > Martin > > > From: ppc-aix-port-dev bounces at openjdk.java.net bounces at openjdk.java.net>> On Behalf Of Baesken, Matthias > Sent: Dienstag, 23. Juli 2019 17:15 > To: 'hotspot-dev at openjdk.java.net' dev at openjdk.java.net>; core-libs- > dev at openjdk.java.net; net- > dev at openjdk.java.net > Cc: 'ppc-aix-port-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: RFR: 8228482: fix xlc16/xlclang comparison of distinct pointer types > and string literal conversion warnings > > Hello please review this patch . > > It fixes a couple of xlc16/xlclang warnings , especially comparison of distinct > pointer types and string literal conversion warnings . > > When building with xlc16/xlclang, we still have a couple of warnings that have > to be fixed : > warning: ISO C++11 does not allow conversion from string literal to 'char *' [- > Wwritable-strings] > for example : > /nightly/jdk/src/hotspot/os/aix/libodm_aix.cpp:81:18: warning: ISO C++11 > does not allow conversion from string literal to 'char *' [-Wwritable-strings] > odmWrapper odm("product", "/usr/lib/objrepos"); // could also use "lpp" > ^ > /nightly/jdk/src/hotspot/os/aix/libodm_aix.cpp:81:29: warning: ISO C++11 > does not allow conversion from string literal to 'char *' [-Wwritable-strings] > odmWrapper odm("product", "/usr/lib/objrepos"); // could also use "lpp" > ^ > > warning: comparison of distinct pointer types, for example : > > /nightly/jdk/src/java.desktop/aix/native/libawt/porting_aix.c:50:14: > warning: comparison of distinct pointer types ('void *' and 'char *') [- > Wcompare-distinct-pointer-types] > addr < (((char*)p->ldinfo_textorg) + p->ldinfo_textsize)) { > ~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > Bug/webrev : > > > https://bugs.openjdk.java.net/browse/JDK-8228482 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8228482.1/ > > > Thanks, Matthias > From pavel.rappo at oracle.com Tue Sep 17 08:55:26 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 17 Sep 2019 09:55:26 +0100 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: <275EC96C-CC39-41C8-9B9C-B917F25FAB70@oracle.com> References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> <87sgpblxns.fsf@oldenburg2.str.redhat.com> <7A46485C-E250-4E57-9FB0-B9D18CA70632@oracle.com> <60FD933F-51A5-4438-83AF-B3427CFDE60D@oracle.com> <8A9E3066-E6F6-4E65-BD02-DF0ACFF02FAD@oracle.com> <633A0CE3-C771-493B-89E3-7FA843C85183@oracle.com> <6b209e36-686f-7852-7fb8-3a0ef0e8423a@oracle.com> <4CAC6E8D-9198-4701-99C0-49901D72A396@oracle.com> <47acbb78-806f-2951-3b22-de6e7965f461@oracle.com> <275EC96C-CC39-41C8-9B9C-B917F25FAB70@oracle.com> Message-ID: <7D4375A7-E2CC-4297-92DF-A13FC9EF07AE@oracle.com> I have filed the CSR: https://bugs.openjdk.java.net/browse/JDK-8230965 > On 13 Sep 2019, at 11:21, Pavel Rappo wrote: > > Here's the latest webrev accumulating all the changes we've discussed so far: > > http://cr.openjdk.java.net/~prappo/8228580/webrev.03/ > > If people are okay with that I will proceed to creating a CSR. > >> On 12 Sep 2019, at 20:06, Alan Bateman wrote: >> >> On 12/09/2019 12:41, Chris Hegarty wrote: >>> Here is an initial attempt to document these timeout/retry properties. It?s effectively the wording lifted from the tech notes [1], with ?UDP? removed. >> Thanks, this look and dropping the reference to "UDP" make sense. >> >> One minor nit is that "are relevant to the DNS provider" might be better worded as "may be used when creating the initial context". This will fit nicely if/when someone adds a description to the @provides tag. At some point I hope the other properties can be used too but that is beyond the scope of JDK-8228580. >> >> -Alan > From goetz.lindenmaier at sap.com Tue Sep 17 09:23:18 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 17 Sep 2019 09:23:18 +0000 Subject: RFR (L, final): 8218626: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: Message-ID: Hi Thomas, thanks for pointing this out. I improved the placement of the ResourceMarks. Unfortunately, base() returns an immutable string, but for trim_well_known_class_names this does not work. So I'd propose this: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/17-incremental/ http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/17/ Best regards, Goetz. > -----Original Message----- > From: Thomas St?fe > Sent: Dienstag, 17. September 2019 09:06 > To: Lindenmaier, Goetz > Cc: Hotspot dev runtime ; Java Core > Libs > Subject: Re: RFR (L, final): 8218626: Add detailed message to > NullPointerException describing what is null. > > Additionally, since 8224193, stringStream does not use RA anymore, so you do > not need ResourceMarks for the backing buffer. 8224193 has been backported > to 11, btw. > > On Mon, Sep 16, 2019 at 2:53 PM Thomas St?fe > wrote: > > > Hi Goetz, > > not a full review, just a small suggestion. In jvm.cpp you could just > access ss->base() instead of ss->as_string() since the internal buffer is already > NULL terminated and result_string does not outlive the stringStream object. > Also it misses including ostream.hpp. > > Cheers, Thomas > > > On Tue, Sep 10, 2019 at 4:46 PM Lindenmaier, Goetz > > wrote: > > > Hi, > > the subject should mention 8218628. (Not 8218626). > Sorry for this! > > Best regards, > Goetz. > > From: Lindenmaier, Goetz > Sent: Dienstag, 10. September 2019 11:48 > To: 'Hotspot dev runtime' dev at openjdk.java.net >; Java > Core Libs dev at openjdk.java.net> > > Subject: RFR (L, final): 8218626: Add detailed message to > NullPointerException describing what is null. > > Hi, > > this is the implementation of JEP 358: Helpful > NullPointerExceptions. > > The JEP is in status "Candidate". Coleen (many, many thanks!) > ran > it through the Oracle-internal processes. Now I please need > final reviews > for this change so that I can propose it to target jdk 14. > > JEP: https://bugs.openjdk.java.net/browse/JDK-8220715 > Enhancement: https://bugs.openjdk.java.net/browse/JDK- > 8218628 > webrev: http://cr.openjdk.java.net/~goetz/wr19/8218628- > exMsg-NPE/16/ > > The change ran through a lot of testing, all jtreg and jck tests to > name > only some. The webrev points to patch > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg- > NPE/16/enable_NPE_message.patch > that enables the change by default, which was useful for > testing to > assure the code is used in the tests. > I just pushed the change to jdk/submit once more. > > Please review. > > Thanks! > Goetz. > From Alan.Bateman at oracle.com Tue Sep 17 10:00:12 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 17 Sep 2019 11:00:12 +0100 Subject: RFR [14/java.xml] 8230814: Enable SAX ContentHandler to handle XML Declaration In-Reply-To: <04bed9ba-8657-4b54-d604-1e40373a0bf6@oracle.com> References: <5fa47e8d-4512-0e13-f5c3-d315807fe32d@oracle.com> <55d6fd3d-470d-d548-7f9f-b8dc8533944a@oracle.com> <04bed9ba-8657-4b54-d604-1e40373a0bf6@oracle.com> Message-ID: <8327041d-9bd7-51f1-fbc5-a57fa59c14c5@oracle.com> On 16/09/2019 19:25, Joe Wang wrote: > : > > I deliberately left the javadoc in the SAX package as they are. But I > agree it may be worth it to address this aspect of the document. I > suggest we do so with a separate doc-only request[1] to clarify the > relationship with the SAX project, likely adding a short note in the > package description and removing all other references. If you are > okay, I'll keep this changeset the way it is, limiting it to the new > method. A separate issue is fine but I think important to do it in the same release where the APIs diverge to avoid confusing the reader (by redirecting them to stale API docs). -Alan From kevin.rushforth at oracle.com Tue Sep 17 12:24:46 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 17 Sep 2019 05:24:46 -0700 Subject: Comments on jpackage (JEP 343) In-Reply-To: <5D8051DF.2070903@oracle.com> References: <20190903185855.D9F092BEC49@eggemoggin.niobe.net> <5D804F4A.3010103@oracle.com> <5D8051DF.2070903@oracle.com> Message-ID: <4c9ee165-b724-4ed0-4563-1877f567067f@oracle.com> Hi Phil, In the app-image case it always creates a new directory with the name of the application underneath the dest/output directory for holding all of the files. So you either have: ?? /appname.ext or ?? /appname/ So I think "." is a reasonable default if not specified. As to whether to call it "--dest" or "--output", I don't have a strong opinion. There are precedents for both. -- Kevin On 9/16/2019 8:24 PM, Philip Race wrote: > > but I'd concede it to be "." as a default > > On second thoughts I am not sure about that either. > I find it much cleaner to know what was generated by looking in a new > directory rather than > hunting in my current directory, especially for the default app-image > case which will dump > a bunch of unfamiliar files. > > -phil. > > On 9/16/19, 8:13 PM, Philip Race wrote: >> I've been thinking about this. >> output is nicely symmetrical with input and in the case of a default >> app-image it is more than a single item >> and personally I'd much rather it not clutter my working directory >> and again you get symmetry with input >> which you really want to specify? but I'd concede it to be "." as a >> default over changing the name to dest ... >> >> There is also precedent : >> jlink uses -output and these two tools are going to be frequently >> used together. >> >> So I would like to see the status quo. >> >> -phil. >> >> >> On 9/3/19, 11:58 AM, mark.reinhold at oracle.com wrote: >>> ?? - The `--output`/`-o` option is confusing.? It doesn?t name the >>> output >>> ???? itself, but rather a directory into which the single item of >>> output >>> ???? will be placed.? Typing `-o .` all the time is just annoying.? >>> It?d >>> ???? be more logical to rename this option to `--dest`/`-d` and to >>> make it >>> ???? optional, with a default value of `.`. From pavel.rappo at oracle.com Tue Sep 17 13:09:16 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 17 Sep 2019 14:09:16 +0100 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: <7D4375A7-E2CC-4297-92DF-A13FC9EF07AE@oracle.com> References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> <87sgpblxns.fsf@oldenburg2.str.redhat.com> <7A46485C-E250-4E57-9FB0-B9D18CA70632@oracle.com> <60FD933F-51A5-4438-83AF-B3427CFDE60D@oracle.com> <8A9E3066-E6F6-4E65-BD02-DF0ACFF02FAD@oracle.com> <633A0CE3-C771-493B-89E3-7FA843C85183@oracle.com> <6b209e36-686f-7852-7fb8-3a0ef0e8423a@oracle.com> <4CAC6E8D-9198-4701-99C0-49901D72A396@oracle.com> <47acbb78-806f-2951-3b22-de6e7965f461@oracle.com> <275EC96C-CC39-41C8-9B9C-B917F25FAB70@oracle.com> <7D4375A7-E2CC-4297-92DF-A13FC9EF07AE@oracle.com> Message-ID: Milan, While the CSR is being processed, could we maybe think of some additional testing for that change? Otherwise, that test seems kind of anemic. It makes sure that the query doesn't hang, but that's about it. It doesn't check that the timeout is respected. I was wondering if you could propose some way of testing that. > On 17 Sep 2019, at 09:55, Pavel Rappo wrote: > > I have filed the CSR: > > https://bugs.openjdk.java.net/browse/JDK-8230965 > >> On 13 Sep 2019, at 11:21, Pavel Rappo wrote: >> >> Here's the latest webrev accumulating all the changes we've discussed so far: >> >> http://cr.openjdk.java.net/~prappo/8228580/webrev.03/ >> >> If people are okay with that I will proceed to creating a CSR. From goetz.lindenmaier at sap.com Tue Sep 17 14:18:03 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 17 Sep 2019 14:18:03 +0000 Subject: RFR (L, final): 8218626: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: Message-ID: @core-libs experts, I would appreciate comments on the changes to NullPointerException.java, especially wrt. the Javadoc comment. The change there is S. Best regards, Goetz. > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Dienstag, 10. September 2019 11:48 > To: 'Hotspot dev runtime' ; Java Core > Libs > Subject: RFR (L, final): 8218626: Add detailed message to NullPointerException > describing what is null. > > Hi, > > > > this is the implementation of JEP 358: Helpful NullPointerExceptions. > > > > The JEP is in status "Candidate". Coleen (many, many thanks!) ran > > it through the Oracle-internal processes. Now I please need final reviews > > for this change so that I can propose it to target jdk 14. > > > > JEP: https://bugs.openjdk.java.net/browse/JDK-8220715 > > Enhancement: https://bugs.openjdk.java.net/browse/JDK-8218628 > > webrev: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/16/ > > > > The change ran through a lot of testing, all jtreg and jck tests to name > > only some. The webrev points to patch > > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg- > NPE/16/enable_NPE_message.patch > > that enables the change by default, which was useful for testing to > > assure the code is used in the tests. > > I just pushed the change to jdk/submit once more. > > > > Please review. > > > > Thanks! > > Goetz. From martinrb at google.com Tue Sep 17 15:29:28 2019 From: martinrb at google.com (Martin Buchholz) Date: Tue, 17 Sep 2019 08:29:28 -0700 Subject: RFR: 8231098: (tz) Upgrade time-zone data to tzdata2019c In-Reply-To: <80fa7966-1731-4941-9343-2ee7428587fd@default> References: <80fa7966-1731-4941-9343-2ee7428587fd@default> Message-ID: Looks good to me. At Google we also integrated tzdata2019c, and it was uneventful (good!). But we're still using rearguard format. The vanguard/rearguard distinction is a source of errors, so it should be made clear what format is being used to import the files. If you have a script to update the jdk sources, perhaps it should be checked in to openjdk? If these files are in vanguard format, is there a trap for those of us doing backports to jdks that only support rearguard? On Tue, Sep 17, 2019 at 1:19 AM Ramanand Patil wrote: > Hi all, > Please review the patch for tzdata2019c integration into jdk > project(jdk-14). > Webrev: http://cr.openjdk.java.net/~rpatil/8231098/14/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8231098 > > The patch has passed all the related testing including JCK. > > Regards, > Ramanand. > From thomas.stuefe at gmail.com Tue Sep 17 16:09:31 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 17 Sep 2019 18:09:31 +0200 Subject: RFR (L, final): 8218626: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: Message-ID: Makes sense Goetz. Cheers, Thomas On Tue, Sep 17, 2019 at 11:23 AM Lindenmaier, Goetz < goetz.lindenmaier at sap.com> wrote: > Hi Thomas, > > thanks for pointing this out. I improved the placement > of the ResourceMarks. > Unfortunately, base() returns an immutable string, but > for trim_well_known_class_names this does not work. > So I'd propose this: > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/17-incremental/ > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/17/ > > Best regards, > Goetz. > > > -----Original Message----- > > From: Thomas St?fe > > Sent: Dienstag, 17. September 2019 09:06 > > To: Lindenmaier, Goetz > > Cc: Hotspot dev runtime ; Java > Core > > Libs > > Subject: Re: RFR (L, final): 8218626: Add detailed message to > > NullPointerException describing what is null. > > > > Additionally, since 8224193, stringStream does not use RA anymore, so > you do > > not need ResourceMarks for the backing buffer. 8224193 has been > backported > > to 11, btw. > > > > On Mon, Sep 16, 2019 at 2:53 PM Thomas St?fe > > wrote: > > > > > > Hi Goetz, > > > > not a full review, just a small suggestion. In jvm.cpp you could > just > > access ss->base() instead of ss->as_string() since the internal buffer > is already > > NULL terminated and result_string does not outlive the stringStream > object. > > Also it misses including ostream.hpp. > > > > Cheers, Thomas > > > > > > On Tue, Sep 10, 2019 at 4:46 PM Lindenmaier, Goetz > > > wrote: > > > > > > Hi, > > > > the subject should mention 8218628. (Not 8218626). > > Sorry for this! > > > > Best regards, > > Goetz. > > > > From: Lindenmaier, Goetz > > Sent: Dienstag, 10. September 2019 11:48 > > To: 'Hotspot dev runtime' > dev at openjdk.java.net >; > Java > > Core Libs > dev at openjdk.java.net> > > > Subject: RFR (L, final): 8218626: Add detailed message to > > NullPointerException describing what is null. > > > > Hi, > > > > this is the implementation of JEP 358: Helpful > > NullPointerExceptions. > > > > The JEP is in status "Candidate". Coleen (many, many > thanks!) > > ran > > it through the Oracle-internal processes. Now I please > need > > final reviews > > for this change so that I can propose it to target jdk 14. > > > > JEP: https://bugs.openjdk.java.net/browse/JDK-8220715 > > Enhancement: https://bugs.openjdk.java.net/browse/JDK- > > 8218628 > > webrev: http://cr.openjdk.java.net/~goetz/wr19/8218628- > > exMsg-NPE/16/ > > > > The change ran through a lot of testing, all jtreg and jck > tests to > > name > > only some. The webrev points to patch > > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg- > > NPE/16/enable_NPE_message.patch > > that enables the change by default, which was useful for > > testing to > > assure the code is used in the tests. > > I just pushed the change to jdk/submit once more. > > > > Please review. > > > > Thanks! > > Goetz. > > > > From huizhe.wang at oracle.com Tue Sep 17 16:26:30 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 17 Sep 2019 09:26:30 -0700 Subject: RFR [14/java.xml] 8230814: Enable SAX ContentHandler to handle XML Declaration In-Reply-To: <8327041d-9bd7-51f1-fbc5-a57fa59c14c5@oracle.com> References: <5fa47e8d-4512-0e13-f5c3-d315807fe32d@oracle.com> <55d6fd3d-470d-d548-7f9f-b8dc8533944a@oracle.com> <04bed9ba-8657-4b54-d604-1e40373a0bf6@oracle.com> <8327041d-9bd7-51f1-fbc5-a57fa59c14c5@oracle.com> Message-ID: On 9/17/19 3:00 AM, Alan Bateman wrote: > On 16/09/2019 19:25, Joe Wang wrote: >> : >> >> I deliberately left the javadoc in the SAX package as they are. But I >> agree it may be worth it to address this aspect of the document. I >> suggest we do so with a separate doc-only request[1] to clarify the >> relationship with the SAX project, likely adding a short note in the >> package description and removing all other references. If you are >> okay, I'll keep this changeset the way it is, limiting it to the new >> method. > A separate issue is fine but I think important to do it in the same > release where the APIs diverge to avoid confusing the reader (by > redirecting them to stale API docs). Agree, will do it next while we all are here on the issue. -Joe > > -Alan From sean.coffey at oracle.com Tue Sep 17 16:27:33 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 17 Sep 2019 17:27:33 +0100 Subject: RFR: 8231124: Missing closedir call with JDK-8223490 Message-ID: A minor issue that was introduced via my recent JDK-8223490 fix. One which I noticed while backporting the edits.. https://bugs.openjdk.java.net/browse/JDK-8231124 proposed patch: diff --git a/src/java.base/unix/native/libjava/TimeZone_md.c b/src/java.base/unix/native/libjava/TimeZone_md.c --- a/src/java.base/unix/native/libjava/TimeZone_md.c +++ b/src/java.base/unix/native/libjava/TimeZone_md.c @@ -130,11 +130,6 @@ ???? char *tz = NULL; ???? int res; -??? dirp = opendir(dir); -??? if (dirp == NULL) { -??????? return NULL; -??? } - ???? if (strcmp(dir, ZONEINFO_DIR) == 0) { ???????? /* fast path for 1st iteration */ ???????? for (unsigned int i = 0; i < sizeof (popularZones) / sizeof (popularZones[0]); i++) { @@ -151,6 +146,11 @@ ???????? } ???? } +??? dirp = opendir(dir); +??? if (dirp == NULL) { +??????? return NULL; +??? } + ???? while ((dp = readdir(dirp)) != NULL) { ???????? /* ????????? * Skip '.' and '..' (and possibly other .* files) == regards, Sean. From naoto.sato at oracle.com Tue Sep 17 16:37:04 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 17 Sep 2019 09:37:04 -0700 Subject: RFR: 8231124: Missing closedir call with JDK-8223490 In-Reply-To: References: Message-ID: Looks good. Naoto On 9/17/19 9:27 AM, Se?n Coffey wrote: > A minor issue that was introduced via my recent JDK-8223490 fix. One > which I noticed while backporting the edits.. > > https://bugs.openjdk.java.net/browse/JDK-8231124 > > proposed patch: > diff --git a/src/java.base/unix/native/libjava/TimeZone_md.c > b/src/java.base/unix/native/libjava/TimeZone_md.c > --- a/src/java.base/unix/native/libjava/TimeZone_md.c > +++ b/src/java.base/unix/native/libjava/TimeZone_md.c > @@ -130,11 +130,6 @@ > ???? char *tz = NULL; > ???? int res; > > -??? dirp = opendir(dir); > -??? if (dirp == NULL) { > -??????? return NULL; > -??? } > - > ???? if (strcmp(dir, ZONEINFO_DIR) == 0) { > ???????? /* fast path for 1st iteration */ > ???????? for (unsigned int i = 0; i < sizeof (popularZones) / sizeof > (popularZones[0]); i++) { > @@ -151,6 +146,11 @@ > ???????? } > ???? } > > +??? dirp = opendir(dir); > +??? if (dirp == NULL) { > +??????? return NULL; > +??? } > + > ???? while ((dp = readdir(dirp)) != NULL) { > ???????? /* > ????????? * Skip '.' and '..' (and possibly other .* files) > > > == > > regards, > Sean. > > From naoto.sato at oracle.com Tue Sep 17 16:45:15 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 17 Sep 2019 09:45:15 -0700 Subject: RFR: 8231098: (tz) Upgrade time-zone data to tzdata2019c In-Reply-To: References: <80fa7966-1731-4941-9343-2ee7428587fd@default> Message-ID: <18276aaf-6a9c-550b-1619-13a9c550fd04@oracle.com> +1 On 9/17/19 8:29 AM, Martin Buchholz wrote: > Looks good to me. > At Google we also integrated tzdata2019c, and it was uneventful (good!). > But we're still using rearguard format. > The vanguard/rearguard distinction is a source of errors, so it should be > made clear what format is being used to import the files. > If you have a script to update the jdk sources, perhaps it should be > checked in to openjdk? > If these files are in vanguard format, is there a trap for those of us > doing backports to jdks that only support rearguard? Can't think of any off the top of my head, Martin. The build tool internally converts vanguard data into rearguard compatible, by adjusting the standard offsets, and build into tzdb.dat (which should even be compatible to prior JDK runtimes). Naoto > > On Tue, Sep 17, 2019 at 1:19 AM Ramanand Patil > wrote: > >> Hi all, >> Please review the patch for tzdata2019c integration into jdk >> project(jdk-14). >> Webrev: http://cr.openjdk.java.net/~rpatil/8231098/14/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8231098 >> >> The patch has passed all the related testing including JCK. >> >> Regards, >> Ramanand. >> From martinrb at google.com Tue Sep 17 17:14:35 2019 From: martinrb at google.com (Martin Buchholz) Date: Tue, 17 Sep 2019 10:14:35 -0700 Subject: RFR: 8231098: (tz) Upgrade time-zone data to tzdata2019c In-Reply-To: <18276aaf-6a9c-550b-1619-13a9c550fd04@oracle.com> References: <80fa7966-1731-4941-9343-2ee7428587fd@default> <18276aaf-6a9c-550b-1619-13a9c550fd04@oracle.com> Message-ID: On Tue, Sep 17, 2019 at 9:45 AM wrote: > +1 > > On 9/17/19 8:29 AM, Martin Buchholz wrote: > > Looks good to me. > > At Google we also integrated tzdata2019c, and it was uneventful (good!). > > But we're still using rearguard format. > > The vanguard/rearguard distinction is a source of errors, so it should be > > made clear what format is being used to import the files. > > If you have a script to update the jdk sources, perhaps it should be > > checked in to openjdk? > > If these files are in vanguard format, is there a trap for those of us > > doing backports to jdks that only support rearguard? > > Can't think of any off the top of my head, Martin. The build tool > Which build tool? TzdbZoneRulesCompiler? > internally converts vanguard data into rearguard compatible, by > adjusting the standard offsets, and build into tzdb.dat (which should > even be compatible to prior JDK runtimes). > So ... a change like this one is created by copying selected vanguard format files from the tzdata source distribution into openjdk, and then TzdbZoneRulesCompiler converts to rearguard format internally? At Google, we chose to run tzdata's own tool to convert to rearguard format and then check in those data files into the jdk source tree. I worry that when other engineers backport to older releases, if only the data files are copied, then conversion to rearguard format will not happen, with bad results. From naoto.sato at oracle.com Tue Sep 17 17:54:49 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 17 Sep 2019 10:54:49 -0700 Subject: RFR: 8231098: (tz) Upgrade time-zone data to tzdata2019c In-Reply-To: References: <80fa7966-1731-4941-9343-2ee7428587fd@default> <18276aaf-6a9c-550b-1619-13a9c550fd04@oracle.com> Message-ID: On 9/17/19 10:14 AM, Martin Buchholz wrote: > > > On Tue, Sep 17, 2019 at 9:45 AM > wrote: > > +1 > > On 9/17/19 8:29 AM, Martin Buchholz wrote: > > Looks good to me. > > At Google we also integrated tzdata2019c, and it was uneventful > (good!). > > But we're still using rearguard format. > > The vanguard/rearguard distinction is a source of errors, so it > should be > > made clear what format is being used to import the files. > > If you have a script to update the jdk sources, perhaps it should be > > checked in to openjdk? > > If these files are in vanguard format, is there a trap for those > of us > > doing backports to jdks that only support rearguard? > > Can't think of any off the top of my head, Martin. The build tool > > > Which build tool??TzdbZoneRulesCompiler? Yes. > > internally converts vanguard data into rearguard compatible, by > adjusting the standard offsets, and build into tzdb.dat (which should > even be compatible to prior JDK runtimes). > > > So ... a change like this one is created by copying selected vanguard > format files from the tzdata source distribution into openjdk, and > then?TzdbZoneRulesCompiler converts to rearguard format internally?? At > Google, we chose to run tzdata's?own?tool to convert to rearguard format > and then check in those data files into the jdk source tree. The tool will not convert the file format to rearguard. Read the vanguard format file, then converts the data into tzdb.dat that can be recognized by prior runtimes. > > I worry that when other engineers backport to older releases, if only > the data files are copied, then conversion to rearguard format will not > happen,?with bad results. If an engineer only backports the vanguard files into older releases (before the vanguard support), I don't think the JDK build will succeed. Build will fail on creating tzdb.dat file. Naoto From andy.herrick at oracle.com Tue Sep 17 19:17:35 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 17 Sep 2019 15:17:35 -0400 Subject: RFR: JDK-8230920: jpackage problems when -input dir contains any files with "cfg" extension. Message-ID: <1f273c64-8047-7fd7-e919-0b2243b9c67e@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). On Windows? when building MSI, the original application name was determined by looking into the /app dir for a ".cfg" file. The problem was that: ?- There may be application files with ".cfg" extension. ?- There may be multiple ".cfg" files due to --add-launcher option(s) Instead we create an ".id" in the root of the app-image , to insure we can derive application name from app-image. [1] https://bugs.openjdk.java.net/browse/JDK-8230920 [2] http://cr.openjdk.java.net/~herrick/8230920 Thanks Andy, From alexey.semenyuk at oracle.com Tue Sep 17 19:51:17 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Tue, 17 Sep 2019 15:51:17 -0400 Subject: RFR: JDK-8230920: jpackage problems when -input dir contains any files with "cfg" extension. In-Reply-To: <1f273c64-8047-7fd7-e919-0b2243b9c67e@oracle.com> References: <1f273c64-8047-7fd7-e919-0b2243b9c67e@oracle.com> Message-ID: <3ea93022-5e17-9115-ba06-630c590e096c@oracle.com> On 9/17/2019 3:17 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). > > On Windows? when building MSI, the original application name was > determined by looking into the /app dir for a ".cfg" file. > > The problem was that: > > ?- There may be application files with ".cfg" extension. > > ?- There may be multiple ".cfg" files due to --add-launcher option(s) > > Instead we create an ".id" in the root of the > app-image , to insure we can derive application name from app-image. `.id` will be another well known file. Why it is better than `app/.cfg`? Because there can be multiple `app/.cfg` files and only a single `.id`? What will prevent people from creating their own .id files? I don't like this solution, to be honest. Its only benefit is that it is simple. Can we instead put some data in `app/.cfg` file for the main launcher when building app image so that bundle packagers can read all .cfg files and find the one that corresponds to the main launcher and thus get application name? - Alexey > > [1] https://bugs.openjdk.java.net/browse/JDK-8230920 > [2] http://cr.openjdk.java.net/~herrick/8230920 > > > Thanks > > Andy, > From andy.herrick at oracle.com Tue Sep 17 20:24:28 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 17 Sep 2019 16:24:28 -0400 Subject: RFR: JDK-8230920: jpackage problems when -input dir contains any files with "cfg" extension. In-Reply-To: <3ea93022-5e17-9115-ba06-630c590e096c@oracle.com> References: <1f273c64-8047-7fd7-e919-0b2243b9c67e@oracle.com> <3ea93022-5e17-9115-ba06-630c590e096c@oracle.com> Message-ID: <1d2fc516-9d65-d63c-64b5-43617ba9daf6@oracle.com> On 9/17/2019 3:51 PM, Alexey Semenyuk wrote: > > > On 9/17/2019 3:17 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). >> >> On Windows? when building MSI, the original application name was >> determined by looking into the /app dir for a ".cfg" file. >> >> The problem was that: >> >> ?- There may be application files with ".cfg" extension. >> >> ?- There may be multiple ".cfg" files due to --add-launcher option(s) >> >> Instead we create an ".id" in the root of the >> app-image , to insure we can derive application name from app-image. > `.id` will be another well known file. Why it is > better than `app/.cfg`? Because there can be > multiple `app/.cfg` files and only a single > `.id`? What will prevent people from creating their > own .id files? because any file created by user will be in app directory, not in root. > I don't like this solution, to be honest. Its only benefit is that it > is simple. Can we instead put some data in `app/ name>.cfg` file for the main launcher when building app image so that > bundle packagers can read all .cfg files and find the one that > corresponds to the main launcher and thus get application name? I began implementing it this way, adding an app.isMain=true or app.isMain=false entry in each cfg file (at least those generated by us).? That made it far more complicated.? Just to determine the application name required reading and parsing all the cfg files. There is currently no other reason for the bundling code to ever read these files, so I reverted to this simpler solution. /Andy > > - Alexey >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8230920 >> [2] http://cr.openjdk.java.net/~herrick/8230920 >> >> >> Thanks >> >> Andy, >> > From forax at univ-mlv.fr Tue Sep 17 21:51:23 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 17 Sep 2019 23:51:23 +0200 (CEST) Subject: RFR (L, final): 8218626: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: Message-ID: <563186416.1041616.1568757083163.JavaMail.zimbra@u-pem.fr> Hi Goetz, in bytecodeUtils.cpp, in print_local_var(), i believe that the code if (!method->is_static() && (slot == 0)) { os->print("this"); } ... is only true if the bytecode is generated by javac and ecj, tools like proguard that tries to obfuscate the code will reuse the slot 0 once "this" is not needed anymore. This is obviously also true for any other parameters, so in my opinion, you should not try to be too heroic here and always display "local%d". The other solution is to propagate "this" and "parameter%d" during the static analysis, so "this" will become "local0" once a store_0 is seen. R?mi ----- Mail original ----- > De: "Goetz Lindenmaier" > ?: "hotspot-runtime-dev" , "core-libs-dev" > Envoy?: Mardi 17 Septembre 2019 16:18:03 > Objet: RE: RFR (L, final): 8218626: Add detailed message to NullPointerException describing what is null. > @core-libs experts, I would appreciate comments on the changes > to NullPointerException.java, especially wrt. the Javadoc comment. > The change there is S. > > Best regards, > Goetz. > >> -----Original Message----- >> From: Lindenmaier, Goetz >> Sent: Dienstag, 10. September 2019 11:48 >> To: 'Hotspot dev runtime' ; Java Core >> Libs >> Subject: RFR (L, final): 8218626: Add detailed message to NullPointerException >> describing what is null. >> >> Hi, >> >> >> >> this is the implementation of JEP 358: Helpful NullPointerExceptions. >> >> >> >> The JEP is in status "Candidate". Coleen (many, many thanks!) ran >> >> it through the Oracle-internal processes. Now I please need final reviews >> >> for this change so that I can propose it to target jdk 14. >> >> >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8220715 >> >> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8218628 >> >> webrev: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/16/ >> >> >> >> The change ran through a lot of testing, all jtreg and jck tests to name >> >> only some. The webrev points to patch >> >> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg- >> NPE/16/enable_NPE_message.patch >> >> that enables the change by default, which was useful for testing to >> >> assure the code is used in the tests. >> >> I just pushed the change to jdk/submit once more. >> >> >> >> Please review. >> >> >> >> Thanks! >> > > Goetz. From david.holmes at oracle.com Tue Sep 17 22:47:29 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Sep 2019 08:47:29 +1000 Subject: Concurrent Hash Map javadoc question In-Reply-To: References: Message-ID: <471111c8-169a-4bd0-c05f-fe2cd7b27f4d@oracle.com> Re-directing to core-libs-dev mailing list. David On 18/09/2019 5:45 am, Keith Turner wrote: > The javadoc for ConcurrentHashMap.computeIfAbsent() states the > remapping function is applied at most once. The functions > computeIfPresent() and compute() do not explicitly state if the > remapping functions could possibly be run multiple times. Does anyone > know if computeIfPresent() and compute() are guaranteed to only run > the remapping functions at most once? If so, should the javadoc be > updated? > > Thanks, > > Keith > From alexander.matveev at oracle.com Wed Sep 18 02:42:01 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Tue, 17 Sep 2019 19:42:01 -0700 Subject: RFR: JDK-8230654: jpackage package-type dmg on macOS Message-ID: <94fa6522-c5ca-c305-b257-71388e97bb13@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). - Added link to "/Application" folder to DMG for drag and drop app to this folder. - Added background image with arrow pointing from App icon to Application folder. - If adding link and image to DMG fails it will not be considered critical error. In headless environment it might not work correctly. - See JBS issue for screenshot on how DMG will looks like with this fix. [1] https://bugs.openjdk.java.net/browse/JDK-8230654 [2] http://cr.openjdk.java.net/~almatvee/8230654/webrev.01/ Thanks, Alexander From mp at jugs.org Wed Sep 18 06:52:51 2019 From: mp at jugs.org (Michael Paus) Date: Wed, 18 Sep 2019 08:52:51 +0200 Subject: RFR: JDK-8230654: jpackage package-type dmg on macOS In-Reply-To: References: Message-ID: <3ae6caf7-6161-687b-3a60-aa54f9f52fb7@jugs.org> Hi, why are there scrollbars in the image on JBS? When you normally open a DMG you do not get scrollbars. Michael > Message: 6 > Date: Tue, 17 Sep 2019 19:42:01 -0700 > From: Alexander Matveev > To: core-libs-dev > Subject: RFR: JDK-8230654: jpackage package-type dmg on macOS > Message-ID: <94fa6522-c5ca-c305-b257-71388e97bb13 at oracle.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > 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). > > - Added link to "/Application" folder to DMG for drag and drop app to > this folder. > - Added background image with arrow pointing from App icon to > Application folder. > - If adding link and image to DMG fails it will not be considered > critical error. In headless environment it might not work correctly. > - See JBS issue for screenshot on how DMG will looks like with this fix. > > [1] https://bugs.openjdk.java.net/browse/JDK-8230654 > > [2] http://cr.openjdk.java.net/~almatvee/8230654/webrev.01/ > > Thanks, > Alexander From goetz.lindenmaier at sap.com Wed Sep 18 07:37:36 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 18 Sep 2019 07:37:36 +0000 Subject: RFR (L, final): 8218626: Add detailed message to NullPointerException describing what is null. In-Reply-To: <563186416.1041616.1568757083163.JavaMail.zimbra@u-pem.fr> References: <563186416.1041616.1568757083163.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Remi, > in bytecodeUtils.cpp, in print_local_var(), > i believe that the code > if (!method->is_static() && (slot == 0)) { > os->print("this"); > } > ... > is only true if the bytecode is generated by javac and ecj, tools like proguard > that tries to obfuscate the code will reuse the slot 0 once "this" is not needed > anymore. > This is obviously also true for any other parameters, so in my opinion, you > should not try to be too heroic here and always display "local%d". Yes, you are right. I assume the bytecode local slots are mapped 1:1 to the parameters and are not reused for other values. > The other solution is to propagate "this" and "parameter%d" during the static > analysis, so "this" will become "local0" once a store_0 is seen. It would be possible to spot the place where "this" is first overwritten. For other parameters, this is not feasible, they are not read-only, so stores don't indicate obfuscation. I could mark the whole method as 'obfuscated' once I see a store_0, and then print "local" instead of "parameter" in all places. This does not work for static methods, though. Nor for methods where "this" is live to the end, but the parameter slots are reused. For obfuscated methods I would claim that printing "this" etc is fine even if the slot is reused for another value. It just adds to the obfuscation! But there might be code that is just optimized and not meant to be obfuscated. Best regards, Goetz. > > R?mi > > ----- Mail original ----- > > De: "Goetz Lindenmaier" > > ?: "hotspot-runtime-dev" , > "core-libs-dev" > > Envoy?: Mardi 17 Septembre 2019 16:18:03 > > Objet: RE: RFR (L, final): 8218626: Add detailed message to > NullPointerException describing what is null. > > > @core-libs experts, I would appreciate comments on the changes > > to NullPointerException.java, especially wrt. the Javadoc comment. > > The change there is S. > > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: Lindenmaier, Goetz > >> Sent: Dienstag, 10. September 2019 11:48 > >> To: 'Hotspot dev runtime' ; > Java Core > >> Libs > >> Subject: RFR (L, final): 8218626: Add detailed message to > NullPointerException > >> describing what is null. > >> > >> Hi, > >> > >> > >> > >> this is the implementation of JEP 358: Helpful NullPointerExceptions. > >> > >> > >> > >> The JEP is in status "Candidate". Coleen (many, many thanks!) ran > >> > >> it through the Oracle-internal processes. Now I please need final reviews > >> > >> for this change so that I can propose it to target jdk 14. > >> > >> > >> > >> JEP: https://bugs.openjdk.java.net/browse/JDK-8220715 > >> > >> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8218628 > >> > >> webrev: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg- > NPE/16/ > >> > >> > >> > >> The change ran through a lot of testing, all jtreg and jck tests to name > >> > >> only some. The webrev points to patch > >> > >> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg- > >> NPE/16/enable_NPE_message.patch > >> > >> that enables the change by default, which was useful for testing to > >> > >> assure the code is used in the tests. > >> > >> I just pushed the change to jdk/submit once more. > >> > >> > >> > >> Please review. > >> > >> > >> > >> Thanks! > >> > > > Goetz. From christoph.langer at sap.com Wed Sep 18 10:01:45 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 18 Sep 2019 10:01:45 +0000 Subject: [11u] RFR 8229773: Resolve permissions for code source URLs lazily Message-ID: Hi, please review the backport for JDK-8229773: Resolve permissions for code source URLs lazily to OpenJDK11 updates. Bug: https://bugs.openjdk.java.net/browse/JDK-8229773 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8229773.11u-dev.0/ Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/1b6806340400 The patch did not apply cleanly and I had to resolve src/java.base/share/classes/java/lang/System.java: imports and the hunk about "// ensure the default file system is initialized" src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java: import statements With these modifications, the patch applies and regression testing does not show findings. Thanks Christoph From daniel.fuchs at oracle.com Wed Sep 18 11:27:30 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 18 Sep 2019 12:27:30 +0100 Subject: RFR: 8230648: Replace @exception tag with @throws in java.base In-Reply-To: <27B8D59B-26C9-460F-89C1-33CAA3A0B1E0@oracle.com> References: <358c8542-6fdf-fce4-bd77-0a51f81d9d64@oracle.com> <38ab81e8-2042-2b57-238d-61553e8bdf40@oracle.com> <7ca98a57-d4c5-f841-7c5b-bb24a9e58434@oracle.com> <27B8D59B-26C9-460F-89C1-33CAA3A0B1E0@oracle.com> Message-ID: <7b973bad-6d45-f86d-c223-0703a84d4299@oracle.com> Hi Julia, I will be sponsoring this change, since you got a positive review from both Lance and Pavel I believe we can now push it. Can you prepare a changeset that can be hg-imported, including the copyright year updates that were asked for? I'll try to push it later today - unless there's any further objection. best regards, -- daniel On 06/09/2019 12:33, Pavel Rappo wrote: > If you ran the specdiff and saw nothing, I'm fine with that. Looks good. On 06/09/2019 12:23, Lance Andersen wrote: > Hi Julia, > > It looks fine., thank you for doing this > > > Best > Lance >> On Sep 5, 2019, at 2:28 PM, Julia Boes wrote: >> >> Hi, >> >> Thanks for your comments, Lance and Pavel. >> >> The copyright will be updated before pushing, as Daniel suggested. >> >> To address the tag alignment, I adjusted the replacement from '@exception' -> '@throws' to '@exception' -> 'throws ', where the added whitespace preserves the original alignment. This doesn't improve the alignment (which is not consistent in many places) but at least doesn't make it worse. >> >> Updated webrev: http://cr.openjdk.java.net/~dfuchs/jboes/8230648/webrev.02/ >> >> Regarding Pavel's comment: >> >> 8157682: @inheritDoc doesn't work with @exception >> >> I ran specdiff on the whole JDK and it didn't flag any differences but I'll look into additional comparison options. >> >> Cheers, >> >> 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 Sep 18 13:00:44 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Wed, 18 Sep 2019 09:00:44 -0400 Subject: RFR: JDK-8230654: jpackage package-type dmg on macOS In-Reply-To: <94fa6522-c5ca-c305-b257-71388e97bb13@oracle.com> References: <94fa6522-c5ca-c305-b257-71388e97bb13@oracle.com> Message-ID: Looks good. - Alexey On 9/17/2019 10:42 PM, Alexander Matveev wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > - Added link to "/Application" folder to DMG for drag and drop app to > this folder. > - Added background image with arrow pointing from App icon to > Application folder. > - If adding link and image to DMG fails it will not be considered > critical error. In headless environment it might not work correctly. > - See JBS issue for screenshot on how DMG will looks like with this fix. > > [1] https://bugs.openjdk.java.net/browse/JDK-8230654 > > [2] http://cr.openjdk.java.net/~almatvee/8230654/webrev.01/ > > Thanks, > Alexander From milan.mimica at gmail.com Wed Sep 18 13:25:49 2019 From: milan.mimica at gmail.com (Milan Mimica) Date: Wed, 18 Sep 2019 15:25:49 +0200 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> <87sgpblxns.fsf@oldenburg2.str.redhat.com> <7A46485C-E250-4E57-9FB0-B9D18CA70632@oracle.com> <60FD933F-51A5-4438-83AF-B3427CFDE60D@oracle.com> <8A9E3066-E6F6-4E65-BD02-DF0ACFF02FAD@oracle.com> <633A0CE3-C771-493B-89E3-7FA843C85183@oracle.com> <6b209e36-686f-7852-7fb8-3a0ef0e8423a@oracle.com> <4CAC6E8D-9198-4701-99C0-49901D72A396@oracle.com> <47acbb78-806f-2951-3b22-de6e7965f461@oracle.com> <275EC96C-CC39-41C8-9B9C-B917F25FAB70@oracle.com> <7D4375A7-E2CC-4297-92DF-A13FC9EF07AE@oracle.com> Message-ID: Hi Pavel Sure. Here is the incremental change: http://cr.openjdk.java.net/~mmimica/8228580/webrev.03/ What actually bothers me from the beginning is the truncated response. The TXT attribute, a String, prints "A very popular h", but does not equals("A very popular h"), because of some stray bytes. I guess it's because of how DNS response parsing works. I can imagine how this could cause problems to users. I think, at least, we should have a way to tell the user that the response is truncated, and the payload is partial/invalid. On Tue, 17 Sep 2019 at 15:09, Pavel Rappo wrote: > > Milan, > > While the CSR is being processed, could we maybe think of some additional testing for that change? Otherwise, that test seems kind of anemic. It makes sure that the query doesn't hang, but that's about it. It doesn't check that the timeout is respected. I was wondering if you could propose some way of testing that. > > > On 17 Sep 2019, at 09:55, Pavel Rappo wrote: > > > > I have filed the CSR: > > > > https://bugs.openjdk.java.net/browse/JDK-8230965 > > > >> On 13 Sep 2019, at 11:21, Pavel Rappo wrote: > >> > >> Here's the latest webrev accumulating all the changes we've discussed so far: > >> > >> http://cr.openjdk.java.net/~prappo/8228580/webrev.03/ > >> > >> If people are okay with that I will proceed to creating a CSR. > -- Milan Mimica From andy.herrick at oracle.com Wed Sep 18 13:27:55 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 18 Sep 2019 09:27:55 -0400 Subject: RFR: JDK-8230654: jpackage package-type dmg on macOS In-Reply-To: References: <94fa6522-c5ca-c305-b257-71388e97bb13@oracle.com> Message-ID: <4a8e20c2-2256-dbec-0ce7-8b4b6f8db344@oracle.com> Yes - looks good. /Andy On 9/18/19 9:00 AM, Alexey Semenyuk wrote: > Looks good. > > - Alexey > > On 9/17/2019 10:42 PM, Alexander Matveev wrote: >> Please review the jpackage fix for bug [1] at [2]. >> >> This is a fix for the JDK-8200758-branch branch of the open sandbox >> repository (jpackage). >> >> - Added link to "/Application" folder to DMG for drag and drop app to >> this folder. >> - Added background image with arrow pointing from App icon to >> Application folder. >> - If adding link and image to DMG fails it will not be considered >> critical error. In headless environment it might not work correctly. >> - See JBS issue for screenshot on how DMG will looks like with this fix. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8230654 >> >> [2] http://cr.openjdk.java.net/~almatvee/8230654/webrev.01/ >> >> Thanks, >> Alexander > From Roger.Riggs at oracle.com Wed Sep 18 13:47:47 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 18 Sep 2019 09:47:47 -0400 Subject: RFR of JDK-8134599: Improve the code coverage for ThreadLocal In-Reply-To: <2294a248-1569-1d3a-85b5-76bff05a4274@oracle.com> References: <2294a248-1569-1d3a-85b5-76bff05a4274@oracle.com> Message-ID: <0e654f45-be80-f073-07ce-a5b5c9486eb0@oracle.com> Hi Hamlin, Sorry for the protracted delay. This looks ok. Roger On 9/4/19 3:16 AM, Hamlin Li wrote: > Would you please review the following patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8209824 > > webrev: http://cr.openjdk.java.net/~mli/8209824/webrev.00/ > > > Thank you > > -Hamlin > From julia.boes at oracle.com Wed Sep 18 14:20:20 2019 From: julia.boes at oracle.com (Julia Boes) Date: Wed, 18 Sep 2019 15:20:20 +0100 Subject: RFR: 8230648: Replace @exception tag with @throws in java.base In-Reply-To: <7b973bad-6d45-f86d-c223-0703a84d4299@oracle.com> References: <358c8542-6fdf-fce4-bd77-0a51f81d9d64@oracle.com> <38ab81e8-2042-2b57-238d-61553e8bdf40@oracle.com> <7ca98a57-d4c5-f841-7c5b-bb24a9e58434@oracle.com> <27B8D59B-26C9-460F-89C1-33CAA3A0B1E0@oracle.com> <7b973bad-6d45-f86d-c223-0703a84d4299@oracle.com> Message-ID: <4ca201e6-7f38-2362-f836-9603240b185b@oracle.com> Hi Daniel, That sounds good, thank you. The copyright year update is made. Please note that there are a few cases where the whitespace after the @throws tag is less than three to align it with its neighboring tags, e.g. BufferedOutputStream line 65. Changeset: http://cr.openjdk.java.net/~jboes/webrevs/8230648/webrev.03/ Cheers, Julia On 18/09/2019 12:27, Daniel Fuchs wrote: > Hi Julia, > > I will be sponsoring this change, since you got a positive review > from both Lance and Pavel I believe we can now push it. > > Can you prepare a changeset that can be hg-imported, including > the copyright year updates that were asked for? I'll try to push > it later today - unless there's any further objection. > > best regards, > > -- daniel > > On 06/09/2019 12:33, Pavel Rappo wrote: >> If you ran the specdiff and saw nothing, I'm fine with that. Looks good. > > > On 06/09/2019 12:23, Lance Andersen wrote: >> Hi Julia, >> >> It looks fine., thank you for doing this >> >> >> Best >> Lance >>> On Sep 5, 2019, at 2:28 PM, Julia Boes wrote: >>> >>> Hi, >>> >>> Thanks for your comments, Lance and Pavel. >>> >>> The copyright will be updated before pushing, as Daniel suggested. >>> >>> To address the tag alignment, I adjusted the replacement from >>> '@exception' -> '@throws' to '@exception' -> 'throws ', where the >>> added whitespace preserves the original alignment. This doesn't >>> improve the alignment (which is not consistent in many places) but >>> at least doesn't make it worse. >>> >>> Updated webrev: >>> http://cr.openjdk.java.net/~dfuchs/jboes/8230648/webrev.02/ >>> >>> Regarding Pavel's comment: >>> >>> ??? 8157682: @inheritDoc doesn't work with @exception >>> >>> I ran specdiff on the whole JDK and it didn't flag any differences >>> but I'll look into additional comparison options. >>> >>> Cheers, >>> >>> 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 Sep 18 15:23:15 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Wed, 18 Sep 2019 11:23:15 -0400 Subject: RFR: JDK-8225249: LinuxDebBundler and LinuxRpmBundler should share more In-Reply-To: <583dc9b6-6b2b-a04b-f209-9ce2a851d007@oracle.com> References: <583dc9b6-6b2b-a04b-f209-9ce2a851d007@oracle.com> Message-ID: <5f7e9cc8-9698-f7a5-dc1a-3cb3a2ddf30a@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: - Move common deb and rpm packaging code in the new class (jdk.jpackage.internal.LinuxPackageBundler). - Implement Java runtime packaging on Linux. - Fix of [3], [4] bugs as a side effect of code refactoring. - Add shell scripts to run jpackage jtreg tests. - Add tests for application desktop integration on Linux. - Add uninstall script to clean leftovers after file associations of the app are removed. Uninstalling Linux app with file associations will produce the following console output: --- Running: sudo dpkg -r fileassociationstest (Reading database ... 250166 files and directories currently installed.) Removing fileassociationstest (1.0-1) ... Remove fileassociationstest-FileassociationsTest.desktop default handler for application/x-jpackage-jptest1 mime type from /usr/share/applications/defaults.list file Remove fileassociationstest-FileassociationsTest.desktop default handler for application/x-jpackage-jptest2 mime type from /usr/share/applications/defaults.list file /usr/share/applications/defaults.list file updated --- - Clean some unused code. /Andy [1] https://bugs.openjdk.java.net/browse/JDK-8225249 [2] http://cr.openjdk.java.net/~asemenyuk/8225249/webrev.02/ [3] https://bugs.openjdk.java.net/browse/JDK-8230899 [4] https://bugs.openjdk.java.net/browse/JDK-8230917 From julia.boes at oracle.com Wed Sep 18 15:47:57 2019 From: julia.boes at oracle.com (Julia Boes) Date: Wed, 18 Sep 2019 16:47:57 +0100 Subject: RFR: 8231186: Replace html tag foo with javadoc tag {@code foo} in java.base In-Reply-To: <733ed056-1606-0c75-feaf-cc3066e4f6eb@oracle.com> References: <733ed056-1606-0c75-feaf-cc3066e4f6eb@oracle.com> Message-ID: <297d817e-b0d9-2814-bb1c-80c6f67a7147@oracle.com> Hi, This change replaces the HTML code tag with the equivalent javadoc tag in the java.base module as such: foo becomes {@code foo} Ignored are any code tags that enclose other HTML or javadoc tags or that contain HTML entities, e.g. character codes. Examples (after change): java.base/share/classes/java/nio/charset/spi/CharsetProvider.java 51 * ignored.? The comment character is {@code '#'} ('\u0023'); on java.base/share/classes/java/io/File.java 625 * new File(this.{@link #getCanonicalPath}). I reviewed the change with specdiff and doccheck on the java.base module, neither flagged any differences or errors. I also reviewed the javadoc of some classes manually but did not do an extensive manual review. Bug: https://bugs.openjdk.java.net/browse/JDK-8231186 Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8231186/webrev.02/ The copyright year will be updated before generating the changeset. Regards, Julia From sgehwolf at redhat.com Wed Sep 18 17:02:16 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 18 Sep 2019 19:02:16 +0200 Subject: Dead code in jdk.internal.platform.Metrics? Message-ID: Hi Bob, As you probably know, I'm looking at cgroups v2 support[0] in OpenJDK. When looking at Metrics.java[1] I see that many methods aren't used anywhere. Neither in tests nor in actual code. It looks like as if the interface has been modelled along the lines of the cgroups v1 implementation. These methods are: - public long getCpuUsage(); - public long[] getPerCpuUsage(); - public long getCpuUserUsage(); - public long getCpuSystemUsage(); - public double getCpuSetMemoryPressure(); - public long getMemoryMaxUsage(); - public long getMemoryUsage(); - public long getKernelMemoryFailCount(); - public long getKernelMemoryMaxUsage(); - public long getKernelMemoryUsage(); - public long getTcpMemoryFailCount(); - public long getTcpMemoryMaxUsage(); - public long getTcpMemoryUsage(); - public long getBlkIOServiceCount(); - public long getBlkIOServiced(); They are essentially dead code. Note that not all of them would have an implementation in cgroups v2. With that in mind, does it actually make sense for the Metrics interface to define those? We could keep the implementations for cgroup v1 Metrics, but perhaps remove them from the interface? It seems the current Metrics interface defines too many methods for no good reason. Am I missing something? Thoughts? >From the looks of it it wouldn't even require a CSR as jdk.internal.platform isn't an exported package. Here is an example patch removing them, and jdk docker container tests still pass: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8230305/remove_metrics_interface_methods.patch Thanks, Severin [0] https://bugs.openjdk.java.net/browse/JDK-8230305 [1] http://hg.openjdk.java.net/jdk/jdk/file/377f47ccc20b/src/java.base/share/classes/jdk/internal/platform/Metrics.java From claes.redestad at oracle.com Wed Sep 18 17:16:23 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 18 Sep 2019 19:16:23 +0200 Subject: [11u] RFR 8229773: Resolve permissions for code source URLs lazily In-Reply-To: References: Message-ID: Looks ok to me! /Claes On 2019-09-18 12:01, Langer, Christoph wrote: > Hi, > > please review the backport for JDK-8229773: Resolve permissions for code source URLs lazily to OpenJDK11 updates. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8229773 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8229773.11u-dev.0/ > Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/1b6806340400 > > The patch did not apply cleanly and I had to resolve > src/java.base/share/classes/java/lang/System.java: imports and the hunk about "// ensure the default file system is initialized" > src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java: import statements > > With these modifications, the patch applies and regression testing does not show findings. > > Thanks > Christoph > From bob.vandette at oracle.com Wed Sep 18 17:15:46 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 18 Sep 2019 10:15:46 -0700 Subject: Dead code in jdk.internal.platform.Metrics? In-Reply-To: References: Message-ID: <45722DB2-183A-470B-9A05-FA0B6555E416@oracle.com> These internal methods were implemented in order to expose container metrics to via a public API. I?ve filed JDK-8203359 and JDK-8199944 to add an MBean and JFR events that will expose these values. JDK-8203359: Java Flight Recorder (JFR) improvements for containers JDK-8199944: Add Container MBean to JMX There are container tests that verify many of these methods. Can you give me a list of the metrics that are not available under cgroupv2? Bob. > On Sep 18, 2019, at 10:02 AM, Severin Gehwolf wrote: > > Hi Bob, > > As you probably know, I'm looking at cgroups v2 support[0] in OpenJDK. > When looking at Metrics.java[1] I see that many methods aren't used > anywhere. Neither in tests nor in actual code. It looks like as if the > interface has been modelled along the lines of the cgroups v1 > implementation. These methods are: > > - public long getCpuUsage(); > - public long[] getPerCpuUsage(); > - public long getCpuUserUsage(); > - public long getCpuSystemUsage(); > - public double getCpuSetMemoryPressure(); > - public long getMemoryMaxUsage(); > - public long getMemoryUsage(); > - public long getKernelMemoryFailCount(); > - public long getKernelMemoryMaxUsage(); > - public long getKernelMemoryUsage(); > - public long getTcpMemoryFailCount(); > - public long getTcpMemoryMaxUsage(); > - public long getTcpMemoryUsage(); > - public long getBlkIOServiceCount(); > - public long getBlkIOServiced(); > > They are essentially dead code. Note that not all of them would have an > implementation in cgroups v2. With that in mind, does it actually make > sense for the Metrics interface to define those? We could keep the > implementations for cgroup v1 Metrics, but perhaps remove them from the > interface? It seems the current Metrics interface defines too many > methods for no good reason. Am I missing something? Thoughts? > > From the looks of it it wouldn't even require a CSR as > jdk.internal.platform isn't an exported package. > > Here is an example patch removing them, and jdk docker container tests > still pass: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8230305/remove_metrics_interface_methods.patch > > Thanks, > Severin > > [0] https://bugs.openjdk.java.net/browse/JDK-8230305 > [1] http://hg.openjdk.java.net/jdk/jdk/file/377f47ccc20b/src/java.base/share/classes/jdk/internal/platform/Metrics.java > From ramanand.patil at oracle.com Wed Sep 18 17:44:17 2019 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Wed, 18 Sep 2019 10:44:17 -0700 (PDT) Subject: RFR: 8231098: (tz) Upgrade time-zone data to tzdata2019c In-Reply-To: References: <80fa7966-1731-4941-9343-2ee7428587fd@default> <18276aaf-6a9c-550b-1619-13a9c550fd04@oracle.com> Message-ID: Hi Naoto and Martin, Thank you very much for your reviews. Hi Martin, Naoto is correct, the jdk build will fail for the update releases when using vanguard format, since the fix from JDK-8212970 is not yet backported. Since, jdk14 has this fix, my current patch uses vanguard format tzdata. I am planning to backport JDK-8212970 along with the tzdata2019c integration into the update releases, if there are no major issues. I have already seen the 11u backport request from Christoph for-8212970. Regards, Ramanand. > -----Original Message----- > From: Naoto Sato > Sent: Tuesday, September 17, 2019 11:25 PM > To: Martin Buchholz > Cc: Ramanand Patil ; core-libs-dev dev at openjdk.java.net>; i18n-dev > Subject: Re: RFR: 8231098: (tz) Upgrade time-zone data to > tzdata2019c > > On 9/17/19 10:14 AM, Martin Buchholz wrote: > > > > > > On Tue, Sep 17, 2019 at 9:45 AM > > wrote: > > > > +1 > > > > On 9/17/19 8:29 AM, Martin Buchholz wrote: > > > Looks good to me. > > > At Google we also integrated tzdata2019c, and it was uneventful > > (good!). > > > But we're still using rearguard format. > > > The vanguard/rearguard distinction is a source of errors, so it > > should be > > > made clear what format is being used to import the files. > > > If you have a script to update the jdk sources, perhaps it should be > > > checked in to openjdk? > > > If these files are in vanguard format, is there a trap for those > > of us > > > doing backports to jdks that only support rearguard? > > > > Can't think of any off the top of my head, Martin. The build tool > > > > > > Which build tool??TzdbZoneRulesCompiler? > > Yes. > > > > > internally converts vanguard data into rearguard compatible, by > > adjusting the standard offsets, and build into tzdb.dat (which should > > even be compatible to prior JDK runtimes). > > > > > > So ... a change like this one is created by copying selected vanguard > > format files from the tzdata source distribution into openjdk, and > > then?TzdbZoneRulesCompiler converts to rearguard format internally? > > At Google, we chose to run tzdata's?own?tool to convert to rearguard > > format and then check in those data files into the jdk source tree. > > The tool will not convert the file format to rearguard. Read the vanguard > format file, then converts the data into tzdb.dat that can be recognized by > prior runtimes. > > > > > I worry that when other engineers backport to older releases, if only > > the data files are copied, then conversion to rearguard format will > > not happen,?with bad results. > > If an engineer only backports the vanguard files into older releases (before > the vanguard support), I don't think the JDK build will succeed. > Build will fail on creating tzdb.dat file. > > Naoto From claes.redestad at oracle.com Wed Sep 18 18:05:16 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 18 Sep 2019 20:05:16 +0200 Subject: RFR: 8230768: Arrays of SoftReferences in MethodTypeForm should not be @Stable Message-ID: <41e65e9e-d693-e863-5829-16cc081292a1@oracle.com> Hi, please review this patch to remove @Stable from two arrays in MethodTypeForm. These were marked as @Stable in an earlier incarnation of the code when the contents was not SoftReference, but @Stable does not make sense for SoftReferences and might even be detrimental. I also did some incidental cleanup of the code. Bug: https://bugs.openjdk.java.net/browse/JDK-8230768 Webrev: http://cr.openjdk.java.net/~redestad/8230768/jdk.00/ Thanks! /Claes From sgehwolf at redhat.com Wed Sep 18 18:05:31 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 18 Sep 2019 20:05:31 +0200 Subject: Dead code in jdk.internal.platform.Metrics? In-Reply-To: <45722DB2-183A-470B-9A05-FA0B6555E416@oracle.com> References: <45722DB2-183A-470B-9A05-FA0B6555E416@oracle.com> Message-ID: <950c4bf9467c372d969e3cdfca5964c319cf0381.camel@redhat.com> On Wed, 2019-09-18 at 10:15 -0700, Bob Vandette wrote: > These internal methods were implemented in order to expose container metrics to > via a public API. I?ve filed JDK-8203359 and JDK-8199944 to add an MBean > and JFR events that will expose these values. > > JDK-8203359: Java Flight Recorder (JFR) improvements for containers > JDK-8199944: Add Container MBean to JMX Sure. Has there been any movement on them? > There are container tests that verify many of these methods. Like I said, I've run container tests with the patch below applied and they seem to pass. So IMO they're not covered by tests. Grepping through the code doesn't return anything either. > Can you give me a list of the metrics that are not available under > cgroupv2? Not an exhaustive list, but from a cursory initial assessment: - public long getMemoryMaxUsage(); - public long getKernelMemoryFailCount(); - public long getKernelMemoryMaxUsage(); - public long getKernelMemoryUsage(); - public long getTcpMemoryFailCount(); - public long getTcpMemoryMaxUsage(); - public long getTcpMemoryUsage(); Thanks, Severin > Bob. > > > > On Sep 18, 2019, at 10:02 AM, Severin Gehwolf wrote: > > > > Hi Bob, > > > > As you probably know, I'm looking at cgroups v2 support[0] in OpenJDK. > > When looking at Metrics.java[1] I see that many methods aren't used > > anywhere. Neither in tests nor in actual code. It looks like as if the > > interface has been modelled along the lines of the cgroups v1 > > implementation. These methods are: > > > > - public long getCpuUsage(); > > - public long[] getPerCpuUsage(); > > - public long getCpuUserUsage(); > > - public long getCpuSystemUsage(); > > - public double getCpuSetMemoryPressure(); > > - public long getMemoryMaxUsage(); > > - public long getMemoryUsage(); > > - public long getKernelMemoryFailCount(); > > - public long getKernelMemoryMaxUsage(); > > - public long getKernelMemoryUsage(); > > - public long getTcpMemoryFailCount(); > > - public long getTcpMemoryMaxUsage(); > > - public long getTcpMemoryUsage(); > > - public long getBlkIOServiceCount(); > > - public long getBlkIOServiced(); > > > > They are essentially dead code. Note that not all of them would have an > > implementation in cgroups v2. With that in mind, does it actually make > > sense for the Metrics interface to define those? We could keep the > > implementations for cgroup v1 Metrics, but perhaps remove them from the > > interface? It seems the current Metrics interface defines too many > > methods for no good reason. Am I missing something? Thoughts? > > > > From the looks of it it wouldn't even require a CSR as > > jdk.internal.platform isn't an exported package. > > > > Here is an example patch removing them, and jdk docker container tests > > still pass: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8230305/remove_metrics_interface_methods.patch > > > > Thanks, > > Severin > > > > [0] https://bugs.openjdk.java.net/browse/JDK-8230305 > > [1] http://hg.openjdk.java.net/jdk/jdk/file/377f47ccc20b/src/java.base/share/classes/jdk/internal/platform/Metrics.java > > From bob.vandette at oracle.com Wed Sep 18 18:07:20 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 18 Sep 2019 11:07:20 -0700 Subject: Dead code in jdk.internal.platform.Metrics? In-Reply-To: References: Message-ID: <87806C02-A603-433A-972A-5BDFD140B4CE@oracle.com> It appears that many of the metrics we make available are in cgroupv2 although they are located in different files. The TCP memory allocations many not be split out. In the case of V2 you could just return the not available error return or we could talk about removing this metric. https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html Here are where most of the Metrics tests are implemented: {jdk14}/open/test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java I?m at Code One this week and will take a look at your v2 webrev when I get back to the office. Do you handle the case where there are v1 and v2 subsystems enabled at the same time? Bob. > On Sep 18, 2019, at 10:02 AM, Severin Gehwolf wrote: > > Hi Bob, > > As you probably know, I'm looking at cgroups v2 support[0] in OpenJDK. > When looking at Metrics.java[1] I see that many methods aren't used > anywhere. Neither in tests nor in actual code. It looks like as if the > interface has been modelled along the lines of the cgroups v1 > implementation. These methods are: > > - public long getCpuUsage(); > - public long[] getPerCpuUsage(); > - public long getCpuUserUsage(); > - public long getCpuSystemUsage(); > - public double getCpuSetMemoryPressure(); > - public long getMemoryMaxUsage(); > - public long getMemoryUsage(); > - public long getKernelMemoryFailCount(); > - public long getKernelMemoryMaxUsage(); > - public long getKernelMemoryUsage(); > - public long getTcpMemoryFailCount(); > - public long getTcpMemoryMaxUsage(); > - public long getTcpMemoryUsage(); > - public long getBlkIOServiceCount(); > - public long getBlkIOServiced(); > > They are essentially dead code. Note that not all of them would have an > implementation in cgroups v2. With that in mind, does it actually make > sense for the Metrics interface to define those? We could keep the > implementations for cgroup v1 Metrics, but perhaps remove them from the > interface? It seems the current Metrics interface defines too many > methods for no good reason. Am I missing something? Thoughts? > > From the looks of it it wouldn't even require a CSR as > jdk.internal.platform isn't an exported package. > > Here is an example patch removing them, and jdk docker container tests > still pass: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8230305/remove_metrics_interface_methods.patch > > Thanks, > Severin > > [0] https://bugs.openjdk.java.net/browse/JDK-8230305 > [1] http://hg.openjdk.java.net/jdk/jdk/file/377f47ccc20b/src/java.base/share/classes/jdk/internal/platform/Metrics.java > From mandy.chung at oracle.com Wed Sep 18 18:09:25 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 18 Sep 2019 11:09:25 -0700 Subject: RFR: 8230768: Arrays of SoftReferences in MethodTypeForm should not be @Stable In-Reply-To: <41e65e9e-d693-e863-5829-16cc081292a1@oracle.com> References: <41e65e9e-d693-e863-5829-16cc081292a1@oracle.com> Message-ID: <553968c9-403a-6f29-f7ff-d897470d140e@oracle.com> Looks fine to me. Mandy On 9/18/19 11:05 AM, Claes Redestad wrote: > Hi, > > please review this patch to remove @Stable from two arrays in > MethodTypeForm. These were marked as @Stable in an earlier > incarnation of the code when the contents was not SoftReference, > but @Stable does not make sense for SoftReferences and might even > be detrimental. > > I also did some incidental cleanup of the code. > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8230768 > Webrev: http://cr.openjdk.java.net/~redestad/8230768/jdk.00/ > > Thanks! > > /Claes From bob.vandette at oracle.com Wed Sep 18 18:27:14 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 18 Sep 2019 11:27:14 -0700 Subject: Dead code in jdk.internal.platform.Metrics? In-Reply-To: <950c4bf9467c372d969e3cdfca5964c319cf0381.camel@redhat.com> References: <45722DB2-183A-470B-9A05-FA0B6555E416@oracle.com> <950c4bf9467c372d969e3cdfca5964c319cf0381.camel@redhat.com> Message-ID: <5F1A906F-C290-4640-B6E0-43EBB7583575@oracle.com> > On Sep 18, 2019, at 11:05 AM, Severin Gehwolf wrote: > > On Wed, 2019-09-18 at 10:15 -0700, Bob Vandette wrote: >> These internal methods were implemented in order to expose container metrics to >> via a public API. I?ve filed JDK-8203359 and JDK-8199944 to add an MBean >> and JFR events that will expose these values. >> >> JDK-8203359: Java Flight Recorder (JFR) improvements for containers >> JDK-8199944: Add Container MBean to JMX > > Sure. Has there been any movement on them? I need to have a discussion with the core-libs team when I get back. I may pick up the JMX MBean work. This requires taking a look at other OS?s such as Windows to see what could be provided for that platform. Your cgroupv2 work is coming at a good time. > >> There are container tests that verify many of these methods. > > Like I said, I've run container tests with the patch below applied and > they seem to pass. So IMO they're not covered by tests. Grepping > through the code doesn't return anything either. > >> Can you give me a list of the metrics that are not available under >> cgroupv2? > > Not an exhaustive list, but from a cursory initial assessment: > > - public long getMemoryMaxUsage(); > - public long getKernelMemoryFailCount(); > - public long getKernelMemoryMaxUsage(); > - public long getKernelMemoryUsage(); > - public long getTcpMemoryFailCount(); > - public long getTcpMemoryMaxUsage(); > - public long getTcpMemoryUsage(); The Kernel and Tcp metrics are not that critical but I wish they had MemoryMaxUsage. That?s a useful metric for adjusting container memory limits. Bob. > > Thanks, > Severin > >> Bob. >> >> >>> On Sep 18, 2019, at 10:02 AM, Severin Gehwolf wrote: >>> >>> Hi Bob, >>> >>> As you probably know, I'm looking at cgroups v2 support[0] in OpenJDK. >>> When looking at Metrics.java[1] I see that many methods aren't used >>> anywhere. Neither in tests nor in actual code. It looks like as if the >>> interface has been modelled along the lines of the cgroups v1 >>> implementation. These methods are: >>> >>> - public long getCpuUsage(); >>> - public long[] getPerCpuUsage(); >>> - public long getCpuUserUsage(); >>> - public long getCpuSystemUsage(); >>> - public double getCpuSetMemoryPressure(); >>> - public long getMemoryMaxUsage(); >>> - public long getMemoryUsage(); >>> - public long getKernelMemoryFailCount(); >>> - public long getKernelMemoryMaxUsage(); >>> - public long getKernelMemoryUsage(); >>> - public long getTcpMemoryFailCount(); >>> - public long getTcpMemoryMaxUsage(); >>> - public long getTcpMemoryUsage(); >>> - public long getBlkIOServiceCount(); >>> - public long getBlkIOServiced(); >>> >>> They are essentially dead code. Note that not all of them would have an >>> implementation in cgroups v2. With that in mind, does it actually make >>> sense for the Metrics interface to define those? We could keep the >>> implementations for cgroup v1 Metrics, but perhaps remove them from the >>> interface? It seems the current Metrics interface defines too many >>> methods for no good reason. Am I missing something? Thoughts? >>> >>> From the looks of it it wouldn't even require a CSR as >>> jdk.internal.platform isn't an exported package. >>> >>> Here is an example patch removing them, and jdk docker container tests >>> still pass: >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8230305/remove_metrics_interface_methods.patch >>> >>> Thanks, >>> Severin >>> >>> [0] https://bugs.openjdk.java.net/browse/JDK-8230305 >>> [1] http://hg.openjdk.java.net/jdk/jdk/file/377f47ccc20b/src/java.base/share/classes/jdk/internal/platform/Metrics.java >>> > From naoto.sato at oracle.com Wed Sep 18 18:32:46 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 18 Sep 2019 11:32:46 -0700 Subject: RFR: 8231186: Replace html tag foo with javadoc tag {@code foo} in java.base In-Reply-To: <297d817e-b0d9-2814-bb1c-80c6f67a7147@oracle.com> References: <733ed056-1606-0c75-feaf-cc3066e4f6eb@oracle.com> <297d817e-b0d9-2814-bb1c-80c6f67a7147@oracle.com> Message-ID: <67c75546-1683-9140-89b7-98f189839843@oracle.com> Hi Julia, This is not a comment to changes you've made, but the webrev seems missing some diffs, e.g., http://cr.openjdk.java.net/~jboes/webrevs/8231186/webrev.02/src/java.base/share/classes/java/util/Calendar.java.sdiff.html http://cr.openjdk.java.net/~jboes/webrevs/8231186/webrev.02/src/java.base/share/classes/java/util/ResourceBundle.java.sdiff.html Not checked all, so there may be some other blank diffs. Could be a bug in the tool. Naoto On 9/18/19 8:47 AM, Julia Boes wrote: > Hi, > > This change replaces the HTML code tag with the equivalent javadoc tag > in the java.base module as such: > > foo becomes {@code foo} > > Ignored are any code tags that enclose other HTML or javadoc tags or > that contain HTML entities, e.g. character codes. > > > Examples (after change): > > java.base/share/classes/java/nio/charset/spi/CharsetProvider.java > > 51 * ignored.? The comment character is {@code '#'} > ('\u0023'); on > > java.base/share/classes/java/io/File.java > > 625 * new File(this.{@link #getCanonicalPath}). > > > I reviewed the change with specdiff and doccheck on the java.base > module, neither flagged any differences or errors. I also reviewed the > javadoc of some classes manually but did not do an extensive manual review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231186 > > Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8231186/webrev.02/ > > > The copyright year will be updated before generating the changeset. > > Regards, > > Julia > From claes.redestad at oracle.com Wed Sep 18 18:32:51 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 18 Sep 2019 11:32:51 -0700 Subject: RFR: 8230768: Arrays of SoftReferences in MethodTypeForm should not be @Stable In-Reply-To: <553968c9-403a-6f29-f7ff-d897470d140e@oracle.com> References: <41e65e9e-d693-e863-5829-16cc081292a1@oracle.com> <553968c9-403a-6f29-f7ff-d897470d140e@oracle.com> Message-ID: <1638A8C1-BD97-40FC-A83D-5B5FBC871854@oracle.com> Thanks, Mandy! /Claes Mandy Chung skrev: (18 september 2019 11:09:25 GMT-07:00) >Looks fine to me. > >Mandy > >On 9/18/19 11:05 AM, Claes Redestad wrote: >> Hi, >> >> please review this patch to remove @Stable from two arrays in >> MethodTypeForm. These were marked as @Stable in an earlier >> incarnation of the code when the contents was not SoftReference, >> but @Stable does not make sense for SoftReferences and might even >> be detrimental. >> >> I also did some incidental cleanup of the code. >> >> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8230768 >> Webrev: http://cr.openjdk.java.net/~redestad/8230768/jdk.00/ >> >> Thanks! >> >> /Claes -- Skickat fr?n min Android-enhet med K-9 Mail. Urs?kta min f?ordighet. From brent.christian at oracle.com Wed Sep 18 18:37:39 2019 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 18 Sep 2019 11:37:39 -0700 Subject: RFR: 8231186: Replace html tag foo with javadoc tag {@code foo} in java.base In-Reply-To: <67c75546-1683-9140-89b7-98f189839843@oracle.com> References: <733ed056-1606-0c75-feaf-cc3066e4f6eb@oracle.com> <297d817e-b0d9-2814-bb1c-80c6f67a7147@oracle.com> <67c75546-1683-9140-89b7-98f189839843@oracle.com> Message-ID: <454c636e-2c11-a14d-f33f-9d06f3fdae7b@oracle.com> FWIW, I also noticed this for http://cr.openjdk.java.net/~jboes/webrevs/8231186/webrev.02/src/java.base/share/classes/java/lang/SecurityManager.java.sdiff.html -B On 9/18/19 11:32 AM, naoto.sato at oracle.com wrote: > Hi Julia, > > This is not a comment to changes you've made, but the webrev seems > missing some diffs, e.g., > > http://cr.openjdk.java.net/~jboes/webrevs/8231186/webrev.02/src/java.base/share/classes/java/util/Calendar.java.sdiff.html > > http://cr.openjdk.java.net/~jboes/webrevs/8231186/webrev.02/src/java.base/share/classes/java/util/ResourceBundle.java.sdiff.html > > > Not checked all, so there may be some other blank diffs. Could be a bug > in the tool. > > Naoto > > On 9/18/19 8:47 AM, Julia Boes wrote: >> Hi, >> >> This change replaces the HTML code tag with the equivalent javadoc tag >> in the java.base module as such: >> >> foo becomes {@code foo} >> >> Ignored are any code tags that enclose other HTML or javadoc tags or >> that contain HTML entities, e.g. character codes. >> >> >> Examples (after change): >> >> java.base/share/classes/java/nio/charset/spi/CharsetProvider.java >> >> 51 * ignored.? The comment character is {@code '#'} >> ('\u0023'); on >> >> java.base/share/classes/java/io/File.java >> >> 625 * new File(this.{@link #getCanonicalPath}). >> >> >> I reviewed the change with specdiff and doccheck on the java.base >> module, neither flagged any differences or errors. I also reviewed the >> javadoc of some classes manually but did not do an extensive manual >> review. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8231186 >> >> Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8231186/webrev.02/ >> >> >> The copyright year will be updated before generating the changeset. >> >> Regards, >> >> Julia >> From martinrb at google.com Wed Sep 18 18:45:10 2019 From: martinrb at google.com (Martin Buchholz) Date: Wed, 18 Sep 2019 11:45:10 -0700 Subject: RFR: 8231186: Replace html tag foo with javadoc tag {@code foo} in java.base In-Reply-To: <297d817e-b0d9-2814-bb1c-80c6f67a7147@oracle.com> References: <733ed056-1606-0c75-feaf-cc3066e4f6eb@oracle.com> <297d817e-b0d9-2814-bb1c-80c6f67a7147@oracle.com> Message-ID: Thanks. Years ago I did this same cleanup on a subset of java.base that I maintained. I expected occurrences of '' would need changes as well, but it appears there aren't any in java.base (some previous effort cleaned this up, I guess). I wrote this emacs command to help me: (defun tt-code () (interactive) (query-replace-regexp "<\\(tt\\|code\\)>\\([^<>{}&@]+\\)" "{@code \\2}")) On Wed, Sep 18, 2019 at 8:48 AM Julia Boes wrote: > Hi, > > This change replaces the HTML code tag with the equivalent javadoc tag > in the java.base module as such: > > foo becomes {@code foo} > > Ignored are any code tags that enclose other HTML or javadoc tags or > that contain HTML entities, e.g. character codes. > > > Examples (after change): > > java.base/share/classes/java/nio/charset/spi/CharsetProvider.java > > 51 * ignored. The comment character is {@code '#'} > ('\u0023'); on > > java.base/share/classes/java/io/File.java > > 625 * new File(this.{@link #getCanonicalPath}). > > > I reviewed the change with specdiff and doccheck on the java.base > module, neither flagged any differences or errors. I also reviewed the > javadoc of some classes manually but did not do an extensive manual review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231186 > > Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8231186/webrev.02/ > > > The copyright year will be updated before generating the changeset. > > Regards, > > Julia > > From martinrb at google.com Wed Sep 18 18:54:12 2019 From: martinrb at google.com (Martin Buchholz) Date: Wed, 18 Sep 2019 11:54:12 -0700 Subject: RFR: 8231186: Replace html tag foo with javadoc tag {@code foo} in java.base In-Reply-To: <297d817e-b0d9-2814-bb1c-80c6f67a7147@oracle.com> References: <733ed056-1606-0c75-feaf-cc3066e4f6eb@oracle.com> <297d817e-b0d9-2814-bb1c-80c6f67a7147@oracle.com> Message-ID: I recall thinking that many of the should actually be changed to @link since use of suggested ancient times before @link became available. But "Perfect is the enemy of good". /** - * A BufferedInputStream adds + * A {@code BufferedInputStream} adds * functionality to another input stream-namely, * the ability to buffer the input and to - * support the mark and reset - * methods. When the BufferedInputStream + * support the {@code mark} and {@code reset} + * methods. When the {@code BufferedInputStream} * is created, an internal buffer array is * created. As bytes from the stream are read * or skipped, the internal buffer is refilled * as necessary from the contained input stream, - * many bytes at a time. The mark + * many bytes at a time. The {@code mark} * operation remembers a point in the input - * stream and the reset operation + * stream and the {@code reset} operation From mandrikov at gmail.com Wed Sep 18 19:29:30 2019 From: mandrikov at gmail.com (Evgeny Mandrikov) Date: Wed, 18 Sep 2019 21:29:30 +0200 Subject: [8u] RFR: 8142543: Unformatted code example in API Message-ID: Hello, Please review this 8u backport [1] of JDK-8073347 [2] that resolves JDK-8142543 [3]. With best regards, Evgeny [1] http://cr.openjdk.java.net/~godin/8142543/webrev.00/ [2] https://bugs.openjdk.java.net/browse/JDK-8073347 [3] https://bugs.openjdk.java.net/browse/JDK-8142543 From shade at redhat.com Wed Sep 18 19:37:50 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 18 Sep 2019 21:37:50 +0200 Subject: [8u] RFR: 8142543: Unformatted code example in API In-Reply-To: References: Message-ID: <0a9308d9-7138-b669-84a5-9cdb3604cb26@redhat.com> On 9/18/19 9:29 PM, Evgeny Mandrikov wrote: > Hello, > > Please review this 8u backport [1] of JDK-8073347 [2] that resolves > JDK-8142543 [3]. Wait, that's not how it works, sorry. Please read this: https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix Since you are backporting 8073347, you need to start there. It would be backported by the same bug ID (8073347), not the one you are proposing here (8073347). The patch itself looks okay, but you need to do this per process (see above). Chances are, it would not even need an RFR, on the off-chance it applies cleanly. -- Thanks, -Aleksey From mandrikov at gmail.com Wed Sep 18 20:23:22 2019 From: mandrikov at gmail.com (Evgeny Mandrikov) Date: Wed, 18 Sep 2019 22:23:22 +0200 Subject: [8u] RFR: 8142543: Unformatted code example in API In-Reply-To: <0a9308d9-7138-b669-84a5-9cdb3604cb26@redhat.com> References: <0a9308d9-7138-b669-84a5-9cdb3604cb26@redhat.com> Message-ID: On Wed, Sep 18, 2019 at 9:38 PM Aleksey Shipilev wrote: > On 9/18/19 9:29 PM, Evgeny Mandrikov wrote: > > Hello, > > > > Please review this 8u backport [1] of JDK-8073347 [2] that resolves > > JDK-8142543 [3]. > > Wait, that's not how it works, sorry. Please read this: > https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix > > Since you are backporting 8073347, you need to start there. It would be > backported by the same bug > ID (8073347), not the one you are proposing here (8073347). The patch > itself looks okay, but you > need to do this per process (see above). Chances are, it would not even > need an RFR, on the > off-chance it applies cleanly. > Oups, I discovered first 8142543, then 8073347, then tried to follow same process as used year ago but which was requiring modification of original patch. Now I see the difference. Thank you for the link. So AFAIU from the above wiki page - first 8142543 should be closed as dup of 8073347, then 8073347 should be labeled jdk8u-fix-request with a comment like Fix Request (jdk8u) Patch is trivial (documentation-only). Only slight path modification is required due to repo-consolidation past 8u, after which patch applies cleanly. ? Regards, Evgeny From shade at redhat.com Wed Sep 18 20:32:36 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 18 Sep 2019 22:32:36 +0200 Subject: [8u] RFR: 8142543: Unformatted code example in API In-Reply-To: References: <0a9308d9-7138-b669-84a5-9cdb3604cb26@redhat.com> Message-ID: <1951f80c-6853-2e3b-ce68-6a069c1be3da@redhat.com> On 9/18/19 10:23 PM, Evgeny Mandrikov wrote: > So AFAIU from the above wiki page - first 8142543 should be closed as dup of?8073347, For this case, I would comment in JDK-8142543 that JDK-8073347 fixes the same thing, without closing as dup yet. Then finish the backport, then maybe close as dup. There are weird interactions between "open" and "closed" 8u versioning here... > then 8073347 > should be labeled jdk8u-fix-request with a comment like > > Fix Request (jdk8u) > Patch is trivial (documentation-only). Only slight path modification is required due to > repo-consolidation past 8u, after which patch applies cleanly. Yes. You might also mention it fixes the regression introduced by JDK-8019857. -- Thanks, -Aleksey From sverre.moe at gmail.com Wed Sep 18 21:20:00 2019 From: sverre.moe at gmail.com (Sverre Moe) Date: Wed, 18 Sep 2019 23:20:00 +0200 Subject: Comments on jpackage (JEP 343) In-Reply-To: References: <20190903185855.D9F092BEC49@eggemoggin.niobe.net> <5D804F4A.3010103@oracle.com> <5D8051DF.2070903@oracle.com> Message-ID: It seems many of the RPM Requires comes from me adding the JavaFX jmods to the application image. --add-modules javafx.base javafx.controls javafx.graphics javafx.fxml javafx.media javafx.web javafx.swing Without the JavaFX jmods added to runtime image I get only these Requires. libX11.so.6()(64bit) libXext.so.6()(64bit) libXi.so.6()(64bit) libXrender.so.1()(64bit) libXtst.so.6()(64bit) libasound.so.2()(64bit) libasound.so.2(ALSA_0.9)(64bit) libasound.so.2(ALSA_0.9.0rc4)(64bit) libawt.so()(64bit) libawt_xawt.so()(64bit) libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3)(64bit) libc.so.6(GLIBC_2.3.2)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.4)(64bit) libc.so.6(GLIBC_2.6)(64bit) libc.so.6(GLIBC_2.7)(64bit) libdl.so.2()(64bit) libdl.so.2(GLIBC_2.2.5)(64bit) libfreetype.so()(64bit) libjava.so()(64bit) libjli.so()(64bit) libjvm.so()(64bit) libjvm.so(SUNWprivate_1.1)(64bit) libm.so.6()(64bit) libm.so.6(GLIBC_2.2.5)(64bit) libnet.so()(64bit) libpthread.so.0()(64bit) libpthread.so.0(GLIBC_2.2.5)(64bit) libpthread.so.0(GLIBC_2.3.2)(64bit) libverify.so()(64bit) libz.so.1()(64bit) /Sverre tir. 17. sep. 2019 kl. 10:25 skrev Sverre Moe : > I have built many times with the new jpackage, but actually just now tried > to install the package built by it. > > The new jpackage adds a lot of Requires to the built RPM package. We had > the same problem with the old javapackager. Its default RPM spec file had a > lot of Requires that made it difficult for us to install our package on > different Linux distributions. We circumvented this by packaging the > application image with the Gradle ospackage plugin for RPM and DEB packages. > > Only the last one of these requires is actually in our RPM spec file > provided with --resource-dir. > > I cannot even install the package on the system I built it, because it > cannot find libavcodec-ffmpeg.so.56 > For OpenSUSE Leap 15.1, my Linux distribution there is no package that > provides the libavcodec-ffmpeg. > > Are all these Requires actually necessary for running a JavaFX application > on Linux? > As mentioned we had packaged our JavaFX 8 application with Gradle > ospackage plugin without all these Requires, and it has worked fine on RPM > Linux distributions. > > ld-linux-x86-64.so.2()(64bit) > ld-linux-x86-64.so.2(GLIBC_2.3)(64bit) > libGL.so.1()(64bit) > libX11.so.6()(64bit) > libXext.so.6()(64bit) > libXi.so.6()(64bit) > libXrender.so.1()(64bit) > libXtst.so.6()(64bit) > libasound.so.2()(64bit) > libasound.so.2(ALSA_0.9)(64bit) > libasound.so.2(ALSA_0.9.0rc4)(64bit) > libavcodec-ffmpeg.so.56()(64bit) > libavcodec-ffmpeg.so.56(LIBAVCODEC_FFMPEG_56)(64bit) > libavcodec.so.54()(64bit) > libavcodec.so.54(LIBAVCODEC_54)(64bit) > libavcodec.so.56()(64bit) > libavcodec.so.56(LIBAVCODEC_56)(64bit) > libavcodec.so.57()(64bit) > libavcodec.so.57(LIBAVCODEC_57)(64bit) > libavformat-ffmpeg.so.56()(64bit) > libavformat-ffmpeg.so.56(LIBAVFORMAT_FFMPEG_56)(64bit) > libavformat.so.54()(64bit) > libavformat.so.54(LIBAVFORMAT_54)(64bit) > libavformat.so.56()(64bit) > libavformat.so.56(LIBAVFORMAT_56)(64bit) > libavformat.so.57()(64bit) > libavformat.so.57(LIBAVFORMAT_57)(64bit) > libawt.so()(64bit) > libawt_xawt.so()(64bit) > libc.so.6()(64bit) > libc.so.6(GLIBC_2.11)(64bit) > libc.so.6(GLIBC_2.14)(64bit) > libc.so.6(GLIBC_2.15)(64bit) > libc.so.6(GLIBC_2.17)(64bit) > libc.so.6(GLIBC_2.2.5)(64bit) > libc.so.6(GLIBC_2.3)(64bit) > libc.so.6(GLIBC_2.3.2)(64bit) > libc.so.6(GLIBC_2.3.4)(64bit) > libc.so.6(GLIBC_2.4)(64bit) > libc.so.6(GLIBC_2.6)(64bit) > libc.so.6(GLIBC_2.7)(64bit) > libcairo.so.2()(64bit) > libdl.so.2()(64bit) > libdl.so.2(GLIBC_2.2.5)(64bit) > libfreetype.so()(64bit) > libfreetype.so.6()(64bit) > libgdk-3.so.0()(64bit) > libgdk-x11-2.0.so.0()(64bit) > libgdk_pixbuf-2.0.so.0()(64bit) > libgio-2.0.so.0()(64bit) > libglib-2.0.so.0()(64bit) > libgmodule-2.0.so.0()(64bit) > libgobject-2.0.so.0()(64bit) > libgstreamer-lite.so()(64bit) > libgthread-2.0.so.0()(64bit) > libgtk-3.so.0()(64bit) > libgtk-x11-2.0.so.0()(64bit) > libjava.so()(64bit) > libjli.so()(64bit) > libjvm.so()(64bit) > libjvm.so(SUNWprivate_1.1)(64bit) > libm.so.6()(64bit) > libm.so.6(GLIBC_2.15)(64bit) > libm.so.6(GLIBC_2.2.5)(64bit) > libnet.so()(64bit) > libpango-1.0.so.0()(64bit) > libpangoft2-1.0.so.0()(64bit) > libpthread.so.0()(64bit) > libpthread.so.0(GLIBC_2.2.5)(64bit) > libpthread.so.0(GLIBC_2.3.2)(64bit) > librt.so.1()(64bit) > librt.so.1(GLIBC_2.2.5)(64bit) > libverify.so()(64bit) > libz.so.1()(64bit) > rpmlib(CompressedFileNames) <= 3.0.4-1 > rpmlib(FileDigests) <= 4.6.0-1 > rpmlib(PayloadFilesHavePrefix) <= 4.0-1 > rpmlib(PayloadIsXz) <= 5.2-1 > rtld(GNU_HASH) > xdg-utils > From sverre.moe at gmail.com Wed Sep 18 21:30:29 2019 From: sverre.moe at gmail.com (Sverre Moe) Date: Wed, 18 Sep 2019 23:30:29 +0200 Subject: Comments on jpackage (JEP 343) In-Reply-To: References: <20190903185855.D9F092BEC49@eggemoggin.niobe.net> <5D804F4A.3010103@oracle.com> <5D8051DF.2070903@oracle.com> Message-ID: Where does the Requires for libavcodec-ffmpeg and libavcodec.so come from? Is it javafx-media which requires these. The first one of these two requires I cannot find an RPM package for on www.rpmfind.net. Actually we are not using the javafx-media in our application. I could remove that jmods, but would be interesting to see what would happen without this require while running an media JavaFX application. /Sverre ons. 18. sep. 2019 kl. 23:20 skrev Sverre Moe : > It seems many of the RPM Requires comes from me adding the JavaFX jmods to > the application image. > --add-modules javafx.base javafx.controls javafx.graphics javafx.fxml > javafx.media javafx.web javafx.swing > > Without the JavaFX jmods added to runtime image I get only these Requires. > > libX11.so.6()(64bit) > libXext.so.6()(64bit) > libXi.so.6()(64bit) > libXrender.so.1()(64bit) > libXtst.so.6()(64bit) > libasound.so.2()(64bit) > libasound.so.2(ALSA_0.9)(64bit) > libasound.so.2(ALSA_0.9.0rc4)(64bit) > libawt.so()(64bit) > libawt_xawt.so()(64bit) > libc.so.6()(64bit) > libc.so.6(GLIBC_2.2.5)(64bit) > libc.so.6(GLIBC_2.3)(64bit) > libc.so.6(GLIBC_2.3.2)(64bit) > libc.so.6(GLIBC_2.3.4)(64bit) > libc.so.6(GLIBC_2.4)(64bit) > libc.so.6(GLIBC_2.6)(64bit) > libc.so.6(GLIBC_2.7)(64bit) > libdl.so.2()(64bit) > libdl.so.2(GLIBC_2.2.5)(64bit) > libfreetype.so()(64bit) > libjava.so()(64bit) > libjli.so()(64bit) > libjvm.so()(64bit) > libjvm.so(SUNWprivate_1.1)(64bit) > libm.so.6()(64bit) > libm.so.6(GLIBC_2.2.5)(64bit) > libnet.so()(64bit) > libpthread.so.0()(64bit) > libpthread.so.0(GLIBC_2.2.5)(64bit) > libpthread.so.0(GLIBC_2.3.2)(64bit) > libverify.so()(64bit) > libz.so.1()(64bit) > > > /Sverre > > > tir. 17. sep. 2019 kl. 10:25 skrev Sverre Moe : > >> I have built many times with the new jpackage, but actually just now >> tried to install the package built by it. >> >> The new jpackage adds a lot of Requires to the built RPM package. We had >> the same problem with the old javapackager. Its default RPM spec file had a >> lot of Requires that made it difficult for us to install our package on >> different Linux distributions. We circumvented this by packaging the >> application image with the Gradle ospackage plugin for RPM and DEB packages. >> >> Only the last one of these requires is actually in our RPM spec file >> provided with --resource-dir. >> >> I cannot even install the package on the system I built it, because it >> cannot find libavcodec-ffmpeg.so.56 >> For OpenSUSE Leap 15.1, my Linux distribution there is no package that >> provides the libavcodec-ffmpeg. >> >> Are all these Requires actually necessary for running a JavaFX >> application on Linux? >> As mentioned we had packaged our JavaFX 8 application with Gradle >> ospackage plugin without all these Requires, and it has worked fine on RPM >> Linux distributions. >> >> ld-linux-x86-64.so.2()(64bit) >> ld-linux-x86-64.so.2(GLIBC_2.3)(64bit) >> libGL.so.1()(64bit) >> libX11.so.6()(64bit) >> libXext.so.6()(64bit) >> libXi.so.6()(64bit) >> libXrender.so.1()(64bit) >> libXtst.so.6()(64bit) >> libasound.so.2()(64bit) >> libasound.so.2(ALSA_0.9)(64bit) >> libasound.so.2(ALSA_0.9.0rc4)(64bit) >> libavcodec-ffmpeg.so.56()(64bit) >> libavcodec-ffmpeg.so.56(LIBAVCODEC_FFMPEG_56)(64bit) >> libavcodec.so.54()(64bit) >> libavcodec.so.54(LIBAVCODEC_54)(64bit) >> libavcodec.so.56()(64bit) >> libavcodec.so.56(LIBAVCODEC_56)(64bit) >> libavcodec.so.57()(64bit) >> libavcodec.so.57(LIBAVCODEC_57)(64bit) >> libavformat-ffmpeg.so.56()(64bit) >> libavformat-ffmpeg.so.56(LIBAVFORMAT_FFMPEG_56)(64bit) >> libavformat.so.54()(64bit) >> libavformat.so.54(LIBAVFORMAT_54)(64bit) >> libavformat.so.56()(64bit) >> libavformat.so.56(LIBAVFORMAT_56)(64bit) >> libavformat.so.57()(64bit) >> libavformat.so.57(LIBAVFORMAT_57)(64bit) >> libawt.so()(64bit) >> libawt_xawt.so()(64bit) >> libc.so.6()(64bit) >> libc.so.6(GLIBC_2.11)(64bit) >> libc.so.6(GLIBC_2.14)(64bit) >> libc.so.6(GLIBC_2.15)(64bit) >> libc.so.6(GLIBC_2.17)(64bit) >> libc.so.6(GLIBC_2.2.5)(64bit) >> libc.so.6(GLIBC_2.3)(64bit) >> libc.so.6(GLIBC_2.3.2)(64bit) >> libc.so.6(GLIBC_2.3.4)(64bit) >> libc.so.6(GLIBC_2.4)(64bit) >> libc.so.6(GLIBC_2.6)(64bit) >> libc.so.6(GLIBC_2.7)(64bit) >> libcairo.so.2()(64bit) >> libdl.so.2()(64bit) >> libdl.so.2(GLIBC_2.2.5)(64bit) >> libfreetype.so()(64bit) >> libfreetype.so.6()(64bit) >> libgdk-3.so.0()(64bit) >> libgdk-x11-2.0.so.0()(64bit) >> libgdk_pixbuf-2.0.so.0()(64bit) >> libgio-2.0.so.0()(64bit) >> libglib-2.0.so.0()(64bit) >> libgmodule-2.0.so.0()(64bit) >> libgobject-2.0.so.0()(64bit) >> libgstreamer-lite.so()(64bit) >> libgthread-2.0.so.0()(64bit) >> libgtk-3.so.0()(64bit) >> libgtk-x11-2.0.so.0()(64bit) >> libjava.so()(64bit) >> libjli.so()(64bit) >> libjvm.so()(64bit) >> libjvm.so(SUNWprivate_1.1)(64bit) >> libm.so.6()(64bit) >> libm.so.6(GLIBC_2.15)(64bit) >> libm.so.6(GLIBC_2.2.5)(64bit) >> libnet.so()(64bit) >> libpango-1.0.so.0()(64bit) >> libpangoft2-1.0.so.0()(64bit) >> libpthread.so.0()(64bit) >> libpthread.so.0(GLIBC_2.2.5)(64bit) >> libpthread.so.0(GLIBC_2.3.2)(64bit) >> librt.so.1()(64bit) >> librt.so.1(GLIBC_2.2.5)(64bit) >> libverify.so()(64bit) >> libz.so.1()(64bit) >> rpmlib(CompressedFileNames) <= 3.0.4-1 >> rpmlib(FileDigests) <= 4.6.0-1 >> rpmlib(PayloadFilesHavePrefix) <= 4.0-1 >> rpmlib(PayloadIsXz) <= 5.2-1 >> rtld(GNU_HASH) >> xdg-utils >> > From joe.darcy at oracle.com Wed Sep 18 21:38:59 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 18 Sep 2019 14:38:59 -0700 Subject: JDK 14 RFR of JDK-8231202: Suppress warnings on non-serializable non-transient instance fields in serializable classes Message-ID: Hello, As background, I'm working on a number of serialization-related compile-time checks with the goal of enabling stricter javac lint checking in the JDK build (and elsewhere). One check is tracked by ??? JDK-8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type As summarized in the bug description, it may be concerning if a serializable class has non-transient instance fields whose types are not Serializable. This can cause a serialization failure at runtime. (Classes using the serialPersistentFields mechanism are excluded from this check.) A common example is an exception type -- all Throwable's are Serializable -- which has a non-serializable field. If the fields cannot be marked as transient, one approach to handle this robustly is to have a writeObject method which null outs the field in question when serializing and make the other methods in the exception null-tolerant. In other cases, the object pointed to by the non-serializable field are conditionally serializable at runtime. This is the case for many collection types. For example, a class may have a field of type List with the field set to an ArrayList at runtime. While the List interface does not extent Serializable, the ArrayList class does implement Serializable and the class would serialize fine in practice, assuming the Foo's were serialazable. As a precursor to the adding a compile-time check to the build, please review adding @SuppressWarnings("serial") to document the non-serializable fields in the core libraries: ??? JDK-8231202: Suppress warnings on non-serializable non-transient instance fields in serializable classes ??? http://cr.openjdk.java.net/~darcy/8231202.0/ Bugs for similar changes to client libs and security libs will be filed and reviewed separately. A more complete fix would add readObject/writeObject null handling to AnnotationTypeMismatchExceptionProxy, but since this hasn't seemed to be an issue since the type was introduced back in JDK 5.0, I just added the annotation, as done elsewhere. Thanks, -Joe From sverre.moe at gmail.com Wed Sep 18 21:44:19 2019 From: sverre.moe at gmail.com (Sverre Moe) Date: Wed, 18 Sep 2019 23:44:19 +0200 Subject: Comments on jpackage (JEP 343) In-Reply-To: References: <20190903185855.D9F092BEC49@eggemoggin.niobe.net> <5D804F4A.3010103@oracle.com> <5D8051DF.2070903@oracle.com> Message-ID: It is actually the javafx-web module that requires these. Anyone know what part of the Web module that needs the libavcodec and libavcoded-ffmpeg? We are using a small part of the web module, just WebView for Tooltip with HTML. No Video or Audio. /Sverre ons. 18. sep. 2019 kl. 23:30 skrev Sverre Moe : > Where does the Requires for libavcodec-ffmpeg and libavcodec.so come from? > Is it javafx-media which requires these. > > The first one of these two requires I cannot find an RPM package for on > www.rpmfind.net. > > Actually we are not using the javafx-media in our application. I could > remove that jmods, but would be interesting to see what would happen > without this require while running an media JavaFX application. > > /Sverre > > > ons. 18. sep. 2019 kl. 23:20 skrev Sverre Moe : > >> It seems many of the RPM Requires comes from me adding the JavaFX jmods >> to the application image. >> --add-modules javafx.base javafx.controls javafx.graphics javafx.fxml >> javafx.media javafx.web javafx.swing >> >> Without the JavaFX jmods added to runtime image I get only these Requires. >> >> libX11.so.6()(64bit) >> libXext.so.6()(64bit) >> libXi.so.6()(64bit) >> libXrender.so.1()(64bit) >> libXtst.so.6()(64bit) >> libasound.so.2()(64bit) >> libasound.so.2(ALSA_0.9)(64bit) >> libasound.so.2(ALSA_0.9.0rc4)(64bit) >> libawt.so()(64bit) >> libawt_xawt.so()(64bit) >> libc.so.6()(64bit) >> libc.so.6(GLIBC_2.2.5)(64bit) >> libc.so.6(GLIBC_2.3)(64bit) >> libc.so.6(GLIBC_2.3.2)(64bit) >> libc.so.6(GLIBC_2.3.4)(64bit) >> libc.so.6(GLIBC_2.4)(64bit) >> libc.so.6(GLIBC_2.6)(64bit) >> libc.so.6(GLIBC_2.7)(64bit) >> libdl.so.2()(64bit) >> libdl.so.2(GLIBC_2.2.5)(64bit) >> libfreetype.so()(64bit) >> libjava.so()(64bit) >> libjli.so()(64bit) >> libjvm.so()(64bit) >> libjvm.so(SUNWprivate_1.1)(64bit) >> libm.so.6()(64bit) >> libm.so.6(GLIBC_2.2.5)(64bit) >> libnet.so()(64bit) >> libpthread.so.0()(64bit) >> libpthread.so.0(GLIBC_2.2.5)(64bit) >> libpthread.so.0(GLIBC_2.3.2)(64bit) >> libverify.so()(64bit) >> libz.so.1()(64bit) >> >> >> /Sverre >> >> >> tir. 17. sep. 2019 kl. 10:25 skrev Sverre Moe : >> >>> I have built many times with the new jpackage, but actually just now >>> tried to install the package built by it. >>> >>> The new jpackage adds a lot of Requires to the built RPM package. We had >>> the same problem with the old javapackager. Its default RPM spec file had a >>> lot of Requires that made it difficult for us to install our package on >>> different Linux distributions. We circumvented this by packaging the >>> application image with the Gradle ospackage plugin for RPM and DEB packages. >>> >>> Only the last one of these requires is actually in our RPM spec file >>> provided with --resource-dir. >>> >>> I cannot even install the package on the system I built it, because it >>> cannot find libavcodec-ffmpeg.so.56 >>> For OpenSUSE Leap 15.1, my Linux distribution there is no package that >>> provides the libavcodec-ffmpeg. >>> >>> Are all these Requires actually necessary for running a JavaFX >>> application on Linux? >>> As mentioned we had packaged our JavaFX 8 application with Gradle >>> ospackage plugin without all these Requires, and it has worked fine on RPM >>> Linux distributions. >>> >>> ld-linux-x86-64.so.2()(64bit) >>> ld-linux-x86-64.so.2(GLIBC_2.3)(64bit) >>> libGL.so.1()(64bit) >>> libX11.so.6()(64bit) >>> libXext.so.6()(64bit) >>> libXi.so.6()(64bit) >>> libXrender.so.1()(64bit) >>> libXtst.so.6()(64bit) >>> libasound.so.2()(64bit) >>> libasound.so.2(ALSA_0.9)(64bit) >>> libasound.so.2(ALSA_0.9.0rc4)(64bit) >>> libavcodec-ffmpeg.so.56()(64bit) >>> libavcodec-ffmpeg.so.56(LIBAVCODEC_FFMPEG_56)(64bit) >>> libavcodec.so.54()(64bit) >>> libavcodec.so.54(LIBAVCODEC_54)(64bit) >>> libavcodec.so.56()(64bit) >>> libavcodec.so.56(LIBAVCODEC_56)(64bit) >>> libavcodec.so.57()(64bit) >>> libavcodec.so.57(LIBAVCODEC_57)(64bit) >>> libavformat-ffmpeg.so.56()(64bit) >>> libavformat-ffmpeg.so.56(LIBAVFORMAT_FFMPEG_56)(64bit) >>> libavformat.so.54()(64bit) >>> libavformat.so.54(LIBAVFORMAT_54)(64bit) >>> libavformat.so.56()(64bit) >>> libavformat.so.56(LIBAVFORMAT_56)(64bit) >>> libavformat.so.57()(64bit) >>> libavformat.so.57(LIBAVFORMAT_57)(64bit) >>> libawt.so()(64bit) >>> libawt_xawt.so()(64bit) >>> libc.so.6()(64bit) >>> libc.so.6(GLIBC_2.11)(64bit) >>> libc.so.6(GLIBC_2.14)(64bit) >>> libc.so.6(GLIBC_2.15)(64bit) >>> libc.so.6(GLIBC_2.17)(64bit) >>> libc.so.6(GLIBC_2.2.5)(64bit) >>> libc.so.6(GLIBC_2.3)(64bit) >>> libc.so.6(GLIBC_2.3.2)(64bit) >>> libc.so.6(GLIBC_2.3.4)(64bit) >>> libc.so.6(GLIBC_2.4)(64bit) >>> libc.so.6(GLIBC_2.6)(64bit) >>> libc.so.6(GLIBC_2.7)(64bit) >>> libcairo.so.2()(64bit) >>> libdl.so.2()(64bit) >>> libdl.so.2(GLIBC_2.2.5)(64bit) >>> libfreetype.so()(64bit) >>> libfreetype.so.6()(64bit) >>> libgdk-3.so.0()(64bit) >>> libgdk-x11-2.0.so.0()(64bit) >>> libgdk_pixbuf-2.0.so.0()(64bit) >>> libgio-2.0.so.0()(64bit) >>> libglib-2.0.so.0()(64bit) >>> libgmodule-2.0.so.0()(64bit) >>> libgobject-2.0.so.0()(64bit) >>> libgstreamer-lite.so()(64bit) >>> libgthread-2.0.so.0()(64bit) >>> libgtk-3.so.0()(64bit) >>> libgtk-x11-2.0.so.0()(64bit) >>> libjava.so()(64bit) >>> libjli.so()(64bit) >>> libjvm.so()(64bit) >>> libjvm.so(SUNWprivate_1.1)(64bit) >>> libm.so.6()(64bit) >>> libm.so.6(GLIBC_2.15)(64bit) >>> libm.so.6(GLIBC_2.2.5)(64bit) >>> libnet.so()(64bit) >>> libpango-1.0.so.0()(64bit) >>> libpangoft2-1.0.so.0()(64bit) >>> libpthread.so.0()(64bit) >>> libpthread.so.0(GLIBC_2.2.5)(64bit) >>> libpthread.so.0(GLIBC_2.3.2)(64bit) >>> librt.so.1()(64bit) >>> librt.so.1(GLIBC_2.2.5)(64bit) >>> libverify.so()(64bit) >>> libz.so.1()(64bit) >>> rpmlib(CompressedFileNames) <= 3.0.4-1 >>> rpmlib(FileDigests) <= 4.6.0-1 >>> rpmlib(PayloadFilesHavePrefix) <= 4.0-1 >>> rpmlib(PayloadIsXz) <= 5.2-1 >>> rtld(GNU_HASH) >>> xdg-utils >>> >> From alexander.matveev at oracle.com Wed Sep 18 21:14:12 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Wed, 18 Sep 2019 14:14:12 -0700 Subject: RFR: JDK-8230654: jpackage package-type dmg on macOS In-Reply-To: <3ae6caf7-6161-687b-3a60-aa54f9f52fb7@jugs.org> References: <3ae6caf7-6161-687b-3a60-aa54f9f52fb7@jugs.org> Message-ID: Hi Michael, I did screenshot with show hidden files enabled in Finder (Shift + Command + .). We have hidden files with background image, icon in DMG moved away, so if show hidden files enabled you will see scrollbars and can scroll to hidden files, if it is disabled then no scrollbars are shown. Thanks, Alexander On 9/17/2019 11:52 PM, Michael Paus wrote: > Hi, > > why are there scrollbars in the image on JBS? When you normally > > open a DMG you do not get scrollbars. > > Michael > > >> Message: 6 >> Date: Tue, 17 Sep 2019 19:42:01 -0700 >> From: Alexander Matveev >> To: core-libs-dev >> Subject: RFR: JDK-8230654: jpackage package-type dmg on macOS >> Message-ID: <94fa6522-c5ca-c305-b257-71388e97bb13 at oracle.com> >> Content-Type: text/plain; charset=utf-8; format=flowed >> >> 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). >> >> - Added link to "/Application" folder to DMG for drag and drop app to >> this folder. >> - Added background image with arrow pointing from App icon to >> Application folder. >> - If adding link and image to DMG fails it will not be considered >> critical error. In headless environment it might not work correctly. >> - See JBS issue for screenshot on how DMG will looks like with this fix. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8230654 >> >> [2] http://cr.openjdk.java.net/~almatvee/8230654/webrev.01/ >> >> Thanks, >> Alexander > From mp at jugs.org Wed Sep 18 22:02:42 2019 From: mp at jugs.org (Michael Paus) Date: Thu, 19 Sep 2019 00:02:42 +0200 Subject: RFR: JDK-8230654: jpackage package-type dmg on macOS In-Reply-To: References: <3ae6caf7-6161-687b-3a60-aa54f9f52fb7@jugs.org> Message-ID: Hi, that explains it. I just wanted to make sure that you do not see any scrollbars in the normal case. Will it be possible to provide your own image to be used by the packager? Some people like to do some branding here. Michael Am 18.09.19 um 23:14 schrieb Alexander Matveev: > Hi Michael, > > I did screenshot with show hidden files enabled in Finder (Shift + > Command + .). We have hidden files with background image, icon in DMG > moved away, so if show hidden files enabled you will see scrollbars > and can scroll to hidden files, if it is disabled then no scrollbars > are shown. > > Thanks, > Alexander > > On 9/17/2019 11:52 PM, Michael Paus wrote: >> Hi, >> >> why are there scrollbars in the image on JBS? When you normally >> >> open a DMG you do not get scrollbars. >> >> Michael >> >> >>> Message: 6 >>> Date: Tue, 17 Sep 2019 19:42:01 -0700 >>> From: Alexander Matveev >>> To: core-libs-dev >>> Subject: RFR: JDK-8230654: jpackage package-type dmg on macOS >>> Message-ID: <94fa6522-c5ca-c305-b257-71388e97bb13 at oracle.com> >>> Content-Type: text/plain; charset=utf-8; format=flowed >>> >>> 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). >>> >>> - Added link to "/Application" folder to DMG for drag and drop app to >>> this folder. >>> - Added background image with arrow pointing from App icon to >>> Application folder. >>> - If adding link and image to DMG fails it will not be considered >>> critical error. In headless environment it might not work correctly. >>> - See JBS issue for screenshot on how DMG will looks like with this >>> fix. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8230654 >>> >>> [2] http://cr.openjdk.java.net/~almatvee/8230654/webrev.01/ >>> >>> Thanks, >>> Alexander >> > From mandrikov at gmail.com Wed Sep 18 22:51:37 2019 From: mandrikov at gmail.com (Evgeny Mandrikov) Date: Thu, 19 Sep 2019 00:51:37 +0200 Subject: [8u] RFR: 8142543: Unformatted code example in API In-Reply-To: <1951f80c-6853-2e3b-ce68-6a069c1be3da@redhat.com> References: <0a9308d9-7138-b669-84a5-9cdb3604cb26@redhat.com> <1951f80c-6853-2e3b-ce68-6a069c1be3da@redhat.com> Message-ID: On Wed, Sep 18, 2019 at 10:32 PM Aleksey Shipilev wrote: > On 9/18/19 10:23 PM, Evgeny Mandrikov wrote: > > So AFAIU from the above wiki page - first 8142543 should be closed as > dup of 8073347, > > For this case, I would comment in JDK-8142543 that JDK-8073347 fixes the > same thing, without closing > as dup yet. Then finish the backport, then maybe close as dup. There are > weird interactions between > "open" and "closed" 8u versioning here... > Ok > then 8073347 > > should be labeled jdk8u-fix-request with a comment like > > > > Fix Request (jdk8u) > > Patch is trivial (documentation-only). Only slight path modification is > required due to > > repo-consolidation past 8u, after which patch applies cleanly. > > Yes. You might also mention it fixes the regression introduced by > JDK-8019857. > Done From alexander.matveev at oracle.com Wed Sep 18 22:54:17 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Wed, 18 Sep 2019 15:54:17 -0700 Subject: RFR: JDK-8225249: LinuxDebBundler and LinuxRpmBundler should share more In-Reply-To: <5f7e9cc8-9698-f7a5-dc1a-3cb3a2ddf30a@oracle.com> References: <583dc9b6-6b2b-a04b-f209-9ce2a851d007@oracle.com> <5f7e9cc8-9698-f7a5-dc1a-3cb3a2ddf30a@oracle.com> Message-ID: <0ede4107-2b08-3966-b348-5e2844c1592e@oracle.com> Hi Alexey, Looks good. Thanks, Alexander On 9/18/2019 8:23 AM, 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). > > This fix: > > - Move common deb and rpm packaging code in the new class > (jdk.jpackage.internal.LinuxPackageBundler). > - Implement Java runtime packaging on Linux. > - Fix of [3], [4] bugs as a side effect of code refactoring. > - Add shell scripts to run jpackage jtreg tests. > - Add tests for application desktop integration on Linux. > - Add uninstall script to clean leftovers after file associations of > the app are removed. Uninstalling Linux app with file associations > will produce the following console output: > --- > Running: sudo dpkg -r fileassociationstest > (Reading database ... 250166 files and directories currently installed.) > Removing fileassociationstest (1.0-1) ... > Remove fileassociationstest-FileassociationsTest.desktop default > handler for application/x-jpackage-jptest1 mime type from > /usr/share/applications/defaults.list file > Remove fileassociationstest-FileassociationsTest.desktop default > handler for application/x-jpackage-jptest2 mime type from > /usr/share/applications/defaults.list file > /usr/share/applications/defaults.list file updated > --- > - Clean some unused code. > > /Andy > > > [1] https://bugs.openjdk.java.net/browse/JDK-8225249 > > [2] http://cr.openjdk.java.net/~asemenyuk/8225249/webrev.02/ > > [3] https://bugs.openjdk.java.net/browse/JDK-8230899 > > [4] https://bugs.openjdk.java.net/browse/JDK-8230917 From mp at jugs.org Wed Sep 18 23:09:10 2019 From: mp at jugs.org (Michael Paus) Date: Thu, 19 Sep 2019 01:09:10 +0200 Subject: Comments on jpackage (JEP 343) In-Reply-To: References: Message-ID: <65fd59de-d348-fd29-e3b1-af7a4f229406@jugs.org> If you don't use audio or video, you will probably not need it. Have a look here: https://ffmpeg.org/ > Message: 2 > Date: Wed, 18 Sep 2019 23:44:19 +0200 > From: Sverre Moe > To: Philip Race > Cc: core-libs-dev at openjdk.java.net > Subject: Re: Comments on jpackage (JEP 343) > Message-ID: > > Content-Type: text/plain; charset="UTF-8" > > It is actually the javafx-web module that requires these. > > Anyone know what part of the Web module that needs the libavcodec and > libavcoded-ffmpeg? > > We are using a small part of the web module, just WebView for Tooltip with > HTML. No Video or Audio. > > /Sverre From alexander.matveev at oracle.com Wed Sep 18 23:08:53 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Wed, 18 Sep 2019 16:08:53 -0700 Subject: RFR: JDK-8230654: jpackage package-type dmg on macOS In-Reply-To: References: <3ae6caf7-6161-687b-3a60-aa54f9f52fb7@jugs.org> Message-ID: <2375f3ab-bad0-f2ee-f41e-666e1265fa2c@oracle.com> Hi Michael, If you specified --temp to jpackage it will contain config folder with background image and script we running to arrange icons in DMG, so you can convert created DMG to be writable, re-run script and convert it back to read-only. Currently no plans to add CLI to provide background image for DMG, but it is something we can discuss. We will need offsets for launcher icon and application symbolic link folder to place it correctly on top of background image. Thanks, Alexander On 9/18/2019 3:02 PM, Michael Paus wrote: > Hi, > that explains it. I just wanted to make sure that you do not see any > scrollbars in the normal case. > Will it be possible to provide your own image to be used by the > packager? Some people like > to do some branding here. > Michael > > Am 18.09.19 um 23:14 schrieb Alexander Matveev: >> Hi Michael, >> >> I did screenshot with show hidden files enabled in Finder (Shift + >> Command + .). We have hidden files with background image, icon in DMG >> moved away, so if show hidden files enabled you will see scrollbars >> and can scroll to hidden files, if it is disabled then no scrollbars >> are shown. >> >> Thanks, >> Alexander >> >> On 9/17/2019 11:52 PM, Michael Paus wrote: >>> Hi, >>> >>> why are there scrollbars in the image on JBS? When you normally >>> >>> open a DMG you do not get scrollbars. >>> >>> Michael >>> >>> >>>> Message: 6 >>>> Date: Tue, 17 Sep 2019 19:42:01 -0700 >>>> From: Alexander Matveev >>>> To: core-libs-dev >>>> Subject: RFR: JDK-8230654: jpackage package-type dmg on macOS >>>> Message-ID: <94fa6522-c5ca-c305-b257-71388e97bb13 at oracle.com> >>>> Content-Type: text/plain; charset=utf-8; format=flowed >>>> >>>> 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). >>>> >>>> - Added link to "/Application" folder to DMG for drag and drop app to >>>> this folder. >>>> - Added background image with arrow pointing from App icon to >>>> Application folder. >>>> - If adding link and image to DMG fails it will not be considered >>>> critical error. In headless environment it might not work correctly. >>>> - See JBS issue for screenshot on how DMG will looks like with this >>>> fix. >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8230654 >>>> >>>> [2] http://cr.openjdk.java.net/~almatvee/8230654/webrev.01/ >>>> >>>> Thanks, >>>> Alexander >>> >> > From brent.christian at oracle.com Wed Sep 18 23:13:08 2019 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 18 Sep 2019 16:13:08 -0700 Subject: RFR: 8231186: Replace html tag foo with javadoc tag {@code foo} in java.base In-Reply-To: <454c636e-2c11-a14d-f33f-9d06f3fdae7b@oracle.com> References: <733ed056-1606-0c75-feaf-cc3066e4f6eb@oracle.com> <297d817e-b0d9-2814-bb1c-80c6f67a7147@oracle.com> <67c75546-1683-9140-89b7-98f189839843@oracle.com> <454c636e-2c11-a14d-f33f-9d06f3fdae7b@oracle.com> Message-ID: Hi, Julia I found one more empty .diff: http://cr.openjdk.java.net/~jboes/webrevs/8231186/webrev.02/src/java.base/share/classes/java/util/regex/Matcher.java.sdiff.html In the .patch file, I see that there are changes to: ResourceBundle.java, Calendar.java, and SecurityManager.java so it seems that somehow not all the changes were put into Sdiffs. Strange! -- java/io/InputStream.java: 243 *

The {@code read(b,} {@code off,} {@code len)} method I believe this can be simplified to: {@code read(b, off, len)} -- Here's something I found examples of in several places, for instance in PipedInputStream.java: 195 * @exception IOException If the pipe is {@code broken}, Here we have a link written out in HTML, with {@code} used within the displayed text of the link. This would typically be done instead by using a @link tag, as on the next line: 196 * {@link #connect(java.io.PipedOutputStream) unconnected}, Peeking at the generated HTML, AFAICT the @link tag takes care of generating the styling in the generated HTML. I think it's worth considering converting these 's to @link, either now or as future work. I found the following examples in the webrev: java/io/PipedInputStream.java: 195 * @exception IOException If the pipe is {@code broken}, 300 * {@code broken}, closed, 363 * @exception IOException if the pipe is {@code broken}, 421 * {@code broken}. -- java/io/PipedReader.java: 229 * {@code broken}, 286 * {@code broken}, 334 * {@code broken}, -- java/io/PipedWriter.java: 116 * {@code broken}, 146 * {@code broken}, Looks good otherwise. Thanks, -Brent On 9/18/19 11:37 AM, Brent Christian wrote: > FWIW, I also noticed this for > > http://cr.openjdk.java.net/~jboes/webrevs/8231186/webrev.02/src/java.base/share/classes/java/lang/SecurityManager.java.sdiff.html > > > -B > > On 9/18/19 11:32 AM, naoto.sato at oracle.com wrote: >> Hi Julia, >> >> This is not a comment to changes you've made, but the webrev seems >> missing some diffs, e.g., >> >> http://cr.openjdk.java.net/~jboes/webrevs/8231186/webrev.02/src/java.base/share/classes/java/util/Calendar.java.sdiff.html >> >> http://cr.openjdk.java.net/~jboes/webrevs/8231186/webrev.02/src/java.base/share/classes/java/util/ResourceBundle.java.sdiff.html >> >> >> Not checked all, so there may be some other blank diffs. Could be a >> bug in the tool. >> >> Naoto >> >> On 9/18/19 8:47 AM, Julia Boes wrote: >>> Hi, >>> >>> This change replaces the HTML code tag with the equivalent javadoc >>> tag in the java.base module as such: >>> >>> foo becomes {@code foo} >>> >>> Ignored are any code tags that enclose other HTML or javadoc tags or >>> that contain HTML entities, e.g. character codes. >>> >>> >>> Examples (after change): >>> >>> java.base/share/classes/java/nio/charset/spi/CharsetProvider.java >>> >>> 51 * ignored.? The comment character is {@code '#'} >>> ('\u0023'); on >>> >>> java.base/share/classes/java/io/File.java >>> >>> 625 * new File(this.{@link #getCanonicalPath}). >>> >>> >>> I reviewed the change with specdiff and doccheck on the java.base >>> module, neither flagged any differences or errors. I also reviewed >>> the javadoc of some classes manually but did not do an extensive >>> manual review. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8231186 >>> >>> Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8231186/webrev.02/ >>> >>> >>> The copyright year will be updated before generating the changeset. >>> >>> Regards, >>> >>> Julia >>> From mandy.chung at oracle.com Thu Sep 19 02:33:00 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 18 Sep 2019 19:33:00 -0700 Subject: RFR 8221623 : Add StackWalker micro benchmarks to jdk repo In-Reply-To: References: Message-ID: Hi Brent, $ make test TEST="micro:java.lang.StackWalkBench" It took very long that I killed the job.? Does this happen to you? Mandy On 9/13/19 3:07 PM, Brent Christian wrote: > Hi, > > Please review these StackWalker and Throwable benchmarks for addition > into the JDK microbenchmarks. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8221623 > Webrev: > http://cr.openjdk.java.net/~bchristi/8221623/webrev07/ > > The StackWalker benchmarks use StackWalker's forEach(), walk(), and > Options to measure retrieval of various types of information from the > call stack. > > The Throwable benchmarks do corresponding exercises; there are also a > couple of Logging benchmarks. > > A JMH @Param is used to test a variety of call stack depths. > > > In the future, we might consider a benchmark for > Reflection.getCallerClass().? (It is more involved today to benchmark > that method than at the time these benchmarks were originally written, > so that one's commented out.) See JDK-8230976. > > Thanks, > -Brent > > 1. https://bugs.openjdk.java.net/browse/JDK-8230976 From matthias.baesken at sap.com Thu Sep 19 06:57:37 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 19 Sep 2019 06:57:37 +0000 Subject: [RFR] 8231171: remove remaining sun.java.launcher.pid references - was RE: sun.java.launcher.pid property usage Message-ID: Hello, as discussed below , I want to cleanup some older references to sun.java.launcher.pid. Please review the following change. After removal of some code belonging old LinuxThreads (JDK-8078513) , the sun.java.launcher.pid handling code remained but seems to be obsolete these days . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8231171 http://cr.openjdk.java.net/~mbaesken/webrevs/8231171.0/ Best regards, Matthias > > Hi David, thanks for the additional information . > I opened > > https://bugs.openjdk.java.net/browse/JDK-8231171 > > 8231171: remove reamining sun.java.launcher.pid references > > to do the additional cleanup . > > Best regards, Matthias > > > > -----Original Message----- > > From: David Holmes > > Sent: Mittwoch, 18. September 2019 03:16 > > To: Baesken, Matthias ; 'hotspot- > > dev at openjdk.java.net' > > Subject: Re: sun.java.launcher.pid property usage > > > > Hi Matthias, > > > > On 18/09/2019 12:18 am, Baesken, Matthias wrote: > > > Hello, while looking at some atoi usages in the codebase I started to > > wonder about the "sun.java.launcher.pid" property. > > > Currently in java_md_solinux.c the property is set on Linux only by > default > > (code is guarded #ifdef __linux__ ). > > > Later it is passed to the int variable _sun_java_launcher_pid > > (arguments.cpp) and can be retrieved by sun_java_launcher_pid() . > > > However only in src/hotspot/os/bsd/os_bsd.cpp it is really used. > > > > > > Is the property still supported (one would need to set it from user side on > > the command line on non-Linux because it is not set by default on > > bsd/macOS) ? > > > Can the coding be removed (or should it enabled for BSD/Mac like we do > > on Linux) ? > > > > > > The os_bsd comment mentiones the bug 6351349 : > > > > > > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6351349 > > > JDK-6351349 : On linux with the old thread lib, jps should return the same > > PID as $! > > > > > > but this looks very old. > > > > That was the bug that added this code as it was needed on Linux with > > LinuxThreads. The code was then removed on Linux under > > > > https://bugs.openjdk.java.net/browse/JDK-8078513 > > > > The review thread starts here: > > > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015- > > May/014709.html > > > > I think we were focussed solely on cleaning up the hotspot Linux code > > and didn't really look at the wider implication of the use of > > sun.java.launcher.pid. The code in os_bsd.cpp was simply copied from the > > Linux code without giving it any consideration - as you can tell from > > the comment: > > > > // With BsdThreads the JavaMain thread pid (primordial thread) > > // is different than the pid of the java launcher thread. > > // So, on Bsd, the launcher thread pid is passed to the VM > > // via the sun.java.launcher.pid property. > > > > where you can tell that Linux was simply replaced by Bsd, so we > > reference the non-existent BsdThreads :( > > > > So yes this all seems to be dead code that should be removed - core-libs > > folk will need to be involved of course as they own the launcher. :) It > > looks like SetJavaLauncherPlatformProps() can be removed completely. > > > > Thanks, > > David From Alan.Bateman at oracle.com Thu Sep 19 07:01:50 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 19 Sep 2019 08:01:50 +0100 Subject: [RFR] 8231171: remove remaining sun.java.launcher.pid references - was RE: sun.java.launcher.pid property usage In-Reply-To: References: Message-ID: On 19/09/2019 07:57, Baesken, Matthias wrote: > Hello, as discussed below , I want to cleanup some older references to sun.java.launcher.pid. > Please review the following change. > > After removal of some code belonging old LinuxThreads (JDK-8078513) , the sun.java.launcher.pid handling code remained but > seems to be obsolete these days . > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8231171 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8231171.0/ > The removal from the java launcher looks okay. -Alan. From sverre.moe at gmail.com Thu Sep 19 07:43:51 2019 From: sverre.moe at gmail.com (Sverre Moe) Date: Thu, 19 Sep 2019 09:43:51 +0200 Subject: Comments on jpackage (JEP 343) In-Reply-To: <65fd59de-d348-fd29-e3b1-af7a4f229406@jugs.org> References: <65fd59de-d348-fd29-e3b1-af7a4f229406@jugs.org> Message-ID: Yes it would seem so. I am still perplexed to why it has an RPM Requires libavcodec-ffmpeg.so.56. That one does not exist as far as I can find anywhere. It is not provided with the ffmpeg package. I thought perhaps it was the same library as libavcodec.so.56 only named differently, but considering that also is listed among the Requires it is a distinct package. As to why it has this Requires, perhaps I need to address it at the JavaFX mailinglist. How does jpackage accumulate its RPM Requires list? I thought it had it in a default RPM spec file, but I don't see how that can be, we use our own custom spec file, and jpackage adds many additional Requires not used in our own. Only when javafx-web is within the built runtime image used with jpackage, is these extra Requires used. The RPM spec template file does not have any hard coded Requires, only those from PACKAGE_DEPENDENCIES. I looked around in the source code, and could only see this was set from the command line arguments for dependencies. Does it scan the runtime image to produce its additional Requires list? I have the javafx as dependencies in my project, but those are not "scanned" for linux package dependencies. https://hg.openjdk.java.net/jdk/sandbox/file/bf06a1d3aef6/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/ Trying with the --linux-package-deps none of those dependencies ended up in the built RPM package. Only those from jpackage and those from our custom spec file. /Sverre tor. 19. sep. 2019 kl. 01:09 skrev Michael Paus : > If you don't use audio or video, you will probably not need it. > > Have a look here: https://ffmpeg.org/ > > > Message: 2 > > Date: Wed, 18 Sep 2019 23:44:19 +0200 > > From: Sverre Moe > > To: Philip Race > > Cc: core-libs-dev at openjdk.java.net > > Subject: Re: Comments on jpackage (JEP 343) > > Message-ID: > > qakvDETiRxLFcNY0CVH4pOEzggDw at mail.gmail.com> > > Content-Type: text/plain; charset="UTF-8" > > > > It is actually the javafx-web module that requires these. > > > > Anyone know what part of the Web module that needs the libavcodec and > > libavcoded-ffmpeg? > > > > We are using a small part of the web module, just WebView for Tooltip > with > > HTML. No Video or Audio. > > > > /Sverre > > From david.holmes at oracle.com Thu Sep 19 08:55:47 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 Sep 2019 18:55:47 +1000 Subject: [RFR] 8231171: remove remaining sun.java.launcher.pid references - was RE: sun.java.launcher.pid property usage In-Reply-To: References: Message-ID: <3db7390f-36df-d304-3188-d11e35a673ab@oracle.com> Hi Matthias, Thanks for cleaning this up. On 19/09/2019 4:57 pm, Baesken, Matthias wrote: > Hello, as discussed below , I want to cleanup some older references to sun.java.launcher.pid. > Please review the following change. > > After removal of some code belonging old LinuxThreads (JDK-8078513) , the sun.java.launcher.pid handling code remained but > seems to be obsolete these days . > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8231171 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8231171.0/ src/hotspot/os/bsd/os_bsd.cpp Can you delete the entire comment block here: 1126 // Under the old bsd thread library, bsd gives each thread ... 1140 // OSThread::thread_id() method in osThread_bsd.hpp file as it was simply copied from Linux and is nonsense on BSD. Otherwise that all looks good to me. No need for an updated webrev. Thanks, David ----- > Best regards, Matthias > > >> >> Hi David, thanks for the additional information . >> I opened >> >> https://bugs.openjdk.java.net/browse/JDK-8231171 >> >> 8231171: remove reamining sun.java.launcher.pid references >> >> to do the additional cleanup . >> >> Best regards, Matthias >> >> >>> -----Original Message----- >>> From: David Holmes >>> Sent: Mittwoch, 18. September 2019 03:16 >>> To: Baesken, Matthias ; 'hotspot- >>> dev at openjdk.java.net' >>> Subject: Re: sun.java.launcher.pid property usage >>> >>> Hi Matthias, >>> >>> On 18/09/2019 12:18 am, Baesken, Matthias wrote: >>>> Hello, while looking at some atoi usages in the codebase I started to >>> wonder about the "sun.java.launcher.pid" property. >>>> Currently in java_md_solinux.c the property is set on Linux only by >> default >>> (code is guarded #ifdef __linux__ ). >>>> Later it is passed to the int variable _sun_java_launcher_pid >>> (arguments.cpp) and can be retrieved by sun_java_launcher_pid() . >>>> However only in src/hotspot/os/bsd/os_bsd.cpp it is really used. >>>> >>>> Is the property still supported (one would need to set it from user side on >>> the command line on non-Linux because it is not set by default on >>> bsd/macOS) ? >>>> Can the coding be removed (or should it enabled for BSD/Mac like we do >>> on Linux) ? >>>> >>>> The os_bsd comment mentiones the bug 6351349 : >>>> >>>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6351349 >>>> JDK-6351349 : On linux with the old thread lib, jps should return the same >>> PID as $! >>>> >>>> but this looks very old. >>> >>> That was the bug that added this code as it was needed on Linux with >>> LinuxThreads. The code was then removed on Linux under >>> >>> https://bugs.openjdk.java.net/browse/JDK-8078513 >>> >>> The review thread starts here: >>> >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015- >>> May/014709.html >>> >>> I think we were focussed solely on cleaning up the hotspot Linux code >>> and didn't really look at the wider implication of the use of >>> sun.java.launcher.pid. The code in os_bsd.cpp was simply copied from the >>> Linux code without giving it any consideration - as you can tell from >>> the comment: >>> >>> // With BsdThreads the JavaMain thread pid (primordial thread) >>> // is different than the pid of the java launcher thread. >>> // So, on Bsd, the launcher thread pid is passed to the VM >>> // via the sun.java.launcher.pid property. >>> >>> where you can tell that Linux was simply replaced by Bsd, so we >>> reference the non-existent BsdThreads :( >>> >>> So yes this all seems to be dead code that should be removed - core-libs >>> folk will need to be involved of course as they own the launcher. :) It >>> looks like SetJavaLauncherPlatformProps() can be removed completely. >>> >>> Thanks, >>> David > From sgehwolf at redhat.com Thu Sep 19 10:12:38 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 19 Sep 2019 12:12:38 +0200 Subject: Dead code in jdk.internal.platform.Metrics? In-Reply-To: <87806C02-A603-433A-972A-5BDFD140B4CE@oracle.com> References: <87806C02-A603-433A-972A-5BDFD140B4CE@oracle.com> Message-ID: On Wed, 2019-09-18 at 11:07 -0700, Bob Vandette wrote: > Do you handle the case where there are v1 and v2 subsystems enabled at the same time? Do you mean hybrid hierarchy? I believe so, yes. Right now, if cpu/cpuset/memory/cpuacct controllers are not bound to a cgroupv1 hierarchy - 0 of the hierarchy field in /proc/cgroups (see man 7 cgroups) - cgroupv2 is being assumed. For hybrid hiearchy, which is pretty common with systemd, this would detect to cgroupv1. It's all or nothing for relevant controllers, though. Either all of them are cgroups v1 or all of them are cgroups v2. Examples: hybrid hierarchy (note cgroup2 mounted at /sys/fs/cgroup/unified): ---------------------------------------------------- $ grep cgroup /proc/self/mountinfo 28 21 0:25 / /sys/fs/cgroup ro,nosuid,nodev,noexec shared:4 - tmpfs tmpfs ro,seclabel,mode=755 29 28 0:26 / /sys/fs/cgroup/unified rw,nosuid,nodev,noexec,relatime shared:5 - cgroup2 cgroup2 rw,seclabel,nsdelegate 30 28 0:27 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime shared:6 - cgroup cgroup rw,seclabel,xattr,name=systemd 33 28 0:30 / /sys/fs/cgroup/blkio rw,nosuid,nodev,noexec,relatime shared:7 - cgroup cgroup rw,seclabel,blkio 34 28 0:31 / /sys/fs/cgroup/cpuset rw,nosuid,nodev,noexec,relatime shared:8 - cgroup cgroup rw,seclabel,cpuset 35 28 0:32 / /sys/fs/cgroup/net_cls,net_prio rw,nosuid,nodev,noexec,relatime shared:9 - cgroup cgroup rw,seclabel,net_cls,net_prio 36 28 0:33 / /sys/fs/cgroup/cpu,cpuacct rw,nosuid,nodev,noexec,relatime shared:10 - cgroup cgroup rw,seclabel,cpu,cpuacct 37 28 0:34 / /sys/fs/cgroup/devices rw,nosuid,nodev,noexec,relatime shared:11 - cgroup cgroup rw,seclabel,devices 38 28 0:35 / /sys/fs/cgroup/hugetlb rw,nosuid,nodev,noexec,relatime shared:12 - cgroup cgroup rw,seclabel,hugetlb 39 28 0:36 / /sys/fs/cgroup/pids rw,nosuid,nodev,noexec,relatime shared:13 - cgroup cgroup rw,seclabel,pids 40 28 0:37 / /sys/fs/cgroup/memory rw,nosuid,nodev,noexec,relatime shared:14 - cgroup cgroup rw,seclabel,memory 41 28 0:38 / /sys/fs/cgroup/freezer rw,nosuid,nodev,noexec,relatime shared:15 - cgroup cgroup rw,seclabel,freezer 42 28 0:39 / /sys/fs/cgroup/perf_event rw,nosuid,nodev,noexec,relatime shared:16 - cgroup cgroup rw,seclabel,perf_event $ bin/java -Xlog:os+container=trace -version | grep Detected [0.003s][debug][os,container] Detected cgroups hybrid or legacy hierarchy, using cgroups v1 controllers openjdk version "14-internal" 2020-03-17 OpenJDK Runtime Environment (fastdebug build 14-internal+0-adhoc.sgehwolf.openjdk-head) OpenJDK 64-Bit Server VM (fastdebug build 14-internal+0-adhoc.sgehwolf.openjdk-head, mixed mode, sharing) unified hierarchy: ---------------------------------------------------- $ grep cgroup /proc/self/mountinfo 28 21 0:25 / /sys/fs/cgroup rw,nosuid,nodev,noexec,relatime shared:4 - cgroup2 cgroup2 rw,seclabel $ bin/java -Xlog:os+container=trace -version | grep Detected [0.001s][debug][os,container] Detected cgroups v2 unified hierarchy openjdk version "14-internal" 2020-03-17 OpenJDK Runtime Environment (fastdebug build 14-internal+0-adhoc.sgehwolf.openjdk-head) OpenJDK 64-Bit Server VM (fastdebug build 14-internal+0-adhoc.sgehwolf.openjdk-head, mixed mode, sharing) Thanks, Severin From christoph.langer at sap.com Thu Sep 19 10:37:29 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 19 Sep 2019 10:37:29 +0000 Subject: [11u] RFR 8229773: Resolve permissions for code source URLs lazily In-Reply-To: References: Message-ID: Thanks for the review, Claes. > -----Original Message----- > From: Claes Redestad > Sent: Mittwoch, 18. September 2019 19:16 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net > Cc: core-libs-dev > Subject: Re: [11u] RFR 8229773: Resolve permissions for code source URLs > lazily > > Looks ok to me! > > /Claes > > On 2019-09-18 12:01, Langer, Christoph wrote: > > Hi, > > > > please review the backport for JDK-8229773: Resolve permissions for code > source URLs lazily to OpenJDK11 updates. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8229773 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8229773.11u- > dev.0/ > > Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/1b6806340400 > > > > The patch did not apply cleanly and I had to resolve > > src/java.base/share/classes/java/lang/System.java: imports and the hunk > about "// ensure the default file system is initialized" > > src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java: > import statements > > > > With these modifications, the patch applies and regression testing does not > show findings. > > > > Thanks > > Christoph > > From pavel.rappo at oracle.com Thu Sep 19 11:16:16 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 19 Sep 2019 12:16:16 +0100 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> <87sgpblxns.fsf@oldenburg2.str.redhat.com> <7A46485C-E250-4E57-9FB0-B9D18CA70632@oracle.com> <60FD933F-51A5-4438-83AF-B3427CFDE60D@oracle.com> <8A9E3066-E6F6-4E65-BD02-DF0ACFF02FAD@oracle.com> <633A0CE3-C771-493B-89E3-7FA843C85183@oracle.com> <6b209e36-686f-7852-7fb8-3a0ef0e8423a@oracle.com> <4CAC6E8D-9198-4701-99C0-49901D72A396@oracle.com> <47acbb78-806f-2951-3b22-de6e7965f461@oracle.com> <275EC96C-CC39-41C8-9B9C-B917F25FAB70@oracle.com> <7D4375A7-E2CC-4297-92DF-A13FC9EF07AE@oracle.com> Message-ID: <81087256-819E-49FF-BB94-ADA9530717DD@oracle.com> Milan, This looks like a good start. Please consider 1. Setting TOLERANCE to 5 seconds 2. Getting the second time mark immediately after the query returns (i.e. do not waste your time in DNSTestUtils.debug(attrs)) 3. Making the test parametric instead of hardcoded for the DEFAULT_DNS_CLIENT_TIMEOUT 4. Running the test for at least 2 different values of the timeout, e.g.: * @run main TcpTimeout * @run main TcpTimeout -Dcom.sun.jndi.dns.timeout.initial=5000 As for you question, I'm not sure how we would be able to communicate the fact that the response is truncated to the user. You could try to ask this on the net-dev mailing list. -Pavel > On 18 Sep 2019, at 14:25, Milan Mimica wrote: > > Hi Pavel > > Sure. Here is the incremental change: > http://cr.openjdk.java.net/~mmimica/8228580/webrev.03/ > > What actually bothers me from the beginning is the truncated response. > The TXT attribute, a String, prints "A very popular h", but does not > equals("A very popular h"), because of some stray bytes. I guess it's > because of how DNS response parsing works. I can imagine how this > could cause problems to users. I think, at least, we should have a way > to tell the user that the response is truncated, and the payload is > partial/invalid. > > > On Tue, 17 Sep 2019 at 15:09, Pavel Rappo wrote: >> >> Milan, >> >> While the CSR is being processed, could we maybe think of some additional testing for that change? Otherwise, that test seems kind of anemic. It makes sure that the query doesn't hang, but that's about it. It doesn't check that the timeout is respected. I was wondering if you could propose some way of testing that. >> >>> On 17 Sep 2019, at 09:55, Pavel Rappo wrote: >>> >>> I have filed the CSR: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8230965 >>> >>>> On 13 Sep 2019, at 11:21, Pavel Rappo wrote: >>>> >>>> Here's the latest webrev accumulating all the changes we've discussed so far: >>>> >>>> http://cr.openjdk.java.net/~prappo/8228580/webrev.03/ >>>> >>>> If people are okay with that I will proceed to creating a CSR. >> > > > -- > Milan Mimica From kevin.rushforth at oracle.com Thu Sep 19 13:13:17 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 19 Sep 2019 06:13:17 -0700 Subject: Comments on jpackage (JEP 343) In-Reply-To: References: <65fd59de-d348-fd29-e3b1-af7a4f229406@jugs.org> Message-ID: > As to why it has this Requires, perhaps I need to address it at the JavaFX > mailinglist. Yes, that would be best, as this is no longer related to jpackage. -- Kevin On 9/19/2019 12:43 AM, Sverre Moe wrote: > Yes it would seem so. > > I am still perplexed to why it has an RPM Requires libavcodec-ffmpeg.so.56. > That one does not exist as far as I can find anywhere. It is not provided > with the ffmpeg package. > I thought perhaps it was the same library as libavcodec.so.56 only named > differently, but considering that also is listed among the Requires it is a > distinct package. > As to why it has this Requires, perhaps I need to address it at the JavaFX > mailinglist. > > How does jpackage accumulate its RPM Requires list? I thought it had it in > a default RPM spec file, but I don't see how that can be, we use our own > custom spec file, and jpackage adds many additional Requires not used in > our own. Only when javafx-web is within the built runtime image used with > jpackage, is these extra Requires used. > The RPM spec template file does not have any hard coded Requires, only > those from PACKAGE_DEPENDENCIES. I looked around in the source code, and > could only see this was set from the command line arguments for > dependencies. Does it scan the runtime image to produce its additional > Requires list? I have the javafx as dependencies in my project, but those > are not "scanned" for linux package dependencies. > https://hg.openjdk.java.net/jdk/sandbox/file/bf06a1d3aef6/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/ > > Trying with the --linux-package-deps none of those dependencies ended up in > the built RPM package. Only those from jpackage and those from our custom > spec file. > > /Sverre > > > tor. 19. sep. 2019 kl. 01:09 skrev Michael Paus : > >> If you don't use audio or video, you will probably not need it. >> >> Have a look here: https://ffmpeg.org/ >> >>> Message: 2 >>> Date: Wed, 18 Sep 2019 23:44:19 +0200 >>> From: Sverre Moe >>> To: Philip Race >>> Cc: core-libs-dev at openjdk.java.net >>> Subject: Re: Comments on jpackage (JEP 343) >>> Message-ID: >>> > qakvDETiRxLFcNY0CVH4pOEzggDw at mail.gmail.com> >>> Content-Type: text/plain; charset="UTF-8" >>> >>> It is actually the javafx-web module that requires these. >>> >>> Anyone know what part of the Web module that needs the libavcodec and >>> libavcoded-ffmpeg? >>> >>> We are using a small part of the web module, just WebView for Tooltip >> with >>> HTML. No Video or Audio. >>> >>> /Sverre >> From sverre.moe at gmail.com Thu Sep 19 15:13:10 2019 From: sverre.moe at gmail.com (Sverre Moe) Date: Thu, 19 Sep 2019 17:13:10 +0200 Subject: Comments on jpackage (JEP 343) In-Reply-To: References: <65fd59de-d348-fd29-e3b1-af7a4f229406@jugs.org> Message-ID: It seems jpackage should not need to add these Requires to the RPM package. If adding the JavaFX modules to the runtime image, these so-files are bundled within the lib directory. Thus no need for them to be required for installing the RPM. They should perhaps only be necessary as required if the JavaFX modules are not in the runtime image, but only present as dependencies to the application. tor. 19. sep. 2019 kl. 15:14 skrev Kevin Rushforth < kevin.rushforth at oracle.com>: > > > As to why it has this Requires, perhaps I need to address it at the > JavaFX > > mailinglist. > > Yes, that would be best, as this is no longer related to jpackage. > > -- Kevin > > > On 9/19/2019 12:43 AM, Sverre Moe wrote: > > Yes it would seem so. > > > > I am still perplexed to why it has an RPM Requires > libavcodec-ffmpeg.so.56. > > That one does not exist as far as I can find anywhere. It is not provided > > with the ffmpeg package. > > I thought perhaps it was the same library as libavcodec.so.56 only named > > differently, but considering that also is listed among the Requires it > is a > > distinct package. > > As to why it has this Requires, perhaps I need to address it at the > JavaFX > > mailinglist. > > > > How does jpackage accumulate its RPM Requires list? I thought it had it > in > > a default RPM spec file, but I don't see how that can be, we use our own > > custom spec file, and jpackage adds many additional Requires not used in > > our own. Only when javafx-web is within the built runtime image used with > > jpackage, is these extra Requires used. > > The RPM spec template file does not have any hard coded Requires, only > > those from PACKAGE_DEPENDENCIES. I looked around in the source code, and > > could only see this was set from the command line arguments for > > dependencies. Does it scan the runtime image to produce its additional > > Requires list? I have the javafx as dependencies in my project, but those > > are not "scanned" for linux package dependencies. > > > https://hg.openjdk.java.net/jdk/sandbox/file/bf06a1d3aef6/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/ > > > > Trying with the --linux-package-deps none of those dependencies ended up > in > > the built RPM package. Only those from jpackage and those from our custom > > spec file. > > > > /Sverre > > > > > > tor. 19. sep. 2019 kl. 01:09 skrev Michael Paus : > > > >> If you don't use audio or video, you will probably not need it. > >> > >> Have a look here: https://ffmpeg.org/ > >> > >>> Message: 2 > >>> Date: Wed, 18 Sep 2019 23:44:19 +0200 > >>> From: Sverre Moe > >>> To: Philip Race > >>> Cc: core-libs-dev at openjdk.java.net > >>> Subject: Re: Comments on jpackage (JEP 343) > >>> Message-ID: > >>> >> qakvDETiRxLFcNY0CVH4pOEzggDw at mail.gmail.com> > >>> Content-Type: text/plain; charset="UTF-8" > >>> > >>> It is actually the javafx-web module that requires these. > >>> > >>> Anyone know what part of the Web module that needs the libavcodec and > >>> libavcoded-ffmpeg? > >>> > >>> We are using a small part of the web module, just WebView for Tooltip > >> with > >>> HTML. No Video or Audio. > >>> > >>> /Sverre > >> > > From philip.race at oracle.com Thu Sep 19 15:29:42 2019 From: philip.race at oracle.com (Philip Race) Date: Thu, 19 Sep 2019 08:29:42 -0700 Subject: Comments on jpackage (JEP 343) In-Reply-To: References: <65fd59de-d348-fd29-e3b1-af7a4f229406@jugs.org> Message-ID: <5D839EE6.9080000@oracle.com> I also think the list of dependencies is too much. It is probably being derived in an automatic manner that really isn't adequate. For example these (at least) are standard libraries included in the JDK run time you are verifying libawt.so()(64bit) libawt_xawt.so()(64bit) libjava.so()(64bit) libjli.so()(64bit) libjvm.so()(64bit) libjvm.so(SUNWprivate_1.1)(64bit) libverify.so()(64bit) and this .. libcairo.so.2()(64bit) ... I am not aware that either FX or AWT/2D has any direct dependency on Cairo. So this is perhaps being dragged in by some other lib (gdk) and if so, it is a bit presumptuous to assume that gdk necessarily implies Cairo .. and don't all rpms depend on rpm :-) Seems unnecessary for it to be here : rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsXz) <= 5.2-1 -phil On 9/19/19, 8:13 AM, Sverre Moe wrote: > It seems jpackage should not need to add these Requires to the RPM package. > If adding the JavaFX modules to the runtime image, these so-files are > bundled within the lib directory. > Thus no need for them to be required for installing the RPM. > They should perhaps only be necessary as required if the JavaFX modules are > not in the runtime image, but only present as dependencies to the > application. > > tor. 19. sep. 2019 kl. 15:14 skrev Kevin Rushforth< > kevin.rushforth at oracle.com>: > >>> As to why it has this Requires, perhaps I need to address it at the >> JavaFX >>> mailinglist. >> Yes, that would be best, as this is no longer related to jpackage. >> >> -- Kevin >> >> >> On 9/19/2019 12:43 AM, Sverre Moe wrote: >>> Yes it would seem so. >>> >>> I am still perplexed to why it has an RPM Requires >> libavcodec-ffmpeg.so.56. >>> That one does not exist as far as I can find anywhere. It is not provided >>> with the ffmpeg package. >>> I thought perhaps it was the same library as libavcodec.so.56 only named >>> differently, but considering that also is listed among the Requires it >> is a >>> distinct package. >>> As to why it has this Requires, perhaps I need to address it at the >> JavaFX >>> mailinglist. >>> >>> How does jpackage accumulate its RPM Requires list? I thought it had it >> in >>> a default RPM spec file, but I don't see how that can be, we use our own >>> custom spec file, and jpackage adds many additional Requires not used in >>> our own. Only when javafx-web is within the built runtime image used with >>> jpackage, is these extra Requires used. >>> The RPM spec template file does not have any hard coded Requires, only >>> those from PACKAGE_DEPENDENCIES. I looked around in the source code, and >>> could only see this was set from the command line arguments for >>> dependencies. Does it scan the runtime image to produce its additional >>> Requires list? I have the javafx as dependencies in my project, but those >>> are not "scanned" for linux package dependencies. >>> >> https://hg.openjdk.java.net/jdk/sandbox/file/bf06a1d3aef6/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/ >>> Trying with the --linux-package-deps none of those dependencies ended up >> in >>> the built RPM package. Only those from jpackage and those from our custom >>> spec file. >>> >>> /Sverre >>> >>> >>> tor. 19. sep. 2019 kl. 01:09 skrev Michael Paus: >>> >>>> If you don't use audio or video, you will probably not need it. >>>> >>>> Have a look here: https://ffmpeg.org/ >>>> >>>>> Message: 2 >>>>> Date: Wed, 18 Sep 2019 23:44:19 +0200 >>>>> From: Sverre Moe >>>>> To: Philip Race >>>>> Cc: core-libs-dev at openjdk.java.net >>>>> Subject: Re: Comments on jpackage (JEP 343) >>>>> Message-ID: >>>>> >>> qakvDETiRxLFcNY0CVH4pOEzggDw at mail.gmail.com> >>>>> Content-Type: text/plain; charset="UTF-8" >>>>> >>>>> It is actually the javafx-web module that requires these. >>>>> >>>>> Anyone know what part of the Web module that needs the libavcodec and >>>>> libavcoded-ffmpeg? >>>>> >>>>> We are using a small part of the web module, just WebView for Tooltip >>>> with >>>>> HTML. No Video or Audio. >>>>> >>>>> /Sverre >> From mark.reinhold at oracle.com Thu Sep 19 17:25:19 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 19 Sep 2019 10:25:19 -0700 Subject: Comments on jpackage (JEP 343) In-Reply-To: <4c9ee165-b724-4ed0-4563-1877f567067f@oracle.com> References: <20190903185855.D9F092BEC49@eggemoggin.niobe.net> <5D804F4A.3010103@oracle.com> <5D8051DF.2070903@oracle.com> <4c9ee165-b724-4ed0-4563-1877f567067f@oracle.com> Message-ID: <20190919102519.205163004@eggemoggin.niobe.net> jlink?s -o/--output option names exactly the thing being output, rather than a container for the thing being output. The jpackage option we?re discussing here names a container for the thing being output, much like the -d option of javac and javadoc. Using -d/--dest for jpackage is consistent with the JDK?s other command-line tools. - Mark From brent.christian at oracle.com Thu Sep 19 18:09:07 2019 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 19 Sep 2019 11:09:07 -0700 Subject: RFR 8221623 : Add StackWalker micro benchmarks to jdk repo In-Reply-To: References: Message-ID: Hi, Mandy Yes, that 'make' job would take ~7 hours on my machine. I believe this is typical for running micros using 'make'. AFAICT, the jmh defaults are used, so it forks (running all the warmups + iterations) 5 times. Trying another (>100 loc) benchmark at random, the java.lang.ArrayCopy one would take 25 hours. There might be a way to pass jmh args (e.g. '-f 1') via 'make test TEST=...', though I really only ever run benchmarks using 'java -jar path/to/benchmark.jar'. It may be worth looking into updating the make target to setup more practical JMH runtimes by default. But I don't think this an issue particular the new benchmarks. Thanks, -Brent On 9/18/19 7:33 PM, Mandy Chung wrote: > Hi Brent, > > $ make test TEST="micro:java.lang.StackWalkBench" > > It took very long that I killed the job.? Does this happen to you? > > Mandy > > On 9/13/19 3:07 PM, Brent Christian wrote: >> Hi, >> >> Please review these StackWalker and Throwable benchmarks for addition >> into the JDK microbenchmarks. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8221623 >> Webrev: >> http://cr.openjdk.java.net/~bchristi/8221623/webrev07/ >> >> The StackWalker benchmarks use StackWalker's forEach(), walk(), and >> Options to measure retrieval of various types of information from the >> call stack. >> >> The Throwable benchmarks do corresponding exercises; there are also a >> couple of Logging benchmarks. >> >> A JMH @Param is used to test a variety of call stack depths. >> >> >> In the future, we might consider a benchmark for >> Reflection.getCallerClass().? (It is more involved today to benchmark >> that method than at the time these benchmarks were originally written, >> so that one's commented out.) See JDK-8230976. >> >> Thanks, >> -Brent >> >> 1. https://bugs.openjdk.java.net/browse/JDK-8230976 > From kevin.rushforth at oracle.com Thu Sep 19 18:27:50 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 19 Sep 2019 11:27:50 -0700 Subject: Comments on jpackage (JEP 343) In-Reply-To: <20190919102519.205163004@eggemoggin.niobe.net> References: <20190903185855.D9F092BEC49@eggemoggin.niobe.net> <5D804F4A.3010103@oracle.com> <5D8051DF.2070903@oracle.com> <4c9ee165-b724-4ed0-4563-1877f567067f@oracle.com> <20190919102519.205163004@eggemoggin.niobe.net> Message-ID: <7c7197f1-edb7-6e6b-b303-4abe373d0051@oracle.com> OK, that makes sense. Andy has already implemented this change (pushed it to the sandbox), so it will be in the next EA build. -- Kevin On 9/19/2019 10:25 AM, mark.reinhold at oracle.com wrote: > jlink?s -o/--output option names exactly the thing being output, > rather than a container for the thing being output. > > The jpackage option we?re discussing here names a container for the > thing being output, much like the -d option of javac and javadoc. > > Using -d/--dest for jpackage is consistent with the JDK?s other > command-line tools. > > - Mark From brent.christian at oracle.com Thu Sep 19 19:08:49 2019 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 19 Sep 2019 12:08:49 -0700 Subject: RFR 8221623 : Add StackWalker micro benchmarks to jdk repo In-Reply-To: <1408b71b-bf20-eb45-376d-bcd8dc2d3e3d@oracle.com> References: <1408b71b-bf20-eb45-376d-bcd8dc2d3e3d@oracle.com> Message-ID: Hi, Daniel On 9/16/19 3:40 AM, Daniel Fuchs wrote: > > However I have some doubts about the the logging benchmark. > > Is the benchmark run in a single thread? If not then > there doesn't seem any guarantee that each call to publish() > will be immediately followed by a call to reset(), but instead, > if you have two threads, you could see things like: > > T1: publish(); > T2: publish();?? => T1 record would be lost here > T1: reset(); > T2: reset();???? => reset() would return null here Well-spotted. JMH defaults to using 1 worker thread, but can be configured to use more. I tried with '-t max' (8 threads on my machine), and the benchmark NPE'd, as you predicted. I've updated the benchmark to use a separate handler (and Logger) per-thread, and it can now run w/ '-t max'. Single-thread scores are within a few % of the original test. I also added "Logging" to the benchmark names to make it easier to select both in JMH using a simple regex. http://cr.openjdk.java.net/~bchristi/8221623/webrev09-loggerPerThread/ Though really, since logging is no longer using Throwable to examine the call stack, maybe it makes more sense to move the logging benchmarks to their own file under: test/micro/org/openjdk/bench/java/util/logging/ ? Thanks, -Brent > On 13/09/2019 23:07, Brent Christian wrote: >> Hi, >> >> Please review these StackWalker and Throwable benchmarks for addition >> into the JDK microbenchmarks. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8221623 >> Webrev: >> http://cr.openjdk.java.net/~bchristi/8221623/webrev07/ >> >> The StackWalker benchmarks use StackWalker's forEach(), walk(), and >> Options to measure retrieval of various types of information from the >> call stack. >> >> The Throwable benchmarks do corresponding exercises; there are also a >> couple of Logging benchmarks. >> >> A JMH @Param is used to test a variety of call stack depths. >> >> >> In the future, we might consider a benchmark for >> Reflection.getCallerClass().? (It is more involved today to benchmark >> that method than at the time these benchmarks were originally written, >> so that one's commented out.) See JDK-8230976. >> >> Thanks, >> -Brent >> >> 1. https://bugs.openjdk.java.net/browse/JDK-8230976 > From Roger.Riggs at oracle.com Thu Sep 19 19:13:30 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 19 Sep 2019 15:13:30 -0400 Subject: JDK 14 RFR of JDK-8231202: Suppress warnings on non-serializable non-transient instance fields in serializable classes In-Reply-To: References: Message-ID: <6d2a410f-acff-f2f7-a9b2-2c2bedaec10e@oracle.com> Hi Joe, The addition of @SuppressWarnings(serial) hides a number of instances of poor choices of types.? Before they dissappear behind the suppress warnings, the fix should be to correct the types used. For example, in the serialization proxies for java.time, the Ser class carelessly has a field of type Object when it could/should be using Serializable. The types being serialized and deserialized are known to be Serializable. See the attach patches for details and a suggested fix. Thanks, Roger (p.s. the patch is attached twice, once as .patch and the other .txt. I'd like to see if they both get through the mail). On 9/18/19 5:38 PM, Joe Darcy wrote: > Hello, > > As background, I'm working on a number of serialization-related > compile-time checks with the goal of enabling stricter javac lint > checking in the JDK build (and elsewhere). > > One check is tracked by > > ??? JDK-8160675: Issue lint warning for non-serializable non-transient > instance fields in serializable type > > As summarized in the bug description, it may be concerning if a > serializable class has non-transient instance fields whose types are > not Serializable. This can cause a serialization failure at runtime. > (Classes using the serialPersistentFields mechanism are excluded from > this check.) > > A common example is an exception type -- all Throwable's are > Serializable -- which has a non-serializable field. If the fields > cannot be marked as transient, one approach to handle this robustly is > to have a writeObject method which null outs the field in question > when serializing and make the other methods in the exception > null-tolerant. > > In other cases, the object pointed to by the non-serializable field > are conditionally serializable at runtime. This is the case for many > collection types. For example, a class may have a field of type > List with the field set to an ArrayList at runtime. While > the List interface does not extent Serializable, the ArrayList class > does implement Serializable and the class would serialize fine in > practice, assuming the Foo's were serialazable. > > As a precursor to the adding a compile-time check to the build, please > review adding @SuppressWarnings("serial") to document the > non-serializable fields in the core libraries: > > ??? JDK-8231202: Suppress warnings on non-serializable non-transient > instance fields in serializable classes > ??? http://cr.openjdk.java.net/~darcy/8231202.0/ > > Bugs for similar changes to client libs and security libs will be > filed and reviewed separately. > > A more complete fix would add readObject/writeObject null handling to > AnnotationTypeMismatchExceptionProxy, but since this hasn't seemed to > be an issue since the type was introduced back in JDK 5.0, I just > added the annotation, as done elsewhere. > > Thanks, > > -Joe > -------------- next part -------------- A non-text attachment was scrubbed... Name: Ser-serializable.patch Type: text/x-patch Size: 7973 bytes Desc: not available URL: -------------- next part -------------- # HG changeset patch # Parent aad3466779bbcc2778d039ef7aee01ac75228b86 diff -r aad3466779bb -r f584c4228c70 src/java.base/share/classes/java/lang/invoke/SerializedLambda.java --- a/src/java.base/share/classes/java/lang/invoke/SerializedLambda.java Thu Sep 19 14:40:54 2019 -0400 +++ b/src/java.base/share/classes/java/lang/invoke/SerializedLambda.java Thu Sep 19 15:04:48 2019 -0400 @@ -77,7 +77,7 @@ public final class SerializedLambda impl private final int implMethodKind; private final String instantiatedMethodType; @SuppressWarnings("serial") // Not statically typed as Serializable - private final Object[] capturedArgs; + private final Serializable[] capturedArgs; /** * Create a {@code SerializedLambda} from the low-level information present @@ -114,7 +114,7 @@ public final class SerializedLambda impl String implMethodName, String implMethodSignature, String instantiatedMethodType, - Object[] capturedArgs) { + Serializable[] capturedArgs) { this.capturingClass = capturingClass; this.functionalInterfaceClass = functionalInterfaceClass; this.functionalInterfaceMethodName = functionalInterfaceMethodName; diff -r aad3466779bb -r f584c4228c70 src/java.base/share/classes/java/time/Ser.java --- a/src/java.base/share/classes/java/time/Ser.java Thu Sep 19 14:40:54 2019 -0400 +++ b/src/java.base/share/classes/java/time/Ser.java Thu Sep 19 15:04:48 2019 -0400 @@ -61,6 +61,7 @@ import java.io.IOException; import java.io.InvalidClassException; import java.io.ObjectInput; import java.io.ObjectOutput; +import java.io.Serializable; import java.io.StreamCorruptedException; /** @@ -112,8 +113,7 @@ final class Ser implements Externalizabl /** The type being serialized. */ private byte type; /** The object being serialized. */ - @SuppressWarnings("serial") // Not statically typed as Serializable - private Object object; + private Serializable object; /** * Constructor for deserialization. @@ -127,7 +127,7 @@ final class Ser implements Externalizabl * @param type the type * @param object the object */ - Ser(byte type, Object object) { + Ser(byte type, Serializable object) { this.type = type; this.object = object; } @@ -248,12 +248,12 @@ final class Ser implements Externalizabl object = readInternal(type, in); } - static Object read(ObjectInput in) throws IOException, ClassNotFoundException { + static Serializable read(ObjectInput in) throws IOException, ClassNotFoundException { byte type = in.readByte(); return readInternal(type, in); } - private static Object readInternal(byte type, ObjectInput in) throws IOException, ClassNotFoundException { + private static Serializable readInternal(byte type, ObjectInput in) throws IOException, ClassNotFoundException { switch (type) { case DURATION_TYPE: return Duration.readExternal(in); case INSTANT_TYPE: return Instant.readExternal(in); diff -r aad3466779bb -r f584c4228c70 src/java.base/share/classes/java/time/chrono/AbstractChronology.java --- a/src/java.base/share/classes/java/time/chrono/AbstractChronology.java Thu Sep 19 14:40:54 2019 -0400 +++ b/src/java.base/share/classes/java/time/chrono/AbstractChronology.java Thu Sep 19 15:04:48 2019 -0400 @@ -731,7 +731,7 @@ public abstract class AbstractChronology */ @java.io.Serial Object writeReplace() { - return new Ser(Ser.CHRONO_TYPE, this); + return new Ser(Ser.CHRONO_TYPE, (Serializable)this); } /** diff -r aad3466779bb -r f584c4228c70 src/java.base/share/classes/java/time/chrono/Ser.java --- a/src/java.base/share/classes/java/time/chrono/Ser.java Thu Sep 19 14:40:54 2019 -0400 +++ b/src/java.base/share/classes/java/time/chrono/Ser.java Thu Sep 19 15:04:48 2019 -0400 @@ -61,6 +61,7 @@ import java.io.IOException; import java.io.InvalidClassException; import java.io.ObjectInput; import java.io.ObjectOutput; +import java.io.Serializable; import java.io.StreamCorruptedException; import java.time.LocalDate; import java.time.LocalDateTime; @@ -110,8 +111,7 @@ final class Ser implements Externalizabl /** The type being serialized. */ private byte type; /** The object being serialized. */ - @SuppressWarnings("serial") // Not statically typed as Serializable - private Object object; + private Serializable object; /** * Constructor for deserialization. @@ -125,7 +125,7 @@ final class Ser implements Externalizabl * @param type the type * @param object the object */ - Ser(byte type, Object object) { + Ser(byte type, Serializable object) { this.type = type; this.object = object; } @@ -231,11 +231,12 @@ final class Ser implements Externalizabl return readInternal(type, in); } - private static Object readInternal(byte type, ObjectInput in) throws IOException, ClassNotFoundException { + private static Serializable readInternal(byte type, ObjectInput in) throws IOException, + ClassNotFoundException { switch (type) { - case CHRONO_TYPE: return AbstractChronology.readExternal(in); - case CHRONO_LOCAL_DATE_TIME_TYPE: return ChronoLocalDateTimeImpl.readExternal(in); - case CHRONO_ZONE_DATE_TIME_TYPE: return ChronoZonedDateTimeImpl.readExternal(in); + case CHRONO_TYPE: return (Serializable)AbstractChronology.readExternal(in); + case CHRONO_LOCAL_DATE_TIME_TYPE: return (Serializable)ChronoLocalDateTimeImpl.readExternal(in); + case CHRONO_ZONE_DATE_TIME_TYPE: return (Serializable)ChronoZonedDateTimeImpl.readExternal(in); case JAPANESE_DATE_TYPE: return JapaneseDate.readExternal(in); case JAPANESE_ERA_TYPE: return JapaneseEra.readExternal(in); case HIJRAH_DATE_TYPE: return HijrahDate.readExternal(in); diff -r aad3466779bb -r f584c4228c70 src/java.base/share/classes/java/time/zone/Ser.java --- a/src/java.base/share/classes/java/time/zone/Ser.java Thu Sep 19 14:40:54 2019 -0400 +++ b/src/java.base/share/classes/java/time/zone/Ser.java Thu Sep 19 15:04:48 2019 -0400 @@ -68,6 +68,7 @@ import java.io.IOException; import java.io.InvalidClassException; import java.io.ObjectInput; import java.io.ObjectOutput; +import java.io.Serializable; import java.io.StreamCorruptedException; import java.time.ZoneOffset; @@ -97,8 +98,7 @@ final class Ser implements Externalizabl /** The type being serialized. */ private byte type; /** The object being serialized. */ - @SuppressWarnings("serial") // Not statically typed as Serializable - private Object object; + private Serializable object; /** * Constructor for deserialization. @@ -112,7 +112,7 @@ final class Ser implements Externalizabl * @param type the type * @param object the object */ - Ser(byte type, Object object) { + Ser(byte type, Serializable object) { this.type = type; this.object = object; } @@ -184,12 +184,13 @@ final class Ser implements Externalizabl object = readInternal(type, in); } - static Object read(DataInput in) throws IOException, ClassNotFoundException { + static Serializable read(DataInput in) throws IOException, ClassNotFoundException { byte type = in.readByte(); return readInternal(type, in); } - private static Object readInternal(byte type, DataInput in) throws IOException, ClassNotFoundException { + private static Serializable readInternal(byte type, DataInput in) throws IOException, + ClassNotFoundException { switch (type) { case ZRULES: return ZoneRules.readExternal(in); From joe.darcy at oracle.com Thu Sep 19 19:39:54 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 19 Sep 2019 12:39:54 -0700 Subject: JDK 14 RFR of JDK-8231202: Suppress warnings on non-serializable non-transient instance fields in serializable classes In-Reply-To: <6d2a410f-acff-f2f7-a9b2-2c2bedaec10e@oracle.com> References: <6d2a410f-acff-f2f7-a9b2-2c2bedaec10e@oracle.com> Message-ID: <0765c19e-e84e-1a20-753e-a9bf505c4054@oracle.com> Hi Roger, I think the Object -> Serializable type changes you suggest are fine improvements. Would you like to push them first ahead of applying @SuppressWarnings to the remaining locations? Thanks, -Joe On 9/19/2019 12:13 PM, Roger Riggs wrote: > Hi Joe, > > The addition of @SuppressWarnings(serial) hides a number of instances of > poor choices of types.? Before they dissappear behind the suppress > warnings, > the fix should be to correct the types used. > > For example, in the serialization proxies for java.time, the Ser class > carelessly > has a field of type Object when it could/should be using Serializable. > The types being serialized and deserialized are known to be Serializable. > See the attach patches for details and a suggested fix. > > Thanks, Roger > > (p.s. the patch is attached twice, once as .patch and the other .txt. > I'd like to see if they both get through the mail). > > On 9/18/19 5:38 PM, Joe Darcy wrote: >> Hello, >> >> As background, I'm working on a number of serialization-related >> compile-time checks with the goal of enabling stricter javac lint >> checking in the JDK build (and elsewhere). >> >> One check is tracked by >> >> ??? JDK-8160675: Issue lint warning for non-serializable >> non-transient instance fields in serializable type >> >> As summarized in the bug description, it may be concerning if a >> serializable class has non-transient instance fields whose types are >> not Serializable. This can cause a serialization failure at runtime. >> (Classes using the serialPersistentFields mechanism are excluded from >> this check.) >> >> A common example is an exception type -- all Throwable's are >> Serializable -- which has a non-serializable field. If the fields >> cannot be marked as transient, one approach to handle this robustly >> is to have a writeObject method which null outs the field in question >> when serializing and make the other methods in the exception >> null-tolerant. >> >> In other cases, the object pointed to by the non-serializable field >> are conditionally serializable at runtime. This is the case for many >> collection types. For example, a class may have a field of type >> List with the field set to an ArrayList at runtime. While >> the List interface does not extent Serializable, the ArrayList class >> does implement Serializable and the class would serialize fine in >> practice, assuming the Foo's were serialazable. >> >> As a precursor to the adding a compile-time check to the build, >> please review adding @SuppressWarnings("serial") to document the >> non-serializable fields in the core libraries: >> >> ??? JDK-8231202: Suppress warnings on non-serializable non-transient >> instance fields in serializable classes >> http://cr.openjdk.java.net/~darcy/8231202.0/ >> >> Bugs for similar changes to client libs and security libs will be >> filed and reviewed separately. >> >> A more complete fix would add readObject/writeObject null handling to >> AnnotationTypeMismatchExceptionProxy, but since this hasn't seemed to >> be an issue since the type was introduced back in JDK 5.0, I just >> added the annotation, as done elsewhere. >> >> Thanks, >> >> -Joe >> > From claes.redestad at oracle.com Thu Sep 19 20:40:28 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 19 Sep 2019 22:40:28 +0200 Subject: RFR 8221623 : Add StackWalker micro benchmarks to jdk repo In-Reply-To: References: Message-ID: <32fb594c-1d27-552c-1c9f-b8667db2f85d@oracle.com> Hi, FYI, you can control the number of forks etc run by make test: make test TEST="micro:java.lang.StackWalkBench" MICRO="FORK=1;WARMUP_ITER=2;OPTIONS=-p depth=128" (documented in doc/testing.md|html) Still, I agree it might be a good idea to have make test TEST=... run fewer forks/iterations by default, since this shortcut was primarily intended as a means for devs to quickly verify specific microbenchmarks. However, reducing forks and iterations only cuts down one factor of the total runtime: others being the number of methods and the number of chosen parameters (as controlled by @Param-annotated fields). So IMHO, what should be thought through carefully when adding micros is whether all methods are necessary or at least useful and whether we can reduce the number of parameter chosen. For these two, I think picking 2 or 3 values for depth (lowest, highest, maybe a midpoint) might be sufficient. This would cut total runtime budget by 60% or 40%, respectively. Thanks! /Claes On 2019-09-19 20:09, Brent Christian wrote: > Hi, Mandy > > Yes, that 'make' job would take ~7 hours on my machine. > I believe this is typical for running micros using 'make'.? AFAICT, the > jmh defaults are used, so it forks (running all the warmups + > iterations) 5 times.? Trying another (>100 loc) benchmark? at random, > the java.lang.ArrayCopy one would take 25 hours. > > There might be a way to pass jmh args (e.g. '-f 1') via 'make test > TEST=...', though I really only ever run benchmarks using 'java -jar > path/to/benchmark.jar'. > > It may be worth looking into updating the make target to setup more > practical JMH runtimes by default.? But I don't think this an issue > particular the new benchmarks. > > Thanks, > -Brent > On 9/18/19 7:33 PM, Mandy Chung wrote: >> Hi Brent, >> >> $ make test TEST="micro:java.lang.StackWalkBench" >> >> It took very long that I killed the job.? Does this happen to you? >> >> Mandy >> >> On 9/13/19 3:07 PM, Brent Christian wrote: >>> Hi, >>> >>> Please review these StackWalker and Throwable benchmarks for addition >>> into the JDK microbenchmarks. >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8221623 >>> Webrev: >>> http://cr.openjdk.java.net/~bchristi/8221623/webrev07/ >>> >>> The StackWalker benchmarks use StackWalker's forEach(), walk(), and >>> Options to measure retrieval of various types of information from the >>> call stack. >>> >>> The Throwable benchmarks do corresponding exercises; there are also a >>> couple of Logging benchmarks. >>> >>> A JMH @Param is used to test a variety of call stack depths. >>> >>> >>> In the future, we might consider a benchmark for >>> Reflection.getCallerClass().? (It is more involved today to benchmark >>> that method than at the time these benchmarks were originally >>> written, so that one's commented out.) See JDK-8230976. >>> >>> Thanks, >>> -Brent >>> >>> 1. https://bugs.openjdk.java.net/browse/JDK-8230976 >> > From forax at univ-mlv.fr Thu Sep 19 20:45:29 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 19 Sep 2019 22:45:29 +0200 (CEST) Subject: JDK 14 RFR of JDK-8231202: Suppress warnings on non-serializable non-transient instance fields in serializable classes In-Reply-To: <0765c19e-e84e-1a20-753e-a9bf505c4054@oracle.com> References: <6d2a410f-acff-f2f7-a9b2-2c2bedaec10e@oracle.com> <0765c19e-e84e-1a20-753e-a9bf505c4054@oracle.com> Message-ID: <1061082691.2179001.1568925929745.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "joe darcy" > ?: "Roger Riggs" , "core-libs-dev" > Envoy?: Jeudi 19 Septembre 2019 21:39:54 > Objet: Re: JDK 14 RFR of JDK-8231202: Suppress warnings on non-serializable non-transient instance fields in > serializable classes > Hi Roger, > > I think the Object -> Serializable type changes you suggest are fine > improvements. > > Would you like to push them first ahead of applying @SuppressWarnings to > the remaining locations? > > Thanks, > > -Joe Hi Joe, hi Roger, these changes are not fine, SerializedLambda is a public class with a public constructor so it's an incompatible change to replace Object[] by Serializable[], moreover for an array, all values can be Serializable but the array itself can be not Serializable, by example if the array is created as a Object... (varargs). there are other issues: - a class can be marked as Serializable but not being serialized at runtime, in that case, it's valid to construct an instance of a Serializable class with an argument which is typed Object instead of Serializable because it will not serialized (basically Serializable means can be serialized and not will be serialized). - using Serializable as type of a field means that if you have an interface you have to introduce a cast somewhere in the code, so you are moving the CCE that comes from writeObject to a CCE in the middle of the user code, i think i prefer the CCE to be issued inside writeObject because at least it's documented. the real question is what are the pro and cons of Serializable acting as a type instead of only as a marker interface that you can check at runtime, or said differently if the serialization was introduced after Java 5, is Serializable still be an interface or be an annotation instead. R?mi > > On 9/19/2019 12:13 PM, Roger Riggs wrote: >> Hi Joe, >> >> The addition of @SuppressWarnings(serial) hides a number of instances of >> poor choices of types.? Before they dissappear behind the suppress >> warnings, >> the fix should be to correct the types used. >> >> For example, in the serialization proxies for java.time, the Ser class >> carelessly >> has a field of type Object when it could/should be using Serializable. >> The types being serialized and deserialized are known to be Serializable. >> See the attach patches for details and a suggested fix. >> >> Thanks, Roger >> >> (p.s. the patch is attached twice, once as .patch and the other .txt. >> I'd like to see if they both get through the mail). >> >> On 9/18/19 5:38 PM, Joe Darcy wrote: >>> Hello, >>> >>> As background, I'm working on a number of serialization-related >>> compile-time checks with the goal of enabling stricter javac lint >>> checking in the JDK build (and elsewhere). >>> >>> One check is tracked by >>> >>> ??? JDK-8160675: Issue lint warning for non-serializable >>> non-transient instance fields in serializable type >>> >>> As summarized in the bug description, it may be concerning if a >>> serializable class has non-transient instance fields whose types are >>> not Serializable. This can cause a serialization failure at runtime. >>> (Classes using the serialPersistentFields mechanism are excluded from >>> this check.) >>> >>> A common example is an exception type -- all Throwable's are >>> Serializable -- which has a non-serializable field. If the fields >>> cannot be marked as transient, one approach to handle this robustly >>> is to have a writeObject method which null outs the field in question >>> when serializing and make the other methods in the exception >>> null-tolerant. >>> >>> In other cases, the object pointed to by the non-serializable field >>> are conditionally serializable at runtime. This is the case for many >>> collection types. For example, a class may have a field of type >>> List with the field set to an ArrayList at runtime. While >>> the List interface does not extent Serializable, the ArrayList class >>> does implement Serializable and the class would serialize fine in >>> practice, assuming the Foo's were serialazable. >>> >>> As a precursor to the adding a compile-time check to the build, >>> please review adding @SuppressWarnings("serial") to document the >>> non-serializable fields in the core libraries: >>> >>> ??? JDK-8231202: Suppress warnings on non-serializable non-transient >>> instance fields in serializable classes >>> http://cr.openjdk.java.net/~darcy/8231202.0/ >>> >>> Bugs for similar changes to client libs and security libs will be >>> filed and reviewed separately. >>> >>> A more complete fix would add readObject/writeObject null handling to >>> AnnotationTypeMismatchExceptionProxy, but since this hasn't seemed to >>> be an issue since the type was introduced back in JDK 5.0, I just >>> added the annotation, as done elsewhere. >>> >>> Thanks, >>> >>> -Joe >>> From mandy.chung at oracle.com Thu Sep 19 21:19:39 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 19 Sep 2019 14:19:39 -0700 Subject: RFR 8221623 : Add StackWalker micro benchmarks to jdk repo In-Reply-To: <32fb594c-1d27-552c-1c9f-b8667db2f85d@oracle.com> References: <32fb594c-1d27-552c-1c9f-b8667db2f85d@oracle.com> Message-ID: or make forks/iterations as required parameters when invoking the microbenchmark through make. I'm doing the micro test run just for the review and I want it to finish in short time.? Performance runs will be a different configuration. Mandy On 9/19/19 1:40 PM, Claes Redestad wrote: > Hi, > > FYI, you can control the number of forks etc run by make test: > > make test TEST="micro:java.lang.StackWalkBench" > MICRO="FORK=1;WARMUP_ITER=2;OPTIONS=-p depth=128" > > (documented in doc/testing.md|html) > > Still, I agree it might be a good idea to have make test TEST=... run > fewer forks/iterations by default, since this shortcut was primarily > intended as a means for devs to quickly verify specific microbenchmarks. > > However, reducing forks and iterations only cuts down one factor of the > total runtime: others being the number of methods and the number of > chosen parameters (as controlled by @Param-annotated fields). > > So IMHO, what should be thought through carefully when adding micros is > whether all methods are necessary or at least useful and whether we can > reduce the number of parameter chosen. > > For these two, I think picking 2 or 3 values for depth (lowest, highest, > maybe a midpoint) might be sufficient. This would cut total runtime > budget by 60% or 40%, respectively. > > Thanks! > > /Claes > > On 2019-09-19 20:09, Brent Christian wrote: >> Hi, Mandy >> >> Yes, that 'make' job would take ~7 hours on my machine. >> I believe this is typical for running micros using 'make'. AFAICT, >> the jmh defaults are used, so it forks (running all the warmups + >> iterations) 5 times.? Trying another (>100 loc) benchmark? at random, >> the java.lang.ArrayCopy one would take 25 hours. >> >> There might be a way to pass jmh args (e.g. '-f 1') via 'make test >> TEST=...', though I really only ever run benchmarks using 'java -jar >> path/to/benchmark.jar'. >> >> It may be worth looking into updating the make target to setup more >> practical JMH runtimes by default.? But I don't think this an issue >> particular the new benchmarks. >> >> Thanks, >> -Brent >> On 9/18/19 7:33 PM, Mandy Chung wrote: >>> Hi Brent, >>> >>> $ make test TEST="micro:java.lang.StackWalkBench" >>> >>> It took very long that I killed the job.? Does this happen to you? >>> >>> Mandy >>> >>> On 9/13/19 3:07 PM, Brent Christian wrote: >>>> Hi, >>>> >>>> Please review these StackWalker and Throwable benchmarks for >>>> addition into the JDK microbenchmarks. >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8221623 >>>> Webrev: >>>> http://cr.openjdk.java.net/~bchristi/8221623/webrev07/ >>>> >>>> The StackWalker benchmarks use StackWalker's forEach(), walk(), and >>>> Options to measure retrieval of various types of information from >>>> the call stack. >>>> >>>> The Throwable benchmarks do corresponding exercises; there are also >>>> a couple of Logging benchmarks. >>>> >>>> A JMH @Param is used to test a variety of call stack depths. >>>> >>>> >>>> In the future, we might consider a benchmark for >>>> Reflection.getCallerClass().? (It is more involved today to >>>> benchmark that method than at the time these benchmarks were >>>> originally written, so that one's commented out.) See JDK-8230976. >>>> >>>> Thanks, >>>> -Brent >>>> >>>> 1. https://bugs.openjdk.java.net/browse/JDK-8230976 >>> >> From forax at univ-mlv.fr Thu Sep 19 22:00:33 2019 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 20 Sep 2019 00:00:33 +0200 (CEST) Subject: RFR (L, final): 8218626: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <563186416.1041616.1568757083163.JavaMail.zimbra@u-pem.fr> Message-ID: <1893074105.2191032.1568930433981.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Goetz Lindenmaier" > ?: "Remi Forax" > Cc: "hotspot-runtime-dev" , "core-libs-dev" > Envoy?: Mercredi 18 Septembre 2019 09:37:36 > Objet: RE: RFR (L, final): 8218626: Add detailed message to NullPointerException describing what is null. > Hi Remi, Hi Goetz, > >> in bytecodeUtils.cpp, in print_local_var(), >> i believe that the code >> if (!method->is_static() && (slot == 0)) { >> os->print("this"); >> } >> ... >> is only true if the bytecode is generated by javac and ecj, tools like proguard >> that tries to obfuscate the code will reuse the slot 0 once "this" is not needed >> anymore. >> This is obviously also true for any other parameters, so in my opinion, you >> should not try to be too heroic here and always display "local%d". > Yes, you are right. I assume the bytecode local slots are mapped 1:1 to > the parameters and are not reused for other values. > >> The other solution is to propagate "this" and "parameter%d" during the static >> analysis, so "this" will become "local0" once a store_0 is seen. > It would be possible to spot the place where "this" is first overwritten. > For other parameters, this is not feasible, they are not read-only, so > stores don't indicate obfuscation. Java is not the only language to run on the Java plateform so try to detect "obfuscation" is again akind of shortcut. > > I could mark the whole method as 'obfuscated' once I see a store_0, > and then print "local" instead of "parameter" in all places. > This does not work for static methods, though. Nor for methods > where "this" is live to the end, but the parameter slots are > reused. and you can have a path with a store_0 and one without (the code is not linear). > > For obfuscated methods I would claim that printing "this" etc > is fine even if the slot is reused for another value. It just > adds to the obfuscation! But there might be code > that is just optimized and not meant to be obfuscated. I've used obfuscation as an example, but there are also valid case to reuse slots likeit will consume less stack memory if you are using a very small device. > > Best regards, > Goetz. regards, R?mi > > > > > > >> >> R?mi >> >> ----- Mail original ----- >> > De: "Goetz Lindenmaier" >> > ?: "hotspot-runtime-dev" , >> "core-libs-dev" >> > Envoy?: Mardi 17 Septembre 2019 16:18:03 >> > Objet: RE: RFR (L, final): 8218626: Add detailed message to >> NullPointerException describing what is null. >> >> > @core-libs experts, I would appreciate comments on the changes >> > to NullPointerException.java, especially wrt. the Javadoc comment. >> > The change there is S. >> > >> > Best regards, >> > Goetz. >> > >> >> -----Original Message----- >> >> From: Lindenmaier, Goetz >> >> Sent: Dienstag, 10. September 2019 11:48 >> >> To: 'Hotspot dev runtime' ; >> Java Core >> >> Libs >> >> Subject: RFR (L, final): 8218626: Add detailed message to >> NullPointerException >> >> describing what is null. >> >> >> >> Hi, >> >> >> >> >> >> >> >> this is the implementation of JEP 358: Helpful NullPointerExceptions. >> >> >> >> >> >> >> >> The JEP is in status "Candidate". Coleen (many, many thanks!) ran >> >> >> >> it through the Oracle-internal processes. Now I please need final reviews >> >> >> >> for this change so that I can propose it to target jdk 14. >> >> >> >> >> >> >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8220715 >> >> >> >> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8218628 >> >> >> >> webrev: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg- >> NPE/16/ >> >> >> >> >> >> >> >> The change ran through a lot of testing, all jtreg and jck tests to name >> >> >> >> only some. The webrev points to patch >> >> >> >> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg- >> >> NPE/16/enable_NPE_message.patch >> >> >> >> that enables the change by default, which was useful for testing to >> >> >> >> assure the code is used in the tests. >> >> >> >> I just pushed the change to jdk/submit once more. >> >> >> >> >> >> >> >> Please review. >> >> >> >> >> >> >> >> Thanks! >> >> > > > > Goetz. From joe.darcy at oracle.com Thu Sep 19 22:34:58 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 19 Sep 2019 15:34:58 -0700 Subject: JDK 14 RFR of JDK-8199424: consider removing ObjectInputStream and ObjectOutputStream native methods Message-ID: <88e88816-f685-7d0d-4fb9-f3304d0ec726@oracle.com> Hello, As part of my serialization work, I noticed some "to do" notes in ObjectOutputStream.java to get rid of two native methods once the integral <-> floating-point bitwise conversion methods (Float.floatToIntBits, etc.) were intrinsified. That intrinsification occurred many releases back and the recommended cleanup can be done now. Pre-existing bug for this issue: ???? JDK-8199424 : consider removing ObjectInputStream and ObjectOutputStream native methods ??? http://cr.openjdk.java.net/~darcy/8199424.0/ Note the logic controlling for copying the float bytes is the same as the logic for copying the int bytes as both int and float are 4 bytes, same relationship between the copying of double and long bytes. The serialization regression tests pass with this change. I have not attempted to benchmark any speed differences with and without the cleanup, but would welcome such an experiment being done. Thanks, -Joe From huizhe.wang at oracle.com Fri Sep 20 00:00:05 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 19 Sep 2019 17:00:05 -0700 Subject: RFR [14/java.xml] 8231083: Clarify SAX documentation Message-ID: Please review a follow-up doc clarification patch after 8230814 [1]. In this patch, the statement with a reference to the SAX project is moved to an apiNote in package/sub-package description to reflect the fact that it is a historical note in nature. The license related text that appears in the class description of every SAX class is removed and consolidated with the existing text in the license header. JBS: https://bugs.openjdk.java.net/browse/JDK-8231083 webrev: http://cr.openjdk.java.net/~joehw/jdk14/8231083/webrev/index.html [1] https://bugs.openjdk.java.net/browse/JDK-8230814 Thanks, Joe From brian.burkhalter at oracle.com Fri Sep 20 00:19:14 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 19 Sep 2019 17:19:14 -0700 Subject: JDK 14 RFR of JDK-8199424: consider removing ObjectInputStream and ObjectOutputStream native methods In-Reply-To: <88e88816-f685-7d0d-4fb9-f3304d0ec726@oracle.com> References: <88e88816-f685-7d0d-4fb9-f3304d0ec726@oracle.com> Message-ID: <7FDB4FEA-6CE3-40A5-8A7B-2FF988622E83@oracle.com> Hi Joe, This looks good. Will there be a similar separate patch for ObjectInputStream? Brian > On Sep 19, 2019, at 3:34 PM, Joe Darcy wrote: > > As part of my serialization work, I noticed some "to do" notes in ObjectOutputStream.java to get rid of two native methods once the integral <-> floating-point bitwise conversion methods (Float.floatToIntBits, etc.) were intrinsified. That intrinsification occurred many releases back and the recommended cleanup can be done now. Pre-existing bug for this issue: > > JDK-8199424 : consider removing ObjectInputStream and ObjectOutputStream native methods > http://cr.openjdk.java.net/~darcy/8199424.0/ > > Note the logic controlling for copying the float bytes is the same as the logic for copying the int bytes as both int and float are 4 bytes, same relationship between the copying of double and long bytes. From lance.andersen at oracle.com Fri Sep 20 00:18:34 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 19 Sep 2019 20:18:34 -0400 Subject: RFR [14/java.xml] 8231083: Clarify SAX documentation In-Reply-To: References: Message-ID: <4A513D16-0094-4150-B15B-79B3E21EC903@oracle.com> Hi Joe, Overall this looks good and also cleans up a couple of typos :-) One nit in both package-info @apiNote, you will notice an extra space before the was which could be removed before you push Best Lance > On Sep 19, 2019, at 8:00 PM, Joe Wang wrote: > > Please review a follow-up doc clarification patch after 8230814 [1]. In this patch, the statement with a reference to the SAX project is moved to an apiNote in package/sub-package description to reflect the fact that it is a historical note in nature. The license related text that appears in the class description of every SAX class is removed and consolidated with the existing text in the license header. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8231083 > webrev: http://cr.openjdk.java.net/~joehw/jdk14/8231083/webrev/index.html > > > [1] https://bugs.openjdk.java.net/browse/JDK-8230814 > > 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 joe.darcy at oracle.com Fri Sep 20 03:02:30 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 19 Sep 2019 20:02:30 -0700 Subject: JDK 14 RFR of JDK-8199424: consider removing ObjectInputStream and ObjectOutputStream native methods In-Reply-To: <7FDB4FEA-6CE3-40A5-8A7B-2FF988622E83@oracle.com> References: <88e88816-f685-7d0d-4fb9-f3304d0ec726@oracle.com> <7FDB4FEA-6CE3-40A5-8A7B-2FF988622E83@oracle.com> Message-ID: <6a80116f-6971-eea7-9ec3-12a19e6f569a@oracle.com> Hi Brian, Now including ObjectInputStream changes: ???? http://cr.openjdk.java.net/~darcy/8199424.1/ Serialization regression tests still all pass. Thanks, -Joe On 9/19/2019 5:19 PM, Brian Burkhalter wrote: > Hi Joe, > > This looks good. Will there be a similar separate patch for > ObjectInputStream? > > Brian > >> On Sep 19, 2019, at 3:34 PM, Joe Darcy > > wrote: >> >> As part of my serialization work, I noticed some "to do" notes in >> ObjectOutputStream.java to get rid of two native methods once the >> integral <-> floating-point bitwise conversion methods >> (Float.floatToIntBits, etc.) were intrinsified. That intrinsification >> occurred many releases back and the recommended cleanup can be done >> now. Pre-existing bug for this issue: >> >> ???? JDK-8199424 : consider removing ObjectInputStream and >> ObjectOutputStream native methods >> http://cr.openjdk.java.net/~darcy/8199424.0/ >> >> Note the logic controlling for copying the float bytes is the same as >> the logic for copying the int bytes as both int and float are 4 >> bytes, same relationship between the copying of double and long bytes. > From claes.redestad at oracle.com Fri Sep 20 04:32:38 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 20 Sep 2019 06:32:38 +0200 Subject: JDK 14 RFR of JDK-8199424: consider removing ObjectInputStream and ObjectOutputStream native methods In-Reply-To: <88e88816-f685-7d0d-4fb9-f3304d0ec726@oracle.com> References: <88e88816-f685-7d0d-4fb9-f3304d0ec726@oracle.com> Message-ID: <0d46beb4-cef2-a218-44c5-f516a2e7ac8a@oracle.com> On 2019-09-20 00:34, Joe Darcy wrote: > I have not attempted to benchmark any speed differences with and without > the cleanup, but would welcome such an experiment being done. I ran a quick, naive test by modifying an existing serialization micro[1], and results are in the noise on default/tiered and C1 (-XX:TieredStopAtLevel=1) while there seems to be a 5-10% regression running interpreter only (not verified to be statistically significant), which is somewhat expected but inconsequential. So no reason to worry AFAICT - ship it! /Claes [1] diff -r 3386b9a8ef4d test/micro/org/openjdk/bench/java/io/SerializationWriteReplace.java --- a/test/micro/org/openjdk/bench/java/io/SerializationWriteReplace.java Thu Sep 19 23:38:50 2019 +0200 +++ b/test/micro/org/openjdk/bench/java/io/SerializationWriteReplace.java Fri Sep 20 06:35:34 2019 +0200 @@ -83,8 +83,8 @@ public static class Class3 extends Base { private static final long serialVersionUID = 4L; - private String tuto = "tuto"; - private byte b = (byte) 0xff; + private float[] floats = new float[] { 1.5f, -1.43f, 131313131313.0f }; + private double[] doubles = new double[] { 1.5, -1.43, 131313131313.0 }; } } From huizhe.wang at oracle.com Fri Sep 20 05:15:31 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 19 Sep 2019 22:15:31 -0700 Subject: RFR [14/java.xml] 8231083: Clarify SAX documentation In-Reply-To: <4A513D16-0094-4150-B15B-79B3E21EC903@oracle.com> References: <4A513D16-0094-4150-B15B-79B3E21EC903@oracle.com> Message-ID: <72ee4560-3989-6ef2-3f90-2dc71668e913@oracle.com> Thanks Lance! Yes, saw them typos :-)? Also removed the extra space in apiNote. Updated webrev below, with removing the text in the javadoc instead of moving to the header. http://cr.openjdk.java.net/~joehw/jdk14/8231083/webrev/index.html -Joe On 9/19/19 5:18 PM, Lance Andersen wrote: > Hi Joe, > > Overall this looks good and also cleans up a couple of typos :-) > > One nit in both package-info @apiNote, you will notice an extra space > before the was which could be removed before you push > > Best > Lance >> On Sep 19, 2019, at 8:00 PM, Joe Wang > > wrote: >> >> Please review a follow-up doc clarification patch after 8230814 [1]. >> In this patch, the statement with a reference to the SAX project is >> moved to an apiNote in package/sub-package description to reflect the >> fact that it is a historical note in nature. The license related text >> that appears in the class description of every SAX class is removed >> and consolidated with the existing text in the license header. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8231083 >> webrev: http://cr.openjdk.java.net/~joehw/jdk14/8231083/webrev/index.html >> >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8230814 >> >> 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 matthias.baesken at sap.com Fri Sep 20 07:03:33 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 20 Sep 2019 07:03:33 +0000 Subject: [RFR] 8231171: remove remaining sun.java.launcher.pid references - was RE: sun.java.launcher.pid property usage In-Reply-To: <3db7390f-36df-d304-3188-d11e35a673ab@oracle.com> References: <3db7390f-36df-d304-3188-d11e35a673ab@oracle.com> Message-ID: Hello, looks like on Linux there is a special check in TestSpecialArgs.java for launcherPidString = "launcher.pid=" that fails after 8231171 . Should I adjust the test ? Or keep the setting in the launcher on Linux ? tools/launcher/TestSpecialArgs.java /* * On Linux, Launcher Tracking will print the PID. Use this info * to validate what we got as the PID in the Launcher itself. * Linux is the only one that prints this, and trying to get it * here for win is awful. So let the linux test make sure we get * the valid pid, and for non-linux, just make sure pid string is * non-zero. */ if (isLinux) { . . . . . if (launcherPid == null) { System.out.println(tr); throw new RuntimeException("Error: failed to find launcher Pid in launcher tracking info"); } ... Exception thrown by the test : ----begin detailed exceptions---- java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at TestHelper.run(TestHelper.java:202) at TestSpecialArgs.main(TestSpecialArgs.java:44) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:830) Caused by: java.lang.RuntimeException: Error: failed to find launcher Pid in launcher tracking info at TestSpecialArgs.testNativeMemoryTracking(TestSpecialArgs.java:193) ... 12 more Best regards, Matthias > > Hi Matthias, > > Thanks for cleaning this up. > > On 19/09/2019 4:57 pm, Baesken, Matthias wrote: > > Hello, as discussed below , I want to cleanup some older references to > sun.java.launcher.pid. > > Please review the following change. > > > > After removal of some code belonging old LinuxThreads (JDK-8078513) , > the sun.java.launcher.pid handling code remained but > > seems to be obsolete these days . > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8231171 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8231171.0/ > > src/hotspot/os/bsd/os_bsd.cpp > > Can you delete the entire comment block here: > > 1126 // Under the old bsd thread library, bsd gives each thread > ... > 1140 // OSThread::thread_id() method in osThread_bsd.hpp file > > as it was simply copied from Linux and is nonsense on BSD. > > Otherwise that all looks good to me. No need for an updated webrev. > > Thanks, > David > ----- > > > Best regards, Matthias > > > > > >> > >> Hi David, thanks for the additional information . > >> I opened > >> > >> https://bugs.openjdk.java.net/browse/JDK-8231171 > >> > >> 8231171: remove reamining sun.java.launcher.pid references > >> > >> to do the additional cleanup . > >> > >> Best regards, Matthias > >> > >> > >>> -----Original Message----- > >>> From: David Holmes > >>> Sent: Mittwoch, 18. September 2019 03:16 > >>> To: Baesken, Matthias ; 'hotspot- > >>> dev at openjdk.java.net' > >>> Subject: Re: sun.java.launcher.pid property usage > >>> > >>> Hi Matthias, > >>> > >>> On 18/09/2019 12:18 am, Baesken, Matthias wrote: > >>>> Hello, while looking at some atoi usages in the codebase I started to > >>> wonder about the "sun.java.launcher.pid" property. > >>>> Currently in java_md_solinux.c the property is set on Linux only by > >> default > >>> (code is guarded #ifdef __linux__ ). > >>>> Later it is passed to the int variable _sun_java_launcher_pid > >>> (arguments.cpp) and can be retrieved by sun_java_launcher_pid() . > >>>> However only in src/hotspot/os/bsd/os_bsd.cpp it is really used. > >>>> > >>>> Is the property still supported (one would need to set it from user side > on > >>> the command line on non-Linux because it is not set by default on > >>> bsd/macOS) ? > >>>> Can the coding be removed (or should it enabled for BSD/Mac like we > do > >>> on Linux) ? > >>>> > >>>> The os_bsd comment mentiones the bug 6351349 : > >>>> > >>>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6351349 > >>>> JDK-6351349 : On linux with the old thread lib, jps should return the > same > >>> PID as $! > >>>> > >>>> but this looks very old. > >>> > >>> That was the bug that added this code as it was needed on Linux with > >>> LinuxThreads. The code was then removed on Linux under > >>> > >>> https://bugs.openjdk.java.net/browse/JDK-8078513 > >>> > >>> The review thread starts here: > >>> > >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015- > >>> May/014709.html > >>> > >>> I think we were focussed solely on cleaning up the hotspot Linux code > >>> and didn't really look at the wider implication of the use of > >>> sun.java.launcher.pid. The code in os_bsd.cpp was simply copied from > the > >>> Linux code without giving it any consideration - as you can tell from > >>> the comment: > >>> > >>> // With BsdThreads the JavaMain thread pid (primordial thread) > >>> // is different than the pid of the java launcher thread. > >>> // So, on Bsd, the launcher thread pid is passed to the VM > >>> // via the sun.java.launcher.pid property. > >>> > >>> where you can tell that Linux was simply replaced by Bsd, so we > >>> reference the non-existent BsdThreads :( > >>> > >>> So yes this all seems to be dead code that should be removed - core-libs > >>> folk will need to be involved of course as they own the launcher. :) It > >>> looks like SetJavaLauncherPlatformProps() can be removed completely. > >>> > >>> Thanks, > >>> David > > From david.holmes at oracle.com Fri Sep 20 08:11:09 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 20 Sep 2019 18:11:09 +1000 Subject: [RFR] 8231171: remove remaining sun.java.launcher.pid references - was RE: sun.java.launcher.pid property usage In-Reply-To: References: <3db7390f-36df-d304-3188-d11e35a673ab@oracle.com> Message-ID: <765279b9-1b60-88ad-8548-3f5cf1b19f28@oracle.com> Hi Matthias, On 20/09/2019 5:03 pm, Baesken, Matthias wrote: > > Hello, looks like on Linux there is a special check in TestSpecialArgs.java for > > launcherPidString = "launcher.pid=" > > that fails after 8231171 . > Should I adjust the test ? Or keep the setting in the launcher on Linux ? IMHO adjust the test please. Thanks, David ----- > > tools/launcher/TestSpecialArgs.java > > > /* > * On Linux, Launcher Tracking will print the PID. Use this info > * to validate what we got as the PID in the Launcher itself. > * Linux is the only one that prints this, and trying to get it > * here for win is awful. So let the linux test make sure we get > * the valid pid, and for non-linux, just make sure pid string is > * non-zero. > */ > if (isLinux) { > . . . . . > if (launcherPid == null) { > System.out.println(tr); > throw new RuntimeException("Error: failed to find launcher Pid in launcher tracking info"); > } > ... > > Exception thrown by the test : > > > ----begin detailed exceptions---- > java.lang.reflect.InvocationTargetException > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:564) > at TestHelper.run(TestHelper.java:202) > at TestSpecialArgs.main(TestSpecialArgs.java:44) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:564) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:830) > Caused by: java.lang.RuntimeException: Error: failed to find launcher Pid in launcher tracking info > at TestSpecialArgs.testNativeMemoryTracking(TestSpecialArgs.java:193) > ... 12 more > > > Best regards, Matthias > > > >> >> Hi Matthias, >> >> Thanks for cleaning this up. >> >> On 19/09/2019 4:57 pm, Baesken, Matthias wrote: >>> Hello, as discussed below , I want to cleanup some older references to >> sun.java.launcher.pid. >>> Please review the following change. >>> >>> After removal of some code belonging old LinuxThreads (JDK-8078513) , >> the sun.java.launcher.pid handling code remained but >>> seems to be obsolete these days . >>> >>> Bug/webrev : >>> >>> https://bugs.openjdk.java.net/browse/JDK-8231171 >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8231171.0/ >> >> src/hotspot/os/bsd/os_bsd.cpp >> >> Can you delete the entire comment block here: >> >> 1126 // Under the old bsd thread library, bsd gives each thread >> ... >> 1140 // OSThread::thread_id() method in osThread_bsd.hpp file >> >> as it was simply copied from Linux and is nonsense on BSD. >> >> Otherwise that all looks good to me. No need for an updated webrev. >> >> Thanks, >> David >> ----- >> >>> Best regards, Matthias >>> >>> >>>> >>>> Hi David, thanks for the additional information . >>>> I opened >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8231171 >>>> >>>> 8231171: remove reamining sun.java.launcher.pid references >>>> >>>> to do the additional cleanup . >>>> >>>> Best regards, Matthias >>>> >>>> >>>>> -----Original Message----- >>>>> From: David Holmes >>>>> Sent: Mittwoch, 18. September 2019 03:16 >>>>> To: Baesken, Matthias ; 'hotspot- >>>>> dev at openjdk.java.net' >>>>> Subject: Re: sun.java.launcher.pid property usage >>>>> >>>>> Hi Matthias, >>>>> >>>>> On 18/09/2019 12:18 am, Baesken, Matthias wrote: >>>>>> Hello, while looking at some atoi usages in the codebase I started to >>>>> wonder about the "sun.java.launcher.pid" property. >>>>>> Currently in java_md_solinux.c the property is set on Linux only by >>>> default >>>>> (code is guarded #ifdef __linux__ ). >>>>>> Later it is passed to the int variable _sun_java_launcher_pid >>>>> (arguments.cpp) and can be retrieved by sun_java_launcher_pid() . >>>>>> However only in src/hotspot/os/bsd/os_bsd.cpp it is really used. >>>>>> >>>>>> Is the property still supported (one would need to set it from user side >> on >>>>> the command line on non-Linux because it is not set by default on >>>>> bsd/macOS) ? >>>>>> Can the coding be removed (or should it enabled for BSD/Mac like we >> do >>>>> on Linux) ? >>>>>> >>>>>> The os_bsd comment mentiones the bug 6351349 : >>>>>> >>>>>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6351349 >>>>>> JDK-6351349 : On linux with the old thread lib, jps should return the >> same >>>>> PID as $! >>>>>> >>>>>> but this looks very old. >>>>> >>>>> That was the bug that added this code as it was needed on Linux with >>>>> LinuxThreads. The code was then removed on Linux under >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8078513 >>>>> >>>>> The review thread starts here: >>>>> >>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015- >>>>> May/014709.html >>>>> >>>>> I think we were focussed solely on cleaning up the hotspot Linux code >>>>> and didn't really look at the wider implication of the use of >>>>> sun.java.launcher.pid. The code in os_bsd.cpp was simply copied from >> the >>>>> Linux code without giving it any consideration - as you can tell from >>>>> the comment: >>>>> >>>>> // With BsdThreads the JavaMain thread pid (primordial thread) >>>>> // is different than the pid of the java launcher thread. >>>>> // So, on Bsd, the launcher thread pid is passed to the VM >>>>> // via the sun.java.launcher.pid property. >>>>> >>>>> where you can tell that Linux was simply replaced by Bsd, so we >>>>> reference the non-existent BsdThreads :( >>>>> >>>>> So yes this all seems to be dead code that should be removed - core-libs >>>>> folk will need to be involved of course as they own the launcher. :) It >>>>> looks like SetJavaLauncherPlatformProps() can be removed completely. >>>>> >>>>> Thanks, >>>>> David >>> From matthias.baesken at sap.com Fri Sep 20 09:14:39 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 20 Sep 2019 09:14:39 +0000 Subject: [RFR] 8231171: remove remaining sun.java.launcher.pid references - was RE: sun.java.launcher.pid property usage In-Reply-To: <765279b9-1b60-88ad-8548-3f5cf1b19f28@oracle.com> References: <3db7390f-36df-d304-3188-d11e35a673ab@oracle.com> <765279b9-1b60-88ad-8548-3f5cf1b19f28@oracle.com> Message-ID: Hi David , I adjusted the test ( test/jdk/tools/launcher/TestSpecialArgs.java ) and removed the comments in os_bsd.cpp (suggested by you) . New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8231171.1/ Best regards, Matthias > Hi Matthias, > > On 20/09/2019 5:03 pm, Baesken, Matthias wrote: > > > > Hello, looks like on Linux there is a special check in TestSpecialArgs.java > for > > > > launcherPidString = "launcher.pid=" > > > > that fails after 8231171 . > > Should I adjust the test ? Or keep the setting in the launcher on Linux ? > > IMHO adjust the test please. > > Thanks, > David > ----- > From david.holmes at oracle.com Fri Sep 20 09:41:04 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 20 Sep 2019 19:41:04 +1000 Subject: [RFR] 8231171: remove remaining sun.java.launcher.pid references - was RE: sun.java.launcher.pid property usage In-Reply-To: References: <3db7390f-36df-d304-3188-d11e35a673ab@oracle.com> <765279b9-1b60-88ad-8548-3f5cf1b19f28@oracle.com> Message-ID: <173137cf-2fbd-1d5a-17d2-a2d42265f688@oracle.com> That looks fine to me. Thanks, David On 20/09/2019 7:14 pm, Baesken, Matthias wrote: > Hi David , I adjusted the test ( test/jdk/tools/launcher/TestSpecialArgs.java ) and removed the comments in os_bsd.cpp (suggested by you) . > New webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8231171.1/ > > Best regards, Matthias > > > > >> Hi Matthias, >> >> On 20/09/2019 5:03 pm, Baesken, Matthias wrote: >>> >>> Hello, looks like on Linux there is a special check in TestSpecialArgs.java >> for >>> >>> launcherPidString = "launcher.pid=" >>> >>> that fails after 8231171 . >>> Should I adjust the test ? Or keep the setting in the launcher on Linux ? >> >> IMHO adjust the test please. >> >> Thanks, >> David >> ----- >> > From julia.boes at oracle.com Fri Sep 20 10:22:40 2019 From: julia.boes at oracle.com (Julia Boes) Date: Fri, 20 Sep 2019 11:22:40 +0100 Subject: RFR: 8231186: Replace html tag foo with javadoc tag {@code foo} in java.base In-Reply-To: References: <733ed056-1606-0c75-feaf-cc3066e4f6eb@oracle.com> <297d817e-b0d9-2814-bb1c-80c6f67a7147@oracle.com> <67c75546-1683-9140-89b7-98f189839843@oracle.com> <454c636e-2c11-a14d-f33f-9d06f3fdae7b@oracle.com> Message-ID: Hi, Thanks for noticing the glitch in the sdiffs, Naoto and Brent. I see that there is indeed an issue with the webrev script and I'm looking into a workaround. The following classes are affected: src/java.base/share/classes/java/lang/SecurityManager.java src/java.base/share/classes/java/util/Calendar.java src/java.base/share/classes/java/util/ResourceBundle.java src/java.base/share/classes/java/util/regex/Matcher.java > java/io/InputStream.java: > > ?243????? *

The {@code read(b,} {@code off,} {@code len)} method > > I believe this can be simplified to: > > {@code read(b, off, len)} > > -- Changed! > Here's something I found examples of in several places, for instance > in PipedInputStream.java: > > ?195????? * @exception IOException If the pipe is > {@code broken}, > > Here we have a link written out in HTML, with {@code} used within the > displayed text of the link.? This would typically be done instead by > using a @link tag, as on the next line: > > ?196????? *????????? {@link #connect(java.io.PipedOutputStream) > unconnected}, > > Peeking at the generated HTML, AFAICT the @link tag takes care of > generating the styling in the generated HTML.? I think > it's worth considering converting these 's to @link, > either now or as future work. Brent, I can make this change but can the @link tag link to a HTML id? It's not mentioned in the documentation https://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#link. I expected occurrences of '' would need changes as well, but it appears there aren't any in java.base (some previous effort cleaned this up, I guess). ??? That's right, there are none in java.base. I recall thinking that many of the should actually be changed to?@link since use of suggested ancient times before?@link became available. But "Perfect is the enemy of good". ??? I agree, if that's ok I would leave that as future work ;) Regards, Julia From ralf.schmelter at sap.com Fri Sep 20 10:58:57 2019 From: ralf.schmelter at sap.com (Schmelter, Ralf) Date: Fri, 20 Sep 2019 10:58:57 +0000 Subject: RFR (L, final): 8218626: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: Message-ID: Hi Goetz, here are my review remarks: In javaClasses.cpp: > #define CLASS_FIELDS_DO(macro) \ > macro(classRedefinedCount_offset, k, "classRedefinedCount", int_signature, false); \ > macro(_class_loader_offset, k, "classLoader", classloader_signature, false); \ The field name should match the other field names. So _class_redefined_count_offset instead of classRedefinedCount_offset. The method java_lang_Throwable::get_method_and_bci() should be renamed java_lang_Throwable::get_top_method_and_bci(). The usage of java.lang.Boolean(true) as the marker pointer leads to more code than a simpler, but more hackish solution (e.g. just reusing a reference to the backtrace array itself). I'm not sure it is really worth it. Considering you in the end just test for != NULL. In jvm.cpp: The method trim_well_known_class_names() would convert a name like test.java.lang.String to test.String. I think you have to be more specific when replacing a name. In bytecodeUtils.cpp: The method get_slotData() should be renamed get_slot_data() in class SimulatedOperandStack. The parameter innerExpr should be renamed inner_expr. In method print_local_var() you could initialize param_index to 1 instead of 0 and remove adding 1 later. In ExceptionMessageBuilder::ExceptionMessageBuilder you should add spaces in '(len+1)'. Since the ExceptionMessageBuilder is only used with a bci >= 0, you could remove the code which handles the case for bci < 0 (where we would create the simulated stack for every bci). In ExceptionMessageBuilder::do_instruction() the dup2 bytecode seems to be implemented wrongly, since you seemingly push two times the same value. It isn't, since you change the stack with the push, so in the first push you push the top of stack - 1 entry, and in the next push the former top of stack. A comment should be added to make this clearer or change to the code to use temporary variables. In ExceptionMessageBuilder::do_instruction() the is_wide variable is never used, so it should be removed. In ExceptionMessageBuilder::do_instruction() when handling the invoke* bytecodes, there is the following code: if ((code != Bytecodes::_invokestatic) && (code != Bytecodes::_invokedynamic)) { // Pop class. stack->pop(1); } The // Pop class comment is misleading, because the receiver is popped in reality. In ExceptionMessageBuilder::get_NPE_null_slot() the opening brace for the invoke* cases should be consistent with the rest of the code. In ExceptionMessageBuilder::get_NPE_null_slot() maybe we should use defines for -2 and -1 which convey the meaning of that return values. In ExceptionMessageBuilder::print_NPE_failed_action() you assert that the method holder is not the NativeConstructorAccessorImpl, noting that this should already have been checked In get_NPE_null_slot(). But I don't see any code in that message which would check this, it seemed to be check in BytecodeUtils::get_NPE_message_at() instead. In NullPointerExceptionTest.java: It seems you don't have tests for invokeinterface or invokespecial calls to cause an NPE (e.g. by calling a null interface variable or a private non-static method of a null objects). The rest looks good to me. Best regards, Ralf From lance.andersen at oracle.com Fri Sep 20 11:13:38 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 20 Sep 2019 07:13:38 -0400 Subject: RFR [14/java.xml] 8231083: Clarify SAX documentation In-Reply-To: <72ee4560-3989-6ef2-3f90-2dc71668e913@oracle.com> References: <4A513D16-0094-4150-B15B-79B3E21EC903@oracle.com> <72ee4560-3989-6ef2-3f90-2dc71668e913@oracle.com> Message-ID: <085AC6F3-5FC6-474D-AAB6-517700998BC3@oracle.com> Round 2 even looks cleaner :-) > On Sep 20, 2019, at 1:15 AM, Joe Wang > wrote: > > Thanks Lance! > > Yes, saw them typos :-) Also removed the extra space in apiNote. > > Updated webrev below, with removing the text in the javadoc instead of moving to the header. > http://cr.openjdk.java.net/~joehw/jdk14/8231083/webrev/index.html > > -Joe > > On 9/19/19 5:18 PM, Lance Andersen wrote: >> Hi Joe, >> >> Overall this looks good and also cleans up a couple of typos :-) >> >> One nit in both package-info @apiNote, you will notice an extra space before the was which could be removed before you push >> >> Best >> Lance >>> On Sep 19, 2019, at 8:00 PM, Joe Wang > wrote: >>> >>> Please review a follow-up doc clarification patch after 8230814 [1]. In this patch, the statement with a reference to the SAX project is moved to an apiNote in package/sub-package description to reflect the fact that it is a historical note in nature. The license related text that appears in the class description of every SAX class is removed and consolidated with the existing text in the license header. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8231083 >>> webrev: http://cr.openjdk.java.net/~joehw/jdk14/8231083/webrev/index.html >>> >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8230814 >>> >>> 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 >> >> >> > 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 Fri Sep 20 11:57:42 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Fri, 20 Sep 2019 07:57:42 -0400 Subject: RFR: JDK-8231277: Adjust Linux application image layout In-Reply-To: <5f7e9cc8-9698-f7a5-dc1a-3cb3a2ddf30a@oracle.com> References: <5f7e9cc8-9698-f7a5-dc1a-3cb3a2ddf30a@oracle.com> Message-ID: <658dada7-d09e-d49c-b100-fed29db6ab3d@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: - directory layout of Linux app image adjusted to better comply with Linux FSH. - some unused code clean up. - added support to run JUnit4 tests along with the standard jtreg tests. - DeployParamsTest.java jtreg test converted into JUnit test. - unit tests added. Baseline for the fix is http://cr.openjdk.java.net/~asemenyuk/8225249/webrev.02/ patch. [1] https://bugs.openjdk.java.net/browse/JDK-8231277 [2] http://cr.openjdk.java.net/~asemenyuk/8231277/webrev.00/ From Roger.Riggs at oracle.com Fri Sep 20 13:05:24 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 20 Sep 2019 09:05:24 -0400 Subject: RFR: 8231186: Replace html tag foo with javadoc tag {@code foo} in java.base In-Reply-To: References: <733ed056-1606-0c75-feaf-cc3066e4f6eb@oracle.com> <297d817e-b0d9-2814-bb1c-80c6f67a7147@oracle.com> <67c75546-1683-9140-89b7-98f189839843@oracle.com> <454c636e-2c11-a14d-f33f-9d06f3fdae7b@oracle.com> Message-ID: <2464894a-a30b-c6f1-9f4a-d9cd3d79376b@oracle.com> Hi Julia, Did youuse webrev.ksh or the git-webrev available with Skara? If the later, then it can/should be reported and fixed. Roger On 9/20/19 6:22 AM, Julia Boes wrote: > Hi, > > Thanks for noticing the glitch in the sdiffs, Naoto and Brent. I see > that there is indeed an issue with the webrev script and I'm looking > into a workaround. > > The following classes are affected: > > src/java.base/share/classes/java/lang/SecurityManager.java > > src/java.base/share/classes/java/util/Calendar.java > > src/java.base/share/classes/java/util/ResourceBundle.java > > src/java.base/share/classes/java/util/regex/Matcher.java > > >> java/io/InputStream.java: >> >> ?243????? *

The {@code read(b,} {@code off,} {@code len)} method >> >> I believe this can be simplified to: >> >> {@code read(b, off, len)} >> >> -- > > ?? Changed! > > >> Here's something I found examples of in several places, for instance >> in PipedInputStream.java: >> >> ?195????? * @exception IOException If the pipe is >> {@code broken}, >> >> Here we have a link written out in HTML, with {@code} used within the >> displayed text of the link.? This would typically be done instead by >> using a @link tag, as on the next line: >> >> ?196????? *????????? {@link #connect(java.io.PipedOutputStream) >> unconnected}, >> >> Peeking at the generated HTML, AFAICT the @link tag takes care of >> generating the styling in the generated HTML.? I think >> it's worth considering converting these 's to @link, >> either now or as future work. > > ?? Brent, I can make this change but can the @link tag link to a HTML > ?? id? It's not mentioned in the documentation > https://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#link. > > > I expected occurrences of '' would need changes as well, but it > appears there aren't any in java.base (some previous effort cleaned > this up, I guess). > > ??? That's right, there are none in java.base. > > > I recall thinking that many of the should actually be changed > to?@link since use of suggested ancient times before?@link > became available. > But "Perfect is the enemy of good". > > ??? I agree, if that's ok I would leave that as future work ;) > > Regards, > Julia > > > > From Roger.Riggs at oracle.com Fri Sep 20 13:38:22 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 20 Sep 2019 09:38:22 -0400 Subject: JDK 14 RFR of JDK-8199424: consider removing ObjectInputStream and ObjectOutputStream native methods In-Reply-To: <6a80116f-6971-eea7-9ec3-12a19e6f569a@oracle.com> References: <88e88816-f685-7d0d-4fb9-f3304d0ec726@oracle.com> <7FDB4FEA-6CE3-40A5-8A7B-2FF988622E83@oracle.com> <6a80116f-6971-eea7-9ec3-12a19e6f569a@oracle.com> Message-ID: <63842d1f-81e7-ae80-a401-fe1a183fa7f2@oracle.com> Hi Joe, Looks good, thanks for the cleanup. Roger On 9/19/19 11:02 PM, Joe Darcy wrote: > Hi Brian, > > Now including ObjectInputStream changes: > > ???? http://cr.openjdk.java.net/~darcy/8199424.1/ > > Serialization regression tests still all pass. > > Thanks, > > -Joe > > On 9/19/2019 5:19 PM, Brian Burkhalter wrote: >> Hi Joe, >> >> This looks good. Will there be a similar separate patch for >> ObjectInputStream? >> >> Brian >> >>> On Sep 19, 2019, at 3:34 PM, Joe Darcy >> > wrote: >>> >>> As part of my serialization work, I noticed some "to do" notes in >>> ObjectOutputStream.java to get rid of two native methods once the >>> integral <-> floating-point bitwise conversion methods >>> (Float.floatToIntBits, etc.) were intrinsified. That >>> intrinsification occurred many releases back and the recommended >>> cleanup can be done now. Pre-existing bug for this issue: >>> >>> ???? JDK-8199424 : consider removing ObjectInputStream and >>> ObjectOutputStream native methods >>> http://cr.openjdk.java.net/~darcy/8199424.0/ >>> >>> Note the logic controlling for copying the float bytes is the same >>> as the logic for copying the int bytes as both int and float are 4 >>> bytes, same relationship between the copying of double and long bytes. >> From Roger.Riggs at oracle.com Fri Sep 20 13:54:54 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 20 Sep 2019 09:54:54 -0400 Subject: JDK 14 RFR of JDK-8231202: Suppress warnings on non-serializable non-transient instance fields in serializable classes In-Reply-To: <1061082691.2179001.1568925929745.JavaMail.zimbra@u-pem.fr> References: <6d2a410f-acff-f2f7-a9b2-2c2bedaec10e@oracle.com> <0765c19e-e84e-1a20-753e-a9bf505c4054@oracle.com> <1061082691.2179001.1568925929745.JavaMail.zimbra@u-pem.fr> Message-ID: Hi R?mi, On 9/19/19 4:45 PM, Remi Forax wrote: > > Hi Joe, hi Roger, > > these changes are not fine, SerializedLambda is a public class with a public constructor so it's an incompatible change to replace Object[] by Serializable[], > moreover for an array, all values can be Serializable but the array itself can be not Serializable, by example if the array is created as a Object... (varargs). Correct, this change is incompatible; withdrawn. All arrays are Serializable even if the array type does not 'implement Serializable'. But the static type checks can't help with that. > > there are other issues: > - a class can be marked as Serializable but not being serialized at runtime, in that case, it's valid to construct an instance of a Serializable class with an argument which is typed Object instead of Serializable because it will not serialized (basically Serializable means can be serialized and not will be serialized). Right, I would not suggest using a static Serializable type in that case. Generally, I view using Object as a undesirable shortcut. > - using Serializable as type of a field means that if you have an interface you have to introduce a cast somewhere in the code, so you are moving the CCE that comes from writeObject to a CCE in the middle of the user code, i think i prefer the CCE to be issued inside writeObject because at least it's documented. For the java.time.*.Ser suggestions, all of the objects implement Serializable and the Ser class is an implementation artifact only supporting Serialization. With the aid of sealing, the CCE should not need to be a runtime check. > > the real question is what are the pro and cons of Serializable acting as a type instead of only as a marker interface that you can check at runtime, Serializable is a real type and the code better reflects the typing requirements than Object. > or said differently if the serialization was introduced after Java 5, is Serializable still be an interface or be an annotation instead. Regrettable that we didn't understand 20 years ago what we understand today and had all of the language and runtime features available now. Sigh... Thanks, Roger > > R?mi > >> On 9/19/2019 12:13 PM, Roger Riggs wrote: >>> Hi Joe, >>> >>> The addition of @SuppressWarnings(serial) hides a number of instances of >>> poor choices of types.? Before they dissappear behind the suppress >>> warnings, >>> the fix should be to correct the types used. >>> >>> For example, in the serialization proxies for java.time, the Ser class >>> carelessly >>> has a field of type Object when it could/should be using Serializable. >>> The types being serialized and deserialized are known to be Serializable. >>> See the attach patches for details and a suggested fix. >>> >>> Thanks, Roger >>> >>> (p.s. the patch is attached twice, once as .patch and the other .txt. >>> I'd like to see if they both get through the mail). >>> >>> On 9/18/19 5:38 PM, Joe Darcy wrote: >>>> Hello, >>>> >>>> As background, I'm working on a number of serialization-related >>>> compile-time checks with the goal of enabling stricter javac lint >>>> checking in the JDK build (and elsewhere). >>>> >>>> One check is tracked by >>>> >>>> ??? JDK-8160675: Issue lint warning for non-serializable >>>> non-transient instance fields in serializable type >>>> >>>> As summarized in the bug description, it may be concerning if a >>>> serializable class has non-transient instance fields whose types are >>>> not Serializable. This can cause a serialization failure at runtime. >>>> (Classes using the serialPersistentFields mechanism are excluded from >>>> this check.) >>>> >>>> A common example is an exception type -- all Throwable's are >>>> Serializable -- which has a non-serializable field. If the fields >>>> cannot be marked as transient, one approach to handle this robustly >>>> is to have a writeObject method which null outs the field in question >>>> when serializing and make the other methods in the exception >>>> null-tolerant. >>>> >>>> In other cases, the object pointed to by the non-serializable field >>>> are conditionally serializable at runtime. This is the case for many >>>> collection types. For example, a class may have a field of type >>>> List with the field set to an ArrayList at runtime. While >>>> the List interface does not extent Serializable, the ArrayList class >>>> does implement Serializable and the class would serialize fine in >>>> practice, assuming the Foo's were serialazable. >>>> >>>> As a precursor to the adding a compile-time check to the build, >>>> please review adding @SuppressWarnings("serial") to document the >>>> non-serializable fields in the core libraries: >>>> >>>> ??? JDK-8231202: Suppress warnings on non-serializable non-transient >>>> instance fields in serializable classes >>>> http://cr.openjdk.java.net/~darcy/8231202.0/ >>>> >>>> Bugs for similar changes to client libs and security libs will be >>>> filed and reviewed separately. >>>> >>>> A more complete fix would add readObject/writeObject null handling to >>>> AnnotationTypeMismatchExceptionProxy, but since this hasn't seemed to >>>> be an issue since the type was introduced back in JDK 5.0, I just >>>> added the annotation, as done elsewhere. >>>> >>>> Thanks, >>>> >>>> -Joe >>>> From goetz.lindenmaier at sap.com Fri Sep 20 14:39:02 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 20 Sep 2019 14:39:02 +0000 Subject: RFR (L, final): 8218626: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: Message-ID: Hi Ralf, thanks for looking at this code and this thorough review! New webrevs: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/18/ http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/18-incremental/ Find my comments inline: > In javaClasses.cpp: > > > #define CLASS_FIELDS_DO(macro) \ > > macro(classRedefinedCount_offset, k, "classRedefinedCount", int_signature, > false); \ > > macro(_class_loader_offset, k, "classLoader", classloader_signature, > false); \ > > The field name should match the other field names. So > _class_redefined_count_offset instead of classRedefinedCount_offset. That's right. But the field was there before my change, I just removed the spurious space. So I don't feel like changing this. > The method java_lang_Throwable::get_method_and_bci() should be renamed > java_lang_Throwable::get_top_method_and_bci(). Changed. > The usage of java.lang.Boolean(true) as the marker pointer leads to more code > than a simpler, but more hackish solution (e.g. just reusing a reference to the > backtrace array itself). I'm not sure it is really worth it. Considering you in the > end just test for != NULL. I think the design is clearer the way I did it. The Boolean should almost never be allocated. In general, hidden frames should not throw NPEs. > In jvm.cpp: > > The method trim_well_known_class_names() would convert a name like > test.java.lang.String to test.String. I think you have to be more specific when > replacing a name. Ah, you are right. A pity, this was nice and compact. I moved the code into bytecodeUtils.cpp. > In bytecodeUtils.cpp: > > The method get_slotData() should be renamed get_slot_data() in class > SimulatedOperandStack. Done. > The parameter innerExpr should be renamed inner_expr. Done. > In method print_local_var() you could initialize param_index to 1 instead of 0 > and remove adding 1 later. Fixed. > In ExceptionMessageBuilder::ExceptionMessageBuilder you should add spaces > in '(len+1)'. Fixed. > Since the ExceptionMessageBuilder is only used with a bci >= 0, you could > remove the code which handles the case for bci < 0 (where we would create > the simulated stack for every bci). I'd like to leave this as-is, as the code could well analyze the whole method. > In ExceptionMessageBuilder::do_instruction() the dup2 bytecode seems to be > implemented wrongly, since you seemingly push two times the same value. It > isn't, since you change the stack with the push, so in the first push you push > the top of stack - 1 entry, and in the next push the former top of stack. A > comment should be added to make this clearer or change to the code to use > temporary variables. Added comment. > In ExceptionMessageBuilder::do_instruction() the is_wide variable is never > used, so it should be removed. Done. > In ExceptionMessageBuilder::do_instruction() when handling the invoke* > bytecodes, there is the following code: > > if ((code != Bytecodes::_invokestatic) && (code != > Bytecodes::_invokedynamic)) { > // Pop class. > stack->pop(1); > } > > The // Pop class comment is misleading, because the receiver is popped in > reality. Fixed. > In ExceptionMessageBuilder::get_NPE_null_slot() the opening brace for the > invoke* cases should be consistent with the rest of the code. Fixed. > In ExceptionMessageBuilder::get_NPE_null_slot() maybe we should use defines > for -2 and -1 which convey the meaning of that return values. Done. > In ExceptionMessageBuilder::print_NPE_failed_action() you assert that the > method holder is not the NativeConstructorAccessorImpl, noting that this > should already have been checked In get_NPE_null_slot(). But I don't see any > code in that message which would check this, it seemed to be check in > BytecodeUtils::get_NPE_message_at() instead. I moved that code up when I reviewed my own code. It seems better placed here, as also the check for NPE_EXPLICIT_CONSTRUCTED is here. I removed the assertion. > In NullPointerExceptionTest.java: > > It seems you don't have tests for invokeinterface or invokespecial calls to cause > an NPE (e.g. by calling a null interface variable or a private non-static method > of a null objects). That is because the code is the same as for invokevirtual in all places in bytecodeUtils.cpp. Thanks and best regards, Goetz. From milan.mimica at gmail.com Fri Sep 20 14:42:31 2019 From: milan.mimica at gmail.com (Milan Mimica) Date: Fri, 20 Sep 2019 16:42:31 +0200 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: <81087256-819E-49FF-BB94-ADA9530717DD@oracle.com> References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> <87sgpblxns.fsf@oldenburg2.str.redhat.com> <7A46485C-E250-4E57-9FB0-B9D18CA70632@oracle.com> <60FD933F-51A5-4438-83AF-B3427CFDE60D@oracle.com> <8A9E3066-E6F6-4E65-BD02-DF0ACFF02FAD@oracle.com> <633A0CE3-C771-493B-89E3-7FA843C85183@oracle.com> <6b209e36-686f-7852-7fb8-3a0ef0e8423a@oracle.com> <4CAC6E8D-9198-4701-99C0-49901D72A396@oracle.com> <47acbb78-806f-2951-3b22-de6e7965f461@oracle.com> <275EC96C-CC39-41C8-9B9C-B917F25FAB70@oracle.com> <7D4375A7-E2CC-4297-92DF-A13FC9EF07AE@oracle.com> <81087256-819E-49FF-BB94-ADA9530717DD@oracle.com> Message-ID: Pavel, Here it is: http://cr.openjdk.java.net/~mmimica/8228580/webrev.04/ I don't see the test is run twice when I execute "make test TEST=jtreg:test/jdk/com/sun/jndi/dns/ConfigTests/TcpTimeout.java". Am I missing something? On Thu, 19 Sep 2019 at 13:16, Pavel Rappo wrote: > > Milan, > > This looks like a good start. Please consider > > 1. Setting TOLERANCE to 5 seconds > 2. Getting the second time mark immediately after the query returns (i.e. do not waste your time in DNSTestUtils.debug(attrs)) > 3. Making the test parametric instead of hardcoded for the DEFAULT_DNS_CLIENT_TIMEOUT > 4. Running the test for at least 2 different values of the timeout, e.g.: > > * @run main TcpTimeout > * @run main TcpTimeout -Dcom.sun.jndi.dns.timeout.initial=5000 > > As for you question, I'm not sure how we would be able to communicate the fact that the response is truncated to the user. You could try to ask this on the net-dev mailing list. > > -Pavel > > > On 18 Sep 2019, at 14:25, Milan Mimica wrote: > > > > Hi Pavel > > > > Sure. Here is the incremental change: > > http://cr.openjdk.java.net/~mmimica/8228580/webrev.03/ > > > > What actually bothers me from the beginning is the truncated response. > > The TXT attribute, a String, prints "A very popular h", but does not > > equals("A very popular h"), because of some stray bytes. I guess it's > > because of how DNS response parsing works. I can imagine how this > > could cause problems to users. I think, at least, we should have a way > > to tell the user that the response is truncated, and the payload is > > partial/invalid. > > > > > > On Tue, 17 Sep 2019 at 15:09, Pavel Rappo wrote: > >> > >> Milan, > >> > >> While the CSR is being processed, could we maybe think of some additional testing for that change? Otherwise, that test seems kind of anemic. It makes sure that the query doesn't hang, but that's about it. It doesn't check that the timeout is respected. I was wondering if you could propose some way of testing that. > >> > >>> On 17 Sep 2019, at 09:55, Pavel Rappo wrote: > >>> > >>> I have filed the CSR: > >>> > >>> https://bugs.openjdk.java.net/browse/JDK-8230965 > >>> > >>>> On 13 Sep 2019, at 11:21, Pavel Rappo wrote: > >>>> > >>>> Here's the latest webrev accumulating all the changes we've discussed so far: > >>>> > >>>> http://cr.openjdk.java.net/~prappo/8228580/webrev.03/ > >>>> > >>>> If people are okay with that I will proceed to creating a CSR. > >> > > > > > > -- > > Milan Mimica > -- Milan Mimica From brian.burkhalter at oracle.com Fri Sep 20 14:58:27 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 20 Sep 2019 07:58:27 -0700 Subject: JDK 14 RFR of JDK-8199424: consider removing ObjectInputStream and ObjectOutputStream native methods In-Reply-To: <63842d1f-81e7-ae80-a401-fe1a183fa7f2@oracle.com> References: <88e88816-f685-7d0d-4fb9-f3304d0ec726@oracle.com> <7FDB4FEA-6CE3-40A5-8A7B-2FF988622E83@oracle.com> <6a80116f-6971-eea7-9ec3-12a19e6f569a@oracle.com> <63842d1f-81e7-ae80-a401-fe1a183fa7f2@oracle.com> Message-ID: <61D7FBC6-CC1B-446C-964C-B4D57D9C4BB9@oracle.com> +1 Brian > On Sep 20, 2019, at 6:38 AM, Roger Riggs wrote: > > Looks good, thanks for the cleanup. > > Roger > > > On 9/19/19 11:02 PM, Joe Darcy wrote: >> Hi Brian, >> >> Now including ObjectInputStream changes: >> >> http://cr.openjdk.java.net/~darcy/8199424.1/ >> >> Serialization regression tests still all pass. From julia.boes at oracle.com Fri Sep 20 15:42:41 2019 From: julia.boes at oracle.com (Julia Boes) Date: Fri, 20 Sep 2019 16:42:41 +0100 Subject: RFR: 8231186: Replace html tag foo with javadoc tag {@code foo} in java.base In-Reply-To: <2464894a-a30b-c6f1-9f4a-d9cd3d79376b@oracle.com> References: <733ed056-1606-0c75-feaf-cc3066e4f6eb@oracle.com> <297d817e-b0d9-2814-bb1c-80c6f67a7147@oracle.com> <67c75546-1683-9140-89b7-98f189839843@oracle.com> <454c636e-2c11-a14d-f33f-9d06f3fdae7b@oracle.com> <2464894a-a30b-c6f1-9f4a-d9cd3d79376b@oracle.com> Message-ID: <47250fc9-c6b0-3ac6-4955-c059424d0d6c@oracle.com> Hi Roger, I ran webrev.ksh. The issue is reported here: https://bugs.openjdk.java.net/browse/CODETOOLS-7902519 (knowing that it's not a priority with git-webrev on the horizon). Regards, Julia On 20/09/2019 14:05, Roger Riggs wrote: > Hi Julia, > > Did youuse webrev.ksh or the git-webrev available with Skara? > If the later, then it can/should be reported and fixed. > > Roger > > > On 9/20/19 6:22 AM, Julia Boes wrote: >> Hi, >> >> Thanks for noticing the glitch in the sdiffs, Naoto and Brent. I see >> that there is indeed an issue with the webrev script and I'm looking >> into a workaround. >> >> The following classes are affected: >> >> src/java.base/share/classes/java/lang/SecurityManager.java >> >> src/java.base/share/classes/java/util/Calendar.java >> >> src/java.base/share/classes/java/util/ResourceBundle.java >> >> src/java.base/share/classes/java/util/regex/Matcher.java >> >> >>> java/io/InputStream.java: >>> >>> ?243????? *

The {@code read(b,} {@code off,} {@code len)} method >>> >>> I believe this can be simplified to: >>> >>> {@code read(b, off, len)} >>> >>> -- >> >> ?? Changed! >> >> >>> Here's something I found examples of in several places, for instance >>> in PipedInputStream.java: >>> >>> ?195????? * @exception IOException If the pipe is >>> {@code broken}, >>> >>> Here we have a link written out in HTML, with {@code} used within >>> the displayed text of the link.? This would typically be done >>> instead by using a @link tag, as on the next line: >>> >>> ?196????? *????????? {@link #connect(java.io.PipedOutputStream) >>> unconnected}, >>> >>> Peeking at the generated HTML, AFAICT the @link tag takes care of >>> generating the styling in the generated HTML.? I think >>> it's worth considering converting these 's to @link, >>> either now or as future work. >> >> ?? Brent, I can make this change but can the @link tag link to a HTML >> ?? id? It's not mentioned in the documentation >> https://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#link. >> >> >> >> I expected occurrences of '' would need changes as well, but it >> appears there aren't any in java.base (some previous effort cleaned >> this up, I guess). >> >> ??? That's right, there are none in java.base. >> >> >> I recall thinking that many of the should actually be changed >> to?@link since use of suggested ancient times before?@link >> became available. >> But "Perfect is the enemy of good". >> >> ??? I agree, if that's ok I would leave that as future work ;) >> >> Regards, >> Julia >> >> >> >> > From huizhe.wang at oracle.com Fri Sep 20 16:05:58 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 20 Sep 2019 09:05:58 -0700 Subject: RFR [14/java.xml] 8231083: Clarify SAX documentation In-Reply-To: <085AC6F3-5FC6-474D-AAB6-517700998BC3@oracle.com> References: <4A513D16-0094-4150-B15B-79B3E21EC903@oracle.com> <72ee4560-3989-6ef2-3f90-2dc71668e913@oracle.com> <085AC6F3-5FC6-474D-AAB6-517700998BC3@oracle.com> Message-ID: Thanks Lance!? It's a cleanup on top of cleanup :-) On 9/20/19 4:13 AM, Lance Andersen wrote: > Round 2 ?even looks cleaner :-) > > >> On Sep 20, 2019, at 1:15 AM, Joe Wang > > wrote: >> >> Thanks Lance! >> >> Yes, saw them typos :-)? Also removed the extra space in apiNote. >> >> Updated webrev below, with removing the text in the javadoc instead >> of moving to the header. >> http://cr.openjdk.java.net/~joehw/jdk14/8231083/webrev/index.html >> >> -Joe >> >> On 9/19/19 5:18 PM, Lance Andersen wrote: >>> Hi Joe, >>> >>> Overall this looks good and also cleans up a couple of typos :-) >>> >>> One nit in both package-info @apiNote, you will notice an extra >>> space before the was which could be removed before you push >>> >>> Best >>> Lance >>>> On Sep 19, 2019, at 8:00 PM, Joe Wang >>> > wrote: >>>> >>>> Please review a follow-up doc clarification patch after 8230814 >>>> [1]. In this patch, the statement with a reference to the SAX >>>> project is moved to an apiNote in package/sub-package description >>>> to reflect the fact that it is a historical note in nature. The >>>> license related text that appears in the class description of every >>>> SAX class is removed and consolidated with the existing text in the >>>> license header. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8231083 >>>> webrev: >>>> http://cr.openjdk.java.net/~joehw/jdk14/8231083/webrev/index.html >>>> >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8230814 >>>> >>>> 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 >>> >>> >>> >> > > > > 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 Fri Sep 20 16:07:17 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 Sep 2019 17:07:17 +0100 Subject: RFR [14/java.xml] 8231083: Clarify SAX documentation In-Reply-To: <72ee4560-3989-6ef2-3f90-2dc71668e913@oracle.com> References: <4A513D16-0094-4150-B15B-79B3E21EC903@oracle.com> <72ee4560-3989-6ef2-3f90-2dc71668e913@oracle.com> Message-ID: <1cf4807a-a329-78f6-54b9-12547489be50@oracle.com> On 20/09/2019 06:15, Joe Wang wrote: > Thanks Lance! > > Yes, saw them typos :-)? Also removed the extra space in apiNote. > > Updated webrev below, with removing the text in the javadoc instead of > moving to the header. > http://cr.openjdk.java.net/~joehw/jdk14/8231083/webrev/index.html Just a minor comment on the @apiNote where it reads "was introduced in Java SE 1.4 and continues to be maintained as part of Java SE". It might be simpler to just say that "has been defined by Java SE since 1.4" and leave out any mention of being maintained. -Alan. From huizhe.wang at oracle.com Fri Sep 20 16:46:39 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 20 Sep 2019 09:46:39 -0700 Subject: RFR [14/java.xml] 8231083: Clarify SAX documentation In-Reply-To: <1cf4807a-a329-78f6-54b9-12547489be50@oracle.com> References: <4A513D16-0094-4150-B15B-79B3E21EC903@oracle.com> <72ee4560-3989-6ef2-3f90-2dc71668e913@oracle.com> <1cf4807a-a329-78f6-54b9-12547489be50@oracle.com> Message-ID: <7ef1ddad-d7d2-79e4-2fd9-b2771a654195@oracle.com> Thanks Alan! Here's the updated webrev after changing the apiNote as you suggested: http://cr.openjdk.java.net/~joehw/jdk14/8231083/webrev02/index.html -Joe On 9/20/19 9:07 AM, Alan Bateman wrote: > On 20/09/2019 06:15, Joe Wang wrote: >> Thanks Lance! >> >> Yes, saw them typos :-)? Also removed the extra space in apiNote. >> >> Updated webrev below, with removing the text in the javadoc instead >> of moving to the header. >> http://cr.openjdk.java.net/~joehw/jdk14/8231083/webrev/index.html > Just a minor comment on the @apiNote where it reads "was introduced in > Java SE 1.4 and continues to be maintained as part of Java SE". It > might be simpler to just say that "has been defined by Java SE since > 1.4" and leave out any mention of being maintained. > > -Alan. From Alan.Bateman at oracle.com Fri Sep 20 17:03:27 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 Sep 2019 18:03:27 +0100 Subject: RFR [14/java.xml] 8231083: Clarify SAX documentation In-Reply-To: <7ef1ddad-d7d2-79e4-2fd9-b2771a654195@oracle.com> References: <4A513D16-0094-4150-B15B-79B3E21EC903@oracle.com> <72ee4560-3989-6ef2-3f90-2dc71668e913@oracle.com> <1cf4807a-a329-78f6-54b9-12547489be50@oracle.com> <7ef1ddad-d7d2-79e4-2fd9-b2771a654195@oracle.com> Message-ID: On 20/09/2019 17:46, Joe Wang wrote: > Thanks Alan! > > Here's the updated webrev after changing the apiNote as you suggested: > http://cr.openjdk.java.net/~joehw/jdk14/8231083/webrev02/index.html Looks good. From huizhe.wang at oracle.com Fri Sep 20 17:43:06 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 20 Sep 2019 10:43:06 -0700 Subject: RFR [14/java.xml] 8231083: Clarify SAX documentation In-Reply-To: References: <4A513D16-0094-4150-B15B-79B3E21EC903@oracle.com> <72ee4560-3989-6ef2-3f90-2dc71668e913@oracle.com> <1cf4807a-a329-78f6-54b9-12547489be50@oracle.com> <7ef1ddad-d7d2-79e4-2fd9-b2771a654195@oracle.com> Message-ID: Thanks Alan! Joe On 9/20/19 10:03 AM, Alan Bateman wrote: > > > On 20/09/2019 17:46, Joe Wang wrote: >> Thanks Alan! >> >> Here's the updated webrev after changing the apiNote as you suggested: >> http://cr.openjdk.java.net/~joehw/jdk14/8231083/webrev02/index.html > Looks good. From Roger.Riggs at oracle.com Fri Sep 20 18:51:45 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 20 Sep 2019 14:51:45 -0400 Subject: RFR 8231314: java.time serialization warning cleanup Message-ID: <5c9f0062-1036-d638-1940-3d4974b05bc4@oracle.com> Please review code cleanup that will remove the need to suppress soon to be introduced warnings [1] about static typing of serialization related fields. A few of the implementation Ser classes that serialize java.time types are affected. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-warn-serializable-8231314/ Thanks, Roger [1] https://bugs.openjdk.java.net/browse/JDK-8231202 From naoto.sato at oracle.com Fri Sep 20 20:25:38 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 20 Sep 2019 13:25:38 -0700 Subject: CharsetEncoder.maxBytesPerChar() Message-ID: <07109047-3a9b-c784-4fa8-86616a3bc263@oracle.com> Hello, I am looking at the following bug: https://bugs.openjdk.java.net/browse/JDK-8230531 and hoping someone who is familiar with the encoder will clear things out. As in the bug report, the method description reads: -- Returns the maximum number of bytes that will be produced for each character of input. This value may be used to compute the worst-case size of the output buffer required for a given input sequence. -- Initially I thought it would return the maximum number of encoded bytes for an arbitrary input "char" value, i.e. a code unit of UTF-16 encoding. For example, any UTF-16 Charset (UTF-16, UTF-16BE, and UTF-16LE) would return 2 from the method, as the code unit is a 16 bit value. In reality, the encoder of UTF-16 Charset returns 4, which accounts for the initial byte-order mark (2 bytes for a code unit, plus size of the BOM). This is justifiable because it is meant to be the worst case scenario, though. I believe this implementation has been there since the inception of java.nio, i.e., JDK1.4. Obviously I can clarify the spec of maxBytesPerChar() to account for the conversion independent prefix (or suffix) bytes, such as BOM, but I am not sure the initial intent of the method. If it intends to return pure max bytes for a single input char, UTF-16 should also have been returning 2. But in that case, caller would not be able to calculate the worst case byte buffer size as in the bug report. Naoto From brent.christian at oracle.com Fri Sep 20 21:02:48 2019 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 20 Sep 2019 14:02:48 -0700 Subject: RFR: 8231186: Replace html tag foo with javadoc tag {@code foo} in java.base In-Reply-To: References: <733ed056-1606-0c75-feaf-cc3066e4f6eb@oracle.com> <297d817e-b0d9-2814-bb1c-80c6f67a7147@oracle.com> <67c75546-1683-9140-89b7-98f189839843@oracle.com> <454c636e-2c11-a14d-f33f-9d06f3fdae7b@oracle.com> Message-ID: <5631697e-2f7d-2d29-3606-1822a4141ba8@oracle.com> Hi, Julia On 9/20/19 3:22 AM, Julia Boes wrote: > Hi, > > Thanks for noticing the glitch in the sdiffs, Naoto and Brent. I see > that there is indeed an issue with the webrev script and I'm looking > into a workaround. > > The following classes are affected: > > src/java.base/share/classes/java/lang/SecurityManager.java > src/java.base/share/classes/java/util/Calendar.java The Udiffs for these look fine. > src/java.base/share/classes/java/util/ResourceBundle.java I believe the tag spanning L2801-2 can be changed: 2801 *

  • Special cases for Norwegian. Both Locale("no", "NO", 2802 * "NY") and {@code Locale("nn", "NO")} represent Norwegian Same at L2818-9: 2818 * Bokm?l "nb". Except for the single case Locale("no", 2819 * "NO", "NY") (handled above), when an input {@code Locale} > src/java.base/share/classes/java/util/regex/Matcher.java All I see in this file is the final closing brace being replaced with a closing brace :D >> in PipedInputStream.java: >> >> ?195????? * @exception IOException If the pipe is >> {@code broken}, >> >> Here we have a link written out in HTML, with {@code} used within the >> displayed text of the link.? This would typically be done instead by >> using a @link tag, as on the next line: >> >> ?196????? *????????? {@link #connect(java.io.PipedOutputStream) >> unconnected}, >> > > ?? Brent, I can make this change but can the @link tag link to a HTML > ?? id? It's not mentioned in the documentation > > https://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#link. Oh, I see now - #BROKEN is a hand-coded HTML anchor, not a field name. Hmm... > I recall thinking that many of the should actually be changed > to?@link since use of suggested ancient times before?@link became > available. > But "Perfect is the enemy of good". Indeed. > ??? I agree, if that's ok I would leave that as future work ;) Definitely OK. Those may even already be "correct", and not suitable uses of @link at all. Thanks, -Brent From naoto.sato at oracle.com Fri Sep 20 21:03:56 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 20 Sep 2019 14:03:56 -0700 Subject: RFR 8231314: java.time serialization warning cleanup In-Reply-To: <5c9f0062-1036-d638-1940-3d4974b05bc4@oracle.com> References: <5c9f0062-1036-d638-1940-3d4974b05bc4@oracle.com> Message-ID: Hi Roger, Looks good to me. There are some removed "@SuppressWarnings("serial")" which don't exist in the current JDK14 code base, e.g., line 115 of java/time/Ser.java, but I assumed they can be safely ignored. Naoto On 9/20/19 11:51 AM, Roger Riggs wrote: > Please review code cleanup that will remove the need to suppress soon to > be introduced > warnings [1] about static typing of serialization related fields. > A few of the implementation Ser classes that serialize java.time types > are affected. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-warn-serializable-8231314/ > > Thanks, Roger > > [1] https://bugs.openjdk.java.net/browse/JDK-8231202 > > From alexander.matveev at oracle.com Fri Sep 20 21:41:18 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Fri, 20 Sep 2019 14:41:18 -0700 Subject: RFR: JDK-8231277: Adjust Linux application image layout In-Reply-To: <658dada7-d09e-d49c-b100-fed29db6ab3d@oracle.com> References: <5f7e9cc8-9698-f7a5-dc1a-3cb3a2ddf30a@oracle.com> <658dada7-d09e-d49c-b100-fed29db6ab3d@oracle.com> Message-ID: Looks good. On 9/20/2019 4:57 AM, 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). > > This fix: > > - directory layout of Linux app image adjusted to better comply with > Linux FSH. > - some unused code clean up. > - added support to run JUnit4 tests along with the standard jtreg tests. > - DeployParamsTest.java jtreg test converted into JUnit test. > - unit tests added. > > Baseline for the fix is > http://cr.openjdk.java.net/~asemenyuk/8225249/webrev.02/ patch. > > [1] https://bugs.openjdk.java.net/browse/JDK-8231277 > > [2] http://cr.openjdk.java.net/~asemenyuk/8231277/webrev.00/ > From joe.darcy at oracle.com Fri Sep 20 21:40:25 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 20 Sep 2019 14:40:25 -0700 Subject: RFR 8231314: java.time serialization warning cleanup In-Reply-To: References: <5c9f0062-1036-d638-1940-3d4974b05bc4@oracle.com> Message-ID: Hello, Looks fine to me too. As Naoto observed, the patch is on top of a changeset with annotations I haven't pushed yet; I think it would be fine if this changeset were pushed first and I'll adjust mine accordingly. Thanks, -Joe On 9/20/2019 2:03 PM, naoto.sato at oracle.com wrote: > Hi Roger, > > Looks good to me. > > There are some removed "@SuppressWarnings("serial")" which don't exist > in the current JDK14 code base, e.g., line 115 of java/time/Ser.java, > but I assumed they can be safely ignored. > > Naoto > > On 9/20/19 11:51 AM, Roger Riggs wrote: >> Please review code cleanup that will remove the need to suppress soon >> to be introduced >> warnings [1] about static typing of serialization related fields. >> A few of the implementation Ser classes that serialize java.time >> types are affected. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-warn-serializable-8231314/ >> >> Thanks, Roger >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8231202 >> >> From alexander.matveev at oracle.com Fri Sep 20 21:54:16 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Fri, 20 Sep 2019 14:54:16 -0700 Subject: RFR: JDK-8230651: Use version string from main module 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). - Version from main module (if exist) will be used as --app-version if --app-version is not specified. [1] https://bugs.openjdk.java.net/browse/JDK-8230651 [2] http://cr.openjdk.java.net/~almatvee/8230651/webrev.01/ Thanks, Alexander From brent.christian at oracle.com Fri Sep 20 21:57:50 2019 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 20 Sep 2019 14:57:50 -0700 Subject: RFR 8221623 : Add StackWalker micro benchmarks to jdk repo In-Reply-To: <32fb594c-1d27-552c-1c9f-b8667db2f85d@oracle.com> References: <32fb594c-1d27-552c-1c9f-b8667db2f85d@oracle.com> Message-ID: <8da432ed-ee0f-7613-cd7f-39ce8006230c@oracle.com> Hi, Claes On 9/19/19 1:40 PM, Claes Redestad wrote: > > FYI, you can control the number of forks etc run by make test: > > make test TEST="micro:java.lang.StackWalkBench" > MICRO="FORK=1;WARMUP_ITER=2;OPTIONS=-p depth=128" > > (documented in doc/testing.md|html) Neat, thanks! > Still, I agree it might be a good idea to have make test TEST=... run > fewer forks/iterations by default, since this shortcut was primarily > intended as a means for devs to quickly verify specific microbenchmarks. OK, I've submitted: https://bugs.openjdk.java.net/browse/JDK-8231315 > However, reducing forks and iterations only cuts down one factor of the > total runtime: others being the number of methods and the number of > chosen parameters (as controlled by @Param-annotated fields). > > So IMHO, what should be thought through carefully when adding micros is > whether all methods are necessary or at least useful and whether we can > reduce the number of parameter chosen. > > For these two, I think picking 2 or 3 values for depth (lowest, highest, > maybe a midpoint) might be sufficient. This would cut total runtime > budget by 60% or 40%, respectively. Mandy makes a good point that configurations would be different between doing a quick performance verification/sanity check, versus a more comprehensive run to measure tuning work or larger scale work. In the interest of reducing the run time when using 'make', I'd be OK with having fewer values in the 'depth' @Param in the source. It's easy enough to add values back from the commandline for more thorough testing. (In the case of StackWalker, it's good to exercise its various batch sizes.) Thanks, -Brent P.S. As you alluded to, there is also a "quick-and-efficient versus thorough coverage" tension WRT what @Benchmark methods get included/run. Worth giving thought to sometime... > On 2019-09-19 20:09, Brent Christian wrote: >> Hi, Mandy >> >> Yes, that 'make' job would take ~7 hours on my machine. >> I believe this is typical for running micros using 'make'.? AFAICT, >> the jmh defaults are used, so it forks (running all the warmups + >> iterations) 5 times.? Trying another (>100 loc) benchmark? at random, >> the java.lang.ArrayCopy one would take 25 hours. >> >> There might be a way to pass jmh args (e.g. '-f 1') via 'make test >> TEST=...', though I really only ever run benchmarks using 'java -jar >> path/to/benchmark.jar'. >> >> It may be worth looking into updating the make target to setup more >> practical JMH runtimes by default.? But I don't think this an issue >> particular the new benchmarks. >> >> Thanks, >> -Brent >> On 9/18/19 7:33 PM, Mandy Chung wrote: >>> Hi Brent, >>> >>> $ make test TEST="micro:java.lang.StackWalkBench" >>> >>> It took very long that I killed the job.? Does this happen to you? >>> >>> Mandy >>> >>> On 9/13/19 3:07 PM, Brent Christian wrote: >>>> Hi, >>>> >>>> Please review these StackWalker and Throwable benchmarks for >>>> addition into the JDK microbenchmarks. >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8221623 >>>> Webrev: >>>> http://cr.openjdk.java.net/~bchristi/8221623/webrev07/ >>>> >>>> The StackWalker benchmarks use StackWalker's forEach(), walk(), and >>>> Options to measure retrieval of various types of information from >>>> the call stack. >>>> >>>> The Throwable benchmarks do corresponding exercises; there are also >>>> a couple of Logging benchmarks. >>>> >>>> A JMH @Param is used to test a variety of call stack depths. >>>> >>>> >>>> In the future, we might consider a benchmark for >>>> Reflection.getCallerClass().? (It is more involved today to >>>> benchmark that method than at the time these benchmarks were >>>> originally written, so that one's commented out.) See JDK-8230976. >>>> >>>> Thanks, >>>> -Brent >>>> >>>> 1. https://bugs.openjdk.java.net/browse/JDK-8230976 >>> >> From mark.reinhold at oracle.com Fri Sep 20 22:03:39 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 20 Sep 2019 15:03:39 -0700 Subject: CharsetEncoder.maxBytesPerChar() In-Reply-To: <07109047-3a9b-c784-4fa8-86616a3bc263@oracle.com> References: <07109047-3a9b-c784-4fa8-86616a3bc263@oracle.com> Message-ID: <20190920150339.254128936@eggemoggin.niobe.net> 2019/9/20 13:25:38 -0700, naoto.sato at oracle.com: > I am looking at the following bug: > > https://bugs.openjdk.java.net/browse/JDK-8230531 > > and hoping someone who is familiar with the encoder will clear things > out. As in the bug report, the method description reads: > > -- > Returns the maximum number of bytes that will be produced for each > character of input. This value may be used to compute the worst-case > size of the output buffer required for a given input sequence. > -- > > Initially I thought it would return the maximum number of encoded bytes > for an arbitrary input "char" value, i.e. a code unit of UTF-16 > encoding. For example, any UTF-16 Charset (UTF-16, UTF-16BE, and > UTF-16LE) would return 2 from the method, as the code unit is a 16 bit > value. In reality, the encoder of UTF-16 Charset returns 4, which > accounts for the initial byte-order mark (2 bytes for a code unit, plus > size of the BOM). Exactly. A comment in the implementation, in sun.nio.cs.UnicodeEncoder, mentions this (perhaps you already saw it): protected UnicodeEncoder(Charset cs, int bo, boolean m) { super(cs, 2.0f, * // Four bytes max if you need a BOM * m ? 4.0f : 2.0f, // Replacement depends upon byte order ((bo == BIG) ? new byte[] { (byte)0xff, (byte)0xfd } : new byte[] { (byte)0xfd, (byte)0xff })); usesMark = needsMark = m; byteOrder = bo; } > This is justifiable because it is meant to be the > worst case scenario, though. I believe this implementation has been > there since the inception of java.nio, i.e., JDK 1.4. Yes, it has. > Obviously I can clarify the spec of maxBytesPerChar() to account for the > conversion independent prefix (or suffix) bytes, such as BOM, but I am > not sure the initial intent of the method. If it intends to return pure > max bytes for a single input char, UTF-16 should also have been > returning 2. But in that case, caller would not be able to calculate the > worst case byte buffer size as in the bug report. The original intent is that the return value of this method can be used to allocate a buffer that is guaranteed to be large enough for any possible output. Returning 2 for UTF-16 would, as you observe, not work for that purpose. To avoid this confusion, a more verbose specification might read: * Returns the maximum number of $otype$s that will be produced for each * $itype$ of input. This value may be used to compute the worst-case size * of the output buffer required for a given input sequence. This value * accounts for any necessary content-independent prefix or suffix #if[encoder] * $otype$s, such as byte-order marks. #end[encoder] #if[decoder] * $otype$s. #end[decoder] (The example of byte-order marks applies only to CharsetEncoders, so I?ve conditionalized that text for Charset-X-Coder.java.template.) - Mark From alexey.semenyuk at oracle.com Fri Sep 20 22:14:44 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Fri, 20 Sep 2019 18:14:44 -0400 Subject: RFR: JDK-8230651: Use version string from main module In-Reply-To: References: Message-ID: Looks good. Unfortunately the new test helper classes don't support --module option yet and the test can not be implemented based on them. - Alexey On 9/20/2019 5:54 PM, Alexander Matveev wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > - Version from main module (if exist) will be used as --app-version if > --app-version is not specified. > > [1] https://bugs.openjdk.java.net/browse/JDK-8230651 > > [2] http://cr.openjdk.java.net/~almatvee/8230651/webrev.01/ > > Thanks, > Alexander From naoto.sato at oracle.com Fri Sep 20 22:18:58 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 20 Sep 2019 15:18:58 -0700 Subject: CharsetEncoder.maxBytesPerChar() In-Reply-To: <20190920150339.254128936@eggemoggin.niobe.net> References: <07109047-3a9b-c784-4fa8-86616a3bc263@oracle.com> <20190920150339.254128936@eggemoggin.niobe.net> Message-ID: Hi Mark, Thank you for the crystal clear explanation. I will go ahead and clarify the method description. Naoto On 9/20/19 3:03 PM, mark.reinhold at oracle.com wrote: > 2019/9/20 13:25:38 -0700, naoto.sato at oracle.com: >> I am looking at the following bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8230531 >> >> and hoping someone who is familiar with the encoder will clear things >> out. As in the bug report, the method description reads: >> >> -- >> Returns the maximum number of bytes that will be produced for each >> character of input. This value may be used to compute the worst-case >> size of the output buffer required for a given input sequence. >> -- >> >> Initially I thought it would return the maximum number of encoded bytes >> for an arbitrary input "char" value, i.e. a code unit of UTF-16 >> encoding. For example, any UTF-16 Charset (UTF-16, UTF-16BE, and >> UTF-16LE) would return 2 from the method, as the code unit is a 16 bit >> value. In reality, the encoder of UTF-16 Charset returns 4, which >> accounts for the initial byte-order mark (2 bytes for a code unit, plus >> size of the BOM). > > Exactly. A comment in the implementation, in sun.nio.cs.UnicodeEncoder, > mentions this (perhaps you already saw it): > > protected UnicodeEncoder(Charset cs, int bo, boolean m) { > super(cs, 2.0f, > * // Four bytes max if you need a BOM > * m ? 4.0f : 2.0f, > // Replacement depends upon byte order > ((bo == BIG) > ? new byte[] { (byte)0xff, (byte)0xfd } > : new byte[] { (byte)0xfd, (byte)0xff })); > usesMark = needsMark = m; > byteOrder = bo; > } > >> This is justifiable because it is meant to be the >> worst case scenario, though. I believe this implementation has been >> there since the inception of java.nio, i.e., JDK 1.4. > > Yes, it has. > >> Obviously I can clarify the spec of maxBytesPerChar() to account for the >> conversion independent prefix (or suffix) bytes, such as BOM, but I am >> not sure the initial intent of the method. If it intends to return pure >> max bytes for a single input char, UTF-16 should also have been >> returning 2. But in that case, caller would not be able to calculate the >> worst case byte buffer size as in the bug report. > > The original intent is that the return value of this method can be used > to allocate a buffer that is guaranteed to be large enough for any > possible output. Returning 2 for UTF-16 would, as you observe, not work > for that purpose. > > To avoid this confusion, a more verbose specification might read: > > * Returns the maximum number of $otype$s that will be produced for each > * $itype$ of input. This value may be used to compute the worst-case size > * of the output buffer required for a given input sequence. This value > * accounts for any necessary content-independent prefix or suffix > #if[encoder] > * $otype$s, such as byte-order marks. > #end[encoder] > #if[decoder] > * $otype$s. > #end[decoder] > > (The example of byte-order marks applies only to CharsetEncoders, so > I?ve conditionalized that text for Charset-X-Coder.java.template.) > > - Mark > From chris.hegarty at oracle.com Sat Sep 21 10:31:11 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 21 Sep 2019 11:31:11 +0100 Subject: RFR 8231314: java.time serialization warning cleanup In-Reply-To: <5c9f0062-1036-d638-1940-3d4974b05bc4@oracle.com> References: <5c9f0062-1036-d638-1940-3d4974b05bc4@oracle.com> Message-ID: <42910678-6051-44E9-AB89-0318A1100684@oracle.com> Roger, > On 20 Sep 2019, at 19:51, Roger Riggs wrote: > > Please review code cleanup that will remove the need to suppress soon to be introduced > warnings [1] about static typing of serialization related fields. > A few of the implementation Ser classes that serialize java.time types are affected. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-warn-serializable-8231314/ I think the change is fine, just a few comments.. - AbstractChronology is not necessarily is not always Serializable, but writeReplace expects that it is. Since this is a package-private method, then I assume that it will only ever be called by Serializable subtypes or the serialization framework itself. - time/chrono/Ser.java : it?s kinda awkward to have to cast the return of readExternal, especially since the set of types is locked down, but without these readExternal methods returning xxxImpl types there is little choice. -Chris. From matthias.baesken at sap.com Mon Sep 23 07:06:54 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 23 Sep 2019 07:06:54 +0000 Subject: [RFR] 8231171: remove remaining sun.java.launcher.pid references - was RE: sun.java.launcher.pid property usage In-Reply-To: <173137cf-2fbd-1d5a-17d2-a2d42265f688@oracle.com> References: <3db7390f-36df-d304-3188-d11e35a673ab@oracle.com> <765279b9-1b60-88ad-8548-3f5cf1b19f28@oracle.com> <173137cf-2fbd-1d5a-17d2-a2d42265f688@oracle.com> Message-ID: Thanks for the review ! Alan, may I add you as reviewer too ? Best regards, Matthias > -----Original Message----- > From: David Holmes > Sent: Freitag, 20. September 2019 11:41 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' ; core-libs- > dev at openjdk.java.net > Cc: Alan Bateman > Subject: Re: [RFR] 8231171: remove remaining sun.java.launcher.pid > references - was RE: sun.java.launcher.pid property usage > > That looks fine to me. > > Thanks, > David > > On 20/09/2019 7:14 pm, Baesken, Matthias wrote: > > Hi David , I adjusted the test ( > test/jdk/tools/launcher/TestSpecialArgs.java ) and removed the comments > in os_bsd.cpp (suggested by you) . > > New webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8231171.1/ > > > > Best regards, Matthias > > > > > > > > > >> Hi Matthias, > >> > >> On 20/09/2019 5:03 pm, Baesken, Matthias wrote: > >>> > >>> Hello, looks like on Linux there is a special check in > TestSpecialArgs.java > >> for > >>> > >>> launcherPidString = "launcher.pid=" > >>> > >>> that fails after 8231171 . > >>> Should I adjust the test ? Or keep the setting in the launcher on Linux ? > >> > >> IMHO adjust the test please. > >> > >> Thanks, > >> David > >> ----- > >> > > From peter.levart at gmail.com Mon Sep 23 07:23:11 2019 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 23 Sep 2019 09:23:11 +0200 Subject: JDK 14 RFR of JDK-8231202: Suppress warnings on non-serializable non-transient instance fields in serializable classes In-Reply-To: References: Message-ID: <55659406-be43-7739-bd1e-db037bcb75b0@gmail.com> Hi Joe, I've been thinking of this example: ? 83 final class Ser implements Externalizable { ? 84 ... ? 99???? /** The object being serialized. */ ?100???? @SuppressWarnings("serial") // Not statically typed as Serializable ?101???? private Object object; Externalizable does extend Serializable, but the serialization infrastructure delegates all work to writeExternal/readExternal methods which implement the (de)serialization logic. They may deconstruct otherwise non-Serializable objects into Serializable parts before handing them to ObjectOutputStream /? construct otherwise non-Serializable objects from Serializable parts read from ObjectInputStream. @SuppressWarnings in such cases is maybe not suitable. Perhaps the intent would be better expressed by marking the field as transient.? What do you think? Regards, Peter On 9/18/19 11:38 PM, Joe Darcy wrote: > Hello, > > As background, I'm working on a number of serialization-related > compile-time checks with the goal of enabling stricter javac lint > checking in the JDK build (and elsewhere). > > One check is tracked by > > ??? JDK-8160675: Issue lint warning for non-serializable non-transient > instance fields in serializable type > > As summarized in the bug description, it may be concerning if a > serializable class has non-transient instance fields whose types are > not Serializable. This can cause a serialization failure at runtime. > (Classes using the serialPersistentFields mechanism are excluded from > this check.) > > A common example is an exception type -- all Throwable's are > Serializable -- which has a non-serializable field. If the fields > cannot be marked as transient, one approach to handle this robustly is > to have a writeObject method which null outs the field in question > when serializing and make the other methods in the exception > null-tolerant. > > In other cases, the object pointed to by the non-serializable field > are conditionally serializable at runtime. This is the case for many > collection types. For example, a class may have a field of type > List with the field set to an ArrayList at runtime. While > the List interface does not extent Serializable, the ArrayList class > does implement Serializable and the class would serialize fine in > practice, assuming the Foo's were serialazable. > > As a precursor to the adding a compile-time check to the build, please > review adding @SuppressWarnings("serial") to document the > non-serializable fields in the core libraries: > > ??? JDK-8231202: Suppress warnings on non-serializable non-transient > instance fields in serializable classes > ??? http://cr.openjdk.java.net/~darcy/8231202.0/ > > Bugs for similar changes to client libs and security libs will be > filed and reviewed separately. > > A more complete fix would add readObject/writeObject null handling to > AnnotationTypeMismatchExceptionProxy, but since this hasn't seemed to > be an issue since the type was introduced back in JDK 5.0, I just > added the annotation, as done elsewhere. > > Thanks, > > -Joe > From peter.levart at gmail.com Mon Sep 23 08:44:12 2019 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 23 Sep 2019 10:44:12 +0200 Subject: RFR 8231314: java.time serialization warning cleanup In-Reply-To: <42910678-6051-44E9-AB89-0318A1100684@oracle.com> References: <5c9f0062-1036-d638-1940-3d4974b05bc4@oracle.com> <42910678-6051-44E9-AB89-0318A1100684@oracle.com> Message-ID: <08f26ffe-90d5-7646-0788-696ef822d1d2@gmail.com> Once more, for the list (sorry)... Hi, On 9/21/19 12:31 PM, Chris Hegarty wrote: > Roger, > >> On 20 Sep 2019, at 19:51, Roger Riggs wrote: >> >> Please review code cleanup that will remove the need to suppress soon >> to be introduced >> warnings [1] about static typing of serialization related fields. >> A few of the implementation Ser classes that serialize java.time >> types are affected. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-warn-serializable-8231314/ > I think the change is fine, just a few comments.. > > - AbstractChronology is not necessarily is not always Serializable, > but writeReplace expects that it is. > Since this is a package-private method, then I assume that it will > only ever be called by Serializable subtypes or the serialization > framework itself. > > - time/chrono/Ser.java : it?s kinda awkward to have to cast the return > of readExternal, especially since the set of types is locked down, but > without these readExternal methods returning xxxImpl types there is > little choice. readExternal package-private methods could return Serializable, but then those methods would have to cast. Perhaps this would be better as it is "closer" to the real impl. Another option (as I mentioned in previous message) would be to simply mark the Ser field as transient. The fact that currently it always holds an instance that *is* Serializable is just a coincidence, because it acts as a serialization proxy for Serializable implementations. Nothing in the logic of Ser class "requires" the instance assigned? to the field to be in fact Serializable. Regards, Peter From daniel.fuchs at oracle.com Mon Sep 23 09:15:36 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 23 Sep 2019 10:15:36 +0100 Subject: RFR 8221623 : Add StackWalker micro benchmarks to jdk repo In-Reply-To: References: <1408b71b-bf20-eb45-376d-bcd8dc2d3e3d@oracle.com> Message-ID: <59efb0d6-ecf1-74dd-eebb-656c9fa1fb8d@oracle.com> Hi Brent, On 19/09/2019 20:08, Brent Christian wrote: > Well-spotted. > JMH defaults to using 1 worker thread, but can be configured to use > more.? I tried with '-t max' (8 threads on my machine), and the > benchmark NPE'd, as you predicted. > > I've updated the benchmark to use a separate handler (and Logger) > per-thread, and it can now run w/ '-t max'.? Single-thread scores are > within a few % of the original test.? I also added "Logging" to the > benchmark names to make it easier to select both in JMH using a simple > regex. Good. Thanks for checking! > http://cr.openjdk.java.net/~bchristi/8221623/webrev09-loggerPerThread/ The updated benchmark looks good to me. I almost missed the magic at line 47: 47 @State(value = Scope.Thread) // create a separate one for each worker thread I'll try to remember that trick. > Though really, since logging is no longer using Throwable to examine the > call stack, maybe it makes more sense to move the logging benchmarks to > their own file under: > > test/micro/org/openjdk/bench/java/util/logging/ Well, I'll let you decide on that. That would be the first logging benchmark :-) best regards, -- daniel From goetz.lindenmaier at sap.com Mon Sep 23 10:03:30 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 23 Sep 2019 10:03:30 +0000 Subject: RFR (L, final): 8218626: Add detailed message to NullPointerException describing what is null. In-Reply-To: <1893074105.2191032.1568930433981.JavaMail.zimbra@u-pem.fr> References: <563186416.1041616.1568757083163.JavaMail.zimbra@u-pem.fr> <1893074105.2191032.1568930433981.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Remi, what do you think about dealing with the problem like this: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/18-obfuscation/ It's at the cost of one 64-bit field per bytecode in the analysis data. Also, if there is a real assignment to a parameter it's not named 'parameteri' after that any more. See the example in the test. Best regards, Goetz. > -----Original Message----- > From: forax at univ-mlv.fr > Sent: Freitag, 20. September 2019 00:01 > To: Lindenmaier, Goetz > Cc: hotspot-runtime-dev ; core-libs- > dev > Subject: Re: RFR (L, final): 8218626: Add detailed message to > NullPointerException describing what is null. > > ----- Mail original ----- > > De: "Goetz Lindenmaier" > > ?: "Remi Forax" > > Cc: "hotspot-runtime-dev" , "core- > libs-dev" > > Envoy?: Mercredi 18 Septembre 2019 09:37:36 > > Objet: RE: RFR (L, final): 8218626: Add detailed message to > NullPointerException describing what is null. > > > Hi Remi, > > Hi Goetz, > > > > >> in bytecodeUtils.cpp, in print_local_var(), > >> i believe that the code > >> if (!method->is_static() && (slot == 0)) { > >> os->print("this"); > >> } > >> ... > >> is only true if the bytecode is generated by javac and ecj, tools like proguard > >> that tries to obfuscate the code will reuse the slot 0 once "this" is not > needed > >> anymore. > >> This is obviously also true for any other parameters, so in my opinion, you > >> should not try to be too heroic here and always display "local%d". > > Yes, you are right. I assume the bytecode local slots are mapped 1:1 to > > the parameters and are not reused for other values. > > > >> The other solution is to propagate "this" and "parameter%d" during the > static > >> analysis, so "this" will become "local0" once a store_0 is seen. > > It would be possible to spot the place where "this" is first overwritten. > > For other parameters, this is not feasible, they are not read-only, so > > stores don't indicate obfuscation. > > Java is not the only language to run on the Java plateform so try to detect > "obfuscation" is again akind of shortcut. > > > > > I could mark the whole method as 'obfuscated' once I see a store_0, > > and then print "local" instead of "parameter" in all places. > > This does not work for static methods, though. Nor for methods > > where "this" is live to the end, but the parameter slots are > > reused. > > and you can have a path with a store_0 and one without (the code is not > linear). > > > > > For obfuscated methods I would claim that printing "this" etc > > is fine even if the slot is reused for another value. It just > > adds to the obfuscation! But there might be code > > that is just optimized and not meant to be obfuscated. > > I've used obfuscation as an example, but there are also valid case to reuse slots > likeit will consume less stack memory if you are using a very small device. > > > > > Best regards, > > Goetz. > > regards, > R?mi > > > > > > > > > > > > > > >> > >> R?mi > >> > >> ----- Mail original ----- > >> > De: "Goetz Lindenmaier" > >> > ?: "hotspot-runtime-dev" , > >> "core-libs-dev" > >> > Envoy?: Mardi 17 Septembre 2019 16:18:03 > >> > Objet: RE: RFR (L, final): 8218626: Add detailed message to > >> NullPointerException describing what is null. > >> > >> > @core-libs experts, I would appreciate comments on the changes > >> > to NullPointerException.java, especially wrt. the Javadoc comment. > >> > The change there is S. > >> > > >> > Best regards, > >> > Goetz. > >> > > >> >> -----Original Message----- > >> >> From: Lindenmaier, Goetz > >> >> Sent: Dienstag, 10. September 2019 11:48 > >> >> To: 'Hotspot dev runtime' ; > >> Java Core > >> >> Libs > >> >> Subject: RFR (L, final): 8218626: Add detailed message to > >> NullPointerException > >> >> describing what is null. > >> >> > >> >> Hi, > >> >> > >> >> > >> >> > >> >> this is the implementation of JEP 358: Helpful NullPointerExceptions. > >> >> > >> >> > >> >> > >> >> The JEP is in status "Candidate". Coleen (many, many thanks!) ran > >> >> > >> >> it through the Oracle-internal processes. Now I please need final reviews > >> >> > >> >> for this change so that I can propose it to target jdk 14. > >> >> > >> >> > >> >> > >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8220715 > >> >> > >> >> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8218628 > >> >> > >> >> webrev: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg- > >> NPE/16/ > >> >> > >> >> > >> >> > >> >> The change ran through a lot of testing, all jtreg and jck tests to name > >> >> > >> >> only some. The webrev points to patch > >> >> > >> >> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg- > >> >> NPE/16/enable_NPE_message.patch > >> >> > >> >> that enables the change by default, which was useful for testing to > >> >> > >> >> assure the code is used in the tests. > >> >> > >> >> I just pushed the change to jdk/submit once more. > >> >> > >> >> > >> >> > >> >> Please review. > >> >> > >> >> > >> >> > >> >> Thanks! > >> >> > > > > > Goetz. From pavel.rappo at oracle.com Mon Sep 23 11:35:17 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Mon, 23 Sep 2019 12:35:17 +0100 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> <87sgpblxns.fsf@oldenburg2.str.redhat.com> <7A46485C-E250-4E57-9FB0-B9D18CA70632@oracle.com> <60FD933F-51A5-4438-83AF-B3427CFDE60D@oracle.com> <8A9E3066-E6F6-4E65-BD02-DF0ACFF02FAD@oracle.com> <633A0CE3-C771-493B-89E3-7FA843C85183@oracle.com> <6b209e36-686f-7852-7fb8-3a0ef0e8423a@oracle.com> <4CAC6E8D-9198-4701-99C0-49901D72A396@oracle.com> <47acbb78-806f-2951-3b22-de6e7965f461@oracle.com> <275EC96C-CC39-41C8-9B9C-B917F25FAB70@oracle.com> <7D4375A7-E2CC-4297-92DF-A13FC9EF07AE@oracle.com> <81087256-819E-49FF-BB94-ADA9530717DD@oracle.com> Message-ID: Milan, How do you check which tests are run? That's what I see in the /test-support/jtreg_open_test_jdk_com_sun_jndi_dns_ConfigTests_TcpTimeout_java/com/sun/jndi/dns/ConfigTests/TcpTimeout.jtr file after I have run the test locally on my machine: ----------messages:(5/233)---------- command: main TcpTimeout reason: User specified action: run main TcpTimeout Mode: othervm Additional options from @modules: --add-modules java.base --add-exports java.base/sun.security.util=ALL-UNNAMED elapsed time (seconds): 1.751 ... ----------messages:(5/313)---------- command: main TcpTimeout -Dcom.sun.jndi.dns.timeout.initial=5000 reason: User specified action: run main TcpTimeout -Dcom.sun.jndi.dns.timeout.initial=5000 Mode: othervm Additional options from @modules: --add-modules java.base --add-exports java.base/sun.security.util=ALL-UNNAMED elapsed time (seconds): 5.498 ------------------------------------ Which is consistent with what I would expect given the timeout values. The following output does not tell the full story, just the name of the test: ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR jtreg:open/test/jdk/com/sun/jndi/dns/ConfigTests/TcpTimeout.java 1 1 0 0 ============================== TEST SUCCESS -Pavel > On 20 Sep 2019, at 15:42, Milan Mimica wrote: > > Pavel, > > Here it is: http://cr.openjdk.java.net/~mmimica/8228580/webrev.04/ > I don't see the test is run twice when I execute "make test > TEST=jtreg:test/jdk/com/sun/jndi/dns/ConfigTests/TcpTimeout.java". Am > I missing something? > > On Thu, 19 Sep 2019 at 13:16, Pavel Rappo wrote: >> >> Milan, >> >> This looks like a good start. Please consider >> >> 1. Setting TOLERANCE to 5 seconds >> 2. Getting the second time mark immediately after the query returns (i.e. do not waste your time in DNSTestUtils.debug(attrs)) >> 3. Making the test parametric instead of hardcoded for the DEFAULT_DNS_CLIENT_TIMEOUT >> 4. Running the test for at least 2 different values of the timeout, e.g.: >> >> * @run main TcpTimeout >> * @run main TcpTimeout -Dcom.sun.jndi.dns.timeout.initial=5000 >> >> As for you question, I'm not sure how we would be able to communicate the fact that the response is truncated to the user. You could try to ask this on the net-dev mailing list. >> >> -Pavel >> >>> On 18 Sep 2019, at 14:25, Milan Mimica wrote: >>> >>> Hi Pavel >>> >>> Sure. Here is the incremental change: >>> http://cr.openjdk.java.net/~mmimica/8228580/webrev.03/ >>> >>> What actually bothers me from the beginning is the truncated response. >>> The TXT attribute, a String, prints "A very popular h", but does not >>> equals("A very popular h"), because of some stray bytes. I guess it's >>> because of how DNS response parsing works. I can imagine how this >>> could cause problems to users. I think, at least, we should have a way >>> to tell the user that the response is truncated, and the payload is >>> partial/invalid. >>> >>> >>> On Tue, 17 Sep 2019 at 15:09, Pavel Rappo wrote: >>>> >>>> Milan, >>>> >>>> While the CSR is being processed, could we maybe think of some additional testing for that change? Otherwise, that test seems kind of anemic. It makes sure that the query doesn't hang, but that's about it. It doesn't check that the timeout is respected. I was wondering if you could propose some way of testing that. >>>> >>>>> On 17 Sep 2019, at 09:55, Pavel Rappo wrote: >>>>> >>>>> I have filed the CSR: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8230965 >>>>> >>>>>> On 13 Sep 2019, at 11:21, Pavel Rappo wrote: >>>>>> >>>>>> Here's the latest webrev accumulating all the changes we've discussed so far: >>>>>> >>>>>> http://cr.openjdk.java.net/~prappo/8228580/webrev.03/ >>>>>> >>>>>> If people are okay with that I will proceed to creating a CSR. >>>> >>> >>> >>> -- >>> Milan Mimica >> > > > -- > Milan Mimica From alexey.semenyuk at oracle.com Mon Sep 23 11:49:58 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Mon, 23 Sep 2019 07:49:58 -0400 Subject: RFR: JDK-8231279: Change install location for copyright file for Debian package In-Reply-To: <658dada7-d09e-d49c-b100-fed29db6ab3d@oracle.com> References: <658dada7-d09e-d49c-b100-fed29db6ab3d@oracle.com> 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). Baseline for the fix is [3] patch. [1] https://bugs.openjdk.java.net/browse/JDK-8231279 [2] http://cr.openjdk.java.net/~asemenyuk/8231279/webrev.01/ [3] http://cr.openjdk.java.net/~asemenyuk/8231277/webrev.00/ From andy.herrick at oracle.com Mon Sep 23 12:19:07 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 23 Sep 2019 08:19:07 -0400 Subject: RFR: JDK-8225249: LinuxDebBundler and LinuxRpmBundler should share more In-Reply-To: <5f7e9cc8-9698-f7a5-dc1a-3cb3a2ddf30a@oracle.com> References: <583dc9b6-6b2b-a04b-f209-9ce2a851d007@oracle.com> <5f7e9cc8-9698-f7a5-dc1a-3cb3a2ddf30a@oracle.com> Message-ID: <6a9affb3-bdf0-5301-1be6-b60ee11c900a@oracle.com> This looks good far as I can tell. /Andy On 9/18/2019 11:23 AM, 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). > > This fix: > > - Move common deb and rpm packaging code in the new class > (jdk.jpackage.internal.LinuxPackageBundler). > - Implement Java runtime packaging on Linux. > - Fix of [3], [4] bugs as a side effect of code refactoring. > - Add shell scripts to run jpackage jtreg tests. > - Add tests for application desktop integration on Linux. > - Add uninstall script to clean leftovers after file associations of > the app are removed. Uninstalling Linux app with file associations > will produce the following console output: > --- > Running: sudo dpkg -r fileassociationstest > (Reading database ... 250166 files and directories currently installed.) > Removing fileassociationstest (1.0-1) ... > Remove fileassociationstest-FileassociationsTest.desktop default > handler for application/x-jpackage-jptest1 mime type from > /usr/share/applications/defaults.list file > Remove fileassociationstest-FileassociationsTest.desktop default > handler for application/x-jpackage-jptest2 mime type from > /usr/share/applications/defaults.list file > /usr/share/applications/defaults.list file updated > --- > - Clean some unused code. > > /Andy > > > [1] https://bugs.openjdk.java.net/browse/JDK-8225249 > > [2] http://cr.openjdk.java.net/~asemenyuk/8225249/webrev.02/ > > [3] https://bugs.openjdk.java.net/browse/JDK-8230899 > > [4] https://bugs.openjdk.java.net/browse/JDK-8230917 From andy.herrick at oracle.com Mon Sep 23 12:24:27 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 23 Sep 2019 08:24:27 -0400 Subject: RFR: JDK-8231279: Change install location for copyright file for Debian package In-Reply-To: References: <658dada7-d09e-d49c-b100-fed29db6ab3d@oracle.com> Message-ID: looks good. /Andy On 9/23/2019 7:49 AM, 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). > > Baseline for the fix is [3] patch. > > [1] https://bugs.openjdk.java.net/browse/JDK-8231279 > > [2] http://cr.openjdk.java.net/~asemenyuk/8231279/webrev.01/ > > [3] http://cr.openjdk.java.net/~asemenyuk/8231277/webrev.00/ > From andy.herrick at oracle.com Mon Sep 23 12:53:10 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 23 Sep 2019 08:53:10 -0400 Subject: RFR: JDK-8230651: Use version string from main module In-Reply-To: References: Message-ID: <7ac275f7-62e4-6095-35e3-e01233c3ee72@oracle.com> Looks good. /Andy On 9/20/2019 5:54 PM, Alexander Matveev wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > - Version from main module (if exist) will be used as --app-version if > --app-version is not specified. > > [1] https://bugs.openjdk.java.net/browse/JDK-8230651 > > [2] http://cr.openjdk.java.net/~almatvee/8230651/webrev.01/ > > Thanks, > Alexander From milan.mimica at gmail.com Mon Sep 23 13:20:34 2019 From: milan.mimica at gmail.com (Milan Mimica) Date: Mon, 23 Sep 2019 15:20:34 +0200 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> <87sgpblxns.fsf@oldenburg2.str.redhat.com> <7A46485C-E250-4E57-9FB0-B9D18CA70632@oracle.com> <60FD933F-51A5-4438-83AF-B3427CFDE60D@oracle.com> <8A9E3066-E6F6-4E65-BD02-DF0ACFF02FAD@oracle.com> <633A0CE3-C771-493B-89E3-7FA843C85183@oracle.com> <6b209e36-686f-7852-7fb8-3a0ef0e8423a@oracle.com> <4CAC6E8D-9198-4701-99C0-49901D72A396@oracle.com> <47acbb78-806f-2951-3b22-de6e7965f461@oracle.com> <275EC96C-CC39-41C8-9B9C-B917F25FAB70@oracle.com> <7D4375A7-E2CC-4297-92DF-A13FC9EF07AE@oracle.com> <81087256-819E-49FF-BB94-ADA9530717DD@oracle.com> Message-ID: Got it. Thanks Pavel! On Mon, 23 Sep 2019 at 13:37, Pavel Rappo wrote: > > Milan, > > How do you check which tests are run? That's what I see in the /test-support/jtreg_open_test_jdk_com_sun_jndi_dns_ConfigTests_TcpTimeout_java/com/sun/jndi/dns/ConfigTests/TcpTimeout.jtr file after I have run the test locally on my machine: > > ----------messages:(5/233)---------- > command: main TcpTimeout > reason: User specified action: run main TcpTimeout > Mode: othervm > Additional options from @modules: --add-modules java.base --add-exports java.base/sun.security.util=ALL-UNNAMED > elapsed time (seconds): 1.751 > > ... > > ----------messages:(5/313)---------- > command: main TcpTimeout -Dcom.sun.jndi.dns.timeout.initial=5000 > reason: User specified action: run main TcpTimeout -Dcom.sun.jndi.dns.timeout.initial=5000 > Mode: othervm > Additional options from @modules: --add-modules java.base --add-exports java.base/sun.security.util=ALL-UNNAMED > elapsed time (seconds): 5.498 > > ------------------------------------ > > Which is consistent with what I would expect given the timeout values. > > The following output does not tell the full story, just the name of the test: > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:open/test/jdk/com/sun/jndi/dns/ConfigTests/TcpTimeout.java > 1 1 0 0 > ============================== > TEST SUCCESS > > -Pavel > > > On 20 Sep 2019, at 15:42, Milan Mimica wrote: > > > > Pavel, > > > > Here it is: http://cr.openjdk.java.net/~mmimica/8228580/webrev.04/ > > I don't see the test is run twice when I execute "make test > > TEST=jtreg:test/jdk/com/sun/jndi/dns/ConfigTests/TcpTimeout.java". Am > > I missing something? > > -- Milan Mimica From Alan.Bateman at oracle.com Mon Sep 23 13:56:08 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 Sep 2019 14:56:08 +0100 Subject: [RFR] 8231171: remove remaining sun.java.launcher.pid references - was RE: sun.java.launcher.pid property usage In-Reply-To: References: <3db7390f-36df-d304-3188-d11e35a673ab@oracle.com> <765279b9-1b60-88ad-8548-3f5cf1b19f28@oracle.com> <173137cf-2fbd-1d5a-17d2-a2d42265f688@oracle.com> Message-ID: <89fe0bc2-41d0-0e4c-d6a7-101304a1c151@oracle.com> On 23/09/2019 08:06, Baesken, Matthias wrote: > Thanks for the review ! > Alan, may I add you as reviewer too ? > Yes, okay with me too. -Alan From Roger.Riggs at oracle.com Mon Sep 23 14:09:59 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 23 Sep 2019 10:09:59 -0400 Subject: JDK 14 RFR of JDK-8231202: Suppress warnings on non-serializable non-transient instance fields in serializable classes In-Reply-To: <55659406-be43-7739-bd1e-db037bcb75b0@gmail.com> References: <55659406-be43-7739-bd1e-db037bcb75b0@gmail.com> Message-ID: <341096fd-ff1e-0e2c-3b9b-3e9f81c73967@oracle.com> Hi Peter, Good observation. Adding transient would negate on of the conditions for warning, so no warning. And there would be no need to look at the static types more closely. If the Ser proxy were for a non-serializable type that would be a good option. I think there's a different problem with the chrono/Ser type that complicates that case. More about that on the thread...? 8231314: java.time serialization warning cleanup Thanks, Roger On 9/23/19 3:23 AM, Peter Levart wrote: > Hi Joe, > > I've been thinking of this example: > > ? 83 final class Ser implements Externalizable { > ? 84 > ... > ? 99???? /** The object being serialized. */ > ?100???? @SuppressWarnings("serial") // Not statically typed as > Serializable > ?101???? private Object object; > > > Externalizable does extend Serializable, but the serialization > infrastructure delegates all work to writeExternal/readExternal > methods which implement the (de)serialization logic. They may > deconstruct otherwise non-Serializable objects into Serializable parts > before handing them to ObjectOutputStream /? construct otherwise > non-Serializable objects from Serializable parts read from > ObjectInputStream. @SuppressWarnings in such cases is maybe not > suitable. Perhaps the intent would be better expressed by marking the > field as transient.? What do you think? > > Regards, Peter > > On 9/18/19 11:38 PM, Joe Darcy wrote: >> Hello, >> >> As background, I'm working on a number of serialization-related >> compile-time checks with the goal of enabling stricter javac lint >> checking in the JDK build (and elsewhere). >> >> One check is tracked by >> >> ??? JDK-8160675: Issue lint warning for non-serializable >> non-transient instance fields in serializable type >> >> As summarized in the bug description, it may be concerning if a >> serializable class has non-transient instance fields whose types are >> not Serializable. This can cause a serialization failure at runtime. >> (Classes using the serialPersistentFields mechanism are excluded from >> this check.) >> >> A common example is an exception type -- all Throwable's are >> Serializable -- which has a non-serializable field. If the fields >> cannot be marked as transient, one approach to handle this robustly >> is to have a writeObject method which null outs the field in question >> when serializing and make the other methods in the exception >> null-tolerant. >> >> In other cases, the object pointed to by the non-serializable field >> are conditionally serializable at runtime. This is the case for many >> collection types. For example, a class may have a field of type >> List with the field set to an ArrayList at runtime. While >> the List interface does not extent Serializable, the ArrayList class >> does implement Serializable and the class would serialize fine in >> practice, assuming the Foo's were serialazable. >> >> As a precursor to the adding a compile-time check to the build, >> please review adding @SuppressWarnings("serial") to document the >> non-serializable fields in the core libraries: >> >> ??? JDK-8231202: Suppress warnings on non-serializable non-transient >> instance fields in serializable classes >> ??? http://cr.openjdk.java.net/~darcy/8231202.0/ >> >> Bugs for similar changes to client libs and security libs will be >> filed and reviewed separately. >> >> A more complete fix would add readObject/writeObject null handling to >> AnnotationTypeMismatchExceptionProxy, but since this hasn't seemed to >> be an issue since the type was introduced back in JDK 5.0, I just >> added the annotation, as done elsewhere. >> >> Thanks, >> >> -Joe >> > From pavel.rappo at oracle.com Mon Sep 23 14:14:55 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Mon, 23 Sep 2019 15:14:55 +0100 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> <87sgpblxns.fsf@oldenburg2.str.redhat.com> <7A46485C-E250-4E57-9FB0-B9D18CA70632@oracle.com> <60FD933F-51A5-4438-83AF-B3427CFDE60D@oracle.com> <8A9E3066-E6F6-4E65-BD02-DF0ACFF02FAD@oracle.com> <633A0CE3-C771-493B-89E3-7FA843C85183@oracle.com> <6b209e36-686f-7852-7fb8-3a0ef0e8423a@oracle.com> <4CAC6E8D-9198-4701-99C0-49901D72A396@oracle.com> <47acbb78-806f-2951-3b22-de6e7965f461@oracle.com> <275EC96C-CC39-41C8-9B9C-B917F25FAB70@oracle.com> <7D4375A7-E2CC-4297-92DF-A13FC9EF07AE@oracle.com> <81087256-819E-49FF-BB94-ADA9530717DD@oracle.com> Message-ID: Milan, I'm observing the latest version (.04) of this test failing quite frequently (4/100) on Windows (Windows Server 2012 R2 6.3 (amd64)) machines. The test passes fine on macOS and Linux. Here's the typical output I see in the logs: java.lang.RuntimeException: Query took 4997 ms. . Timeout value is 5000 java.lang.RuntimeException: Query took 4999 ms. . Timeout value is 5000 java.lang.RuntimeException: Query took 4995 ms. . Timeout value is 5000 java.lang.RuntimeException: Query took 4998 ms. . Timeout value is 5000 ... Now, there might be many reasons for that. One of which would be that the DnsClient code is buggy. The other reason would be that the accuracy guaranteed by Windows implementation of `read` is not what we would expect. Would you be able to investigate that? P.S. The good news is that the CSR has been approved: https://bugs.openjdk.java.net/browse/JDK-8230965 > On 23 Sep 2019, at 14:20, Milan Mimica wrote: > > Got it. Thanks Pavel! > > > On Mon, 23 Sep 2019 at 13:37, Pavel Rappo wrote: >> >> Milan, >> >> How do you check which tests are run? That's what I see in the /test-support/jtreg_open_test_jdk_com_sun_jndi_dns_ConfigTests_TcpTimeout_java/com/sun/jndi/dns/ConfigTests/TcpTimeout.jtr file after I have run the test locally on my machine: >> >> ----------messages:(5/233)---------- >> command: main TcpTimeout >> reason: User specified action: run main TcpTimeout >> Mode: othervm >> Additional options from @modules: --add-modules java.base --add-exports java.base/sun.security.util=ALL-UNNAMED >> elapsed time (seconds): 1.751 >> >> ... >> >> ----------messages:(5/313)---------- >> command: main TcpTimeout -Dcom.sun.jndi.dns.timeout.initial=5000 >> reason: User specified action: run main TcpTimeout -Dcom.sun.jndi.dns.timeout.initial=5000 >> Mode: othervm >> Additional options from @modules: --add-modules java.base --add-exports java.base/sun.security.util=ALL-UNNAMED >> elapsed time (seconds): 5.498 >> >> ------------------------------------ >> >> Which is consistent with what I would expect given the timeout values. >> >> The following output does not tell the full story, just the name of the test: >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:open/test/jdk/com/sun/jndi/dns/ConfigTests/TcpTimeout.java >> 1 1 0 0 >> ============================== >> TEST SUCCESS >> >> -Pavel >> >>> On 20 Sep 2019, at 15:42, Milan Mimica wrote: >>> >>> Pavel, >>> >>> Here it is: http://cr.openjdk.java.net/~mmimica/8228580/webrev.04/ >>> I don't see the test is run twice when I execute "make test >>> TEST=jtreg:test/jdk/com/sun/jndi/dns/ConfigTests/TcpTimeout.java". Am >>> I missing something? >>> > > > -- > Milan Mimica From Roger.Riggs at oracle.com Mon Sep 23 14:56:14 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 23 Sep 2019 10:56:14 -0400 Subject: RFR 8231314: java.time serialization warning cleanup In-Reply-To: <08f26ffe-90d5-7646-0788-696ef822d1d2@gmail.com> References: <5c9f0062-1036-d638-1940-3d4974b05bc4@oracle.com> <42910678-6051-44E9-AB89-0318A1100684@oracle.com> <08f26ffe-90d5-7646-0788-696ef822d1d2@gmail.com> Message-ID: <2fc0faee-2be4-5e54-0ff1-ba8666933bd1@oracle.com> Hi, Updated to? wrap long lines and remove unneeded @SuppressWarnings. http://cr.openjdk.java.net/~rriggs/webrev-warn-serializable-8231314-2/ On 9/23/19 4:44 AM, Peter Levart wrote: > Once more, for the list (sorry)... > > Hi, > > On 9/21/19 12:31 PM, Chris Hegarty wrote: >> Roger, >> >>> On 20 Sep 2019, at 19:51, Roger Riggs wrote: >>> >>> Please review code cleanup that will remove the need to suppress >>> soon to be introduced >>> warnings [1] about static typing of serialization related fields. >>> A few of the implementation Ser classes that serialize java.time >>> types are affected. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-warn-serializable-8231314/ >> I think the change is fine, just a few comments.. >> >> - AbstractChronology is not necessarily is not always Serializable, >> but writeReplace expects that it is. >> Since this is a package-private method, then I assume that it will >> only ever be called by Serializable subtypes or the serialization >> framework itself. Correct, chrono/Ser is only used for built-in subtypes of AbstractChronology. I think there is a separate design choice that should be questioned. In retrsospect I think it should required subclasses of AbstractChronology be Serializable. A number of java.time. serializable types can refer to a Chronology and if Chronology is not serializable, then they won't be either.? If AbstractChronology extended Serializable, other implementations would be aware of the expectation and have to make a deliberate choice. But this is a separate issue. >> >> - time/chrono/Ser.java : it?s kinda awkward to have to cast the >> return of readExternal, especially since the set of types is locked >> down, but without these readExternal methods returning xxxImpl types >> there is little choice. True > > readExternal package-private methods could return Serializable, but > then those methods would have to cast. Perhaps this would be better as > it is "closer" to the real impl. That would be better, but except for lambdas, I don't know of a way to cast to multiple interfaces. > > Another option (as I mentioned in previous message) would be to simply > mark the Ser field as transient. The fact that currently it always > holds an instance that *is* Serializable is just a coincidence, > because it acts as a serialization proxy for Serializable > implementations. Nothing in the logic of Ser class "requires" the > instance assigned? to the field to be in fact Serializable. That makes sense for the general non-serializable case, but in the case of chrono/Ser, all of the implementations are known to be Serializable. Thanks, Roger > > Regards, Peter > > From Roger.Riggs at oracle.com Mon Sep 23 15:29:44 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 23 Sep 2019 11:29:44 -0400 Subject: RFR (L, final): 8218626: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: Message-ID: <402d9260-8cde-194b-3638-283eddb8c6c9@oracle.com> Hi Goetz, A bit of wordsmithing on the javadoc of NullPointerException.getMessage and separating out the implementation specific description to an @implNote 75: ?/** * Returns the detail message string of this throwable. *

    * If a non-null message was supplied in a constructor it is returned. * Otherwise, an implementation specific message or {@code null} is returned. ?* @ImplNote * If no explicit message was passed to the constructor, and as * long as certain internal information is available, a verbose * description of the null reference is returned. * The internal information is not available in deserialized NullPointerExceptions. * * @return the detail message string, which may be {@code null}. * 94-97: The comment on the getExtendedNPEMessage should use the normal /**... */ syntax. Thanks, Roger On 9/17/19 10:18 AM, Lindenmaier, Goetz wrote: > @core-libs experts, I would appreciate comments on the changes > to NullPointerException.java, especially wrt. the Javadoc comment. > The change there is S. > > Best regards, > Goetz. > >> -----Original Message----- >> From: Lindenmaier, Goetz >> Sent: Dienstag, 10. September 2019 11:48 >> To: 'Hotspot dev runtime' ; Java Core >> Libs >> Subject: RFR (L, final): 8218626: Add detailed message to NullPointerException >> describing what is null. >> >> Hi, >> >> >> >> this is the implementation of JEP 358: Helpful NullPointerExceptions. >> >> >> >> The JEP is in status "Candidate". Coleen (many, many thanks!) ran >> >> it through the Oracle-internal processes. Now I please need final reviews >> >> for this change so that I can propose it to target jdk 14. >> >> >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8220715 >> >> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8218628 >> >> webrev: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/16/ >> >> >> >> The change ran through a lot of testing, all jtreg and jck tests to name >> >> only some. The webrev points to patch >> >> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg- >> NPE/16/enable_NPE_message.patch >> >> that enables the change by default, which was useful for testing to >> >> assure the code is used in the tests. >> >> I just pushed the change to jdk/submit once more. >> >> >> >> Please review. >> >> >> >> Thanks! >> >> Goetz. From forax at univ-mlv.fr Mon Sep 23 16:02:29 2019 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Mon, 23 Sep 2019 18:02:29 +0200 (CEST) Subject: RFR (L, final): 8218626: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <563186416.1041616.1568757083163.JavaMail.zimbra@u-pem.fr> <1893074105.2191032.1568930433981.JavaMail.zimbra@u-pem.fr> Message-ID: <2062332399.429540.1569254549560.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Goetz Lindenmaier" > ?: "Remi Forax" > Cc: "hotspot-runtime-dev" , "core-libs-dev" > Envoy?: Lundi 23 Septembre 2019 12:03:30 > Objet: RE: RFR (L, final): 8218626: Add detailed message to NullPointerException describing what is null. > Hi Remi, Hi Goetz, > > what do you think about dealing with the problem like this: > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/18-obfuscation/ > It's at the cost of one 64-bit field per bytecode in the analysis data. > Also, if there is a real assignment to a parameter it's not named 'parameteri' > after that any more. See the example in the test. > yes, it's a nice approximation, having a method with more than 63/64 parameters is rare. patch looks good, thumbs up ! > Best regards, > Goetz. > regards, R?mi > > >> -----Original Message----- >> From: forax at univ-mlv.fr >> Sent: Freitag, 20. September 2019 00:01 >> To: Lindenmaier, Goetz >> Cc: hotspot-runtime-dev ; core-libs- >> dev >> Subject: Re: RFR (L, final): 8218626: Add detailed message to >> NullPointerException describing what is null. >> >> ----- Mail original ----- >> > De: "Goetz Lindenmaier" >> > ?: "Remi Forax" >> > Cc: "hotspot-runtime-dev" , "core- >> libs-dev" >> > Envoy?: Mercredi 18 Septembre 2019 09:37:36 >> > Objet: RE: RFR (L, final): 8218626: Add detailed message to >> NullPointerException describing what is null. >> >> > Hi Remi, >> >> Hi Goetz, >> >> > >> >> in bytecodeUtils.cpp, in print_local_var(), >> >> i believe that the code >> >> if (!method->is_static() && (slot == 0)) { >> >> os->print("this"); >> >> } >> >> ... >> >> is only true if the bytecode is generated by javac and ecj, tools like proguard >> >> that tries to obfuscate the code will reuse the slot 0 once "this" is not >> needed >> >> anymore. >> >> This is obviously also true for any other parameters, so in my opinion, you >> >> should not try to be too heroic here and always display "local%d". >> > Yes, you are right. I assume the bytecode local slots are mapped 1:1 to >> > the parameters and are not reused for other values. >> > >> >> The other solution is to propagate "this" and "parameter%d" during the >> static >> >> analysis, so "this" will become "local0" once a store_0 is seen. >> > It would be possible to spot the place where "this" is first overwritten. >> > For other parameters, this is not feasible, they are not read-only, so >> > stores don't indicate obfuscation. >> >> Java is not the only language to run on the Java plateform so try to detect >> "obfuscation" is again akind of shortcut. >> >> > >> > I could mark the whole method as 'obfuscated' once I see a store_0, >> > and then print "local" instead of "parameter" in all places. >> > This does not work for static methods, though. Nor for methods >> > where "this" is live to the end, but the parameter slots are >> > reused. >> >> and you can have a path with a store_0 and one without (the code is not >> linear). >> >> > >> > For obfuscated methods I would claim that printing "this" etc >> > is fine even if the slot is reused for another value. It just >> > adds to the obfuscation! But there might be code >> > that is just optimized and not meant to be obfuscated. >> >> I've used obfuscation as an example, but there are also valid case to reuse >> slots >> likeit will consume less stack memory if you are using a very small device. >> >> > >> > Best regards, >> > Goetz. >> >> regards, >> R?mi >> >> > >> > >> > >> > >> > >> > >> >> >> >> R?mi >> >> >> >> ----- Mail original ----- >> >> > De: "Goetz Lindenmaier" >> >> > ?: "hotspot-runtime-dev" , >> >> "core-libs-dev" >> >> > Envoy?: Mardi 17 Septembre 2019 16:18:03 >> >> > Objet: RE: RFR (L, final): 8218626: Add detailed message to >> >> NullPointerException describing what is null. >> >> >> >> > @core-libs experts, I would appreciate comments on the changes >> >> > to NullPointerException.java, especially wrt. the Javadoc comment. >> >> > The change there is S. >> >> > >> >> > Best regards, >> >> > Goetz. >> >> > >> >> >> -----Original Message----- >> >> >> From: Lindenmaier, Goetz >> >> >> Sent: Dienstag, 10. September 2019 11:48 >> >> >> To: 'Hotspot dev runtime' ; >> >> Java Core >> >> >> Libs >> >> >> Subject: RFR (L, final): 8218626: Add detailed message to >> >> NullPointerException >> >> >> describing what is null. >> >> >> >> >> >> Hi, >> >> >> >> >> >> >> >> >> >> >> >> this is the implementation of JEP 358: Helpful NullPointerExceptions. >> >> >> >> >> >> >> >> >> >> >> >> The JEP is in status "Candidate". Coleen (many, many thanks!) ran >> >> >> >> >> >> it through the Oracle-internal processes. Now I please need final reviews >> >> >> >> >> >> for this change so that I can propose it to target jdk 14. >> >> >> >> >> >> >> >> >> >> >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8220715 >> >> >> >> >> >> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8218628 >> >> >> >> >> >> webrev: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg- >> >> NPE/16/ >> >> >> >> >> >> >> >> >> >> >> >> The change ran through a lot of testing, all jtreg and jck tests to name >> >> >> >> >> >> only some. The webrev points to patch >> >> >> >> >> >> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg- >> >> >> NPE/16/enable_NPE_message.patch >> >> >> >> >> >> that enables the change by default, which was useful for testing to >> >> >> >> >> >> assure the code is used in the tests. >> >> >> >> >> >> I just pushed the change to jdk/submit once more. >> >> >> >> >> >> >> >> >> >> >> >> Please review. >> >> >> >> >> >> >> >> >> >> >> >> Thanks! >> >> >> > > > > > > Goetz. From martinrb at google.com Mon Sep 23 17:43:18 2019 From: martinrb at google.com (Martin Buchholz) Date: Mon, 23 Sep 2019 10:43:18 -0700 Subject: RFR: jsr166 integration 2019-09 In-Reply-To: References: <517197737.1773850.1568278129180.JavaMail.zimbra@u-pem.fr> <738837959.2535658.1568387411851.JavaMail.zimbra@u-pem.fr> <16d7944e-4b61-7ed9-aeea-fca44e970016@cs.oswego.edu> <1150861893.2564720.1568393036106.JavaMail.zimbra@u-pem.fr> <1a4c7ebd-78bd-de5b-7053-cff63f13bdeb@oracle.com> Message-ID: We now have a fix-up integration that removes all the previously excluded tests from their exclude lists. https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html 8231031: runtime/ReservedStack/ReservedStackTest.java fails after jsr166 refresh https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/ReservedStackTest/index.html https://bugs.openjdk.java.net/browse/JDK-8231031 LockInfo objects now restored to their previous values (although David was looking at future improvements). 8231032: ThreadMXBean locking tests fail after JSR 166 refresh https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/wrong-blocker/index.html https://bugs.openjdk.java.net/browse/JDK-8231032 8231036: vmTestbase monitoring tests fail after JSR 166 refresh https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/SynchronizerLockingThreads/index.html https://bugs.openjdk.java.net/browse/JDK-8231036 From julia.boes at oracle.com Mon Sep 23 18:17:03 2019 From: julia.boes at oracle.com (Julia Boes) Date: Mon, 23 Sep 2019 19:17:03 +0100 Subject: RFR: 8231186: Replace html tag foo with javadoc tag {@code foo} in java.base In-Reply-To: <5631697e-2f7d-2d29-3606-1822a4141ba8@oracle.com> References: <733ed056-1606-0c75-feaf-cc3066e4f6eb@oracle.com> <297d817e-b0d9-2814-bb1c-80c6f67a7147@oracle.com> <67c75546-1683-9140-89b7-98f189839843@oracle.com> <454c636e-2c11-a14d-f33f-9d06f3fdae7b@oracle.com> <5631697e-2f7d-2d29-3606-1822a4141ba8@oracle.com> Message-ID: <5b08e362-ea09-442d-246f-6f2ccd1d709c@oracle.com> Hi Brent, I was able to generate a webrev without any missing sdiffs (using gawk instead of awk with webrev.ksh) and made the requested changes below. >> src/java.base/share/classes/java/util/ResourceBundle.java > > I believe the tag spanning L2801-2 can be changed: > > 2801????????? *

  • Special cases for Norwegian.? Both > Locale("no", "NO", > 2802????????? * "NY") and {@code Locale("nn", "NO")} represent > Norwegian > > Same at L2818-9: > > 2818????????? * Bokm?l "nb".? Except for the single case > Locale("no", > 2819????????? * "NO", "NY") (handled above), when an input > {@code Locale} > The copyright year is now updated where applicable. Updated webrev: http://cr.openjdk.java.net/~jboes/webrevs/8231186/webrev.03/ Regards, Julia From brent.christian at oracle.com Mon Sep 23 18:52:32 2019 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 23 Sep 2019 11:52:32 -0700 Subject: RFR: 8231186: Replace html tag foo with javadoc tag {@code foo} in java.base In-Reply-To: <5b08e362-ea09-442d-246f-6f2ccd1d709c@oracle.com> References: <733ed056-1606-0c75-feaf-cc3066e4f6eb@oracle.com> <297d817e-b0d9-2814-bb1c-80c6f67a7147@oracle.com> <67c75546-1683-9140-89b7-98f189839843@oracle.com> <454c636e-2c11-a14d-f33f-9d06f3fdae7b@oracle.com> <5631697e-2f7d-2d29-3606-1822a4141ba8@oracle.com> <5b08e362-ea09-442d-246f-6f2ccd1d709c@oracle.com> Message-ID: Looks good. -B On 9/23/19 11:17 AM, Julia Boes wrote: > Hi Brent, > > I was able to generate a webrev without any missing sdiffs (using gawk > instead of awk with webrev.ksh) and made the requested changes below. > >>> src/java.base/share/classes/java/util/ResourceBundle.java >> >> I believe the tag spanning L2801-2 can be changed: >> >> 2801????????? *
  • Special cases for Norwegian.? Both >> Locale("no", "NO", >> 2802????????? * "NY") and {@code Locale("nn", "NO")} represent >> Norwegian >> >> Same at L2818-9: >> >> 2818????????? * Bokm?l "nb".? Except for the single case >> Locale("no", >> 2819????????? * "NO", "NY") (handled above), when an input >> {@code Locale} >> > The copyright year is now updated where applicable. > > Updated webrev: > http://cr.openjdk.java.net/~jboes/webrevs/8231186/webrev.03/ > > > Regards, > > Julia > > From lance.andersen at oracle.com Mon Sep 23 18:58:50 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 23 Sep 2019 14:58:50 -0400 Subject: RFR: 8231186: Replace html tag foo with javadoc tag {@code foo} in java.base In-Reply-To: <5b08e362-ea09-442d-246f-6f2ccd1d709c@oracle.com> References: <733ed056-1606-0c75-feaf-cc3066e4f6eb@oracle.com> <297d817e-b0d9-2814-bb1c-80c6f67a7147@oracle.com> <67c75546-1683-9140-89b7-98f189839843@oracle.com> <454c636e-2c11-a14d-f33f-9d06f3fdae7b@oracle.com> <5631697e-2f7d-2d29-3606-1822a4141ba8@oracle.com> <5b08e362-ea09-442d-246f-6f2ccd1d709c@oracle.com> Message-ID: <4CD9EBD3-2A25-4B1B-AF4F-2C5A001D878D@oracle.com> Hi Julia, I made a quick pass and the changes seem OK > On Sep 23, 2019, at 2:17 PM, Julia Boes wrote: > > Hi Brent, > > I was able to generate a webrev without any missing sdiffs (using gawk instead of awk with webrev.ksh) and made the requested changes below. > >>> src/java.base/share/classes/java/util/ResourceBundle.java >> >> I believe the tag spanning L2801-2 can be changed: >> >> 2801 *
  • Special cases for Norwegian. Both Locale("no", "NO", >> 2802 * "NY") and {@code Locale("nn", "NO")} represent Norwegian >> >> Same at L2818-9: >> >> 2818 * Bokm?l "nb". Except for the single case Locale("no", >> 2819 * "NO", "NY") (handled above), when an input {@code Locale} >> > The copyright year is now updated where applicable. > > Updated webrev: http://cr.openjdk.java.net/~jboes/webrevs/8231186/webrev.03/ > > > 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 naoto.sato at oracle.com Mon Sep 23 20:45:51 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 23 Sep 2019 13:45:51 -0700 Subject: [14] RFR: 8230531: API Doc for CharsetEncoder.maxBytesPerChar() should be clearer about BOMs Message-ID: Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8230531 Relevant CSR (in draft) and proposed changeset are located at: [CSR]: https://bugs.openjdk.java.net/browse/JDK-8231319 [changeset]: https://cr.openjdk.java.net/~naoto/8230531/webrev.00/ The proposed spec change was discussed in a previous thread in this mail list [1] Naoto [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-September/062514.html From alexander.matveev at oracle.com Mon Sep 23 22:05:18 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Mon, 23 Sep 2019 15:05:18 -0700 Subject: RFR: JDK-8231279: Change install location for copyright file for Debian package In-Reply-To: References: <658dada7-d09e-d49c-b100-fed29db6ab3d@oracle.com> Message-ID: <10024540-fc09-42f5-4f21-89afa4284f6e@oracle.com> Hi Alexey, http://cr.openjdk.java.net/~asemenyuk/8231279/webrev.01/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebBundler.java.frames.html Maybe add new line between 41-42 and remove 43 to align import static with other static imports. Looks fine. Thanks, Alexander On 9/23/2019 4:49 AM, 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). > > Baseline for the fix is [3] patch. > > [1] https://bugs.openjdk.java.net/browse/JDK-8231279 > > [2] http://cr.openjdk.java.net/~asemenyuk/8231279/webrev.01/ > > [3] http://cr.openjdk.java.net/~asemenyuk/8231277/webrev.00/ > From alexey.semenyuk at oracle.com Mon Sep 23 22:08:53 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Mon, 23 Sep 2019 18:08:53 -0400 Subject: RFR: JDK-8231279: Change install location for copyright file for Debian package In-Reply-To: <10024540-fc09-42f5-4f21-89afa4284f6e@oracle.com> References: <658dada7-d09e-d49c-b100-fed29db6ab3d@oracle.com> <10024540-fc09-42f5-4f21-89afa4284f6e@oracle.com> Message-ID: <68806053-08f6-0660-0b7a-b1b98aab3fb3@oracle.com> On 9/23/2019 6:05 PM, Alexander Matveev wrote: > Hi Alexey, > > http://cr.openjdk.java.net/~asemenyuk/8231279/webrev.01/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebBundler.java.frames.html > > Maybe add new line between 41-42 and remove 43 to align import static > with other static imports. This is how Netbeans manages imports. I don't touch this part of the code, just click on "Fix Imports" menu item and magic happens :) - Alexey > > Looks fine. > > Thanks, > Alexander > > On 9/23/2019 4:49 AM, 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). >> >> Baseline for the fix is [3] patch. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8231279 >> >> [2] http://cr.openjdk.java.net/~asemenyuk/8231279/webrev.01/ >> >> [3] http://cr.openjdk.java.net/~asemenyuk/8231277/webrev.00/ >> > From mandy.chung at oracle.com Mon Sep 23 23:48:20 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 23 Sep 2019 16:48:20 -0700 Subject: RFR 8221623 : Add StackWalker micro benchmarks to jdk repo In-Reply-To: References: <1408b71b-bf20-eb45-376d-bcd8dc2d3e3d@oracle.com> Message-ID: On 9/19/19 12:08 PM, Brent Christian wrote: > Hi, Daniel > > http://cr.openjdk.java.net/~bchristi/8221623/webrev09-loggerPerThread/ > I think doing the measurement for one of these would be adequate. StackWalkBench.forEach_AllOpts StackWalkBench.forEach_DefaultOpts StackWalkBench.forEach_HiddenAndReflectFrames There are a couple of commented benchmarks. Should they be taken out? > Though really, since logging is no longer using Throwable to examine > the call stack, maybe it makes more sense to move the logging > benchmarks to their own file under: > > test/micro/org/openjdk/bench/java/util/logging/ That seems a good idea. Mandy From brent.christian at oracle.com Mon Sep 23 23:50:52 2019 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 23 Sep 2019 16:50:52 -0700 Subject: RFR 8221623 : Add StackWalker micro benchmarks to jdk repo In-Reply-To: <59efb0d6-ecf1-74dd-eebb-656c9fa1fb8d@oracle.com> References: <1408b71b-bf20-eb45-376d-bcd8dc2d3e3d@oracle.com> <59efb0d6-ecf1-74dd-eebb-656c9fa1fb8d@oracle.com> Message-ID: <74f0c62b-1164-1883-089f-47c3e5b6485c@oracle.com> On 9/23/19 2:15 AM, Daniel Fuchs wrote: >> ... >> since logging is no longer using Throwable to examine >> the call stack, maybe it makes more sense to move the logging >> benchmarks to their own file under: >> >> test/micro/org/openjdk/bench/java/util/logging/ > > Well, I'll let you decide on that. That would be the first > logging benchmark :-) There is 1 already: http://hg.openjdk.java.net/jdk/jdk/file/2dedeaa537a2/test/micro/org/openjdk/bench/java/util/logging/LogRecord.java I've moved my two logging benchmarks to that directory, too; I think it makes sense. Also, per the discussion with Claes, I've reduced the number of values in the 'depth' @Param. http://cr.openjdk.java.net/~bchristi/8221623/webrev10/ Thanks, -Brent From alexey.semenyuk at oracle.com Mon Sep 23 23:55:02 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Mon, 23 Sep 2019 19:55:02 -0400 Subject: RFR: JDK-8231282: Revisit --linux-deb-copyright option In-Reply-To: <658dada7-d09e-d49c-b100-fed29db6ab3d@oracle.com> References: <658dada7-d09e-d49c-b100-fed29db6ab3d@oracle.com> Message-ID: <8415f13f-2c13-bf32-c82a-640a9040b9a7@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: - remove --linux-deb-copyright option. - add tests to verify that placing copyright template in custom resource dir provides the same functionality as the use of --linux-deb-copyright option. - adjusted test helper classes to save from writing explicit code to rethrow checked exceptions as RuntimeException. Baseline for the fix is [3]. [1] https://bugs.openjdk.java.net/browse/JDK-8231277 [2] http://cr.openjdk.java.net/~asemenyuk/8231282/webrev.00/ [3] http://cr.openjdk.java.net/~asemenyuk/8231279/webrev.01/ From martinrb at google.com Tue Sep 24 00:37:26 2019 From: martinrb at google.com (Martin Buchholz) Date: Mon, 23 Sep 2019 17:37:26 -0700 Subject: [14] RFR: 8230531: API Doc for CharsetEncoder.maxBytesPerChar() should be clearer about BOMs In-Reply-To: References: Message-ID: LGTM On Mon, Sep 23, 2019 at 1:48 PM wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8230531 > > Relevant CSR (in draft) and proposed changeset are located at: > > [CSR]: https://bugs.openjdk.java.net/browse/JDK-8231319 > [changeset]: https://cr.openjdk.java.net/~naoto/8230531/webrev.00/ > > The proposed spec change was discussed in a previous thread in this mail > list [1] > > Naoto > > [1] > > https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-September/062514.html > From alexander.matveev at oracle.com Tue Sep 24 01:43:04 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Mon, 23 Sep 2019 18:43:04 -0700 Subject: RFR: JDK-8231282: Revisit --linux-deb-copyright option In-Reply-To: <8415f13f-2c13-bf32-c82a-640a9040b9a7@oracle.com> References: <658dada7-d09e-d49c-b100-fed29db6ab3d@oracle.com> <8415f13f-2c13-bf32-c82a-640a9040b9a7@oracle.com> Message-ID: <72fc4d6a-e8e3-8f6b-81af-32554967d4e1@oracle.com> Looks good. On 9/23/2019 4:55 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). > > This fix: > > - remove --linux-deb-copyright option. > - add tests to verify that placing copyright template in custom > resource dir provides the same functionality as the use of > --linux-deb-copyright option. > - adjusted test helper classes to save from writing explicit code to > rethrow checked exceptions as RuntimeException. > > Baseline for the fix is [3]. > > [1] https://bugs.openjdk.java.net/browse/JDK-8231277 > > [2] http://cr.openjdk.java.net/~asemenyuk/8231282/webrev.00/ > > [3] http://cr.openjdk.java.net/~asemenyuk/8231279/webrev.01/ From david.holmes at oracle.com Tue Sep 24 02:20:47 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 24 Sep 2019 12:20:47 +1000 Subject: RFR: jsr166 integration 2019-09 In-Reply-To: References: <517197737.1773850.1568278129180.JavaMail.zimbra@u-pem.fr> <738837959.2535658.1568387411851.JavaMail.zimbra@u-pem.fr> <16d7944e-4b61-7ed9-aeea-fca44e970016@cs.oswego.edu> <1150861893.2564720.1568393036106.JavaMail.zimbra@u-pem.fr> <1a4c7ebd-78bd-de5b-7053-cff63f13bdeb@oracle.com> Message-ID: <86366d20-1ae0-6694-4b41-ce21dfb8ddbb@oracle.com> Hi Martin, That all seems fine to me. Thanks, David On 24/09/2019 3:43 am, Martin Buchholz wrote: > We now have a fix-up integration that removes all the previously > excluded tests from their exclude lists. > > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html > > 8231031: runtime/ReservedStack/ReservedStackTest.java fails after jsr166 > refresh > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/ReservedStackTest/index.html > https://bugs.openjdk.java.net/browse/JDK-8231031 > > LockInfo objects now restored to their previous values (although David > was looking at future improvements). > > 8231032: ThreadMXBean locking tests fail after JSR 166 refresh > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/wrong-blocker/index.html > https://bugs.openjdk.java.net/browse/JDK-8231032 > > 8231036: vmTestbase monitoring tests fail after JSR 166 refresh > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/SynchronizerLockingThreads/index.html > https://bugs.openjdk.java.net/browse/JDK-8231036 From david.holmes at oracle.com Tue Sep 24 06:06:06 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 24 Sep 2019 16:06:06 +1000 Subject: RFR: jsr166 integration 2019-09 In-Reply-To: <86366d20-1ae0-6694-4b41-ce21dfb8ddbb@oracle.com> References: <517197737.1773850.1568278129180.JavaMail.zimbra@u-pem.fr> <738837959.2535658.1568387411851.JavaMail.zimbra@u-pem.fr> <16d7944e-4b61-7ed9-aeea-fca44e970016@cs.oswego.edu> <1150861893.2564720.1568393036106.JavaMail.zimbra@u-pem.fr> <1a4c7ebd-78bd-de5b-7053-cff63f13bdeb@oracle.com> <86366d20-1ae0-6694-4b41-ce21dfb8ddbb@oracle.com> Message-ID: Except when I run it through our test system ReservedStackTest is still failing :( I tested it initially when Fred proposed it and that went fine. It also passes for me locally on Linux. David On 24/09/2019 12:20 pm, David Holmes wrote: > Hi Martin, > > That all seems fine to me. > > Thanks, > David > > On 24/09/2019 3:43 am, Martin Buchholz wrote: >> We now have a fix-up integration that removes all the previously >> excluded tests from their exclude lists. >> >> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html >> >> >> 8231031: runtime/ReservedStack/ReservedStackTest.java fails after >> jsr166 refresh >> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/ReservedStackTest/index.html >> >> https://bugs.openjdk.java.net/browse/JDK-8231031 >> >> LockInfo objects now restored to their previous values (although David >> was looking at future improvements). >> >> 8231032: ThreadMXBean locking tests fail after JSR 166 refresh >> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/wrong-blocker/index.html >> >> https://bugs.openjdk.java.net/browse/JDK-8231032 >> >> 8231036: vmTestbase monitoring tests fail after JSR 166 refresh >> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/SynchronizerLockingThreads/index.html >> >> https://bugs.openjdk.java.net/browse/JDK-8231036 From goetz.lindenmaier at sap.com Tue Sep 24 08:06:54 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 24 Sep 2019 08:06:54 +0000 Subject: RFR (L, final): 8218626: Add detailed message to NullPointerException describing what is null. In-Reply-To: <2062332399.429540.1569254549560.JavaMail.zimbra@u-pem.fr> References: <563186416.1041616.1568757083163.JavaMail.zimbra@u-pem.fr> <1893074105.2191032.1568930433981.JavaMail.zimbra@u-pem.fr> <2062332399.429540.1569254549560.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Remi, thanks for the heads up, I incorporated it in the main webrev: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/19/ Best regards, Goetz. > -----Original Message----- > From: forax at univ-mlv.fr > Sent: Montag, 23. September 2019 18:02 > To: Lindenmaier, Goetz > Cc: hotspot-runtime-dev ; core-libs- > dev > Subject: Re: RFR (L, final): 8218626: Add detailed message to > NullPointerException describing what is null. > > ----- Mail original ----- > > De: "Goetz Lindenmaier" > > ?: "Remi Forax" > > Cc: "hotspot-runtime-dev" , "core- > libs-dev" > > Envoy?: Lundi 23 Septembre 2019 12:03:30 > > Objet: RE: RFR (L, final): 8218626: Add detailed message to > NullPointerException describing what is null. > > > Hi Remi, > > Hi Goetz, > > > > > what do you think about dealing with the problem like this: > > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/18- > obfuscation/ > > It's at the cost of one 64-bit field per bytecode in the analysis data. > > Also, if there is a real assignment to a parameter it's not named 'parameteri' > > after that any more. See the example in the test. > > > > yes, it's a nice approximation, having a method with more than 63/64 > parameters is rare. > > patch looks good, thumbs up ! > > > Best regards, > > Goetz. > > > > regards, > R?mi > > > > > > >> -----Original Message----- > >> From: forax at univ-mlv.fr > >> Sent: Freitag, 20. September 2019 00:01 > >> To: Lindenmaier, Goetz > >> Cc: hotspot-runtime-dev ; core- > libs- > >> dev > >> Subject: Re: RFR (L, final): 8218626: Add detailed message to > >> NullPointerException describing what is null. > >> > >> ----- Mail original ----- > >> > De: "Goetz Lindenmaier" > >> > ?: "Remi Forax" > >> > Cc: "hotspot-runtime-dev" , > "core- > >> libs-dev" > >> > Envoy?: Mercredi 18 Septembre 2019 09:37:36 > >> > Objet: RE: RFR (L, final): 8218626: Add detailed message to > >> NullPointerException describing what is null. > >> > >> > Hi Remi, > >> > >> Hi Goetz, > >> > >> > > >> >> in bytecodeUtils.cpp, in print_local_var(), > >> >> i believe that the code > >> >> if (!method->is_static() && (slot == 0)) { > >> >> os->print("this"); > >> >> } > >> >> ... > >> >> is only true if the bytecode is generated by javac and ecj, tools like > proguard > >> >> that tries to obfuscate the code will reuse the slot 0 once "this" is not > >> needed > >> >> anymore. > >> >> This is obviously also true for any other parameters, so in my opinion, > you > >> >> should not try to be too heroic here and always display "local%d". > >> > Yes, you are right. I assume the bytecode local slots are mapped 1:1 to > >> > the parameters and are not reused for other values. > >> > > >> >> The other solution is to propagate "this" and "parameter%d" during the > >> static > >> >> analysis, so "this" will become "local0" once a store_0 is seen. > >> > It would be possible to spot the place where "this" is first overwritten. > >> > For other parameters, this is not feasible, they are not read-only, so > >> > stores don't indicate obfuscation. > >> > >> Java is not the only language to run on the Java plateform so try to detect > >> "obfuscation" is again akind of shortcut. > >> > >> > > >> > I could mark the whole method as 'obfuscated' once I see a store_0, > >> > and then print "local" instead of "parameter" in all places. > >> > This does not work for static methods, though. Nor for methods > >> > where "this" is live to the end, but the parameter slots are > >> > reused. > >> > >> and you can have a path with a store_0 and one without (the code is not > >> linear). > >> > >> > > >> > For obfuscated methods I would claim that printing "this" etc > >> > is fine even if the slot is reused for another value. It just > >> > adds to the obfuscation! But there might be code > >> > that is just optimized and not meant to be obfuscated. > >> > >> I've used obfuscation as an example, but there are also valid case to reuse > >> slots > >> likeit will consume less stack memory if you are using a very small device. > >> > >> > > >> > Best regards, > >> > Goetz. > >> > >> regards, > >> R?mi > >> > >> > > >> > > >> > > >> > > >> > > >> > > >> >> > >> >> R?mi > >> >> > >> >> ----- Mail original ----- > >> >> > De: "Goetz Lindenmaier" > >> >> > ?: "hotspot-runtime-dev" , > >> >> "core-libs-dev" > >> >> > Envoy?: Mardi 17 Septembre 2019 16:18:03 > >> >> > Objet: RE: RFR (L, final): 8218626: Add detailed message to > >> >> NullPointerException describing what is null. > >> >> > >> >> > @core-libs experts, I would appreciate comments on the changes > >> >> > to NullPointerException.java, especially wrt. the Javadoc comment. > >> >> > The change there is S. > >> >> > > >> >> > Best regards, > >> >> > Goetz. > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: Lindenmaier, Goetz > >> >> >> Sent: Dienstag, 10. September 2019 11:48 > >> >> >> To: 'Hotspot dev runtime' ; > >> >> Java Core > >> >> >> Libs > >> >> >> Subject: RFR (L, final): 8218626: Add detailed message to > >> >> NullPointerException > >> >> >> describing what is null. > >> >> >> > >> >> >> Hi, > >> >> >> > >> >> >> > >> >> >> > >> >> >> this is the implementation of JEP 358: Helpful NullPointerExceptions. > >> >> >> > >> >> >> > >> >> >> > >> >> >> The JEP is in status "Candidate". Coleen (many, many thanks!) ran > >> >> >> > >> >> >> it through the Oracle-internal processes. Now I please need final > reviews > >> >> >> > >> >> >> for this change so that I can propose it to target jdk 14. > >> >> >> > >> >> >> > >> >> >> > >> >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8220715 > >> >> >> > >> >> >> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8218628 > >> >> >> > >> >> >> webrev: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg- > >> >> NPE/16/ > >> >> >> > >> >> >> > >> >> >> > >> >> >> The change ran through a lot of testing, all jtreg and jck tests to name > >> >> >> > >> >> >> only some. The webrev points to patch > >> >> >> > >> >> >> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg- > >> >> >> NPE/16/enable_NPE_message.patch > >> >> >> > >> >> >> that enables the change by default, which was useful for testing to > >> >> >> > >> >> >> assure the code is used in the tests. > >> >> >> > >> >> >> I just pushed the change to jdk/submit once more. > >> >> >> > >> >> >> > >> >> >> > >> >> >> Please review. > >> >> >> > >> >> >> > >> >> >> > >> >> >> Thanks! > >> >> >> > > > > > > > Goetz. From milan.mimica at gmail.com Tue Sep 24 08:12:13 2019 From: milan.mimica at gmail.com (Milan Mimica) Date: Tue, 24 Sep 2019 10:12:13 +0200 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> <87sgpblxns.fsf@oldenburg2.str.redhat.com> <7A46485C-E250-4E57-9FB0-B9D18CA70632@oracle.com> <60FD933F-51A5-4438-83AF-B3427CFDE60D@oracle.com> <8A9E3066-E6F6-4E65-BD02-DF0ACFF02FAD@oracle.com> <633A0CE3-C771-493B-89E3-7FA843C85183@oracle.com> <6b209e36-686f-7852-7fb8-3a0ef0e8423a@oracle.com> <4CAC6E8D-9198-4701-99C0-49901D72A396@oracle.com> <47acbb78-806f-2951-3b22-de6e7965f461@oracle.com> <275EC96C-CC39-41C8-9B9C-B917F25FAB70@oracle.com> <7D4375A7-E2CC-4297-92DF-A13FC9EF07AE@oracle.com> <81087256-819E-49FF-BB94-ADA9530717DD@oracle.com> Message-ID: Hi Pavel Wow, I find this awesome. I don't have a Windows machine to play with, but I think I may have found something. The difference is how Java_sun_nio_ch_Net_poll is implemented. On unix it uses poll(2), on Windows it uses select(2). Regarding timeouts, poll() has "wait at least" semantics and overruns by design[1], while select() on windows has "waits at most" semantics, or how they put it[2]: "specifies the maximum time that select should wait before returning.". It returns early by design! Is this a known thing? I don't think there is much one can do here. It probably makes no sense to loop it and wait for time remainder. Java's soTimeout does not specify[3] should it wait at least or at most the specified timeout, so it's fine I guess. Old, "plain" socket impl are not much different. If the above is correct, should I just add a tolerance for the lower bound? [1] http://man7.org/linux/man-pages/man2/poll.2.html [2] https://docs.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-select [3] https://docs.oracle.com/javase/9/docs/api/java/net/Socket.html#setSoTimeout-int- On Mon, 23 Sep 2019 at 16:15, Pavel Rappo wrote: > > Milan, > > I'm observing the latest version (.04) of this test failing quite frequently (4/100) on Windows (Windows Server 2012 R2 6.3 (amd64)) machines. The test passes fine on macOS and Linux. Here's the typical output I see in the logs: > > java.lang.RuntimeException: Query took 4997 ms. . Timeout value is 5000 > java.lang.RuntimeException: Query took 4999 ms. . Timeout value is 5000 > java.lang.RuntimeException: Query took 4995 ms. . Timeout value is 5000 > java.lang.RuntimeException: Query took 4998 ms. . Timeout value is 5000 > ... > > Now, there might be many reasons for that. One of which would be that the DnsClient code is buggy. The other reason would be that the accuracy guaranteed by Windows implementation of `read` is not what we would expect. Would you be able to investigate that? > > P.S. The good news is that the CSR has been approved: > > https://bugs.openjdk.java.net/browse/JDK-8230965 > > > On 23 Sep 2019, at 14:20, Milan Mimica wrote: > > > > Got it. Thanks Pavel! > > > > > > On Mon, 23 Sep 2019 at 13:37, Pavel Rappo wrote: > >> > >> Milan, > >> > >> How do you check which tests are run? That's what I see in the /test-support/jtreg_open_test_jdk_com_sun_jndi_dns_ConfigTests_TcpTimeout_java/com/sun/jndi/dns/ConfigTests/TcpTimeout.jtr file after I have run the test locally on my machine: > >> > >> ----------messages:(5/233)---------- > >> command: main TcpTimeout > >> reason: User specified action: run main TcpTimeout > >> Mode: othervm > >> Additional options from @modules: --add-modules java.base --add-exports java.base/sun.security.util=ALL-UNNAMED > >> elapsed time (seconds): 1.751 > >> > >> ... > >> > >> ----------messages:(5/313)---------- > >> command: main TcpTimeout -Dcom.sun.jndi.dns.timeout.initial=5000 > >> reason: User specified action: run main TcpTimeout -Dcom.sun.jndi.dns.timeout.initial=5000 > >> Mode: othervm > >> Additional options from @modules: --add-modules java.base --add-exports java.base/sun.security.util=ALL-UNNAMED > >> elapsed time (seconds): 5.498 > >> > >> ------------------------------------ > >> > >> Which is consistent with what I would expect given the timeout values. > >> > >> The following output does not tell the full story, just the name of the test: > >> > >> ============================== > >> Test summary > >> ============================== > >> TEST TOTAL PASS FAIL ERROR > >> jtreg:open/test/jdk/com/sun/jndi/dns/ConfigTests/TcpTimeout.java > >> 1 1 0 0 > >> ============================== > >> TEST SUCCESS > >> > >> -Pavel > >> > >>> On 20 Sep 2019, at 15:42, Milan Mimica wrote: > >>> > >>> Pavel, > >>> > >>> Here it is: http://cr.openjdk.java.net/~mmimica/8228580/webrev.04/ > >>> I don't see the test is run twice when I execute "make test > >>> TEST=jtreg:test/jdk/com/sun/jndi/dns/ConfigTests/TcpTimeout.java". Am > >>> I missing something? > >>> > > > > > > -- > > Milan Mimica > -- Milan Mimica From goetz.lindenmaier at sap.com Tue Sep 24 08:13:14 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 24 Sep 2019 08:13:14 +0000 Subject: RFR (L, final): 8218626: Add detailed message to NullPointerException describing what is null. In-Reply-To: <402d9260-8cde-194b-3638-283eddb8c6c9@oracle.com> References: <402d9260-8cde-194b-3638-283eddb8c6c9@oracle.com> Message-ID: Hi Roger, thanks for improving the text! Good point to add @implNote. This webrev includes the fixed comments: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/19/ Is it ok to add you as reviewer (for the java.base part)? Best regards, Goetz. > -----Original Message----- > From: Roger Riggs > Sent: Montag, 23. September 2019 17:30 > To: Lindenmaier, Goetz ; Hotspot dev runtime > ; Java Core Libs dev at openjdk.java.net> > Subject: Re: RFR (L, final): 8218626: Add detailed message to > NullPointerException describing what is null. > > Hi Goetz, > > A bit of wordsmithing on the javadoc of NullPointerException.getMessage > and separating out the implementation specific description to an @implNote > > > 75: > /** > * Returns the detail message string of this throwable. > *

    > * If a non-null message was supplied in a constructor it is returned. > * Otherwise, an implementation specific message or {@code null} is > returned. > * @ImplNote > * If no explicit message was passed to the constructor, and as > * long as certain internal information is available, a verbose > * description of the null reference is returned. > * The internal information is not available in deserialized > NullPointerExceptions. > * > * @return the detail message string, which may be {@code null}. > * > 94-97: The comment on the getExtendedNPEMessage should use the normal > /**... */ syntax. > > Thanks, Roger > > > > > On 9/17/19 10:18 AM, Lindenmaier, Goetz wrote: > > > @core-libs experts, I would appreciate comments on the changes > to NullPointerException.java, especially wrt. the Javadoc comment. > The change there is S. > > Best regards, > Goetz. > > > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Dienstag, 10. September 2019 11:48 > To: 'Hotspot dev runtime' dev at openjdk.java.net> ; Java > Core > Libs dev at openjdk.java.net> > Subject: RFR (L, final): 8218626: Add detailed message to > NullPointerException > describing what is null. > > Hi, > > > > this is the implementation of JEP 358: Helpful > NullPointerExceptions. > > > > The JEP is in status "Candidate". Coleen (many, many thanks!) > ran > > it through the Oracle-internal processes. Now I please need > final reviews > > for this change so that I can propose it to target jdk 14. > > > > JEP: https://bugs.openjdk.java.net/browse/JDK-8220715 > > Enhancement: https://bugs.openjdk.java.net/browse/JDK- > 8218628 > > webrev: http://cr.openjdk.java.net/~goetz/wr19/8218628- > exMsg-NPE/16/ > > > > The change ran through a lot of testing, all jtreg and jck tests to > name > > only some. The webrev points to patch > > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg- > NPE/16/enable_NPE_message.patch > > that enables the change by default, which was useful for > testing to > > assure the code is used in the tests. > > I just pushed the change to jdk/submit once more. > > > > Please review. > > > > Thanks! > > Goetz. > > > From julia.boes at oracle.com Tue Sep 24 09:50:55 2019 From: julia.boes at oracle.com (Julia Boes) Date: Tue, 24 Sep 2019 10:50:55 +0100 Subject: RFR: 8231186: Replace html tag foo with javadoc tag {@code foo} in java.base In-Reply-To: <4CD9EBD3-2A25-4B1B-AF4F-2C5A001D878D@oracle.com> References: <733ed056-1606-0c75-feaf-cc3066e4f6eb@oracle.com> <297d817e-b0d9-2814-bb1c-80c6f67a7147@oracle.com> <67c75546-1683-9140-89b7-98f189839843@oracle.com> <454c636e-2c11-a14d-f33f-9d06f3fdae7b@oracle.com> <5631697e-2f7d-2d29-3606-1822a4141ba8@oracle.com> <5b08e362-ea09-442d-246f-6f2ccd1d709c@oracle.com> <4CD9EBD3-2A25-4B1B-AF4F-2C5A001D878D@oracle.com> Message-ID: <3b149635-41e2-b083-ffd0-5d9aca579ef8@oracle.com> Hi, Thanks for the review, Lance and Brent! Changeset: http://cr.openjdk.java.net/~jboes/webrevs/8231186/webrev.04/ Regards, Julia On 23/09/2019 19:58, Lance Andersen wrote: > Hi Julia, > > I made a quick pass and the changes seem OK >> On Sep 23, 2019, at 2:17 PM, Julia Boes > > wrote: >> >> Hi Brent, >> >> I was able to generate a webrev without any missing sdiffs (using >> gawk instead of awk with webrev.ksh) and made the requested changes >> below. >> >>>> src/java.base/share/classes/java/util/ResourceBundle.java >>> >>> I believe the tag spanning L2801-2 can be changed: >>> >>> 2801????????? *

  • Special cases for Norwegian.? Both >>> Locale("no", "NO", >>> 2802????????? * "NY") and {@code Locale("nn", "NO")} >>> represent Norwegian >>> >>> Same at L2818-9: >>> >>> 2818????????? * Bokm?l "nb".? Except for the single case >>> Locale("no", >>> 2819????????? * "NO", "NY") (handled above), when an input >>> {@code Locale} >>> >> The copyright year is now updated where applicable. >> >> Updated webrev: >> http://cr.openjdk.java.net/~jboes/webrevs/8231186/webrev.03/ >> >> >> 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 pavel.rappo at oracle.com Tue Sep 24 10:51:05 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 24 Sep 2019 11:51:05 +0100 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> <87sgpblxns.fsf@oldenburg2.str.redhat.com> <7A46485C-E250-4E57-9FB0-B9D18CA70632@oracle.com> <60FD933F-51A5-4438-83AF-B3427CFDE60D@oracle.com> <8A9E3066-E6F6-4E65-BD02-DF0ACFF02FAD@oracle.com> <633A0CE3-C771-493B-89E3-7FA843C85183@oracle.com> <6b209e36-686f-7852-7fb8-3a0ef0e8423a@oracle.com> <4CAC6E8D-9198-4701-99C0-49901D72A396@oracle.com> <47acbb78-806f-2951-3b22-de6e7965f461@oracle.com> <275EC96C-CC39-41C8-9B9C-B917F25FAB70@oracle.com> <7D4375A7-E2CC-4297-92DF-A13FC9EF07AE@oracle.com> <81087256-819E-49FF-BB94-ADA9530717DD@oracle.com> Message-ID: <6C3441D7-C135-4002-9EB9-28E4C51458B7@oracle.com> Milan, Thanks for looking into this. I think you should ask a question on the expected timing semantics and guarantees on net-dev (with maybe a cc to nio-dev). As for our test. I agree with you that we should simply work a possibility of early returns into the check. ... /* The acceptable variation of early returns from timed socket operations. */ private static final long PREMATURE_RETURN = adjustTimeout(100); ... long elapsed = NANOSECONDS.toMillis(System.nanoTime() - startNanos); if (elapsed < timeout - PREMATURE_RETURN || elapsed > timeout + TOLERANCE) { String msg = String.format( "elapsed=%s, timeout=%s, TOLERANCE=%s, PREMATURE_RETURN=%s", timeout, timeout, TOLERANCE, PREMATURE_RETURN); throw new RuntimeException(msg); } ... Thoughts? -Pavel > On 24 Sep 2019, at 09:12, Milan Mimica wrote: > > Hi Pavel > > Wow, I find this awesome. I don't have a Windows machine to play with, > but I think I may have found something. > The difference is how Java_sun_nio_ch_Net_poll is implemented. On unix > it uses poll(2), on Windows it uses select(2). Regarding timeouts, > poll() has "wait at least" semantics and overruns by design[1], while > select() on windows has "waits at most" semantics, or how they put > it[2]: "specifies the maximum time that select should wait before > returning.". It returns early by design! Is this a known thing? I > don't think there is much one can do here. It probably makes no sense > to loop it and wait for time remainder. > Java's soTimeout does not specify[3] should it wait at least or at > most the specified timeout, so it's fine I guess. Old, "plain" socket > impl are not much different. > > If the above is correct, should I just add a tolerance for the lower bound? > > [1] http://man7.org/linux/man-pages/man2/poll.2.html > [2] https://docs.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-select > [3] https://docs.oracle.com/javase/9/docs/api/java/net/Socket.html#setSoTimeout-int- > > On Mon, 23 Sep 2019 at 16:15, Pavel Rappo wrote: >> >> Milan, >> >> I'm observing the latest version (.04) of this test failing quite frequently (4/100) on Windows (Windows Server 2012 R2 6.3 (amd64)) machines. The test passes fine on macOS and Linux. Here's the typical output I see in the logs: >> >> java.lang.RuntimeException: Query took 4997 ms. . Timeout value is 5000 >> java.lang.RuntimeException: Query took 4999 ms. . Timeout value is 5000 >> java.lang.RuntimeException: Query took 4995 ms. . Timeout value is 5000 >> java.lang.RuntimeException: Query took 4998 ms. . Timeout value is 5000 >> ... >> >> Now, there might be many reasons for that. One of which would be that the DnsClient code is buggy. The other reason would be that the accuracy guaranteed by Windows implementation of `read` is not what we would expect. Would you be able to investigate that? >> >> P.S. The good news is that the CSR has been approved: >> >> https://bugs.openjdk.java.net/browse/JDK-8230965 >> >>> On 23 Sep 2019, at 14:20, Milan Mimica wrote: >>> >>> Got it. Thanks Pavel! >>> >>> >>> On Mon, 23 Sep 2019 at 13:37, Pavel Rappo wrote: >>>> >>>> Milan, >>>> >>>> How do you check which tests are run? That's what I see in the /test-support/jtreg_open_test_jdk_com_sun_jndi_dns_ConfigTests_TcpTimeout_java/com/sun/jndi/dns/ConfigTests/TcpTimeout.jtr file after I have run the test locally on my machine: >>>> >>>> ----------messages:(5/233)---------- >>>> command: main TcpTimeout >>>> reason: User specified action: run main TcpTimeout >>>> Mode: othervm >>>> Additional options from @modules: --add-modules java.base --add-exports java.base/sun.security.util=ALL-UNNAMED >>>> elapsed time (seconds): 1.751 >>>> >>>> ... >>>> >>>> ----------messages:(5/313)---------- >>>> command: main TcpTimeout -Dcom.sun.jndi.dns.timeout.initial=5000 >>>> reason: User specified action: run main TcpTimeout -Dcom.sun.jndi.dns.timeout.initial=5000 >>>> Mode: othervm >>>> Additional options from @modules: --add-modules java.base --add-exports java.base/sun.security.util=ALL-UNNAMED >>>> elapsed time (seconds): 5.498 >>>> >>>> ------------------------------------ >>>> >>>> Which is consistent with what I would expect given the timeout values. >>>> >>>> The following output does not tell the full story, just the name of the test: >>>> >>>> ============================== >>>> Test summary >>>> ============================== >>>> TEST TOTAL PASS FAIL ERROR >>>> jtreg:open/test/jdk/com/sun/jndi/dns/ConfigTests/TcpTimeout.java >>>> 1 1 0 0 >>>> ============================== >>>> TEST SUCCESS >>>> >>>> -Pavel >>>> >>>>> On 20 Sep 2019, at 15:42, Milan Mimica wrote: >>>>> >>>>> Pavel, >>>>> >>>>> Here it is: http://cr.openjdk.java.net/~mmimica/8228580/webrev.04/ >>>>> I don't see the test is run twice when I execute "make test >>>>> TEST=jtreg:test/jdk/com/sun/jndi/dns/ConfigTests/TcpTimeout.java". Am >>>>> I missing something? >>>>> >>> >>> >>> -- >>> Milan Mimica >> > > > -- > Milan Mimica From ralf.schmelter at sap.com Tue Sep 24 11:14:36 2019 From: ralf.schmelter at sap.com (Schmelter, Ralf) Date: Tue, 24 Sep 2019 11:14:36 +0000 Subject: RFR (L, final): 8218626: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: Message-ID: Hi Goetz, just one thing: >> In NullPointerExceptionTest.java: > > > > It seems you don't have tests for invokeinterface or invokespecial calls to cause > > an NPE (e.g. by calling a null interface variable or a private non-static method > > of a null objects). > That is because the code is the same as for invokevirtual in all places in > bytecodeUtils.cpp. The test should not omit these two bytecodes because the current implementation is the same. This can change and it is not much additional code to add the two cases. Thanks and best regards, Goetz. From daniel.fuchs at oracle.com Tue Sep 24 12:00:55 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 24 Sep 2019 13:00:55 +0100 Subject: RFR: 8231186: Replace html tag foo with javadoc tag {@code foo} in java.base In-Reply-To: <3b149635-41e2-b083-ffd0-5d9aca579ef8@oracle.com> References: <733ed056-1606-0c75-feaf-cc3066e4f6eb@oracle.com> <297d817e-b0d9-2814-bb1c-80c6f67a7147@oracle.com> <67c75546-1683-9140-89b7-98f189839843@oracle.com> <454c636e-2c11-a14d-f33f-9d06f3fdae7b@oracle.com> <5631697e-2f7d-2d29-3606-1822a4141ba8@oracle.com> <5b08e362-ea09-442d-246f-6f2ccd1d709c@oracle.com> <4CD9EBD3-2A25-4B1B-AF4F-2C5A001D878D@oracle.com> <3b149635-41e2-b083-ffd0-5d9aca579ef8@oracle.com> Message-ID: <2a60e80a-177f-f458-cddb-759b2c1c7fa2@oracle.com> Thanks Julia! It's now pushed. best regards, -- daniel On 24/09/2019 10:50, Julia Boes wrote: > Hi, > > Thanks for the review, Lance and Brent! > > Changeset: http://cr.openjdk.java.net/~jboes/webrevs/8231186/webrev.04/ > > > Regards, > > Julia From milan.mimica at gmail.com Tue Sep 24 12:41:04 2019 From: milan.mimica at gmail.com (Milan Mimica) Date: Tue, 24 Sep 2019 14:41:04 +0200 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: <6C3441D7-C135-4002-9EB9-28E4C51458B7@oracle.com> References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> <87sgpblxns.fsf@oldenburg2.str.redhat.com> <7A46485C-E250-4E57-9FB0-B9D18CA70632@oracle.com> <60FD933F-51A5-4438-83AF-B3427CFDE60D@oracle.com> <8A9E3066-E6F6-4E65-BD02-DF0ACFF02FAD@oracle.com> <633A0CE3-C771-493B-89E3-7FA843C85183@oracle.com> <6b209e36-686f-7852-7fb8-3a0ef0e8423a@oracle.com> <4CAC6E8D-9198-4701-99C0-49901D72A396@oracle.com> <47acbb78-806f-2951-3b22-de6e7965f461@oracle.com> <275EC96C-CC39-41C8-9B9C-B917F25FAB70@oracle.com> <7D4375A7-E2CC-4297-92DF-A13FC9EF07AE@oracle.com> <81087256-819E-49FF-BB94-ADA9530717DD@oracle.com> <6C3441D7-C135-4002-9EB9-28E4C51458B7@oracle.com> Message-ID: Pavel, Deal. Handling early returns too: http://cr.openjdk.java.net/~mmimica/8228580/webrev.05/ I will ask there about socket timeout semantics. On Tue, 24 Sep 2019 at 12:51, Pavel Rappo wrote: > > Milan, > > Thanks for looking into this. I think you should ask a question on the expected timing semantics and guarantees on net-dev (with maybe a cc to nio-dev). > As for our test. I agree with you that we should simply work a possibility of early returns into the check. > > ... > > /* The acceptable variation of early returns from timed socket operations. */ > private static final long PREMATURE_RETURN = adjustTimeout(100); > > ... > > long elapsed = NANOSECONDS.toMillis(System.nanoTime() - startNanos); > if (elapsed < timeout - PREMATURE_RETURN || elapsed > timeout + TOLERANCE) { > String msg = String.format( > "elapsed=%s, timeout=%s, TOLERANCE=%s, PREMATURE_RETURN=%s", > timeout, timeout, TOLERANCE, PREMATURE_RETURN); > throw new RuntimeException(msg); > } > > ... > > Thoughts? > > -Pavel > > > On 24 Sep 2019, at 09:12, Milan Mimica wrote: > > > > Hi Pavel > > > > Wow, I find this awesome. I don't have a Windows machine to play with, > > but I think I may have found something. > > The difference is how Java_sun_nio_ch_Net_poll is implemented. On unix > > it uses poll(2), on Windows it uses select(2). Regarding timeouts, > > poll() has "wait at least" semantics and overruns by design[1], while > > select() on windows has "waits at most" semantics, or how they put > > it[2]: "specifies the maximum time that select should wait before > > returning.". It returns early by design! Is this a known thing? I > > don't think there is much one can do here. It probably makes no sense > > to loop it and wait for time remainder. > > Java's soTimeout does not specify[3] should it wait at least or at > > most the specified timeout, so it's fine I guess. Old, "plain" socket > > impl are not much different. > > > > If the above is correct, should I just add a tolerance for the lower bound? > > > > [1] http://man7.org/linux/man-pages/man2/poll.2.html > > [2] https://docs.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-select > > [3] https://docs.oracle.com/javase/9/docs/api/java/net/Socket.html#setSoTimeout-int- > > > > On Mon, 23 Sep 2019 at 16:15, Pavel Rappo wrote: > >> > >> Milan, > >> > >> I'm observing the latest version (.04) of this test failing quite frequently (4/100) on Windows (Windows Server 2012 R2 6.3 (amd64)) machines. The test passes fine on macOS and Linux. Here's the typical output I see in the logs: > >> > >> java.lang.RuntimeException: Query took 4997 ms. . Timeout value is 5000 > >> java.lang.RuntimeException: Query took 4999 ms. . Timeout value is 5000 > >> java.lang.RuntimeException: Query took 4995 ms. . Timeout value is 5000 > >> java.lang.RuntimeException: Query took 4998 ms. . Timeout value is 5000 > >> ... > >> > >> Now, there might be many reasons for that. One of which would be that the DnsClient code is buggy. The other reason would be that the accuracy guaranteed by Windows implementation of `read` is not what we would expect. Would you be able to investigate that? > >> > >> P.S. The good news is that the CSR has been approved: > >> > >> https://bugs.openjdk.java.net/browse/JDK-8230965 > >> > >>> On 23 Sep 2019, at 14:20, Milan Mimica wrote: > >>> > >>> Got it. Thanks Pavel! > >>> > >>> > >>> On Mon, 23 Sep 2019 at 13:37, Pavel Rappo wrote: > >>>> > >>>> Milan, > >>>> > >>>> How do you check which tests are run? That's what I see in the /test-support/jtreg_open_test_jdk_com_sun_jndi_dns_ConfigTests_TcpTimeout_java/com/sun/jndi/dns/ConfigTests/TcpTimeout.jtr file after I have run the test locally on my machine: > >>>> > >>>> ----------messages:(5/233)---------- > >>>> command: main TcpTimeout > >>>> reason: User specified action: run main TcpTimeout > >>>> Mode: othervm > >>>> Additional options from @modules: --add-modules java.base --add-exports java.base/sun.security.util=ALL-UNNAMED > >>>> elapsed time (seconds): 1.751 > >>>> > >>>> ... > >>>> > >>>> ----------messages:(5/313)---------- > >>>> command: main TcpTimeout -Dcom.sun.jndi.dns.timeout.initial=5000 > >>>> reason: User specified action: run main TcpTimeout -Dcom.sun.jndi.dns.timeout.initial=5000 > >>>> Mode: othervm > >>>> Additional options from @modules: --add-modules java.base --add-exports java.base/sun.security.util=ALL-UNNAMED > >>>> elapsed time (seconds): 5.498 > >>>> > >>>> ------------------------------------ > >>>> > >>>> Which is consistent with what I would expect given the timeout values. > >>>> > >>>> The following output does not tell the full story, just the name of the test: > >>>> > >>>> ============================== > >>>> Test summary > >>>> ============================== > >>>> TEST TOTAL PASS FAIL ERROR > >>>> jtreg:open/test/jdk/com/sun/jndi/dns/ConfigTests/TcpTimeout.java > >>>> 1 1 0 0 > >>>> ============================== > >>>> TEST SUCCESS > >>>> > >>>> -Pavel > >>>> > >>>>> On 20 Sep 2019, at 15:42, Milan Mimica wrote: > >>>>> > >>>>> Pavel, > >>>>> > >>>>> Here it is: http://cr.openjdk.java.net/~mmimica/8228580/webrev.04/ > >>>>> I don't see the test is run twice when I execute "make test > >>>>> TEST=jtreg:test/jdk/com/sun/jndi/dns/ConfigTests/TcpTimeout.java". Am > >>>>> I missing something? > >>>>> > >>> > >>> > >>> -- > >>> Milan Mimica > >> > > > > > > -- > > Milan Mimica > -- Milan Mimica From andy.herrick at oracle.com Tue Sep 24 12:46:07 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 24 Sep 2019 08:46:07 -0400 Subject: RFR: JDK-8230927 : Wrong arguments set for additional launchers Message-ID: <69e98608-2ce7-219b-f2e8-d5c67b7c6d44@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 applies when arguments or java-options are used in an add-launcher properties file. In these cases the arguments or java-options from the properties files should replace instead of being added to the same options used in the command line? for the main launcher. [1] https://bugs.openjdk.java.net/browse/JDK-8230927 [2] http://cr.openjdk.java.net/~herrick/8230927 /Andy From andy.herrick at oracle.com Tue Sep 24 12:54:14 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 24 Sep 2019 08:54:14 -0400 Subject: RFR: JDK-8230920 : jpackage problems when -input dir contains any files with "cfg" extension. 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 fix replaces the practice we were using on windows to determine the application name, and name of additional launchers (by looking for ".cfg" files in the app dir. Instead we now add a file ".jpackage.args" to the root of the app-image, and record in that file all the arguments used to create the app-image.? We later read that file to determine the original app name and any additional launcher names. This change also fixes the shortcut creation on windows to create shortcuts (if so directed) for all launchers. [1] https://bugs.openjdk.java.net/browse/JDK-8230920 [2] http://cr.openjdk.java.net/~herrick/8230920/webrev.01/ /Andy From alexey.semenyuk at oracle.com Tue Sep 24 13:19:46 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Tue, 24 Sep 2019 09:19:46 -0400 Subject: RFR: JDK-8230927 : Wrong arguments set for additional launchers In-Reply-To: <69e98608-2ce7-219b-f2e8-d5c67b7c6d44@oracle.com> References: <69e98608-2ce7-219b-f2e8-d5c67b7c6d44@oracle.com> Message-ID: Andy, Please remove javadoc update about `--linux-deb-copyright-file` option. It will be dropped in https://bugs.openjdk.java.net/browse/JDK-8231277 patch. Line 180: --- if (additional.containsKey("java-optiions")) { --- Looks like a typo. Should be "java-options", not "java-optiions", I guess. We probably need a test or at least a follow up CR to track the task of adding a test for "java-options" parameter in additional launchers. - Alexey On 9/24/2019 8:46 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 change applies when arguments or java-options are used in an > add-launcher properties file. > > In these cases the arguments or java-options from the properties files > should replace instead of being added to the same options used in the > command line? for the main launcher. > > [1] https://bugs.openjdk.java.net/browse/JDK-8230927 > > [2] http://cr.openjdk.java.net/~herrick/8230927 > > /Andy > From Roger.Riggs at oracle.com Tue Sep 24 13:54:01 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 24 Sep 2019 09:54:01 -0400 Subject: RFR (L, final): 8218626: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: <402d9260-8cde-194b-3638-283eddb8c6c9@oracle.com> Message-ID: <304e5954-608b-2957-e3cd-236daf5d37b3@oracle.com> Hi Goetz, Looks good. Count me as a (java) Reviewer. Thanks, Roger On 9/24/19 4:13 AM, Lindenmaier, Goetz wrote: > Hi Roger, > > thanks for improving the text! Good point to add > @implNote. > This webrev includes the fixed comments: > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/19/ > Is it ok to add you as reviewer (for the java.base part)? > > Best regards, > Goetz. > > >> -----Original Message----- >> From: Roger Riggs >> Sent: Montag, 23. September 2019 17:30 >> To: Lindenmaier, Goetz ; Hotspot dev runtime >> ; Java Core Libs > dev at openjdk.java.net> >> Subject: Re: RFR (L, final): 8218626: Add detailed message to >> NullPointerException describing what is null. >> >> Hi Goetz, >> >> A bit of wordsmithing on the javadoc of NullPointerException.getMessage >> and separating out the implementation specific description to an @implNote >> >> >> 75: >> /** >> * Returns the detail message string of this throwable. >> *

    >> * If a non-null message was supplied in a constructor it is returned. >> * Otherwise, an implementation specific message or {@code null} is >> returned. >> * @ImplNote >> * If no explicit message was passed to the constructor, and as >> * long as certain internal information is available, a verbose >> * description of the null reference is returned. >> * The internal information is not available in deserialized >> NullPointerExceptions. >> * >> * @return the detail message string, which may be {@code null}. >> * >> 94-97: The comment on the getExtendedNPEMessage should use the normal >> /**... */ syntax. >> >> Thanks, Roger >> >> >> >> >> On 9/17/19 10:18 AM, Lindenmaier, Goetz wrote: >> >> >> @core-libs experts, I would appreciate comments on the changes >> to NullPointerException.java, especially wrt. the Javadoc comment. >> The change there is S. >> >> Best regards, >> Goetz. >> >> >> -----Original Message----- >> From: Lindenmaier, Goetz >> Sent: Dienstag, 10. September 2019 11:48 >> To: 'Hotspot dev runtime' > dev at openjdk.java.net> ; Java >> Core >> Libs > dev at openjdk.java.net> >> Subject: RFR (L, final): 8218626: Add detailed message to >> NullPointerException >> describing what is null. >> >> Hi, >> >> >> >> this is the implementation of JEP 358: Helpful >> NullPointerExceptions. >> >> >> >> The JEP is in status "Candidate". Coleen (many, many thanks!) >> ran >> >> it through the Oracle-internal processes. Now I please need >> final reviews >> >> for this change so that I can propose it to target jdk 14. >> >> >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8220715 >> >> Enhancement: https://bugs.openjdk.java.net/browse/JDK- >> 8218628 >> >> webrev: http://cr.openjdk.java.net/~goetz/wr19/8218628- >> exMsg-NPE/16/ >> >> >> >> The change ran through a lot of testing, all jtreg and jck tests to >> name >> >> only some. The webrev points to patch >> >> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg- >> NPE/16/enable_NPE_message.patch >> >> that enables the change by default, which was useful for >> testing to >> >> assure the code is used in the tests. >> >> I just pushed the change to jdk/submit once more. >> >> >> >> Please review. >> >> >> >> Thanks! >> >> Goetz. >> >> >> From andy.herrick at oracle.com Tue Sep 24 14:06:29 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 24 Sep 2019 10:06:29 -0400 Subject: RFR: JDK-8231282: Revisit --linux-deb-copyright option In-Reply-To: <8415f13f-2c13-bf32-c82a-640a9040b9a7@oracle.com> References: <658dada7-d09e-d49c-b100-fed29db6ab3d@oracle.com> <8415f13f-2c13-bf32-c82a-640a9040b9a7@oracle.com> Message-ID: <66c5e11f-50ce-801d-2c5d-cab56bd0399a@oracle.com> looks good /Andy On 9/23/2019 7:55 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). > > This fix: > > - remove --linux-deb-copyright option. > - add tests to verify that placing copyright template in custom > resource dir provides the same functionality as the use of > --linux-deb-copyright option. > - adjusted test helper classes to save from writing explicit code to > rethrow checked exceptions as RuntimeException. > > Baseline for the fix is [3]. > > [1] https://bugs.openjdk.java.net/browse/JDK-8231277 > > [2] http://cr.openjdk.java.net/~asemenyuk/8231282/webrev.00/ > > [3] http://cr.openjdk.java.net/~asemenyuk/8231279/webrev.01/ From andy.herrick at oracle.com Tue Sep 24 14:39:41 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 24 Sep 2019 10:39:41 -0400 Subject: RFR: JDK-8231277: Adjust Linux application image layout In-Reply-To: <658dada7-d09e-d49c-b100-fed29db6ab3d@oracle.com> References: <5f7e9cc8-9698-f7a5-dc1a-3cb3a2ddf30a@oracle.com> <658dada7-d09e-d49c-b100-fed29db6ab3d@oracle.com> Message-ID: <04828059-50ce-e78c-afef-715b8ea1f7f9@oracle.com> Looks good. /Andy On 9/20/19 7:57 AM, 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). > > This fix: > > - directory layout of Linux app image adjusted to better comply with > Linux FSH. > - some unused code clean up. > - added support to run JUnit4 tests along with the standard jtreg tests. > - DeployParamsTest.java jtreg test converted into JUnit test. > - unit tests added. > > Baseline for the fix is > http://cr.openjdk.java.net/~asemenyuk/8225249/webrev.02/ patch. > > [1] https://bugs.openjdk.java.net/browse/JDK-8231277 > > [2] http://cr.openjdk.java.net/~asemenyuk/8231277/webrev.00/ > From goetz.lindenmaier at sap.com Tue Sep 24 14:47:38 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 24 Sep 2019 14:47:38 +0000 Subject: RFR (L, final): 8218626: Add detailed message to NullPointerException describing what is null. In-Reply-To: <304e5954-608b-2957-e3cd-236daf5d37b3@oracle.com> References: <402d9260-8cde-194b-3638-283eddb8c6c9@oracle.com> <304e5954-608b-2957-e3cd-236daf5d37b3@oracle.com> Message-ID: Thanks! Best regards, Goetz > -----Original Message----- > From: Roger Riggs > Sent: Dienstag, 24. September 2019 15:54 > To: Lindenmaier, Goetz ; Hotspot dev runtime > ; Java Core Libs dev at openjdk.java.net> > Subject: Re: RFR (L, final): 8218626: Add detailed message to > NullPointerException describing what is null. > > Hi Goetz, > > Looks good. > Count me as a (java) Reviewer. > > Thanks, Roger > > > On 9/24/19 4:13 AM, Lindenmaier, Goetz wrote: > > > Hi Roger, > > thanks for improving the text! Good point to add > @implNote. > This webrev includes the fixed comments: > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/19/ > Is it ok to add you as reviewer (for the java.base part)? > > Best regards, > Goetz. > > > > -----Original Message----- > From: Roger Riggs > > Sent: Montag, 23. September 2019 17:30 > To: Lindenmaier, Goetz > ; Hotspot dev runtime > runtime-dev at openjdk.java.net> ; Java Core Libs dev at openjdk.java.net > > Subject: Re: RFR (L, final): 8218626: Add detailed message to > NullPointerException describing what is null. > > Hi Goetz, > > A bit of wordsmithing on the javadoc of > NullPointerException.getMessage > and separating out the implementation specific description to > an @implNote > > > 75: > /** > * Returns the detail message string of this throwable. > *

    > * If a non-null message was supplied in a constructor it is > returned. > * Otherwise, an implementation specific message or {@code > null} is > returned. > * @ImplNote > * If no explicit message was passed to the constructor, and > as > * long as certain internal information is available, a verbose > * description of the null reference is returned. > * The internal information is not available in deserialized > NullPointerExceptions. > * > * @return the detail message string, which may be {@code > null}. > * > 94-97: The comment on the getExtendedNPEMessage should > use the normal > /**... */ syntax. > > Thanks, Roger > > > > > On 9/17/19 10:18 AM, Lindenmaier, Goetz wrote: > > > @core-libs experts, I would appreciate comments on > the changes > to NullPointerException.java, especially wrt. the > Javadoc comment. > The change there is S. > > Best regards, > Goetz. > > > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Dienstag, 10. September 2019 11:48 > To: 'Hotspot dev runtime' dev at openjdk.java.net > > dev at openjdk.java.net> ; Java > Core > Libs > dev at openjdk.java.net> dev at openjdk.java.net> > Subject: RFR (L, final): 8218626: Add detailed > message to > NullPointerException > describing what is null. > > Hi, > > > > this is the implementation of JEP 358: Helpful > NullPointerExceptions. > > > > The JEP is in status "Candidate". Coleen (many, > many thanks!) > ran > > it through the Oracle-internal processes. Now I > please need > final reviews > > for this change so that I can propose it to > target jdk 14. > > > > JEP: > https://bugs.openjdk.java.net/browse/JDK-8220715 > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK- > 8218628 > > webrev: > http://cr.openjdk.java.net/~goetz/wr19/8218628- > exMsg-NPE/16/ > > > > The change ran through a lot of testing, all > jtreg and jck tests to > name > > only some. The webrev points to patch > > > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg- > NPE/16/enable_NPE_message.patch > > that enables the change by default, which was > useful for > testing to > > assure the code is used in the tests. > > I just pushed the change to jdk/submit once > more. > > > > Please review. > > > > Thanks! > > Goetz. > > > > > > From Alan.Bateman at oracle.com Tue Sep 24 15:04:55 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 24 Sep 2019 16:04:55 +0100 Subject: Thread.suspend/resume - any reason not to deprecate forRemoval=true Message-ID: <796b2fd7-44aa-ac27-e297-655e4cb87758@oracle.com> Thread.suspend/resume (and the corresponding methods in ThreadGroup) have been deprecated since 1.2 (1998). I haven't see anything use these methods in many years. Would anyone care if their deprecation is changed to forRemoval=true with a view to really removing them in the future? Just to clear, I'm only asking about the Thread/ThreadGroups APIs, we have to keep suspend/resume support in the debugger and tool APIs. -Alan. From Alan.Bateman at oracle.com Tue Sep 24 15:26:54 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 24 Sep 2019 16:26:54 +0100 Subject: [14] RFR: 8230531: API Doc for CharsetEncoder.maxBytesPerChar() should be clearer about BOMs In-Reply-To: References: Message-ID: <6d5f172f-d425-344a-87bf-6dcb5893cd38@oracle.com> On 23/09/2019 21:45, naoto.sato at oracle.com wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8230531 > > Relevant CSR (in draft) and proposed changeset are located at: > > [CSR]: https://bugs.openjdk.java.net/browse/JDK-8231319 > [changeset]: https://cr.openjdk.java.net/~naoto/8230531/webrev.00/ Looks good. -Alan From mark.reinhold at oracle.com Tue Sep 24 16:46:35 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 24 Sep 2019 09:46:35 -0700 Subject: Thread.suspend/resume - any reason not to deprecate forRemoval=true In-Reply-To: <796b2fd7-44aa-ac27-e297-655e4cb87758@oracle.com> References: <796b2fd7-44aa-ac27-e297-655e4cb87758@oracle.com> Message-ID: <20190924094635.324972962@eggemoggin.niobe.net> 2019/9/24 8:04:55 -0700, alan.bateman at oracle.com: > Thread.suspend/resume (and the corresponding methods in ThreadGroup) > have been deprecated since 1.2 (1998). I haven't see anything use these > methods in many years. Would anyone care if their deprecation is changed > to forRemoval=true with a view to really removing them in the future? > Just to clear, I'm only asking about the Thread/ThreadGroups APIs, we > have to keep suspend/resume support in the debugger and tool APIs. Go for it! - Mark From andy.herrick at oracle.com Tue Sep 24 17:24:59 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 24 Sep 2019 13:24:59 -0400 Subject: RFR: JDK-8230927 : Wrong arguments set for additional launchers In-Reply-To: References: <69e98608-2ce7-219b-f2e8-d5c67b7c6d44@oracle.com> Message-ID: <550955c7-45eb-7e5d-3796-83d407cb63eb@oracle.com> Revision 2 or the webrev ( [3] )? removes the comment about `--linux-deb-copyright-file` option., replaces the literal strings with the CLIOptions id's, and adds unit test to AddLauncherTest.java [3] http://cr.openjdk.java.net/~herrick/8230927/webrev.02/ /Andy On 9/24/2019 9:19 AM, Alexey Semenyuk wrote: > Andy, > > Please remove javadoc update about `--linux-deb-copyright-file` > option. It will be dropped in > https://bugs.openjdk.java.net/browse/JDK-8231277 patch. > Line 180: > --- > if (additional.containsKey("java-optiions")) { > --- > Looks like a typo. Should be "java-options", not "java-optiions", I > guess. > We probably need a test or at least a follow up CR to track the task > of adding a test for "java-options" parameter in additional launchers. > > - Alexey > > On 9/24/2019 8:46 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 change applies when arguments or java-options are used in an >> add-launcher properties file. >> >> In these cases the arguments or java-options from the properties >> files should replace instead of being added to the same options used >> in the command line? for the main launcher. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8230927 >> >> [2] http://cr.openjdk.java.net/~herrick/8230927 >> >> /Andy >> > From alexey.semenyuk at oracle.com Tue Sep 24 18:08:54 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Tue, 24 Sep 2019 14:08:54 -0400 Subject: RFR: JDK-8230927 : Wrong arguments set for additional launchers In-Reply-To: <550955c7-45eb-7e5d-3796-83d407cb63eb@oracle.com> References: <69e98608-2ce7-219b-f2e8-d5c67b7c6d44@oracle.com> <550955c7-45eb-7e5d-3796-83d407cb63eb@oracle.com> Message-ID: Looks good. - Alexey On 9/24/2019 1:24 PM, Andy Herrick wrote: > Revision 2 or the webrev ( [3] )? removes the comment about > `--linux-deb-copyright-file` option., replaces the literal strings > with the CLIOptions id's, and adds unit test to AddLauncherTest.java > > [3] http://cr.openjdk.java.net/~herrick/8230927/webrev.02/ > > /Andy > > On 9/24/2019 9:19 AM, Alexey Semenyuk wrote: >> Andy, >> >> Please remove javadoc update about `--linux-deb-copyright-file` >> option. It will be dropped in >> https://bugs.openjdk.java.net/browse/JDK-8231277 patch. >> Line 180: >> --- >> if (additional.containsKey("java-optiions")) { >> --- >> Looks like a typo. Should be "java-options", not "java-optiions", I >> guess. >> We probably need a test or at least a follow up CR to track the task >> of adding a test for "java-options" parameter in additional launchers. >> >> - Alexey >> >> On 9/24/2019 8:46 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 change applies when arguments or java-options are used in an >>> add-launcher properties file. >>> >>> In these cases the arguments or java-options from the properties >>> files should replace instead of being added to the same options used >>> in the command line? for the main launcher. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8230927 >>> >>> [2] http://cr.openjdk.java.net/~herrick/8230927 >>> >>> /Andy >>> >> From chris.hegarty at oracle.com Tue Sep 24 18:29:30 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 24 Sep 2019 19:29:30 +0100 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> <87sgpblxns.fsf@oldenburg2.str.redhat.com> <7A46485C-E250-4E57-9FB0-B9D18CA70632@oracle.com> <60FD933F-51A5-4438-83AF-B3427CFDE60D@oracle.com> <8A9E3066-E6F6-4E65-BD02-DF0ACFF02FAD@oracle.com> <633A0CE3-C771-493B-89E3-7FA843C85183@oracle.com> <6b209e36-686f-7852-7fb8-3a0ef0e8423a@oracle.com> <4CAC6E8D-9198-4701-99C0-49901D72A396@oracle.com! > <47acbb78-806f-2951-3b22-de6e7965f461@oracle.com> <275EC96C-CC39-41C8-9B9C-B917F25FAB70@oracle.com> <7D4375A7-E2CC-4297-92DF-A13FC9EF07AE@oracle.com> <81087256-819E-49FF-BB94-ADA9530717DD@oracle.com> <6C3441D7-C135-4002-9EB9-28E4C51458B7@oracle.com> Message-ID: <0B4FCAB1-EEE6-4862-978A-9FB028936310@oracle.com> > On 24 Sep 2019, at 13:41, Milan Mimica wrote: > > Pavel, > > Deal. Handling early returns too: > http://cr.openjdk.java.net/~mmimica/8228580/webrev.05/ LGTM -Chris From Ulf.Zibis at CoSoCo.de Tue Sep 24 20:00:21 2019 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Tue, 24 Sep 2019 22:00:21 +0200 Subject: CharsetEncoder.maxBytesPerChar() In-Reply-To: <20190920150339.254128936@eggemoggin.niobe.net> References: <07109047-3a9b-c784-4fa8-86616a3bc263@oracle.com> <20190920150339.254128936@eggemoggin.niobe.net> Message-ID: <5336b4de-cd28-c66b-963a-c5f63c8cb807@CoSoCo.de> Am 21.09.19 um 00:03 schrieb mark.reinhold at oracle.com: > To avoid this confusion, a more verbose specification might read: > * Returns the maximum number of $otype$s that will be produced for each > * $itype$ of input. This value may be used to compute the worst-case size > * of the output buffer required for a given input sequence. This value > * accounts for any necessary content-independent prefix or suffix > #if[encoder] > * $otype$s, such as byte-order marks. > #end[encoder] > #if[decoder] > * $otype$s. > #end[decoder] > > (The example of byte-order marks applies only to CharsetEncoders, so > I?ve conditionalized that text for Charset-X-Coder.java.template.) Hi, wouldn't it be more clear to use "char" or even "{@code char}" instead "character" as replacment for the $xtype$ parameters? -Ulf From brent.christian at oracle.com Tue Sep 24 20:01:26 2019 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 24 Sep 2019 13:01:26 -0700 Subject: RFR 8221623 : Add StackWalker micro benchmarks to jdk repo In-Reply-To: References: <1408b71b-bf20-eb45-376d-bcd8dc2d3e3d@oracle.com> Message-ID: <7f28c973-01d0-59a2-435c-eea842b2878d@oracle.com> On 9/23/19 4:48 PM, Mandy Chung wrote: > > I think doing the measurement for one of these would be adequate. > > StackWalkBench.forEach_AllOpts > StackWalkBench.forEach_DefaultOpts > StackWalkBench.forEach_HiddenAndReflectFrames OK, reduced to just DefaultOpts. > There are a couple of commented benchmarks. Should they be taken out? Sure; testGoThereBH() was from some early experimenting and is not needed - removed. The getCallerClass() tests in ThrowableRuntimeMicros served as a reminder that they need updating, but having JDK-8230976 filed is sufficient. IMO, it would be nice to have the PerfCounter example in StackWalkBench ready-to-uncomment, in case it's needed again sometime. >> Though really, since logging is no longer using Throwable to examine >> the call stack, maybe it makes more sense to move the logging >> benchmarks to their own file under: >> >> test/micro/org/openjdk/bench/java/util/logging/ > > That seems a good idea. Yes, those are moved. http://cr.openjdk.java.net/~bchristi/8221623/webrev11/ Thanks, -Brent From mandy.chung at oracle.com Tue Sep 24 20:13:50 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 24 Sep 2019 13:13:50 -0700 Subject: RFR 8221623 : Add StackWalker micro benchmarks to jdk repo In-Reply-To: <7f28c973-01d0-59a2-435c-eea842b2878d@oracle.com> References: <1408b71b-bf20-eb45-376d-bcd8dc2d3e3d@oracle.com> <7f28c973-01d0-59a2-435c-eea842b2878d@oracle.com> Message-ID: <5cb8d430-c7ce-9005-b625-fdc3d78500a9@oracle.com> On 9/24/19 1:01 PM, Brent Christian wrote: > http://cr.openjdk.java.net/~bchristi/8221623/webrev11/ Looks okay.? Thanks for doing this. Mandy From raffaello.giulietti at gmail.com Tue Sep 24 21:24:20 2019 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Tue, 24 Sep 2019 23:24:20 +0200 Subject: Why you want a better specification and a fast implementation of Double.toString(double) Message-ID: <6668f01c-8a93-8cc9-8622-59c725a64dbe@gmail.com> Hi, I'd like this community to help me pushing a new spec and the accompanying implementation of Double.toString(double) and Float.toString(float) into the OpenJDK 14 release. All material has already been submitted to this mailing list months ago [2] and passes tier 1 tests. Yet, there hasn't been much discussion or progress. I understand that everybody is busy with many other big and small issues, duties and enhancements. But while my sponsor Brian Burkhalter started to look at it, he can't do everything alone, so I'm still looking for reviewers interested in the subject. I would also be much interested in tactics, strategies and techniques to accelerate the review and approval process. Languishing here and waiting for good souls is not a nice position to be ;-) Greetings Raffaello ---- Q: Why a new implementation? What's wrong with the current one? A: The current one tries to adhere to the rather non-mathematical current spec and does so in a costly and buggy way. Not that the bugs produce patently wrong results, but they are annoying anyway. They can all be categorized under the "too many digits" kind of bug. Q: Isn't there a risk in replacing the current implementation with a new one? A: Every change in the OpenJDK bears potential risks. On the other hand, the proposed implementation has been extensively tested in all aspects, without troubles. The risks are related more to reliance on current (mis)behavior than to unnoticed bugs in the new implementation. Q: What are the cons of the new implementation? A: Technically, there are none known to me. As alluded above, the only disadvantage is that the new outcomes are sometimes different, and then for the better (shorter outputs). Code that relies on the exact current behavior can possibly break. For example, a test that expects Double.toString(2e23) to produce "1.9999999999999998E23", as currently done, rather than "2.0E23", as returned by the new implementation, will fail. Q: Can you list some of the pros of the new implementation? A: Two stand out: (1) on the average, a conversion is about 15x faster (around 90 ns on a 6 years old home-grade laptop) (2) no temporary objects are ever allocated Q: Why is there a need for another spec? A: Because the current one is rather unclear in its main goal. In addition, it intermingles the selection of a decimal to represent the floating-point number with its formatting, which adds to the unclarity. Q: What about the proposed spec. A: It clearly separates the rather simple, mathematical and 100% unambiguous selection of the decimal from the formatting aspects. Q: Which kind of help is needed? A: You can: (1) Take a look at the proposed spec [1] and send questions and comments to this mailing list. (2) Take a look at the overall structure of the implementation [2] (webrev is in [3]) and discuss it here, even without understanding the underlying algorithms. The focus could be on quality, conventions, etc. (3) Take a look at the accompanying paper [4] which presents all the nitty-gritty details and let me know if there's something unclear or wrong. (4) You can try out the code. It is now about 6 months old, meant for and tested on OpenJDK 13. I guess it will work on OpenJDK 14 as well, but I didn't try out as of today. Q: What is the investment in time? A: The spec can be read and understood in about 10-15 minutes. The paper needs 0.5-1.0 days, depending on your willingness to understand every detail. Once the paper has been worked out, however, the core of the implementation is straightforward to understand, say a couple of hours. ---- [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 From pavel.rappo at oracle.com Tue Sep 24 22:05:03 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 24 Sep 2019 23:05:03 +0100 Subject: RFR(s): 8228580: DnsClient TCP socket timeout In-Reply-To: References: <87tv9sm332.fsf@oldenburg2.str.redhat.com> <878sr4m05r.fsf@oldenburg2.str.redhat.com> <87zhjkkkuz.fsf@oldenburg2.str.redhat.com> <87sgpblxns.fsf@oldenburg2.str.redhat.com> <7A46485C-E250-4E57-9FB0-B9D18CA70632@oracle.com> <60FD933F-51A5-4438-83AF-B3427CFDE60D@oracle.com> <8A9E3066-E6F6-4E65-BD02-DF0ACFF02FAD@oracle.com> <633A0CE3-C771-493B-89E3-7FA843C85183@oracle.com> <6b209e36-686f-7852-7fb8-3a0ef0e8423a@oracle.com> <4CAC6E8D-9198-4701-99C0-49901D72A396@oracle.com> <47acbb78-806f-2951-3b22-de6e7965f461@oracle.com> <275EC96C-CC39-41C8-9B9C-B917F25FAB70@oracle.com> <7D4375A7-E2CC-4297-92DF-A13FC9EF07AE@oracle.com> <81087256-819E-49FF-BB94-ADA9530717DD@oracle.com> <6C3441D7-C135-4002-9EB9-28E4C51458B7@oracle.com> Message-ID: Milan, I satisfied myself by running the final version of the test some 8k times and then pushed the change. Thanks for your patience and persistence. I saw your question on the net-dev and nio-dev mailing lists. Thanks. -Pavel > On 24 Sep 2019, at 13:41, Milan Mimica wrote: > > Pavel, > > Deal. Handling early returns too: > http://cr.openjdk.java.net/~mmimica/8228580/webrev.05/ > I will ask there about socket timeout semantics. > > On Tue, 24 Sep 2019 at 12:51, Pavel Rappo wrote: >> >> Milan, >> >> Thanks for looking into this. I think you should ask a question on the expected timing semantics and guarantees on net-dev (with maybe a cc to nio-dev). >> As for our test. I agree with you that we should simply work a possibility of early returns into the check. >> >> ... >> >> /* The acceptable variation of early returns from timed socket operations. */ >> private static final long PREMATURE_RETURN = adjustTimeout(100); >> >> ... >> >> long elapsed = NANOSECONDS.toMillis(System.nanoTime() - startNanos); >> if (elapsed < timeout - PREMATURE_RETURN || elapsed > timeout + TOLERANCE) { >> String msg = String.format( >> "elapsed=%s, timeout=%s, TOLERANCE=%s, PREMATURE_RETURN=%s", >> timeout, timeout, TOLERANCE, PREMATURE_RETURN); >> throw new RuntimeException(msg); >> } >> >> ... >> >> Thoughts? >> >> -Pavel >> >>> On 24 Sep 2019, at 09:12, Milan Mimica wrote: >>> >>> Hi Pavel >>> >>> Wow, I find this awesome. I don't have a Windows machine to play with, >>> but I think I may have found something. >>> The difference is how Java_sun_nio_ch_Net_poll is implemented. On unix >>> it uses poll(2), on Windows it uses select(2). Regarding timeouts, >>> poll() has "wait at least" semantics and overruns by design[1], while >>> select() on windows has "waits at most" semantics, or how they put >>> it[2]: "specifies the maximum time that select should wait before >>> returning.". It returns early by design! Is this a known thing? I >>> don't think there is much one can do here. It probably makes no sense >>> to loop it and wait for time remainder. >>> Java's soTimeout does not specify[3] should it wait at least or at >>> most the specified timeout, so it's fine I guess. Old, "plain" socket >>> impl are not much different. >>> >>> If the above is correct, should I just add a tolerance for the lower bound? >>> >>> [1] http://man7.org/linux/man-pages/man2/poll.2.html >>> [2] https://docs.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-select >>> [3] https://docs.oracle.com/javase/9/docs/api/java/net/Socket.html#setSoTimeout-int- >>> >>> On Mon, 23 Sep 2019 at 16:15, Pavel Rappo wrote: >>>> >>>> Milan, >>>> >>>> I'm observing the latest version (.04) of this test failing quite frequently (4/100) on Windows (Windows Server 2012 R2 6.3 (amd64)) machines. The test passes fine on macOS and Linux. Here's the typical output I see in the logs: >>>> >>>> java.lang.RuntimeException: Query took 4997 ms. . Timeout value is 5000 >>>> java.lang.RuntimeException: Query took 4999 ms. . Timeout value is 5000 >>>> java.lang.RuntimeException: Query took 4995 ms. . Timeout value is 5000 >>>> java.lang.RuntimeException: Query took 4998 ms. . Timeout value is 5000 >>>> ... >>>> >>>> Now, there might be many reasons for that. One of which would be that the DnsClient code is buggy. The other reason would be that the accuracy guaranteed by Windows implementation of `read` is not what we would expect. Would you be able to investigate that? >>>> >>>> P.S. The good news is that the CSR has been approved: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8230965 >>>> >>>>> On 23 Sep 2019, at 14:20, Milan Mimica wrote: >>>>> >>>>> Got it. Thanks Pavel! >>>>> >>>>> >>>>> On Mon, 23 Sep 2019 at 13:37, Pavel Rappo wrote: >>>>>> >>>>>> Milan, >>>>>> >>>>>> How do you check which tests are run? That's what I see in the /test-support/jtreg_open_test_jdk_com_sun_jndi_dns_ConfigTests_TcpTimeout_java/com/sun/jndi/dns/ConfigTests/TcpTimeout.jtr file after I have run the test locally on my machine: >>>>>> >>>>>> ----------messages:(5/233)---------- >>>>>> command: main TcpTimeout >>>>>> reason: User specified action: run main TcpTimeout >>>>>> Mode: othervm >>>>>> Additional options from @modules: --add-modules java.base --add-exports java.base/sun.security.util=ALL-UNNAMED >>>>>> elapsed time (seconds): 1.751 >>>>>> >>>>>> ... >>>>>> >>>>>> ----------messages:(5/313)---------- >>>>>> command: main TcpTimeout -Dcom.sun.jndi.dns.timeout.initial=5000 >>>>>> reason: User specified action: run main TcpTimeout -Dcom.sun.jndi.dns.timeout.initial=5000 >>>>>> Mode: othervm >>>>>> Additional options from @modules: --add-modules java.base --add-exports java.base/sun.security.util=ALL-UNNAMED >>>>>> elapsed time (seconds): 5.498 >>>>>> >>>>>> ------------------------------------ >>>>>> >>>>>> Which is consistent with what I would expect given the timeout values. >>>>>> >>>>>> The following output does not tell the full story, just the name of the test: >>>>>> >>>>>> ============================== >>>>>> Test summary >>>>>> ============================== >>>>>> TEST TOTAL PASS FAIL ERROR >>>>>> jtreg:open/test/jdk/com/sun/jndi/dns/ConfigTests/TcpTimeout.java >>>>>> 1 1 0 0 >>>>>> ============================== >>>>>> TEST SUCCESS >>>>>> >>>>>> -Pavel >>>>>> >>>>>>> On 20 Sep 2019, at 15:42, Milan Mimica wrote: >>>>>>> >>>>>>> Pavel, >>>>>>> >>>>>>> Here it is: http://cr.openjdk.java.net/~mmimica/8228580/webrev.04/ >>>>>>> I don't see the test is run twice when I execute "make test >>>>>>> TEST=jtreg:test/jdk/com/sun/jndi/dns/ConfigTests/TcpTimeout.java". Am >>>>>>> I missing something? >>>>>>> >>>>> >>>>> >>>>> -- >>>>> Milan Mimica >>>> >>> >>> >>> -- >>> Milan Mimica >> > > > -- > Milan Mimica From martinrb at google.com Tue Sep 24 22:15:19 2019 From: martinrb at google.com (Martin Buchholz) Date: Tue, 24 Sep 2019 15:15:19 -0700 Subject: RFR: jsr166 integration 2019-09 In-Reply-To: References: <517197737.1773850.1568278129180.JavaMail.zimbra@u-pem.fr> <738837959.2535658.1568387411851.JavaMail.zimbra@u-pem.fr> <16d7944e-4b61-7ed9-aeea-fca44e970016@cs.oswego.edu> <1150861893.2564720.1568393036106.JavaMail.zimbra@u-pem.fr> <1a4c7ebd-78bd-de5b-7053-cff63f13bdeb@oracle.com> <86366d20-1ae0-6694-4b41-ce21dfb8ddbb@oracle.com> Message-ID: Frederic, could you figure out how to resolve 8231031: runtime/ReservedStack/ReservedStackTest.java fails after jsr166 refresh https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/ReservedStackTest/index.html https://bugs.openjdk.java.net/browse/JDK-8231031 On Mon, Sep 23, 2019 at 11:08 PM David Holmes wrote: > Except when I run it through our test system ReservedStackTest is still > failing :( > > I tested it initially when Fred proposed it and that went fine. It also > passes for me locally on Linux. > > David > > On 24/09/2019 12:20 pm, David Holmes wrote: > > Hi Martin, > > > > That all seems fine to me. > > > > Thanks, > > David > > > > On 24/09/2019 3:43 am, Martin Buchholz wrote: > >> We now have a fix-up integration that removes all the previously > >> excluded tests from their exclude lists. > >> > >> > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html > >> > >> > >> 8231031: runtime/ReservedStack/ReservedStackTest.java fails after > >> jsr166 refresh > >> > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/ReservedStackTest/index.html > >> > >> https://bugs.openjdk.java.net/browse/JDK-8231031 > >> > >> LockInfo objects now restored to their previous values (although David > >> was looking at future improvements). > >> > >> 8231032: ThreadMXBean locking tests fail after JSR 166 refresh > >> > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/wrong-blocker/index.html > >> > >> https://bugs.openjdk.java.net/browse/JDK-8231032 > >> > >> 8231036: vmTestbase monitoring tests fail after JSR 166 refresh > >> > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/SynchronizerLockingThreads/index.html > >> > >> https://bugs.openjdk.java.net/browse/JDK-8231036 > From alexander.matveev at oracle.com Tue Sep 24 22:22:02 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Tue, 24 Sep 2019 15:22:02 -0700 Subject: RFR: JDK-8230927 : Wrong arguments set for additional launchers In-Reply-To: References: <69e98608-2ce7-219b-f2e8-d5c67b7c6d44@oracle.com> <550955c7-45eb-7e5d-3796-83d407cb63eb@oracle.com> Message-ID: Looks good. On 9/24/2019 11:08 AM, Alexey Semenyuk wrote: > Looks good. > > - Alexey > > On 9/24/2019 1:24 PM, Andy Herrick wrote: >> Revision 2 or the webrev ( [3] )? removes the comment about >> `--linux-deb-copyright-file` option., replaces the literal strings >> with the CLIOptions id's, and adds unit test to AddLauncherTest.java >> >> [3] http://cr.openjdk.java.net/~herrick/8230927/webrev.02/ >> >> /Andy >> >> On 9/24/2019 9:19 AM, Alexey Semenyuk wrote: >>> Andy, >>> >>> Please remove javadoc update about `--linux-deb-copyright-file` >>> option. It will be dropped in >>> https://bugs.openjdk.java.net/browse/JDK-8231277 patch. >>> Line 180: >>> --- >>> if (additional.containsKey("java-optiions")) { >>> --- >>> Looks like a typo. Should be "java-options", not "java-optiions", I >>> guess. >>> We probably need a test or at least a follow up CR to track the task >>> of adding a test for "java-options" parameter in additional launchers. >>> >>> - Alexey >>> >>> On 9/24/2019 8:46 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 change applies when arguments or java-options are used in an >>>> add-launcher properties file. >>>> >>>> In these cases the arguments or java-options from the properties >>>> files should replace instead of being added to the same options >>>> used in the command line? for the main launcher. >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8230927 >>>> >>>> [2] http://cr.openjdk.java.net/~herrick/8230927 >>>> >>>> /Andy >>>> >>> > From alexander.matveev at oracle.com Tue Sep 24 23:29:30 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Tue, 24 Sep 2019 16:29:30 -0700 Subject: RFR: JDK-8230920 : jpackage problems when -input dir contains any files with "cfg" extension. In-Reply-To: References: Message-ID: Hi Andy, Looks good. Do you think it would be better to write CLI arguments in some internal format instead of just raw dump? It might be better in case if we plan to change CLI between versions and at same time supporting generation of installers for app image using different jpackage versions. Thanks, Alexander On 9/24/2019 5:54 AM, Andy Herrick wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > This fix replaces the practice we were using on windows to determine > the application name, and name of additional launchers (by looking for > ".cfg" files in the app dir. > > Instead we now add a file ".jpackage.args" to the root of the > app-image, and record in that file all the arguments used to create > the app-image.? We later read that file to determine the original app > name and any additional launcher names. > > This change also fixes the shortcut creation on windows to create > shortcuts (if so directed) for all launchers. > > [1] https://bugs.openjdk.java.net/browse/JDK-8230920 > > [2] http://cr.openjdk.java.net/~herrick/8230920/webrev.01/ > > /Andy > From shill at turningtechnologies.com Tue Sep 24 21:23:10 2019 From: shill at turningtechnologies.com (Scott Hill) Date: Tue, 24 Sep 2019 21:23:10 +0000 Subject: Build errors - JDK-8200758-branch References: Message-ID: Build fails on my CI Window Server 2008 & 2012 agents. I am only able to get it to build on a Windows 10 system. [12:49:04][Step 1/1] ERROR: Build failed for target 'jdk' in configuration 'windows-x86-server-release' (exit code 2) [12:49:05][Step 1/1] [12:49:05][Step 1/1] === Output from failing command(s) repeated here === [12:49:05][Step 1/1] * For target support_native_jdk.jpackage_libjpackage_WindowsRegistry.obj: [12:49:05][Step 1/1] WindowsRegistry.cpp [12:49:05][Step 1/1] c:\progra~2\micros~2.0\vc\include\tchar.h(24) : fatal error C1189: #error : Need to include strsafe.h after tchar.h [12:49:05][Step 1/1] ... (rest of output omitted) [12:49:05][Step 1/1] [12:49:05][Step 1/1] * All command lines available in /cygdrive/e/BuildAgent/work/ccdca5c47124cb38/build/windows-x86-server-release/make-support/failure-logs. [12:49:05][Step 1/1] === End of repeated output === Build script: make dist-clean bash configure --with-target-bits=32 --disable-warnings-as-errors make jdk Any help would be appreciated. Thanks, Scott Hill | Software Build Manager Turning Technologies | 14557 N. 82nd Street Scottsdale, AZ 85260 Direct: 480-443-2249 | Main: 330-746-3015 | Fax: 330-884-6065 shill at turningtechnologies.com | TurningTechnologies.com This email message, including any attached files, is for the sole use of the intended recipients(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. To manage your email preferences or to opt-out of marketing communications completely, click here. From cvafadari at gmail.com Wed Sep 25 03:19:49 2019 From: cvafadari at gmail.com (Cyrus Vafadari) Date: Tue, 24 Sep 2019 20:19:49 -0700 Subject: RandomAccess Interface and List Heirarchy Message-ID: Hello all, *TLDR: Why doesn't RandomAccess interface extend List?* I'm maintaining a framework that lets developers build plugins, and developers implement a `put(List thingList)` in their plugins. However, I want to guarantee to the implementer that their List will support RandomAccess. I see Java does support a syntax for declaring that the argument should implement both List and RandomAccess using the "&" operator, and I could declare my own interface that extends both, but I am surprised that RandomAccess itself does not extend List and appear in the List hierarchy. According to the docs, it only applies to List implementations anyway, and we use `instanceof` extensively in the code to bifurcate how we handle both cases. It seems more natural to me for RandomAccess to extend List, so that I can let my implementer know explicitly they can rely on RandomAccess. I am happy to give more details on my scenario, and very excited to learn more why this decision was made, and if there is an aspect I am missing or if improvements could be made! Best wishes, Cyrus From joe.darcy at oracle.com Wed Sep 25 04:34:48 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 24 Sep 2019 21:34:48 -0700 Subject: JDK 14 RFR of JDK-8231442 : Suppress warnings on non-serializable instance fields in java.sql.* modules Message-ID: <7cee1e8a-886d-192a-9eb8-0bd5e894fb88@oracle.com> Hello, Next step in the serialization warnings pre-cleanup is java.sql.* modules. Please review the proposed changes: ??? JDK-8231442 : Suppress warnings on non-serializable instance fields in java.sql.* modules ??? http://cr.openjdk.java.net/~darcy/8231442.0/ Several of the writeObject methods do runtime checks on whether on not objects pointed to by the fields in question are serializable. The fields with this runtime check get a explanatory comment noting that different from the usual comment. Thanks, -Joe From lance.andersen at oracle.com Wed Sep 25 10:10:18 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 25 Sep 2019 06:10:18 -0400 Subject: JDK 14 RFR of JDK-8231442 : Suppress warnings on non-serializable instance fields in java.sql.* modules In-Reply-To: <7cee1e8a-886d-192a-9eb8-0bd5e894fb88@oracle.com> References: <7cee1e8a-886d-192a-9eb8-0bd5e894fb88@oracle.com> Message-ID: <00B50DA2-51FD-4625-A13D-7B2F4164A7EF@oracle.com> Hi Joe, Looks OK SyncProviderException.java, SQLClientInfoException.java, StatementEvent.java should probably have the copyright notice updated to 2019 prior to pushing Best Lance > On Sep 25, 2019, at 12:34 AM, Joe Darcy wrote: > > Hello, > > Next step in the serialization warnings pre-cleanup is java.sql.* modules. Please review the proposed changes: > > JDK-8231442 : Suppress warnings on non-serializable instance fields in java.sql.* modules > http://cr.openjdk.java.net/~darcy/8231442.0/ > > Several of the writeObject methods do runtime checks on whether on not objects pointed to by the fields in question are serializable. The fields with this runtime check get a explanatory comment noting that different from the usual comment. > > 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 forax at univ-mlv.fr Wed Sep 25 10:15:40 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 25 Sep 2019 12:15:40 +0200 (CEST) Subject: RandomAccess Interface and List Heirarchy In-Reply-To: References: Message-ID: <1062347590.1395885.1569406540881.JavaMail.zimbra@u-pem.fr> Hi Cyrus, as the javadoc says RandomAccess is a marker interface, an interface used at runtime to indicate if the implementation provides a fast random access operation or not. "marker interface" is the precursor of a runtime visible annotation. RandomAccess was introduce in 1.4 while annotations were introduced later in 1.5. implementing RandomAccess is equivalent of adding a bit on all implementations of List, so casting an instance to RandomAccess is not how you should using it. More generally, the idea of the collection API is that instead of having a RandomAccessList, a MutableList, an ImmutableList, a RandomImmutableList, etc you have only one type java.util.List and if you want to know more either you do a instanceof check, or call a method that throws UnsuportedOperationException or use a method of the API that does the runtime checks for you, like by example List.copyOf(). 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). R?mi ----- Mail original ----- > De: "Cyrus Vafadari" > ?: "core-libs-dev" > Envoy?: Mercredi 25 Septembre 2019 05:19:49 > Objet: RandomAccess Interface and List Heirarchy > Hello all, > > *TLDR: Why doesn't RandomAccess interface extend List?* > > I'm maintaining a framework that lets developers build plugins, and > developers implement a `put(List thingList)` in their plugins. > However, I want to guarantee to the implementer that their List will > support RandomAccess. I see Java does support a syntax for declaring that > the argument should implement both List and RandomAccess using the "&" > operator, and I could declare my own interface that extends both, but I am > surprised that RandomAccess itself does not extend List and appear in the > List hierarchy. According to the docs, it only applies to List > implementations anyway, and we use `instanceof` extensively in the code to > bifurcate how we handle both cases. It seems more natural to me for > RandomAccess to extend List, so that I can let my implementer know > explicitly they can rely on RandomAccess. > > I am happy to give more details on my scenario, and very excited to learn > more why this decision was made, and if there is an aspect I am missing or > if improvements could be made! > > Best wishes, > > Cyrus From sverre.moe at gmail.com Wed Sep 25 13:45:36 2019 From: sverre.moe at gmail.com (Sverre Moe) Date: Wed, 25 Sep 2019 15:45:36 +0200 Subject: Comments on jpackage (JEP 343) In-Reply-To: <7c7197f1-edb7-6e6b-b303-4abe373d0051@oracle.com> References: <20190903185855.D9F092BEC49@eggemoggin.niobe.net> <5D804F4A.3010103@oracle.com> <5D8051DF.2070903@oracle.com> <4c9ee165-b724-4ed0-4563-1877f567067f@oracle.com> <20190919102519.205163004@eggemoggin.niobe.net> <7c7197f1-edb7-6e6b-b303-4abe373d0051@oracle.com> Message-ID: I have some new comments regarding the Windows build of jpackage. 1) Is there any way to build an trusted application installer using WiX? I want to avoid "Unknown Publisher" when installing the application. Also having problems with Windows Defender SmartScreen, depending on what settings the user has (Block, Warn, Off). If Block, the user cannot install the application. If Warn, the user can click "More info", then "Run anyway". 2) The EXE installer details has no information about the actual application it will install. File version: 14.0.0 Product Name OpenJDK Platform 14 Product version: 14 This is not quite right, since the application was built with Java 11, only packaged with jpackage from Java 14. Should it not use the name and app version supplied to jpackage on these properties. Original filename: msiwrapper.msi. It should be the name supplied to jpackage used here at least > applicationName.msi Building an MSI has much better detail properties, but a couple of the description properties says nothing about the actual application. Title: Installation Database Comments: This installer database contains the logic and data required to install applicationName. Any way to change the title and comments? 3) The icon for the installer file is not using the one from the resource directory. If supplied the --icon argument is not used. Both Explorer and List of installed application shows a generic application icon. 4) MSI installer has a Category detail property. Perhaps jpackage should have an --windows-category argument. 5) Help text for --icon argument should mention that it needs to be an ICO when packaging on Windows. Currently there is no way to supply a custom WXS file to WiX in the resource directory. Perhaps this could help further customization. /Sverre tor. 19. sep. 2019 kl. 20:29 skrev Kevin Rushforth < kevin.rushforth at oracle.com>: > OK, that makes sense. Andy has already implemented this change (pushed > it to the sandbox), so it will be in the next EA build. > > -- Kevin > > On 9/19/2019 10:25 AM, mark.reinhold at oracle.com wrote: > > jlink?s -o/--output option names exactly the thing being output, > > rather than a container for the thing being output. > > > > The jpackage option we?re discussing here names a container for the > > thing being output, much like the -d option of javac and javadoc. > > > > Using -d/--dest for jpackage is consistent with the JDK?s other > > command-line tools. > > > > - Mark > > From andy.herrick at oracle.com Wed Sep 25 14:33:47 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 25 Sep 2019 10:33:47 -0400 Subject: RFR: JDK-8230649 : Make jpackage tool an experimental feature 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). These are the code changes to make jpackage an experimental feature. [1] https://bugs.openjdk.java.net/browse/JDK-8230649 [2] http://cr.openjdk.java.net/~herrick/8230649/webrev.02/ /Andy From Alan.Bateman at oracle.com Wed Sep 25 14:44:37 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 25 Sep 2019 15:44:37 +0100 Subject: RFR: JDK-8230649 : Make jpackage tool an experimental feature In-Reply-To: References: Message-ID: <4783a6d2-4f5a-5257-6baf-aba9ae930419@oracle.com> On 25/09/2019 15:33, 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). > > These are the code changes to make jpackage an experimental feature. > > [1] https://bugs.openjdk.java.net/browse/JDK-8230649 > > [2] http://cr.openjdk.java.net/~herrick/8230649/webrev.02/ I assume the change to CreateJmods.gmk is not needed as the module will be resolved because it provides an implementation of ToolProvider. -Alan From kevin.rushforth at oracle.com Wed Sep 25 15:18:47 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 25 Sep 2019 08:18:47 -0700 Subject: RFR: JDK-8230649 : Make jpackage tool an experimental feature In-Reply-To: <4783a6d2-4f5a-5257-6baf-aba9ae930419@oracle.com> References: <4783a6d2-4f5a-5257-6baf-aba9ae930419@oracle.com> Message-ID: <13a2824a-c06d-1743-fd08-e3f30d14f93a@oracle.com> On 9/25/2019 7:44 AM, Alan Bateman wrote: > On 25/09/2019 15:33, 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). >> >> These are the code changes to make jpackage an experimental feature. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8230649 >> >> [2] http://cr.openjdk.java.net/~herrick/8230649/webrev.02/ > I assume the change to CreateJmods.gmk is not needed as the module > will be resolved because it provides an implementation of ToolProvider. I was going to point out the same thing as Alan. The rest looks good, although an explicit informational line in the --help message might be nice, in case log warnings are going somewhere else. -- Kevin From andy.herrick at oracle.com Wed Sep 25 15:29:22 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 25 Sep 2019 11:29:22 -0400 Subject: RFR: JDK-8230649 : Make jpackage tool an experimental feature In-Reply-To: <13a2824a-c06d-1743-fd08-e3f30d14f93a@oracle.com> References: <4783a6d2-4f5a-5257-6baf-aba9ae930419@oracle.com> <13a2824a-c06d-1743-fd08-e3f30d14f93a@oracle.com> Message-ID: <139c366c-bce0-8c51-48f9-71b0dd8c4b62@oracle.com> I can will remove the makefile change then. The warning is going the same place as the help output (Log.info()) which is stdout unless a different stream is passed to ToolProvider. So if we want a more detailed message in Help text we can either show the more detailed message in addition to the message shown in all cases, or specifically exclude the generic message in the Help case. /Andy On 9/25/19 11:18 AM, Kevin Rushforth wrote: > > > On 9/25/2019 7:44 AM, Alan Bateman wrote: >> On 25/09/2019 15:33, 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). >>> >>> These are the code changes to make jpackage an experimental feature. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8230649 >>> >>> [2] http://cr.openjdk.java.net/~herrick/8230649/webrev.02/ >> I assume the change to CreateJmods.gmk is not needed as the module >> will be resolved because it provides an implementation of ToolProvider. > > I was going to point out the same thing as Alan. The rest looks good, > although an explicit informational line in the --help message might be > nice, in case log warnings are going somewhere else. > > -- Kevin > From kevin.rushforth at oracle.com Wed Sep 25 17:06:09 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 25 Sep 2019 10:06:09 -0700 Subject: RFR: JDK-8230649 : Make jpackage tool an experimental feature In-Reply-To: <139c366c-bce0-8c51-48f9-71b0dd8c4b62@oracle.com> References: <4783a6d2-4f5a-5257-6baf-aba9ae930419@oracle.com> <13a2824a-c06d-1743-fd08-e3f30d14f93a@oracle.com> <139c366c-bce0-8c51-48f9-71b0dd8c4b62@oracle.com> Message-ID: <6ea08062-b7b9-710a-4a8e-ea1e4cc0fa05@oracle.com> That seems fine then. Thanks. -- Kevin On 9/25/2019 8:29 AM, Andy Herrick wrote: > I can will remove the makefile change then. > > The warning is going the same place as the help output (Log.info()) > which is stdout unless a different stream is passed to ToolProvider. > > So if we want a more detailed message in Help text we can either show > the more detailed message in addition to the message shown in all > cases, or specifically exclude the generic message in the Help case. > > /Andy > > On 9/25/19 11:18 AM, Kevin Rushforth wrote: >> >> >> On 9/25/2019 7:44 AM, Alan Bateman wrote: >>> On 25/09/2019 15:33, 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). >>>> >>>> These are the code changes to make jpackage an experimental feature. >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8230649 >>>> >>>> [2] http://cr.openjdk.java.net/~herrick/8230649/webrev.02/ >>> I assume the change to CreateJmods.gmk is not needed as the module >>> will be resolved because it provides an implementation of ToolProvider. >> >> I was going to point out the same thing as Alan. The rest looks good, >> although an explicit informational line in the --help message might >> be nice, in case log warnings are going somewhere else. >> >> -- Kevin >> From alexander.matveev at oracle.com Wed Sep 25 22:30:53 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Wed, 25 Sep 2019 15:30:53 -0700 Subject: RFR: JDK-8231382: Use main class from main module if available Message-ID: <10f07cb4-3e9f-e1e5-8c40-d0142d1f367a@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). - Main class from module will be used if main class is not specified in CLI. Main class from CLI will be preferred over main class specified in module attribute. [1] https://bugs.openjdk.java.net/browse/JDK-8231382 [2] http://cr.openjdk.java.net/~almatvee/8231382/webrev.00/ Thanks, Alexander From jonathan.gibbons at oracle.com Wed Sep 25 22:40:49 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 25 Sep 2019 15:40:49 -0700 Subject: JEP proposed to target JDK 14: 358: Helpful NullPointerExceptions In-Reply-To: <20190925222220.8DCD03084DA@eggemoggin.niobe.net> References: <20190925222220.8DCD03084DA@eggemoggin.niobe.net> Message-ID: Typo "isnull" and/or font issue, in "The format of the null-detail message" 1. In a failed array access --|Cannot load from object array because 'a[i][j]' is|null|.|-- the second part|'a[i][j]' is null.|suffices to pinpoint the|null|expression in source code,|a[i][j][k] = 99;| -- Jon On 9/25/19 3:22 PM, mark.reinhold at oracle.com wrote: > The following JEP is proposed to target JDK 14: > > 358: Helpful NullPointerExceptions > https://openjdk.java.net/jeps/358 > > Feedback on this proposal from JDK Project Committers and Reviewers [1] > is more than welcome, as are reasoned objections. If no such objections > are raised by 23:00 UTC on Wednesday, 2 October, or if they?re raised > and then satisfactorily answered, then per the JEP 2.0 process proposal > [2] I?ll target this JEP to JDK 14. > > - Mark > > > [1] https://openjdk.java.net/census#jdk > [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From alexey.semenyuk at oracle.com Wed Sep 25 22:46:45 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Wed, 25 Sep 2019 18:46:45 -0400 Subject: RFR: JDK-8231382: Use main class from main module if available In-Reply-To: <10f07cb4-3e9f-e1e5-8c40-d0142d1f367a@oracle.com> References: <10f07cb4-3e9f-e1e5-8c40-d0142d1f367a@oracle.com> Message-ID: <4390409a-f693-322c-392f-b2c4254a73bb@oracle.com> Looks good. - Alexey On 9/25/2019 6:30 PM, Alexander Matveev wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > - Main class from module will be used if main class is not specified > in CLI. Main class from CLI will be preferred over main class > specified in module attribute. > > [1] https://bugs.openjdk.java.net/browse/JDK-8231382 > > [2] http://cr.openjdk.java.net/~almatvee/8231382/webrev.00/ > > Thanks, > Alexander From alexey.semenyuk at oracle.com Wed Sep 25 23:58:26 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Wed, 25 Sep 2019 19:58:26 -0400 Subject: Comments on jpackage (JEP 343) In-Reply-To: References: <20190903185855.D9F092BEC49@eggemoggin.niobe.net> <5D804F4A.3010103@oracle.com> <5D8051DF.2070903@oracle.com> <4c9ee165-b724-4ed0-4563-1877f567067f@oracle.com> <20190919102519.205163004@eggemoggin.niobe.net> <7c7197f1-edb7-6e6b-b303-4abe373d0051@oracle.com> Message-ID: <0d67d896-1eca-83c2-1ce4-c48e14e79f4a@oracle.com> Sverre, Thank you for your feedback. I've captured it in https://bugs.openjdk.java.net/browse/JDK-8230668. - Alexey On 9/25/2019 9:45 AM, Sverre Moe wrote: > I have some new comments regarding the Windows build of jpackage. > > 1) > Is there any way to build an trusted application installer using WiX? > I want to avoid "Unknown Publisher" when installing the application. > Also having problems with Windows Defender SmartScreen, depending on what > settings the user has (Block, Warn, Off). > If Block, the user cannot install the application. If Warn, the user can > click "More info", then "Run anyway". > > 2) > The EXE installer details has no information about the actual application > it will install. > File version: 14.0.0 > Product Name OpenJDK Platform 14 > Product version: 14 > This is not quite right, since the application was built with Java 11, only > packaged with jpackage from Java 14. > Should it not use the name and app version supplied to jpackage on these > properties. > > Original filename: msiwrapper.msi. > It should be the name supplied to jpackage used here at least > > applicationName.msi > > Building an MSI has much better detail properties, but a couple of the > description properties says nothing about the actual application. > Title: Installation Database > Comments: This installer database contains the logic and data required to > install applicationName. > Any way to change the title and comments? > > 3) > The icon for the installer file is not using the one from the resource > directory. If supplied the --icon argument is not used. > Both Explorer and List of installed application shows a generic application > icon. > > 4) > MSI installer has a Category detail property. Perhaps jpackage should have > an --windows-category argument. > > 5) > Help text for --icon argument should mention that it needs to be an ICO > when packaging on Windows. > > Currently there is no way to supply a custom WXS file to WiX in the > resource directory. Perhaps this could help further customization. > > /Sverre > > > > tor. 19. sep. 2019 kl. 20:29 skrev Kevin Rushforth < > kevin.rushforth at oracle.com>: > >> OK, that makes sense. Andy has already implemented this change (pushed >> it to the sandbox), so it will be in the next EA build. >> >> -- Kevin >> >> On 9/19/2019 10:25 AM, mark.reinhold at oracle.com wrote: >>> jlink?s -o/--output option names exactly the thing being output, >>> rather than a container for the thing being output. >>> >>> The jpackage option we?re discussing here names a container for the >>> thing being output, much like the -d option of javac and javadoc. >>> >>> Using -d/--dest for jpackage is consistent with the JDK?s other >>> command-line tools. >>> >>> - Mark >> From ying.z.zhou at oracle.com Thu Sep 26 05:58:22 2019 From: ying.z.zhou at oracle.com (Daisy Zhou) Date: Wed, 25 Sep 2019 22:58:22 -0700 (PDT) Subject: [14]RFR 8231213: Migrate SimpleDateFormatConstTest to JDK Repo Message-ID: <61169622-561d-4a93-b1f9-fa261727d6d5@default> Hello, Please help to review this patch for migrating SimpleDateFormatConstTest from Tonga to Jtreg. Bug:HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8231213" https://bugs.openjdk.java.net/browse/JDK-8231213 Webrev: http://cr.openjdk.java.net/~yzhou/8231213/webrev.02/ Thanks, Daisy From goetz.lindenmaier at sap.com Thu Sep 26 06:56:48 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 26 Sep 2019 06:56:48 +0000 Subject: JEP proposed to target JDK 14: 358: Helpful NullPointerExceptions In-Reply-To: References: <20190925222220.8DCD03084DA@eggemoggin.niobe.net> Message-ID: Hi Jon, Good catch, I fixed it. Thanks! Goetz. > -----Original Message----- > From: hotspot-runtime-dev bounces at openjdk.java.net> On Behalf Of Jonathan Gibbons > Sent: Thursday, September 26, 2019 12:41 AM > To: hotspot-runtime-dev at openjdk.java.net runtime dev at openjdk.java.net>; OpenJDK Dev list > Subject: Re: JEP proposed to target JDK 14: 358: Helpful > NullPointerExceptions > > Typo "isnull" and/or font issue, in "The format of the null-detail message" > > 1. > > In a failed array access --|Cannot load from object array because > 'a[i][j]' is|null|.|-- the second part|'a[i][j]' is null.|suffices > to pinpoint the|null|expression in source code,|a[i][j][k] = 99;| > > -- Jon > > On 9/25/19 3:22 PM, mark.reinhold at oracle.com wrote: > > The following JEP is proposed to target JDK 14: > > > > 358: Helpful NullPointerExceptions > > https://openjdk.java.net/jeps/358 > > > > Feedback on this proposal from JDK Project Committers and Reviewers [1] > > is more than welcome, as are reasoned objections. If no such objections > > are raised by 23:00 UTC on Wednesday, 2 October, or if they?re raised > > and then satisfactorily answered, then per the JEP 2.0 process proposal > > [2] I?ll target this JEP to JDK 14. > > > > - Mark > > > > > > [1] https://openjdk.java.net/census#jdk > > [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From patrick.concannon at oracle.com Thu Sep 26 08:38:18 2019 From: patrick.concannon at oracle.com (Patrick Concannon) Date: Thu, 26 Sep 2019 09:38:18 +0100 Subject: RFR[8229338]: clean up test/jdk/java/util/RandomAccess/Basic.java Message-ID: <4b40de1d-c6a6-675f-60ea-fee4af8b66f4@oracle.com> Hi, Would it be possible to have my fix for JDK-8229338 reviewed? This a general refactoring of test/jdk/java/util/RandomAccess/Basic.java as outlined in JDK-8229338 'clean up test/jdk/java/util/RandomAccess/Basic.java'. Further information on this bug can be found here: https://bugs.openjdk.java.net/browse/JDK-8229338 Webrev: http://cr.openjdk.java.net/~pconcannon/8229338/webrevs/webrev.00/ Kind regards, Patrick From andy.herrick at oracle.com Thu Sep 26 10:57:51 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Thu, 26 Sep 2019 06:57:51 -0400 Subject: RFR: JDK-8230649 : Make jpackage tool an experimental feature In-Reply-To: References: Message-ID: <6ed841b8-0a9c-cd70-3475-51098e61213e@oracle.com> Revised [3] to remove the change to CreateJmods.gmk since it is not needed as the module will be resolved because it provides an implementation of ToolProvider. [3] http://cr.openjdk.java.net/~herrick/8230649/webrev.03/ /Andy On 9/25/2019 10:33 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). > > These are the code changes to make jpackage an experimental feature. > > [1] https://bugs.openjdk.java.net/browse/JDK-8230649 > > [2] http://cr.openjdk.java.net/~herrick/8230649/webrev.02/ > > /Andy > From andy.herrick at oracle.com Thu Sep 26 11:03:23 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Thu, 26 Sep 2019 07:03:23 -0400 Subject: RFR: JDK-8231382: Use main class from main module if available In-Reply-To: <10f07cb4-3e9f-e1e5-8c40-d0142d1f367a@oracle.com> References: <10f07cb4-3e9f-e1e5-8c40-d0142d1f367a@oracle.com> Message-ID: looks good. /Andy On 9/25/2019 6:30 PM, Alexander Matveev wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > - Main class from module will be used if main class is not specified > in CLI. Main class from CLI will be preferred over main class > specified in module attribute. > > [1] https://bugs.openjdk.java.net/browse/JDK-8231382 > > [2] http://cr.openjdk.java.net/~almatvee/8231382/webrev.00/ > > Thanks, > Alexander From alexey.semenyuk at oracle.com Thu Sep 26 11:34:04 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Thu, 26 Sep 2019 07:34:04 -0400 Subject: RFR: JDK-8230649 : Make jpackage tool an experimental feature In-Reply-To: <6ed841b8-0a9c-cd70-3475-51098e61213e@oracle.com> References: <6ed841b8-0a9c-cd70-3475-51098e61213e@oracle.com> Message-ID: <070198e6-0929-8e25-98ba-a5dde93ceaed@oracle.com> Looks good. - Alexey On 9/26/2019 6:57 AM, Andy Herrick wrote: > Revised [3] to remove the change to CreateJmods.gmk since it is not > needed as the module will be resolved because it provides an > implementation of ToolProvider. > > [3] http://cr.openjdk.java.net/~herrick/8230649/webrev.03/ > > /Andy > > On 9/25/2019 10:33 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). >> >> These are the code changes to make jpackage an experimental feature. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8230649 >> >> [2] http://cr.openjdk.java.net/~herrick/8230649/webrev.02/ >> >> /Andy >> From kevin.rushforth at oracle.com Thu Sep 26 12:15:38 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 26 Sep 2019 05:15:38 -0700 Subject: RFR: JDK-8230649 : Make jpackage tool an experimental feature In-Reply-To: <6ed841b8-0a9c-cd70-3475-51098e61213e@oracle.com> References: <6ed841b8-0a9c-cd70-3475-51098e61213e@oracle.com> Message-ID: <4502e6a0-e67c-26a9-72c1-55f8c7b51669@oracle.com> Looks good. -- Kevin On 9/26/2019 3:57 AM, Andy Herrick wrote: > Revised [3] to remove the change to CreateJmods.gmk since it is not > needed as the module will be resolved because it provides an > implementation of ToolProvider. > > [3] http://cr.openjdk.java.net/~herrick/8230649/webrev.03/ > > /Andy > > On 9/25/2019 10:33 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). >> >> These are the code changes to make jpackage an experimental feature. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8230649 >> >> [2] http://cr.openjdk.java.net/~herrick/8230649/webrev.02/ >> >> /Andy >> From lance.andersen at oracle.com Thu Sep 26 12:36:39 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 26 Sep 2019 08:36:39 -0400 Subject: RFR[8229338]: clean up test/jdk/java/util/RandomAccess/Basic.java In-Reply-To: <4b40de1d-c6a6-675f-60ea-fee4af8b66f4@oracle.com> References: <4b40de1d-c6a6-675f-60ea-fee4af8b66f4@oracle.com> Message-ID: Hi Patrick, Overall I think this looks ok. A few minor comments Please add 8229338 to the @bug line I might suggest adding either a comment to the DataProvider or the test which uses it with an overview of the parameters to make it easier and quicker for future maintainers to know the intent. Lines 86 and 91, you could if you want use String.format and just substitute the changed values. Your testCopy and testFlil methods you can probably consider using a DataProvider so that you can also test other types such as Vector or was this intentional to omit them ? HTH Lance > On Sep 26, 2019, at 4:38 AM, Patrick Concannon wrote: > > Hi, > > > Would it be possible to have my fix for JDK-8229338 reviewed? > > This a general refactoring of test/jdk/java/util/RandomAccess/Basic.java as outlined in JDK-8229338 'clean up test/jdk/java/util/RandomAccess/Basic.java'. > > > Further information on this bug can be found here: https://bugs.openjdk.java.net/browse/JDK-8229338 > > Webrev: http://cr.openjdk.java.net/~pconcannon/8229338/webrevs/webrev.00/ > > > Kind regards, > > Patrick > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From naoto.sato at oracle.com Thu Sep 26 15:28:46 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 26 Sep 2019 08:28:46 -0700 Subject: [14]RFR 8231213: Migrate SimpleDateFormatConstTest to JDK Repo In-Reply-To: <61169622-561d-4a93-b1f9-fa261727d6d5@default> References: <61169622-561d-4a93-b1f9-fa261727d6d5@default> Message-ID: Looks good. Naoto On 9/25/19 10:58 PM, Daisy Zhou wrote: > Hello, > > Please help to review this patch for migrating SimpleDateFormatConstTest from Tonga to Jtreg. > > > > Bug:HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8231213" https://bugs.openjdk.java.net/browse/JDK-8231213 > > Webrev: http://cr.openjdk.java.net/~yzhou/8231213/webrev.02/ > > > > Thanks, > > Daisy > From joe.darcy at oracle.com Thu Sep 26 17:51:26 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 26 Sep 2019 10:51:26 -0700 Subject: JDK 14 RFR of JDK-8231546: Suppress warnings on non-serializable instance fields in java.prefs module Message-ID: Hello, Another part of the cleanup of library serialization usage ahead of augmented javac -Xlint warnings (JDK-8160675), the non-serializable instance fields of serializable types in the java.prefs module should have their serial warnings suppressed. The analogous issue in core libs is JDK-8231202. For the type in question, while NodeChangeEvent is typed as serializable, both its readObject and writeObject methods are written to unconditionally throw exceptions, so it is not serializable in practice. The class does define a serialVersionUID, so the one suspect field can be marked as "transient" without causing an effective change in serialization support. Patch below. Thanks, -Joe diff -r e23e560afbcb src/java.prefs/share/classes/java/util/prefs/NodeChangeEvent.java --- a/src/java.prefs/share/classes/java/util/prefs/NodeChangeEvent.java Wed Sep 25 21:26:38 2019 -0700 +++ b/src/java.prefs/share/classes/java/util/prefs/NodeChangeEvent.java Thu Sep 26 10:48:34 2019 -0700 @@ -49,7 +49,7 @@ ????? * ????? * @serial ????? */ -??? private Preferences child; +??? private transient Preferences child; ???? /** ????? * Constructs a new {@code NodeChangeEvent} instance. From alexander.matveev at oracle.com Thu Sep 26 18:05:11 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Thu, 26 Sep 2019 11:05:11 -0700 Subject: RFR: JDK-8230649 : Make jpackage tool an experimental feature In-Reply-To: <4502e6a0-e67c-26a9-72c1-55f8c7b51669@oracle.com> References: <6ed841b8-0a9c-cd70-3475-51098e61213e@oracle.com> <4502e6a0-e67c-26a9-72c1-55f8c7b51669@oracle.com> Message-ID: Looks good. On 9/26/2019 5:15 AM, Kevin Rushforth wrote: > Looks good. > > -- Kevin > > > On 9/26/2019 3:57 AM, Andy Herrick wrote: >> Revised [3] to remove the change to CreateJmods.gmk since it is not >> needed as the module will be resolved because it provides an >> implementation of ToolProvider. >> >> [3] http://cr.openjdk.java.net/~herrick/8230649/webrev.03/ >> >> /Andy >> >> On 9/25/2019 10:33 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). >>> >>> These are the code changes to make jpackage an experimental feature. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8230649 >>> >>> [2] http://cr.openjdk.java.net/~herrick/8230649/webrev.02/ >>> >>> /Andy >>> > From Roger.Riggs at oracle.com Thu Sep 26 18:27:27 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 26 Sep 2019 14:27:27 -0400 Subject: JDK 14 RFR of JDK-8231546: Suppress warnings on non-serializable instance fields in java.prefs module In-Reply-To: References: Message-ID: Looks fine, Joe On 9/26/19 1:51 PM, Joe Darcy wrote: > Hello, > > Another part of the cleanup of library serialization usage ahead of > augmented javac -Xlint warnings (JDK-8160675), the non-serializable > instance fields of serializable types in the java.prefs module should > have their serial warnings suppressed. The analogous issue in core > libs is JDK-8231202. > > For the type in question, while NodeChangeEvent is typed as > serializable, both its readObject and writeObject methods are written > to unconditionally throw exceptions, so it is not serializable in > practice. The class does define a serialVersionUID, so the one suspect > field can be marked as "transient" without causing an effective change > in serialization support. > > Patch below. > > Thanks, > > -Joe > > diff -r e23e560afbcb > src/java.prefs/share/classes/java/util/prefs/NodeChangeEvent.java > --- > a/src/java.prefs/share/classes/java/util/prefs/NodeChangeEvent.java > Wed Sep 25 21:26:38 2019 -0700 > +++ > b/src/java.prefs/share/classes/java/util/prefs/NodeChangeEvent.java > Thu Sep 26 10:48:34 2019 -0700 > @@ -49,7 +49,7 @@ > ????? * > ????? * @serial > ????? */ > -??? private Preferences child; > +??? private transient Preferences child; > > ???? /** > ????? * Constructs a new {@code NodeChangeEvent} instance. > > From chris.hegarty at oracle.com Thu Sep 26 19:58:12 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 26 Sep 2019 20:58:12 +0100 Subject: JDK 14 RFR of JDK-8231546: Suppress warnings on non-serializable instance fields in java.prefs module In-Reply-To: References: Message-ID: <2063227F-63F4-4F77-A9D8-8E6D9FC2E2B3@oracle.com> +1. Should the @serial javadoc tag be removed? -Chris. > On 26 Sep 2019, at 19:27, Roger Riggs wrote: > > Looks fine, Joe > >> On 9/26/19 1:51 PM, Joe Darcy wrote: >> Hello, >> >> Another part of the cleanup of library serialization usage ahead of augmented javac -Xlint warnings (JDK-8160675), the non-serializable instance fields of serializable types in the java.prefs module should have their serial warnings suppressed. The analogous issue in core libs is JDK-8231202. >> >> For the type in question, while NodeChangeEvent is typed as serializable, both its readObject and writeObject methods are written to unconditionally throw exceptions, so it is not serializable in practice. The class does define a serialVersionUID, so the one suspect field can be marked as "transient" without causing an effective change in serialization support. >> >> Patch below. >> >> Thanks, >> >> -Joe >> >> diff -r e23e560afbcb src/java.prefs/share/classes/java/util/prefs/NodeChangeEvent.java >> --- a/src/java.prefs/share/classes/java/util/prefs/NodeChangeEvent.java Wed Sep 25 21:26:38 2019 -0700 >> +++ b/src/java.prefs/share/classes/java/util/prefs/NodeChangeEvent.java Thu Sep 26 10:48:34 2019 -0700 >> @@ -49,7 +49,7 @@ >> * >> * @serial >> */ >> - private Preferences child; >> + private transient Preferences child; >> >> /** >> * Constructs a new {@code NodeChangeEvent} instance. >> >> > From mark.reinhold at oracle.com Thu Sep 26 21:23:36 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 26 Sep 2019 14:23:36 -0700 Subject: CharsetEncoder.maxBytesPerChar() In-Reply-To: <5336b4de-cd28-c66b-963a-c5f63c8cb807@CoSoCo.de> References: <07109047-3a9b-c784-4fa8-86616a3bc263@oracle.com> <20190920150339.254128936@eggemoggin.niobe.net> <5336b4de-cd28-c66b-963a-c5f63c8cb807@CoSoCo.de> Message-ID: <20190926142336.572175248@eggemoggin.niobe.net> 2019/9/24 13:00:21 -0700, ulf.zibis at cosoco.de: > Am 21.09.19 um 00:03 schrieb mark.reinhold at oracle.com: >> To avoid this confusion, a more verbose specification might read: >> * Returns the maximum number of $otype$s that will be produced for each >> * $itype$ of input. This value may be used to compute the worst-case size >> * of the output buffer required for a given input sequence. This value >> * accounts for any necessary content-independent prefix or suffix >> #if[encoder] >> * $otype$s, such as byte-order marks. >> #end[encoder] >> #if[decoder] >> * $otype$s. >> #end[decoder] > > wouldn't it be more clear to use "char" or even "{@code char}" instead > "character" as replacment for the $xtype$ parameters? The specifications of the Charset{De,En}coder classes make it clear up front that ?character? means ?sixteen-bit Unicode character,? so I don?t think changing ?character? everywhere to ?{@code char}? is necessary. This usage of ?character? is common throughout the API specification. With the introduction of 32-bit Unicode characters we started calling those ?code points,? but kept on calling sixteen-bit characters just ?characters.? (I don?t think the official term ?Unicode code unit? ever caught on, and it?s a bit of a mouthful anyway.) - Mark From sgehwolf at redhat.com Fri Sep 27 08:33:58 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 27 Sep 2019 10:33:58 +0200 Subject: [8u] PING: RFR: 8213734: SAXParser.parse(File, ..) does not close resources when Exception occurs. In-Reply-To: References: <0a64931ab640afd557f4bd46aa7bb05512bc79d6.camel@redhat.com> Message-ID: <3adc99dd5410882edcf129859ddfb7b0648c941d.camel@redhat.com> Hi! I'd appreciate a review of this one. Thanks in advance! See below. On Tue, 2019-09-03 at 17:50 +0200, Severin Gehwolf wrote: > On Mon, 2019-08-26 at 17:54 +0200, Severin Gehwolf wrote: > > Hi, > > > > Please review this 8u backport. The OpenJDK 11u patch does not apply > > cleanly after path-reshuffeling due to a) test and code for jaxp are > > split in JDK 8 b) Some rejects in comments - copyright and last > > modified date. I've omitted rejected comments. I can manually add them > > if that's preferred. See below. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213734 > > webrevs: > > jdk: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8213734/jdk8/jdk/01/webrev/ > > jaxp: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8213734/jdk8/jaxp/01/webrev/ > > > > Testing: tier1 on Linux x86_64. javax/xml/jaxp tests. New test on > > Windows without the fix fails and passes with it. > > > > Thanks to Simon Tooke who helped testing this patch on Windows. > > > > Rejects: > > $ cat src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java.rej > > --- XMLEntityManager.java > > +++ XMLEntityManager.java > > @@ -1,5 +1,5 @@ > > /* > > - * Copyright (c) 2009, 2017, Oracle and/or its affiliates. All rights reserved. > > + * Copyright (c) 2009, 2018, Oracle and/or its affiliates. All rights reserved. > > */ > > /* > > * Licensed to the Apache Software Foundation (ASF) under one or more > > @@ -89,7 +89,7 @@ > > * @author K.Venugopal SUN Microsystems > > * @author Neeraj Bajaj SUN Microsystems > > * @author Sunitha Reddy SUN Microsystems > > - * @LastModified: Oct 2017 > > + * @LastModified: Nov 2018 > > */ > > public class XMLEntityManager implements XMLComponent, XMLEntityResolver { > > > > Gentle reminder. Anyone? It's been a month :( FWIW, I've updated XMLEntityManager to include the copyright update upper bound to 2018. The @LastModified lines don't exist in JDK 8u, so I've omitted that. Latest webrevs: webrevs: jdk: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8213734/jdk8/jdk/01/webrev/ jaxp: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8213734/jdk8/jaxp/02/webrev/ Thanks, Severin From martinrb at google.com Fri Sep 27 13:04:47 2019 From: martinrb at google.com (Martin Buchholz) Date: Fri, 27 Sep 2019 06:04:47 -0700 Subject: CharsetEncoder.maxBytesPerChar() In-Reply-To: <20190926142336.572175248@eggemoggin.niobe.net> References: <07109047-3a9b-c784-4fa8-86616a3bc263@oracle.com> <20190920150339.254128936@eggemoggin.niobe.net> <5336b4de-cd28-c66b-963a-c5f63c8cb807@CoSoCo.de> <20190926142336.572175248@eggemoggin.niobe.net> Message-ID: Like Ulf, I am sometimes annoyed by the use of the "character" misnomer throughout the API docs, and would support an effort to use "character" the way that unicode.org uses it. "char" no longer represents a Unicode character, but at least it provides a short clear name, in the Java language, for "UTF-16 code unit" - if we use it consistently! https://unicode.org/faq/utf_bom.html#utf16-1 On Thu, Sep 26, 2019 at 2:24 PM wrote: > 2019/9/24 13:00:21 -0700, ulf.zibis at cosoco.de: > > Am 21.09.19 um 00:03 schrieb mark.reinhold at oracle.com: > >> To avoid this confusion, a more verbose specification might read: > >> * Returns the maximum number of $otype$s that will be produced for > each > >> * $itype$ of input. This value may be used to compute the > worst-case size > >> * of the output buffer required for a given input sequence. This > value > >> * accounts for any necessary content-independent prefix or suffix > >> #if[encoder] > >> * $otype$s, such as byte-order marks. > >> #end[encoder] > >> #if[decoder] > >> * $otype$s. > >> #end[decoder] > > > > wouldn't it be more clear to use "char" or even "{@code char}" instead > > "character" as replacment for the $xtype$ parameters? > > The specifications of the Charset{De,En}coder classes make it clear > up front that ?character? means ?sixteen-bit Unicode character,? so > I don?t think changing ?character? everywhere to ?{@code char}? is > necessary. > > This usage of ?character? is common throughout the API specification. > With the introduction of 32-bit Unicode characters we started calling > those ?code points,? but kept on calling sixteen-bit characters just > ?characters.? (I don?t think the official term ?Unicode code unit? > ever caught on, and it?s a bit of a mouthful anyway.) > > - Mark > From fw at deneb.enyo.de Fri Sep 27 13:23:54 2019 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 27 Sep 2019 15:23:54 +0200 Subject: Formatting rules for exception messages In-Reply-To: <20190327094525.87527075@eggemoggin.niobe.net> (mark reinhold's message of "Wed, 27 Mar 2019 09:45:25 -0700") References: <87o95zm9a2.fsf@mid.deneb.enyo.de> <20190327094525.87527075@eggemoggin.niobe.net> Message-ID: <87wodtna8l.fsf@mid.deneb.enyo.de> * mark reinhold: > 2019/3/25 5:24:37 -0700, Florian Weimer : >> Are there any guidelines for formatting exception messages? >> >> In particular, I'm interested in the case when the exception message >> is a (clipped) sentence. Is it supposed to start with a capital >> letter? >> >> If the message refers to a parameter name, the spelling should reflect >> the name exactly, of course. There seems to be a slight bias towards >> capitalization, based on a few greps. ... > > The first word of any exception message in code that I?ve written, or > reviewed, is always capitalized unless that word conveys case-sensitive > technical information (e.g., a parameter name, as you mentioned). This > improves readability, especially in longer exception messages that > contain additional punctuation characters. Thank you for confirming my observation. Would it make sense to have these rules documented somewhere? From sean.mullan at oracle.com Fri Sep 27 14:20:03 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 27 Sep 2019 10:20:03 -0400 Subject: RFR (XS) 8230415 : Avoid redundant permission checking in FilePermissionCollection and SocketPermissionCollection In-Reply-To: <7bf465d9-c5c0-c886-5aec-32ce79017b04@oracle.com> References: <7bf465d9-c5c0-c886-5aec-32ce79017b04@oracle.com> Message-ID: Hi Ivan, The fix looks good. Good catch. --Sean On 8/30/19 7:32 PM, Ivan Gerasimov wrote: > Hello! > > In the two implementations of PermissionCollection.implies(Permission), > all the permissions are traversed, and their corresponding bit mask are > checked. > > For example, here's a snippet from FilePermission.java: > > ??????? int desired = fperm.getMask(); > ??????? int effective = 0; > ??????? int needed = desired; > > ??????? for (Permission perm : perms.values()) { > ??????????? FilePermission fp = (FilePermission)perm; > ??????????? if (((needed & fp.getMask()) != 0) && > fp.impliesIgnoreMask(fperm)) { > ??????????????? effective |= fp.getMask(); > ??????????????? if ((effective & desired) == desired) { > ??????????????????? return true; > ??????????????? } > ??????????????? needed = (desired ^ effective);// <<< should be > (desired & ~effective) > ??????????? } > ??????? } > > Here, if a permission's mask `fp.getMask()` intersects with `needed`, > but does not fully cover all the needed bits, the variable `needed` is > updated as XOR of desired and effective. This can raise a > not-really-needed bits in the `needed` mask, so that for all subsequent > permissions from the collection with that unneeded bits in the mask, an > expensive fp.impliesIgnoreMask(fperm) will be executed. > > The fix does not change the behavior, but helps avoid unnecessary calls > to impliesIgnoreMask(). > > Would you please help review a trivial fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8230415 > WEBREV: http://cr.openjdk.java.net/~igerasim/8230415/00/webrev/ > > Thanks in advance! > From patrick.concannon at oracle.com Fri Sep 27 14:53:54 2019 From: patrick.concannon at oracle.com (Patrick Concannon) Date: Fri, 27 Sep 2019 15:53:54 +0100 Subject: RFR[8229338]: clean up test/jdk/java/util/RandomAccess/Basic.java In-Reply-To: References: <4b40de1d-c6a6-675f-60ea-fee4af8b66f4@oracle.com> Message-ID: Hi Lance, Thanks for your feedback. I've added in those changes, and you can find them in the new webrev linked below. webrev: http://cr.openjdk.java.net/~pconcannon/8229338/webrevs/webrev.01/ Kind regards, Patrick On 26/09/2019 13:36, Lance Andersen wrote: > Hi Patrick, > > Overall I think this looks ok. > > A few minor comments > > Please add?8229338 to the @bug line > > I might suggest adding either a comment to the DataProvider or the > test which uses it with an overview of the parameters to make it > easier and quicker for future maintainers to know the intent. > > Lines 86 and 91, you could if you want ?use String.format and just > substitute the changed values. > > Your testCopy and testFlil methods you can probably consider using a > DataProvider so that you can also test other types such as Vector or > was this intentional to omit them ? > > HTH > > Lance > >> On Sep 26, 2019, at 4:38 AM, Patrick Concannon >> > >> wrote: >> >> Hi, >> >> >> Would it be possible to have my fix for JDK-8229338 reviewed? >> >> This a general refactoring of >> test/jdk/java/util/RandomAccess/Basic.java as outlined in JDK-8229338 >> 'clean up test/jdk/java/util/RandomAccess/Basic.java'. >> >> >> Further information on this bug can be found here: >> https://bugs.openjdk.java.net/browse/JDK-8229338 >> >> Webrev: http://cr.openjdk.java.net/~pconcannon/8229338/webrevs/webrev.00/ >> >> >> Kind regards, >> >> Patrick >> > > > > 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 joe.darcy at oracle.com Fri Sep 27 16:00:59 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 27 Sep 2019 09:00:59 -0700 Subject: JDK 14 RFR of JDK-8231546: Suppress warnings on non-serializable instance fields in java.prefs module In-Reply-To: <2063227F-63F4-4F77-A9D8-8E6D9FC2E2B3@oracle.com> References: <2063227F-63F4-4F77-A9D8-8E6D9FC2E2B3@oracle.com> Message-ID: <811d717f-bf67-d826-978c-7157dd08ba34@oracle.com> Hmm. That would seem to be more consistent. I'll take another look and likely file a follow-up bug since I had already pushed JDK-8231546 when I saw this message. Thanks for the careful review, -Joe On 9/26/2019 12:58 PM, Chris Hegarty wrote: > +1. Should the @serial javadoc tag be removed? > > -Chris. > >> On 26 Sep 2019, at 19:27, Roger Riggs wrote: >> >> Looks fine, Joe >> >>> On 9/26/19 1:51 PM, Joe Darcy wrote: >>> Hello, >>> >>> Another part of the cleanup of library serialization usage ahead of augmented javac -Xlint warnings (JDK-8160675), the non-serializable instance fields of serializable types in the java.prefs module should have their serial warnings suppressed. The analogous issue in core libs is JDK-8231202. >>> >>> For the type in question, while NodeChangeEvent is typed as serializable, both its readObject and writeObject methods are written to unconditionally throw exceptions, so it is not serializable in practice. The class does define a serialVersionUID, so the one suspect field can be marked as "transient" without causing an effective change in serialization support. >>> >>> Patch below. >>> >>> Thanks, >>> >>> -Joe >>> >>> diff -r e23e560afbcb src/java.prefs/share/classes/java/util/prefs/NodeChangeEvent.java >>> --- a/src/java.prefs/share/classes/java/util/prefs/NodeChangeEvent.java Wed Sep 25 21:26:38 2019 -0700 >>> +++ b/src/java.prefs/share/classes/java/util/prefs/NodeChangeEvent.java Thu Sep 26 10:48:34 2019 -0700 >>> @@ -49,7 +49,7 @@ >>> * >>> * @serial >>> */ >>> - private Preferences child; >>> + private transient Preferences child; >>> >>> /** >>> * Constructs a new {@code NodeChangeEvent} instance. >>> >>> From huizhe.wang at oracle.com Fri Sep 27 16:29:53 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 27 Sep 2019 09:29:53 -0700 Subject: RFR [14/java.xml] 8016914: CoreDocumentImpl.setXmlVersion NPE Message-ID: Please review a fix to the NPE issue. This is part of the work on the XML declaration related issues. JBS: https://bugs.openjdk.java.net/browse/JDK-8016914 webrev: http://cr.openjdk.java.net/~joehw/jdk14/8016914/webrev/ Thanks, Joe From akozlov at azul.com Fri Sep 27 16:37:39 2019 From: akozlov at azul.com (Anton Kozlov) Date: Fri, 27 Sep 2019 19:37:39 +0300 Subject: RFR: 8231584: Deadlock with ClassLoader.findLibrary and System.loadLibrary call Message-ID: Hi, I think that JDK-8194653 [0] affects jdk/jdk and it doesn't specific to FileSystems.getDefault. I'm starting a new thread/bug as the original issue marked as resolved ([3]) Ryan, thanks for investigation and providing a test [1]! But the test fails in the same way if the FileSystems.getDefault replaced with anything that calls System.loadLibrary in an initializer. For jdk/jdk it may be jdk.net.ExtendedSocketOptions.SO_FLOW_SLA and the issue will arise. I don't think it's possible to provide a general fix for that. We are unable to prevent a user to take the Runtime's monitor and do initialization and loadLibrary, which make a room for deadlock. Taking the lock is incorrect action at first. We can only prevent doing that by accident. >From the original deadlock report [2], initialization and loadLibrary under the monitor caused not by java.* code, but class loader's findLibrary (sun.misc.ExtClassLoader to be specific). A workaround for ExtClassLoader is possible, to ensure all necessary classes are inited before findLibrary called, i.e. in the constructor. But then we should require the same for any custom class loader. Chances that it would be implemented correctly are not high since even ExtClassLoader is flawed. I propose to call a ClassLoader.findLibrary with Runtime's monitor unlocked: http://cr.openjdk.java.net/~akozlov/8231584/webrev.00 Thanks, Anton [0]: https://bugs.openjdk.java.net/browse/JDK-8194653 [1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-April/059811.html [2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-January/050819.html [3]: https://bugs.openjdk.java.net/browse/JDK-8231584 From Roger.Riggs at oracle.com Fri Sep 27 17:02:26 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 27 Sep 2019 13:02:26 -0400 Subject: RFR 8231427 (test) Warning cleanup in tests of java.io.Serializable Message-ID: <63539469-c100-20c7-f22c-cac31265d03b@oracle.com> Please review cleanup of tests in java/io/Serializable. There are warnings for mis-use of serialization methods and fields; some are intentional as they are the focus of the tests. The test code had quite a few warnings about raw types, deprecated methods, and missing serialVersionUIDs, and deprecated methods, etc. Issue: https://bugs.openjdk.java.net/browse/JDK-8231427 Webrev: http://cr.openjdk.java.net/~rriggs/webrev-ser-test-cleanup-8231427-2/ Thanks, Roger From lance.andersen at oracle.com Fri Sep 27 17:47:21 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 27 Sep 2019 13:47:21 -0400 Subject: RFR [14/java.xml] 8016914: CoreDocumentImpl.setXmlVersion NPE In-Reply-To: References: Message-ID: <496AB4BD-BF80-48B3-88D9-3721EB68C0FB@oracle.com> Hi Joe, The change looks fine as does the test. Best Lance > On Sep 27, 2019, at 12:29 PM, Joe Wang wrote: > > Please review a fix to the NPE issue. This is part of the work on the XML declaration related issues. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8016914 > webrev: http://cr.openjdk.java.net/~joehw/jdk14/8016914/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 Sep 27 17:51:46 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 27 Sep 2019 10:51:46 -0700 Subject: RFR [14/java.xml] 8016914: CoreDocumentImpl.setXmlVersion NPE In-Reply-To: <496AB4BD-BF80-48B3-88D9-3721EB68C0FB@oracle.com> References: <496AB4BD-BF80-48B3-88D9-3721EB68C0FB@oracle.com> Message-ID: Thanks Lance! On 9/27/19 10:47 AM, Lance Andersen wrote: > Hi Joe, > > The change looks fine as does the test. > > Best > Lance >> On Sep 27, 2019, at 12:29 PM, Joe Wang > > wrote: >> >> Please review a fix to the NPE issue. This is part of the work on the >> XML declaration related issues. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8016914 >> webrev: http://cr.openjdk.java.net/~joehw/jdk14/8016914/webrev/ >> >> Thanks, >> Joe > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle?Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From lance.andersen at oracle.com Fri Sep 27 18:31:11 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 27 Sep 2019 14:31:11 -0400 Subject: RFR[8229338]: clean up test/jdk/java/util/RandomAccess/Basic.java In-Reply-To: References: <4b40de1d-c6a6-675f-60ea-fee4af8b66f4@oracle.com> Message-ID: <9142E376-E4DE-404D-A52C-F11E2BBC221A@oracle.com> Hi Patrick, This looks much better. Best lance > On Sep 27, 2019, at 10:53 AM, Patrick Concannon wrote: > > Hi Lance, > > > > Thanks for your feedback. I've added in those changes, and you can find them in the new webrev linked below. > > webrev: http://cr.openjdk.java.net/~pconcannon/8229338/webrevs/webrev.01/ > > Kind regards, > > Patrick > > > On 26/09/2019 13:36, Lance Andersen wrote: >> Hi Patrick, >> >> Overall I think this looks ok. >> >> A few minor comments >> >> Please add 8229338 to the @bug line >> >> I might suggest adding either a comment to the DataProvider or the test which uses it with an overview of the parameters to make it easier and quicker for future maintainers to know the intent. >> >> Lines 86 and 91, you could if you want use String.format and just substitute the changed values. >> >> Your testCopy and testFlil methods you can probably consider using a DataProvider so that you can also test other types such as Vector or was this intentional to omit them ? >> >> HTH >> >> Lance >> >>> On Sep 26, 2019, at 4:38 AM, Patrick Concannon > wrote: >>> >>> Hi, >>> >>> >>> Would it be possible to have my fix for JDK-8229338 reviewed? >>> >>> This a general refactoring of test/jdk/java/util/RandomAccess/Basic.java as outlined in JDK-8229338 'clean up test/jdk/java/util/RandomAccess/Basic.java'. >>> >>> >>> Further information on this bug can be found here: https://bugs.openjdk.java.net/browse/JDK-8229338 >>> >>> Webrev: http://cr.openjdk.java.net/~pconcannon/8229338/webrevs/webrev.00/ >>> >>> >>> Kind regards, >>> >>> Patrick >>> >> >> >> >> 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 joe.darcy at oracle.com Fri Sep 27 18:45:47 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 27 Sep 2019 11:45:47 -0700 Subject: RFR 8231427 (test) Warning cleanup in tests of java.io.Serializable In-Reply-To: <63539469-c100-20c7-f22c-cac31265d03b@oracle.com> References: <63539469-c100-20c7-f22c-cac31265d03b@oracle.com> Message-ID: <7d7389b0-b060-5e7f-4f0f-1f98b9cef872@oracle.com> Hi Roger, Generally looks fine. Adding some comments about why the @SuppressWarnings annotations were being applied might help future readers of the code. Cheers, -Joe On 9/27/2019 10:02 AM, Roger Riggs wrote: > Please review cleanup of tests in java/io/Serializable. There are > warnings for mis-use of > serialization methods and fields; some are intentional as they are the > focus of the tests. > The test code had quite a few warnings about raw types, deprecated > methods, and > missing serialVersionUIDs, and deprecated methods, etc. > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8231427 > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-ser-test-cleanup-8231427-2/ > > Thanks, Roger > From mark.reinhold at oracle.com Fri Sep 27 18:56:30 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 27 Sep 2019 11:56:30 -0700 Subject: Formatting rules for exception messages In-Reply-To: <87wodtna8l.fsf@mid.deneb.enyo.de> References: <87o95zm9a2.fsf@mid.deneb.enyo.de> <20190327094525.87527075@eggemoggin.niobe.net> <87wodtna8l.fsf@mid.deneb.enyo.de> Message-ID: <20190927115630.706194298@eggemoggin.niobe.net> 2019/9/27 6:23:54 -0700, Florian Weimer : > * mark reinhold: > >> 2019/3/25 5:24:37 -0700, Florian Weimer : >>> Are there any guidelines for formatting exception messages? >>> >>> In particular, I'm interested in the case when the exception message >>> is a (clipped) sentence. Is it supposed to start with a capital >>> letter? >>> >>> If the message refers to a parameter name, the spelling should reflect >>> the name exactly, of course. There seems to be a slight bias towards >>> capitalization, based on a few greps. ... >> >> The first word of any exception message in code that I?ve written, or >> reviewed, is always capitalized unless that word conveys case-sensitive >> technical information (e.g., a parameter name, as you mentioned). This >> improves readability, especially in longer exception messages that >> contain additional punctuation characters. > > Thank you for confirming my observation. Would it make sense to have > these rules documented somewhere? Yes, it would. Perhaps an informational JEP -- I?ll add it to my queue. - Mark From martinrb at google.com Fri Sep 27 19:33:48 2019 From: martinrb at google.com (Martin Buchholz) Date: Fri, 27 Sep 2019 12:33:48 -0700 Subject: RFR: jsr166 integration 2019-09 In-Reply-To: References: <517197737.1773850.1568278129180.JavaMail.zimbra@u-pem.fr> <738837959.2535658.1568387411851.JavaMail.zimbra@u-pem.fr> <16d7944e-4b61-7ed9-aeea-fca44e970016@cs.oswego.edu> <1150861893.2564720.1568393036106.JavaMail.zimbra@u-pem.fr> <1a4c7ebd-78bd-de5b-7053-cff63f13bdeb@oracle.com> <86366d20-1ae0-6694-4b41-ce21dfb8ddbb@oracle.com> Message-ID: On Mon, Sep 23, 2019 at 11:08 PM David Holmes wrote: > Except when I run it through our test system ReservedStackTest is still > failing :( > > I tested it initially when Fred proposed it and that went fine. It also > passes for me locally on Linux. > I committed the changes other than for @ReservedStackAccess, which remains in limbo. From brian.burkhalter at oracle.com Sat Sep 28 00:25:37 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 27 Sep 2019 17:25:37 -0700 Subject: [Ping] 8229333: java/io/File/SetLastModified.java timed out References: Message-ID: <2A0235EA-9EC4-4591-9071-DA3CDC154A43@oracle.com> > Begin forwarded message: > > From: Brian Burkhalter > Subject: Re: 8229333: java/io/File/SetLastModified.java timed out > Date: September 6, 2019 at 9:36:39 AM PDT > To: core-libs-dev > > An alternative would be to increase the required memory: > > @@ -23,6 +23,7 @@ > > /* @test > @bug 4091757 6652379 8177809 > + @requires os.maxMemory >= 16G > @summary Basic test for setLastModified method > */ > > Thanks, > > Brian > >> On Aug 28, 2019, at 10:51 AM, Lance Andersen > wrote: >> >> Looks fine Brian, fingers crossed the little bugger does not come back :-) >> >>> On Aug 27, 2019, at 2:00 PM, Brian Burkhalter > wrote: >>> >>> The failure reported in [1] was observed to occur on two Mac minis with HDDs. Given the large file access it is possibly due to slow disk access. The suggested fix is to increase the timeout [2]. If it is still observed at a later date a new issue can be filed. >>> >>> Thanks, >>> >>> Brian >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8229333 >>> [2] diff: >>> >>> @@ -22,11 +22,13 @@ >>> */ >>> >>> /* @test >>> - @bug 4091757 6652379 8177809 >>> - @summary Basic test for setLastModified method >>> + * @bug 4091757 6652379 8177809 >>> + * @summary Basic test for setLastModified method >>> + * @run main/timeout=180 SetLastModified >>> */ >>> >>> -import java.io .*; >>> +import java.io.File; >>> +import java.io.FileOutputStream; >>> import java.nio.ByteBuffer; >>> import java.nio.channels.FileChannel; >> >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> > From alexander.matveev at oracle.com Sat Sep 28 03:55:30 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Fri, 27 Sep 2019 20:55:30 -0700 Subject: RFR: JDK-8231281: Consider eliminating --identifier option Message-ID: <7c819a79-0503-4e78-c565-775e8b3d5154@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). - Removed --identifier option, since it only usage is to specify identifier when generating pkg on macOS and as default value for --mac-package-identifier. - Specifying identifier is no longer needed when generating pkg from app image and it will be extract from app image by default. --mac-package-identifier can be used to overwrite default value. - Removed check for identifier from DMG bundler, since it is not required by DMG. [1] https://bugs.openjdk.java.net/browse/JDK-8231281 [2] http://cr.openjdk.java.net/~almatvee/8231281/webrev.00/ Thanks, Alexander From peter.levart at gmail.com Sat Sep 28 08:38:43 2019 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 28 Sep 2019 10:38:43 +0200 Subject: RandomAccess Interface and List Heirarchy In-Reply-To: <1062347590.1395885.1569406540881.JavaMail.zimbra@u-pem.fr> References: <1062347590.1395885.1569406540881.JavaMail.zimbra@u-pem.fr> Message-ID: <060d71d4-66e5-b593-dd72-e187b1dc8ae9@gmail.com> 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. That brings me to the question: Is it possible and how to deprecate only one aspect of a particular implementation - in this case the List interface of the LinkedList? In this concrete case, and also because it would be strange to have a class called LinkedList implementing only Deque interface, it may be an alternative to 1st create a replacement in the form of LinkedDeque implements Deque, and then deprecating the whole LinkedList. As always there are pros and cons to a particular "solution": 1. Do nothing pros: - no refactoring of old code needed cons: - performance problems continue as inexperienced programmers couple LinkedList with typical indexed accesses of List interface - hard discoverability of single-threaded "linked" Deque implementation continues - LinkedList is not a name that comes to mind when searching for Deque implementation - this is less of a problem nowadays as we have tools like Ctrl-H in IDEA, ... 2a. Deprecate the List aspect of LinkedList and eventually remove the List interface from the LinkedList pros: - performance problems eventually solved - at least some of the usages of LinkedList would remain valid: Deque d = new LinkedList<>(); cons: - compatibility risk - all uses of LinkedList that assume it implements List interface will have to be refactored - hard discoverability of single-threaded "linked" Deque implementation continues - LinkedList is not a name that comes to mind 2b. Deprecate the List aspect of LinkedList with not planned removal of the List interface from the LinkedList pros: - performance problems eventually solved - at least some of the usages of LinkedList would remain valid: Deque d = new LinkedList<>(); not even warnings suppression would be needed - no immediate compatibility risk - only suppressing warnings may be needed in short term cons: - hard discoverability of single-threaded "linked" Deque implementation continues - LinkedList is not a name that comes to mind 3. Create a replacement LinkedDeque implementation of Deque and deprecate LinkedList (with no planned removal) pros: - performance problems eventually solved as new code typically would refrain from using LinkedList for the List purpose and would start using LinkedDeque for the Deque purpose - no refactoring of old code needed (at least not in the near future) - better discoverability of single-threaded "linked" Deque implementation cons: - new type to learn - code using new type would not compile/run on old JDKs - adoption rate of new type would be slow 2b is most promising IMO. But is there an effective way to deprecate the List aspect of the LinkedList? What would be needed is a particular use of @Deprecated annotation that would cause usages like this: ??? List l = new LinkedList<>(); produce compile-time deprecation warnings, but usages like this: ?? Deque d = new LinkedList<>(); not produce warnings. The 1st thing that comes to mind is adding a TYPE_USE to the list of @Target(s) of the @Deprecated annotation and then using it like this: public class LinkedList ??? extends AbstractSequentialList ??? implements @Deprecated List, Deque, Cloneable, java.io.Serializable Would this make sense? Regards, Peter From forax at univ-mlv.fr Sat Sep 28 11:34:51 2019 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sat, 28 Sep 2019 13:34:51 +0200 (CEST) Subject: RandomAccess Interface and List Heirarchy In-Reply-To: <060d71d4-66e5-b593-dd72-e187b1dc8ae9@gmail.com> References: <1062347590.1395885.1569406540881.JavaMail.zimbra@u-pem.fr> <060d71d4-66e5-b593-dd72-e187b1dc8ae9@gmail.com> Message-ID: <1628864341.2674360.1569670491259.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Peter Levart" > ?: "Remi Forax" , "Cyrus Vafadari" > Cc: "core-libs-dev" > Envoy?: Samedi 28 Septembre 2019 10:38:43 > Objet: Re: RandomAccess Interface and List Heirarchy > 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. That brings me to the question: Is it > possible and how to deprecate only one aspect of a particular > implementation - in this case the List interface of the LinkedList? In > this concrete case, and also because it would be strange to have a class > called LinkedList implementing only Deque interface, it may be an > alternative to 1st create a replacement in the form of LinkedDeque > implements Deque, and then deprecating the whole LinkedList. > > As always there are pros and cons to a particular "solution": > > 1. Do nothing > pros: > - no refactoring of old code needed > cons: > - performance problems continue as inexperienced programmers couple > LinkedList with typical indexed accesses of List interface > - hard discoverability of single-threaded "linked" Deque implementation > continues - LinkedList is not a name that comes to mind when searching > for Deque implementation - this is less of a problem nowadays as we have > tools like Ctrl-H in IDEA, ... > > 2a. Deprecate the List aspect of LinkedList and eventually remove the > List interface from the LinkedList > pros: > - performance problems eventually solved > - at least some of the usages of LinkedList would remain valid: Deque > d = new LinkedList<>(); > cons: > - compatibility risk - all uses of LinkedList that assume it implements > List interface will have to be refactored > - hard discoverability of single-threaded "linked" Deque implementation > continues - LinkedList is not a name that comes to mind > > 2b. Deprecate the List aspect of LinkedList with not planned removal of > the List interface from the LinkedList > pros: > - performance problems eventually solved > - at least some of the usages of LinkedList would remain valid: Deque > d = new LinkedList<>(); not even warnings suppression would be needed > - no immediate compatibility risk - only suppressing warnings may be > needed in short term > cons: > - hard discoverability of single-threaded "linked" Deque implementation > continues - LinkedList is not a name that comes to mind > > 3. Create a replacement LinkedDeque implementation of Deque and > deprecate LinkedList (with no planned removal) > pros: > - performance problems eventually solved as new code typically would > refrain from using LinkedList for the List purpose and would start using > LinkedDeque for the Deque purpose > - no refactoring of old code needed (at least not in the near future) > - better discoverability of single-threaded "linked" Deque implementation > cons: > - new type to learn > - code using new type would not compile/run on old JDKs - adoption rate > of new type would be slow > > > 2b is most promising IMO. But is there an effective way to deprecate the > List aspect of the LinkedList? What would be needed is a particular use > of @Deprecated annotation that would cause usages like this: > > ??? List l = new LinkedList<>(); > > produce compile-time deprecation warnings, but usages like this: > > ?? Deque d = new LinkedList<>(); > > not produce warnings. > > The 1st thing that comes to mind is adding a TYPE_USE to the list of > @Target(s) of the @Deprecated annotation and then using it like this: > > public class LinkedList > ??? extends AbstractSequentialList > ??? implements @Deprecated List, Deque, Cloneable, > java.io.Serializable > > > Would this make sense? For 2b, you don't have to have a syntax for that, it can be one line of code in the compiler. Introducing an exotic syntax for an exotic use case is generally not a good idea, it's better to solve it in an ad hoc way. I don't think we need to find a replacement to LinkedList seen as a Deque given that perf wise it's always better to use an ArrayDeque instead. But i may be wrong. so i'm more for option 0, deprecate LinkedList, provide no replacement for LinkedList as a Deque. > > > Regards, Peter regards, R?mi From andy.herrick at oracle.com Sat Sep 28 12:13:06 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Sat, 28 Sep 2019 08:13:06 -0400 Subject: RFR: JDK-8231281: Consider eliminating --identifier option In-Reply-To: <7c819a79-0503-4e78-c565-775e8b3d5154@oracle.com> References: <7c819a79-0503-4e78-c565-775e8b3d5154@oracle.com> Message-ID: <63fca2ef-8c42-53cc-9596-75f112d333d1@oracle.com> looks good. /Andy On 9/27/2019 11:55 PM, Alexander Matveev wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > - Removed --identifier option, since it only usage is to specify > identifier when generating pkg on macOS and as default value for > --mac-package-identifier. > - Specifying identifier is no longer needed when generating pkg from > app image and it will be extract from app image by default. > --mac-package-identifier can be used to overwrite default value. > - Removed check for identifier from DMG bundler, since it is not > required by DMG. > > [1] https://bugs.openjdk.java.net/browse/JDK-8231281 > > [2] http://cr.openjdk.java.net/~almatvee/8231281/webrev.00/ > > Thanks, > Alexander From TobiasDiez at gmx.de Fri Sep 27 19:07:13 2019 From: TobiasDiez at gmx.de (Tobias Diez) Date: Fri, 27 Sep 2019 21:07:13 +0200 Subject: [jpackage] Run custom action/script during installation Message-ID: <000201d57566$c5b5aef0$51210cd0$@gmx.de> Hi all, I've been experimenting with the recent build of jpackage and in general it is working quite well. Thanks for your work! One feature that I was strongly missing (or at least couldn't find anything in the docs) is to run an own script during installation. For example, I need to register components in the registry (for Windows), create files (e.g. in /Library on Mac or /usr/lib/ on Linux) and copy custom resources to the installation directory. It would be nice to add such a feature because I guess most installers need to do more than copying a few files into a given folder. Best regards Tobias From philip.race at oracle.com Sat Sep 28 19:48:10 2019 From: philip.race at oracle.com (Philip Race) Date: Sat, 28 Sep 2019 12:48:10 -0700 Subject: RFR: JDK-8231281: Consider eliminating --identifier option In-Reply-To: <7c819a79-0503-4e78-c565-775e8b3d5154@oracle.com> References: <7c819a79-0503-4e78-c565-775e8b3d5154@oracle.com> Message-ID: <5D8FB8FA.8070706@oracle.com> + // Get indetifier from app image if user provided app image and + // does not provided identifier via CLI. + String indentifier = extractBundleIdentifier(params); + if (indentifier != null) { + return indentifier; the variable name and the comment both spell identifier incorrectly and "does not provided" should be written "did not provide the" I must be missing something because you seem to be adding a dependency on the javax.xml module, yet I don't see a "requires" import for that in the shared module-info.java or the macos platform extra file. Oh .. I get it, jdk.jpackage requires java.desktop and it in turn requires transitive java.xml because it re-exports some of those APIs. I don't know that this unrelated use we are making here is really the intended use of requires transitive, but I suppose we can address that another day ... -phil. On 9/27/19, 8:55 PM, Alexander Matveev wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > - Removed --identifier option, since it only usage is to specify > identifier when generating pkg on macOS and as default value for > --mac-package-identifier. > - Specifying identifier is no longer needed when generating pkg from > app image and it will be extract from app image by default. > --mac-package-identifier can be used to overwrite default value. > - Removed check for identifier from DMG bundler, since it is not > required by DMG. > > [1] https://bugs.openjdk.java.net/browse/JDK-8231281 > > [2] http://cr.openjdk.java.net/~almatvee/8231281/webrev.00/ > > Thanks, > Alexander From andy.herrick at oracle.com Sun Sep 29 14:08:31 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Sun, 29 Sep 2019 10:08:31 -0400 Subject: RFR: JDK-8230920 : jpackage problems when -input dir contains any files with "cfg" extension. In-Reply-To: References: Message-ID: <3eb7a77e-eb65-8242-5504-7be300230d32@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). The revised fix stores an xml file (.jpackage.xml) in the app-image so that jpackage commands using that app-image can determine some things previously available only when building the app-image, such as the name of the application and the name of additional launchers. Initially this is only used on windows, but should be later used on linux and possibly macOS as well (if additional data needed by dmg or pkg building are identified). The windows fix also ensures that shortcuts are created for all launchers (when shortcut hint option(s) are used). [1] https://bugs.openjdk.java.net/browse/JDK-8230920 [3] http://cr.openjdk.java.net/~herrick/8230920/webrev.01/ /Andy On 9/24/2019 8:54 AM, Andy Herrick wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > This fix replaces the practice we were using on windows to determine > the application name, and name of additional launchers (by looking for > ".cfg" files in the app dir. > > Instead we now add a file ".jpackage.args" to the root of the > app-image, and record in that file all the arguments used to create > the app-image.? We later read that file to determine the original app > name and any additional launcher names. > > This change also fixes the shortcut creation on windows to create > shortcuts (if so directed) for all launchers. > > [1] https://bugs.openjdk.java.net/browse/JDK-8230920 > > [2] http://cr.openjdk.java.net/~herrick/8230920/webrev.01/ > > /Andy > From alexey.semenyuk at oracle.com Sun Sep 29 14:23:42 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Sun, 29 Sep 2019 10:23:42 -0400 Subject: RFR: JDK-8230920 : jpackage problems when -input dir contains any files with "cfg" extension. In-Reply-To: <3eb7a77e-eb65-8242-5504-7be300230d32@oracle.com> References: <3eb7a77e-eb65-8242-5504-7be300230d32@oracle.com> Message-ID: <2d21564a-c8d1-a750-6c1c-16f10efb93ff@oracle.com> I guess it was a type in webrev adderss. Should be http://cr.openjdk.java.net/~herrick/8230920/webrev.03/ This webrev looks good. - Alexey On 9/29/2019 10:08 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). > > The revised fix stores an xml file (.jpackage.xml) in the app-image so > that jpackage commands using that app-image can determine some things > previously available only when building the app-image, such as the > name of the application and the name of additional launchers. > > Initially this is only used on windows, but should be later used on > linux and possibly macOS as well (if additional data needed by dmg or > pkg building are identified). > > The windows fix also ensures that shortcuts are created for all > launchers (when shortcut hint option(s) are used). > > [1] https://bugs.openjdk.java.net/browse/JDK-8230920 > > [3] http://cr.openjdk.java.net/~herrick/8230920/webrev.01/ > > /Andy > > On 9/24/2019 8:54 AM, Andy Herrick wrote: >> Please review the jpackage fix for bug [1] at [2]. >> >> This is a fix for the JDK-8200758-branch branch of the open sandbox >> repository (jpackage). >> >> This fix replaces the practice we were using on windows to determine >> the application name, and name of additional launchers (by looking >> for ".cfg" files in the app dir. >> >> Instead we now add a file ".jpackage.args" to the root of the >> app-image, and record in that file all the arguments used to create >> the app-image.? We later read that file to determine the original app >> name and any additional launcher names. >> >> This change also fixes the shortcut creation on windows to create >> shortcuts (if so directed) for all launchers. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8230920 >> >> [2] http://cr.openjdk.java.net/~herrick/8230920/webrev.01/ >> >> /Andy >> From andy.herrick at oracle.com Sun Sep 29 14:37:27 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Sun, 29 Sep 2019 10:37:27 -0400 Subject: RFR: JDK-8230920 : jpackage problems when -input dir contains any files with "cfg" extension. In-Reply-To: <2d21564a-c8d1-a750-6c1c-16f10efb93ff@oracle.com> References: <3eb7a77e-eb65-8242-5504-7be300230d32@oracle.com> <2d21564a-c8d1-a750-6c1c-16f10efb93ff@oracle.com> Message-ID: <332cad09-a538-80ae-2c2c-0ba28f5487c1@oracle.com> Yes? - I meant webrev.03 Sorry /Andy On 9/29/19 10:23 AM, Alexey Semenyuk wrote: > I guess it was a type in webrev adderss. Should be > http://cr.openjdk.java.net/~herrick/8230920/webrev.03/ > > This webrev looks good. > > - Alexey > > On 9/29/2019 10:08 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). >> >> The revised fix stores an xml file (.jpackage.xml) in the app-image >> so that jpackage commands using that app-image can determine some >> things previously available only when building the app-image, such as >> the name of the application and the name of additional launchers. >> >> Initially this is only used on windows, but should be later used on >> linux and possibly macOS as well (if additional data needed by dmg or >> pkg building are identified). >> >> The windows fix also ensures that shortcuts are created for all >> launchers (when shortcut hint option(s) are used). >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8230920 >> >> [3] http://cr.openjdk.java.net/~herrick/8230920/webrev.01/ >> >> /Andy >> >> On 9/24/2019 8:54 AM, Andy Herrick wrote: >>> Please review the jpackage fix for bug [1] at [2]. >>> >>> This is a fix for the JDK-8200758-branch branch of the open sandbox >>> repository (jpackage). >>> >>> This fix replaces the practice we were using on windows to determine >>> the application name, and name of additional launchers (by looking >>> for ".cfg" files in the app dir. >>> >>> Instead we now add a file ".jpackage.args" to the root of the >>> app-image, and record in that file all the arguments used to create >>> the app-image.? We later read that file to determine the original >>> app name and any additional launcher names. >>> >>> This change also fixes the shortcut creation on windows to create >>> shortcuts (if so directed) for all launchers. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8230920 >>> >>> [2] http://cr.openjdk.java.net/~herrick/8230920/webrev.01/ >>> >>> /Andy >>> > From alexey.semenyuk at oracle.com Sun Sep 29 20:06:17 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Sun, 29 Sep 2019 16:06:17 -0400 Subject: RFR: JDK-8230920 : jpackage problems when -input dir contains any files with "cfg" extension. In-Reply-To: <332cad09-a538-80ae-2c2c-0ba28f5487c1@oracle.com> References: <3eb7a77e-eb65-8242-5504-7be300230d32@oracle.com> <2d21564a-c8d1-a750-6c1c-16f10efb93ff@oracle.com> <332cad09-a538-80ae-2c2c-0ba28f5487c1@oracle.com> Message-ID: One thing that I just notice is that you introduced caching in AppImageFile file. The caching doesn't take into consideration that different values can be passed in AppImageFile.get() function. So if the function would be called multiple times with different values of `appImageDir` parameter the same AppImageFile instance will be returned in all the calls. Unfortunately unit tests didn't catch this. I suggest you either fix the caching logic or get rid of it in AppImageFile class. - Alexey On 9/29/2019 10:37 AM, Andy Herrick wrote: > Yes? - I meant webrev.03 > > Sorry > > /Andy > > On 9/29/19 10:23 AM, Alexey Semenyuk wrote: >> I guess it was a type in webrev adderss. Should be >> http://cr.openjdk.java.net/~herrick/8230920/webrev.03/ >> >> This webrev looks good. >> >> - Alexey >> >> On 9/29/2019 10:08 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). >>> >>> The revised fix stores an xml file (.jpackage.xml) in the app-image >>> so that jpackage commands using that app-image can determine some >>> things previously available only when building the app-image, such >>> as the name of the application and the name of additional launchers. >>> >>> Initially this is only used on windows, but should be later used on >>> linux and possibly macOS as well (if additional data needed by dmg >>> or pkg building are identified). >>> >>> The windows fix also ensures that shortcuts are created for all >>> launchers (when shortcut hint option(s) are used). >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8230920 >>> >>> [3] http://cr.openjdk.java.net/~herrick/8230920/webrev.01/ >>> >>> /Andy >>> >>> On 9/24/2019 8:54 AM, Andy Herrick wrote: >>>> Please review the jpackage fix for bug [1] at [2]. >>>> >>>> This is a fix for the JDK-8200758-branch branch of the open sandbox >>>> repository (jpackage). >>>> >>>> This fix replaces the practice we were using on windows to >>>> determine the application name, and name of additional launchers >>>> (by looking for ".cfg" files in the app dir. >>>> >>>> Instead we now add a file ".jpackage.args" to the root of the >>>> app-image, and record in that file all the arguments used to create >>>> the app-image.? We later read that file to determine the original >>>> app name and any additional launcher names. >>>> >>>> This change also fixes the shortcut creation on windows to create >>>> shortcuts (if so directed) for all launchers. >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8230920 >>>> >>>> [2] http://cr.openjdk.java.net/~herrick/8230920/webrev.01/ >>>> >>>> /Andy >>>> >> From alexey.semenyuk at oracle.com Sun Sep 29 20:50:53 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Sun, 29 Sep 2019 16:50:53 -0400 Subject: RFR: JDK-8231605: Improve test helpers In-Reply-To: <8415f13f-2c13-bf32-c82a-640a9040b9a7@oracle.com> References: <8415f13f-2c13-bf32-c82a-640a9040b9a7@oracle.com> 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 fix: - Improve jpackage test helpers. - Implement jdk.jpackage.internal.ApplicationLayout class on all platforms. - Functionality of all deleted tests moved into the new BasicTest.java based on the new test helper classes. The long term plan is to refactor existing tests based on the old test helpers using the new testing classes. For now it is suggested to implement all new tests with the new test helpers using BasicTest.java as a reference. BasicTest not in the default but in jdk.jpackage.tests package intentionally. It is not directly executed by jtreg harness, but indirectly through test helper, so jtreg has no issues locating it. The reason to keep test classes away from the default package is that NetBeans is very slow on projects with many classes in the default package, so the expectation is that it will work faster of the project with jpackage tests after they get moved out from the default package. [1] https://bugs.openjdk.java.net/browse/JDK-8231605 [2] http://cr.openjdk.java.net/~asemenyuk/8231605/webrev.00/ From alexey.semenyuk at oracle.com Sun Sep 29 22:08:05 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Sun, 29 Sep 2019 18:08:05 -0400 Subject: RFR: JDK-8231280: Linux packages produced by jpackage should have correct dependencies In-Reply-To: References: Message-ID: <917eff6c-801b-c186-f3fe-e04eee171848@oracle.com> Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). The fix adds use of `ldd` command and packaging specific tools to build list of packages required by a package produced by jpackage. Baseline for review is [3]. [1] https://bugs.openjdk.java.net/browse/JDK-8231280 [2] http://cr.openjdk.java.net/~asemenyuk/8231280/webrev.01/ [3] http://cr.openjdk.java.net/~asemenyuk/8231605/webrev.00/ From alexey.semenyuk at oracle.com Sun Sep 29 23:45:58 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Sun, 29 Sep 2019 19:45:58 -0400 Subject: RFR: JDK-8230974: creating rpm, get error for relative path to the license.txt In-Reply-To: <917eff6c-801b-c186-f3fe-e04eee171848@oracle.com> References: <917eff6c-801b-c186-f3fe-e04eee171848@oracle.com> Message-ID: <57db7b7a-0e41-6a1e-c3c1-e5c59096cbbc@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). Baseline for review is [3]. [1] https://bugs.openjdk.java.net/browse/JDK-8230974 [2] http://cr.openjdk.java.net/~asemenyuk/8230974/webrev.00/ [3] http://cr.openjdk.java.net/~asemenyuk/8231280/webrev.01/ From supermonkey at gmail.com Sat Sep 28 23:16:01 2019 From: supermonkey at gmail.com (Jeff Davidson) Date: Sat, 28 Sep 2019 16:16:01 -0700 Subject: Invalid .pkg file generated when name has space in it Message-ID: Hi, First of all, sorry in advance if there is a more appropriate place or system to report this issue. I'm not yet familiar with reporting Java bugs. Please let me know if that's the case. I'm testing out jpackage (using the 14-jpackage+1-35 build at https://jdk.java.net/jpackage/) and am seeing an issue with .pkg files when there are spaces in the --name argument. I made a simple .jar with a main class that prints "Hello world" and tested generated packages using the following three commands: $ jpackage --package-type dmg --output build/ -i . -n "Hello world" --main-jar Test.jar $ jpackage --package-type pkg --output build/ -i . -n "Hello world" --main-jar Test.jar $ jpackage --package-type pkg --output build/ -i . -n "Hello" --main-jar Test.jar The first command produces a .dmg file that is 50.4 MB in size. However, the second command, which is identical to the first except for the package type, produces a .pkg file which is only 4 KB in size and thus seemingly invalid. The third command, which is identical to the second except that there are no spaces in the name, produces a .pkg file which is 95.5 MB in size. Is this an issue in jpackage or in how I'm using it? If the former, is this a known issue? Please let me know if there is any more information I can provide. Thanks, Jeff From Ulf.Zibis at CoSoCo.de Mon Sep 30 09:35:16 2019 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Mon, 30 Sep 2019 11:35:16 +0200 Subject: CharsetEncoder.maxBytesPerChar() In-Reply-To: References: <07109047-3a9b-c784-4fa8-86616a3bc263@oracle.com> <20190920150339.254128936@eggemoggin.niobe.net> <5336b4de-cd28-c66b-963a-c5f63c8cb807@CoSoCo.de> <20190926142336.572175248@eggemoggin.niobe.net> Message-ID: Hey Martin, great, that you got my issue. The link you shared is an interesting basis for this discussion. Maybe at some places e.g. in the "upfront specifications", additionally the term "UTF-16 char" or "UTF-16 code unit" could be helpful and then determining "char" or "{@code char}" as a short cut. -Ulf Am 27.09.19 um 15:04 schrieb Martin Buchholz: > Like Ulf, I am sometimes annoyed by the use of the "character" > misnomer throughout the API docs, and would support an effort to use > "character" the way that unicode.org uses it. > "char" no longer represents a Unicode character, but at least it > provides a short clear name, in the Java language, for "UTF-16 code > unit" - if we use it consistently! > https://unicode.org/faq/utf_bom.html#utf16-1 > > On Thu, Sep 26, 2019 at 2:24 PM > wrote: > > 2019/9/24 13:00:21 -0700, ulf.zibis at cosoco.de > : > > Am 21.09.19 um 00:03 schrieb mark.reinhold at oracle.com > : > >> To avoid this confusion, a more verbose specification might read: > >>? ? ?* Returns the maximum number of $otype$s that will be > produced for each > >>? ? ?* $itype$ of input.? This value may be used to compute the > worst-case size > >>? ? ?* of the output buffer required for a given input sequence. > This value > >>? ? ?* accounts for any necessary content-independent prefix or > suffix > >> #if[encoder] > >>? ? ?* $otype$s, such as byte-order marks. > >> #end[encoder] > >> #if[decoder] > >>? ? ?* $otype$s. > >> #end[decoder] > > > > wouldn't it be more clear to use "char" or even "{@code char}" > instead > > "character" as replacment for the $xtype$ parameters? > > The specifications of the Charset{De,En}coder classes make it clear > up front that ?character? means ?sixteen-bit Unicode character,? so > I don?t think changing ?character? everywhere to ?{@code char}? is > necessary. > > This usage of ?character? is common throughout the API specification. > With the introduction of 32-bit Unicode characters we started calling > those ?code points,? but kept on calling sixteen-bit characters just > ?characters.?? (I don?t think the official term ?Unicode code unit? > ever caught on, and it?s a bit of a mouthful anyway.) > > - Mark > From andy.herrick at oracle.com Mon Sep 30 11:31:47 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 30 Sep 2019 07:31:47 -0400 Subject: RFR: JDK-8230920 : jpackage problems when -input dir contains any files with "cfg" extension. In-Reply-To: References: <3eb7a77e-eb65-8242-5504-7be300230d32@oracle.com> <2d21564a-c8d1-a750-6c1c-16f10efb93ff@oracle.com> <332cad09-a538-80ae-2c2c-0ba28f5487c1@oracle.com> Message-ID: Please review the revised jpackage fix for bug [1] at [4]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). I have removed the caching in AppImageFile and moved it to the caller, in this case WinMsiBundler, where the knowledge resides that the value of the arg to AppImageFile.load() is not changeable . [1] https://bugs.openjdk.java.net/browse/JDK-8230920 [4] http://cr.openjdk.java.net/~herrick/8230920/webrev.04/ /Andy On 9/29/2019 4:06 PM, Alexey Semenyuk wrote: > One thing that I just notice is that you introduced caching in > AppImageFile file. The caching doesn't take into consideration that > different values can be passed in AppImageFile.get() function. So if > the function would be called multiple times with different values of > `appImageDir` parameter the same AppImageFile instance will be > returned in all the calls. Unfortunately unit tests didn't catch this. > I suggest you either fix the caching logic or get rid of it in > AppImageFile class. > > - Alexey > > On 9/29/2019 10:37 AM, Andy Herrick wrote: >> Yes? - I meant webrev.03 >> >> Sorry >> >> /Andy >> >> On 9/29/19 10:23 AM, Alexey Semenyuk wrote: >>> I guess it was a type in webrev adderss. Should be >>> http://cr.openjdk.java.net/~herrick/8230920/webrev.03/ >>> >>> This webrev looks good. >>> >>> - Alexey >>> >>> On 9/29/2019 10:08 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). >>>> >>>> The revised fix stores an xml file (.jpackage.xml) in the app-image >>>> so that jpackage commands using that app-image can determine some >>>> things previously available only when building the app-image, such >>>> as the name of the application and the name of additional launchers. >>>> >>>> Initially this is only used on windows, but should be later used on >>>> linux and possibly macOS as well (if additional data needed by dmg >>>> or pkg building are identified). >>>> >>>> The windows fix also ensures that shortcuts are created for all >>>> launchers (when shortcut hint option(s) are used). >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8230920 >>>> >>>> [3] http://cr.openjdk.java.net/~herrick/8230920/webrev.01/ >>>> >>>> /Andy >>>> >>>> On 9/24/2019 8:54 AM, Andy Herrick wrote: >>>>> Please review the jpackage fix for bug [1] at [2]. >>>>> >>>>> This is a fix for the JDK-8200758-branch branch of the open >>>>> sandbox repository (jpackage). >>>>> >>>>> This fix replaces the practice we were using on windows to >>>>> determine the application name, and name of additional launchers >>>>> (by looking for ".cfg" files in the app dir. >>>>> >>>>> Instead we now add a file ".jpackage.args" to the root of the >>>>> app-image, and record in that file all the arguments used to >>>>> create the app-image.? We later read that file to determine the >>>>> original app name and any additional launcher names. >>>>> >>>>> This change also fixes the shortcut creation on windows to create >>>>> shortcuts (if so directed) for all launchers. >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8230920 >>>>> >>>>> [2] http://cr.openjdk.java.net/~herrick/8230920/webrev.01/ >>>>> >>>>> /Andy >>>>> >>> > From andy.herrick at oracle.com Mon Sep 30 11:57:41 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 30 Sep 2019 07:57:41 -0400 Subject: RFR: JDK-8230974: creating rpm, get error for relative path to the license.txt In-Reply-To: <57db7b7a-0e41-6a1e-c3c1-e5c59096cbbc@oracle.com> References: <917eff6c-801b-c186-f3fe-e04eee171848@oracle.com> <57db7b7a-0e41-6a1e-c3c1-e5c59096cbbc@oracle.com> Message-ID: <8a26b925-6383-a2d2-e5ac-6b84d9ca579f@oracle.com> looks good. /Andy ps: still studying the two prerequisite patches. On 9/29/2019 7:45 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). > > Baseline for review is [3]. > > [1] https://bugs.openjdk.java.net/browse/JDK-8230974 > > [2] http://cr.openjdk.java.net/~asemenyuk/8230974/webrev.00/ > > [3] http://cr.openjdk.java.net/~asemenyuk/8231280/webrev.01/ > From alexey.semenyuk at oracle.com Mon Sep 30 12:01:56 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Mon, 30 Sep 2019 08:01:56 -0400 Subject: RFR: JDK-8230920 : jpackage problems when -input dir contains any files with "cfg" extension. In-Reply-To: References: <3eb7a77e-eb65-8242-5504-7be300230d32@oracle.com> <2d21564a-c8d1-a750-6c1c-16f10efb93ff@oracle.com> <332cad09-a538-80ae-2c2c-0ba28f5487c1@oracle.com> Message-ID: <024b77a6-17e4-88f1-8628-d57ae39a07ec@oracle.com> Looks good. - Alexey On 9/30/2019 7:31 AM, Andy Herrick wrote: > Please review the revised jpackage fix for bug [1] at [4]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > I have removed the caching in AppImageFile and moved it to the caller, > in this case WinMsiBundler, where the knowledge resides that the value > of the arg to AppImageFile.load() is not changeable . > > [1] https://bugs.openjdk.java.net/browse/JDK-8230920 > > [4] http://cr.openjdk.java.net/~herrick/8230920/webrev.04/ > > /Andy > > On 9/29/2019 4:06 PM, Alexey Semenyuk wrote: >> One thing that I just notice is that you introduced caching in >> AppImageFile file. The caching doesn't take into consideration that >> different values can be passed in AppImageFile.get() function. So if >> the function would be called multiple times with different values of >> `appImageDir` parameter the same AppImageFile instance will be >> returned in all the calls. Unfortunately unit tests didn't catch >> this. I suggest you either fix the caching logic or get rid of it in >> AppImageFile class. >> >> - Alexey >> >> On 9/29/2019 10:37 AM, Andy Herrick wrote: >>> Yes? - I meant webrev.03 >>> >>> Sorry >>> >>> /Andy >>> >>> On 9/29/19 10:23 AM, Alexey Semenyuk wrote: >>>> I guess it was a type in webrev adderss. Should be >>>> http://cr.openjdk.java.net/~herrick/8230920/webrev.03/ >>>> >>>> This webrev looks good. >>>> >>>> - Alexey >>>> >>>> On 9/29/2019 10:08 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). >>>>> >>>>> The revised fix stores an xml file (.jpackage.xml) in the >>>>> app-image so that jpackage commands using that app-image can >>>>> determine some things previously available only when building the >>>>> app-image, such as the name of the application and the name of >>>>> additional launchers. >>>>> >>>>> Initially this is only used on windows, but should be later used >>>>> on linux and possibly macOS as well (if additional data needed by >>>>> dmg or pkg building are identified). >>>>> >>>>> The windows fix also ensures that shortcuts are created for all >>>>> launchers (when shortcut hint option(s) are used). >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8230920 >>>>> >>>>> [3] http://cr.openjdk.java.net/~herrick/8230920/webrev.01/ >>>>> >>>>> /Andy >>>>> >>>>> On 9/24/2019 8:54 AM, Andy Herrick wrote: >>>>>> Please review the jpackage fix for bug [1] at [2]. >>>>>> >>>>>> This is a fix for the JDK-8200758-branch branch of the open >>>>>> sandbox repository (jpackage). >>>>>> >>>>>> This fix replaces the practice we were using on windows to >>>>>> determine the application name, and name of additional launchers >>>>>> (by looking for ".cfg" files in the app dir. >>>>>> >>>>>> Instead we now add a file ".jpackage.args" to the root of the >>>>>> app-image, and record in that file all the arguments used to >>>>>> create the app-image.? We later read that file to determine the >>>>>> original app name and any additional launcher names. >>>>>> >>>>>> This change also fixes the shortcut creation on windows to create >>>>>> shortcuts (if so directed) for all launchers. >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8230920 >>>>>> >>>>>> [2] http://cr.openjdk.java.net/~herrick/8230920/webrev.01/ >>>>>> >>>>>> /Andy >>>>>> >>>> >> From david.lloyd at redhat.com Mon Sep 30 12:41:17 2019 From: david.lloyd at redhat.com (David Lloyd) Date: Mon, 30 Sep 2019 07:41:17 -0500 Subject: RandomAccess Interface and List Heirarchy In-Reply-To: <060d71d4-66e5-b593-dd72-e187b1dc8ae9@gmail.com> References: <1062347590.1395885.1569406540881.JavaMail.zimbra@u-pem.fr> <060d71d4-66e5-b593-dd72-e187b1dc8ae9@gmail.com> Message-ID: 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 Roger.Riggs at oracle.com Mon Sep 30 13:47:43 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 30 Sep 2019 09:47:43 -0400 Subject: [Ping] 8229333: java/io/File/SetLastModified.java timed out In-Reply-To: <2A0235EA-9EC4-4591-9071-DA3CDC154A43@oracle.com> References: <2A0235EA-9EC4-4591-9071-DA3CDC154A43@oracle.com> Message-ID: <79788253-e622-e0cc-dca3-e9c5ca44812c@oracle.com> Looks fine. (Sorry to have needed the reminder to respond). Roger On 9/27/19 8:25 PM, Brian Burkhalter wrote: >> Begin forwarded message: >> >> From: Brian Burkhalter >> Subject: Re: 8229333: java/io/File/SetLastModified.java timed out >> Date: September 6, 2019 at 9:36:39 AM PDT >> To: core-libs-dev >> >> An alternative would be to increase the required memory: >> >> @@ -23,6 +23,7 @@ >> >> /* @test >> @bug 4091757 6652379 8177809 >> + @requires os.maxMemory >= 16G >> @summary Basic test for setLastModified method >> */ >> >> Thanks, >> >> Brian >> >>> On Aug 28, 2019, at 10:51 AM, Lance Andersen > wrote: >>> >>> Looks fine Brian, fingers crossed the little bugger does not come back :-) >>> >>>> On Aug 27, 2019, at 2:00 PM, Brian Burkhalter > wrote: >>>> >>>> The failure reported in [1] was observed to occur on two Mac minis with HDDs. Given the large file access it is possibly due to slow disk access. The suggested fix is to increase the timeout [2]. If it is still observed at a later date a new issue can be filed. >>>> >>>> Thanks, >>>> >>>> Brian >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8229333 >>>> [2] diff: >>>> >>>> @@ -22,11 +22,13 @@ >>>> */ >>>> >>>> /* @test >>>> - @bug 4091757 6652379 8177809 >>>> - @summary Basic test for setLastModified method >>>> + * @bug 4091757 6652379 8177809 >>>> + * @summary Basic test for setLastModified method >>>> + * @run main/timeout=180 SetLastModified >>>> */ >>>> >>>> -import java.io .*; >>>> +import java.io.File; >>>> +import java.io.FileOutputStream; >>>> import java.nio.ByteBuffer; >>>> import java.nio.channels.FileChannel; >>> >>> >>> 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 aleksej.efimov at oracle.com Mon Sep 30 14:47:10 2019 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Mon, 30 Sep 2019 15:47:10 +0100 Subject: RFR[8229338]: clean up test/jdk/java/util/RandomAccess/Basic.java In-Reply-To: References: <4b40de1d-c6a6-675f-60ea-fee4af8b66f4@oracle.com> Message-ID: Hey Patrick, I don't think that we need to add 8229338 to the bug line since it is just test refactoring issue (noreg-self). Otherwise, the changes look good to me! With Best Regards, Aleksei On 27/09/2019 15:53, Patrick Concannon wrote: > Hi Lance, > > > Thanks for your feedback. I've added in those changes, and you can > find them in the new webrev linked below. > > webrev: http://cr.openjdk.java.net/~pconcannon/8229338/webrevs/webrev.01/ > > > Kind regards, > > Patrick > > > On 26/09/2019 13:36, Lance Andersen wrote: >> Hi Patrick, >> >> Overall I think this looks ok. >> >> A few minor comments >> >> Please add?8229338 to the @bug line >> >> I might suggest adding either a comment to the DataProvider or the >> test which uses it with an overview of the parameters to make it >> easier and quicker for future maintainers to know the intent. >> >> Lines 86 and 91, you could if you want ?use String.format and just >> substitute the changed values. >> >> Your testCopy and testFlil methods you can probably consider using a >> DataProvider so that you can also test other types such as Vector or >> was this intentional to omit them ? >> >> HTH >> >> Lance >> >>> On Sep 26, 2019, at 4:38 AM, Patrick Concannon >>> > >>> wrote: >>> >>> Hi, >>> >>> >>> Would it be possible to have my fix for JDK-8229338 reviewed? >>> >>> This a general refactoring of >>> test/jdk/java/util/RandomAccess/Basic.java as outlined in >>> JDK-8229338 'clean up test/jdk/java/util/RandomAccess/Basic.java'. >>> >>> >>> Further information on this bug can be found here: >>> https://bugs.openjdk.java.net/browse/JDK-8229338 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~pconcannon/8229338/webrevs/webrev.00/ >>> >>> >>> Kind regards, >>> >>> Patrick >>> >> >> >> >> >> 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 goetz.lindenmaier at sap.com Mon Sep 30 16:30:40 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 30 Sep 2019 16:30:40 +0000 Subject: RFR (L, final): 8218626: Add detailed message to NullPointerException describing what is null. In-Reply-To: References: Message-ID: Hi Ralf, > The test should not omit these two bytecodes because the current > implementation is the same. This can change and it is not much additional code > to add the two cases. I implemented test cases for the missing invokes: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/20-incremental/ http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/20/ Best regards, Goetz. From mandy.chung at oracle.com Mon Sep 30 18:18:09 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 30 Sep 2019 11:18:09 -0700 Subject: RFR: 8231584: Deadlock with ClassLoader.findLibrary and System.loadLibrary call In-Reply-To: References: Message-ID: <7f8c6c29-0670-066a-9d51-b6f9803e9939@oracle.com> I will need to look at this closer.?? Skimming through the implementation, it seems to me that the Runtime::loadLibrary0 does not need to be synchronized.?? ClassLoader::loadLibrary0 should ensure that a native library of a given name is loaded and registered only once.?? Can you explain why you think ClassLoader::findLibrary needs to be called with a lock? Mandy On 9/27/19 9:37 AM, Anton Kozlov wrote: > Hi, > > I think that JDK-8194653 [0] affects jdk/jdk and it doesn't specific to FileSystems.getDefault. > > I'm starting a new thread/bug as the original issue marked as resolved ([3]) > > Ryan, thanks for investigation and providing a test [1]! > > But the test fails in the same way if the FileSystems.getDefault replaced with anything that calls System.loadLibrary in an initializer. For jdk/jdk it may be jdk.net.ExtendedSocketOptions.SO_FLOW_SLA and the issue will arise. > > I don't think it's possible to provide a general fix for that. We are unable to prevent a user to take the Runtime's monitor and do initialization and loadLibrary, which make a room for deadlock. Taking the lock is incorrect action at first. We can only prevent doing that by accident. > > From the original deadlock report [2], initialization and loadLibrary under the monitor caused not by java.* code, but class loader's findLibrary (sun.misc.ExtClassLoader to be specific). A workaround for ExtClassLoader is possible, to ensure all necessary classes are inited before findLibrary called, i.e. in the constructor. But then we should require the same for any custom class loader. Chances that it would be implemented correctly are not high since even ExtClassLoader is flawed. > > I propose to call a ClassLoader.findLibrary with Runtime's monitor unlocked: > > http://cr.openjdk.java.net/~akozlov/8231584/webrev.00 > > Thanks, > Anton > > [0]: https://bugs.openjdk.java.net/browse/JDK-8194653 > [1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-April/059811.html > [2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-January/050819.html > [3]: https://bugs.openjdk.java.net/browse/JDK-8231584 > From ivan.gerasimov at oracle.com Mon Sep 30 18:42:03 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 30 Sep 2019 11:42:03 -0700 Subject: RFR (XS) 8230415 : Avoid redundant permission checking in FilePermissionCollection and SocketPermissionCollection In-Reply-To: References: <7bf465d9-c5c0-c886-5aec-32ce79017b04@oracle.com> Message-ID: <10175bdf-027b-54ec-fb30-370843aed6f0@oracle.com> Thank you Sean for reviewing! With kind regards, Ivan On 9/27/19 7:20 AM, Sean Mullan wrote: > Hi Ivan, > > The fix looks good. Good catch. > > --Sean > > On 8/30/19 7:32 PM, Ivan Gerasimov wrote: >> Hello! >> >> In the two implementations of >> PermissionCollection.implies(Permission), all the permissions are >> traversed, and their corresponding bit mask are checked. >> >> For example, here's a snippet from FilePermission.java: >> >> ???????? int desired = fperm.getMask(); >> ???????? int effective = 0; >> ???????? int needed = desired; >> >> ???????? for (Permission perm : perms.values()) { >> ???????????? FilePermission fp = (FilePermission)perm; >> ???????????? if (((needed & fp.getMask()) != 0) && >> fp.impliesIgnoreMask(fperm)) { >> ???????????????? effective |= fp.getMask(); >> ???????????????? if ((effective & desired) == desired) { >> ???????????????????? return true; >> ???????????????? } >> ???????????????? needed = (desired ^ effective);// <<< should be >> (desired & ~effective) >> ???????????? } >> ???????? } >> >> Here, if a permission's mask `fp.getMask()` intersects with `needed`, >> but does not fully cover all the needed bits, the variable `needed` >> is updated as XOR of desired and effective. This can raise a >> not-really-needed bits in the `needed` mask, so that for all >> subsequent permissions from the collection with that unneeded bits in >> the mask, an expensive fp.impliesIgnoreMask(fperm) will be executed. >> >> The fix does not change the behavior, but helps avoid unnecessary >> calls to impliesIgnoreMask(). >> >> Would you please help review a trivial fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8230415 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8230415/00/webrev/ >> >> Thanks in advance! >> > -- With kind regards, Ivan Gerasimov From alexander.matveev at oracle.com Mon Sep 30 20:07:01 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Mon, 30 Sep 2019 13:07:01 -0700 Subject: RFR: JDK-8230920 : jpackage problems when -input dir contains any files with "cfg" extension. In-Reply-To: References: <3eb7a77e-eb65-8242-5504-7be300230d32@oracle.com> <2d21564a-c8d1-a750-6c1c-16f10efb93ff@oracle.com> <332cad09-a538-80ae-2c2c-0ba28f5487c1@oracle.com> Message-ID: <13942793-1dfd-f27c-c046-e553073a26bf@oracle.com> Looks good. Do we really planning to call AppImageFile.get() with different values? I think removing or fixing is still better to avoid any potential bugs. Thanks, Alexander On 9/29/2019 1:06 PM, Alexey Semenyuk wrote: > One thing that I just notice is that you introduced caching in > AppImageFile file. The caching doesn't take into consideration that > different values can be passed in AppImageFile.get() function. So if > the function would be called multiple times with different values of > `appImageDir` parameter the same AppImageFile instance will be > returned in all the calls. Unfortunately unit tests didn't catch this. > I suggest you either fix the caching logic or get rid of it in > AppImageFile class. > > - Alexey > > On 9/29/2019 10:37 AM, Andy Herrick wrote: >> Yes? - I meant webrev.03 >> >> Sorry >> >> /Andy >> >> On 9/29/19 10:23 AM, Alexey Semenyuk wrote: >>> I guess it was a type in webrev adderss. Should be >>> http://cr.openjdk.java.net/~herrick/8230920/webrev.03/ >>> >>> This webrev looks good. >>> >>> - Alexey >>> >>> On 9/29/2019 10:08 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). >>>> >>>> The revised fix stores an xml file (.jpackage.xml) in the app-image >>>> so that jpackage commands using that app-image can determine some >>>> things previously available only when building the app-image, such >>>> as the name of the application and the name of additional launchers. >>>> >>>> Initially this is only used on windows, but should be later used on >>>> linux and possibly macOS as well (if additional data needed by dmg >>>> or pkg building are identified). >>>> >>>> The windows fix also ensures that shortcuts are created for all >>>> launchers (when shortcut hint option(s) are used). >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8230920 >>>> >>>> [3] http://cr.openjdk.java.net/~herrick/8230920/webrev.01/ >>>> >>>> /Andy >>>> >>>> On 9/24/2019 8:54 AM, Andy Herrick wrote: >>>>> Please review the jpackage fix for bug [1] at [2]. >>>>> >>>>> This is a fix for the JDK-8200758-branch branch of the open >>>>> sandbox repository (jpackage). >>>>> >>>>> This fix replaces the practice we were using on windows to >>>>> determine the application name, and name of additional launchers >>>>> (by looking for ".cfg" files in the app dir. >>>>> >>>>> Instead we now add a file ".jpackage.args" to the root of the >>>>> app-image, and record in that file all the arguments used to >>>>> create the app-image.? We later read that file to determine the >>>>> original app name and any additional launcher names. >>>>> >>>>> This change also fixes the shortcut creation on windows to create >>>>> shortcuts (if so directed) for all launchers. >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8230920 >>>>> >>>>> [2] http://cr.openjdk.java.net/~herrick/8230920/webrev.01/ >>>>> >>>>> /Andy >>>>> >>> > From andy.herrick at oracle.com Mon Sep 30 20:09:37 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 30 Sep 2019 16:09:37 -0400 Subject: RFR: JDK-8230920 : jpackage problems when -input dir contains any files with "cfg" extension. In-Reply-To: <13942793-1dfd-f27c-c046-e553073a26bf@oracle.com> References: <3eb7a77e-eb65-8242-5504-7be300230d32@oracle.com> <2d21564a-c8d1-a750-6c1c-16f10efb93ff@oracle.com> <332cad09-a538-80ae-2c2c-0ba28f5487c1@oracle.com> <13942793-1dfd-f27c-c046-e553073a26bf@oracle.com> Message-ID: <1070fb78-9de4-8eb0-ac8b-ec3bc7e7ed42@oracle.com> yes - I removed get, and the "instance" variable and just call load (see: webrev.04). we shouldn't actually call it with different base dir arg, except possibly in a test. /Andy On 9/30/2019 4:07 PM, Alexander Matveev wrote: > Looks good. > > Do we really planning to call AppImageFile.get() with different > values? I think removing or fixing is still better to avoid any > potential bugs. > > Thanks, > Alexander > > On 9/29/2019 1:06 PM, Alexey Semenyuk wrote: >> One thing that I just notice is that you introduced caching in >> AppImageFile file. The caching doesn't take into consideration that >> different values can be passed in AppImageFile.get() function. So if >> the function would be called multiple times with different values of >> `appImageDir` parameter the same AppImageFile instance will be >> returned in all the calls. Unfortunately unit tests didn't catch >> this. I suggest you either fix the caching logic or get rid of it in >> AppImageFile class. >> >> - Alexey >> >> On 9/29/2019 10:37 AM, Andy Herrick wrote: >>> Yes? - I meant webrev.03 >>> >>> Sorry >>> >>> /Andy >>> >>> On 9/29/19 10:23 AM, Alexey Semenyuk wrote: >>>> I guess it was a type in webrev adderss. Should be >>>> http://cr.openjdk.java.net/~herrick/8230920/webrev.03/ >>>> >>>> This webrev looks good. >>>> >>>> - Alexey >>>> >>>> On 9/29/2019 10:08 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). >>>>> >>>>> The revised fix stores an xml file (.jpackage.xml) in the >>>>> app-image so that jpackage commands using that app-image can >>>>> determine some things previously available only when building the >>>>> app-image, such as the name of the application and the name of >>>>> additional launchers. >>>>> >>>>> Initially this is only used on windows, but should be later used >>>>> on linux and possibly macOS as well (if additional data needed by >>>>> dmg or pkg building are identified). >>>>> >>>>> The windows fix also ensures that shortcuts are created for all >>>>> launchers (when shortcut hint option(s) are used). >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8230920 >>>>> >>>>> [3] http://cr.openjdk.java.net/~herrick/8230920/webrev.01/ >>>>> >>>>> /Andy >>>>> >>>>> On 9/24/2019 8:54 AM, Andy Herrick wrote: >>>>>> Please review the jpackage fix for bug [1] at [2]. >>>>>> >>>>>> This is a fix for the JDK-8200758-branch branch of the open >>>>>> sandbox repository (jpackage). >>>>>> >>>>>> This fix replaces the practice we were using on windows to >>>>>> determine the application name, and name of additional launchers >>>>>> (by looking for ".cfg" files in the app dir. >>>>>> >>>>>> Instead we now add a file ".jpackage.args" to the root of the >>>>>> app-image, and record in that file all the arguments used to >>>>>> create the app-image.? We later read that file to determine the >>>>>> original app name and any additional launcher names. >>>>>> >>>>>> This change also fixes the shortcut creation on windows to create >>>>>> shortcuts (if so directed) for all launchers. >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8230920 >>>>>> >>>>>> [2] http://cr.openjdk.java.net/~herrick/8230920/webrev.01/ >>>>>> >>>>>> /Andy >>>>>> >>>> >> > From alexander.matveev at oracle.com Mon Sep 30 20:24:31 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Mon, 30 Sep 2019 13:24:31 -0700 Subject: RFR: JDK-8231280: Linux packages produced by jpackage should have correct dependencies In-Reply-To: <917eff6c-801b-c186-f3fe-e04eee171848@oracle.com> References: <917eff6c-801b-c186-f3fe-e04eee171848@oracle.com> Message-ID: Looks good. On 9/29/2019 3:08 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). > > The fix adds use of `ldd` command and packaging specific tools to > build list of packages required by a package produced by jpackage. > > Baseline for review is [3]. > > [1] https://bugs.openjdk.java.net/browse/JDK-8231280 > > [2] http://cr.openjdk.java.net/~asemenyuk/8231280/webrev.01/ > > [3] http://cr.openjdk.java.net/~asemenyuk/8231605/webrev.00/ > From alexander.matveev at oracle.com Mon Sep 30 20:26:52 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Mon, 30 Sep 2019 13:26:52 -0700 Subject: RFR: JDK-8230974: creating rpm, get error for relative path to the license.txt In-Reply-To: <57db7b7a-0e41-6a1e-c3c1-e5c59096cbbc@oracle.com> References: <917eff6c-801b-c186-f3fe-e04eee171848@oracle.com> <57db7b7a-0e41-6a1e-c3c1-e5c59096cbbc@oracle.com> Message-ID: Looks good. On 9/29/2019 4:45 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). > > Baseline for review is [3]. > > [1] https://bugs.openjdk.java.net/browse/JDK-8230974 > > [2] http://cr.openjdk.java.net/~asemenyuk/8230974/webrev.00/ > > [3] http://cr.openjdk.java.net/~asemenyuk/8231280/webrev.01/ > From alexander.matveev at oracle.com Mon Sep 30 20:31:11 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Mon, 30 Sep 2019 13:31:11 -0700 Subject: RFR: JDK-8230920 : jpackage problems when -input dir contains any files with "cfg" extension. In-Reply-To: <1070fb78-9de4-8eb0-ac8b-ec3bc7e7ed42@oracle.com> References: <3eb7a77e-eb65-8242-5504-7be300230d32@oracle.com> <2d21564a-c8d1-a750-6c1c-16f10efb93ff@oracle.com> <332cad09-a538-80ae-2c2c-0ba28f5487c1@oracle.com> <13942793-1dfd-f27c-c046-e553073a26bf@oracle.com> <1070fb78-9de4-8eb0-ac8b-ec3bc7e7ed42@oracle.com> Message-ID: <611d2012-223b-14d7-2057-7a6de7926203@oracle.com> Hi Andy, webrev.04 looks good. Thanks, Alexander On 9/30/2019 1:09 PM, Andy Herrick wrote: > yes - I removed get, and the "instance" variable and just call load > (see: webrev.04). > > we shouldn't actually call it with different base dir arg, except > possibly in a test. > > /Andy > > On 9/30/2019 4:07 PM, Alexander Matveev wrote: >> Looks good. >> >> Do we really planning to call AppImageFile.get() with different >> values? I think removing or fixing is still better to avoid any >> potential bugs. >> >> Thanks, >> Alexander >> >> On 9/29/2019 1:06 PM, Alexey Semenyuk wrote: >>> One thing that I just notice is that you introduced caching in >>> AppImageFile file. The caching doesn't take into consideration that >>> different values can be passed in AppImageFile.get() function. So if >>> the function would be called multiple times with different values of >>> `appImageDir` parameter the same AppImageFile instance will be >>> returned in all the calls. Unfortunately unit tests didn't catch >>> this. I suggest you either fix the caching logic or get rid of it in >>> AppImageFile class. >>> >>> - Alexey >>> >>> On 9/29/2019 10:37 AM, Andy Herrick wrote: >>>> Yes? - I meant webrev.03 >>>> >>>> Sorry >>>> >>>> /Andy >>>> >>>> On 9/29/19 10:23 AM, Alexey Semenyuk wrote: >>>>> I guess it was a type in webrev adderss. Should be >>>>> http://cr.openjdk.java.net/~herrick/8230920/webrev.03/ >>>>> >>>>> This webrev looks good. >>>>> >>>>> - Alexey >>>>> >>>>> On 9/29/2019 10:08 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). >>>>>> >>>>>> The revised fix stores an xml file (.jpackage.xml) in the >>>>>> app-image so that jpackage commands using that app-image can >>>>>> determine some things previously available only when building the >>>>>> app-image, such as the name of the application and the name of >>>>>> additional launchers. >>>>>> >>>>>> Initially this is only used on windows, but should be later used >>>>>> on linux and possibly macOS as well (if additional data needed by >>>>>> dmg or pkg building are identified). >>>>>> >>>>>> The windows fix also ensures that shortcuts are created for all >>>>>> launchers (when shortcut hint option(s) are used). >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8230920 >>>>>> >>>>>> [3] http://cr.openjdk.java.net/~herrick/8230920/webrev.01/ >>>>>> >>>>>> /Andy >>>>>> >>>>>> On 9/24/2019 8:54 AM, Andy Herrick wrote: >>>>>>> Please review the jpackage fix for bug [1] at [2]. >>>>>>> >>>>>>> This is a fix for the JDK-8200758-branch branch of the open >>>>>>> sandbox repository (jpackage). >>>>>>> >>>>>>> This fix replaces the practice we were using on windows to >>>>>>> determine the application name, and name of additional launchers >>>>>>> (by looking for ".cfg" files in the app dir. >>>>>>> >>>>>>> Instead we now add a file ".jpackage.args" to the root of the >>>>>>> app-image, and record in that file all the arguments used to >>>>>>> create the app-image.? We later read that file to determine the >>>>>>> original app name and any additional launcher names. >>>>>>> >>>>>>> This change also fixes the shortcut creation on windows to >>>>>>> create shortcuts (if so directed) for all launchers. >>>>>>> >>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8230920 >>>>>>> >>>>>>> [2] http://cr.openjdk.java.net/~herrick/8230920/webrev.01/ >>>>>>> >>>>>>> /Andy >>>>>>> >>>>> >>> >> From alexander.matveev at oracle.com Mon Sep 30 21:56:31 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Mon, 30 Sep 2019 14:56:31 -0700 Subject: RFR: JDK-8231605: Improve test helpers In-Reply-To: References: <8415f13f-2c13-bf32-c82a-640a9040b9a7@oracle.com> Message-ID: Looks good. On 9/29/2019 1:50 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). > > This fix: > > - Improve jpackage test helpers. > - Implement jdk.jpackage.internal.ApplicationLayout class on all > platforms. > - Functionality of all deleted tests moved into the new BasicTest.java > based on the new test helper classes. > > The long term plan is to refactor existing tests based on the old test > helpers using the new testing classes. > For now it is suggested to implement all new tests with the new test > helpers using BasicTest.java as a reference. > > BasicTest not in the default but in jdk.jpackage.tests package > intentionally. It is not directly executed by jtreg harness, but > indirectly through test helper, so jtreg has no issues locating it. > The reason to keep test classes away from the default package is that > NetBeans is very slow on projects with many classes in the default > package, so the expectation is that it will work faster of the project > with jpackage tests after they get moved out from the default package. > > [1] https://bugs.openjdk.java.net/browse/JDK-8231605 > > [2] http://cr.openjdk.java.net/~asemenyuk/8231605/webrev.00/ > From andy.herrick at oracle.com Mon Sep 30 23:17:28 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 30 Sep 2019 19:17:28 -0400 Subject: RFR: JDK-8231280: Linux packages produced by jpackage should have correct dependencies In-Reply-To: <917eff6c-801b-c186-f3fe-e04eee171848@oracle.com> References: <917eff6c-801b-c186-f3fe-e04eee171848@oracle.com> Message-ID: <9fb5975a-f5c4-1839-9ad5-25af4d1e4b7e@oracle.com> looks good . /Andy On 9/29/2019 6:08 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). > > The fix adds use of `ldd` command and packaging specific tools to > build list of packages required by a package produced by jpackage. > > Baseline for review is [3]. > > [1] https://bugs.openjdk.java.net/browse/JDK-8231280 > > [2] http://cr.openjdk.java.net/~asemenyuk/8231280/webrev.01/ > > [3] http://cr.openjdk.java.net/~asemenyuk/8231605/webrev.00/ >