From r.lichtenberger at gmail.com Mon Jul 1 06:47:46 2019 From: r.lichtenberger at gmail.com (Robert Lichtenberger) Date: Mon, 1 Jul 2019 08:47:46 +0200 Subject: JPackage application image file system layout Message-ID: While trying to update our application to the (ea-version of) jpackager I noticed that the executable files are now in a bin/ subdirectory, which will make the application update from javapackager a real pain. For Linux this can be argumented with the Filesystem Hierarchy Standard but under Windows it is not common or standard to do so. The .exe file for an application is expected to live in the base installation directory. Is there any chance this can still be changed or made configurable? Best regards, Robert Lichtenberger From abraham.marin.perez at gmail.com Mon Jul 1 07:43:37 2019 From: abraham.marin.perez at gmail.com (=?utf-8?B?QWJyYWhhbSBNYXLDrW4gUMOpcmV6?=) Date: Mon, 1 Jul 2019 08:43:37 +0100 Subject: Suggestion for a more sensible implementation of EMPTY_MAP In-Reply-To: <28ae0d9d-b739-17d2-fad0-7dcbde436df3@oracle.com> References: <35DF053F-BBFB-4799-92F3-DD7B0B29832D@gmail.com> <09549493-63ae-582d-3a82-d1366e839f9f@oracle.com> <1BD96549-92C8-4BB3-88D0-FB1FBDB9DCF5@gmail.com> <28ae0d9d-b739-17d2-fad0-7dcbde436df3@oracle.com> Message-ID: <0239F306-07E3-4EF7-AD9B-77FEDD1F921C@gmail.com> > On 27 Jun 2019, at 22:38, Stuart Marks wrote: > > > > On 6/19/19 12:51 AM, Abraham Mar?n P?rez wrote: >> private void decorate(Map data) { >> //... >> data.computeIfPresent("field", (k, v) -> highlightDifferences(v, otherValue)); >> //... >> } >> At one point an emptyMap() was passed to this method, causing an UOE. [...] > > On the face of it, the decorate() method has the possibility to modify the map that it's passed. Thus, it shouldn't be at all surprising that passing an unmodifiable map to it results in UOE. decorate() does other things other than calling computeIfPresent. Given our business logic, we don?t believe throwing UOE is a helpful behaviour in this particular case. > > As a special case, it doesn't *actually* modify the map if "field" is absent, but you have to do some analysis to figure this out. > > Now you want the JDK to add another special case to Collections.emptyMap(), and possibly others, in order to make this special case work. I don't think we want to do that. Fair enough. I made the suggestion thinking that this is something that would benefit the overall community. But maybe that?s not the case. If the overall community benefits better from the current implementation, then I agree it should stay as it is. Thanks for taking the time to debate and consider this change. Cheers, Abraham > > s'marks From mik3hall at gmail.com Mon Jul 1 10:52:02 2019 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 1 Jul 2019 05:52:02 -0500 Subject: JPackage EA build 8 ( jdk-14-jpackage+1-8 ) In-Reply-To: <9dc7df8e-5e06-8aaa-a10d-3478432bf2a3@oracle.com> References: <9dc7df8e-5e06-8aaa-a10d-3478432bf2a3@oracle.com> Message-ID: Is jdk-14 the current target release for this? I?m seeing the following in my app. Would this mean this release actually cracks down on some reflection? Is some jdk-14 bug unrelated to jpackage? Probably uncovered some other bug of mine? Who knows? java.lang.reflect.InvocationTargetException at java.desktop/sun.lwawt.macosx.LWCToolkit.checkException(LWCToolkit.java:736) at java.desktop/sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:705) at java.desktop/sun.lwawt.macosx.CInputMethod.firstRectForCharacterRange(CInputMethod.java:717) Caused by: java.lang.NullPointerException at java.desktop/sun.lwawt.macosx.CInputMethod$6.run(CInputMethod.java:738) at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:303) at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:770) at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721) at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715) at java.base/java.security.AccessController.doPrivileged(AccessController.java:391) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:95) at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:745) at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:743) at java.base/java.security.AccessController.doPrivileged(AccessController.java:391) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742) at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203) at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) From swpalmer at gmail.com Mon Jul 1 14:50:23 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 1 Jul 2019 10:50:23 -0400 Subject: JPackage application image file system layout In-Reply-To: References: Message-ID: <646068FF-040B-4B97-B494-A8615997E951@gmail.com> > On Jul 1, 2019, at 2:47 AM, Robert Lichtenberger wrote: > > While trying to update our application to the (ea-version of) jpackager I > noticed that the executable files are now in a bin/ subdirectory, which > will make the application update from javapackager a real pain. > > For Linux this can be argumented with the Filesystem Hierarchy Standard but > under Windows it is not common or standard to do so. The .exe file for an > application is expected to live in the base installation directory. It can also be argued that on Windows it is more common to launch the application from a shortcut in the Start menu, on the Desktop, or in the launch bar. I get that this is a change from the previous behaviour so some adjustments need to be made, but how bad is it really? The JDK has always had a bin directory and many other applications follow this pattern on Windows as well. > Is there any chance this can still be changed or made configurable? Making it configurable makes the most sense. But it may get complicated as the launcher exe needs to find the .cfg file without any additional info. Maybe the relative path to the .cfg file can be injected into the exe at build time, much like customizing the exe?s icon? Regards, Scott From naoto.sato at oracle.com Mon Jul 1 15:32:22 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 1 Jul 2019 08:32:22 -0700 Subject: RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string In-Reply-To: <8ec24050-0c2a-4f2d-88e6-a3fba5d40e12@default> References: <8ec24050-0c2a-4f2d-88e6-a3fba5d40e12@default> Message-ID: <1e497a17-ac12-d2f6-064f-39c4cb15223b@oracle.com> Hi Thejasvi, Thanks for fixing this. Since those new test cases depend on the CLDR localization, which might change in other implementations, those test cases should be in jdk/java/time/test directory, as "tck" tests should only test the spec. Please create a new test case for this in the "test" directory (with @modules jdk.localedata directive) similar to the existing TCK one. Also the current test in the TCK should enforce that it runs in Locale.US so that the result should match "GMT." Naoto On 6/28/19 5:59 AM, Thejasvi Voniadka wrote: > Hi, > > Request you to please review this change. > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8154520 > > > Description: At present, the "DateTimeFormatterBuilder.appendLocalizedOffset()" method formulates the base string as "GMT", without accounting for locale-specific transformations. This change is to return the localized version of "GMT" instead. So for example, instead of returning "GMT +5.30", it may now return "XXXX +5.30" where "XXXX" is the localized string for "GMT" for the locale associated with the formatter. I have used DateTimeTextProvider.getLocalizedResource() method to return the "gmtZeroFormat" value from CLDR/LDML corresponding to the given locale. The code defaults to "GMT" in the absence of such a localized value. > > > Webrev: http://cr.openjdk.java.net/~vagarwal/8154520/webrev.1/ > > > Additional notes: I preferred to update and reuse an existing test instead of creating a new one. It already has the niceties in place, and creating another method would mean some amount of code redundancy. However, if that's the recommended norm, then I can change it. > From andy.herrick at oracle.com Mon Jul 1 17:07:38 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 1 Jul 2019 13:07:38 -0400 Subject: RFR: JDK-8226751: "Exception: ..." for missing file In-Reply-To: <7e64f8d0-834a-a091-47dd-57af38af4a84@oracle.com> References: <43520bd2-8800-7b9e-7b2f-b42c12f7751a@oracle.com> <7e64f8d0-834a-a091-47dd-57af38af4a84@oracle.com> Message-ID: <25d47022-a6f1-178b-d278-5b1e9a4a6acb@oracle.com> Updated webrev at https://bugs.openjdk.java.net/browse/JDK-8226751/webrev.02 to use Files.isReadable() /Andy On 6/29/2019 9:54 AM, Kevin Rushforth wrote: > The rest of the CommandLine class uses nio Paths/Files, so the > following might be a better fit, and also checks whether the file can > be read: > > ??? if (!Files.isReadable(Paths.of(name))) > > The rest looks fine. > > -- Kevin > > On 6/29/2019 6:27 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). >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8226751 >> >> [2] http://cr.openjdk.java.net/~herrick/8226751/ >> >> >> /Andy >> > From alexey.semenyuk at oracle.com Mon Jul 1 18:12:36 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Mon, 1 Jul 2019 14:12:36 -0400 Subject: RFR: JDK-8226751: "Exception: ..." for missing file In-Reply-To: <25d47022-a6f1-178b-d278-5b1e9a4a6acb@oracle.com> References: <43520bd2-8800-7b9e-7b2f-b42c12f7751a@oracle.com> <7e64f8d0-834a-a091-47dd-57af38af4a84@oracle.com> <25d47022-a6f1-178b-d278-5b1e9a4a6acb@oracle.com> Message-ID: <2eafd499-bd7b-ab9e-3f72-cc47320953ef@oracle.com> Looks good. On 7/1/2019 1:07 PM, Andy Herrick wrote: > Updated webrev at > https://bugs.openjdk.java.net/browse/JDK-8226751/webrev.02 to use > Files.isReadable() > > /Andy > > > On 6/29/2019 9:54 AM, Kevin Rushforth wrote: >> The rest of the CommandLine class uses nio Paths/Files, so the >> following might be a better fit, and also checks whether the file can >> be read: >> >> ??? if (!Files.isReadable(Paths.of(name))) >> >> The rest looks fine. >> >> -- Kevin >> >> On 6/29/2019 6:27 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). >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8226751 >>> >>> [2] http://cr.openjdk.java.net/~herrick/8226751/ >>> >>> >>> /Andy >>> >> > From huizhe.wang at oracle.com Mon Jul 1 18:46:54 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 01 Jul 2019 11:46:54 -0700 Subject: RFR(JDK 14/java.xml) 8223291: Whitespace is added to CDATA tags when using OutputKeys.INDENT to format XML Message-ID: <5D1A551E.1070600@oracle.com> Please review a fix to xml pretty print. This is a regression introduced during the JDK 9 development. CDATA is marked up to be interpreted literally as textual data, in other words, it's still character data. The processor therefore shall treat it as text data. The content of "abcxyz" should be "abc & xyz", not " abc\n & \n xyz\n" as that before this fix. JBS: https://bugs.openjdk.java.net/browse/JDK-8223291 webrev: http://cr.openjdk.java.net/~joehw/jdk14/8223291/webrev/ Thanks, Joe From mik3hall at gmail.com Mon Jul 1 19:02:31 2019 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 1 Jul 2019 14:02:31 -0500 Subject: OS X jpackage and java.class.path Message-ID: <3340E12E-597A-47BD-A51B-7BB3AAECF93A@gmail.com> I think I may out mentioned this before but maybe I didn?t fix the problems it was causing me because I just ran into it again. So I?ll mention it again. java.class.path is somewhat inconsistent in its entries. The main jar is present as absolute path? /Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/Java/halfpipe.jar all other entries are relative too user.dir which is? user.dir=/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/Java Example entries of the remaining relative paths? RserveEngine.jar:quartz-jobs-2.2.2.jar:commons-logging-1.1.1.jar:httpcore-4.4.10.jar:groovy-all-2.6.0-alpha-1.jar? Any code that for whatever reason wants to process off of java.class.path needs to be aware of this. It would have to be prepared to handle either condition of absolute or user.dir relative paths. How much code does this I don?t know but mine for some limited functionality does. This just isn?t consistent for all entries. It of course works fine for normal loading and application execution. From mandy.chung at oracle.com Mon Jul 1 19:51:11 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 1 Jul 2019 12:51:11 -0700 Subject: Review Request: JDK-8173978: Lookup.in should allow teleporting from a lookup class in a named module without dropping all access Message-ID: <77478136-29fd-45f9-d122-6826099dfe84@oracle.com> This is an enhancement to |`Lookup::in`| and |`MethodHandles::privateLookupIn`| API for cross module teleporting.? A `Lookup` object will record the previous lookup class from which this |Lookup| object was teleported such that the access check will use both the previous lookup class and the current |lookup| context (current lookup class and allowed modes) to determine if a type is accessible to this `Lookup` object or not. In a nutshell, `T` in M2 is accessible to a `Lookup` object on `C` (lookup class in M1) and `PLC` (previous lookup class in M0) if and only if 1. both M0 and M1 can read M2 2. T is in a package that is exported from M2 at least to both M0 and M1 Detailed specification is in Lookup class spec and `accessClass` javadoc. The relevant spec about cross-module teleporting is in the Lookup class spec and `Lookup::in` and `MethodHandles::privateLookupIn`. CSR: https://bugs.openjdk.java.net/browse/JDK-8226916 webrev: http://cr.openjdk.java.net/~mchung/jdk14/8173978/webrev.00 javadoc: http://cr.openjdk.java.net/~mchung/jdk14/8173978/javadoc/java.base/java/lang/invoke/MethodHandles.Lookup.html http://cr.openjdk.java.net/~mchung/jdk14/8173978/javadoc/java.base/java/lang/invoke/MethodHandles.html#privateLookupIn(java.lang.Class,java.lang.invoke.MethodHandles.Lookup) I have yet to generate the spec diff. The tool is currently broken due to javadoc change.? I'll try to workaround it and post the spec diff soon. thanks Mandy From andy.herrick at oracle.com Mon Jul 1 20:21:16 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 1 Jul 2019 16:21:16 -0400 Subject: OS X jpackage and java.class.path In-Reply-To: <3340E12E-597A-47BD-A51B-7BB3AAECF93A@gmail.com> References: <3340E12E-597A-47BD-A51B-7BB3AAECF93A@gmail.com> Message-ID: <459b0d11-8535-f813-cc5b-6b4f5c93b7d5@oracle.com> can you share the command options used launching jpackage ? I think I would understand better if I saw the complete command. /Andy On 7/1/2019 3:02 PM, Michael Hall wrote: > I think I may out mentioned this before but maybe I didn?t fix the problems it was causing me because I just ran into it again. So I?ll mention it again. > > java.class.path is somewhat inconsistent in its entries. > > The main jar is present as absolute path? > /Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/Java/halfpipe.jar > > all other entries are relative too user.dir which is? > user.dir=/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/Java > > Example entries of the remaining relative paths? > RserveEngine.jar:quartz-jobs-2.2.2.jar:commons-logging-1.1.1.jar:httpcore-4.4.10.jar:groovy-all-2.6.0-alpha-1.jar? > > Any code that for whatever reason wants to process off of java.class.path needs to be aware of this. It would have to be prepared to handle either condition of absolute or user.dir relative paths. > > How much code does this I don?t know but mine for some limited functionality does. This just isn?t consistent for all entries. > It of course works fine for normal loading and application execution. > From mik3hall at gmail.com Mon Jul 1 20:25:47 2019 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 1 Jul 2019 15:25:47 -0500 Subject: OS X jpackage and java.class.path In-Reply-To: <459b0d11-8535-f813-cc5b-6b4f5c93b7d5@oracle.com> References: <3340E12E-597A-47BD-A51B-7BB3AAECF93A@gmail.com> <459b0d11-8535-f813-cc5b-6b4f5c93b7d5@oracle.com> Message-ID: <1AB62D1B-7873-4F8D-B4C4-50836E111265@gmail.com> > On Jul 1, 2019, at 3:21 PM, Andy Herrick wrote: > > can you share the command options used launching jpackage ? > > I think I would understand better if I saw the complete command. ${PACKAGER} \ --verbose \ --input ../HalfPipe12.app/Contents/Java \ --output outputdir \ --name HalfPipe \ --main-jar halfpipe.jar \ --runtime-image /Library/Java/JavaVirtualMachines/jdk-14.jdk/Contents/Home \ --main-class us.hall.hp.common.LoaderLaunchStub \ --add-modules java.compiler,java.desktop,java.logging,java.management,java.prefs,java.se,java.rmi,java.scripting,java.sql,java.xml,jdk.attach,jdk.jshell \ --java-options '-Xmx1024m -XX:+UseG1GC -XX:MaxGCPauseMillis=50 -Djava.security.manager -Djava.security.policy=../JavaApp/all.policy -Dapple.laf.useScreenMenuBar=true -Dcom.apple.mrj.application.apple.menu.about.name=HalfPipe -Dconsole=pane' \ --mac-bundle-identifier us.hall.HalfPipe resulting in a java.class.path setting of? java.class.path=/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/Java/halfpipe.jar:RserveEngine.jar:quartz-jobs-2.2.2.jar:commons-logging-1.1.1.jar:httpcore-4.4.10.jar:groovy-all-2.6.0-alpha-1.jar:jta.jar:slf4j-log4j12-1.7.7.jar:weka.jar:groovy-all-2.6.0-alpha-1-indy.jar:htmlparser.jar:quartz-2.2.2.jar:httpclient-4.5.6.jar:JRS.jar:slf4j-api-1.7.7.jar:log4j-1.2.16.jar:macnio2.jar:halfpipe.jar:rome-1.11.1-SNAPSHOT.jar:AppleScriptEngine.jar:JRI.jar:stringtemplate-3.2.1.jar:resource.jar:rome-utils-1.11.1-SNAPSHOT.jar:Java_Simulation_Code.jar:JRIEngine.jar:antlr-2.7.7.jar:jdom2-2.0.6.jar:REngine.jar:rhino-1.7.9.jar: From mik3hall at gmail.com Mon Jul 1 20:29:59 2019 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 1 Jul 2019 15:29:59 -0500 Subject: OS X jpackage and java.class.path In-Reply-To: <459b0d11-8535-f813-cc5b-6b4f5c93b7d5@oracle.com> References: <3340E12E-597A-47BD-A51B-7BB3AAECF93A@gmail.com> <459b0d11-8535-f813-cc5b-6b4f5c93b7d5@oracle.com> Message-ID: <2FD0A6E7-0C55-4ED4-8634-2CB6D8980007@gmail.com> > On Jul 1, 2019, at 3:21 PM, Andy Herrick wrote: > > can you share the command options used launching jpackage ? > > I think I would understand better if I saw the complete command. > > /Andy > Fwiw legacy was all absolute? java.class.path=/Users/mjh/HalfPipe/HalfPipe7.app/Contents/Java/Classes:/Users/mjh/HalfPipe/HalfPipe7.app/Contents/Java/RserveEngine.jar:/Users/mjh/HalfPipe/HalfPipe7.app/Contents/Java/quartz-jobs-2.2.2.jar:/Users/mjh/HalfPipe/HalfPipe7.app/Contents/Java/commons-logging-1.1.1.jar:/Users/mjh/HalfPipe/HalfPipe7.app/Contents/Java/httpcore-4.4.10.jar:/Users/mjh/HalfPipe/HalfPipe7.app/Contents/Java/groovy-all-2.6.0-alpha-1.jar:/Users/mjh/HalfPipe/HalfPipe7.app/Contents/Java/jta.jar:/Users/mjh/HalfPipe/HalfPipe7.app/Contents/Java/slf4j-log4j12-1.7.7.jar:/Users/mjh/HalfPipe/HalfPipe7.app/Contents/Java/weka.jar:/Users/mjh/HalfPipe/HalfPipe7.app/Contents/Java/groovy-all-2.6.0-alpha-1-indy.jar:/Users/mjh/HalfPipe/HalfPipe7.app/Contents/Java/js.jar:/Users/mjh/HalfPipe/HalfPipe7.app/Contents/Java/htmlparser.jar:/Users/mjh/HalfPipe/HalfPipe7.app/Contents/Java/quartz-2.2.2.jar:/Users/mjh/HalfPipe/HalfPipe7.app/Contents/Java/httpclient-4.5.6.jar:/Users/mjh/HalfPipe/HalfPipe7.app/Contents/Java/JRS.jar:/Users/mjh/HalfPipe/HalfPipe7.app/Contents/Java/slf4j-api-1.7.7.jar:/Users/mjh/HalfPipe/HalfPipe7.app/Contents/Java/log4j-1.2.16.jar:/Users/mjh/HalfPipe/HalfPipe7.app/Contents/Java/macnio2.jar:/Users/mjh/HalfPipe/HalfPipe7.app/Contents/Java/halfpipe.jar:/Users/mjh/HalfPipe/HalfPipe7.app/Contents/Java/rome-1.11.1-SNAPSHOT.jar:/Users/mjh/HalfPipe/HalfPipe7.app/Contents/Java/AppleScriptEngine.jar:/Users/mjh/HalfPipe/HalfPipe7.app/Contents/Java/JRI.jar:/Users/mjh/HalfPipe/HalfPipe7.app/Contents/Java/stringtemplate-3.2.1.jar:/Users/mjh/HalfPipe/HalfPipe7.app/Contents/Java/rome-utils-1.11.1-SNAPSHOT.jar:/Users/mjh/HalfPipe/HalfPipe7.app/Contents/Java/Java_Simulation_Code.jar:/Users/mjh/HalfPipe/HalfPipe7.app/Contents/Java/JRIEngine.jar:/Users/mjh/HalfPipe/HalfPipe7.app/Contents/Java/antlr-2.7.7.jar:/Users/mjh/HalfPipe/HalfPipe7.app/Contents/Java/jdom2-2.0.6.jar:/Users/mjh/HalfPipe/HalfPipe7.app/Contents/ From alexander.matveev at oracle.com Mon Jul 1 21:30:07 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Mon, 1 Jul 2019 14:30:07 -0700 Subject: RFR: JDK-8226751: "Exception: ..." for missing file In-Reply-To: <2eafd499-bd7b-ab9e-3f72-cc47320953ef@oracle.com> References: <43520bd2-8800-7b9e-7b2f-b42c12f7751a@oracle.com> <7e64f8d0-834a-a091-47dd-57af38af4a84@oracle.com> <25d47022-a6f1-178b-d278-5b1e9a4a6acb@oracle.com> <2eafd499-bd7b-ab9e-3f72-cc47320953ef@oracle.com> Message-ID: Looks good. On 7/1/2019 11:12 AM, Alexey Semenyuk wrote: > Looks good. > > On 7/1/2019 1:07 PM, Andy Herrick wrote: >> Updated webrev at >> https://bugs.openjdk.java.net/browse/JDK-8226751/webrev.02 to use >> Files.isReadable() >> >> /Andy >> >> >> On 6/29/2019 9:54 AM, Kevin Rushforth wrote: >>> The rest of the CommandLine class uses nio Paths/Files, so the >>> following might be a better fit, and also checks whether the file >>> can be read: >>> >>> ??? if (!Files.isReadable(Paths.of(name))) >>> >>> The rest looks fine. >>> >>> -- Kevin >>> >>> On 6/29/2019 6:27 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). >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8226751 >>>> >>>> [2] http://cr.openjdk.java.net/~herrick/8226751/ >>>> >>>> >>>> /Andy >>>> >>> >> > From alexander.matveev at oracle.com Mon Jul 1 22:09:20 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Mon, 1 Jul 2019 15:09:20 -0700 Subject: RFR: JDK-8226891: rename and re-layout jpackage tests. In-Reply-To: <1c7c70a5-3660-6c86-4fc4-74cc568929cc@oracle.com> References: <1c7c70a5-3660-6c86-4fc4-74cc568929cc@oracle.com> Message-ID: <8b0a60e0-e532-5a1d-385f-65abbec4d379@oracle.com> Hi Andy, Looks good. Thanks, Alexander On 6/30/2019 2:11 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). > > [1] https://bugs.openjdk.java.net/browse/JDK-8226891 > > [2] http://cr.openjdk.java.net/~herrick/8226891/ > > > /Andy From mandy.chung at oracle.com Tue Jul 2 01:47:16 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 1 Jul 2019 18:47:16 -0700 Subject: Review Request: JDK-8173978: Lookup.in should allow teleporting from a lookup class in a named module without dropping all access In-Reply-To: <77478136-29fd-45f9-d122-6826099dfe84@oracle.com> References: <77478136-29fd-45f9-d122-6826099dfe84@oracle.com> Message-ID: On 7/1/19 12:51 PM, Mandy Chung wrote: > This is an enhancement to |`Lookup::in`| and > |`MethodHandles::privateLookupIn`| API > for cross module teleporting.? A `Lookup` object will record the previous > lookup class from which this |Lookup| object was teleported such that > the access check will use both the previous lookup class and the current > |lookup| context (current lookup class and allowed modes) to determine if > a type is accessible to this `Lookup` object or not. > > In a nutshell, `T` in M2 is accessible to a `Lookup` object on `C` > (lookup class in M1) and `PLC` (previous lookup class in M0) if and > only if > 1. both M0 and M1 can read M2 > 2. T is in a package that is exported from M2 at least to both M0 and M1 > > Detailed specification is in Lookup class spec and `accessClass` javadoc. > The relevant spec about cross-module teleporting is in the Lookup class > spec and `Lookup::in` and `MethodHandles::privateLookupIn`. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8226916 > > webrev: > http://cr.openjdk.java.net/~mchung/jdk14/8173978/webrev.00 > > javadoc: > http://cr.openjdk.java.net/~mchung/jdk14/8173978/javadoc/java.base/java/lang/invoke/MethodHandles.Lookup.html > > > http://cr.openjdk.java.net/~mchung/jdk14/8173978/javadoc/java.base/java/lang/invoke/MethodHandles.html#privateLookupIn(java.lang.Class,java.lang.invoke.MethodHandles.Lookup) > > > I have yet to generate the spec diff. The tool is currently broken > due to javadoc change.? I'll try to workaround it and post the > spec diff soon. specdiff: http://cr.openjdk.java.net/~mchung/jdk14/8173978/specdiff/overview-summary.html Mandy From thomas.stuefe at gmail.com Tue Jul 2 05:23:06 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 2 Jul 2019 07:23:06 +0200 Subject: 8226863: [aix] jdk/java/lang/reflect/exeCallerAccessTest cannot launch on primordial thread In-Reply-To: References: Message-ID: Second, corrected Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/execalleraccesstest-cannot-launch-on-primordial-thread/webrev.01/webrev/ Run through SAP nightlies on all platforms. Cheers, Thomas On Thu, Jun 27, 2019 at 9:02 AM Thomas St?fe wrote: > Hi all, > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8226863 > webrev: > > http://cr.openjdk.java.net/~stuefe/webrevs/8226863--jdk-java-lang-reflect-execalleraccesstest-cannot-launch-on-primordial-thread/webrev.00/webrev/ > > we have this annoying issue on AIX that the libjvm cannot be invoked on a > primordial thread. Therefore we need to change launchers which create the > VM to spawn own threads (we only do this where it is worth the effort - > this, admittedly, is a corner case, we could alternatively just disable the > test on AIX). > > This is annoying and vaguely embarrassing :-/ Maybe IBM will step in some > time and help us solve the underlying issues which have to do with the > inability to create guard pages on the primordial thread stack (among other > things IIRC). > > Thanks for reviewing, > > Thomas > > > From sergei.tsypanov at yandex.ru Tue Jul 2 07:43:02 2019 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Tue, 02 Jul 2019 09:43:02 +0200 Subject: [ BUG ? ] simple code throws on Windows but works fine on *nix Message-ID: <733461562053382@iva6-22e79380f52c.qloud-c.yandex.net> Hello, one of key Java principles is "write once - run everywhere". It seems to me that this code breaks this rule ------------------------------------ import java.nio.file.Files; import java.nio.file.Path; import java.util.List; public class Main { public static void main(String[] args) throws IOException { String path = Main.class .getClassLoader() .getResource("tsypanov/example/war-and-peace.json") .getPath(); List lines = Files.readAllLines(Path.of(path)); assert lines.size() == 1; } } ------------------------------------ This code work under *nix (tested on MacOS and Linux Mint) and fails on Windows 10 with exception: Exception in thread "main" java.nio.file.InvalidPathException: Illegal char <:> at index 2: /C:/Users/sergii_tsypanov/IdeaProjects/jdk-bug/out/production/jdk-bug/tsypanov/example/war-and-peace.json at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92) at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:229) at java.base/java.nio.file.Path.of(Path.java:147) at tsypanov.example.Main.main(Main.java:15) As far as I use a relative path in my Java code I expect this to have same behaviour on all supported platforms. This was reproduced on JDK 12. I've prepared a test project on GitHub to reproduce this in IDEA: https://github.com/stsypanov/jdk-bug Regards, Sergey Tsypanov From Alan.Bateman at oracle.com Tue Jul 2 08:16:43 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 2 Jul 2019 09:16:43 +0100 Subject: [ BUG ? ] simple code throws on Windows but works fine on *nix In-Reply-To: <733461562053382@iva6-22e79380f52c.qloud-c.yandex.net> References: <733461562053382@iva6-22e79380f52c.qloud-c.yandex.net> Message-ID: <09034706-6e5b-d4a9-4bb1-c187eac949a0@oracle.com> On 02/07/2019 08:43, ?????? ??????? wrote: > Hello, > > one of key Java principles is "write once - run everywhere". > It seems to me that this code breaks this rule > ------------------------------------ > > import java.nio.file.Files; > import java.nio.file.Path; > import java.util.List; > > public class Main { > public static void main(String[] args) throws IOException { > String path = Main.class > .getClassLoader() > .getResource("tsypanov/example/war-and-peace.json") > .getPath(); Resource name -> URL -> URL path component.? A URL path component is not a file path. For file URLs then it encodes a file path (at least file paths that are not located on the network). There's a warning in the URL javadoc on this but maybe it's time to deprecate URL::getPath (in time we need to deprecate all of URL constructors and several methods but that is a topic for another day). For the example, change getPath to toURI so you get a URI rather than a String and it should work. -Alan From daniel.fuchs at oracle.com Tue Jul 2 08:21:21 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 2 Jul 2019 10:21:21 +0200 Subject: RFR(JDK 14/java.xml) 8223291: Whitespace is added to CDATA tags when using OutputKeys.INDENT to format XML In-Reply-To: <5D1A551E.1070600@oracle.com> References: <5D1A551E.1070600@oracle.com> Message-ID: Hi Joe, I haven't spotted anything obviously wrong. > The content of "abcxyz" should be "abc & xyz", not " abc\n & \n xyz\n" as that before this fix. Maybe the test could have a test case for that specific example too? Just to make sure whitespaces in CDATA aren't eaten away? best regards, -- daniel On 01/07/2019 20:46, Joe Wang wrote: > Please review a fix to xml pretty print. This is a regression introduced > during the JDK 9 development. CDATA is marked up to be interpreted > literally as textual data, in other words, it's still character data. > The processor therefore shall treat it as text data. The content of > "abcxyz" should be "abc & xyz", not "??? abc\n & \n > xyz\n" as that before this fix. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8223291 > webrev: http://cr.openjdk.java.net/~joehw/jdk14/8223291/webrev/ > > Thanks, > Joe > From daniel.fuchs at oracle.com Tue Jul 2 08:23:55 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 2 Jul 2019 10:23:55 +0200 Subject: RFR(JDK 14/java.xml) 8223291: Whitespace is added to CDATA tags when using OutputKeys.INDENT to format XML In-Reply-To: References: <5D1A551E.1070600@oracle.com> Message-ID: Oh, and BTW is the change to PrettyPrintTest.java intended? (the removal of the line: 385 dbf.setValidating(true); seems to be the only change) best regards, -- daniel On 02/07/2019 10:21, Daniel Fuchs wrote: > JBS: https://bugs.openjdk.java.net/browse/JDK-8223291 > webrev: http://cr.openjdk.java.net/~joehw/jdk14/8223291/webrev/ From sergei.tsypanov at yandex.ru Tue Jul 2 08:25:07 2019 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Tue, 02 Jul 2019 10:25:07 +0200 Subject: [ BUG ? ] simple code throws on Windows but works fine on *nix In-Reply-To: <09034706-6e5b-d4a9-4bb1-c187eac949a0@oracle.com> References: <733461562053382@iva6-22e79380f52c.qloud-c.yandex.net> <09034706-6e5b-d4a9-4bb1-c187eac949a0@oracle.com> Message-ID: <4964141562055907@myt1-4903e6646a45.qloud-c.yandex.net> > For the example, change getPath to > toURI so you get a URI rather than a String and it should work. Hello, this is exactly how I've worked this around. But shouldn't behaviour be the same on all platforms at least when accessing files on a local drive? Regards, Sergey Tsypanov From daniel.fuchs at oracle.com Tue Jul 2 08:36:02 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 2 Jul 2019 10:36:02 +0200 Subject: [ BUG ? ] simple code throws on Windows but works fine on *nix In-Reply-To: <4964141562055907@myt1-4903e6646a45.qloud-c.yandex.net> References: <733461562053382@iva6-22e79380f52c.qloud-c.yandex.net> <09034706-6e5b-d4a9-4bb1-c187eac949a0@oracle.com> <4964141562055907@myt1-4903e6646a45.qloud-c.yandex.net> Message-ID: <437145ef-2b04-bb5e-ce63-1c222754edb0@oracle.com> Hi Sergey, On 02/07/2019 10:25, ?????? ??????? wrote: > Hello, > > this is exactly how I've worked this around. > > But shouldn't behaviour be the same on all platforms > at least when accessing files on a local drive? Hierarchical URLs/URIs are specified to use '/' as file separator This is platform independent. On the other hand file systems are platform dependents: the file system file separator is '/' on UNIX and '\' on windows. Therefore converting a URL path to a String and then feeding it to the file system without any validation/conversion is a bug in your code. As Alan mentioned, an URL path is not a file path even if it looks like it. Using Path.of(URI) is the right API, and not a work around. best regards, -- daniel > > Regards, > Sergey Tsypanov From sergei.tsypanov at yandex.ru Tue Jul 2 08:48:48 2019 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Tue, 02 Jul 2019 10:48:48 +0200 Subject: [ BUG ? ] simple code throws on Windows but works fine on *nix In-Reply-To: <437145ef-2b04-bb5e-ce63-1c222754edb0@oracle.com> References: <733461562053382@iva6-22e79380f52c.qloud-c.yandex.net> <09034706-6e5b-d4a9-4bb1-c187eac949a0@oracle.com> <4964141562055907@myt1-4903e6646a45.qloud-c.yandex.net> <437145ef-2b04-bb5e-ce63-1c222754edb0@oracle.com> Message-ID: <13128011562057328@myt1-4ac6a2e2d480.qloud-c.yandex.net> Hi Daniel, then I'll use URI in my code. Thanks for explanation, I was sure something is wrong with JDK. Regards, Sergey Tsypanov 02.07.2019, 10:36, "Daniel Fuchs" : > Hi Sergey, > > On 02/07/2019 10:25, ?????? ??????? wrote: >> ?Hello, >> >> ?this is exactly how I've worked this around. >> >> ?But shouldn't behaviour be the same on all platforms >> ?at least when accessing files on a local drive? > > Hierarchical URLs/URIs are specified to use '/' as file separator > This is platform independent. > On the other hand file systems are platform dependents: > the file system file separator is '/' on UNIX and '\' on > windows. > > Therefore converting a URL path to a String and then feeding > it to the file system without any validation/conversion is a bug > in your code. As Alan mentioned, an URL path is not a file path > even if it looks like it. > > Using Path.of(URI) is the right API, and not a work around. > > best regards, > > -- daniel > >> ?Regards, >> ?Sergey Tsypanov From kasperni at gmail.com Tue Jul 2 09:09:11 2019 From: kasperni at gmail.com (Kasper Nielsen) Date: Tue, 2 Jul 2019 10:09:11 +0100 Subject: Slow performance of StackWalker.getCallerClass() vs Reflection.getCallerClass() Message-ID: Hi, Are there any security reasons for why StackWalker.getCallerClass() cannot be made as performant as Reflection.getCallerClass()? StackWalker.getCallerClass() is at least 100 times slower then Reflection.getCallerClass() (~1000 ns/op vs ~10 ns/op). I'm trying to retrofit some existing APIs where I cannot take a Lookup object to do some access control checks. But the performance of StackWalker.getCallerClass() is making it impossible. Best Kasper From forax at univ-mlv.fr Tue Jul 2 12:49:59 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 2 Jul 2019 14:49:59 +0200 (CEST) Subject: Slow performance of StackWalker.getCallerClass() vs Reflection.getCallerClass() In-Reply-To: References: Message-ID: <1082795724.1561886.1562071799378.JavaMail.zimbra@u-pem.fr> Hi Kasper, did you store the StackWalker instance in a static final field ? R?mi ----- Mail original ----- > De: "Kasper Nielsen" > ?: "core-libs-dev" > Envoy?: Mardi 2 Juillet 2019 11:09:11 > Objet: Slow performance of StackWalker.getCallerClass() vs Reflection.getCallerClass() > Hi, > > Are there any security reasons for why StackWalker.getCallerClass() > cannot be made as performant as Reflection.getCallerClass()? > StackWalker.getCallerClass() is at least 100 times slower then > Reflection.getCallerClass() (~1000 ns/op vs ~10 ns/op). > > I'm trying to retrofit some existing APIs where I cannot take a Lookup > object to do some access control checks. > But the performance of StackWalker.getCallerClass() is making it impossible. > > Best > Kasper From kasperni at gmail.com Tue Jul 2 13:07:03 2019 From: kasperni at gmail.com (Kasper Nielsen) Date: Tue, 2 Jul 2019 14:07:03 +0100 Subject: Slow performance of StackWalker.getCallerClass() vs Reflection.getCallerClass() In-Reply-To: <1082795724.1561886.1562071799378.JavaMail.zimbra@u-pem.fr> References: <1082795724.1561886.1562071799378.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Remi, Yes, setting up a StackWalker is more or less free. It is just wrapping a set of options. public class StackWalkerPerf { static final StackWalker sw = StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE); @Benchmark public StackWalker stackWalkerSetup() { return StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE); } @Benchmark public Class stackWalkerCallerClass() { return sw.getCallerClass(); } @Benchmark public Lookup reflectionCallerClass() { return MethodHandles.lookup(); } } Benchmark Mode Cnt Score Error Units StackWalkerPerf.stackWalkerSetup avgt 10 11.958 ? 0.353 ns/op StackWalkerPerf.reflectionCallerClass avgt 10 8.511 ? 0.415 ns/op StackWalkerPerf.stackWalkerCallerClass avgt 10 1269.825 ? 66.471 ns/op I'm using MethodHandles.lookup() in this test because it is cheapest way to invoke Reflection.getCallerClass() without any tricks. So real performance is likely better. /Kasper On Tue, 2 Jul 2019 at 13:53, Remi Forax wrote: > > Hi Kasper, > did you store the StackWalker instance in a static final field ? > > R?mi > > ----- Mail original ----- > > De: "Kasper Nielsen" > > ?: "core-libs-dev" > > Envoy?: Mardi 2 Juillet 2019 11:09:11 > > Objet: Slow performance of StackWalker.getCallerClass() vs Reflection.getCallerClass() > > > Hi, > > > > Are there any security reasons for why StackWalker.getCallerClass() > > cannot be made as performant as Reflection.getCallerClass()? > > StackWalker.getCallerClass() is at least 100 times slower then > > Reflection.getCallerClass() (~1000 ns/op vs ~10 ns/op). > > > > I'm trying to retrofit some existing APIs where I cannot take a Lookup > > object to do some access control checks. > > But the performance of StackWalker.getCallerClass() is making it impossible. > > > > Best > > Kasper From Alan.Bateman at oracle.com Tue Jul 2 13:59:22 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 2 Jul 2019 14:59:22 +0100 Subject: Review Request: JDK-8173978: Lookup.in should allow teleporting from a lookup class in a named module without dropping all access In-Reply-To: <77478136-29fd-45f9-d122-6826099dfe84@oracle.com> References: <77478136-29fd-45f9-d122-6826099dfe84@oracle.com> Message-ID: <847246aa-fa7a-5781-a973-5eb021a294e3@oracle.com> On 01/07/2019 20:51, Mandy Chung wrote: > This is an enhancement to |`Lookup::in`| and > |`MethodHandles::privateLookupIn`| API > for cross module teleporting.? A `Lookup` object will record the previous > lookup class from which this |Lookup| object was teleported such that > the access check will use both the previous lookup class and the current > |lookup| context (current lookup class and allowed modes) to determine if > a type is accessible to this `Lookup` object or not. > > In a nutshell, `T` in M2 is accessible to a `Lookup` object on `C` > (lookup class in M1) and `PLC` (previous lookup class in M0) if and > only if > 1. both M0 and M1 can read M2 > 2. T is in a package that is exported from M2 at least to both M0 and M1 > > Detailed specification is in Lookup class spec and `accessClass` javadoc. > The relevant spec about cross-module teleporting is in the Lookup class > spec and `Lookup::in` and `MethodHandles::privateLookupIn`. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8226916 > > webrev: > http://cr.openjdk.java.net/~mchung/jdk14/8173978/webrev.00 > > javadoc: > http://cr.openjdk.java.net/~mchung/jdk14/8173978/javadoc/java.base/java/lang/invoke/MethodHandles.Lookup.html > > > http://cr.openjdk.java.net/~mchung/jdk14/8173978/javadoc/java.base/java/lang/invoke/MethodHandles.html#privateLookupIn(java.lang.Class,java.lang.invoke.MethodHandles.Lookup) > This is really good work and fixes several issues left over from JDK 9. The compatibility issues (mostly small/advanced) are unfortunate but necessary and I hope it won't impact too many things. It will need a detail release note once the CSR is done and the changes are in. I've taken several passes over the changes and I don't see anything obviously wrong. One minor nit is that the @throws IllegalAccessException in accessClass(Class) needs to be updated to allow for it to thrown when not accessible from the previous lookup class. Also VerifyAccess::isModuleAccessible shouldn't need to if the package is exported unconditionally as it is covered by isExported(pn, m1) && isExported(pn, m2). -Alan From thejasvi.v.voniadka at oracle.com Tue Jul 2 14:32:07 2019 From: thejasvi.v.voniadka at oracle.com (Thejasvi Voniadka) Date: Tue, 2 Jul 2019 07:32:07 -0700 (PDT) Subject: RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string In-Reply-To: <1e497a17-ac12-d2f6-064f-39c4cb15223b@oracle.com> References: <8ec24050-0c2a-4f2d-88e6-a3fba5d40e12@default> <1e497a17-ac12-d2f6-064f-39c4cb15223b@oracle.com> Message-ID: <590cca03-1741-41a2-9544-157d1f553835@default> Hi Naoto, Thank you for the review. I have performed the modifications, and here is the updated webrev: http://cr.openjdk.java.net/~vagarwal/8154520/webrev.2/ I have moved the new tests from TCK area. I have also updated the current TCK test to explicitly pass Locale.US while calling format. -----Original Message----- From: Naoto Sato Sent: Monday, July 01, 2019 9:02 PM To: Thejasvi Voniadka ; core-libs-dev at openjdk.java.net; i18n-dev at openjdk.java.net Subject: Re: RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string Hi Thejasvi, Thanks for fixing this. Since those new test cases depend on the CLDR localization, which might change in other implementations, those test cases should be in jdk/java/time/test directory, as "tck" tests should only test the spec. Please create a new test case for this in the "test" directory (with @modules jdk.localedata directive) similar to the existing TCK one. Also the current test in the TCK should enforce that it runs in Locale.US so that the result should match "GMT." Naoto On 6/28/19 5:59 AM, Thejasvi Voniadka wrote: > Hi, > > Request you to please review this change. > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8154520 > > > Description: At present, the "DateTimeFormatterBuilder.appendLocalizedOffset()" method formulates the base string as "GMT", without accounting for locale-specific transformations. This change is to return the localized version of "GMT" instead. So for example, instead of returning "GMT +5.30", it may now return "XXXX +5.30" where "XXXX" is the localized string for "GMT" for the locale associated with the formatter. I have used DateTimeTextProvider.getLocalizedResource() method to return the "gmtZeroFormat" value from CLDR/LDML corresponding to the given locale. The code defaults to "GMT" in the absence of such a localized value. > > > Webrev: http://cr.openjdk.java.net/~vagarwal/8154520/webrev.1/ > > > Additional notes: I preferred to update and reuse an existing test instead of creating a new one. It already has the niceties in place, and creating another method would mean some amount of code redundancy. However, if that's the recommended norm, then I can change it. > From daniel.fuchs at oracle.com Tue Jul 2 15:03:44 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 2 Jul 2019 17:03:44 +0200 Subject: Review Request: JDK-8173978: Lookup.in should allow teleporting from a lookup class in a named module without dropping all access In-Reply-To: References: <77478136-29fd-45f9-d122-6826099dfe84@oracle.com> Message-ID: <3666da22-6d60-95fc-d7a4-b473197ffcee@oracle.com> Hi Mandy, Don't count me as reviewer; this is only editorial: In MethodHandles.java: ============ 165 * A caller, specified as a {@code Lookup} object, is in module {@code M1} is 166 * allowed to do deep reflection on module {@code M2} and package of the target class 167 * if and only if all of the following conditions are {@code true}: There are two 'is' in this sentence, which makes it a bit difficult to parse. Should the first be removed? * A caller, specified as a {@code Lookup} object, in module {@code M1} is ... ============ 169 *
  • If there is a security manager, its {@code checkPermission} method is 170 * called to check {@code ReflectPermission("suppressAccessChecks")} and 171 * that must return normally. 172 *
  • 173 * If there is a security manager, its {@code checkPermission} method is 174 * called to check {@code ReflectPermission("suppressAccessChecks")}. 175 * This method must return normally. Probably one of these two bullets should be removed: they look the same to me. ============= 585 * A {@code Lookup} with {@link #PUBLIC} mode and a lookup class in {@code M1} 586 * can access public types in a module {@code M2} when {@code M2} is readable to 587 * {@code M1} when the type is in a package of {@code M2} that is exported to at least {@code M1}. ^^^^ I believe there is "and" missing here: <<... when M2 is readable to M1 *and* when the type ....>> =========== Is the specdiff report incomplete? I was hoping to see the table added to the Lookup class level API under 582 *

    Cross-module lookups

    but it seems to be missing from the specdiff? BTW: is

    the right header? I thought

    was reserved for the class name. John Gibbon will know more ;-) best regards, -- daniel On 02/07/2019 03:47, Mandy Chung wrote: > > > On 7/1/19 12:51 PM, Mandy Chung wrote: >> This is an enhancement to |`Lookup::in`| and >> |`MethodHandles::privateLookupIn`| API >> for cross module teleporting.? A `Lookup` object will record the previous >> lookup class from which this |Lookup| object was teleported such that >> the access check will use both the previous lookup class and the current >> |lookup| context (current lookup class and allowed modes) to determine if >> a type is accessible to this `Lookup` object or not. >> >> In a nutshell, `T` in M2 is accessible to a `Lookup` object on `C` >> (lookup class in M1) and `PLC` (previous lookup class in M0) if and >> only if >> 1. both M0 and M1 can read M2 >> 2. T is in a package that is exported from M2 at least to both M0 and M1 >> >> Detailed specification is in Lookup class spec and `accessClass` javadoc. >> The relevant spec about cross-module teleporting is in the Lookup class >> spec and `Lookup::in` and `MethodHandles::privateLookupIn`. >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8226916 >> >> webrev: >> http://cr.openjdk.java.net/~mchung/jdk14/8173978/webrev.00 >> >> javadoc: >> http://cr.openjdk.java.net/~mchung/jdk14/8173978/javadoc/java.base/java/lang/invoke/MethodHandles.Lookup.html >> >> >> http://cr.openjdk.java.net/~mchung/jdk14/8173978/javadoc/java.base/java/lang/invoke/MethodHandles.html#privateLookupIn(java.lang.Class,java.lang.invoke.MethodHandles.Lookup) >> >> >> I have yet to generate the spec diff. The tool is currently broken >> due to javadoc change.? I'll try to workaround it and post the >> spec diff soon. > > specdiff: > > http://cr.openjdk.java.net/~mchung/jdk14/8173978/specdiff/overview-summary.html > > > Mandy From kasperni at gmail.com Tue Jul 2 15:35:45 2019 From: kasperni at gmail.com (Kasper Nielsen) Date: Tue, 2 Jul 2019 16:35:45 +0100 Subject: Review Request: JDK-8173978: Lookup.in should allow teleporting from a lookup class in a named module without dropping all access In-Reply-To: <77478136-29fd-45f9-d122-6826099dfe84@oracle.com> References: <77478136-29fd-45f9-d122-6826099dfe84@oracle.com> Message-ID: Hi Mandy, Are there any plans to make functionality from VerifyAccess public in any way? Changes to the access model like these are extremely frustrating because the access check mechanisms in VerifyAccess are not available outside of the JDK. I've posted about this before [1][2], But if you are a library developer there are basically no way to cache a MethodHandle and allow it to be used against multiple different Lookup objects because the access checks are so complicated. Another really useful addition would be a LookupValue class (similar to ClassValue) which would allow you to cache access check information for a given lookup object. Right now, I'm using a cache of ClassValue> with lookupClass and allowedModes as parameters [3]. This will obviously break with these changes. A simple use case is implement a simple serialization library with the following signature String serializeToString(Class clazz, MethodHandles.Lookup lookup). Trying to implement something like this that is both performant, secure and classloader friendly is really difficult. Creating varhandles/methodhandles for every call to 'serializeToString ' is not performant for obvious reasons. So you need to cache it in some way, which is currently non-trivial. /Kasper [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2018-October/014012.html [2] https://bugs.openjdk.java.net/browse/JDK-8213251 [3] https://gist.github.com/kaspernielsen/540aacaf0581e7be80b0ebe3348f4a24 On Mon, 1 Jul 2019 at 20:51, Mandy Chung wrote: > > This is an enhancement to |`Lookup::in`| and > |`MethodHandles::privateLookupIn`| API > for cross module teleporting. A `Lookup` object will record the previous > lookup class from which this |Lookup| object was teleported such that > the access check will use both the previous lookup class and the current > |lookup| context (current lookup class and allowed modes) to determine if > a type is accessible to this `Lookup` object or not. > > In a nutshell, `T` in M2 is accessible to a `Lookup` object on `C` > (lookup class in M1) and `PLC` (previous lookup class in M0) if and only if > 1. both M0 and M1 can read M2 > 2. T is in a package that is exported from M2 at least to both M0 and M1 > > Detailed specification is in Lookup class spec and `accessClass` javadoc. > The relevant spec about cross-module teleporting is in the Lookup class > spec and `Lookup::in` and `MethodHandles::privateLookupIn`. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8226916 > > webrev: > http://cr.openjdk.java.net/~mchung/jdk14/8173978/webrev.00 > > javadoc: > http://cr.openjdk.java.net/~mchung/jdk14/8173978/javadoc/java.base/java/lang/invoke/MethodHandles.Lookup.html > > http://cr.openjdk.java.net/~mchung/jdk14/8173978/javadoc/java.base/java/lang/invoke/MethodHandles.html#privateLookupIn(java.lang.Class,java.lang.invoke.MethodHandles.Lookup) > > I have yet to generate the spec diff. The tool is currently broken > due to javadoc change. I'll try to workaround it and post the > spec diff soon. > > thanks > Mandy From huizhe.wang at oracle.com Tue Jul 2 15:51:11 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 02 Jul 2019 08:51:11 -0700 Subject: RFR(JDK 14/java.xml) 8223291: Whitespace is added to CDATA tags when using OutputKeys.INDENT to format XML In-Reply-To: References: <5D1A551E.1070600@oracle.com> Message-ID: <5D1B7D6F.3@oracle.com> Thanks Daniel. That test case is added. Best, Joe On 7/2/19, 1:21 AM, Daniel Fuchs wrote: > Hi Joe, > > I haven't spotted anything obviously wrong. > >> The content of "abcxyz" should be "abc & xyz", not >> " abc\n & \n xyz\n" as that before this fix. > > Maybe the test could have a test case for that specific example too? > Just to make sure whitespaces in CDATA aren't eaten away? > > best regards, > > -- daniel > > > On 01/07/2019 20:46, Joe Wang wrote: >> Please review a fix to xml pretty print. This is a regression >> introduced during the JDK 9 development. CDATA is marked up to be >> interpreted literally as textual data, in other words, it's still >> character data. The processor therefore shall treat it as text data. >> The content of "abcxyz" should be "abc & xyz", not >> " abc\n & \n xyz\n" as that before this fix. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8223291 >> webrev: http://cr.openjdk.java.net/~joehw/jdk14/8223291/webrev/ >> >> Thanks, >> Joe >> > From Alan.Bateman at oracle.com Tue Jul 2 15:51:25 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 2 Jul 2019 16:51:25 +0100 Subject: Review Request: JDK-8173978: Lookup.in should allow teleporting from a lookup class in a named module without dropping all access In-Reply-To: References: <77478136-29fd-45f9-d122-6826099dfe84@oracle.com> Message-ID: <59437c87-e272-c017-c817-2f42223452e5@oracle.com> On 02/07/2019 16:35, Kasper Nielsen wrote: > Right now, > I'm using a cache of ClassValue> > with lookupClass and allowedModes as parameters [3]. This will > obviously break with > these changes. > Are you using privateLookupIn and dropping PRIVATE access? Are you teleporting in Lookup.in? It might be that you don't have to change anything. -Alan From huizhe.wang at oracle.com Tue Jul 2 15:53:18 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 02 Jul 2019 08:53:18 -0700 Subject: RFR(JDK 14/java.xml) 8223291: Whitespace is added to CDATA tags when using OutputKeys.INDENT to format XML In-Reply-To: References: <5D1A551E.1070600@oracle.com> Message-ID: <5D1B7DEE.8050200@oracle.com> On 7/2/19, 1:23 AM, Daniel Fuchs wrote: > Oh, and BTW is the change to PrettyPrintTest.java intended? > (the removal of the line: > 385 dbf.setValidating(true); > seems to be the only change) Yes. The only effect of setting validating without an ErrorHandler was producing lots of warnings in the test result. It was therefore removed. Best, Joe > > best regards, > > -- daniel > > On 02/07/2019 10:21, Daniel Fuchs wrote: >> JBS: https://bugs.openjdk.java.net/browse/JDK-8223291 >> webrev: http://cr.openjdk.java.net/~joehw/jdk14/8223291/webrev/ > From Alan.Bateman at oracle.com Tue Jul 2 15:59:42 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 2 Jul 2019 16:59:42 +0100 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <892f3b0b-55f1-872d-15f4-5af907fa8437@redhat.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <656f462e-c655-0c48-7c90-190c92e0bc28@redhat.com> <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com> <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> <892f3b0b-55f1-872d-15f4-5af907fa8437@redhat.com> Message-ID: On 18/06/2019 12:43, Andrew Dinn wrote: > Hi Alan, > > Thanks for reviewing the JEP one more time. The proposed updates look good to me. One nit is that the update to the Goals section says "rework" in two places. I think it might more accurate to say "upgrade" or "update" as it doesn't significantly re-working the existing implementation. -Alan From naoto.sato at oracle.com Tue Jul 2 16:03:12 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 2 Jul 2019 09:03:12 -0700 Subject: RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string In-Reply-To: <590cca03-1741-41a2-9544-157d1f553835@default> References: <8ec24050-0c2a-4f2d-88e6-a3fba5d40e12@default> <1e497a17-ac12-d2f6-064f-39c4cb15223b@oracle.com> <590cca03-1741-41a2-9544-157d1f553835@default> Message-ID: <0ba3fe52-ba6f-df36-7a99-d5b8741920fc@oracle.com> Hi Thejasvi, Here are my comments to the webrev: TCKOffsetPrinterParser.java - No need to define Locale_US as a static field, nor have it in the test data (data_print_localized) then pass it as an argument to the test. Specifying Locale.US in line 572, 578, and 586 should suffice. TestOffsetPrinterParser.java - Copyright year is 2019. - It would be nice if some comments that reads something like "This test relies on the localized text of "GMT" in the CLDR." - Test class (and the description) should include "Localized", as it is testing the implementation of localized version of OffsetIdPrinterParser. - Line 64-76: I prefer just instantiating them in the test data, not defining a static field for each, unless there will be duplicate in the test data. - Line 111, 118, 124, 132: I believe the locale parameter is required. Make sure that with Objects.requireNonNull(), or fail if it's null. Naoto On 7/2/19 7:32 AM, Thejasvi Voniadka wrote: > Hi Naoto, > > Thank you for the review. I have performed the modifications, and here is the updated webrev: > > http://cr.openjdk.java.net/~vagarwal/8154520/webrev.2/ > > > I have moved the new tests from TCK area. I have also updated the current TCK test to explicitly pass Locale.US while calling format. > > > > > -----Original Message----- > From: Naoto Sato > Sent: Monday, July 01, 2019 9:02 PM > To: Thejasvi Voniadka ; core-libs-dev at openjdk.java.net; i18n-dev at openjdk.java.net > Subject: Re: RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string > > Hi Thejasvi, > > Thanks for fixing this. > > Since those new test cases depend on the CLDR localization, which might change in other implementations, those test cases should be in jdk/java/time/test directory, as "tck" tests should only test the spec. > Please create a new test case for this in the "test" directory (with @modules jdk.localedata directive) similar to the existing TCK one. Also the current test in the TCK should enforce that it runs in Locale.US so that the result should match "GMT." > > Naoto > > On 6/28/19 5:59 AM, Thejasvi Voniadka wrote: >> Hi, >> >> Request you to please review this change. >> >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8154520 >> >> >> Description: At present, the "DateTimeFormatterBuilder.appendLocalizedOffset()" method formulates the base string as "GMT", without accounting for locale-specific transformations. This change is to return the localized version of "GMT" instead. So for example, instead of returning "GMT +5.30", it may now return "XXXX +5.30" where "XXXX" is the localized string for "GMT" for the locale associated with the formatter. I have used DateTimeTextProvider.getLocalizedResource() method to return the "gmtZeroFormat" value from CLDR/LDML corresponding to the given locale. The code defaults to "GMT" in the absence of such a localized value. >> >> >> Webrev: http://cr.openjdk.java.net/~vagarwal/8154520/webrev.1/ >> >> >> Additional notes: I preferred to update and reuse an existing test instead of creating a new one. It already has the niceties in place, and creating another method would mean some amount of code redundancy. However, if that's the recommended norm, then I can change it. >> From daniel.fuchs at oracle.com Tue Jul 2 16:16:08 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 2 Jul 2019 18:16:08 +0200 Subject: RFR(JDK 14/java.xml) 8223291: Whitespace is added to CDATA tags when using OutputKeys.INDENT to format XML In-Reply-To: <5D1B7D6F.3@oracle.com> References: <5D1A551E.1070600@oracle.com> <5D1B7D6F.3@oracle.com> Message-ID: <95a8d280-5eeb-d1df-dcab-bace0f7dc145@oracle.com> Hi Joe, On 02/07/2019 17:51, Joe Wang wrote: > Thanks Daniel. That test case is added. LGTM! best regards, -- daniel > > Best, > Joe > > On 7/2/19, 1:21 AM, Daniel Fuchs wrote: >> Hi Joe, >> >> I haven't spotted anything obviously wrong. >> >>> The content of "abcxyz" should be "abc & xyz", not >>> "??? abc\n & \n??? xyz\n" as that before this fix. >> >> Maybe the test could have a test case for that specific example too? >> Just to make sure whitespaces in CDATA aren't eaten away? >> >> best regards, >> >> -- daniel >> >> >> On 01/07/2019 20:46, Joe Wang wrote: >>> Please review a fix to xml pretty print. This is a regression >>> introduced during the JDK 9 development. CDATA is marked up to be >>> interpreted literally as textual data, in other words, it's still >>> character data. The processor therefore shall treat it as text data. >>> The content of "abcxyz" should be "abc & xyz", not >>> "??? abc\n & \n xyz\n" as that before this fix. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8223291 >>> webrev: http://cr.openjdk.java.net/~joehw/jdk14/8223291/webrev/ >>> >>> Thanks, >>> Joe >>> >> From mandy.chung at oracle.com Tue Jul 2 16:57:20 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 2 Jul 2019 09:57:20 -0700 Subject: Review Request: JDK-8173978: Lookup.in should allow teleporting from a lookup class in a named module without dropping all access In-Reply-To: <3666da22-6d60-95fc-d7a4-b473197ffcee@oracle.com> References: <77478136-29fd-45f9-d122-6826099dfe84@oracle.com> <3666da22-6d60-95fc-d7a4-b473197ffcee@oracle.com> Message-ID: <0cef6970-0a92-e8e0-321e-59c7d3f19264@oracle.com> Hi Daniel, Thanks for catching these. On 7/2/19 8:03 AM, Daniel Fuchs wrote: > Hi Mandy, > > Don't count me as reviewer; this is only editorial: > > In MethodHandles.java: > > ============ > > ?165????? * A caller, specified as a {@code Lookup} object, is in > module {@code M1} is > ?166????? * allowed to do deep reflection on module {@code M2} and > package of the target class > ?167????? * if and only if all of the following conditions are {@code > true}: > > There are two 'is' in this sentence, which makes it a bit difficult > to parse. Should the first be removed? > Yes the first "is" is removed. > * A caller, specified as a {@code Lookup} object, in module {@code M1} > is ... > > ============ > > ?169????? *
  • If there is a security manager, its {@code > checkPermission} method is > ?170????? * called to check {@code > ReflectPermission("suppressAccessChecks")} and > ?171????? * that must return normally. > ?172????? *
  • > ?173????? * If there is a security manager, its {@code > checkPermission} method is > ?174????? * called to check {@code > ReflectPermission("suppressAccessChecks")}. > ?175????? * This method must return normally. > > Probably one of these two bullets should be removed: they look > the same to me. > Removed. Thanks for catching it. > ============= > > ?585????? * A {@code Lookup} with {@link #PUBLIC} mode and a lookup > class in {@code M1} > ?586????? * can access public types in a module {@code M2} when {@code > M2} is readable to > ?587????? * {@code M1} when the type is in a package of {@code M2} > that is exported to at least {@code M1}. > ???????????????????? ^^^^ > I believe there is "and" missing here: > > ? <<... when M2 is readable to M1 *and* when the type ....>> > Fixed. > =========== > > Is the specdiff report incomplete? I was hoping to see the table > added to the Lookup class level API under > > ?582????? *

    Cross-module lookups

    > > but it seems to be missing from the specdiff? > The specdiff tool is broken.? Sigh... I workaround to generate the method/field summary but hit another bug that it does not generate the class summary. > BTW: is

    the right header? I thought

    was reserved for the > ???? class name. John Gibbon will know more ;-) > It should be

    .?? Updated.?? This was written prior to that change. thanks Mandy > best regards, > > -- daniel > > On 02/07/2019 03:47, Mandy Chung wrote: >> >> >> On 7/1/19 12:51 PM, Mandy Chung wrote: >>> This is an enhancement to |`Lookup::in`| and >>> |`MethodHandles::privateLookupIn`| API >>> for cross module teleporting.? A `Lookup` object will record the >>> previous >>> lookup class from which this |Lookup| object was teleported such that >>> the access check will use both the previous lookup class and the >>> current >>> |lookup| context (current lookup class and allowed modes) to >>> determine if >>> a type is accessible to this `Lookup` object or not. >>> >>> In a nutshell, `T` in M2 is accessible to a `Lookup` object on `C` >>> (lookup class in M1) and `PLC` (previous lookup class in M0) if and >>> only if >>> 1. both M0 and M1 can read M2 >>> 2. T is in a package that is exported from M2 at least to both M0 >>> and M1 >>> >>> Detailed specification is in Lookup class spec and `accessClass` >>> javadoc. >>> The relevant spec about cross-module teleporting is in the Lookup class >>> spec and `Lookup::in` and `MethodHandles::privateLookupIn`. >>> >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8226916 >>> >>> webrev: >>> http://cr.openjdk.java.net/~mchung/jdk14/8173978/webrev.00 >>> >>> javadoc: >>> http://cr.openjdk.java.net/~mchung/jdk14/8173978/javadoc/java.base/java/lang/invoke/MethodHandles.Lookup.html >>> >>> >>> http://cr.openjdk.java.net/~mchung/jdk14/8173978/javadoc/java.base/java/lang/invoke/MethodHandles.html#privateLookupIn(java.lang.Class,java.lang.invoke.MethodHandles.Lookup) >>> >>> >>> I have yet to generate the spec diff. The tool is currently broken >>> due to javadoc change.? I'll try to workaround it and post the >>> spec diff soon. >> >> specdiff: >> >> http://cr.openjdk.java.net/~mchung/jdk14/8173978/specdiff/overview-summary.html >> >> >> Mandy > From kasperni at gmail.com Tue Jul 2 16:58:24 2019 From: kasperni at gmail.com (Kasper Nielsen) Date: Tue, 2 Jul 2019 17:58:24 +0100 Subject: Review Request: JDK-8173978: Lookup.in should allow teleporting from a lookup class in a named module without dropping all access In-Reply-To: <59437c87-e272-c017-c817-2f42223452e5@oracle.com> References: <77478136-29fd-45f9-d122-6826099dfe84@oracle.com> <59437c87-e272-c017-c817-2f42223452e5@oracle.com> Message-ID: On Tue, 2 Jul 2019 at 16:51, Alan Bateman wrote: > > Are you using privateLookupIn and dropping PRIVATE access? Are you > teleporting in Lookup.in? It might be that you don't have to change > anything. I don't really have any control over how the Lookup object is created. It is provide by users of the library. And I just use the "raw" version (this might change at some point). /Kasper /Kasper From huizhe.wang at oracle.com Tue Jul 2 17:10:08 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 02 Jul 2019 10:10:08 -0700 Subject: RFR(JDK 14/java.xml) 8223291: Whitespace is added to CDATA tags when using OutputKeys.INDENT to format XML In-Reply-To: <95a8d280-5eeb-d1df-dcab-bace0f7dc145@oracle.com> References: <5D1A551E.1070600@oracle.com> <5D1B7D6F.3@oracle.com> <95a8d280-5eeb-d1df-dcab-bace0f7dc145@oracle.com> Message-ID: <5D1B8FF0.7020402@oracle.com> Thanks Daniel! On 7/2/19, 9:16 AM, Daniel Fuchs wrote: > Hi Joe, > > On 02/07/2019 17:51, Joe Wang wrote: >> Thanks Daniel. That test case is added. > > LGTM! > > best regards, > > -- daniel > >> >> Best, >> Joe >> >> On 7/2/19, 1:21 AM, Daniel Fuchs wrote: >>> Hi Joe, >>> >>> I haven't spotted anything obviously wrong. >>> >>>> The content of "abcxyz" should be "abc & xyz", not >>>> " abc\n & \n xyz\n" as that before this fix. >>> >>> Maybe the test could have a test case for that specific example too? >>> Just to make sure whitespaces in CDATA aren't eaten away? >>> >>> best regards, >>> >>> -- daniel >>> >>> >>> On 01/07/2019 20:46, Joe Wang wrote: >>>> Please review a fix to xml pretty print. This is a regression >>>> introduced during the JDK 9 development. CDATA is marked up to be >>>> interpreted literally as textual data, in other words, it's still >>>> character data. The processor therefore shall treat it as text >>>> data. The content of "abcxyz" should be "abc & xyz", >>>> not " abc\n & \n xyz\n" as that before this fix. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8223291 >>>> webrev: http://cr.openjdk.java.net/~joehw/jdk14/8223291/webrev/ >>>> >>>> Thanks, >>>> Joe >>>> >>> > From adinn at redhat.com Tue Jul 2 17:13:02 2019 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 2 Jul 2019 18:13:02 +0100 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com> <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> <892f3b0b-55f1-872d-15f4-5af907fa8437@redhat.com> Message-ID: Hi Alan, On 02/07/2019 16:59, Alan Bateman wrote: > On 18/06/2019 12:43, Andrew Dinn wrote: > One nit is that the update to the Goals section says "rework" in two > places. I think it might more accurate to say "upgrade" or "update" as > it doesn't significantly re-working the existing implementation. Thanks for checking this rewording. I have updated the JEP text modulo replacing reworked with upgraded. regards, Andrew Dinn ----------- From mandy.chung at oracle.com Tue Jul 2 17:20:16 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 2 Jul 2019 10:20:16 -0700 Subject: Review Request: JDK-8173978: Lookup.in should allow teleporting from a lookup class in a named module without dropping all access In-Reply-To: <847246aa-fa7a-5781-a973-5eb021a294e3@oracle.com> References: <77478136-29fd-45f9-d122-6826099dfe84@oracle.com> <847246aa-fa7a-5781-a973-5eb021a294e3@oracle.com> Message-ID: <76395107-8da7-4bdf-66ec-b5f9f1459284@oracle.com> On 7/2/19 6:59 AM, Alan Bateman wrote: > This is really good work and fixes several issues left over from JDK > 9. The compatibility issues (mostly small/advanced) are unfortunate > but necessary and I hope it won't impact too many things. It will need > a detail release note once the CSR is done and the changes are in. > The existing usage of `privateLookupIn` I am aware of is using a private lookup object and do deep reflection in one module.?? I expect that the compatibility risk should be low while the library developers/maintainers are encouraged to test with EA early. > I've taken several passes over the changes and I don't see anything > obviously wrong. One minor nit is that the @throws > IllegalAccessException in accessClass(Class) needs to be updated to > allow for it to thrown when not accessible from the previous lookup > class. Also VerifyAccess::isModuleAccessible shouldn't need to if the > package is exported unconditionally as it is covered by isExported(pn, > m1) && isExported(pn, m2). Good point.? Fixed. Webrev updated: ?? http://cr.openjdk.java.net/~mchung/jdk14/8173978/webrev.01/ Mandy From lance.andersen at oracle.com Tue Jul 2 17:22:15 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 2 Jul 2019 13:22:15 -0400 Subject: RFR(JDK 14/java.xml) 8223291: Whitespace is added to CDATA tags when using OutputKeys.INDENT to format XML In-Reply-To: <5D1B7D6F.3@oracle.com> References: <5D1A551E.1070600@oracle.com> <5D1B7D6F.3@oracle.com> Message-ID: <942D6625-4640-4CFC-BAB4-77A6F484736E@oracle.com> Looks OK to me Joe > On Jul 2, 2019, at 11:51 AM, Joe Wang wrote: > > Thanks Daniel. That test case is added. > > Best, > Joe > > On 7/2/19, 1:21 AM, Daniel Fuchs wrote: >> Hi Joe, >> >> I haven't spotted anything obviously wrong. >> >>> The content of "abcxyz" should be "abc & xyz", not " abc\n & \n xyz\n" as that before this fix. >> >> Maybe the test could have a test case for that specific example too? >> Just to make sure whitespaces in CDATA aren't eaten away? >> >> best regards, >> >> -- daniel >> >> >> On 01/07/2019 20:46, Joe Wang wrote: >>> Please review a fix to xml pretty print. This is a regression introduced during the JDK 9 development. CDATA is marked up to be interpreted literally as textual data, in other words, it's still character data. The processor therefore shall treat it as text data. The content of "abcxyz" should be "abc & xyz", not " abc\n & \n xyz\n" as that before this fix. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8223291 >>> webrev: http://cr.openjdk.java.net/~joehw/jdk14/8223291/webrev/ >>> >>> Thanks, >>> Joe >>> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From huizhe.wang at oracle.com Tue Jul 2 17:29:20 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 02 Jul 2019 10:29:20 -0700 Subject: RFR(JDK 14/java.xml) 8223291: Whitespace is added to CDATA tags when using OutputKeys.INDENT to format XML In-Reply-To: <942D6625-4640-4CFC-BAB4-77A6F484736E@oracle.com> References: <5D1A551E.1070600@oracle.com> <5D1B7D6F.3@oracle.com> <942D6625-4640-4CFC-BAB4-77A6F484736E@oracle.com> Message-ID: <5D1B9470.6040602@oracle.com> Thanks Lance! -Joe On 7/2/19, 10:22 AM, Lance Andersen wrote: > Looks OK to me Joe >> On Jul 2, 2019, at 11:51 AM, Joe Wang > > wrote: >> >> Thanks Daniel. That test case is added. >> >> Best, >> Joe >> >> On 7/2/19, 1:21 AM, Daniel Fuchs wrote: >>> Hi Joe, >>> >>> I haven't spotted anything obviously wrong. >>> >>>> The content of "abcxyz" should be "abc & xyz", not " >>>> abc\n & \n xyz\n" as that before this fix. >>> >>> Maybe the test could have a test case for that specific example too? >>> Just to make sure whitespaces in CDATA aren't eaten away? >>> >>> best regards, >>> >>> -- daniel >>> >>> >>> On 01/07/2019 20:46, Joe Wang wrote: >>>> Please review a fix to xml pretty print. This is a regression >>>> introduced during the JDK 9 development. CDATA is marked up to be >>>> interpreted literally as textual data, in other words, it's still >>>> character data. The processor therefore shall treat it as text >>>> data. The content of "abcxyz" should be "abc & xyz", >>>> not " abc\n & \n xyz\n" as that before this fix. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8223291 >>>> webrev: http://cr.openjdk.java.net/~joehw/jdk14/8223291/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 Alan.Bateman at oracle.com Tue Jul 2 17:39:05 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 2 Jul 2019 18:39:05 +0100 Subject: Review Request: JDK-8173978: Lookup.in should allow teleporting from a lookup class in a named module without dropping all access In-Reply-To: <76395107-8da7-4bdf-66ec-b5f9f1459284@oracle.com> References: <77478136-29fd-45f9-d122-6826099dfe84@oracle.com> <847246aa-fa7a-5781-a973-5eb021a294e3@oracle.com> <76395107-8da7-4bdf-66ec-b5f9f1459284@oracle.com> Message-ID: <660b8f8f-a8b0-659f-6131-58b740bc9938@oracle.com> On 02/07/2019 18:20, Mandy Chung wrote: > : > >> I've taken several passes over the changes and I don't see anything >> obviously wrong. One minor nit is that the @throws >> IllegalAccessException in accessClass(Class) needs to be updated to >> allow for it to thrown when not accessible from the previous lookup >> class. Also VerifyAccess::isModuleAccessible shouldn't need to if the >> package is exported unconditionally as it is covered by >> isExported(pn, m1) && isExported(pn, m2). > > Good point.? Fixed. > > Webrev updated: > ?? http://cr.openjdk.java.net/~mchung/jdk14/8173978/webrev.01/ > The updated @throws IAE in accessClass and the updated VerifyAccess::isModuleAccessible looks good. -Alan. From mandy.chung at oracle.com Tue Jul 2 17:48:18 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 2 Jul 2019 10:48:18 -0700 Subject: Slow performance of StackWalker.getCallerClass() vs Reflection.getCallerClass() In-Reply-To: References: <1082795724.1561886.1562071799378.JavaMail.zimbra@u-pem.fr> Message-ID: MethodHandles::lookup is optimized (@ForceInline) and so it may not represent apple-to-apple comparison.StackWalker::getCallerClass does have overhead compared to Reflection::getCallerClass and need to get the microbenchmark in the jdk repo and rerun the numbers [1]. I'm not getting how getCallerClass is used and related to access check. Can you elaborate? Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8221623 On 7/2/19 6:07 AM, Kasper Nielsen wrote: > Hi Remi, > > Yes, setting up a StackWalker is more or less free. It is just > wrapping a set of options. > > public class StackWalkerPerf { > > static final StackWalker sw = > StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE); > > @Benchmark > public StackWalker stackWalkerSetup() { > return StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE); > } > > @Benchmark > public Class stackWalkerCallerClass() { > return sw.getCallerClass(); > } > > @Benchmark > public Lookup reflectionCallerClass() { > return MethodHandles.lookup(); > } > } > > Benchmark Mode Cnt Score Error Units > StackWalkerPerf.stackWalkerSetup avgt 10 11.958 ? 0.353 ns/op > StackWalkerPerf.reflectionCallerClass avgt 10 8.511 ? 0.415 ns/op > StackWalkerPerf.stackWalkerCallerClass avgt 10 1269.825 ? 66.471 ns/op > > I'm using MethodHandles.lookup() in this test because it is cheapest > way to invoke Reflection.getCallerClass() without any tricks. > So real performance is likely better. > > /Kasper > > On Tue, 2 Jul 2019 at 13:53, Remi Forax wrote: >> Hi Kasper, >> did you store the StackWalker instance in a static final field ? >> >> R?mi >> >> ----- Mail original ----- >>> De: "Kasper Nielsen" >>> ?: "core-libs-dev" >>> Envoy?: Mardi 2 Juillet 2019 11:09:11 >>> Objet: Slow performance of StackWalker.getCallerClass() vs Reflection.getCallerClass() >>> Hi, >>> >>> Are there any security reasons for why StackWalker.getCallerClass() >>> cannot be made as performant as Reflection.getCallerClass()? >>> StackWalker.getCallerClass() is at least 100 times slower then >>> Reflection.getCallerClass() (~1000 ns/op vs ~10 ns/op). >>> >>> I'm trying to retrofit some existing APIs where I cannot take a Lookup >>> object to do some access control checks. >>> But the performance of StackWalker.getCallerClass() is making it impossible. >>> >>> Best >>> Kasper From ralph.goers at dslextreme.com Tue Jul 2 21:49:18 2019 From: ralph.goers at dslextreme.com (Ralph Goers) Date: Tue, 2 Jul 2019 14:49:18 -0700 Subject: Slow performance of StackWalker.getCallerClass() vs Reflection.getCallerClass() In-Reply-To: References: <1082795724.1561886.1562071799378.JavaMail.zimbra@u-pem.fr> Message-ID: The timing of this question is perfect. I have been doing some testing over the last week to address https://issues.apache.org/jira/browse/LOG4J2-2644 and found some interesting things - although they are related to the walk() method, not getCallerClass(). 1. Using skip(n) to find a frame a couple frames up is pretty fast but isn?t too much faster than finding the same element using new Throwable().getStackTrace() was in Java 8. 2. The cost of walking the stack becomes much more costly as the number of elements needing to be walked increases. 3. The most shocking to me was that the fastest way to traverse a stack trace is to use a Function that immediately converts the Stream to an array and then use an old style for loop to traverse it. However, doing this is incredibly awkward because StackWalker only supports streams so there is no good way to pass the value being searched for into the Function. I had to resort to storing it in a ThreadLocal. Having a toArray() method on StackWalker would be a lot nicer, especially if I could limit the number of frames retrieved. I should note that java.util.logging.LogRecord uses a Filter to walk the stack which is faster than the stream methods I was originally using, but is much slower than what I ended up with. As for the issue mentioned here, I believe I reported that getCallerClass was much slower than the Reflection class in Java 9 and opened a bug here. As I recall that was addressed and I believe I verified that fix but it probably wouldn?t hurt for me to do it again. Ralph > On Jul 2, 2019, at 10:48 AM, Mandy Chung wrote: > > MethodHandles::lookup is optimized (@ForceInline) and so it may not > represent apple-to-apple comparison.StackWalker::getCallerClass > does have overhead compared to Reflection::getCallerClass and > need to get the microbenchmark in the jdk repo and rerun the numbers [1]. > > I'm not getting how getCallerClass is used and related to access check. > Can you elaborate? > > Mandy > [1] https://bugs.openjdk.java.net/browse/JDK-8221623 > > > On 7/2/19 6:07 AM, Kasper Nielsen wrote: >> Hi Remi, >> >> Yes, setting up a StackWalker is more or less free. It is just >> wrapping a set of options. >> >> public class StackWalkerPerf { >> >> static final StackWalker sw = >> StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE); >> >> @Benchmark >> public StackWalker stackWalkerSetup() { >> return StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE); >> } >> >> @Benchmark >> public Class stackWalkerCallerClass() { >> return sw.getCallerClass(); >> } >> >> @Benchmark >> public Lookup reflectionCallerClass() { >> return MethodHandles.lookup(); >> } >> } >> >> Benchmark Mode Cnt Score Error Units >> StackWalkerPerf.stackWalkerSetup avgt 10 11.958 ? 0.353 ns/op >> StackWalkerPerf.reflectionCallerClass avgt 10 8.511 ? 0.415 ns/op >> StackWalkerPerf.stackWalkerCallerClass avgt 10 1269.825 ? 66.471 ns/op >> >> I'm using MethodHandles.lookup() in this test because it is cheapest >> way to invoke Reflection.getCallerClass() without any tricks. >> So real performance is likely better. >> >> /Kasper >> >> On Tue, 2 Jul 2019 at 13:53, Remi Forax wrote: >>> Hi Kasper, >>> did you store the StackWalker instance in a static final field ? >>> >>> R?mi >>> >>> ----- Mail original ----- >>>> De: "Kasper Nielsen" >>>> ?: "core-libs-dev" >>>> Envoy?: Mardi 2 Juillet 2019 11:09:11 >>>> Objet: Slow performance of StackWalker.getCallerClass() vs Reflection.getCallerClass() >>>> Hi, >>>> >>>> Are there any security reasons for why StackWalker.getCallerClass() >>>> cannot be made as performant as Reflection.getCallerClass()? >>>> StackWalker.getCallerClass() is at least 100 times slower then >>>> Reflection.getCallerClass() (~1000 ns/op vs ~10 ns/op). >>>> >>>> I'm trying to retrofit some existing APIs where I cannot take a Lookup >>>> object to do some access control checks. >>>> But the performance of StackWalker.getCallerClass() is making it impossible. >>>> >>>> Best >>>> Kasper > > From mandy.chung at oracle.com Tue Jul 2 22:20:39 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 2 Jul 2019 15:20:39 -0700 Subject: 8226863: [aix] jdk/java/lang/reflect/exeCallerAccessTest cannot launch on primordial thread In-Reply-To: References: Message-ID: <9e935e78-a7ec-3627-1637-f3c43e6ed74c@oracle.com> Hi Thomas, This is AIX-only.??? It would be cleaner to move AIX-specific launcher to a new file like main_aix.c.? Have you considered that? I don't know how to specify additional .c file in make/test/JtregNativeJdk.gmk? though. Mandy On 7/1/19 10:23 PM, Thomas St?fe wrote: > Second, corrected Webrev: > > http://cr.openjdk.java.net/~stuefe/webrevs/execalleraccesstest-cannot-launch-on-primordial-thread/webrev.01/webrev/ > > Run through SAP nightlies on all platforms. > > Cheers, Thomas > > > On Thu, Jun 27, 2019 at 9:02 AM Thomas St?fe > wrote: > >> Hi all, >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8226863 >> webrev: >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8226863--jdk-java-lang-reflect-execalleraccesstest-cannot-launch-on-primordial-thread/webrev.00/webrev/ >> >> we have this annoying issue on AIX that the libjvm cannot be invoked on a >> primordial thread. Therefore we need to change launchers which create the >> VM to spawn own threads (we only do this where it is worth the effort - >> this, admittedly, is a corner case, we could alternatively just disable the >> test on AIX). >> >> This is annoying and vaguely embarrassing :-/ Maybe IBM will step in some >> time and help us solve the underlying issues which have to do with the >> inability to create guard pages on the primordial thread stack (among other >> things IIRC). >> >> Thanks for reviewing, >> >> Thomas >> >> >> From david.holmes at oracle.com Tue Jul 2 22:44:46 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 3 Jul 2019 08:44:46 +1000 Subject: (13) RFR (S): 8227055: Minor edits to launcher help text Message-ID: <7311d01f-e886-0bff-5e4d-ca70ca1252d5@oracle.com> webrev: http://cr.openjdk.java.net/~dholmes/8227055/webrev/ bug: https://bugs.openjdk.java.net/browse/JDK-8227055 The launcher help text needs some minor updates/corrections - -verbose needs more info - -Xdebug needs to say it does nothing - -Xloggc is deprecated and replaced by -Xlog:gc:filename - -Xshare:on needs warning about use Reference to Mac OS X should be macOS. The --disable- at files is documented as both a standard and extra option. This aligns the help info with the Java manpage info. Thanks, David From mandy.chung at oracle.com Tue Jul 2 22:57:01 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 2 Jul 2019 15:57:01 -0700 Subject: (13) RFR (S): 8227055: Minor edits to launcher help text In-Reply-To: <7311d01f-e886-0bff-5e4d-ca70ca1252d5@oracle.com> References: <7311d01f-e886-0bff-5e4d-ca70ca1252d5@oracle.com> Message-ID: On 7/2/19 3:44 PM, David Holmes wrote: > webrev: http://cr.openjdk.java.net/~dholmes/8227055/webrev/ > bug: https://bugs.openjdk.java.net/browse/JDK-8227055 > > The launcher help text needs some minor updates/corrections > - -verbose needs more info > - -Xdebug needs to say it does nothing Should this be removed instead? > - -Xloggc is deprecated and replaced by -Xlog:gc:filename I think it can just list -Xlog:gc (the replacement) and no need to mention the deprecated option in the launcher help message. > - -Xshare:on needs warning about use > > Reference to Mac OS X should be macOS. > > The --disable- at files is documented as both a standard and extra option. > I think this is intended to be an extra option. Otherwise, looks okay. Mandy > This aligns the help info with the Java manpage info. > > Thanks, > David From mandy.chung at oracle.com Tue Jul 2 23:12:53 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 2 Jul 2019 16:12:53 -0700 Subject: Slow performance of StackWalker.getCallerClass() vs Reflection.getCallerClass() In-Reply-To: References: <1082795724.1561886.1562071799378.JavaMail.zimbra@u-pem.fr> Message-ID: <886e2549-ac78-2f6e-0b71-cd29c837ec23@oracle.com> Hi Ralph, Thanks for this info. Quick comments: LogRecord does not get the line number nor StackTraceElement.? There is cost to construct the string-based StackTraceElement or get the line number mapped from BCI.?? And it is orthogonal to StackWalker::getCallerClass that is only interested in the Class object. You may also be interesting in https://bugs.openjdk.java.net/browse/JDK-8189752 to take a snapshot of a stack trace (possibly the top N frames). Mandy On 7/2/19 2:49 PM, Ralph Goers wrote: > The timing of this question is perfect. I have been doing some testing > over the last week to address > https://issues.apache.org/jira/browse/LOG4J2-2644?and found some > interesting things - although they are related to the walk() method, > not getCallerClass(). > 1. Using skip(n) to find a frame a couple frames up is pretty fast but > isn?t too much faster than finding the same element using new > Throwable().getStackTrace() was in Java 8. > 2. The cost of walking the stack becomes much more costly as the > number of elements needing to be walked increases. > 3. The most shocking to me was that the fastest way to traverse a > stack trace is to use a Function that immediately converts the Stream > to an array and then use an old style for loop to traverse it. > However, doing this is incredibly awkward because StackWalker only > supports streams so there is no good way to pass the value being > searched for into the Function. I had to resort to storing it in a > ThreadLocal. Having a toArray() method on StackWalker would be a lot > nicer, especially if I could limit the number of frames retrieved. I > should note that java.util.logging.LogRecord uses a Filter to walk the > stack which is faster than the stream methods I was originally using, > but is much slower than what I ended up with. > > As for the issue mentioned here, I believe I reported that > getCallerClass was much slower than the Reflection class in Java 9 and > opened a bug here. As I recall that was addressed and I believe I > verified that fix but it probably wouldn?t hurt for me to do it again. > > Ralph > >> On Jul 2, 2019, at 10:48 AM, Mandy Chung > > wrote: >> >> MethodHandles::lookup is optimized (@ForceInline) and so it may not >> represent apple-to-apple comparison.StackWalker::getCallerClass >> does have overhead compared to Reflection::getCallerClass and >> need to get the microbenchmark in the jdk repo and rerun the numbers [1]. >> >> I'm not getting how getCallerClass is used and related to access check. >> Can you elaborate? >> >> Mandy >> [1] https://bugs.openjdk.java.net/browse/JDK-8221623 >> >> >> On 7/2/19 6:07 AM, Kasper Nielsen wrote: >>> Hi Remi, >>> >>> Yes, setting up a StackWalker is more or less free. It is just >>> wrapping a set of options. >>> >>> public class StackWalkerPerf { >>> >>> ????static final StackWalker sw = >>> StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE); >>> >>> ????@Benchmark >>> ????public StackWalker stackWalkerSetup() { >>> ????????return StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE); >>> ????} >>> >>> ????@Benchmark >>> ????public Class stackWalkerCallerClass() { >>> ????????return sw.getCallerClass(); >>> ????} >>> >>> ????@Benchmark >>> ????public Lookup reflectionCallerClass() { >>> ????????return MethodHandles.lookup(); >>> ????} >>> } >>> >>> Benchmark ??????????????????????????????Mode ?Cnt ????Score ???Error >>> ?Units >>> StackWalkerPerf.stackWalkerSetup ???????avgt ??10 ???11.958 ? ?0.353 >>> ?ns/op >>> StackWalkerPerf.reflectionCallerClass ??avgt ??10 ????8.511 ? ?0.415 >>> ?ns/op >>> StackWalkerPerf.stackWalkerCallerClass ?avgt ??10 ?1269.825 ? 66.471 >>> ?ns/op >>> >>> I'm using MethodHandles.lookup() in this test because it is cheapest >>> way to invoke Reflection.getCallerClass() without any tricks. >>> So real performance is likely better. >>> >>> /Kasper >>> >>> On Tue, 2 Jul 2019 at 13:53, Remi Forax >> > wrote: >>>> Hi Kasper, >>>> did you store the StackWalker instance in a static final field ? >>>> >>>> R?mi >>>> >>>> ----- Mail original ----- >>>>> De: "Kasper Nielsen" > >>>>> ?: "core-libs-dev" >>>> > >>>>> Envoy?: Mardi 2 Juillet 2019 11:09:11 >>>>> Objet: Slow performance of StackWalker.getCallerClass() vs >>>>> Reflection.getCallerClass() >>>>> Hi, >>>>> >>>>> Are there any security reasons for why StackWalker.getCallerClass() >>>>> cannot be made as performant as Reflection.getCallerClass()? >>>>> StackWalker.getCallerClass() is at least 100 times slower then >>>>> Reflection.getCallerClass() (~1000 ns/op vs ~10 ns/op). >>>>> >>>>> I'm trying to retrofit some existing APIs where I cannot take a Lookup >>>>> object to do some access control checks. >>>>> But the performance of StackWalker.getCallerClass() is making it >>>>> impossible. >>>>> >>>>> Best >>>>> ?Kasper >> >> > From jhg023 at bucknell.edu Tue Jul 2 23:55:52 2019 From: jhg023 at bucknell.edu (Jacob Glickman) Date: Tue, 2 Jul 2019 19:55:52 -0400 Subject: Fwd: Mechanism to maintain backwards compatibility when moving classes to different packages In-Reply-To: References: Message-ID: Friendly reminder :) ---------- Forwarded message --------- From: Jacob Glickman Date: Sat, Jun 22, 2019 at 4:42 PM Subject: Mechanism to maintain backwards compatibility when moving classes to different packages To: Yesterday, Mark Reinhold introduced the idea of a java.util.random subpackage[1]. Obviously, moving java.util.Random into that subpackage is not currently an option, as that would break backwards compatibility. Assuming the subpackage is created, it would make sense to ultimately move java.util.Random into it. For that reason, I propose a new language feature that could make this possible: package java.util.random previously java.util; The syntax isn't important at the moment, but this mechanism should allow for users to run previously-compiled code with newer versions of Java, even if their code points to a class that has since been moved to a different package. To eliminate potential bugs, users compiling new code shouldn't be allowed to reference java.util.Random, even if java.util.random.Random states that it previously resided in java.util. I'm curious what you all would think of this, as it is not just applicable to this single example. There have been plenty of times that I've realized that my packages were named badly, but I'm forced to stick with that naming (unless I want my users to have to modify their code). Thanks, Jacob Glickman [1]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-June/060995.html From swpalmer at gmail.com Wed Jul 3 00:10:45 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 2 Jul 2019 20:10:45 -0400 Subject: Mechanism to maintain backwards compatibility when moving classes to different packages In-Reply-To: References: Message-ID: <6343298E-6EE8-41C6-9D47-047B3E5B3B17@gmail.com> Not worth it. How will package level access be affected? How can this be exploited? How will it affect security and signing when things from the same package aren?t *really* from the same package? Now that the recommendation is to bundle a JRE with your application, that kind of backwards compatibility is becoming less critical. If necessary, deprecate java.util.Random. Make an interface for RNGs to implement and go with factories and a service provider pattern. Sometime down the line retire java.util.Random. Scott > On Jul 2, 2019, at 7:55 PM, Jacob Glickman wrote: > > Friendly reminder :) > ---------- Forwarded message --------- > From: Jacob Glickman > Date: Sat, Jun 22, 2019 at 4:42 PM > Subject: Mechanism to maintain backwards compatibility when moving classes > to different packages > To: > > > Yesterday, Mark Reinhold introduced the idea of a java.util.random > subpackage[1]. Obviously, moving java.util.Random into that subpackage is > not currently an option, as that would break backwards compatibility. > Assuming the subpackage is created, it would make sense to ultimately move > java.util.Random into it. For that reason, I propose a new language feature > that could make this possible: > > package java.util.random previously java.util; > > The syntax isn't important at the moment, but this mechanism should allow > for users to run previously-compiled code with newer versions of Java, even > if their code points to a class that has since been moved to a different > package. > > To eliminate potential bugs, users compiling new code shouldn't be allowed > to reference java.util.Random, even if java.util.random.Random states that > it previously resided in java.util. > > I'm curious what you all would think of this, as it is not just applicable > to this single example. There have been plenty of times that I've realized > that my packages were named badly, but I'm forced to stick with that naming > (unless I want my users to have to modify their code). > > Thanks, > > Jacob Glickman > > [1]: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-June/060995.html From ralph.goers at dslextreme.com Wed Jul 3 01:57:42 2019 From: ralph.goers at dslextreme.com (Ralph Goers) Date: Tue, 2 Jul 2019 18:57:42 -0700 Subject: Slow performance of StackWalker.getCallerClass() vs Reflection.getCallerClass() In-Reply-To: <886e2549-ac78-2f6e-0b71-cd29c837ec23@oracle.com> References: <1082795724.1561886.1562071799378.JavaMail.zimbra@u-pem.fr> <886e2549-ac78-2f6e-0b71-cd29c837ec23@oracle.com> Message-ID: Thanks Mandy, It seems I commented on the thread mentioned in the issue you linked to. Unfortunately, it doesn?t look like any work has been done on the issue.in the last 18 months. Yes, LogRecord doesn?t get the StackTraceElement. We only get it for the one stack entry we are interested in and we only do that because Log4j is still compatible with Java 7 and creating our own class would be too disruptive. Still, the cost seems to be in locating the correct frame, not creating the StackTraceElement. I don?t have an account in the bug tracking system or I would comment on the bug there instead of here. But it seems like adding toArray() and toArray(int frames) wouldn?t be very hard and has to perform better than Stream.toArray. While it was a nice idea to use Streams to deal with the stack trace, in practical terms almost everything that needs to do it is going to be extremely performance sensitive and is going to want to traverse it as fast as possible. Ralph > On Jul 2, 2019, at 4:12 PM, Mandy Chung wrote: > > Hi Ralph, > > Thanks for this info. > > Quick comments: LogRecord does not get the line number nor StackTraceElement. There is cost to construct the string-based StackTraceElement or get the line number mapped from BCI. And it is orthogonal to StackWalker::getCallerClass that is only interested in the Class object. > > You may also be interesting in https://bugs.openjdk.java.net/browse/JDK-8189752 to take a snapshot of a stack trace (possibly the top N frames). > > Mandy > > On 7/2/19 2:49 PM, Ralph Goers wrote: >> The timing of this question is perfect. I have been doing some testing over the last week to address https://issues.apache.org/jira/browse/LOG4J2-2644 and found some interesting things - although they are related to the walk() method, not getCallerClass(). >> 1. Using skip(n) to find a frame a couple frames up is pretty fast but isn?t too much faster than finding the same element using new Throwable().getStackTrace() was in Java 8. >> 2. The cost of walking the stack becomes much more costly as the number of elements needing to be walked increases. >> 3. The most shocking to me was that the fastest way to traverse a stack trace is to use a Function that immediately converts the Stream to an array and then use an old style for loop to traverse it. However, doing this is incredibly awkward because StackWalker only supports streams so there is no good way to pass the value being searched for into the Function. I had to resort to storing it in a ThreadLocal. Having a toArray() method on StackWalker would be a lot nicer, especially if I could limit the number of frames retrieved. I should note that java.util.logging.LogRecord uses a Filter to walk the stack which is faster than the stream methods I was originally using, but is much slower than what I ended up with. >> >> As for the issue mentioned here, I believe I reported that getCallerClass was much slower than the Reflection class in Java 9 and opened a bug here. As I recall that was addressed and I believe I verified that fix but it probably wouldn?t hurt for me to do it again. >> >> Ralph >> >>> On Jul 2, 2019, at 10:48 AM, Mandy Chung > wrote: >>> >>> MethodHandles::lookup is optimized (@ForceInline) and so it may not >>> represent apple-to-apple comparison.StackWalker::getCallerClass >>> does have overhead compared to Reflection::getCallerClass and >>> need to get the microbenchmark in the jdk repo and rerun the numbers [1]. >>> >>> I'm not getting how getCallerClass is used and related to access check. >>> Can you elaborate? >>> >>> Mandy >>> [1] https://bugs.openjdk.java.net/browse/JDK-8221623 >>> >>> >>> On 7/2/19 6:07 AM, Kasper Nielsen wrote: >>>> Hi Remi, >>>> >>>> Yes, setting up a StackWalker is more or less free. It is just >>>> wrapping a set of options. >>>> >>>> public class StackWalkerPerf { >>>> >>>> static final StackWalker sw = >>>> StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE); >>>> >>>> @Benchmark >>>> public StackWalker stackWalkerSetup() { >>>> return StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE); >>>> } >>>> >>>> @Benchmark >>>> public Class stackWalkerCallerClass() { >>>> return sw.getCallerClass(); >>>> } >>>> >>>> @Benchmark >>>> public Lookup reflectionCallerClass() { >>>> return MethodHandles.lookup(); >>>> } >>>> } >>>> >>>> Benchmark Mode Cnt Score Error Units >>>> StackWalkerPerf.stackWalkerSetup avgt 10 11.958 ? 0.353 ns/op >>>> StackWalkerPerf.reflectionCallerClass avgt 10 8.511 ? 0.415 ns/op >>>> StackWalkerPerf.stackWalkerCallerClass avgt 10 1269.825 ? 66.471 ns/op >>>> >>>> I'm using MethodHandles.lookup() in this test because it is cheapest >>>> way to invoke Reflection.getCallerClass() without any tricks. >>>> So real performance is likely better. >>>> >>>> /Kasper >>>> >>>> On Tue, 2 Jul 2019 at 13:53, Remi Forax > wrote: >>>>> Hi Kasper, >>>>> did you store the StackWalker instance in a static final field ? >>>>> >>>>> R?mi >>>>> >>>>> ----- Mail original ----- >>>>>> De: "Kasper Nielsen" > >>>>>> ?: "core-libs-dev" > >>>>>> Envoy?: Mardi 2 Juillet 2019 11:09:11 >>>>>> Objet: Slow performance of StackWalker.getCallerClass() vs Reflection.getCallerClass() >>>>>> Hi, >>>>>> >>>>>> Are there any security reasons for why StackWalker.getCallerClass() >>>>>> cannot be made as performant as Reflection.getCallerClass()? >>>>>> StackWalker.getCallerClass() is at least 100 times slower then >>>>>> Reflection.getCallerClass() (~1000 ns/op vs ~10 ns/op). >>>>>> >>>>>> I'm trying to retrofit some existing APIs where I cannot take a Lookup >>>>>> object to do some access control checks. >>>>>> But the performance of StackWalker.getCallerClass() is making it impossible. >>>>>> >>>>>> Best >>>>>> Kasper >>> >>> >> > From stuart.marks at oracle.com Wed Jul 3 03:27:05 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 2 Jul 2019 20:27:05 -0700 Subject: Inputs on patch for JDK-8225763? Inflater and Deflater should implement AutoCloseable In-Reply-To: <5b1f547f-84da-c8c2-c071-278830e125a2@gmail.com> References: <44582692-a30b-0d54-e550-6277cab95969@gmail.com> <152766d5-72b0-9847-cde2-c89f1d0229d8@gmail.com> <5b1f547f-84da-c8c2-c071-278830e125a2@gmail.com> Message-ID: <0d234157-869f-9c95-b3dc-587f989b1551@oracle.com> Hi Jaikiran, OK, good analysis. Rather a lot of issues for what seems like a simple patch, eh? - Idempotency Yes, it looks to me like Inflater.end() and Deflater.end() implementations are idempotent. As you point out, overrides by subclasses might not be. We should be clear when we're talking about the specific implementatations of the end() methods in the Deflater and Inflater classes, or whether we're talking about the contracts defined by these method specifications on these classes and subtypes. The behavior of an implementation in a class can be specified with @implSpec without imposing this on the contract of subclasses. This is useful for subclasses that need to know the exact behavior of calling super.end(), and also for callers who know they have an instance of a particular class and not a subclass. The upshot is that while we might not have the end() method's contract specify idempotency, we can certainly say so in an @implSpec, if doing this will help. I'm not sure we'll actually need it in this case, but let's keep it in mind. - Subclasses I don't think there are any subclasses in the JDK, and I did some searching and I didn't find any subclasses "in the wild" either. I did find a few uses of these classes though. If these classes are rarely subclassed, we might be able to get away with changing the contract, though this does entail some risk. If we need to modify the subclasses used in tests, that's fair game though. - Relationship between end() and close() I think close() should have more-or-less the same semantics as end(), namely, pretty much the way end() is specified now regarding releasing resources. But it should be allowable to call both in either order. try (var inf = new Inflater()) { ... # explicitly call end() inf.end(); } I think this should allowed, but it shouldn't be required. The application can call either close() or end() and this will have the effect of releasing the native resources. A key question is whether close() should be specified to call end() -- which is subject to being overridden by suclasses -- or whether close() is defined to do the same thing as the end() implementation in this class does. This can be implemented by taking the body of the current end() method and refactoring it into an internal method and then having both close() and end() call that internal method. If close() calls end() then AC+TWR might call close() twice, and therefore call end() twice, which might be a problem for subclasses. So to be really conservative we might want to do the internal-method refactoring to avoid this problem. On the other hand, suppose a subclass has extra resources it frees in its end() method, which then calls super.end(). Even though this class would inherit AC, using it in TWR would be a *bug* because close() would call the internal method to free the superclass resources, but this would leak the subclass resources. That sounds like a mistake to perpetuate in the API. It's possible for a subclass to override end() in such a way that's not idempotent, but I think this is unlikely. I'm leaning toward risking the small possibility of incompatibility in declaring end() idempotent, allowing close() simply to call end(). This makes TWR more useful in the long run, which seems like a better position to be in. Of course, if somebody turns up evidence that this would break a bunch of stuff, we should reconsider. (This might be moot anyway. The condition where TWR closes a resource multiple times occurs in cases where closing a wrapper closes the wrapped resource, and both are TWR resource variables. But in my earlier example try (var inf = new Inflater(); var iis = new InflaterInputStream(inputStream, inf)) { ... } and in fact all of {Inflater,Deflater}{Input,Output}Stream don't close the passed-in Deflater/Inflater, so multiple close() calls won't occur.) - Deprecation of end() I don't think deprecation of end() is useful. It'll just cause noise for people. Uses such as var deflater = new Deflater(); try { ... } finally { deflater.end(); } are valid and correct and needn't be changed (though using TWR is preferable, this is more of a style issue). - Undefined behavior after close()/end() OK, I'll admit this is possibly out of scope, but the line in the specs about "once end() is called, the behavior is undefined" rubs me the wrong way. Right now, most operations seem to call ensureOpen(), which throws NPE if the object has been closed. But "undefined" allows anything to happen, including filling the output buffer with garbage. That seems wrong. We might not want to specify what exception is thrown, but we might want to specify that *AN* exception is thrown -- which must be a RuntimeException, since most methods don't declare any checked exceptions. In any case, the clause would have to be updated to say something like "Once this Deflater (Inflater) is closed, any subsequent operations will ." ** If you think the issues are settled enough, maybe it's time for you to take a stab at a patch. Up to you how to proceed with the "undefined" issue. If it's simple, great, I'd like to see it happen. But if it leads you off into the weeds, then feel free to drop it. Note: US holiday weekend coming up; replies might take several days. s'marks On 6/29/19 4:16 AM, Jaikiran Pai wrote: > > On 29/06/19 4:31 PM, Jaikiran Pai wrote: >> Hello Stuart, >> >> Thank you for the detailed response. Comments inline. >> >> On 28/06/19 2:48 AM, Stuart Marks wrote: >>> On 6/26/19 9:28 PM, Jaikiran Pai wrote: >>>> I am looking to contribute a patch for the enhancement noted in >>>> https://bugs.openjdk.java.net/browse/JDK-8225763. The change itself >>>> looks relatively straightforward to me and here's what I plan to do: >>>> >>>> 1. Have both java.util.zip.Inflater and java.util.zip.Deflater start >>>> implementing the AutoCloseable interface >>>> >>>> 2. Have the close() method call the end() method >>>> >>>> 3. Add javadoc to the close() implementation to mention that the end() >>>> method gets called >>>> >>>> 4. Add test(s) to verify that the close indeed actually "ends" the >>>> inflater/deflater >>>> >>>> 5. This is more of a question - do we have to update the class level >>>> javadoc of both these classes to make a mention that these classes have >>>> started implementing the AutoCloseable starting version 14 (or whichever >>>> version this change makes into) of Java? >>>> >>>> Any other inputs/suggestions on what else might be needed in this >>>> change? >>> Hi Jaikiran, >>> >>> Thanks for picking this up. There are some small wrinkles with this, >>> but I hope nothing that will prevent it from happening. >>> >>> >>> 2) Alan already mentioned this, but we need to consider the issue of >>> idempotent close() or end() carefully. It's not strictly required, but >>> it would be nice. I had taken a quick look at end() and I *thought* it >>> was idempotent already, but a more careful analysis needs to be done. >> I did some checks in the current JDK code. From what I see, the Inflater >> and Deflater do not have any subclasses within the JDK itself. > > To be clear - I couldn't find any subclasses in the main source code of > JDK. There are a couple of subclasses in the tests > (ConstructInflaterOutput.java and ConstructDeflaterInput.java), but > those don't do much outside of the context of testing. > > -Jaikiran > > From kasperni at gmail.com Wed Jul 3 04:54:46 2019 From: kasperni at gmail.com (Kasper Nielsen) Date: Wed, 3 Jul 2019 05:54:46 +0100 Subject: Slow performance of StackWalker.getCallerClass() vs Reflection.getCallerClass() In-Reply-To: References: <1082795724.1561886.1562071799378.JavaMail.zimbra@u-pem.fr> Message-ID: On Tue, 2 Jul 2019 at 18:50, Mandy Chung wrote: > > I'm not getting how getCallerClass is used and related to access check. > Can you elaborate? Caller sensitive methods are viral, in the sense that if you invoke a caller sensitive method in the JDK, as a library on behalf of a client (without having a lookup object). You need to perform the same access checks as the JDK does. That is, checking that the client that calls you - the library - has the right access rights. The caller sensitive methods in the JDK cannot do this, because there is no way for them to see that the library is merely a proxy acting on behalf of a client. Consider a very simple serialization library with one method String serializeToString(Object o) // prints out the value of every field with an implementation in a module called SER. And two modules M1, M2 that uses SER (For example, via a ServiceLoader). Both M1 and M2 are open to SER in order for the serializer to serialize the objects in each of the two modules. However, M1 and M2 are not open towards each other. So it is not the intention that, for example, some code from M1 can call it with objects from M2 and have them serialized or vice versa. However, this is entire possible unless serializeToString() performs access checks on the caller. All M1 has to do is get a hold of an object from M2 and then call serializeToString() with it. There is no way the jdk can check this, it just sees an object from M2 which is open to SER. It has no idea it is actually M1 trying to serialize it. So the only way for this to work as intended is for serializeToString to check that the caller matches the object. And unless you pass around Lookup objects the only way you can do it, is similar to how the jdk does it; by looking at the calling class. Reflection::getCallerClass is not available outside of the JDK, so StackWalker is the only way to do this. I've put up an example at https://github.com/kaspernielsen/modulestest. Calling M2Use.main will serialize an object from M1 even though it M1 is not open to M2. As noted in another thread this gets further complicated because all the access control code is buried in internal jdk classes. In this example you more or less have to reimplement AccessibleObject.checkCanSetAccessible yourself. In the end I don't think it is realistic to expect library developers to get this right. /Kasper From kasperni at gmail.com Wed Jul 3 05:22:47 2019 From: kasperni at gmail.com (Kasper Nielsen) Date: Wed, 3 Jul 2019 06:22:47 +0100 Subject: Slow performance of StackWalker.getCallerClass() vs Reflection.getCallerClass() In-Reply-To: References: <1082795724.1561886.1562071799378.JavaMail.zimbra@u-pem.fr> Message-ID: On Tue, 2 Jul 2019 at 22:49, Ralph Goers wrote: > > The timing of this question is perfect. I have been doing some testing over the last week to address https://issues.apache.org/jira/browse/LOG4J2-2644 and found some interesting things - although they are related to the walk() method, not getCallerClass(). Getting a single stack frame with the calling class + line number for logging is probably the most common use case for using a StackWalker. I think optimized versions of these two methods would be really useful and cover most of these usecases: Optional findFirstWithClassName(Predicate p) {...} Optional findFirstWithDeclaringClass(Predicate> p) {...} There is really no reason to create a StackFrame object for every frame. Only the final frame. Perhaps even skip returning a StackFrame but just returning a string with ClassName:Linenumber if there is significant overhead in creating the StackFrame. I use StackWalker as well for logging, and find that the 2-3 microseconds it typically takes to get the calling class + line number a bit steep in my performance budget. /Kasper From thomas.stuefe at gmail.com Wed Jul 3 05:30:18 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 3 Jul 2019 07:30:18 +0200 Subject: 8226863: [aix] jdk/java/lang/reflect/exeCallerAccessTest cannot launch on primordial thread In-Reply-To: <9e935e78-a7ec-3627-1637-f3c43e6ed74c@oracle.com> References: <9e935e78-a7ec-3627-1637-f3c43e6ed74c@oracle.com> Message-ID: Hi Mandy, On Wed, Jul 3, 2019, 00:20 Mandy Chung wrote: > Hi Thomas, > > This is AIX-only. It would be cleaner to move AIX-specific launcher > to a new file like main_aix.c. Have you considered that? > I rather not since this would unnecessarily increase complexity even further. However, if you really dislike the platform specific code, I would withdraw the patch and just disable the test on AIX. I was on the fence about that anyway. Cheers, Thomas > > I don't know how to specify additional .c file in > make/test/JtregNativeJdk.gmk though. > > Mandy > > > > On 7/1/19 10:23 PM, Thomas St?fe wrote: > > Second, corrected Webrev: > > > > > http://cr.openjdk.java.net/~stuefe/webrevs/execalleraccesstest-cannot-launch-on-primordial-thread/webrev.01/webrev/ > > > > Run through SAP nightlies on all platforms. > > > > Cheers, Thomas > > > > > > On Thu, Jun 27, 2019 at 9:02 AM Thomas St?fe > > wrote: > > > >> Hi all, > >> > >> Issue: > >> https://bugs.openjdk.java.net/browse/JDK-8226863 > >> webrev: > >> > >> > http://cr.openjdk.java.net/~stuefe/webrevs/8226863--jdk-java-lang-reflect-execalleraccesstest-cannot-launch-on-primordial-thread/webrev.00/webrev/ > >> > >> we have this annoying issue on AIX that the libjvm cannot be invoked on > a > >> primordial thread. Therefore we need to change launchers which create > the > >> VM to spawn own threads (we only do this where it is worth the effort - > >> this, admittedly, is a corner case, we could alternatively just disable > the > >> test on AIX). > >> > >> This is annoying and vaguely embarrassing :-/ Maybe IBM will step in > some > >> time and help us solve the underlying issues which have to do with the > >> inability to create guard pages on the primordial thread stack (among > other > >> things IIRC). > >> > >> Thanks for reviewing, > >> > >> Thomas > >> > >> > >> > > From r.lichtenberger at gmail.com Wed Jul 3 06:08:22 2019 From: r.lichtenberger at gmail.com (Robert Lichtenberger) Date: Wed, 3 Jul 2019 08:08:22 +0200 Subject: JPackage application image file system layout In-Reply-To: <646068FF-040B-4B97-B494-A8615997E951@gmail.com> References: <646068FF-040B-4B97-B494-A8615997E951@gmail.com> Message-ID: I just noticed that my last reply was addressed to Scott Palmer only, so I "repost" my latest thougths now: Am 01.07.19 um 16:50 schrieb Scott Palmer: >> On Jul 1, 2019, at 2:47 AM, Robert Lichtenberger wrote: >> >> While trying to update our application to the (ea-version of) jpackager I >> noticed that the executable files are now in a bin/ subdirectory, which >> will make the application update from javapackager a real pain. >> >> For Linux this can be argumented with the Filesystem Hierarchy Standard but >> under Windows it is not common or standard to do so. The .exe file for an >> application is expected to live in the base installation directory. > It can also be argued that on Windows it is more common to launch the application from a shortcut in the Start menu, on the Desktop, or in the launch bar. > I get that this is a change from the previous behaviour so some adjustments need to be made, but how bad is it really? For me, right now, it is a showstopper. I have to update my application silently, in-place. If jpackage isn't adapted I'll have to resort to crude hacks like a "trampoline" .exe - File which will call bin/.exe when it's called and/or adapting existing .lnk - Files on the Windows machine (which will probably look very suspicious to anti-malware solutions ...). > The JDK has always had a bin directory and many other applications follow this pattern on Windows as well. Usually these are applications ported from Linux/Unix. But I admit there's no real standard or de-facto-standard about it. It's just the fact that javapackager used to work this way and now jpackage works that way, which makes it difficult in some situations. I've digged into the jpackage source code yesterday and was able to adapt LinuxAppImageBuilder.java and LinuxPlatform.cpp so that they would no longer use the bin/ subdirectory and from a cursory look it seems this could be done for Windows as well. Of course this would have to be tested and checked much more. To me it looks like there are three possible solutions: a) Everything stays as it is now. Things will remain difficult for me (and possibly for other people) b) We change Windows so as to not use the bin/ subdirectory. c) We add another config-option that will control whether or not to use the bin/ subdirectory I would be willing to invest time in a patch for? b) or c) but only if someone with authority (Andy Herrick?) tells me, this makes sense. Best regards, Robert Lichtenberger From david.holmes at oracle.com Wed Jul 3 06:10:05 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 3 Jul 2019 16:10:05 +1000 Subject: (13) RFR (S): 8227055: Minor edits to launcher help text In-Reply-To: References: <7311d01f-e886-0bff-5e4d-ca70ca1252d5@oracle.com> Message-ID: <7ee9335c-9fd1-eba1-40a4-47cbe8ecf4d5@oracle.com> Hi Mandy, Thanks for taking a look. On 3/07/2019 8:57 am, Mandy Chung wrote: > On 7/2/19 3:44 PM, David Holmes wrote: >> webrev: http://cr.openjdk.java.net/~dholmes/8227055/webrev/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8227055 >> >> The launcher help text needs some minor updates/corrections >> - -verbose needs more info >> - -Xdebug needs to say it does nothing > > Should this be removed instead? There is some strange history/status with this flag. I expect the flag and thus documentation should be removed, but that would be a seperate issue for 14 (or later). For 13 I'm just aligning the help text with the manpage description. >> - -Xloggc is deprecated and replaced by -Xlog:gc:filename > > I think it can just list -Xlog:gc (the replacement) and no need > to mention the deprecated option in the launcher help message. Again this aligns with the manpage which does list it as deprecated and its replacement. Otherwise the launcher help doesn't document specific -Xlog usages. >> - -Xshare:on needs warning about use >> >> Reference to Mac OS X should be macOS. >> >> The --disable- at files is documented as both a standard and extra option. >> > > I think this is intended to be an extra option. This is from Alan: "I'm not sure how `-disable- at files` ended up in both the `-help` and `-X` output, it probably make sense to drop it from the `-X` output. That way, `@argument` and `-disable- at files` are listed together, not in separate usage pages." (The bug explains how it ended up in both places - and yes it started as a -X option.) Thanks, David ----- > Otherwise, looks okay. > > Mandy > >> This aligns the help info with the Java manpage info. >> >> Thanks, >> David > From andy.herrick at oracle.com Wed Jul 3 12:22:35 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 3 Jul 2019 08:22:35 -0400 Subject: JPackage application image file system layout In-Reply-To: References: <646068FF-040B-4B97-B494-A8615997E951@gmail.com> Message-ID: <843aaeba-2427-0a8b-12f2-81c40448d2a7@oracle.com> On 7/3/2019 2:08 AM, Robert Lichtenberger wrote: > I just noticed that my last reply was addressed to Scott Palmer only, so > I "repost" my latest thougths now: > > Am 01.07.19 um 16:50 schrieb Scott Palmer: >>> On Jul 1, 2019, at 2:47 AM, Robert Lichtenberger wrote: >>> >>> While trying to update our application to the (ea-version of) jpackager I >>> noticed that the executable files are now in a bin/ subdirectory, which >>> will make the application update from javapackager a real pain. >>> >>> For Linux this can be argumented with the Filesystem Hierarchy Standard but >>> under Windows it is not common or standard to do so. The .exe file for an >>> application is expected to live in the base installation directory. >> It can also be argued that on Windows it is more common to launch the application from a shortcut in the Start menu, on the Desktop, or in the launch bar. >> I get that this is a change from the previous behaviour so some adjustments need to be made, but how bad is it really? > For me, right now, it is a showstopper. > > I have to update my application silently, in-place. If jpackage isn't > adapted I'll have to resort to crude hacks like a "trampoline" > .exe - File which will call bin/.exe when it's called and/or > adapting existing .lnk - Files on the Windows machine (which will > probably look very suspicious to anti-malware solutions ...). >> The JDK has always had a bin directory and many other applications follow this pattern on Windows as well. > Usually these are applications ported from Linux/Unix. But I admit > there's no real standard or de-facto-standard about it. It's just the > fact that javapackager used to work this way and now jpackage works that > way, which makes it difficult in some situations. > > > I've digged into the jpackage source code yesterday and was able to > adapt LinuxAppImageBuilder.java and LinuxPlatform.cpp so that they would > no longer use the bin/ subdirectory and from a cursory look it seems > this could be done for Windows as well. Of course this would have to be > tested and checked much more. > > To me it looks like there are three possible solutions: > > a) Everything stays as it is now. Things will remain difficult for me > (and possibly for other people) As is. > > b) We change Windows so as to not use the bin/ subdirectory. I have filed an enhancement JDK-8227172 to consider this option . > > c) We add another config-option that will control whether or not to use > the bin/ subdirectory This option is basically a subset of JDK-8216564 , except option would allow any specified subdir path (or none) to be used. These options will require further discussion. /Andy > > I would be willing to invest time in a patch for? b) or c) but only if > someone with authority (Andy Herrick?) tells me, this makes sense. > > Best regards, > > Robert Lichtenberger > From thejasvi.v.voniadka at oracle.com Wed Jul 3 12:32:29 2019 From: thejasvi.v.voniadka at oracle.com (Thejasvi Voniadka) Date: Wed, 3 Jul 2019 05:32:29 -0700 (PDT) Subject: RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string In-Reply-To: <0ba3fe52-ba6f-df36-7a99-d5b8741920fc@oracle.com> References: <8ec24050-0c2a-4f2d-88e6-a3fba5d40e12@default> <1e497a17-ac12-d2f6-064f-39c4cb15223b@oracle.com> <590cca03-1741-41a2-9544-157d1f553835@default> <0ba3fe52-ba6f-df36-7a99-d5b8741920fc@oracle.com> Message-ID: Hi Naoto, Thank you for the review. Please find the updated webrev: http://cr.openjdk.java.net/~vagarwal/8154520/webrev.3/ The TCKOffsetPrinterParser.java has been reverted back to what it was, except for the copyright year and the locale addition. I have incorporated your comments to TestLocalizedOffsetPrinterParser.java. -----Original Message----- From: Naoto Sato Sent: Tuesday, July 02, 2019 9:33 PM To: Thejasvi Voniadka ; core-libs-dev at openjdk.java.net; i18n-dev at openjdk.java.net Subject: Re: RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string Hi Thejasvi, Here are my comments to the webrev: TCKOffsetPrinterParser.java - No need to define Locale_US as a static field, nor have it in the test data (data_print_localized) then pass it as an argument to the test. Specifying Locale.US in line 572, 578, and 586 should suffice. TestOffsetPrinterParser.java - Copyright year is 2019. - It would be nice if some comments that reads something like "This test relies on the localized text of "GMT" in the CLDR." - Test class (and the description) should include "Localized", as it is testing the implementation of localized version of OffsetIdPrinterParser. - Line 64-76: I prefer just instantiating them in the test data, not defining a static field for each, unless there will be duplicate in the test data. - Line 111, 118, 124, 132: I believe the locale parameter is required. Make sure that with Objects.requireNonNull(), or fail if it's null. Naoto On 7/2/19 7:32 AM, Thejasvi Voniadka wrote: > Hi Naoto, > > Thank you for the review. I have performed the modifications, and here is the updated webrev: > > http://cr.openjdk.java.net/~vagarwal/8154520/webrev.2/ > > > I have moved the new tests from TCK area. I have also updated the current TCK test to explicitly pass Locale.US while calling format. > > > > > -----Original Message----- > From: Naoto Sato > Sent: Monday, July 01, 2019 9:02 PM > To: Thejasvi Voniadka ; > core-libs-dev at openjdk.java.net; i18n-dev at openjdk.java.net > Subject: Re: RFR: 8154520: java.time: > appendLocalizedOffset() should return the localized "GMT" string > > Hi Thejasvi, > > Thanks for fixing this. > > Since those new test cases depend on the CLDR localization, which might change in other implementations, those test cases should be in jdk/java/time/test directory, as "tck" tests should only test the spec. > Please create a new test case for this in the "test" directory (with @modules jdk.localedata directive) similar to the existing TCK one. Also the current test in the TCK should enforce that it runs in Locale.US so that the result should match "GMT." > > Naoto > > On 6/28/19 5:59 AM, Thejasvi Voniadka wrote: >> Hi, >> >> Request you to please review this change. >> >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8154520 >> >> >> Description: At present, the "DateTimeFormatterBuilder.appendLocalizedOffset()" method formulates the base string as "GMT", without accounting for locale-specific transformations. This change is to return the localized version of "GMT" instead. So for example, instead of returning "GMT +5.30", it may now return "XXXX +5.30" where "XXXX" is the localized string for "GMT" for the locale associated with the formatter. I have used DateTimeTextProvider.getLocalizedResource() method to return the "gmtZeroFormat" value from CLDR/LDML corresponding to the given locale. The code defaults to "GMT" in the absence of such a localized value. >> >> >> Webrev: http://cr.openjdk.java.net/~vagarwal/8154520/webrev.1/ >> >> >> Additional notes: I preferred to update and reuse an existing test instead of creating a new one. It already has the niceties in place, and creating another method would mean some amount of code redundancy. However, if that's the recommended norm, then I can change it. >> From andy.herrick at oracle.com Wed Jul 3 14:16:59 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 3 Jul 2019 10:16:59 -0400 Subject: RFR: JDK-8227058: Regressions related to no longer setting user.dir 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). [1] https://bugs.openjdk.java.net/browse/JDK-8227058 [2] http://cr.openjdk.java.net/~herrick/8227058/ /Andy From naoto.sato at oracle.com Wed Jul 3 16:10:36 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 3 Jul 2019 09:10:36 -0700 Subject: RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string In-Reply-To: References: <8ec24050-0c2a-4f2d-88e6-a3fba5d40e12@default> <1e497a17-ac12-d2f6-064f-39c4cb15223b@oracle.com> <590cca03-1741-41a2-9544-157d1f553835@default> <0ba3fe52-ba6f-df36-7a99-d5b8741920fc@oracle.com> Message-ID: Looks good. Naoto On 7/3/19 5:32 AM, Thejasvi Voniadka wrote: > Hi Naoto, > > Thank you for the review. Please find the updated webrev: > > http://cr.openjdk.java.net/~vagarwal/8154520/webrev.3/ > > > The TCKOffsetPrinterParser.java has been reverted back to what it was, except for the copyright year and the locale addition. I have incorporated your comments to TestLocalizedOffsetPrinterParser.java. > > > > -----Original Message----- > From: Naoto Sato > Sent: Tuesday, July 02, 2019 9:33 PM > To: Thejasvi Voniadka ; core-libs-dev at openjdk.java.net; i18n-dev at openjdk.java.net > Subject: Re: RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string > > Hi Thejasvi, > > Here are my comments to the webrev: > > TCKOffsetPrinterParser.java > > - No need to define Locale_US as a static field, nor have it in the test data (data_print_localized) then pass it as an argument to the test. > Specifying Locale.US in line 572, 578, and 586 should suffice. > > TestOffsetPrinterParser.java > > - Copyright year is 2019. > > - It would be nice if some comments that reads something like "This test relies on the localized text of "GMT" in the CLDR." > > - Test class (and the description) should include "Localized", as it is testing the implementation of localized version of OffsetIdPrinterParser. > > - Line 64-76: I prefer just instantiating them in the test data, not defining a static field for each, unless there will be duplicate in the test data. > > - Line 111, 118, 124, 132: I believe the locale parameter is required. > Make sure that with Objects.requireNonNull(), or fail if it's null. > > Naoto > > On 7/2/19 7:32 AM, Thejasvi Voniadka wrote: >> Hi Naoto, >> >> Thank you for the review. I have performed the modifications, and here is the updated webrev: >> >> http://cr.openjdk.java.net/~vagarwal/8154520/webrev.2/ >> >> >> I have moved the new tests from TCK area. I have also updated the current TCK test to explicitly pass Locale.US while calling format. >> >> >> >> >> -----Original Message----- >> From: Naoto Sato >> Sent: Monday, July 01, 2019 9:02 PM >> To: Thejasvi Voniadka ; >> core-libs-dev at openjdk.java.net; i18n-dev at openjdk.java.net >> Subject: Re: RFR: 8154520: java.time: >> appendLocalizedOffset() should return the localized "GMT" string >> >> Hi Thejasvi, >> >> Thanks for fixing this. >> >> Since those new test cases depend on the CLDR localization, which might change in other implementations, those test cases should be in jdk/java/time/test directory, as "tck" tests should only test the spec. >> Please create a new test case for this in the "test" directory (with @modules jdk.localedata directive) similar to the existing TCK one. Also the current test in the TCK should enforce that it runs in Locale.US so that the result should match "GMT." >> >> Naoto >> >> On 6/28/19 5:59 AM, Thejasvi Voniadka wrote: >>> Hi, >>> >>> Request you to please review this change. >>> >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8154520 >>> >>> >>> Description: At present, the "DateTimeFormatterBuilder.appendLocalizedOffset()" method formulates the base string as "GMT", without accounting for locale-specific transformations. This change is to return the localized version of "GMT" instead. So for example, instead of returning "GMT +5.30", it may now return "XXXX +5.30" where "XXXX" is the localized string for "GMT" for the locale associated with the formatter. I have used DateTimeTextProvider.getLocalizedResource() method to return the "gmtZeroFormat" value from CLDR/LDML corresponding to the given locale. The code defaults to "GMT" in the absence of such a localized value. >>> >>> >>> Webrev: http://cr.openjdk.java.net/~vagarwal/8154520/webrev.1/ >>> >>> >>> Additional notes: I preferred to update and reuse an existing test instead of creating a new one. It already has the niceties in place, and creating another method would mean some amount of code redundancy. However, if that's the recommended norm, then I can change it. >>> From mandy.chung at oracle.com Wed Jul 3 16:47:12 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 3 Jul 2019 09:47:12 -0700 Subject: 8226863: [aix] jdk/java/lang/reflect/exeCallerAccessTest cannot launch on primordial thread In-Reply-To: References: <9e935e78-a7ec-3627-1637-f3c43e6ed74c@oracle.com> Message-ID: On 7/2/19 10:30 PM, Thomas St?fe wrote: > Hi Mandy, > > On Wed, Jul 3, 2019, 00:20 Mandy Chung > wrote: > > Hi Thomas, > > This is AIX-only.??? It would be cleaner to move AIX-specific > launcher > to a new file like main_aix.c.? Have you considered that? > > > I rather not since this would unnecessarily increase complexity even > further. > > However, if you really dislike the platform specific code, I would > withdraw the patch and just disable the test on AIX. I was on the > fence about that anyway. > +1 disabling this test on AIX until the underlying issue is addressed. Mandy > Cheers, Thomas > > > I don't know how to specify additional .c file in > make/test/JtregNativeJdk.gmk? though. > > Mandy > > > > On 7/1/19 10:23 PM, Thomas St?fe wrote: > > Second, corrected Webrev: > > > > > http://cr.openjdk.java.net/~stuefe/webrevs/execalleraccesstest-cannot-launch-on-primordial-thread/webrev.01/webrev/ > > > > Run through SAP nightlies on all platforms. > > > > Cheers, Thomas > > > > > > On Thu, Jun 27, 2019 at 9:02 AM Thomas St?fe > > > > wrote: > > > >> Hi all, > >> > >> Issue: > >> https://bugs.openjdk.java.net/browse/JDK-8226863 > >> webrev: > >> > >> > http://cr.openjdk.java.net/~stuefe/webrevs/8226863--jdk-java-lang-reflect-execalleraccesstest-cannot-launch-on-primordial-thread/webrev.00/webrev/ > >> > >> we have this annoying issue on AIX that the libjvm cannot be > invoked on a > >> primordial thread. Therefore we need to change launchers which > create the > >> VM to spawn own threads (we only do this where it is worth the > effort - > >> this, admittedly, is a corner case, we could alternatively just > disable the > >> test on AIX). > >> > >> This is annoying and vaguely embarrassing :-/ Maybe IBM will > step in some > >> time and help us solve the underlying issues which have to do > with the > >> inability to create guard pages on the primordial thread stack > (among other > >> things IIRC). > >> > >> Thanks for reviewing, > >> > >> Thomas > >> > >> > >> > From Roger.Riggs at oracle.com Wed Jul 3 17:16:18 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 3 Jul 2019 13:16:18 -0400 Subject: RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string In-Reply-To: References: <8ec24050-0c2a-4f2d-88e6-a3fba5d40e12@default> <1e497a17-ac12-d2f6-064f-39c4cb15223b@oracle.com> <590cca03-1741-41a2-9544-157d1f553835@default> <0ba3fe52-ba6f-df36-7a99-d5b8741920fc@oracle.com> Message-ID: <0c7e5fbf-74fe-cb40-4878-5287bf6581ea@oracle.com> Hi, Looks ok, but... .../java/time/format/DateTimeFormatterBuilder.java 3924: needs a space in "if(" -> "if (" java/time/format/TestLocalizedOffsetPrinterParser.java I would cut the number of test cases to a minimum; only need to ensure the code is correct. We don't need to be testing the CLDR data; it is just? pass through. At least cut the number of different locale's used to cut the risk of unexpected maintenance. Thanks, Roger On 7/3/19 12:10 PM, naoto.sato at oracle.com wrote: > Looks good. > > Naoto > > On 7/3/19 5:32 AM, Thejasvi Voniadka wrote: >> Hi Naoto, >> >> Thank you for the review. Please find the updated webrev: >> >> http://cr.openjdk.java.net/~vagarwal/8154520/webrev.3/ >> >> >> The TCKOffsetPrinterParser.java has been reverted back to what it >> was, except for the copyright year and the locale addition. I have >> incorporated your comments to TestLocalizedOffsetPrinterParser.java. >> >> >> >> -----Original Message----- >> From: Naoto Sato >> Sent: Tuesday, July 02, 2019 9:33 PM >> To: Thejasvi Voniadka ; >> core-libs-dev at openjdk.java.net; i18n-dev at openjdk.java.net >> Subject: Re: RFR: 8154520: java.time: >> appendLocalizedOffset() should return the localized "GMT" string >> >> Hi Thejasvi, >> >> Here are my comments to the webrev: >> >> TCKOffsetPrinterParser.java >> >> - No need to define Locale_US as a static field, nor have it in the >> test data (data_print_localized) then pass it as an argument to the >> test. >> Specifying Locale.US in line 572, 578, and 586 should suffice. >> >> TestOffsetPrinterParser.java >> >> - Copyright year is 2019. >> >> - It would be nice if some comments that reads something like "This >> test relies on the localized text of "GMT" in the CLDR." >> >> - Test class (and the description) should include "Localized", as it >> is testing the implementation of localized version of >> OffsetIdPrinterParser. >> >> - Line 64-76: I prefer just instantiating them in the test data, not >> defining a static field for each, unless there will be duplicate in >> the test data. >> >> - Line 111, 118, 124, 132: I believe the locale parameter is required. >> Make sure that with Objects.requireNonNull(), or fail if it's null. >> >> Naoto >> >> On 7/2/19 7:32 AM, Thejasvi Voniadka wrote: >>> Hi Naoto, >>> >>> Thank you for the review. I have performed the modifications, and >>> here is the updated webrev: >>> >>> http://cr.openjdk.java.net/~vagarwal/8154520/webrev.2/ >>> >>> >>> I have moved the new tests from TCK area. I have also updated the >>> current TCK test to explicitly pass Locale.US while calling format. >>> >>> >>> >>> >>> -----Original Message----- >>> From: Naoto Sato >>> Sent: Monday, July 01, 2019 9:02 PM >>> To: Thejasvi Voniadka ; >>> core-libs-dev at openjdk.java.net; i18n-dev at openjdk.java.net >>> Subject: Re: RFR: 8154520: java.time: >>> appendLocalizedOffset() should return the localized "GMT" string >>> >>> Hi Thejasvi, >>> >>> Thanks for fixing this. >>> >>> Since those new test cases depend on the CLDR localization, which >>> might change in other implementations, those test cases should be in >>> jdk/java/time/test directory, as "tck" tests should only test the spec. >>> Please create a new test case for this in the "test" directory (with >>> @modules jdk.localedata directive) similar to the existing TCK one. >>> Also the current test in the TCK should enforce that it runs in >>> Locale.US so that the result should match "GMT." >>> >>> Naoto >>> >>> On 6/28/19 5:59 AM, Thejasvi Voniadka wrote: >>>> Hi, >>>> >>>> Request you to please review this change. >>>> >>>> >>>> JBS:??? https://bugs.openjdk.java.net/browse/JDK-8154520 >>>> >>>> >>>> Description:??? At present, the >>>> "DateTimeFormatterBuilder.appendLocalizedOffset()" method >>>> formulates the base string as "GMT", without accounting for >>>> locale-specific transformations. This change is to return the >>>> localized version of "GMT" instead. So for example, instead of >>>> returning "GMT +5.30", it may now return "XXXX +5.30" where "XXXX" >>>> is the localized string for "GMT" for the locale associated with >>>> the formatter. I have used >>>> DateTimeTextProvider.getLocalizedResource() method to return the >>>> "gmtZeroFormat" value from CLDR/LDML corresponding to the given >>>> locale. The code defaults to "GMT" in the absence of such a >>>> localized value. >>>> >>>> >>>> Webrev: http://cr.openjdk.java.net/~vagarwal/8154520/webrev.1/ >>>> >>>> >>>> Additional notes:??? I preferred to update and reuse an existing >>>> test instead of creating a new one. It already has the niceties in >>>> place, and creating another method would mean some amount of code >>>> redundancy. However, if that's the recommended norm, then I can >>>> change it. >>>> From mandy.chung at oracle.com Wed Jul 3 17:36:51 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 3 Jul 2019 10:36:51 -0700 Subject: (13) RFR (S): 8227055: Minor edits to launcher help text In-Reply-To: <7ee9335c-9fd1-eba1-40a4-47cbe8ecf4d5@oracle.com> References: <7311d01f-e886-0bff-5e4d-ca70ca1252d5@oracle.com> <7ee9335c-9fd1-eba1-40a4-47cbe8ecf4d5@oracle.com> Message-ID: <82a41d91-d235-4be3-964e-edc92d41a165@oracle.com> On 7/2/19 11:10 PM, David Holmes wrote: > Hi Mandy, > > Thanks for taking a look. > > On 3/07/2019 8:57 am, Mandy Chung wrote: >> On 7/2/19 3:44 PM, David Holmes wrote: >>> webrev: http://cr.openjdk.java.net/~dholmes/8227055/webrev/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8227055 >>> >>> The launcher help text needs some minor updates/corrections >>> - -verbose needs more info >>> - -Xdebug needs to say it does nothing >> >> Should this be removed instead? > > There is some strange history/status with this flag. I expect the flag > and thus documentation should be removed, but that would be a seperate > issue for 14 (or later). For 13 I'm just aligning the help text with > the manpage description. > I would propose? to take -Xdebug out from the launcher help message and man page but -Xdebug is still accepted but do nothing. >>> - -Xloggc is deprecated and replaced by -Xlog:gc:filename >> >> I think it can just list -Xlog:gc (the replacement) and no need >> to mention the deprecated option in the launcher help message. > > Again this aligns with the manpage which does list it as deprecated > and its replacement. Otherwise the launcher help doesn't document > specific -Xlog usages. > -Xloggc was deprecated since 9 (or earlier [1]).? I think documenting the recommended option instead is the right thing to do.? I think it worths the discussion and includes some guideline in JEP 293 (Guidelines for JDK CLI) [2] w.r.t. deprecated options in the help message vs man page. I'm fine if you want to move ahead with this patch. >>> - -Xshare:on needs warning about use >>> >>> Reference to Mac OS X should be macOS. >>> >>> The --disable- at files is documented as both a standard and extra option. >>> >> >> I think this is intended to be an extra option. > > This is from Alan: > > "I'm not sure how `-disable- at files` ended up in both the `-help` and > `-X` output, it probably make sense to drop it from the `-X` output. > That way, `@argument` and `-disable- at files` are listed together, not > in separate usage pages." > > (The bug explains how it ended up in both places - and yes it started > as a -X option.) > Hmm... Alan and Jon are both on vacation.? We can follow up this separately. Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8170636 [2] https://openjdk.java.net/jeps/293 From lance.andersen at oracle.com Wed Jul 3 17:57:26 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 3 Jul 2019 13:57:26 -0400 Subject: Inputs on patch for JDK-8225763? Inflater and Deflater should implement AutoCloseable In-Reply-To: <0d234157-869f-9c95-b3dc-587f989b1551@oracle.com> References: <44582692-a30b-0d54-e550-6277cab95969@gmail.com> <152766d5-72b0-9847-cde2-c89f1d0229d8@gmail.com> <5b1f547f-84da-c8c2-c071-278830e125a2@gmail.com> <0d234157-869f-9c95-b3dc-587f989b1551@oracle.com> Message-ID: <68D51EE3-869F-4865-A249-6AF321A92E51@oracle.com> Just a thought below to consider or ignore ;-) > On Jul 2, 2019, at 11:27 PM, Stuart Marks wrote: > > Hi Jaikiran, > > OK, good analysis. Rather a lot of issues for what seems like a simple patch, eh? > > - Idempotency > > Yes, it looks to me like Inflater.end() and Deflater.end() implementations are idempotent. As you point out, overrides by subclasses might not be. We should be clear when we're talking about the specific implementatations of the end() methods in the Deflater and Inflater classes, or whether we're talking about the contracts defined by these method specifications on these classes and subtypes. > > The behavior of an implementation in a class can be specified with @implSpec without imposing this on the contract of subclasses. This is useful for subclasses that need to know the exact behavior of calling super.end(), and also for callers who know they have an instance of a particular class and not a subclass. > > The upshot is that while we might not have the end() method's contract specify idempotency, we can certainly say so in an @implSpec, if doing this will help. I'm not sure we'll actually need it in this case, but let's keep it in mind. > > - Subclasses > > I don't think there are any subclasses in the JDK, and I did some searching and I didn't find any subclasses "in the wild" either. I did find a few uses of these classes though. If these classes are rarely subclassed, we might be able to get away with changing the contract, though this does entail some risk. we could consider leaving end() as is and just introduce close() which while it duplicates what end() does, it reduces the chance of any potential complaints. We could then update the javadoc for end() to strongly suggest the use of close() vs end() > > If we need to modify the subclasses used in tests, that's fair game though. > > - Relationship between end() and close() > > I think close() should have more-or-less the same semantics as end(), namely, pretty much the way end() is specified now regarding releasing resources. But it should be allowable to call both in either order. > > try (var inf = new Inflater()) { > ... > # explicitly call end() > inf.end(); > } > > I think this should allowed, but it shouldn't be required. The application can call either close() or end() and this will have the effect of releasing the native resources. > > A key question is whether close() should be specified to call end() -- which is subject to being overridden by suclasses -- or whether close() is defined to do the same thing as the end() implementation in this class does. This can be implemented by taking the body of the current end() method and refactoring it into an internal method and then having both close() and end() call that internal method. > > If close() calls end() then AC+TWR might call close() twice, and therefore call end() twice, which might be a problem for subclasses. So to be really conservative we might want to do the internal-method refactoring to avoid this problem. > > On the other hand, suppose a subclass has extra resources it frees in its end() method, which then calls super.end(). Even though this class would inherit AC, using it in TWR would be a *bug* because close() would call the internal method to free the superclass resources, but this would leak the subclass resources. That sounds like a mistake to perpetuate in the API. > > It's possible for a subclass to override end() in such a way that's not idempotent, but I think this is unlikely. I'm leaning toward risking the small possibility of incompatibility in declaring end() idempotent, allowing close() simply to call end(). This makes TWR more useful in the long run, which seems like a better position to be in. Of course, if somebody turns up evidence that this would break a bunch of stuff, we should reconsider. > > (This might be moot anyway. The condition where TWR closes a resource multiple times occurs in cases where closing a wrapper closes the wrapped resource, and both are TWR resource variables. But in my earlier example > > try (var inf = new Inflater(); > var iis = new InflaterInputStream(inputStream, inf)) { > ... > } > > and in fact all of {Inflater,Deflater}{Input,Output}Stream don't close the passed-in Deflater/Inflater, so multiple close() calls won't occur.) > > - Deprecation of end() I don?t think we need to deprecate, just add a note to its javadoc encouraging the use of close() going forward... > > I don't think deprecation of end() is useful. It'll just cause noise for people. Uses such as > > var deflater = new Deflater(); > try { > ... > } finally { > deflater.end(); > } > > are valid and correct and needn't be changed (though using TWR is preferable, this is more of a style issue). > > - Undefined behavior after close()/end() > > OK, I'll admit this is possibly out of scope, but the line in the specs about "once end() is called, the behavior is undefined" rubs me the wrong way. Right now, most operations seem to call ensureOpen(), which throws NPE if the object has been closed. But "undefined" allows anything to happen, including filling the output buffer with garbage. That seems wrong. We might not want to specify what exception is thrown, but we might want to specify that *AN* exception is thrown -- which must be a RuntimeException, since most methods don't declare any checked exceptions. > > In any case, the clause would have to be updated to say something like "Once this Deflater (Inflater) is closed, any subsequent operations will ." > > ** > > If you think the issues are settled enough, maybe it's time for you to take a stab at a patch. Up to you how to proceed with the "undefined" issue. If it's simple, great, I'd like to see it happen. But if it leads you off into the weeds, then feel free to drop it. > > Note: US holiday weekend coming up; replies might take several days. > > s'marks > > > > > On 6/29/19 4:16 AM, Jaikiran Pai wrote: >> On 29/06/19 4:31 PM, Jaikiran Pai wrote: >>> Hello Stuart, >>> >>> Thank you for the detailed response. Comments inline. >>> >>> On 28/06/19 2:48 AM, Stuart Marks wrote: >>>> On 6/26/19 9:28 PM, Jaikiran Pai wrote: >>>>> I am looking to contribute a patch for the enhancement noted in >>>>> https://bugs.openjdk.java.net/browse/JDK-8225763. The change itself >>>>> looks relatively straightforward to me and here's what I plan to do: >>>>> >>>>> 1. Have both java.util.zip.Inflater and java.util.zip.Deflater start >>>>> implementing the AutoCloseable interface >>>>> >>>>> 2. Have the close() method call the end() method >>>>> >>>>> 3. Add javadoc to the close() implementation to mention that the end() >>>>> method gets called >>>>> >>>>> 4. Add test(s) to verify that the close indeed actually "ends" the >>>>> inflater/deflater >>>>> >>>>> 5. This is more of a question - do we have to update the class level >>>>> javadoc of both these classes to make a mention that these classes have >>>>> started implementing the AutoCloseable starting version 14 (or whichever >>>>> version this change makes into) of Java? >>>>> >>>>> Any other inputs/suggestions on what else might be needed in this >>>>> change? >>>> Hi Jaikiran, >>>> >>>> Thanks for picking this up. There are some small wrinkles with this, >>>> but I hope nothing that will prevent it from happening. >>>> >>>> >>>> 2) Alan already mentioned this, but we need to consider the issue of >>>> idempotent close() or end() carefully. It's not strictly required, but >>>> it would be nice. I had taken a quick look at end() and I *thought* it >>>> was idempotent already, but a more careful analysis needs to be done. >>> I did some checks in the current JDK code. From what I see, the Inflater >>> and Deflater do not have any subclasses within the JDK itself. >> To be clear - I couldn't find any subclasses in the main source code of >> JDK. There are a couple of subclasses in the tests >> (ConstructInflaterOutput.java and ConstructDeflaterInput.java), but >> those don't do much outside of the context of testing. >> -Jaikiran Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From mandy.chung at oracle.com Wed Jul 3 20:04:53 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 3 Jul 2019 13:04:53 -0700 Subject: Slow performance of StackWalker.getCallerClass() vs Reflection.getCallerClass() In-Reply-To: References: <1082795724.1561886.1562071799378.JavaMail.zimbra@u-pem.fr> <886e2549-ac78-2f6e-0b71-cd29c837ec23@oracle.com> Message-ID: <048dff93-0a17-cbf6-45a1-709287f0ac18@oracle.com> On 7/2/19 6:57 PM, Ralph Goers wrote: > Thanks Mandy, > > It seems I commented on the thread mentioned in the issue you linked > to. Unfortunately, it doesn?t look like any work has been done on the > issue.in the last 18 months. > I did start to explore some options and never have time to spend on this as I have been working on other higher priority projects. > Yes, LogRecord doesn?t get the StackTraceElement. We only get it for > the one stack entry we are interested in and we only do that because > Log4j is still compatible with Java 7 and creating our own class would > be too disruptive. Still, the cost seems to be in locating the correct > frame, not creating the StackTraceElement. Do you have data/information where you find the overhead comes from?? if you avoid using StackTraceElement, that'd help understanding it. Mandy From alexander.matveev at oracle.com Wed Jul 3 21:01:09 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Wed, 3 Jul 2019 14:01:09 -0700 Subject: RFR: JDK-8227058: Regressions related to no longer setting user.dir In-Reply-To: References: Message-ID: <38e7d1a3-a16c-e808-bac3-4efb896f7725@oracle.com> Hi Andy, Looks good. Thanks, Alexander On 7/3/2019 7:16 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). > > [1] https://bugs.openjdk.java.net/browse/JDK-8227058 > > [2] http://cr.openjdk.java.net/~herrick/8227058/ > > /Andy > From joe.darcy at oracle.com Wed Jul 3 21:24:52 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 3 Jul 2019 14:24:52 -0700 Subject: JDK 14 RFR of JDK-8227202: clarify Class.isEnum() doc Message-ID: <2c05fb70-bbc9-393f-3a1a-b2f6dfa00e53@oracle.com> Hello, Please review the patch below to address ??? JDK-8227202: clarify Class.isEnum() doc To condense a long story (see https://blogs.oracle.com/darcy/so-you-want-to-change-the-java-programming-language), there are cases where the Class object of an enum constant is *not* the Class object of the declaring enum type. While this is the specified behavior, it can be surprising and the paragraph of added text is intended to explain the situation. Thanks, -Joe --- a/src/java.base/share/classes/java/lang/Class.java??? Wed Jul 03 15:46:48 2019 -0400 +++ b/src/java.base/share/classes/java/lang/Class.java??? Wed Jul 03 14:22:28 2019 -0700 @@ -3491,9 +3491,16 @@ ????? * Returns true if and only if this class was declared as an enum in the ????? * source code. ????? * +???? * Note that if an enum constant is declared with a class body, +???? * the class of that enum constant is an anonymous class and +???? * not the class of the declaring enum type. The {@link +???? * Enum.getDeclaringClass} method can be used to get class of the +???? * enum type declaring an enum constant. +???? * ????? * @return true if and only if this class was declared as an enum in the ????? *???? source code ????? * @since 1.5 +???? * @jls 8.9.1 Enum Constants ????? */ ???? public boolean isEnum() { ???????? // An enum must both directly extend java.lang.Enum and have From brian.burkhalter at oracle.com Wed Jul 3 21:28:28 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 3 Jul 2019 14:28:28 -0700 Subject: JDK 14 RFR of JDK-8227202: clarify Class.isEnum() doc In-Reply-To: <2c05fb70-bbc9-393f-3a1a-b2f6dfa00e53@oracle.com> References: <2c05fb70-bbc9-393f-3a1a-b2f6dfa00e53@oracle.com> Message-ID: Hi Joe, > On Jul 3, 2019, at 2:24 PM, Joe Darcy wrote: > > + * Note that if an enum constant is declared with a class body, > + * the class of that enum constant is an anonymous class and > + * not the class of the declaring enum type. The {@link > + * Enum.getDeclaringClass} method can be used to get class of the I think you intended ?get the class? in the preceding line. > + * enum type declaring an enum constant. Thanks, Brian From joe.darcy at oracle.com Wed Jul 3 22:46:12 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 3 Jul 2019 15:46:12 -0700 Subject: JDK 14 RFR of JDK-8227202: clarify Class.isEnum() doc In-Reply-To: References: <2c05fb70-bbc9-393f-3a1a-b2f6dfa00e53@oracle.com> Message-ID: Hi Brian, Thanks for catching that; I'll correct before pushing. Cheers, -Joe On 7/3/2019 2:28 PM, Brian Burkhalter wrote: > Hi Joe, > >> On Jul 3, 2019, at 2:24 PM, Joe Darcy > > wrote: >> >> +???? * Note that if an enum constant is declared with a class body, >> +???? * the class of that enum constant is an anonymous class and >> +???? * not the class of the declaring enum type. The {@link >> +???? * Enum.getDeclaringClass} method can be used to get class of the > > I think you intended ?get *the*?class? in the preceding line. > >> +???? * enum type declaring an enum constant. > > Thanks, > > Brian From brian.burkhalter at oracle.com Wed Jul 3 22:47:05 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 3 Jul 2019 15:47:05 -0700 Subject: JDK 14 RFR of JDK-8227202: clarify Class.isEnum() doc In-Reply-To: References: <2c05fb70-bbc9-393f-3a1a-b2f6dfa00e53@oracle.com> Message-ID: <1230C049-1675-4B98-BAB8-0CCAD23C889B@oracle.com> Hi Joe, Sounds good. Thanks, Brian > On Jul 3, 2019, at 3:46 PM, Joe Darcy wrote: > > Thanks for catching that; I'll correct before pushing. > > Cheers, > > -Joe > > On 7/3/2019 2:28 PM, Brian Burkhalter wrote: >> Hi Joe, >> >>> On Jul 3, 2019, at 2:24 PM, Joe Darcy > wrote: >>> >>> + * Note that if an enum constant is declared with a class body, >>> + * the class of that enum constant is an anonymous class and >>> + * not the class of the declaring enum type. The {@link >>> + * Enum.getDeclaringClass} method can be used to get class of the >> >> I think you intended ?get the class? in the preceding line. From david.holmes at oracle.com Wed Jul 3 23:24:01 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 4 Jul 2019 09:24:01 +1000 Subject: (13) RFR (S): 8227055: Minor edits to launcher help text In-Reply-To: <82a41d91-d235-4be3-964e-edc92d41a165@oracle.com> References: <7311d01f-e886-0bff-5e4d-ca70ca1252d5@oracle.com> <7ee9335c-9fd1-eba1-40a4-47cbe8ecf4d5@oracle.com> <82a41d91-d235-4be3-964e-edc92d41a165@oracle.com> Message-ID: <078b01db-2fbb-72c3-8015-142a80af1bdd@oracle.com> > I'm fine if you want to move ahead with this patch. Thanks Mandy - much appreciated! We can continue this refinement for 14. I have filed JDK-8227229 to deprecate and remove Xdebug - for history see: https://bugs.openjdk.java.net/browse/JDK-6272174 BTW thanks for the reference to JEP-293, I wasn't aware of it. Would be nice to expand it to give more guidelines on handling deprecation etc. Cheers, David ----- On 4/07/2019 3:36 am, Mandy Chung wrote: > > > On 7/2/19 11:10 PM, David Holmes wrote: >> Hi Mandy, >> >> Thanks for taking a look. >> >> On 3/07/2019 8:57 am, Mandy Chung wrote: >>> On 7/2/19 3:44 PM, David Holmes wrote: >>>> webrev: http://cr.openjdk.java.net/~dholmes/8227055/webrev/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8227055 >>>> >>>> The launcher help text needs some minor updates/corrections >>>> - -verbose needs more info >>>> - -Xdebug needs to say it does nothing >>> >>> Should this be removed instead? >> >> There is some strange history/status with this flag. I expect the flag >> and thus documentation should be removed, but that would be a seperate >> issue for 14 (or later). For 13 I'm just aligning the help text with >> the manpage description. >> > > I would propose? to take -Xdebug out from the launcher help message and > man page but -Xdebug is still accepted but do nothing. > >>>> - -Xloggc is deprecated and replaced by -Xlog:gc:filename >>> >>> I think it can just list -Xlog:gc (the replacement) and no need >>> to mention the deprecated option in the launcher help message. >> >> Again this aligns with the manpage which does list it as deprecated >> and its replacement. Otherwise the launcher help doesn't document >> specific -Xlog usages. >> > > -Xloggc was deprecated since 9 (or earlier [1]).? I think documenting > the recommended option instead is the right thing to do.? I think it > worths the discussion and includes some guideline in JEP 293 (Guidelines > for JDK CLI) [2] w.r.t. deprecated options in the help message vs man page. > > I'm fine if you want to move ahead with this patch. > >>>> - -Xshare:on needs warning about use >>>> >>>> Reference to Mac OS X should be macOS. >>>> >>>> The --disable- at files is documented as both a standard and extra option. >>>> >>> >>> I think this is intended to be an extra option. >> >> This is from Alan: >> >> "I'm not sure how `-disable- at files` ended up in both the `-help` and >> `-X` output, it probably make sense to drop it from the `-X` output. >> That way, `@argument` and `-disable- at files` are listed together, not >> in separate usage pages." >> >> (The bug explains how it ended up in both places - and yes it started >> as a -X option.) >> > > Hmm... Alan and Jon are both on vacation.? We can follow up this > separately. > > Mandy > [1] https://bugs.openjdk.java.net/browse/JDK-8170636 > [2] https://openjdk.java.net/jeps/293 > From thomas.stuefe at gmail.com Thu Jul 4 09:13:48 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 4 Jul 2019 11:13:48 +0200 Subject: RFR(T): 8227252: [aix] Disable jdk/java/lang/reflect/exeCallerAccessTest Message-ID: Greetings, please review this trivial fix which switches off jdk/java/lang/reflect/exeCallerAccessTest on AIX. JBS: https://bugs.openjdk.java.net/browse/JDK-8227252 cr: http://cr.openjdk.java.net/~stuefe/webrevs/8227252-disable-execallertest-on-aix/webrev.00/webrev/ Thanks, Thomas From goetz.lindenmaier at sap.com Thu Jul 4 09:17:14 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 4 Jul 2019 09:17:14 +0000 Subject: RFR(T): 8227252: [aix] Disable jdk/java/lang/reflect/exeCallerAccessTest In-Reply-To: References: Message-ID: Hi Thomas, looks good. We did similar to other tests using the primordial thread before. Best regards, Goetz. > -----Original Message----- > From: core-libs-dev On Behalf Of > Thomas St?fe > Sent: Donnerstag, 4. Juli 2019 11:14 > To: Java Core Libs ; ppc-aix-port-dev aix-port-dev at openjdk.java.net> > Subject: RFR(T): 8227252: [aix] Disable > jdk/java/lang/reflect/exeCallerAccessTest > > Greetings, > > please review this trivial fix which switches > off jdk/java/lang/reflect/exeCallerAccessTest on AIX. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8227252 > cr: > http://cr.openjdk.java.net/~stuefe/webrevs/8227252-disable-execallertest-on- > aix/webrev.00/webrev/ > > Thanks, Thomas From thomas.stuefe at gmail.com Thu Jul 4 09:21:19 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 4 Jul 2019 11:21:19 +0200 Subject: RFR(T): 8227252: [aix] Disable jdk/java/lang/reflect/exeCallerAccessTest In-Reply-To: References: Message-ID: Thanks Goetz. On Thu, Jul 4, 2019 at 11:17 AM Lindenmaier, Goetz < goetz.lindenmaier at sap.com> wrote: > Hi Thomas, > > looks good. > We did similar to other tests using the primordial thread before. > > Best regards, > Goetz. > > > -----Original Message----- > > From: core-libs-dev On Behalf > Of > > Thomas St?fe > > Sent: Donnerstag, 4. Juli 2019 11:14 > > To: Java Core Libs ; ppc-aix-port-dev > > aix-port-dev at openjdk.java.net> > > Subject: RFR(T): 8227252: [aix] Disable > > jdk/java/lang/reflect/exeCallerAccessTest > > > > Greetings, > > > > please review this trivial fix which switches > > off jdk/java/lang/reflect/exeCallerAccessTest on AIX. > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8227252 > > cr: > > > http://cr.openjdk.java.net/~stuefe/webrevs/8227252-disable-execallertest-on- > > aix/webrev.00/webrev/ > > > > Thanks, Thomas > From mandy.chung at oracle.com Fri Jul 5 00:03:38 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 4 Jul 2019 17:03:38 -0700 Subject: RFR(T): 8227252: [aix] Disable jdk/java/lang/reflect/exeCallerAccessTest In-Reply-To: References: Message-ID: <7e78dab2-1edf-e3bd-cd7d-95e8a9d6639e@oracle.com> +1 Mandy On 7/4/19 2:13 AM, Thomas St?fe wrote: > Greetings, > > please review this trivial fix which switches > off jdk/java/lang/reflect/exeCallerAccessTest on AIX. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8227252 > cr: > http://cr.openjdk.java.net/~stuefe/webrevs/8227252-disable-execallertest-on-aix/webrev.00/webrev/ > > Thanks, Thomas From lists at jeffc.ca Fri Jul 5 03:17:20 2019 From: lists at jeffc.ca (Jeff Carpenter) Date: Fri, 05 Jul 2019 03:17:20 +0000 Subject: [PATCH] jpackage: Pack Only AppImage in DMG Message-ID: Hi everyone, As I mentioned a couple of weeks ago (in a message titled "jpackage DMG creation trouble"), the new jpackage packs both a .pkg & AppImage into any .dmg images it creates. The expected behavior is that the tool would pack only an AppImage inside. There may be the very odd case where someone does in fact want a .pkg in a .dmg, but that can be added in future work if needed. This patch gets the primary jpackage .dmg use case working _today_. Hope this helps. Thanks, Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: jpackage-only-pack-appimage-dmg.patch Type: text/x-patch Size: 3527 bytes Desc: not available URL: From thejasvi.v.voniadka at oracle.com Fri Jul 5 03:45:58 2019 From: thejasvi.v.voniadka at oracle.com (Thejasvi Voniadka) Date: Thu, 4 Jul 2019 20:45:58 -0700 (PDT) Subject: RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string In-Reply-To: <0c7e5fbf-74fe-cb40-4878-5287bf6581ea@oracle.com> References: <8ec24050-0c2a-4f2d-88e6-a3fba5d40e12@default> <1e497a17-ac12-d2f6-064f-39c4cb15223b@oracle.com> <590cca03-1741-41a2-9544-157d1f553835@default> <0ba3fe52-ba6f-df36-7a99-d5b8741920fc@oracle.com> <0c7e5fbf-74fe-cb40-4878-5287bf6581ea@oracle.com> Message-ID: <24971d96-e27a-4d2d-bc2f-5290a353e2f4@default> Hi Roger, ? Thank you for the review. I am in transit this weekend, but I will fix this and republish as soon as I can. ? ? From: Roger Riggs Sent: Wednesday, July 03, 2019 10:46 PM To: Thejasvi Voniadka ; core-libs-dev at openjdk.java.net; i18n-dev at openjdk.java.net Subject: Re: RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string ? Hi, Looks ok, but... .../java/time/format/DateTimeFormatterBuilder.java 3924: needs a space in "if(" -> "if (" java/time/format/TestLocalizedOffsetPrinterParser.java I would cut the number of test cases to a minimum; only need to ensure the code is correct. We don't need to be testing the CLDR data; it is just? pass through. At least cut the number of different locale's used to cut the risk of unexpected maintenance. Thanks, Roger On 7/3/19 12:10 PM, HYPERLINK "mailto:naoto.sato at oracle.com"naoto.sato at oracle.com wrote: Looks good. Naoto On 7/3/19 5:32 AM, Thejasvi Voniadka wrote: Hi Naoto, Thank you for the review. Please find the updated webrev: http://cr.openjdk.java.net/~vagarwal/8154520/webrev.3/ The TCKOffsetPrinterParser.java has been reverted back to what it was, except for the copyright year and the locale addition. I have incorporated your comments to TestLocalizedOffsetPrinterParser.java. -----Original Message----- From: Naoto Sato Sent: Tuesday, July 02, 2019 9:33 PM To: Thejasvi Voniadka HYPERLINK "mailto:thejasvi.v.voniadka at oracle.com"; HYPERLINK "mailto:core-libs-dev at openjdk.java.net"core-libs-dev at openjdk.java.net; HYPERLINK "mailto:i18n-dev at openjdk.java.net"i18n-dev at openjdk.java.net Subject: Re: RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string Hi Thejasvi, Here are my comments to the webrev: TCKOffsetPrinterParser.java - No need to define Locale_US as a static field, nor have it in the test data (data_print_localized) then pass it as an argument to the test. Specifying Locale.US in line 572, 578, and 586 should suffice. TestOffsetPrinterParser.java - Copyright year is 2019. - It would be nice if some comments that reads something like "This test relies on the localized text of "GMT" in the CLDR." - Test class (and the description) should include "Localized", as it is testing the implementation of localized version of OffsetIdPrinterParser. - Line 64-76: I prefer just instantiating them in the test data, not defining a static field for each, unless there will be duplicate in the test data. - Line 111, 118, 124, 132: I believe the locale parameter is required. Make sure that with Objects.requireNonNull(), or fail if it's null. Naoto On 7/2/19 7:32 AM, Thejasvi Voniadka wrote: Hi Naoto, Thank you for the review. I have performed the modifications, and here is the updated webrev: http://cr.openjdk.java.net/~vagarwal/8154520/webrev.2/ I have moved the new tests from TCK area. I have also updated the current TCK test to explicitly pass Locale.US while calling format. -----Original Message----- From: Naoto Sato Sent: Monday, July 01, 2019 9:02 PM To: Thejasvi Voniadka HYPERLINK "mailto:thejasvi.v.voniadka at oracle.com"; HYPERLINK "mailto:core-libs-dev at openjdk.java.net"core-libs-dev at openjdk.java.net; HYPERLINK "mailto:i18n-dev at openjdk.java.net"i18n-dev at openjdk.java.net Subject: Re: RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string Hi Thejasvi, Thanks for fixing this. Since those new test cases depend on the CLDR localization, which might change in other implementations, those test cases should be in jdk/java/time/test directory, as "tck" tests should only test the spec. Please create a new test case for this in the "test" directory (with @modules jdk.localedata directive) similar to the existing TCK one. Also the current test in the TCK should enforce that it runs in Locale.US so that the result should match "GMT." Naoto On 6/28/19 5:59 AM, Thejasvi Voniadka wrote: Hi, Request you to please review this change. JBS:??? https://bugs.openjdk.java.net/browse/JDK-8154520 Description:??? At present, the "DateTimeFormatterBuilder.appendLocalizedOffset()" method formulates the base string as "GMT", without accounting for locale-specific transformations. This change is to return the localized version of "GMT" instead. So for example, instead of returning "GMT +5.30", it may now return "XXXX +5.30" where "XXXX" is the localized string for "GMT" for the locale associated with the formatter. I have used DateTimeTextProvider.getLocalizedResource() method to return the "gmtZeroFormat" value from CLDR/LDML corresponding to the given locale. The code defaults to "GMT" in the absence of such a localized value. Webrev:??? http://cr.openjdk.java.net/~vagarwal/8154520/webrev.1/ Additional notes:??? I preferred to update and reuse an existing test instead of creating a new one. It already has the niceties in place, and creating another method would mean some amount of code redundancy. However, if that's the recommended norm, then I can change it. ? From ramanand.patil at oracle.com Fri Jul 5 14:16:43 2019 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Fri, 5 Jul 2019 07:16:43 -0700 (PDT) Subject: RFR: 8224560: (tz) Upgrade time-zone data to tzdata2019a and 8225580: tzdata2018i integration causes test failures on jdk-13 Message-ID: <0a339591-f5ac-4680-ac70-1a48d8699999@default> Hi all, Please review the patch for tzdata2019a integration into jdk project. Webrev: http://cr.openjdk.java.net/~rpatil/8224560/webrev.00/ Bugs: https://bugs.openjdk.java.net/browse/JDK-8224560 https://bugs.openjdk.java.net/browse/JDK-8225580 Summary: - The fix contains cumulative tzdata changes from tzdata2018i and tzdata2019a, as tzdata2018i was not integrated into jdk/jdk earlier. - In JDK-13/14, multiple failures were seen during integration of tzdata2018i (JDK-8225580), those are fixed now. Many thanks to Naoto for providing a fix for this in CLDRConverter.java. - There are 2 type of test failures in TestZoneInfo310.java file, which are solved in this patch by providing workarounds, But a permanent fix needs to be added in future for the same. Below are the 2 bugs created to track the development on it: 1. https://bugs.openjdk.java.net/browse/JDK-8223388: TestZoneInfo310.java fails post tzdata2018i integration: This failure is seen for the TimeZones which are having zone rules defined till year 2037 or beyond. For now, the failing zones are skipped. The supporting test class ZoneInfo.java has maxYear defined http://hg.openjdk.java.net/jdk/jdk/file/d01b345865d7/test/jdk/sun/util/calendar/zi/Zoneinfo.java#l40, changing this max value greater than the zone rule's last year also fixes the issue, but further investigation is needed on why this boundary condition is affecting the test behavior. 2. JDK-8227293: https://bugs.openjdk.java.net/browse/JDK-8227293 TestZoneInfo310.java fails post tzdata2019a integration for Palestine zone rules: There are many hacks and assumptions in the class sun.util.calendar.ZoneInfoFile.java. This issue looks because of the code starting from here: http://hg.openjdk.java.net/jdk/jdk/file/963924f1c891/src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java#l552 There is an assumption where the transition date is >=24,(line 577 and 599) it assumes it is the "last" rule, but it is not last rule in case of Asia/Gaza and Asia/Hebron zones. For now, I have fixed these 2 problematic timezones by overwriting the assumption made on line 577, where date of month dom = startRule.dom; I think, overriding of the second jdk hack on line 599 is not required as the "dom" is calculated from the last rule there. Keeping this bug open as we need to find a generic solution for this issue, without hard-coding the values and adding specific time zone names in exclusion as seen in many places in this class file. - The patch has passed all the related testing including JCK tests. Regards, Ramanand. From peter.levart at gmail.com Fri Jul 5 15:24:57 2019 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 5 Jul 2019 17:24:57 +0200 Subject: Review Request: JDK-8173978: Lookup.in should allow teleporting from a lookup class in a named module without dropping all access In-Reply-To: <76395107-8da7-4bdf-66ec-b5f9f1459284@oracle.com> References: <77478136-29fd-45f9-d122-6826099dfe84@oracle.com> <847246aa-fa7a-5781-a973-5eb021a294e3@oracle.com> <76395107-8da7-4bdf-66ec-b5f9f1459284@oracle.com> Message-ID: Hi Mandy, On 7/2/19 7:20 PM, Mandy Chung wrote: > Webrev updated: > http://cr.openjdk.java.net/~mchung/jdk14/8173978/webrev.01/ I just skimmed across code and I think there's a little optimization possible in VerifyAccess: ?224???????????? // cross-module access ?225???????????? // 1. refc is in different module from lookupModule, or ?226???????????? // 2. refc is in lookupModule and a different module from prevLookupModule ?227???????????? Module prevLookupModule = prevLookupClass != null ? prevLookupClass.getModule() ?228?????????????????????????????????????????????????????????????? : lookupModule; ?229???????????? assert refModule != lookupModule || refModule != prevLookupModule; ?230???????????? if (isModuleAccessible(refc, lookupModule, prevLookupModule)) ?231???????????????? return true; ...instead of seting prevLookupModule to lookupModule in case prevLookupClass is null (common case) causing double canRead and isExported checks against the same module in isModuleAccessible() (for positive outcome - the case where we want the check to be quick): ?250???? public static boolean isModuleAccessible(Class refc,? Module m1, Module m2) { ?251???????? Module refModule = refc.getModule(); ?252???????? assert refModule != m1 || refModule != m2; ?253???????? int mods = getClassModifiers(refc); ?254???????? if (isPublic(mods)) { ?255???????????? if (m1.canRead(refModule) && m2.canRead(refModule)) { ?256???????????????? String pn = refc.getPackageName(); ?257 ?258???????????????? // refc is exported package to at least both m1 and m2 ?259???????????????? if (refModule.isExported(pn, m1) && refModule.isExported(pn, m2)) ?260???????????????????? return true; ?261???????????? } ?262???????? } ?263???????? return false; ?264???? } ...you could set prevLookupModule to null if prevLookupClass is null: ??????????? Module prevLookupModule = prevLookupClass != null ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ????? ? prevLookupClass.getModule() ????????????????????????????????????????????????????????????? : null; ...and then check against null in isModuleAccessible(): ??? public static boolean isModuleAccessible(Class refc, Module m1, Module m2) { ??????? Module refModule = refc.getModule(); ??????? assert refModule != m1 || refModule != m2; ??????? int mods = getClassModifiers(refc); ??????? if (isPublic(mods)) { ??????????? if (m1.canRead(refModule) && (m2 == null || m2.canRead(refModule))) { ??????????????? String pn = refc.getPackageName(); ??????????????? // refc is exported package to at least both m1 and m2 ??????????????? if (refModule.isExported(pn, m1) && (m2 == null || refModule.isExported(pn, m2))) ??????????????????? return true; ??????????? } ??????? } ??????? return false; ??? } I think this would be faster since canRead and isExported are not trivial... Regards, Peter From mandy.chung at oracle.com Fri Jul 5 16:26:44 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 5 Jul 2019 09:26:44 -0700 Subject: Slow performance of StackWalker.getCallerClass() vs Reflection.getCallerClass() In-Reply-To: References: <1082795724.1561886.1562071799378.JavaMail.zimbra@u-pem.fr> Message-ID: <90b11ffe-8fb4-451f-66c2-8ee3550b54cd@oracle.com> On 7/2/19 9:54 PM, Kasper Nielsen wrote: > On Tue, 2 Jul 2019 at 18:50, Mandy Chung wrote: >> I'm not getting how getCallerClass is used and related to access check. >> Can you elaborate? > Caller sensitive methods are viral, in the sense that if you invoke a caller > sensitive method in the JDK, as a library on behalf of a client (without > having a lookup object). You need to perform the same access checks as the JDK > does. That is, checking that the client that calls you - the library - has the > right access rights. The caller sensitive methods in the JDK cannot do this, > because there is no way for them to see that the library is merely a proxy > acting on behalf of a client. > > Consider a very simple serialization library with one method > String serializeToString(Object o) // prints out the value of every field > with an implementation in a module called SER. And two modules M1, M2 that uses > SER (For example, via a ServiceLoader). Both M1 and M2 are open to SER in order > for the serializer to serialize the objects in each of the two modules. > However, M1 and M2 are not open towards each other. So it is not the intention > that, for example, some code from M1 can call it with objects from M2 and have > them serialized or vice versa. However, this is entire possible unless > serializeToString() performs access checks on the caller. All M1 has to do is > get a hold of an object from M2 and then call serializeToString() with it. > There is no way the jdk can check this, it just sees an object from M2 which > is open to SER. It has no idea it is actually M1 trying to serialize it. So > the only way for this to work as intended is for serializeToString to check > that the caller matches the object. And unless you pass around Lookup objects > the only way you can do it, is similar to how the jdk does it; by looking at the > calling class. Reflection::getCallerClass is not available outside of the JDK, > so StackWalker is the only way to do this. > > I've put up an example at https://github.com/kaspernielsen/modulestest. > Calling M2Use.main will serialize an object from M1 even though it M1 is > not open to M2. > > As noted in another thread this gets further complicated because all the access > control code is buried in internal jdk classes. In this example you more or less > have to reimplement AccessibleObject.checkCanSetAccessible yourself. > In the end I don't think it is realistic to expect library developers to get > this right. > M1 and M2 are open to SER.? SER can call `privateLookupIn` to get a lookup on M1's class and then it can use M1's lookup to call accessClass.?? An alternative idea is to have the caller to pass its lookup to serializeToString method to access if the caller lookup object has access to the given object.?? Would that be a plausible solution? Mandy From mandy.chung at oracle.com Fri Jul 5 18:19:32 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 5 Jul 2019 11:19:32 -0700 Subject: Review Request: JDK-8173978: Lookup.in should allow teleporting from a lookup class in a named module without dropping all access In-Reply-To: References: <77478136-29fd-45f9-d122-6826099dfe84@oracle.com> <847246aa-fa7a-5781-a973-5eb021a294e3@oracle.com> <76395107-8da7-4bdf-66ec-b5f9f1459284@oracle.com> Message-ID: <4edca042-a3f9-0a4f-bc1c-a948da0fcf2f@oracle.com> On 7/5/19 8:24 AM, Peter Levart wrote: > Hi Mandy, > > On 7/2/19 7:20 PM, Mandy Chung wrote: >> Webrev updated: >> http://cr.openjdk.java.net/~mchung/jdk14/8173978/webrev.01/ > > I just skimmed across code and I think there's a little optimization > possible in VerifyAccess: > > ?: > ...instead of seting prevLookupModule to lookupModule in case > prevLookupClass is null (common case) causing double canRead and > isExported checks against the same module in isModuleAccessible() (for > positive outcome - the case where we want the check to be quick): > alternatively, keep prevLookupModule = lookupModule if prevLookupClass is null > : > ...and then check against null in isModuleAccessible(): > and skip for the case where m1 == m2 like: ?? public static boolean isModuleAccessible(Class refc, Module m1, Module m2) { ??????? Module refModule = refc.getModule(); ??????? assert refModule != m1 || refModule != m2; ??????? int mods = getClassModifiers(refc); ??????? if (isPublic(mods)) { ??????????? if (m1.canRead(refModule) && (m1 == m2 || m2.canRead(refModule))) { ??????????????? String pn = refc.getPackageName(); ??????????????? // refc is exported package to at least both m1 and m2 ??????????????? if (refModule.isExported(pn, m1) && (m1 == m2 || refModule.isExported(pn, m2))) ??????????????????? return true; ??????????? } ??????? } ??????? return false; ??? } Mandy From peter.levart at gmail.com Fri Jul 5 19:29:30 2019 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 5 Jul 2019 21:29:30 +0200 Subject: Review Request: JDK-8173978: Lookup.in should allow teleporting from a lookup class in a named module without dropping all access In-Reply-To: <4edca042-a3f9-0a4f-bc1c-a948da0fcf2f@oracle.com> References: <77478136-29fd-45f9-d122-6826099dfe84@oracle.com> <847246aa-fa7a-5781-a973-5eb021a294e3@oracle.com> <76395107-8da7-4bdf-66ec-b5f9f1459284@oracle.com> <4edca042-a3f9-0a4f-bc1c-a948da0fcf2f@oracle.com> Message-ID: <9d1efa00-d179-ebc4-42de-dcfd452ea3e9@gmail.com> Hi Mandy, Yes, either way will avoid double canRead/isExported calls against the same module. Although perhaps, an API with null prevModule would be more consistent with other API methods that use null prevLookupClass etc... Regards, Peter On 7/5/19 8:19 PM, Mandy Chung wrote: > > > On 7/5/19 8:24 AM, Peter Levart wrote: >> Hi Mandy, >> >> On 7/2/19 7:20 PM, Mandy Chung wrote: >>> Webrev updated: >>> http://cr.openjdk.java.net/~mchung/jdk14/8173978/webrev.01/ >> >> I just skimmed across code and I think there's a little optimization >> possible in VerifyAccess: >> >> ?: >> ...instead of seting prevLookupModule to lookupModule in case >> prevLookupClass is null (common case) causing double canRead and >> isExported checks against the same module in isModuleAccessible() >> (for positive outcome - the case where we want the check to be quick): >> > alternatively, keep prevLookupModule = lookupModule if prevLookupClass > is null > >> : >> ...and then check against null in isModuleAccessible(): >> > > and skip for the case where m1 == m2 like: > > ?? public static boolean isModuleAccessible(Class refc, Module m1, > Module m2) { > ??????? Module refModule = refc.getModule(); > ??????? assert refModule != m1 || refModule != m2; > ??????? int mods = getClassModifiers(refc); > ??????? if (isPublic(mods)) { > ??????????? if (m1.canRead(refModule) && (m1 == m2 || > m2.canRead(refModule))) { > ??????????????? String pn = refc.getPackageName(); > > ??????????????? // refc is exported package to at least both m1 and m2 > ??????????????? if (refModule.isExported(pn, m1) && (m1 == m2 || > refModule.isExported(pn, m2))) > ??????????????????? return true; > ??????????? } > ??????? } > ??????? return false; > ??? } > > Mandy From jai.forums2013 at gmail.com Sat Jul 6 13:59:03 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sat, 6 Jul 2019 19:29:03 +0530 Subject: Inputs on patch for JDK-8225763? Inflater and Deflater should implement AutoCloseable In-Reply-To: <0d234157-869f-9c95-b3dc-587f989b1551@oracle.com> References: <44582692-a30b-0d54-e550-6277cab95969@gmail.com> <152766d5-72b0-9847-cde2-c89f1d0229d8@gmail.com> <5b1f547f-84da-c8c2-c071-278830e125a2@gmail.com> <0d234157-869f-9c95-b3dc-587f989b1551@oracle.com> Message-ID: Hello Stuart, On 03/07/19 8:57 AM, Stuart Marks wrote: > Hi Jaikiran, > > OK, good analysis. Rather a lot of issues for what seems like a simple > patch, eh? Indeed, but I kind of expected that :) > > ?- Idempotency > > Yes, it looks to me like Inflater.end() and Deflater.end() > implementations are idempotent. As you point out, overrides by > subclasses might not be. We should be clear when we're talking about > the specific implementatations of the end() methods in the Deflater > and Inflater classes, or whether we're talking about the contracts > defined by these method specifications on these classes and subtypes. > > The behavior of an implementation in a class can be specified with > @implSpec without imposing this on the contract of subclasses. This is > useful for subclasses that need to know the exact behavior of calling > super.end(), and also for callers who know they have an instance of a > particular class and not a subclass. > > The upshot is that while we might not have the end() method's contract > specify idempotency, we can certainly say so in an @implSpec, if doing > this will help. I'm not sure we'll actually need it in this case, but > let's keep it in mind. Thank you. Although not for end(), I have now used this @implSpec in the first version of my patch[1]. > > ?- Relationship between end() and close() > > I think close() should have more-or-less the same semantics as end(), > namely, pretty much the way end() is specified now regarding releasing > resources. But it should be allowable to call both in either order. > > ??? try (var inf = new Inflater()) { > ??????? ... > ??????? # explicitly call end() > ??????? inf.end(); > ??? } > > I think this should allowed, but it shouldn't be required. The > application can call either close() or end() and this will have the > effect of releasing the native resources. > Agreed. > A key question is whether close() should be specified to call end() -- > which is subject to being overridden by suclasses -- or whether > close() is defined to do the same thing as the end() implementation in > this class does. This can be implemented by taking the body of the > current end() method and refactoring it into an internal method and > then having both close() and end() call that internal method. > > If close() calls end() then AC+TWR might call close() twice, and > therefore call end() twice, which might be a problem for subclasses. > So to be really conservative we might want to do the internal-method > refactoring to avoid this problem. > > On the other hand, suppose a subclass has extra resources it frees in > its end() method, which then calls super.end(). Even though this class > would inherit AC, using it in TWR would be a *bug* because close() > would call the internal method to free the superclass resources, but > this would leak the subclass resources. That sounds like a mistake to > perpetuate in the API. > > It's possible for a subclass to override end() in such a way that's > not idempotent, but I think this is unlikely. I'm leaning toward > risking the small possibility of incompatibility in declaring end() > idempotent, allowing close() simply to call end(). This makes TWR more > useful in the long run, which seems like a better position to be in. > Of course, if somebody turns up evidence that this would break a bunch > of stuff, we should reconsider. > I thought about this a bit more and I think we should call end() from close() instead of neither doing whatever end() is doing nor extracting out the logic into a private method. The advantage of close() calling end() is, (as you state), it allows the subclasses to correctly cleanup any resources those subclasses are holding on to. Furthermore, I think we can still make it such that the (potentially overridden) end() doesn't get called more than once even if close() gets called multiple times. In the patch[1], I've implemented and documented close() such that it calls end() atmost once. > > ?- Deprecation of end() > > I don't think deprecation of end() is useful. It'll just cause noise > for people. Uses such as > > ??? var deflater = new Deflater(); > ??? try { > ??????? ... > ??? } finally { > ??????? deflater.end(); > ??? } > > are valid and correct and needn't be changed (though using TWR is > preferable, this is more of a style issue). OK and I do agree about the noise the deprecation can cause in this case. > > ?- Undefined behavior after close()/end() > > OK, I'll admit this is possibly out of scope, but the line in the > specs about "once end() is called, the behavior is undefined" rubs me > the wrong way. Right now, most operations seem to call ensureOpen(), > which throws NPE if the object has been closed. But "undefined" allows > anything to happen, including filling the output buffer with garbage. > That seems wrong. We might not want to specify what exception is > thrown, but we might want to specify that *AN* exception is thrown -- > which must be a RuntimeException, since most methods don't declare any > checked exceptions. > > In any case, the clause would have to be updated to say something like > "Once this Deflater (Inflater) is closed, any subsequent operations > will ." In my patch I have attempted to clarify the end() method by taking your input. > > ** > > If you think the issues are settled enough, maybe it's time for you to > take a stab at a patch. The initial version of my patch is now ready at [1]. Here's a high level summary of what's contained in this patch: - The Inflater/Deflater class now implements AutoCloseable - The class level javadoc of both these classes has been to updated to use newer style of code, with try-with-resources, for the example contained in that javadoc. The @apiNote in these class level javadoc has also been updated to mention the use of close() method for releasing resources. - The javadoc of end() method in both these classes has been updated to encourage the use of close() method instead of this one. In addition, this javadoc has also been updated to replace the "undefined behaviour" statement with a mention that the usage of the Inflater/Deflater instance after a call to end() may throw an exception in those subsequent usages. Please note that, there's no such explicit mention in the javadoc of the (newly added) close() method because IMO, it isn't needed for close() since I think it's kind of implied that a closed resource can no longer be used for further operations. - The new close() method has been added along with javadoc which uses an @implSpec to state that it internally calls end() - TotalInOut.java test has been updated to use the new try-with-resources construct for the inflater and deflater it uses. - A couple of new test classes have been added to test various scenarios where close() and end() method get called. These test mostly focus on ensuring that the close() and end(), either implicitly or explicitly, get called the right number of times on the subclasses of Inflater/Deflater. - I have run the tests under test/jdk/java/util/zip/ by running: jtreg -jdk:build/macosx-x86_64-server-release/images/jdk test/jdk/java/util/zip/ and they have come back passing (except for failures/errors in java/util/zip/ZipFile/TestZipFile.java, java/util/zip/3GBZipFiles.sh and java/util/zip/DataDescriptorSignatureMissing.java - those issues though are unrelated to this change and expected to fail, based on what I see in their test report logs) - In addition, I have sneaked in an unrelated change in this patch, into the Deflater.end() method: ???? public void end() { ???????? synchronized (zsRef) { +??????????? // check if already closed +??????????? if (zsRef.address() == 0) { +??????????????? return; +??????????? } ???????????? zsRef.clean(); ???????????? input = ZipUtils.defaultBuf; +??????????? inputArray = null; +??????? } Unlike in the Inflater.end(), the Deflater.end() didn't previously have the "inputArray = null". I have included it in this patch, since it looks right to clean up that array too. If this isn't the right time/patch to do it, please do let me know and I'll take that up separately. Thank you very much for your inputs so far. [1] http://cr.openjdk.java.net/~jpai/webrev/8225763/1/webrev/index.html P.S: I can start a new official RFR thread in this mailing list, if needed. Please do let me know. -Jaikiran > > Note: US holiday weekend coming up; replies might take several days. > > s'marks > > > > > On 6/29/19 4:16 AM, Jaikiran Pai wrote: >> >> On 29/06/19 4:31 PM, Jaikiran Pai wrote: >>> Hello Stuart, >>> >>> Thank you for the detailed response. Comments inline. >>> >>> On 28/06/19 2:48 AM, Stuart Marks wrote: >>>> On 6/26/19 9:28 PM, Jaikiran Pai wrote: >>>>> I am looking to contribute a patch for the enhancement noted in >>>>> https://bugs.openjdk.java.net/browse/JDK-8225763. The change itself >>>>> looks relatively straightforward to me and here's what I plan to do: >>>>> >>>>> 1. Have both java.util.zip.Inflater and java.util.zip.Deflater start >>>>> implementing the AutoCloseable interface >>>>> >>>>> 2. Have the close() method call the end() method >>>>> >>>>> 3. Add javadoc to the close() implementation to mention that the >>>>> end() >>>>> method gets called >>>>> >>>>> 4. Add test(s) to verify that the close indeed actually "ends" the >>>>> inflater/deflater >>>>> >>>>> 5. This is more of a question - do we have to update the class level >>>>> javadoc of both these classes to make a mention that these classes >>>>> have >>>>> started implementing the AutoCloseable starting version 14 (or >>>>> whichever >>>>> version this change makes into) of Java? >>>>> >>>>> Any other inputs/suggestions on what else might be needed in this >>>>> change? >>>> Hi Jaikiran, >>>> >>>> Thanks for picking this up. There are some small wrinkles with this, >>>> but I hope nothing that will prevent it from happening. >>>> >>>> >>>> 2) Alan already mentioned this, but we need to consider the issue of >>>> idempotent close() or end() carefully. It's not strictly required, but >>>> it would be nice. I had taken a quick look at end() and I *thought* it >>>> was idempotent already, but a more careful analysis needs to be done. >>> I did some checks in the current JDK code. From what I see, the >>> Inflater >>> and Deflater do not have any subclasses within the JDK itself. >> >> To be clear - I couldn't find any subclasses in the main source code of >> JDK. There are a couple of subclasses in the tests >> (ConstructInflaterOutput.java and ConstructDeflaterInput.java), but >> those don't do much outside of the context of testing. >> >> -Jaikiran >> >> From jai.forums2013 at gmail.com Sat Jul 6 14:10:39 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sat, 6 Jul 2019 19:40:39 +0530 Subject: Inputs on patch for JDK-8225763? Inflater and Deflater should implement AutoCloseable In-Reply-To: <68D51EE3-869F-4865-A249-6AF321A92E51@oracle.com> References: <44582692-a30b-0d54-e550-6277cab95969@gmail.com> <152766d5-72b0-9847-cde2-c89f1d0229d8@gmail.com> <5b1f547f-84da-c8c2-c071-278830e125a2@gmail.com> <0d234157-869f-9c95-b3dc-587f989b1551@oracle.com> <68D51EE3-869F-4865-A249-6AF321A92E51@oracle.com> Message-ID: <1fbac47d-ceb0-ec7a-bf21-4d6367c2b635@gmail.com> Hello Lance, On 03/07/19 11:27 PM, Lance Andersen wrote: > ?Just a thought below to consider or ignore ;-)? >> On Jul 2, 2019, at 11:27 PM, Stuart Marks > > wrote: >> >> Hi Jaikiran, >> >> OK, good analysis. Rather a lot of issues for what seems like a >> simple patch, eh? >> >> - Idempotency >> >> Yes, it looks to me like Inflater.end() and Deflater.end() >> implementations are idempotent. As you point out, overrides by >> subclasses might not be. We should be clear when we're talking about >> the specific implementatations of the end() methods in the Deflater >> and Inflater classes, or whether we're talking about the contracts >> defined by these method specifications on these classes and subtypes. >> >> The behavior of an implementation in a class can be specified with >> @implSpec without imposing this on the contract of subclasses. This >> is useful for subclasses that need to know the exact behavior of >> calling super.end(), and also for callers who know they have an >> instance of a particular class and not a subclass. >> >> The upshot is that while we might not have the end() method's >> contract specify idempotency, we can certainly say so in an >> @implSpec, if doing this will help. I'm not sure we'll actually need >> it in this case, but let's keep it in mind. >> >> - Subclasses >> >> I don't think there are any subclasses in the JDK, and I did some >> searching and I didn't find any subclasses "in the wild" either. I >> did find a few uses of these classes though. If these classes are >> rarely subclassed, we might be able to get away with changing the >> contract, though this does entail some risk. > > > we could consider ?leaving end() as is and just introduce close() > which while it duplicates what end() does, it ?reduces ?the chance of > any potential complaints. > The issue with that is for subclasses which have their own resource cleanup code solely in their end() method. This will actually be the case for any subclasses that are out there currently. When we introduce close() API and users of Deflater/Inflater start using it, if we duplicate the logic of end() into our close(), then (as noted by Stuart too) the end() method of the subclasses will never get called and will lead to a resource leak of any resources those subclasses are holding onto. >> >> >> - Deprecation of end() > > I don?t think we need to deprecate, just add a note to its javadoc > encouraging the use of close() going forward... Agreed and done in the initial version of the proposed patch http://cr.openjdk.java.net/~jpai/webrev/8225763/1/webrev/index.html -Jaikiran From gnu.andrew at redhat.com Sat Jul 6 16:22:32 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Sat, 6 Jul 2019 17:22:32 +0100 Subject: RFR: 8224560: (tz) Upgrade time-zone data to tzdata2019a and 8225580: tzdata2018i integration causes test failures on jdk-13 In-Reply-To: <0a339591-f5ac-4680-ac70-1a48d8699999@default> References: <0a339591-f5ac-4680-ac70-1a48d8699999@default> Message-ID: On 05/07/2019 15:16, Ramanand Patil wrote: > Hi all, > Please review the patch for tzdata2019a integration into jdk project. > Webrev: http://cr.openjdk.java.net/~rpatil/8224560/webrev.00/ > Bugs: https://bugs.openjdk.java.net/browse/JDK-8224560 > https://bugs.openjdk.java.net/browse/JDK-8225580 > > Summary: > - The fix contains cumulative tzdata changes from tzdata2018i and tzdata2019a, as tzdata2018i was not integrated into jdk/jdk earlier. > - In JDK-13/14, multiple failures were seen during integration of tzdata2018i (JDK-8225580), those are fixed now. Many thanks to Naoto for providing a fix for this in CLDRConverter.java. I would guess this is due to the CLDR update (JDK-8221432: Upgrade CLDR to Version 35.1) in OpenJDK 13, making TimeZone.getAvailableIDs inappropriate in some way? Fix looks good. One minor change: + AVAILABLE_TZIDS = new HashSet(ZoneId.getAvailableZoneIds()); is missing the or <>: + AVAILABLE_TZIDS = new HashSet<>(ZoneId.getAvailableZoneIds()); Will this fix also resolve JDK-8225580? If so, it's probably worth mentioning both bug IDs in the commit. > - There are 2 type of test failures in TestZoneInfo310.java file, which are solved in this patch by providing workarounds, But a permanent fix needs to be added in future for the same. Below are the 2 bugs created to track the development on it: > 1. https://bugs.openjdk.java.net/browse/JDK-8223388: TestZoneInfo310.java fails post tzdata2018i integration: > This failure is seen for the TimeZones which are having zone rules defined till year 2037 or beyond. For now, the failing zones are skipped. > The supporting test class ZoneInfo.java has maxYear defined http://hg.openjdk.java.net/jdk/jdk/file/d01b345865d7/test/jdk/sun/util/calendar/zi/Zoneinfo.java#l40, changing this max value greater than the zone rule's last year also fixes the issue, but further investigation is needed on why this boundary condition is affecting the test behavior. I wonder if 2037 is in someway related to the rollover of 32-bit time values? > 2. JDK-8227293: https://bugs.openjdk.java.net/browse/JDK-8227293 TestZoneInfo310.java fails post tzdata2019a integration for Palestine zone rules: > There are many hacks and assumptions in the class sun.util.calendar.ZoneInfoFile.java. This issue looks because of the code starting from here: http://hg.openjdk.java.net/jdk/jdk/file/963924f1c891/src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java#l552 > There is an assumption where the transition date is >=24,(line 577 and 599) it assumes it is the "last" rule, but it is not last rule in case of Asia/Gaza and Asia/Hebron zones. > For now, I have fixed these 2 problematic timezones by overwriting the assumption made on line 577, where date of month dom = startRule.dom; > I think, overriding of the second jdk hack on line 599 is not required as the "dom" is calculated from the last rule there. Keeping this bug open as we need to find a generic solution for this issue, without hard-coding the values and adding specific time zone names in exclusion as seen in many places in this class file. > > - The patch has passed all the related testing including JCK tests. > > > Regards, > Ramanand. > > > > > Looks good to me, with the above minor adjustment. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From peter.levart at gmail.com Sun Jul 7 14:31:55 2019 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 7 Jul 2019 16:31:55 +0200 Subject: EnumSet.class serialization broken - twice In-Reply-To: References: <323f32f3-c242-c083-4d15-2754a3480730@oracle.com> Message-ID: Hi Stuart, I managed to find some time to tackle this bug. What I found from inspecting the JDK code and experimenting is that it doesn't matter how the private static final long serialVersionUID field is initialized. Whether it is a compile-time constant or its value is computed in , the serialization/deserialization infrastructure acts the same. It is using reflection to obtain the field's value and so it can't distinguish between compile-time constant and computed value. So ypur plan to eliminate serialVersionUID value from the stream of "patched" EnumSet.class object falls apart. I filed a bug [1] and prepared a patch [2] which just adds serialVersionUID to EnumSet and initializes it to the same value that is automatically computed in JDK 8 and before. I had to revert the existing BogusEnumSet test to basically a version that was actual at the time of JDK 8 release, undoing the edits of byte[] value representing serialized stream that have been performed by the same patches that broke the serialization of EnumSet.class objects. I also added a test that verifies the de-serialization of a stream containing EnumSet.class object, produced on JDK 8. Although the patched EnumSet now contains explicit serialVersionUID, serializing EnumSet.class with patched JDK 14 does not procude the same stream, because the stream also contains descriptors of EnumSet fields which changed from version in JDK 8. When deserializing EnumSet.class object, only serialVersionUID from stream is checked against local version though, so this doesn't matter. Considering that this patch breaks serialization between already released 9,10,11,12 versions of JDK and yet to be released versions that would contain the patch, I think the patch should be backported to: - 13 - 11u (11.0.4?) (and possibly to other 9+ update versions yet to be released). This would provide consistent serialization among latest releases of actual versions including JDK 8 and before. Do you think it is necessary to provide a fall-back system property or just advise people to upgrade to latest update release in case they experience trouble? Upgrading to latest update releases is pretty safe these days and should not be a problem for anyone. Regards, Peter [1] https://bugs.openjdk.java.net/browse/JDK-8227368 [2] http://cr.openjdk.java.net/~plevart/jdk-dev/8227368_EnumSet.class_serialization/ On 6/29/19 2:00 AM, Stuart Marks wrote: > Daniel Fuchs pointed me to a weird thing they had to do with the > serialVersionUID in one of the JMX classes: > > https://hg.openjdk.java.net/jdk/jdk/file/c59f36ed7b52/src/java.management/share/classes/javax/management/MBeanAttributeInfo.java#l46 > > > Essentially the svuid for this class initialized in a static block, > and its value is conditional based on the value of some system > property. I don't think using a property is necessary for the EnumSet > case. However, it does point out something interesting, which is that > if the svuid is not initialized with a compile-time constant, and > instead via a static block, the value doesn't appear in > serialized-form.html. > > Thus, we can backport a change to JDK 11 that changes EnumSet's svuid, > without changing the Java SE 11 specification! (This is analogous to > changing a method's implementation to behave the way we want to, > without changing the method's specification to specify that it behaves > that way. On the other hand, this is a really sleazy hack.) > > Here's an outline of what we can do: > > 1) Add EnumSet.serialVersionUID to JDK 13 in the usual way, specifying > a constant that's the same as the JDK 8 value. We are after RDP1 but I > think this change is well-justified. This change should automatically > be propagated to JDK 14. > > 2) "Backport" the fix to JDK 11, but assign the value in a static > initializer block instead of as a constant in a field initializer. > Something like this: > > > diff -r 27d4b8acbe07 src/java.base/share/classes/java/util/EnumSet.java > --- a/src/java.base/share/classes/java/util/EnumSet.java??? Thu Jun 13 > 17:46:57 2019 -0700 > +++ b/src/java.base/share/classes/java/util/EnumSet.java??? Fri Jun 28 > 16:42:03 2019 -0700 > @@ -76,11 +76,18 @@ > ? * @since 1.5 > ? * @see EnumMap > ? */ > - at SuppressWarnings("serial") // No serialVersionUID due to usage of > -??????????????????????????? // serial proxy pattern > + at SuppressWarnings("serial") // serialVersionUID is not a compile-time > constant > ?public abstract class EnumSet> extends AbstractSet > ???? implements Cloneable, java.io.Serializable > ?{ > +??? // Initialize the serialVersionUID to be compatible with JDK 8. > +??? // Do this from a static block to avoid having the value appear > +??? // in serialized-form.html. See JDK-xxxxxxx. > +??? private static final long serialVersionUID; > +??? static { > +??????? serialVersionUID = 1009687484059888093L; > +??? } > + > ???? /** > ????? * The class of all the elements of this set. > ????? */ > > 3) Backport the fix to JDK 12. I'm not sure this is absolutely > necessary, since JDK 12 likely has a short lifetime, but if we're > doing 11 and 13 it makes sense to do 12 as well (though mainly for > completeness). > > 4) It's unclear whether a similar patch as above needs to be added to > JDK 8. Since it already has the right svuid, we could get away without > doing anything. However, with backports continuing in the 8u release > family, it might be prudent to apply this patch in order to prevent > future backports to 8u from inadvertently changing the svuid -- which > as you point out did happen in 9 and 10. > > 5) I don't think we need to patch JDK 1.6, 7, 9, or 10 but the > maintainers of those releases can certainly decide to do so. > > ===== > > In any case, I think doing the above will result in consistent > EnumSet.serialVersionUID values for JDK 8 LTS, JDK 11 LTS, and current > JDK releases, without having to worry about spec changes for any of > the past releases. > > Let me know how you'd like to proceed. I'm happy to help out with > reviewing, filing bugs, CSRs, etc. > > s'marks > > > > > > > On 6/27/19 2:57 PM, Stuart Marks wrote: >> Arrrrrggggh. Yet another serialization bug. >> >> But yes, this is a bug. Thanks for finding and diagnosing it. >> >> Like Martin, I've often forgotten that classes themselves can be >> included in a serial stream, as well as instances of those classes. >> In fact I seem to recall arguing that because EnumSet uses the >> serialization proxy pattern, instances of it should never appear in a >> legitimate serial stream. I think that's true. However, I sent on to >> say that because of this, there is no issue with serialization >> compatibility, and thus EnumSet didn't need a serialVersionUID. >> That's incorrect. >> >> I'm uncomfortable with relaxing the serialization spec and mechanism >> to allow a class in the serial stream to have a different svuid from >> the one loaded in the running JVM. Offhand I don't know what problems >> it could cause, but it seems like a fundamental change that would >> lead to problems at some point. >> >> Also, this is a problem with one class (so far...) and I don't think >> we should change the whole serialization mechanism to support it. >> >> I'm thus leaning toward your first suggestion of adding a >> serialVersionUID declaration to EnumSet that matches the value from >> JDK 8. This would go into the current repo (JDK 14) and likely be >> backported to JDK 13. >> >> It seems like a no-brainer to backport this to JDK 11 as well; this >> would provide broad compatibility across JDK 8 LTS, JDK 11 LTS, and >> current JDK releases. However, changing the svuid is a specification >> change. More investigation is necessary to figure out what would be >> involved in doing this. >> >> Meanwhile, it would seem sensible to file a bug and start on a fix >> for the current release(s). Would you be able to do that? >> >> Again, thanks for finding this. >> >> s'marks >> >> On 6/18/19 7:32 AM, Peter Levart wrote: >>> >>> >>> On 6/18/19 4:00 PM, Martin Buchholz wrote: >>>> Java Historian says: >>>> I was a reviewer for Effective Java 3rd Edition and EnumSet is the >>>> canonical example of the Serialization Proxy pattern, >>>> so I tried to make sure the pattern was implemented as perfectly as >>>> possible. >>>> 8192935: Fix EnumSet's SerializationProxy javadoc >>>> All of us who try to make java serialization work right have a >>>> mental model of the many things that might go wrong. >>>> Serialization of Class objects has never been part of my own mental >>>> model - I've only ever considered instances. >>> >>> Perhaps the necessity for Class objects representing Serializable >>> classes to agree in sertialVersionUID is a bug in Java serialization >>> implementation? There's no such requirement for Class objects >>> representing non-Serializable classes and I don't see why this >>> requirement is there for Serializable classes. Could this >>> requirement simply be relaxed with no ill consequences? >>> >>> Regards, Peter >>> >>>> >>>> >>>> On Tue, Jun 18, 2019 at 5:32 AM Peter Levart >>>> > wrote: >>>> >>>> ??? Hi, >>>> >>>> ??? I recently stumbled on an exception thrown when deserializing >>>> stream >>>> ??? produced on JDK 8 and read with JDK 11. I narrowed the problem >>>> ??? down to >>>> ??? serialization/deserialization of a public EnumSet.class object. >>>> There >>>> ??? were several changes made to EnumSet in the Mercurial history >>>> of jdk >>>> ??? repo, but I think the following two broke the serialization: >>>> >>>> ??? http://hg.openjdk.java.net/jdk/jdk/rev/d0e8542ef650 >>>> ??? http://hg.openjdk.java.net/jdk/jdk/rev/a7e13065a7a0 >>>> >>>> ??? It is interesting to note that before those two changes were made, >>>> ??? there >>>> ??? was a chance to fix the problem reported by newly added serial >>>> lint >>>> ??? warnings. Unfortunately they were just silenced: >>>> >>>> ??? http://hg.openjdk.java.net/jdk/jdk/rev/501d8479f798 >>>> >>>> ??? + at SuppressWarnings("serial") // No serialVersionUID due to >>>> usage of >>>> ??? +??????????????????????????? // serial proxy pattern >>>> >>>> ??? It is true that serialization of instances of Serializable >>>> classes is >>>> ??? not broken by changes to them when they implement serial proxy >>>> ??? pattern >>>> ??? (i.e. writeReplace() method) even if they don't itself declare a >>>> ??? private >>>> ??? static final long serialVersionUID field, but this is not true of >>>> ??? Class >>>> ??? objects representing those Serializable classes. It is even more >>>> ??? controversial that serialization of Class objects representing >>>> ??? non-Serializable classes is never broken (which is >>>> understandable as >>>> ??? they don't have a habit of declaring serialVersionUID fields). >>>> >>>> ??? Both of the above braking changes were made post JDK 8 release, so >>>> ??? deserialization of JDK 8 (and older) streams is affected in all >>>> ??? JDK 9 + >>>> ??? releases or vice versa. >>>> >>>> ??? So, what shall be done. I suggest adding serialVersionUID field to >>>> ??? EnumSet vith a value that corresponds to JDK 8 serialization >>>> ??? format and >>>> ??? later backport this change to JDK 11. >>>> >>>> ??? What do you think? >>>> >>>> >>>> ??? Regards, Peter >>>> >>>> >>>> ??? PS: ImmutableCollections nested classes also implement serial >>>> proxy >>>> ??? pattern and don't declare serialVersionUID fields, but they are >>>> not >>>> ??? public, so it is less chance that Class objects representing them >>>> ??? could >>>> ??? be used in serial streams, although it is not impossible. For >>>> example: >>>> >>>> ??? objectOutputStream.writeObject(Set.of().getClass()); >>>> >>> From peter.levart at gmail.com Sun Jul 7 15:11:50 2019 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 7 Jul 2019 17:11:50 +0200 Subject: EnumSet.class serialization broken - twice In-Reply-To: References: <323f32f3-c242-c083-4d15-2754a3480730@oracle.com> Message-ID: <812af6a1-6836-2f51-ab18-ba9b202b0547@gmail.com> On 7/7/19 4:31 PM, Peter Levart wrote: > On 6/29/19 2:00 AM, Stuart Marks wrote: >> Daniel Fuchs pointed me to a weird thing they had to do with the >> serialVersionUID in one of the JMX classes: >> >> https://hg.openjdk.java.net/jdk/jdk/file/c59f36ed7b52/src/java.management/share/classes/javax/management/MBeanAttributeInfo.java#l46 >> >> >> Essentially the svuid for this class initialized in a static block, >> and its value is conditional based on the value of some system >> property. I don't think using a property is necessary for the EnumSet >> case. However, it does point out something interesting, which is that >> if the svuid is not initialized with a compile-time constant, and >> instead via a static block, the value doesn't appear in >> serialized-form.html. Hi Stuart, I just realized that I was reading your last statement wrong. I though it was written as: ...if the svuid is not initialized with a compile-time constant, and instead via a static block, the value doesn't appear in serialized form. And not as: ...if the svuid is not initialized with a compile-time constant, and instead via a static block, the value doesn't appear in serialized-form.html You were only concerned about the generated javadoc and not about the actual "serialized form". Ok, I get it now. I have prepared webrev.02 to fix this. Regards, Peter From ramanand.patil at oracle.com Mon Jul 8 10:35:03 2019 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Mon, 8 Jul 2019 03:35:03 -0700 (PDT) Subject: RFR: 8224560: (tz) Upgrade time-zone data to tzdata2019a and 8225580: tzdata2018i integration causes test failures on jdk-13 In-Reply-To: References: <0a339591-f5ac-4680-ac70-1a48d8699999@default> Message-ID: Hi Andrew, Thank you for your review. Updated webrev: http://cr.openjdk.java.net/~rpatil/8224560/webrev.01/ Regards, Ramanand. > -----Original Message----- > From: Andrew John Hughes > Sent: Saturday, July 6, 2019 9:53 PM > To: Ramanand Patil ; core-libs- > dev at openjdk.java.net; i18n-dev at openjdk.java.net > Subject: Re: RFR: 8224560: (tz) Upgrade time-zone data to > tzdata2019a and 8225580: tzdata2018i integration causes test failures on jdk- > 13 > > > > On 05/07/2019 15:16, Ramanand Patil wrote: > > Hi all, > > Please review the patch for tzdata2019a integration into jdk project. > > Webrev: http://cr.openjdk.java.net/~rpatil/8224560/webrev.00/ > > Bugs: https://bugs.openjdk.java.net/browse/JDK-8224560 > > https://bugs.openjdk.java.net/browse/JDK-8225580 > > > > Summary: > > - The fix contains cumulative tzdata changes from tzdata2018i and > tzdata2019a, as tzdata2018i was not integrated into jdk/jdk earlier. > > - In JDK-13/14, multiple failures were seen during integration of tzdata2018i > (JDK-8225580), those are fixed now. Many thanks to Naoto for providing a fix > for this in CLDRConverter.java. > > I would guess this is due to the CLDR update (JDK-8221432: Upgrade CLDR to > Version 35.1) in OpenJDK 13, making TimeZone.getAvailableIDs > inappropriate in some way? > > Fix looks good. One minor change: > > + AVAILABLE_TZIDS = new > + HashSet(ZoneId.getAvailableZoneIds()); > > is missing the or <>: > > + AVAILABLE_TZIDS = new > + HashSet<>(ZoneId.getAvailableZoneIds()); > > Will this fix also resolve JDK-8225580? If so, it's probably worth mentioning > both bug IDs in the commit. Yes, this fix will also resolve JDK-8225580, hence included in the subject line. And thank you, I will add both bug IDs in the commit message. > > > - There are 2 type of test failures in TestZoneInfo310.java file, which are > solved in this patch by providing workarounds, But a permanent fix needs to > be added in future for the same. Below are the 2 bugs created to track the > development on it: > > 1. https://bugs.openjdk.java.net/browse/JDK-8223388: > TestZoneInfo310.java fails post tzdata2018i integration: > > This failure is seen for the TimeZones which are having zone rules defined > till year 2037 or beyond. For now, the failing zones are skipped. > > The supporting test class ZoneInfo.java has maxYear defined > http://hg.openjdk.java.net/jdk/jdk/file/d01b345865d7/test/jdk/sun/util/cale > ndar/zi/Zoneinfo.java#l40, changing this max value greater than the zone > rule's last year also fixes the issue, but further investigation is needed on why > this boundary condition is affecting the test behavior. > > I wonder if 2037 is in someway related to the rollover of 32-bit time values? I think, not directly related but how the test and JDK handles these values. In JDK, the transitions beyond 2037 are delegated to SimpleTimeZone, and I think the test somehow miscalculates it. http://hg.openjdk.java.net/jdk/jdk/file/5919b273def6/src/java.base/share/classes/sun/util/calendar/ZoneInfo.java#l48 I think, I should re-visit and see if these test are really needed now. As per the long standing bug JDK-8166983 suggestion was to remove the whole tests from test/sun/util/calendar/zi > > > 2. JDK-8227293: https://bugs.openjdk.java.net/browse/JDK-8227293 > TestZoneInfo310.java fails post tzdata2019a integration for Palestine zone > rules: > > There are many hacks and assumptions in the class > > sun.util.calendar.ZoneInfoFile.java. This issue looks because of the > > code starting from here: > > http://hg.openjdk.java.net/jdk/jdk/file/963924f1c891/src/java.base/sha > > re/classes/sun/util/calendar/ZoneInfoFile.java#l552 > > There is an assumption where the transition date is >=24,(line 577 and 599) > it assumes it is the "last" rule, but it is not last rule in case of Asia/Gaza and > Asia/Hebron zones. > > For now, I have fixed these 2 problematic timezones by overwriting the > > assumption made on line 577, where date of month dom = startRule.dom; I > think, overriding of the second jdk hack on line 599 is not required as the > "dom" is calculated from the last rule there. Keeping this bug open as we > need to find a generic solution for this issue, without hard-coding the values > and adding specific time zone names in exclusion as seen in many places in > this class file. > > > > - The patch has passed all the related testing including JCK tests. > > > > > > Regards, > > Ramanand. > > > > > > > > > > > > Looks good to me, with the above minor adjustment. > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint > = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew > From lance.andersen at oracle.com Mon Jul 8 17:46:51 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 8 Jul 2019 13:46:51 -0400 Subject: Inputs on patch for JDK-8225763? Inflater and Deflater should implement AutoCloseable In-Reply-To: References: <44582692-a30b-0d54-e550-6277cab95969@gmail.com> <152766d5-72b0-9847-cde2-c89f1d0229d8@gmail.com> <5b1f547f-84da-c8c2-c071-278830e125a2@gmail.com> <0d234157-869f-9c95-b3dc-587f989b1551@oracle.com> Message-ID: Hi Jaikiran, Thank you for your efforts here. > On Jul 6, 2019, at 9:59 AM, Jaikiran Pai wrote: > >> >> - Idempotency >> >> Yes, it looks to me like Inflater.end() and Deflater.end() >> implementations are idempotent. As you point out, overrides by >> subclasses might not be. We should be clear when we're talking about >> the specific implementatations of the end() methods in the Deflater >> and Inflater classes, or whether we're talking about the contracts >> defined by these method specifications on these classes and subtypes. >> >> The behavior of an implementation in a class can be specified with >> @implSpec without imposing this on the contract of subclasses. This is >> useful for subclasses that need to know the exact behavior of calling >> super.end(), and also for callers who know they have an instance of a >> particular class and not a subclass. >> >> The upshot is that while we might not have the end() method's contract >> specify idempotency, we can certainly say so in an @implSpec, if doing >> this will help. I'm not sure we'll actually need it in this case, but >> let's keep it in mind. > > Thank you. Although not for end(), I have now used this @implSpec in the > first version of my patch[1]. This should be done for end() as well to set expectations. While close() is the preferred way to go moving forward, end() is not going anywhere and still needs to be a first class-citizen WRT documentation. > > >> >> - Relationship between end() and close() >> >> I think close() should have more-or-less the same semantics as end(), >> namely, pretty much the way end() is specified now regarding releasing >> resources. But it should be allowable to call both in either order. >> >> try (var inf = new Inflater()) { >> ... >> # explicitly call end() >> inf.end(); >> } >> >> I think this should allowed, but it shouldn't be required. The >> application can call either close() or end() and this will have the >> effect of releasing the native resources. >> > Agreed. > > >> A key question is whether close() should be specified to call end() -- >> which is subject to being overridden by suclasses -- or whether >> close() is defined to do the same thing as the end() implementation in >> this class does. This can be implemented by taking the body of the >> current end() method and refactoring it into an internal method and >> then having both close() and end() call that internal method. >> >> If close() calls end() then AC+TWR might call close() twice, and >> therefore call end() twice, which might be a problem for subclasses. >> So to be really conservative we might want to do the internal-method >> refactoring to avoid this problem. >> >> On the other hand, suppose a subclass has extra resources it frees in >> its end() method, which then calls super.end(). Even though this class >> would inherit AC, using it in TWR would be a *bug* because close() >> would call the internal method to free the superclass resources, but >> this would leak the subclass resources. That sounds like a mistake to >> perpetuate in the API. >> >> It's possible for a subclass to override end() in such a way that's >> not idempotent, but I think this is unlikely. I'm leaning toward >> risking the small possibility of incompatibility in declaring end() >> idempotent, allowing close() simply to call end(). This makes TWR more >> useful in the long run, which seems like a better position to be in. >> Of course, if somebody turns up evidence that this would break a bunch >> of stuff, we should reconsider. >> > I thought about this a bit more and I think we should call end() from > close() instead of neither doing whatever end() is doing nor extracting > out the logic into a private method. The advantage of close() calling > end() is, (as you state), it allows the subclasses to correctly cleanup > any resources those subclasses are holding on to. Furthermore, I think > we can still make it such that the (potentially overridden) end() > doesn't get called more than once even if close() gets called multiple > times. > > In the patch[1], I've implemented and documented close() such that it > calls end() atmost once. > > >> >> - Deprecation of end() >> >> I don't think deprecation of end() is useful. It'll just cause noise >> for people. Uses such as >> >> var deflater = new Deflater(); >> try { >> ... >> } finally { >> deflater.end(); >> } >> >> are valid and correct and needn't be changed (though using TWR is >> preferable, this is more of a style issue). > > OK and I do agree about the noise the deprecation can cause in this case. > > >> >> - Undefined behavior after close()/end() >> >> OK, I'll admit this is possibly out of scope, but the line in the >> specs about "once end() is called, the behavior is undefined" rubs me >> the wrong way. Right now, most operations seem to call ensureOpen(), >> which throws NPE if the object has been closed. But "undefined" allows >> anything to happen, including filling the output buffer with garbage. >> That seems wrong. We might not want to specify what exception is >> thrown, but we might want to specify that *AN* exception is thrown -- >> which must be a RuntimeException, since most methods don't declare any >> checked exceptions. >> >> In any case, the clause would have to be updated to say something like >> "Once this Deflater (Inflater) is closed, any subsequent operations >> will ." > In my patch I have attempted to clarify the end() method by taking your > input. >> >> ** >> >> If you think the issues are settled enough, maybe it's time for you to >> take a stab at a patch. > > The initial version of my patch is now ready at [1]. Here's a high level > summary of what's contained in this patch: Please start a review request thread so it is easier to follow. Once you do that, I will reply to it.. Also, reminder to update copyright dates. For the tests, it would be best to add more comments. Out of curiosity, was there a reason you chose not to use TestNG vs having just a main which invokes each test? > > - The Inflater/Deflater class now implements AutoCloseable > > - The class level javadoc of both these classes has been to updated to > use newer style of code, with try-with-resources, for the example > contained in that javadoc. The @apiNote in these class level javadoc has > also been updated to mention the use of close() method for releasing > resources. > > - The javadoc of end() method in both these classes has been updated to > encourage the use of close() method instead of this one. In addition, > this javadoc has also been updated to replace the "undefined behaviour" > statement with a mention that the usage of the Inflater/Deflater > instance after a call to end() may throw an exception in those > subsequent usages. Please note that, there's no such explicit mention in > the javadoc of the (newly added) close() method because IMO, it isn't > needed for close() since I think it's kind of implied that a closed > resource can no longer be used for further operations. > > - The new close() method has been added along with javadoc which uses an > @implSpec to state that it internally calls end() > > - TotalInOut.java test has been updated to use the new > try-with-resources construct for the inflater and deflater it uses. > > - A couple of new test classes have been added to test various scenarios > where close() and end() method get called. These test mostly focus on > ensuring that the close() and end(), either implicitly or explicitly, > get called the right number of times on the subclasses of Inflater/Deflater. > > - I have run the tests under test/jdk/java/util/zip/ by running: > > jtreg -jdk:build/macosx-x86_64-server-release/images/jdk > test/jdk/java/util/zip/ > > and they have come back passing (except for failures/errors in > java/util/zip/ZipFile/TestZipFile.java, java/util/zip/3GBZipFiles.sh and > java/util/zip/DataDescriptorSignatureMissing.java - those issues though > are unrelated to this change and expected to fail, based on what I see > in their test report logs) > > - In addition, I have sneaked in an unrelated change in this patch, into > the Deflater.end() method: > > public void end() { > synchronized (zsRef) { > + // check if already closed > + if (zsRef.address() == 0) { > + return; > + } > zsRef.clean(); > input = ZipUtils.defaultBuf; > + inputArray = null; > + } > > Unlike in the Inflater.end(), the Deflater.end() didn't previously have > the "inputArray = null". I have included it in this patch, since it > looks right to clean up that array too. If this isn't the right > time/patch to do it, please do let me know and I'll take that up separately. > > Thank you very much for your inputs so far. > > [1] http://cr.openjdk.java.net/~jpai/webrev/8225763/1/webrev/index.html > > P.S: I can start a new official RFR thread in this mailing list, if > needed. Please do let me know. > > -Jaikiran > > >> >> Note: US holiday weekend coming up; replies might take several days. >> >> s'marks >> >> >> >> >> On 6/29/19 4:16 AM, Jaikiran Pai wrote: >>> >>> On 29/06/19 4:31 PM, Jaikiran Pai wrote: >>>> Hello Stuart, >>>> >>>> Thank you for the detailed response. Comments inline. >>>> >>>> On 28/06/19 2:48 AM, Stuart Marks wrote: >>>>> On 6/26/19 9:28 PM, Jaikiran Pai wrote: >>>>>> I am looking to contribute a patch for the enhancement noted in >>>>>> https://bugs.openjdk.java.net/browse/JDK-8225763. The change itself >>>>>> looks relatively straightforward to me and here's what I plan to do: >>>>>> >>>>>> 1. Have both java.util.zip.Inflater and java.util.zip.Deflater start >>>>>> implementing the AutoCloseable interface >>>>>> >>>>>> 2. Have the close() method call the end() method >>>>>> >>>>>> 3. Add javadoc to the close() implementation to mention that the >>>>>> end() >>>>>> method gets called >>>>>> >>>>>> 4. Add test(s) to verify that the close indeed actually "ends" the >>>>>> inflater/deflater >>>>>> >>>>>> 5. This is more of a question - do we have to update the class level >>>>>> javadoc of both these classes to make a mention that these classes >>>>>> have >>>>>> started implementing the AutoCloseable starting version 14 (or >>>>>> whichever >>>>>> version this change makes into) of Java? >>>>>> >>>>>> Any other inputs/suggestions on what else might be needed in this >>>>>> change? >>>>> Hi Jaikiran, >>>>> >>>>> Thanks for picking this up. There are some small wrinkles with this, >>>>> but I hope nothing that will prevent it from happening. >>>>> >>>>> >>>>> 2) Alan already mentioned this, but we need to consider the issue of >>>>> idempotent close() or end() carefully. It's not strictly required, but >>>>> it would be nice. I had taken a quick look at end() and I *thought* it >>>>> was idempotent already, but a more careful analysis needs to be done. >>>> I did some checks in the current JDK code. From what I see, the >>>> Inflater >>>> and Deflater do not have any subclasses within the JDK itself. >>> >>> To be clear - I couldn't find any subclasses in the main source code of >>> JDK. There are a couple of subclasses in the tests >>> (ConstructInflaterOutput.java and ConstructDeflaterInput.java), but >>> those don't do much outside of the context of testing. >>> >>> -Jaikiran Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From naoto.sato at oracle.com Mon Jul 8 17:49:01 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 8 Jul 2019 10:49:01 -0700 Subject: RFR: 8224560: (tz) Upgrade time-zone data to tzdata2019a and 8225580: tzdata2018i integration causes test failures on jdk-13 In-Reply-To: References: <0a339591-f5ac-4680-ac70-1a48d8699999@default> Message-ID: <52bdd34c-67b4-7e50-c555-15e49f250b0c@oracle.com> Hi Ramanand, As to the change in ZoneInfoFile.java, I would put that special handling of Gaza/Hebron in line 577, as well as merging the comment in 575,576, so that it won't duplicate the code. Otherwise looks good. Naoto On 7/8/19 3:35 AM, Ramanand Patil wrote: > Hi Andrew, > Thank you for your review. > Updated webrev: http://cr.openjdk.java.net/~rpatil/8224560/webrev.01/ > > Regards, > Ramanand. > >> -----Original Message----- >> From: Andrew John Hughes >> Sent: Saturday, July 6, 2019 9:53 PM >> To: Ramanand Patil ; core-libs- >> dev at openjdk.java.net; i18n-dev at openjdk.java.net >> Subject: Re: RFR: 8224560: (tz) Upgrade time-zone data to >> tzdata2019a and 8225580: tzdata2018i integration causes test failures on jdk- >> 13 >> >> >> >> On 05/07/2019 15:16, Ramanand Patil wrote: >>> Hi all, >>> Please review the patch for tzdata2019a integration into jdk project. >>> Webrev: http://cr.openjdk.java.net/~rpatil/8224560/webrev.00/ >>> Bugs: https://bugs.openjdk.java.net/browse/JDK-8224560 >>> https://bugs.openjdk.java.net/browse/JDK-8225580 >>> >>> Summary: >>> - The fix contains cumulative tzdata changes from tzdata2018i and >> tzdata2019a, as tzdata2018i was not integrated into jdk/jdk earlier. >>> - In JDK-13/14, multiple failures were seen during integration of tzdata2018i >> (JDK-8225580), those are fixed now. Many thanks to Naoto for providing a fix >> for this in CLDRConverter.java. >> >> I would guess this is due to the CLDR update (JDK-8221432: Upgrade CLDR to >> Version 35.1) in OpenJDK 13, making TimeZone.getAvailableIDs >> inappropriate in some way? >> >> Fix looks good. One minor change: >> >> + AVAILABLE_TZIDS = new >> + HashSet(ZoneId.getAvailableZoneIds()); >> >> is missing the or <>: >> >> + AVAILABLE_TZIDS = new >> + HashSet<>(ZoneId.getAvailableZoneIds()); >> >> Will this fix also resolve JDK-8225580? If so, it's probably worth mentioning >> both bug IDs in the commit. > Yes, this fix will also resolve JDK-8225580, hence included in the subject line. > And thank you, I will add both bug IDs in the commit message. >> >>> - There are 2 type of test failures in TestZoneInfo310.java file, which are >> solved in this patch by providing workarounds, But a permanent fix needs to >> be added in future for the same. Below are the 2 bugs created to track the >> development on it: >>> 1. https://bugs.openjdk.java.net/browse/JDK-8223388: >> TestZoneInfo310.java fails post tzdata2018i integration: >>> This failure is seen for the TimeZones which are having zone rules defined >> till year 2037 or beyond. For now, the failing zones are skipped. >>> The supporting test class ZoneInfo.java has maxYear defined >> http://hg.openjdk.java.net/jdk/jdk/file/d01b345865d7/test/jdk/sun/util/cale >> ndar/zi/Zoneinfo.java#l40, changing this max value greater than the zone >> rule's last year also fixes the issue, but further investigation is needed on why >> this boundary condition is affecting the test behavior. >> >> I wonder if 2037 is in someway related to the rollover of 32-bit time values? > I think, not directly related but how the test and JDK handles these values. > In JDK, the transitions beyond 2037 are delegated to SimpleTimeZone, and I think the test somehow miscalculates it. > http://hg.openjdk.java.net/jdk/jdk/file/5919b273def6/src/java.base/share/classes/sun/util/calendar/ZoneInfo.java#l48 > I think, I should re-visit and see if these test are really needed now. As per the long standing bug JDK-8166983 suggestion was to remove the whole tests from test/sun/util/calendar/zi >> >>> 2. JDK-8227293: https://bugs.openjdk.java.net/browse/JDK-8227293 >> TestZoneInfo310.java fails post tzdata2019a integration for Palestine zone >> rules: >>> There are many hacks and assumptions in the class >>> sun.util.calendar.ZoneInfoFile.java. This issue looks because of the >>> code starting from here: >>> http://hg.openjdk.java.net/jdk/jdk/file/963924f1c891/src/java.base/sha >>> re/classes/sun/util/calendar/ZoneInfoFile.java#l552 >>> There is an assumption where the transition date is >=24,(line 577 and 599) >> it assumes it is the "last" rule, but it is not last rule in case of Asia/Gaza and >> Asia/Hebron zones. >>> For now, I have fixed these 2 problematic timezones by overwriting the >>> assumption made on line 577, where date of month dom = startRule.dom; I >> think, overriding of the second jdk hack on line 599 is not required as the >> "dom" is calculated from the last rule there. Keeping this bug open as we >> need to find a generic solution for this issue, without hard-coding the values >> and adding specific time zone names in exclusion as seen in many places in >> this class file. >>> >>> - The patch has passed all the related testing including JCK tests. >>> >>> >>> Regards, >>> Ramanand. >>> >>> >>> >>> >>> >> >> Looks good to me, with the above minor adjustment. >> >> Thanks, >> -- >> Andrew :) >> >> Senior Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint >> = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 >> https://keybase.io/gnu_andrew >> From brian.burkhalter at oracle.com Mon Jul 8 20:11:01 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 8 Jul 2019 13:11:01 -0700 Subject: 8193072: File.delete() should remove its path from DeleteOnExitHook.files Message-ID: <9608451A-321D-4CD7-9DD9-04524AC4F53D@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8193072 There does appear to be a memory leak of sorts if one does something like ? File[] files; for (int i = 0; i < largeNumber; i++) { files[i] = File.createTempFile(?blah?, null); files[i].deleteOnExit(); } // do something for (int i = 0; i < largeNumber; i++) { files[i].delete(); } // do something else before shutdown ? The LinkedHashSet in DeleteOnExitHook will contain at least largeNumber Files until the VM shuts down even though the files were deleted. The potential change is included below. The additional call to DeleteOnExitHook.remove() in File.delete() does not appear to have a measurable performance impact, at least trivially and in isolation. Thanks, Brian --- a/src/java.base/share/classes/java/io/DeleteOnExitHook.java +++ b/src/java.base/share/classes/java/io/DeleteOnExitHook.java @@ -64,6 +64,15 @@ files.add(file); } + static synchronized void remove(String file) { + if(files == null) { + // DeleteOnExitHook is running. Too late to remove a file + throw new IllegalStateException("Shutdown in progress"); + } + + files.remove(file); + } + static void runHooks() { LinkedHashSet theFiles; --- a/src/java.base/share/classes/java/io/File.java +++ b/src/java.base/share/classes/java/io/File.java @@ -1050,6 +1050,7 @@ if (isInvalid()) { return false; } + DeleteOnExitHook.remove(path); return fs.delete(this); } From lance.andersen at oracle.com Mon Jul 8 20:30:30 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 8 Jul 2019 16:30:30 -0400 Subject: 8193072: File.delete() should remove its path from DeleteOnExitHook.files In-Reply-To: <9608451A-321D-4CD7-9DD9-04524AC4F53D@oracle.com> References: <9608451A-321D-4CD7-9DD9-04524AC4F53D@oracle.com> Message-ID: Looks OK brian and does not seem to require any update to runHooks() so all good for me :-) > On Jul 8, 2019, at 4:11 PM, Brian Burkhalter wrote: > > https://bugs.openjdk.java.net/browse/JDK-8193072 > > There does appear to be a memory leak of sorts if one does something like > > ? > > File[] files; > for (int i = 0; i < largeNumber; i++) { > files[i] = File.createTempFile(?blah?, null); > files[i].deleteOnExit(); > } > > // do something > > for (int i = 0; i < largeNumber; i++) { > files[i].delete(); > } > > // do something else before shutdown > > ? > > The LinkedHashSet in DeleteOnExitHook will contain at least largeNumber Files until the VM shuts down even though the files were deleted. > > The potential change is included below. The additional call to DeleteOnExitHook.remove() in File.delete() does not appear to have a measurable performance impact, at least trivially and in isolation. > > Thanks, > > Brian > > --- a/src/java.base/share/classes/java/io/DeleteOnExitHook.java > +++ b/src/java.base/share/classes/java/io/DeleteOnExitHook.java > @@ -64,6 +64,15 @@ > files.add(file); > } > > + static synchronized void remove(String file) { > + if(files == null) { > + // DeleteOnExitHook is running. Too late to remove a file > + throw new IllegalStateException("Shutdown in progress"); > + } > + > + files.remove(file); > + } > + > static void runHooks() { > LinkedHashSet theFiles; > > --- a/src/java.base/share/classes/java/io/File.java > +++ b/src/java.base/share/classes/java/io/File.java > @@ -1050,6 +1050,7 @@ > if (isInvalid()) { > return false; > } > + DeleteOnExitHook.remove(path); > return fs.delete(this); > } > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From ivan.gerasimov at oracle.com Mon Jul 8 20:35:35 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 8 Jul 2019 13:35:35 -0700 Subject: 8193072: File.delete() should remove its path from DeleteOnExitHook.files In-Reply-To: <9608451A-321D-4CD7-9DD9-04524AC4F53D@oracle.com> References: <9608451A-321D-4CD7-9DD9-04524AC4F53D@oracle.com> Message-ID: <0525c4cf-4a02-1f9b-2950-a0750cbf4a48@oracle.com> Hi Brian! I believe this would introduce a behavior change in a scenario lile: File f = ...; f.deleteOnExit(); f.delete(); f.createNewFile(); I.e. when the with the same name is recreated.? Current behavior is to unlink such a file before exiting, no matter if it were explicitly deleted and then recreated or not. With kind regards, Ivan On 7/8/19 1:11 PM, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8193072 > > There does appear to be a memory leak of sorts if one does something like > > ? > > File[] files; > for (int i = 0; i < largeNumber; i++) { > files[i] = File.createTempFile(?blah?, null); > files[i].deleteOnExit(); > } > > // do something > > for (int i = 0; i < largeNumber; i++) { > files[i].delete(); > } > > // do something else before shutdown > > ? > > The LinkedHashSet in DeleteOnExitHook will contain at least largeNumber Files until the VM shuts down even though the files were deleted. > > The potential change is included below. The additional call to DeleteOnExitHook.remove() in File.delete() does not appear to have a measurable performance impact, at least trivially and in isolation. > > Thanks, > > Brian > > --- a/src/java.base/share/classes/java/io/DeleteOnExitHook.java > +++ b/src/java.base/share/classes/java/io/DeleteOnExitHook.java > @@ -64,6 +64,15 @@ > files.add(file); > } > > + static synchronized void remove(String file) { > + if(files == null) { > + // DeleteOnExitHook is running. Too late to remove a file > + throw new IllegalStateException("Shutdown in progress"); > + } > + > + files.remove(file); > + } > + > static void runHooks() { > LinkedHashSet theFiles; > > --- a/src/java.base/share/classes/java/io/File.java > +++ b/src/java.base/share/classes/java/io/File.java > @@ -1050,6 +1050,7 @@ > if (isInvalid()) { > return false; > } > + DeleteOnExitHook.remove(path); > return fs.delete(this); > } > > -- With kind regards, Ivan Gerasimov From jason_mehrens at hotmail.com Mon Jul 8 20:53:59 2019 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Mon, 8 Jul 2019 20:53:59 +0000 Subject: 8193072: File.delete() should remove its path from DeleteOnExitHook.files In-Reply-To: <9608451A-321D-4CD7-9DD9-04524AC4F53D@oracle.com> References: <9608451A-321D-4CD7-9DD9-04524AC4F53D@oracle.com> Message-ID: Brian, Previously File.delete wouldn't throw IllegalStateException and with this patch it looks like that is possible (and not desirable). I would think that this change could the break java.util.logging.FileHandler because Handler.close runs in a shutdown hook. Jason ________________________________________ From: core-libs-dev on behalf of Brian Burkhalter Sent: Monday, July 8, 2019 3:11 PM To: core-libs-dev Subject: 8193072: File.delete() should remove its path from DeleteOnExitHook.files https://bugs.openjdk.java.net/browse/JDK-8193072 There does appear to be a memory leak of sorts if one does something like ? File[] files; for (int i = 0; i < largeNumber; i++) { files[i] = File.createTempFile(?blah?, null); files[i].deleteOnExit(); } // do something for (int i = 0; i < largeNumber; i++) { files[i].delete(); } // do something else before shutdown ? The LinkedHashSet in DeleteOnExitHook will contain at least largeNumber Files until the VM shuts down even though the files were deleted. The potential change is included below. The additional call to DeleteOnExitHook.remove() in File.delete() does not appear to have a measurable performance impact, at least trivially and in isolation. Thanks, Brian --- a/src/java.base/share/classes/java/io/DeleteOnExitHook.java +++ b/src/java.base/share/classes/java/io/DeleteOnExitHook.java @@ -64,6 +64,15 @@ files.add(file); } + static synchronized void remove(String file) { + if(files == null) { + // DeleteOnExitHook is running. Too late to remove a file + throw new IllegalStateException("Shutdown in progress"); + } + + files.remove(file); + } + static void runHooks() { LinkedHashSet theFiles; --- a/src/java.base/share/classes/java/io/File.java +++ b/src/java.base/share/classes/java/io/File.java @@ -1050,6 +1050,7 @@ if (isInvalid()) { return false; } + DeleteOnExitHook.remove(path); return fs.delete(this); } From brian.burkhalter at oracle.com Mon Jul 8 21:08:36 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 8 Jul 2019 14:08:36 -0700 Subject: 8193072: File.delete() should remove its path from DeleteOnExitHook.files In-Reply-To: <0525c4cf-4a02-1f9b-2950-a0750cbf4a48@oracle.com> References: <9608451A-321D-4CD7-9DD9-04524AC4F53D@oracle.com> <0525c4cf-4a02-1f9b-2950-a0750cbf4a48@oracle.com> Message-ID: Ivan / Jason, Thanks for the good observations. > On Jul 8, 2019, at 1:35 PM, Ivan Gerasimov wrote: > > I believe this would introduce a behavior change in a scenario lile: > File f = ...; > f.deleteOnExit(); > f.delete(); > f.createNewFile(); > > I.e. when the with the same name is recreated. Current behavior is to unlink such a file before exiting, no matter if it were explicitly deleted and then recreated or not. Good point. Given this consideration I am not sure that this bug can be fixed. > On Jul 8, 2019, at 1:53 PM, Jason Mehrens wrote: > > Previously File.delete wouldn't throw IllegalStateException and with this patch it looks like that is possible (and not desirable). I would think that this change could the break java.util.logging.FileHandler because Handler.close runs in a shutdown hook. I think you are correct that the ISE should not be thrown. Thanks, Brian From naoto.sato at oracle.com Mon Jul 8 22:11:56 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 8 Jul 2019 15:11:56 -0700 Subject: [13] RFR: 8227127: Era designator not displayed correctly using the COMPAT provider Message-ID: <259bb4e9-b4ba-cde8-d2ff-afcb460866c3@oracle.com> Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8227127 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8227127/webrev.00/ This is a regression caused by the fix to 8039301, where era display names are correctly retrieved with styles. This revealed that the short names for Gregorian eras are missing in COMPAT locale provider. Providing the proper display names in its resource bundles fixes the issue. Naoto From stuart.marks at oracle.com Mon Jul 8 23:57:16 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 8 Jul 2019 16:57:16 -0700 Subject: EnumSet.class serialization broken - twice - JDK-8227368 In-Reply-To: <812af6a1-6836-2f51-ab18-ba9b202b0547@gmail.com> References: <323f32f3-c242-c083-4d15-2754a3480730@oracle.com> <812af6a1-6836-2f51-ab18-ba9b202b0547@gmail.com> Message-ID: <72b10257-43a5-5959-5708-7de0ef7c27e4@oracle.com> Hi Peter, Thanks for picking this up, for filing the bug (JDK-8227368), and developing the fix. For the current release, I think we should go ahead and put in the "right" fix, that is, to define serialVersionUID the conventional way -- as a compile-time constant -- and then simply to remove the suppression of the serial warning. This will change the specification (because the change will appear in serialized-form.html), but that's OK, we have the ability to change the specification. Note that this will require a CSR. (Changing the svuid value without changing the specification would probably require a CSR anyway, since it's a behavioral change that affects compatibility.) Might as well fix the specification now and be done with it, at least for current and future releases. The JDK 11 backport is where we should apply the static initializer. That's where changing the specification is more difficult. I think we should discuss that separately, though. Thanks for writing the new test and updating the BogusEnumSet test. Given that this is a fix for an incompatible change, I think this should be fixed as soon as possible. I've raised the priority to P3, and I've targeted this bug to JDK 13. We're after RDP1, but important fixes can still go in during RDP1 [1] until the next phase, RDP2, which begins on July 18. [2] Once this goes into JDK 13, it should automatically be propagated to JDK 14, with no manual steps necessary. With the fairly short time frame left in JDK 13 before RDP2, it would be best to move as quickly as possible. If you have time to work in this immediately, great, but if not, that's ok; please let me know and I'll pick up any or all work that you don't have time to do. Regardless, I'll help out any way I can, such as reviewing the code and the CSR, doing testing, etc. Next steps: 1. New changeset with constant version of EnumSet.serialVersionUID. 2. Create draft CSR. Thanks, s'marks [1] http://openjdk.java.net/jeps/3 [2] http://openjdk.java.net/projects/jdk/13/ On 7/7/19 8:11 AM, Peter Levart wrote: > On 7/7/19 4:31 PM, Peter Levart wrote: >> On 6/29/19 2:00 AM, Stuart Marks wrote: >>> Daniel Fuchs pointed me to a weird thing they had to do with the >>> serialVersionUID in one of the JMX classes: >>> >>> https://hg.openjdk.java.net/jdk/jdk/file/c59f36ed7b52/src/java.management/share/classes/javax/management/MBeanAttributeInfo.java#l46 >>> >>> >>> Essentially the svuid for this class initialized in a static block, and its >>> value is conditional based on the value of some system property. I don't >>> think using a property is necessary for the EnumSet case. However, it does >>> point out something interesting, which is that if the svuid is not >>> initialized with a compile-time constant, and instead via a static block, the >>> value doesn't appear in serialized-form.html. > > Hi Stuart, > > I just realized that I was reading your last statement wrong. I though it was > written as: > > ...if the svuid is not initialized with a compile-time constant, and instead via > a static block, the value doesn't appear in serialized form. > > And not as: > > ...if the svuid is not initialized with a compile-time constant, and instead via > a static block, the value doesn't appear in serialized-form.html > > > You were only concerned about the generated javadoc and not about the actual > "serialized form". Ok, I get it now. I have prepared webrev.02 to fix this. > > > Regards, Peter > From thejasvi.v.voniadka at oracle.com Tue Jul 9 07:50:43 2019 From: thejasvi.v.voniadka at oracle.com (Thejasvi Voniadka) Date: Tue, 9 Jul 2019 00:50:43 -0700 (PDT) Subject: RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string In-Reply-To: <24971d96-e27a-4d2d-bc2f-5290a353e2f4@default> References: <8ec24050-0c2a-4f2d-88e6-a3fba5d40e12@default> <1e497a17-ac12-d2f6-064f-39c4cb15223b@oracle.com> <590cca03-1741-41a2-9544-157d1f553835@default> <0ba3fe52-ba6f-df36-7a99-d5b8741920fc@oracle.com> <0c7e5fbf-74fe-cb40-4878-5287bf6581ea@oracle.com> <24971d96-e27a-4d2d-bc2f-5290a353e2f4@default> Message-ID: Hi Roger, Please find the updated webrev: http://cr.openjdk.java.net/~vagarwal/8154520/webrev.4/ I have updated both lines 3924 and 3874 of .../java/time/format/DateTimeFormatterBuilder.java. I have reduced the number of tests to just 3, and the number of locales to just 1 in java/time/format/TestLocalizedOffsetPrinterParser.java. That should provide sufficient coverage towards the functionality. -----Original Message----- From: Thejasvi Voniadka Sent: Friday, July 05, 2019 9:16 AM To: Roger Riggs ; core-libs-dev at openjdk.java.net; i18n-dev at openjdk.java.net Subject: RE: RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string Hi Roger, ? Thank you for the review. I am in transit this weekend, but I will fix this and republish as soon as I can. ? ? From: Roger Riggs Sent: Wednesday, July 03, 2019 10:46 PM To: Thejasvi Voniadka ; core-libs-dev at openjdk.java.net; i18n-dev at openjdk.java.net Subject: Re: RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string ? Hi, Looks ok, but... .../java/time/format/DateTimeFormatterBuilder.java 3924: needs a space in "if(" -> "if (" java/time/format/TestLocalizedOffsetPrinterParser.java I would cut the number of test cases to a minimum; only need to ensure the code is correct. We don't need to be testing the CLDR data; it is just? pass through. At least cut the number of different locale's used to cut the risk of unexpected maintenance. Thanks, Roger On 7/3/19 12:10 PM, HYPERLINK "mailto:naoto.sato at oracle.com"naoto.sato at oracle.com wrote: Looks good. Naoto On 7/3/19 5:32 AM, Thejasvi Voniadka wrote: Hi Naoto, Thank you for the review. Please find the updated webrev: http://cr.openjdk.java.net/~vagarwal/8154520/webrev.3/ The TCKOffsetPrinterParser.java has been reverted back to what it was, except for the copyright year and the locale addition. I have incorporated your comments to TestLocalizedOffsetPrinterParser.java. -----Original Message----- From: Naoto Sato Sent: Tuesday, July 02, 2019 9:33 PM To: Thejasvi Voniadka HYPERLINK "mailto:thejasvi.v.voniadka at oracle.com"; HYPERLINK "mailto:core-libs-dev at openjdk.java.net"core-libs-dev at openjdk.java.net; HYPERLINK "mailto:i18n-dev at openjdk.java.net"i18n-dev at openjdk.java.net Subject: Re: RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string Hi Thejasvi, Here are my comments to the webrev: TCKOffsetPrinterParser.java - No need to define Locale_US as a static field, nor have it in the test data (data_print_localized) then pass it as an argument to the test. Specifying Locale.US in line 572, 578, and 586 should suffice. TestOffsetPrinterParser.java - Copyright year is 2019. - It would be nice if some comments that reads something like "This test relies on the localized text of "GMT" in the CLDR." - Test class (and the description) should include "Localized", as it is testing the implementation of localized version of OffsetIdPrinterParser. - Line 64-76: I prefer just instantiating them in the test data, not defining a static field for each, unless there will be duplicate in the test data. - Line 111, 118, 124, 132: I believe the locale parameter is required. Make sure that with Objects.requireNonNull(), or fail if it's null. Naoto On 7/2/19 7:32 AM, Thejasvi Voniadka wrote: Hi Naoto, Thank you for the review. I have performed the modifications, and here is the updated webrev: http://cr.openjdk.java.net/~vagarwal/8154520/webrev.2/ I have moved the new tests from TCK area. I have also updated the current TCK test to explicitly pass Locale.US while calling format. -----Original Message----- From: Naoto Sato Sent: Monday, July 01, 2019 9:02 PM To: Thejasvi Voniadka HYPERLINK "mailto:thejasvi.v.voniadka at oracle.com"; HYPERLINK "mailto:core-libs-dev at openjdk.java.net"core-libs-dev at openjdk.java.net; HYPERLINK "mailto:i18n-dev at openjdk.java.net"i18n-dev at openjdk.java.net Subject: Re: RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string Hi Thejasvi, Thanks for fixing this. Since those new test cases depend on the CLDR localization, which might change in other implementations, those test cases should be in jdk/java/time/test directory, as "tck" tests should only test the spec. Please create a new test case for this in the "test" directory (with @modules jdk.localedata directive) similar to the existing TCK one. Also the current test in the TCK should enforce that it runs in Locale.US so that the result should match "GMT." Naoto On 6/28/19 5:59 AM, Thejasvi Voniadka wrote: Hi, Request you to please review this change. JBS:??? https://bugs.openjdk.java.net/browse/JDK-8154520 Description:??? At present, the "DateTimeFormatterBuilder.appendLocalizedOffset()" method formulates the base string as "GMT", without accounting for locale-specific transformations. This change is to return the localized version of "GMT" instead. So for example, instead of returning "GMT +5.30", it may now return "XXXX +5.30" where "XXXX" is the localized string for "GMT" for the locale associated with the formatter. I have used DateTimeTextProvider.getLocalizedResource() method to return the "gmtZeroFormat" value from CLDR/LDML corresponding to the given locale. The code defaults to "GMT" in the absence of such a localized value. Webrev:??? http://cr.openjdk.java.net/~vagarwal/8154520/webrev.1/ Additional notes:??? I preferred to update and reuse an existing test instead of creating a new one. It already has the niceties in place, and creating another method would mean some amount of code redundancy. However, if that's the recommended norm, then I can change it. ? From peter.levart at gmail.com Tue Jul 9 08:45:45 2019 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 9 Jul 2019 10:45:45 +0200 Subject: EnumSet.class serialization broken - twice - JDK-8227368 In-Reply-To: <72b10257-43a5-5959-5708-7de0ef7c27e4@oracle.com> References: <323f32f3-c242-c083-4d15-2754a3480730@oracle.com> <812af6a1-6836-2f51-ab18-ba9b202b0547@gmail.com> <72b10257-43a5-5959-5708-7de0ef7c27e4@oracle.com> Message-ID: <4ac2254b-1b24-12d7-8bb4-70a799bb2a05@gmail.com> Hi Stuart, On 7/9/19 1:57 AM, Stuart Marks wrote: > Hi Peter, > > Thanks for picking this up, for filing the bug (JDK-8227368), and > developing the fix. > > For the current release, I think we should go ahead and put in the > "right" fix, that is, to define serialVersionUID the conventional way > -- as a compile-time constant -- and then simply to remove the > suppression of the serial warning. This will change the specification > (because the change will appear in serialized-form.html), but that's > OK, we have the ability to change the specification. Note that this > will require a CSR. (Changing the svuid value without changing the > specification would probably require a CSR anyway, since it's a > behavioral change that affects compatibility.) Might as well fix the > specification now and be done with it, at least for current and future > releases. Right, I agree. > > The JDK 11 backport is where we should apply the static initializer. > That's where changing the specification is more difficult. I think we > should discuss that separately, though. > > Thanks for writing the new test and updating the BogusEnumSet test. > > Given that this is a fix for an incompatible change, I think this > should be fixed as soon as possible. I've raised the priority to P3, > and I've targeted this bug to JDK 13. We're after RDP1, but important > fixes can still go in during RDP1 [1] until the next phase, RDP2, > which begins on July 18. [2] Once this goes into JDK 13, it should > automatically be propagated to JDK 14, with no manual steps necessary. > > With the fairly short time frame left in JDK 13 before RDP2, it would > be best to move as quickly as possible. If you have time to work in > this immediately, great, but if not, that's ok; please let me know and > I'll pick up any or all work that you don't have time to do. > Regardless, I'll help out any way I can, such as reviewing the code > and the CSR, doing testing, etc. > > Next steps: > > 1. New changeset with constant version of EnumSet.serialVersionUID. This is already in the webrev.01 changeset. webrev.02 is an attempt to sneak the change without being visible in the serialized-form.html. > > 2. Create draft CSR. I'll try that right away. Regards, Peter > > Thanks, > > s'marks > > > [1] http://openjdk.java.net/jeps/3 > > [2] http://openjdk.java.net/projects/jdk/13/ > > > > > On 7/7/19 8:11 AM, Peter Levart wrote: >> On 7/7/19 4:31 PM, Peter Levart wrote: >>> On 6/29/19 2:00 AM, Stuart Marks wrote: >>>> Daniel Fuchs pointed me to a weird thing they had to do with the >>>> serialVersionUID in one of the JMX classes: >>>> >>>> https://hg.openjdk.java.net/jdk/jdk/file/c59f36ed7b52/src/java.management/share/classes/javax/management/MBeanAttributeInfo.java#l46 >>>> >>>> >>>> Essentially the svuid for this class initialized in a static block, >>>> and its value is conditional based on the value of some system >>>> property. I don't think using a property is necessary for the >>>> EnumSet case. However, it does point out something interesting, >>>> which is that if the svuid is not initialized with a compile-time >>>> constant, and instead via a static block, the value doesn't appear >>>> in serialized-form.html. >> >> Hi Stuart, >> >> I just realized that I was reading your last statement wrong. I >> though it was written as: >> >> ...if the svuid is not initialized with a compile-time constant, and >> instead via a static block, the value doesn't appear in serialized form. >> >> And not as: >> >> ...if the svuid is not initialized with a compile-time constant, and >> instead via a static block, the value doesn't appear in >> serialized-form.html >> >> >> You were only concerned about the generated javadoc and not about the >> actual "serialized form". Ok, I get it now. I have prepared webrev.02 >> to fix this. >> >> >> Regards, Peter >> From peter.levart at gmail.com Tue Jul 9 09:30:44 2019 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 9 Jul 2019 11:30:44 +0200 Subject: EnumSet.class serialization broken - twice - JDK-8227368 In-Reply-To: <72b10257-43a5-5959-5708-7de0ef7c27e4@oracle.com> References: <323f32f3-c242-c083-4d15-2754a3480730@oracle.com> <812af6a1-6836-2f51-ab18-ba9b202b0547@gmail.com> <72b10257-43a5-5959-5708-7de0ef7c27e4@oracle.com> Message-ID: <3a163c20-3c9d-8a61-5fab-ca52a354391f@gmail.com> On 7/9/19 1:57 AM, Stuart Marks wrote: > 2. Create draft CSR. Created: https://bugs.openjdk.java.net/browse/JDK-8227432 Regards, Peter From ramanand.patil at oracle.com Tue Jul 9 12:09:52 2019 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Tue, 9 Jul 2019 05:09:52 -0700 (PDT) Subject: RFR: 8224560: (tz) Upgrade time-zone data to tzdata2019a and 8225580: tzdata2018i integration causes test failures on jdk-13 In-Reply-To: <52bdd34c-67b4-7e50-c555-15e49f250b0c@oracle.com> References: <0a339591-f5ac-4680-ac70-1a48d8699999@default> <52bdd34c-67b4-7e50-c555-15e49f250b0c@oracle.com> Message-ID: Hi Naoto, Thank you for the review. Revised webrev: http://cr.openjdk.java.net/~rpatil/8224560/webrev.02/ I plan to push the changes tomorrow, if there are no further comments. Regards, Ramanand. > -----Original Message----- > From: Naoto Sato > Sent: Monday, July 8, 2019 11:19 PM > To: Ramanand Patil ; Andrew John Hughes > ; core-libs-dev at openjdk.java.net; i18n- > dev at openjdk.java.net > Subject: Re: RFR: 8224560: (tz) Upgrade time-zone data to > tzdata2019a and 8225580: tzdata2018i integration causes test failures on jdk- > 13 > > Hi Ramanand, > > As to the change in ZoneInfoFile.java, I would put that special handling of > Gaza/Hebron in line 577, as well as merging the comment in 575,576, so that > it won't duplicate the code. > > Otherwise looks good. > > Naoto > > On 7/8/19 3:35 AM, Ramanand Patil wrote: > > Hi Andrew, > > Thank you for your review. > > Updated webrev: http://cr.openjdk.java.net/~rpatil/8224560/webrev.01/ > > > > Regards, > > Ramanand. > > > >> -----Original Message----- > >> From: Andrew John Hughes > >> Sent: Saturday, July 6, 2019 9:53 PM > >> To: Ramanand Patil ; core-libs- > >> dev at openjdk.java.net; i18n-dev at openjdk.java.net > >> Subject: Re: RFR: 8224560: (tz) Upgrade time-zone data to > >> tzdata2019a and 8225580: tzdata2018i integration causes test failures > >> on jdk- > >> 13 > >> > >> > >> > >> On 05/07/2019 15:16, Ramanand Patil wrote: > >>> Hi all, > >>> Please review the patch for tzdata2019a integration into jdk project. > >>> Webrev: http://cr.openjdk.java.net/~rpatil/8224560/webrev.00/ > >>> Bugs: https://bugs.openjdk.java.net/browse/JDK-8224560 > >>> https://bugs.openjdk.java.net/browse/JDK-8225580 > >>> > >>> Summary: > >>> - The fix contains cumulative tzdata changes from tzdata2018i and > >> tzdata2019a, as tzdata2018i was not integrated into jdk/jdk earlier. > >>> - In JDK-13/14, multiple failures were seen during integration of > >>> tzdata2018i > >> (JDK-8225580), those are fixed now. Many thanks to Naoto for > >> providing a fix for this in CLDRConverter.java. > >> > >> I would guess this is due to the CLDR update (JDK-8221432: Upgrade > >> CLDR to Version 35.1) in OpenJDK 13, making TimeZone.getAvailableIDs > >> inappropriate in some way? > >> > >> Fix looks good. One minor change: > >> > >> + AVAILABLE_TZIDS = new > >> + HashSet(ZoneId.getAvailableZoneIds()); > >> > >> is missing the or <>: > >> > >> + AVAILABLE_TZIDS = new > >> + HashSet<>(ZoneId.getAvailableZoneIds()); > >> > >> Will this fix also resolve JDK-8225580? If so, it's probably worth > >> mentioning both bug IDs in the commit. > > Yes, this fix will also resolve JDK-8225580, hence included in the subject > line. > > And thank you, I will add both bug IDs in the commit message. > >> > >>> - There are 2 type of test failures in TestZoneInfo310.java file, > >>> which are > >> solved in this patch by providing workarounds, But a permanent fix > >> needs to be added in future for the same. Below are the 2 bugs > >> created to track the development on it: > >>> 1. https://bugs.openjdk.java.net/browse/JDK-8223388: > >> TestZoneInfo310.java fails post tzdata2018i integration: > >>> This failure is seen for the TimeZones which are having zone rules > >>> defined > >> till year 2037 or beyond. For now, the failing zones are skipped. > >>> The supporting test class ZoneInfo.java has maxYear defined > >> http://hg.openjdk.java.net/jdk/jdk/file/d01b345865d7/test/jdk/sun/uti > >> l/cale ndar/zi/Zoneinfo.java#l40, changing this max value greater > >> than the zone rule's last year also fixes the issue, but further > >> investigation is needed on why this boundary condition is affecting > >> the test behavior. > >> > >> I wonder if 2037 is in someway related to the rollover of 32-bit time > values? > > I think, not directly related but how the test and JDK handles these values. > > In JDK, the transitions beyond 2037 are delegated to SimpleTimeZone, and I > think the test somehow miscalculates it. > > http://hg.openjdk.java.net/jdk/jdk/file/5919b273def6/src/java.base/sha > > re/classes/sun/util/calendar/ZoneInfo.java#l48 > > I think, I should re-visit and see if these test are really needed > > now. As per the long standing bug JDK-8166983 suggestion was to remove > > the whole tests from test/sun/util/calendar/zi > >> > >>> 2. JDK-8227293: https://bugs.openjdk.java.net/browse/JDK-8227293 > >> TestZoneInfo310.java fails post tzdata2019a integration for Palestine > >> zone > >> rules: > >>> There are many hacks and assumptions in the class > >>> sun.util.calendar.ZoneInfoFile.java. This issue looks because of the > >>> code starting from here: > >>> http://hg.openjdk.java.net/jdk/jdk/file/963924f1c891/src/java.base/s > >>> ha > >>> re/classes/sun/util/calendar/ZoneInfoFile.java#l552 > >>> There is an assumption where the transition date is >=24,(line 577 > >>> and 599) > >> it assumes it is the "last" rule, but it is not last rule in case of > >> Asia/Gaza and Asia/Hebron zones. > >>> For now, I have fixed these 2 problematic timezones by overwriting > >>> the assumption made on line 577, where date of month dom = > >>> startRule.dom; I > >> think, overriding of the second jdk hack on line 599 is not required > >> as the "dom" is calculated from the last rule there. Keeping this bug > >> open as we need to find a generic solution for this issue, without > >> hard-coding the values and adding specific time zone names in > >> exclusion as seen in many places in this class file. > >>> > >>> - The patch has passed all the related testing including JCK tests. > >>> > >>> > >>> Regards, > >>> Ramanand. > >>> > >>> > >>> > >>> > >>> > >> > >> Looks good to me, with the above minor adjustment. > >> > >> Thanks, > >> -- > >> Andrew :) > >> > >> Senior Free Java Software Engineer > >> Red Hat, Inc. (http://www.redhat.com) > >> > >> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > >> Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > >> https://keybase.io/gnu_andrew > >> From naoto.sato at oracle.com Tue Jul 9 13:07:19 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 9 Jul 2019 06:07:19 -0700 Subject: RFR: 8224560: (tz) Upgrade time-zone data to tzdata2019a and 8225580: tzdata2018i integration causes test failures on jdk-13 In-Reply-To: References: <0a339591-f5ac-4680-ac70-1a48d8699999@default> <52bdd34c-67b4-7e50-c555-15e49f250b0c@oracle.com> Message-ID: <94fd20a2-8011-532b-2b11-f82ff023c423@oracle.com> Looks good, Ramanand. Naoto On 7/9/19 5:09 AM, Ramanand Patil wrote: > Hi Naoto, > Thank you for the review. Revised webrev: http://cr.openjdk.java.net/~rpatil/8224560/webrev.02/ > > > I plan to push the changes tomorrow, if there are no further comments. > > > Regards, > Ramanand. > >> -----Original Message----- >> From: Naoto Sato >> Sent: Monday, July 8, 2019 11:19 PM >> To: Ramanand Patil ; Andrew John Hughes >> ; core-libs-dev at openjdk.java.net; i18n- >> dev at openjdk.java.net >> Subject: Re: RFR: 8224560: (tz) Upgrade time-zone data to >> tzdata2019a and 8225580: tzdata2018i integration causes test failures on jdk- >> 13 >> >> Hi Ramanand, >> >> As to the change in ZoneInfoFile.java, I would put that special handling of >> Gaza/Hebron in line 577, as well as merging the comment in 575,576, so that >> it won't duplicate the code. >> >> Otherwise looks good. >> >> Naoto >> >> On 7/8/19 3:35 AM, Ramanand Patil wrote: >>> Hi Andrew, >>> Thank you for your review. >>> Updated webrev: http://cr.openjdk.java.net/~rpatil/8224560/webrev.01/ >>> >>> Regards, >>> Ramanand. >>> >>>> -----Original Message----- >>>> From: Andrew John Hughes >>>> Sent: Saturday, July 6, 2019 9:53 PM >>>> To: Ramanand Patil ; core-libs- >>>> dev at openjdk.java.net; i18n-dev at openjdk.java.net >>>> Subject: Re: RFR: 8224560: (tz) Upgrade time-zone data to >>>> tzdata2019a and 8225580: tzdata2018i integration causes test failures >>>> on jdk- >>>> 13 >>>> >>>> >>>> >>>> On 05/07/2019 15:16, Ramanand Patil wrote: >>>>> Hi all, >>>>> Please review the patch for tzdata2019a integration into jdk project. >>>>> Webrev: http://cr.openjdk.java.net/~rpatil/8224560/webrev.00/ >>>>> Bugs: https://bugs.openjdk.java.net/browse/JDK-8224560 >>>>> https://bugs.openjdk.java.net/browse/JDK-8225580 >>>>> >>>>> Summary: >>>>> - The fix contains cumulative tzdata changes from tzdata2018i and >>>> tzdata2019a, as tzdata2018i was not integrated into jdk/jdk earlier. >>>>> - In JDK-13/14, multiple failures were seen during integration of >>>>> tzdata2018i >>>> (JDK-8225580), those are fixed now. Many thanks to Naoto for >>>> providing a fix for this in CLDRConverter.java. >>>> >>>> I would guess this is due to the CLDR update (JDK-8221432: Upgrade >>>> CLDR to Version 35.1) in OpenJDK 13, making TimeZone.getAvailableIDs >>>> inappropriate in some way? >>>> >>>> Fix looks good. One minor change: >>>> >>>> + AVAILABLE_TZIDS = new >>>> + HashSet(ZoneId.getAvailableZoneIds()); >>>> >>>> is missing the or <>: >>>> >>>> + AVAILABLE_TZIDS = new >>>> + HashSet<>(ZoneId.getAvailableZoneIds()); >>>> >>>> Will this fix also resolve JDK-8225580? If so, it's probably worth >>>> mentioning both bug IDs in the commit. >>> Yes, this fix will also resolve JDK-8225580, hence included in the subject >> line. >>> And thank you, I will add both bug IDs in the commit message. >>>> >>>>> - There are 2 type of test failures in TestZoneInfo310.java file, >>>>> which are >>>> solved in this patch by providing workarounds, But a permanent fix >>>> needs to be added in future for the same. Below are the 2 bugs >>>> created to track the development on it: >>>>> 1. https://bugs.openjdk.java.net/browse/JDK-8223388: >>>> TestZoneInfo310.java fails post tzdata2018i integration: >>>>> This failure is seen for the TimeZones which are having zone rules >>>>> defined >>>> till year 2037 or beyond. For now, the failing zones are skipped. >>>>> The supporting test class ZoneInfo.java has maxYear defined >>>> http://hg.openjdk.java.net/jdk/jdk/file/d01b345865d7/test/jdk/sun/uti >>>> l/cale ndar/zi/Zoneinfo.java#l40, changing this max value greater >>>> than the zone rule's last year also fixes the issue, but further >>>> investigation is needed on why this boundary condition is affecting >>>> the test behavior. >>>> >>>> I wonder if 2037 is in someway related to the rollover of 32-bit time >> values? >>> I think, not directly related but how the test and JDK handles these values. >>> In JDK, the transitions beyond 2037 are delegated to SimpleTimeZone, and I >> think the test somehow miscalculates it. >>> http://hg.openjdk.java.net/jdk/jdk/file/5919b273def6/src/java.base/sha >>> re/classes/sun/util/calendar/ZoneInfo.java#l48 >>> I think, I should re-visit and see if these test are really needed >>> now. As per the long standing bug JDK-8166983 suggestion was to remove >>> the whole tests from test/sun/util/calendar/zi >>>> >>>>> 2. JDK-8227293: https://bugs.openjdk.java.net/browse/JDK-8227293 >>>> TestZoneInfo310.java fails post tzdata2019a integration for Palestine >>>> zone >>>> rules: >>>>> There are many hacks and assumptions in the class >>>>> sun.util.calendar.ZoneInfoFile.java. This issue looks because of the >>>>> code starting from here: >>>>> http://hg.openjdk.java.net/jdk/jdk/file/963924f1c891/src/java.base/s >>>>> ha >>>>> re/classes/sun/util/calendar/ZoneInfoFile.java#l552 >>>>> There is an assumption where the transition date is >=24,(line 577 >>>>> and 599) >>>> it assumes it is the "last" rule, but it is not last rule in case of >>>> Asia/Gaza and Asia/Hebron zones. >>>>> For now, I have fixed these 2 problematic timezones by overwriting >>>>> the assumption made on line 577, where date of month dom = >>>>> startRule.dom; I >>>> think, overriding of the second jdk hack on line 599 is not required >>>> as the "dom" is calculated from the last rule there. Keeping this bug >>>> open as we need to find a generic solution for this issue, without >>>> hard-coding the values and adding specific time zone names in >>>> exclusion as seen in many places in this class file. >>>>> >>>>> - The patch has passed all the related testing including JCK tests. >>>>> >>>>> >>>>> Regards, >>>>> Ramanand. >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> Looks good to me, with the above minor adjustment. >>>> >>>> Thanks, >>>> -- >>>> Andrew :) >>>> >>>> Senior Free Java Software Engineer >>>> Red Hat, Inc. (http://www.redhat.com) >>>> >>>> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) >>>> Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 >>>> https://keybase.io/gnu_andrew >>>> From jai.forums2013 at gmail.com Tue Jul 9 13:18:06 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 9 Jul 2019 18:48:06 +0530 Subject: RFR [14] JDK-8225763 Inflater and Deflater should implement AutoCloseable Message-ID: <1a0052f8-dc3f-9102-942e-e66e6f5ad694@gmail.com> Can I please get a review and a sponsor for the patch that implements the enhancement noted in https://bugs.openjdk.java.net/browse/JDK-8225763 ? There has been a recent discussion about this change in the core-libs-dev mailing list here[1]. The latest version of the patch for this change is now available at [2]. Here's a summary of what's contained in this patch: - The Inflater/Deflater class now implements AutoCloseable - The class level javadoc of both these classes has been to updated to use newer style of code, with try-with-resources, for the example contained in that javadoc. The @apiNote in these class level javadoc has also been updated to mention the use of close() method for releasing resources. - The javadoc of end() method in both these classes has been updated to encourage the use of close() method instead of this one. It now also has a @implSpec which states that it's a no-op if called more than once. In addition, this javadoc has also been updated to replace the "undefined behaviour" statement with a mention that the usage of the Inflater/Deflater instance after a call to end() may throw an exception in those subsequent usages. Please note that, there's no such explicit mention in the javadoc of the (newly added) close() method because IMO, it isn't needed for close() since I think it's kind of implied that a closed resource can no longer be used for further operations. - The new close() method has been added along with javadoc which uses an @implSpec to state that it internally calls end() - TotalInOut.java test has been updated to use the new try-with-resources construct for the inflater and deflater it uses. - A couple of new (testng) test classes have been added to test various scenarios where close() and end() method get called. These test mostly focus on ensuring that the close() and end(), either implicitly or explicitly, get called the right number of times on the subclasses of Inflater/Deflater. - I have run the tests under test/jdk/java/util/zip/ by running: jtreg -jdk:build/macosx-x86_64-server-release/images/jdk test/jdk/java/util/zip/ and they have come back passing (except for failures/errors in java/util/zip/ZipFile/TestZipFile.java, java/util/zip/3GBZipFiles.sh and java/util/zip/DataDescriptorSignatureMissing.java - those issues though are unrelated to this change and expected to fail, based on what I see in their test report logs) - In addition, I have sneaked in an unrelated change in this patch, into the Deflater.end() method: ???? public void end() { ???????? synchronized (zsRef) { +??????????? // check if already closed +??????????? if (zsRef.address() == 0) { +??????????????? return; +??????????? } ???????????? zsRef.clean(); ???????????? input = ZipUtils.defaultBuf; +??????????? inputArray = null; +??????? } Unlike in the Inflater.end(), the Deflater.end() didn't previously have the "inputArray = null". I have included it in this patch, since it looks right to clean up that array too. If this isn't the right time/patch to do it, please do let me know and I'll take that up separately. [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-June/061096.html [2] http://cr.openjdk.java.net/~jpai/webrev/8225763/2/webrev/ -Jaikiran From jai.forums2013 at gmail.com Tue Jul 9 13:24:16 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 9 Jul 2019 18:54:16 +0530 Subject: Inputs on patch for JDK-8225763? Inflater and Deflater should implement AutoCloseable In-Reply-To: References: <44582692-a30b-0d54-e550-6277cab95969@gmail.com> <152766d5-72b0-9847-cde2-c89f1d0229d8@gmail.com> <5b1f547f-84da-c8c2-c071-278830e125a2@gmail.com> <0d234157-869f-9c95-b3dc-587f989b1551@oracle.com> Message-ID: <2dbdccc7-47f8-d60e-acee-12a53f460ada@gmail.com> Hello Lance, On 08/07/19 11:16 PM, Lance Andersen wrote: > Hi Jaikiran, > > Thank you for your efforts here. > >> On Jul 6, 2019, at 9:59 AM, Jaikiran Pai > > wrote: >> >>> >>> ?- Idempotency >>> >>> Yes, it looks to me like Inflater.end() and Deflater.end() >>> implementations are idempotent. As you point out, overrides by >>> subclasses might not be. We should be clear when we're talking about >>> the specific implementatations of the end() methods in the Deflater >>> and Inflater classes, or whether we're talking about the contracts >>> defined by these method specifications on these classes and subtypes. >>> >>> The behavior of an implementation in a class can be specified with >>> @implSpec without imposing this on the contract of subclasses. This is >>> useful for subclasses that need to know the exact behavior of calling >>> super.end(), and also for callers who know they have an instance of a >>> particular class and not a subclass. >>> >>> The upshot is that while we might not have the end() method's contract >>> specify idempotency, we can certainly say so in an @implSpec, if doing >>> this will help. I'm not sure we'll actually need it in this case, but >>> let's keep it in mind. >> >> Thank you. Although not for end(), I have now used this @implSpec in the >> first version of my patch[1]. > > This should be done for end() as well to set expectations. ?While > close() is the preferred way to go moving forward, end() is not going > anywhere and still needs to be a first class-citizen WRT documentation. Done. I have added the @implSpec for end() too in the new updated revision of the webrev. I have opened a separate RFR thread containing that webrev. >>> >>> ** >>> >>> If you think the issues are settled enough, maybe it's time for you to >>> take a stab at a patch.? >> >> The initial version of my patch is now ready at [1]. Here's a high level >> summary of what's contained in this patch: > > Please start a review request thread so it is easier to follow. ?Once > you do that, I will reply to it.. Done - I have now created a new RFR thread for this here http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-July/061229.html > > Also, reminder to update copyright dates. The updated webrev in the RFR thread contains this update. > > For the tests, it would be best to add more comments. ?Out of > curiosity, was there a reason you chose not to use TestNG vs having > just a main which invokes each test? No specific reason. I'm still relatively new to the JDK codebase and don't know when to use testng as against the regular main() driven tests. I have now cleaned up the tests and converted them to testng in the new webrev that I proposed. -Jaikiran From Roger.Riggs at oracle.com Tue Jul 9 13:58:58 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 9 Jul 2019 09:58:58 -0400 Subject: RFR: 8224560: (tz) Upgrade time-zone data to tzdata2019a and 8225580: tzdata2018i integration causes test failures on jdk-13 In-Reply-To: <94fd20a2-8011-532b-2b11-f82ff023c423@oracle.com> References: <0a339591-f5ac-4680-ac70-1a48d8699999@default> <52bdd34c-67b4-7e50-c555-15e49f250b0c@oracle.com> <94fd20a2-8011-532b-2b11-f82ff023c423@oracle.com> Message-ID: <35e5690e-96c6-438d-5388-56bd9315d98a@oracle.com> +1 On 7/9/19 9:07 AM, naoto.sato at oracle.com wrote: > Looks good, Ramanand. > > Naoto > > On 7/9/19 5:09 AM, Ramanand Patil wrote: >> Hi Naoto, >> Thank you for the review. Revised webrev: >> http://cr.openjdk.java.net/~rpatil/8224560/webrev.02/ >> >> >> I plan to push the changes tomorrow, if there are no further comments. >> >> >> Regards, >> Ramanand. >> >>> -----Original Message----- >>> From: Naoto Sato >>> Sent: Monday, July 8, 2019 11:19 PM >>> To: Ramanand Patil ; Andrew John Hughes >>> ; core-libs-dev at openjdk.java.net; i18n- >>> dev at openjdk.java.net >>> Subject: Re: RFR: 8224560: (tz) Upgrade time-zone data to >>> tzdata2019a and 8225580: tzdata2018i integration causes test >>> failures on jdk- >>> 13 >>> >>> Hi Ramanand, >>> >>> As to the change in ZoneInfoFile.java, I would put that special >>> handling of >>> Gaza/Hebron in line 577, as well as merging the comment in 575,576, >>> so that >>> it won't duplicate the code. >>> >>> Otherwise looks good. >>> >>> Naoto >>> >>> On 7/8/19 3:35 AM, Ramanand Patil wrote: >>>> Hi Andrew, >>>> Thank you for your review. >>>> Updated webrev: http://cr.openjdk.java.net/~rpatil/8224560/webrev.01/ >>>> >>>> Regards, >>>> Ramanand. >>>> >>>>> -----Original Message----- >>>>> From: Andrew John Hughes >>>>> Sent: Saturday, July 6, 2019 9:53 PM >>>>> To: Ramanand Patil ; core-libs- >>>>> dev at openjdk.java.net; i18n-dev at openjdk.java.net >>>>> Subject: Re: RFR: 8224560: (tz) Upgrade time-zone data to >>>>> tzdata2019a and 8225580: tzdata2018i integration causes test failures >>>>> on jdk- >>>>> 13 >>>>> >>>>> >>>>> >>>>> On 05/07/2019 15:16, Ramanand Patil wrote: >>>>>> Hi all, >>>>>> Please review the patch for tzdata2019a integration into jdk >>>>>> project. >>>>>> Webrev: http://cr.openjdk.java.net/~rpatil/8224560/webrev.00/ >>>>>> Bugs: https://bugs.openjdk.java.net/browse/JDK-8224560 >>>>>> https://bugs.openjdk.java.net/browse/JDK-8225580 >>>>>> >>>>>> Summary: >>>>>> - The fix contains cumulative tzdata changes from tzdata2018i and >>>>> tzdata2019a, as tzdata2018i was not integrated into jdk/jdk earlier. >>>>>> - In JDK-13/14, multiple failures were seen during integration of >>>>>> tzdata2018i >>>>> (JDK-8225580), those are fixed now. Many thanks to Naoto for >>>>> providing a fix for this in CLDRConverter.java. >>>>> >>>>> I would guess this is due to the CLDR update (JDK-8221432: Upgrade >>>>> CLDR to Version 35.1) in OpenJDK 13, making TimeZone.getAvailableIDs >>>>> inappropriate in some way? >>>>> >>>>> Fix looks good. One minor change: >>>>> >>>>> +??????????? AVAILABLE_TZIDS = new >>>>> + HashSet(ZoneId.getAvailableZoneIds()); >>>>> >>>>> is missing the or <>: >>>>> >>>>> +??????????? AVAILABLE_TZIDS = new >>>>> + HashSet<>(ZoneId.getAvailableZoneIds()); >>>>> >>>>> Will this fix also resolve JDK-8225580? If so, it's probably worth >>>>> mentioning both bug IDs in the commit. >>>> Yes, this fix will also resolve JDK-8225580, hence included in the >>>> subject >>> line. >>>> And thank you, I will add both bug IDs in the commit message. >>>>> >>>>>> - There are 2 type of test failures in TestZoneInfo310.java file, >>>>>> which are >>>>> solved in this patch by providing workarounds, But a permanent fix >>>>> needs to be added in future for the same. Below are the 2 bugs >>>>> created to track the development on it: >>>>>> ????1. https://bugs.openjdk.java.net/browse/JDK-8223388: >>>>> TestZoneInfo310.java fails post tzdata2018i integration: >>>>>> This failure is seen for the TimeZones which are having zone rules >>>>>> defined >>>>> till year 2037 or beyond. For now, the failing zones are skipped. >>>>>> The supporting test class ZoneInfo.java has maxYear defined >>>>> http://hg.openjdk.java.net/jdk/jdk/file/d01b345865d7/test/jdk/sun/uti >>>>> l/cale ndar/zi/Zoneinfo.java#l40, changing this max value greater >>>>> than the zone rule's last year also fixes the issue, but further >>>>> investigation is needed on why this boundary condition is affecting >>>>> the test behavior. >>>>> >>>>> I wonder if 2037 is in someway related to the rollover of 32-bit time >>> values? >>>> I think, not directly related but how the test and JDK handles >>>> these values. >>>> In JDK, the transitions beyond 2037 are delegated to >>>> SimpleTimeZone, and I >>> think the test somehow miscalculates it. >>>> http://hg.openjdk.java.net/jdk/jdk/file/5919b273def6/src/java.base/sha >>>> re/classes/sun/util/calendar/ZoneInfo.java#l48 >>>> I think, I should re-visit and see if these test are really needed >>>> now. As per the long standing bug JDK-8166983 suggestion was to remove >>>> the whole tests from test/sun/util/calendar/zi >>>>> >>>>>> ????2. JDK-8227293: https://bugs.openjdk.java.net/browse/JDK-8227293 >>>>> TestZoneInfo310.java fails post tzdata2019a integration for Palestine >>>>> zone >>>>> rules: >>>>>> There are many hacks and assumptions in the class >>>>>> sun.util.calendar.ZoneInfoFile.java. This issue looks because of the >>>>>> code starting from here: >>>>>> http://hg.openjdk.java.net/jdk/jdk/file/963924f1c891/src/java.base/s >>>>>> ha >>>>>> re/classes/sun/util/calendar/ZoneInfoFile.java#l552 >>>>>> There is an assumption where the transition date is >=24,(line 577 >>>>>> and 599) >>>>> it assumes it is the "last" rule, but it is not last rule in case of >>>>> Asia/Gaza and Asia/Hebron zones. >>>>>> For now, I have fixed these 2 problematic timezones by overwriting >>>>>> the assumption made on line 577, where date of month dom = >>>>>> startRule.dom; I >>>>> think, overriding of the second jdk hack on line 599 is not required >>>>> as the "dom" is calculated from the last rule there. Keeping this bug >>>>> open as we need to find a generic solution for this issue, without >>>>> hard-coding the values and adding specific time zone names in >>>>> exclusion as seen in many places in this class file. >>>>>> >>>>>> - The patch has passed all the related testing including JCK tests. >>>>>> >>>>>> >>>>>> Regards, >>>>>> Ramanand. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> Looks good to me, with the above minor adjustment. >>>>> >>>>> Thanks, >>>>> -- >>>>> Andrew :) >>>>> >>>>> Senior Free Java Software Engineer >>>>> Red Hat, Inc. (http://www.redhat.com) >>>>> >>>>> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) >>>>> Fingerprint = 5132 579D D154 0ED2 3E04? C5A0 CFDA 0F9B 3596 4222 >>>>> https://keybase.io/gnu_andrew >>>>> From Roger.Riggs at oracle.com Tue Jul 9 14:09:35 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 9 Jul 2019 10:09:35 -0400 Subject: RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string In-Reply-To: References: <8ec24050-0c2a-4f2d-88e6-a3fba5d40e12@default> <1e497a17-ac12-d2f6-064f-39c4cb15223b@oracle.com> <590cca03-1741-41a2-9544-157d1f553835@default> <0ba3fe52-ba6f-df36-7a99-d5b8741920fc@oracle.com> <0c7e5fbf-74fe-cb40-4878-5287bf6581ea@oracle.com> <24971d96-e27a-4d2d-bc2f-5290a353e2f4@default> Message-ID: <374dd44a-bd41-b48a-9943-bed34424b224@oracle.com> Hi Thejasvi, Looks good, thanks for the updates Roger On 7/9/19 3:50 AM, Thejasvi Voniadka wrote: > Hi Roger, > > Please find the updated webrev: > > http://cr.openjdk.java.net/~vagarwal/8154520/webrev.4/ > > > I have updated both lines 3924 and 3874 of .../java/time/format/DateTimeFormatterBuilder.java. > > I have reduced the number of tests to just 3, and the number of locales to just 1 in java/time/format/TestLocalizedOffsetPrinterParser.java. That should provide sufficient coverage towards the functionality. > > > > -----Original Message----- > From: Thejasvi Voniadka > Sent: Friday, July 05, 2019 9:16 AM > To: Roger Riggs ; core-libs-dev at openjdk.java.net; i18n-dev at openjdk.java.net > Subject: RE: RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string > > Hi Roger, > > > > Thank you for the review. I am in transit this weekend, but I will fix this and republish as soon as I can. > > > > > > From: Roger Riggs > Sent: Wednesday, July 03, 2019 10:46 PM > To: Thejasvi Voniadka ; core-libs-dev at openjdk.java.net; i18n-dev at openjdk.java.net > Subject: Re: RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string > > > > Hi, > > Looks ok, but... > > .../java/time/format/DateTimeFormatterBuilder.java > 3924: needs a space in "if(" -> "if (" > > java/time/format/TestLocalizedOffsetPrinterParser.java > > I would cut the number of test cases to a minimum; only need to ensure the code is correct. > We don't need to be testing the CLDR data; it is just? pass through. > At least cut the number of different locale's used to cut the risk of unexpected maintenance. > > Thanks, Roger > > > > > On 7/3/19 12:10 PM, HYPERLINK "mailto:naoto.sato at oracle.com"naoto.sato at oracle.com wrote: > > Looks good. > > Naoto > > On 7/3/19 5:32 AM, Thejasvi Voniadka wrote: > > > > Hi Naoto, > > Thank you for the review. Please find the updated webrev: > > http://cr.openjdk.java.net/~vagarwal/8154520/webrev.3/ > > > The TCKOffsetPrinterParser.java has been reverted back to what it was, except for the copyright year and the locale addition. I have incorporated your comments to TestLocalizedOffsetPrinterParser.java. > > > > -----Original Message----- > From: Naoto Sato > Sent: Tuesday, July 02, 2019 9:33 PM > To: Thejasvi Voniadka HYPERLINK "mailto:thejasvi.v.voniadka at oracle.com"; HYPERLINK "mailto:core-libs-dev at openjdk.java.net"core-libs-dev at openjdk.java.net; HYPERLINK "mailto:i18n-dev at openjdk.java.net"i18n-dev at openjdk.java.net > Subject: Re: RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string > > Hi Thejasvi, > > Here are my comments to the webrev: > > TCKOffsetPrinterParser.java > > - No need to define Locale_US as a static field, nor have it in the test data (data_print_localized) then pass it as an argument to the test. > Specifying Locale.US in line 572, 578, and 586 should suffice. > > TestOffsetPrinterParser.java > > - Copyright year is 2019. > > - It would be nice if some comments that reads something like "This test relies on the localized text of "GMT" in the CLDR." > > - Test class (and the description) should include "Localized", as it is testing the implementation of localized version of OffsetIdPrinterParser. > > - Line 64-76: I prefer just instantiating them in the test data, not defining a static field for each, unless there will be duplicate in the test data. > > - Line 111, 118, 124, 132: I believe the locale parameter is required. > Make sure that with Objects.requireNonNull(), or fail if it's null. > > Naoto > > On 7/2/19 7:32 AM, Thejasvi Voniadka wrote: > > > > Hi Naoto, > > Thank you for the review. I have performed the modifications, and here is the updated webrev: > > http://cr.openjdk.java.net/~vagarwal/8154520/webrev.2/ > > > I have moved the new tests from TCK area. I have also updated the current TCK test to explicitly pass Locale.US while calling format. > > > > > -----Original Message----- > From: Naoto Sato > Sent: Monday, July 01, 2019 9:02 PM > To: Thejasvi Voniadka HYPERLINK "mailto:thejasvi.v.voniadka at oracle.com"; > HYPERLINK "mailto:core-libs-dev at openjdk.java.net"core-libs-dev at openjdk.java.net; HYPERLINK "mailto:i18n-dev at openjdk.java.net"i18n-dev at openjdk.java.net > Subject: Re: RFR: 8154520: java.time: > appendLocalizedOffset() should return the localized "GMT" string > > Hi Thejasvi, > > Thanks for fixing this. > > Since those new test cases depend on the CLDR localization, which might change in other implementations, those test cases should be in jdk/java/time/test directory, as "tck" tests should only test the spec. > Please create a new test case for this in the "test" directory (with @modules jdk.localedata directive) similar to the existing TCK one. Also the current test in the TCK should enforce that it runs in Locale.US so that the result should match "GMT." > > Naoto > > On 6/28/19 5:59 AM, Thejasvi Voniadka wrote: > > > > Hi, > > Request you to please review this change. > > > JBS:??? https://bugs.openjdk.java.net/browse/JDK-8154520 > > > Description:??? At present, the "DateTimeFormatterBuilder.appendLocalizedOffset()" method formulates the base string as "GMT", without accounting for locale-specific transformations. This change is to return the localized version of "GMT" instead. So for example, instead of returning "GMT +5.30", it may now return "XXXX +5.30" where "XXXX" is the localized string for "GMT" for the locale associated with the formatter. I have used DateTimeTextProvider.getLocalizedResource() method to return the "gmtZeroFormat" value from CLDR/LDML corresponding to the given locale. The code defaults to "GMT" in the absence of such a localized value. > > > Webrev:??? http://cr.openjdk.java.net/~vagarwal/8154520/webrev.1/ > > > Additional notes:??? I preferred to update and reuse an existing test instead of creating a new one. It already has the niceties in place, and creating another method would mean some amount of code redundancy. However, if that's the recommended norm, then I can change it. > > From Roger.Riggs at oracle.com Tue Jul 9 14:11:58 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 9 Jul 2019 10:11:58 -0400 Subject: [13] RFR: 8227127: Era designator not displayed correctly using the COMPAT provider In-Reply-To: <259bb4e9-b4ba-cde8-d2ff-afcb460866c3@oracle.com> References: <259bb4e9-b4ba-cde8-d2ff-afcb460866c3@oracle.com> Message-ID: Hi Naoto, Looks fine. Thanks, Roger On 7/8/19 6:11 PM, naoto.sato at oracle.com wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8227127 > > The proposed changeset is located at: > > https://cr.openjdk.java.net/~naoto/8227127/webrev.00/ > > This is a regression caused by the fix to 8039301, where era display > names are correctly retrieved with styles. This revealed that the > short names for Gregorian eras are missing in COMPAT locale provider. > Providing the proper display names in its resource bundles fixes the > issue. > > Naoto From Roger.Riggs at oracle.com Tue Jul 9 14:34:45 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 9 Jul 2019 10:34:45 -0400 Subject: 8193072: File.delete() should remove its path from DeleteOnExitHook.files In-Reply-To: References: <9608451A-321D-4CD7-9DD9-04524AC4F53D@oracle.com> <0525c4cf-4a02-1f9b-2950-a0750cbf4a48@oracle.com> Message-ID: <0d67cb9d-96d1-9e55-dda5-31ede2770cfd@oracle.com> Hi Brian, The sequence described is the specified behavior of the API, whether it is a developer mistake or not is unknowable but it would be a compatibility issue to change it. The filename is the key and there is no way to determine if it is the original file or a replacement. deleteOnExit Wins! $.02, Roger On 7/8/19 5:08 PM, Brian Burkhalter wrote: > Ivan / Jason, > > Thanks for the good observations. > >> On Jul 8, 2019, at 1:35 PM, Ivan Gerasimov wrote: >> >> I believe this would introduce a behavior change in a scenario lile: >> File f = ...; >> f.deleteOnExit(); >> f.delete(); >> f.createNewFile(); >> >> I.e. when the with the same name is recreated. Current behavior is to unlink such a file before exiting, no matter if it were explicitly deleted and then recreated or not. > Good point. Given this consideration I am not sure that this bug can be fixed. > >> On Jul 8, 2019, at 1:53 PM, Jason Mehrens wrote: >> >> Previously File.delete wouldn't throw IllegalStateException and with this patch it looks like that is possible (and not desirable). I would think that this change could the break java.util.logging.FileHandler because Handler.close runs in a shutdown hook. > > I think you are correct that the ISE should not be thrown. > > Thanks, > > Brian From brian.burkhalter at oracle.com Tue Jul 9 15:07:10 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 9 Jul 2019 08:07:10 -0700 Subject: 8193072: File.delete() should remove its path from DeleteOnExitHook.files In-Reply-To: <0d67cb9d-96d1-9e55-dda5-31ede2770cfd@oracle.com> References: <9608451A-321D-4CD7-9DD9-04524AC4F53D@oracle.com> <0525c4cf-4a02-1f9b-2950-a0750cbf4a48@oracle.com> <0d67cb9d-96d1-9e55-dda5-31ede2770cfd@oracle.com> Message-ID: Hi Roger, You might be correct but I wrote up a different version at the end of yesterday. Not sure it is right but I might as well post it: http://cr.openjdk.java.net/~bpb/8193072/webrev.01/ Thanks, Brian > On Jul 9, 2019, at 7:34 AM, Roger Riggs wrote: > > The sequence described is the specified behavior of the API, whether it is a developer mistake or not is unknowable but it would be a compatibility issue to change it. The filename is the key and there is no way to determine if it is the original file or a replacement. deleteOnExit Wins! From david.lloyd at redhat.com Tue Jul 9 15:14:18 2019 From: david.lloyd at redhat.com (David Lloyd) Date: Tue, 9 Jul 2019 10:14:18 -0500 Subject: RFR [14] JDK-8225763 Inflater and Deflater should implement AutoCloseable In-Reply-To: <1a0052f8-dc3f-9102-942e-e66e6f5ad694@gmail.com> References: <1a0052f8-dc3f-9102-942e-e66e6f5ad694@gmail.com> Message-ID: On Tue, Jul 9, 2019 at 8:19 AM Jaikiran Pai wrote: > - In addition, I have sneaked in an unrelated change in this patch, into > the Deflater.end() method: > > public void end() { > synchronized (zsRef) { > + // check if already closed > + if (zsRef.address() == 0) { > + return; > + } > zsRef.clean(); > input = ZipUtils.defaultBuf; > + inputArray = null; > + } > > Unlike in the Inflater.end(), the Deflater.end() didn't previously have > the "inputArray = null". I have included it in this patch, since it > looks right to clean up that array too. If this isn't the right > time/patch to do it, please do let me know and I'll take that up separately. This was probably my mistake. The fix looks good to me! -- - DML From Roger.Riggs at oracle.com Tue Jul 9 15:25:56 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 9 Jul 2019 11:25:56 -0400 Subject: 8193072: File.delete() should remove its path from DeleteOnExitHook.files In-Reply-To: References: <9608451A-321D-4CD7-9DD9-04524AC4F53D@oracle.com> <0525c4cf-4a02-1f9b-2950-a0750cbf4a48@oracle.com> <0d67cb9d-96d1-9e55-dda5-31ede2770cfd@oracle.com> Message-ID: <0ab34cb3-38c6-1e62-cc1c-13b9d343ab6c@oracle.com> Hi Brian, The interesting part will be writing/updating the specification to make it clear what happens and under what conditions. How often are File instances re-used vs creating new ones. And any interactions with other APIs that create or delete files with the same name.? (file channels, zip, etc...) Since deleteOnExit() is an deliberate act, perhaps there should be a corresponding withdrawDeleteOnExit() that reverses it so that it is intentional and not a side-effect of other File methods. Roger On 7/9/19 11:07 AM, Brian Burkhalter wrote: > Hi Roger, > > You might be correct but I wrote up a different version at the end of > yesterday. Not sure it is right but I might as well post it: > > http://cr.openjdk.java.net/~bpb/8193072/webrev.01/ > > Thanks, > > Brian > >> On Jul 9, 2019, at 7:34 AM, Roger Riggs > > wrote: >> >> The sequence described is the specified behavior of the API, whether >> it is a developer mistake or not is unknowable but it would be a >> compatibility issue to change it. The filename is the key and there >> is no way to determine if it is the original file or a replacement. >> deleteOnExit Wins! > From brian.burkhalter at oracle.com Tue Jul 9 15:31:08 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 9 Jul 2019 08:31:08 -0700 Subject: 8193072: File.delete() should remove its path from DeleteOnExitHook.files In-Reply-To: <0ab34cb3-38c6-1e62-cc1c-13b9d343ab6c@oracle.com> References: <9608451A-321D-4CD7-9DD9-04524AC4F53D@oracle.com> <0525c4cf-4a02-1f9b-2950-a0750cbf4a48@oracle.com> <0d67cb9d-96d1-9e55-dda5-31ede2770cfd@oracle.com> <0ab34cb3-38c6-1e62-cc1c-13b9d343ab6c@oracle.com> Message-ID: <096A2B42-5635-4254-92CA-2EB2758BD5D1@oracle.com> Hi Roger, > On Jul 9, 2019, at 8:25 AM, Roger Riggs wrote: > > The interesting part will be writing/updating the specification to make it clear what happens and under what conditions. > How often are File instances re-used vs creating new ones. > And any interactions with other APIs that create or delete files with the same name. (file channels, zip, etc?) These interactions also occurred to me. They would be impossible to account for. > Since deleteOnExit() is an deliberate act, perhaps there should be a corresponding withdrawDeleteOnExit() that reverses it so that it is intentional and not a side-effect of other File methods. I think this is a better idea. Perhaps ?cancelDeleteOnExit()?. Thanks, Brian From brian.burkhalter at oracle.com Tue Jul 9 18:08:57 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 9 Jul 2019 11:08:57 -0700 Subject: 8193072: File.delete() should remove its path from DeleteOnExitHook.files In-Reply-To: <096A2B42-5635-4254-92CA-2EB2758BD5D1@oracle.com> References: <9608451A-321D-4CD7-9DD9-04524AC4F53D@oracle.com> <0525c4cf-4a02-1f9b-2950-a0750cbf4a48@oracle.com> <0d67cb9d-96d1-9e55-dda5-31ede2770cfd@oracle.com> <0ab34cb3-38c6-1e62-cc1c-13b9d343ab6c@oracle.com> <096A2B42-5635-4254-92CA-2EB2758BD5D1@oracle.com> Message-ID: <777C2632-ABF3-496A-BB82-01A9733DD747@oracle.com> > On Jul 9, 2019, at 8:31 AM, Brian Burkhalter wrote: > >> Since deleteOnExit() is an deliberate act, perhaps there should be a corresponding withdrawDeleteOnExit() that reverses it so that it is intentional and not a side-effect of other File methods. > > I think this is a better idea. Perhaps ?cancelDeleteOnExit()?. If we want to go this route, here is one possibility: http://cr.openjdk.java.net/~bpb/8193072/webrev.02/ Of course a CSR would be called for if this is agreed upon. Thanks, Brian From brent.christian at oracle.com Tue Jul 9 20:15:24 2019 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 9 Jul 2019 13:15:24 -0700 Subject: The final optimized version of Dual-Pivot Quicksort (ver.19.1) In-Reply-To: <1560893862.105095134@f487.i.mail.ru> References: <1560893862.105095134@f487.i.mail.ru> Message-ID: <5ab79374-a561-de15-6a35-0dde138fdcb9@oracle.com> Hi, Is the webrev incomplete? It only contains the changes for DualPivotQuicksort.java, and not for Arrays.java, etc. Thanks, -Brent On 6/18/19 2:37 PM, Vladimir Yaroslavskiy wrote: > Hi team, > > Please review the final optimized version of Dual-Pivot Quicksort (ver.19.1), > see http://cr.openjdk.java.net/~alanb/8226297/0/webrev > (link to Jira task https://bugs.openjdk.java.net/browse/JDK-8226297) > > The new version was published here more than one year ago (on Jan 19, 2018). > Since that time Dual-Pivot Quicksort has been significantly improved > and this work was done in collaboration with Doug Lea and Laurent Bourges. > > You can find summary of all changes below. > > DualPivotQuicksort.java > ---------------------------------------------------------------------- > * The 1-st and 5-th candidates are taken as pivots > instead of 2-nd and 4-th > * Pivots are chosen with another step > * Pivot candidates are sorted by combination of > 5-element network sorting and insertion sort > * New backwards partitioning was introduced > * Partitioning is related to the golden ratio > * Quicksort tuning parameters were updated > * Thresholds for byte / char / short sorting were updated > * Additional steps for float / double were fully rewritten > * Parallel sorting is based on combination of merge sort > and Dual-Pivot Quicksort > * Pair insertion sort was optimized and became a part > of mixed insertion sort > * Mixed insertion sort was introduced: combination > of simple insertion sort, pin insertion sort and > pair insertion sort > * Simple insertion sort is invoked on tiny array > * Pin insertion sort is started on small array > * Pair insertion sort is continued on remain part > * Merging of runs is invoked on each iteration of Quicksort > * Merging of runs was fully rewritten > * Optimal partitioning of merging is used > * Not more than one copy of part to buffer during merging > * Merging parameters were updated > * Initial capacity of runs is based on size > * Max number of runs is constant > * Optimized version of heap sort was introduced > * Heap sort is used as a guard against quadratic time > (int / long / float / double) > * Parallel merging of runs was also provided > * Parallel sorting, heap sort and merging of runs > are not used in byte / char / short sorting > * Counting sort for byte / char / short were optimized > * Counting sort is used as a guard against quadratic time > (byte / char / short) > * Code style and javadoc improvements > > Sorting.java > ---------------------------------------------------------------------- > * New test cases were added > * Test cases are invoked for both: sequential and > parallel sorting > * Check for Object sorting was added > * New tests were added against heap sort > * Added test case against bug in parallel merge > sort on float / double data > > ParallelSorting.java > ---------------------------------------------------------------------- > * This class was removed, because Sorting class > covers all cases > > SortingHelper.java > ---------------------------------------------------------------------- > * The helper class provides access package-private > methods of DualPivotQuicksort class during testing > > Arrays.java > ---------------------------------------------------------------------- > * Calls of Dual-Pivot Quicksort were updated > * Parallel sorting of primitives was switched to parallel > Dual-Pivot Quicksort > * Javadoc was updated, double spaces were removed > * Format changes > > ArraysParallelSortHelpers.java > ---------------------------------------------------------------------- > * Implementation of parallel sorting > for primitives was removed > * Javadoc was updated > > Thank you, > Vladimir > From lance.andersen at oracle.com Tue Jul 9 20:55:22 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 9 Jul 2019 16:55:22 -0400 Subject: RFR [14] JDK-8225763 Inflater and Deflater should implement AutoCloseable In-Reply-To: <1a0052f8-dc3f-9102-942e-e66e6f5ad694@gmail.com> References: <1a0052f8-dc3f-9102-942e-e66e6f5ad694@gmail.com> Message-ID: <78E885C6-733F-46D7-A21F-F83E09E20DAE@oracle.com> Hi Jaikiran, Again, thank you for your efforts here. Is there a CSR for this yet? This will need to approved prior to moving forward with committing the feature. I can sponsor once everything has been approved and finalized. ??? @implSpec This method is a no-op if this compressor has already 886 * been previously closed, ???? Please remove ?already? in both the close() and end() methods. I believe the preference is the @implSpec and its relatives are on their own line as in https://openjdk.java.net/jeps/8068562 and was done for @apiNote earlier - Undefined behavior after close()/end() I am not convinced the new wording is an improvement and I know Stuart was not thrilled with the existing wording. However given the classes may be subclassed, I am not sure we can truly specify the behavior which could be why the original authors used that wording. Stuart thoughts? Outside of the @ImplSpec, I am not sure the initial wording for end() and close() really need to differ: end(): Closes the decompressor and discards any unprocessed input. close(): Releases resources held by this decompressor and discards any unprocessed input.This method should be called when the decompressor is no longer needed > On Jul 9, 2019, at 9:18 AM, Jaikiran Pai wrote: > > Can I please get a review and a sponsor for the patch that implements > the enhancement noted in https://bugs.openjdk.java.net/browse/JDK-8225763 ? > > There has been a recent discussion about this change in the > core-libs-dev mailing list here[1]. The latest version of the patch for > this change is now available at [2]. > > Here's a summary of what's contained in this patch: > > - The Inflater/Deflater class now implements AutoCloseable > > - The class level javadoc of both these classes has been to updated to > use newer style of code, with try-with-resources, for the example > contained in that javadoc. The @apiNote in these class level javadoc has > also been updated to mention the use of close() method for releasing > resources. > > - The javadoc of end() method in both these classes has been updated to > encourage the use of close() method instead of this one. It now also has > a @implSpec which states that it's a no-op if called more than once. > > In addition, this javadoc has also been updated to replace the > "undefined behaviour" statement with a mention that the usage of the > Inflater/Deflater instance after a call to end() may throw an exception > in those subsequent usages. Please note that, there's no such explicit > mention in the javadoc of the (newly added) close() method because IMO, > it isn't needed for close() since I think it's kind of implied that a > closed resource can no longer be used for further operations. We need to be specific in close() also for clarity > > - The new close() method has been added along with javadoc which uses an > @implSpec to state that it internally calls end() > > - TotalInOut.java test has been updated to use the new > try-with-resources construct for the inflater and deflater it uses. Please update @biug to include the bug number > > - A couple of new (testng) test classes have been added to test various > scenarios where close() and end() method get called. These test mostly > focus on ensuring that the close() and end(), either implicitly or > explicitly, get called the right number of times on the subclasses of > Inflater/Deflater. Overall they look OK. In your tests, you are testing the number of calls for the sub-classes not for Deflate/Inflate so I would either update your comments to clarify that or pull them into their own test methods Again, thank you for your efforts here. Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From huizhe.wang at oracle.com Tue Jul 9 21:17:20 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 9 Jul 2019 14:17:20 -0700 Subject: RFR [14/java.xml] 7148925: StAXSource causes exceptions to be thrown with certain wellformed XML instances Message-ID: <8c9ab17a-55d0-62bf-a513-9d959d97e4cc@oracle.com> Please review a fix for an Exception caused by StAXSource. The fix adds code that processes the prolog and misc content as specified by the XML specification, and removes the code that made incorrect assumption about XML document structure. https://bugs.openjdk.java.net/browse/JDK-7148925 http://cr.openjdk.java.net/~joehw/jdk14/7148925/webrev/ Thanks, Joe From jason_mehrens at hotmail.com Tue Jul 9 21:22:54 2019 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Tue, 9 Jul 2019 21:22:54 +0000 Subject: 8193072: File.delete() should remove its path from DeleteOnExitHook.files In-Reply-To: References: <9608451A-321D-4CD7-9DD9-04524AC4F53D@oracle.com> <0525c4cf-4a02-1f9b-2950-a0750cbf4a48@oracle.com> <0d67cb9d-96d1-9e55-dda5-31ede2770cfd@oracle.com>, Message-ID: Brian, Just a note, one issue I see with webrev.01 is that JDK-7092892 is not resolved. On one hand more calls to DeleteOnExitHook should trigger class init sooner avoiding the issue. On the other it seems this could be more methods that could fail by throwing ExceptionInInitializerError that wouldn't have before the change. I would think that you would want to mark JDK-7092892 as blocker of JDK-8193072 before you go this route. Jason ________________________________________ From: core-libs-dev on behalf of Brian Burkhalter Sent: Tuesday, July 9, 2019 10:07 AM To: Roger Riggs Cc: core-libs-dev at openjdk.java.net Subject: Re: 8193072: File.delete() should remove its path from DeleteOnExitHook.files Hi Roger, You might be correct but I wrote up a different version at the end of yesterday. Not sure it is right but I might as well post it: http://cr.openjdk.java.net/~bpb/8193072/webrev.01/ Thanks, Brian > On Jul 9, 2019, at 7:34 AM, Roger Riggs wrote: > > The sequence described is the specified behavior of the API, whether it is a developer mistake or not is unknowable but it would be a compatibility issue to change it. The filename is the key and there is no way to determine if it is the original file or a replacement. deleteOnExit Wins! From jason_mehrens at hotmail.com Tue Jul 9 21:26:58 2019 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Tue, 9 Jul 2019 21:26:58 +0000 Subject: 8193072: File.delete() should remove its path from DeleteOnExitHook.files In-Reply-To: <777C2632-ABF3-496A-BB82-01A9733DD747@oracle.com> References: <9608451A-321D-4CD7-9DD9-04524AC4F53D@oracle.com> <0525c4cf-4a02-1f9b-2950-a0750cbf4a48@oracle.com> <0d67cb9d-96d1-9e55-dda5-31ede2770cfd@oracle.com> <0ab34cb3-38c6-1e62-cc1c-13b9d343ab6c@oracle.com> <096A2B42-5635-4254-92CA-2EB2758BD5D1@oracle.com>, <777C2632-ABF3-496A-BB82-01A9733DD747@oracle.com> Message-ID: Would the SecurityManager need to for permissions (checkWrite or some new permission) before cancelDeleteOnExit() is allowed? Jason ________________________________________ From: core-libs-dev on behalf of Brian Burkhalter Sent: Tuesday, July 9, 2019 1:08 PM To: core-libs-dev Subject: Re: 8193072: File.delete() should remove its path from DeleteOnExitHook.files > On Jul 9, 2019, at 8:31 AM, Brian Burkhalter wrote: > >> Since deleteOnExit() is an deliberate act, perhaps there should be a corresponding withdrawDeleteOnExit() that reverses it so that it is intentional and not a side-effect of other File methods. > > I think this is a better idea. Perhaps ?cancelDeleteOnExit()?. If we want to go this route, here is one possibility: http://cr.openjdk.java.net/~bpb/8193072/webrev.02/ Of course a CSR would be called for if this is agreed upon. Thanks, Brian From lance.andersen at oracle.com Tue Jul 9 22:07:25 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 9 Jul 2019 18:07:25 -0400 Subject: RFR [14/java.xml] 7148925: StAXSource causes exceptions to be thrown with certain wellformed XML instances In-Reply-To: <8c9ab17a-55d0-62bf-a513-9d959d97e4cc@oracle.com> References: <8c9ab17a-55d0-62bf-a513-9d959d97e4cc@oracle.com> Message-ID: Hi Joe, Overall, this looks good. Please add the bug number to the top @bug in the test class. I might have defined all of the elements in the DataProvider ?xml? in separate String objects to make it easier to read, but no big deal and does not need changed prior to pushing. > On Jul 9, 2019, at 5:17 PM, Joe Wang wrote: > > Please review a fix for an Exception caused by StAXSource. The fix adds code that processes the prolog and misc content as specified by the XML specification, and removes the code that made incorrect assumption about XML document structure. > > https://bugs.openjdk.java.net/browse/JDK-7148925 > http://cr.openjdk.java.net/~joehw/jdk14/7148925/webrev/ > > Thanks, > Joe Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From huizhe.wang at oracle.com Tue Jul 9 22:25:40 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 9 Jul 2019 15:25:40 -0700 Subject: RFR [14/java.xml] 7148925: StAXSource causes exceptions to be thrown with certain wellformed XML instances In-Reply-To: References: <8c9ab17a-55d0-62bf-a513-9d959d97e4cc@oracle.com> Message-ID: On 7/9/19 3:07 PM, Lance Andersen wrote: > Hi Joe, > > Overall, this looks good. Thanks Lance! > > Please add the bug number to the top @bug in the test class. Added. > > > I might have defined all of the elements in the DataProvider ?xml? in > separate String objects to make it easier to read, but no big deal and > does not need changed prior to pushing. Thanks. I'm going to keep them this way then ;-)? They are small enough. -Joe > > > > >> On Jul 9, 2019, at 5:17 PM, Joe Wang > > wrote: >> >> Please review a fix for an Exception caused by StAXSource. The fix >> adds code that processes the prolog and misc content as specified by >> the XML specification, and removes the code that made incorrect >> assumption about XML document structure. >> >> https://bugs.openjdk.java.net/browse/JDK-7148925 >> http://cr.openjdk.java.net/~joehw/jdk14/7148925/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 joe.darcy at oracle.com Tue Jul 9 23:14:10 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 9 Jul 2019 16:14:10 -0700 Subject: JDK 14 RFR of JDK-8202385: Annotation to mark serial-related fields and methods Message-ID: 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 brian.burkhalter at oracle.com Tue Jul 9 23:40:46 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 9 Jul 2019 16:40:46 -0700 Subject: 8193072: File.delete() should remove its path from DeleteOnExitHook.files In-Reply-To: References: <9608451A-321D-4CD7-9DD9-04524AC4F53D@oracle.com> <0525c4cf-4a02-1f9b-2950-a0750cbf4a48@oracle.com> <0d67cb9d-96d1-9e55-dda5-31ede2770cfd@oracle.com> <0ab34cb3-38c6-1e62-cc1c-13b9d343ab6c@oracle.com> <096A2B42-5635-4254-92CA-2EB2758BD5D1@oracle.com> <777C2632-ABF3-496A-BB82-01A9733DD747@oracle.com> Message-ID: <814660AF-A928-4A0A-93FE-9F8524EC7776@oracle.com> I don?t know. On the one hand this does not take an action like reading, writing, or deleting, but on the other it could end up causing files to be left lying around after VM termination which were expected to be deleted. I suppose that could be considered to be some sort of security issue. Thanks, Brian > On Jul 9, 2019, at 2:26 PM, Jason Mehrens wrote: > > Would the SecurityManager need to for permissions (checkWrite or some new permission) before cancelDeleteOnExit() is allowed? From stuart.marks at oracle.com Wed Jul 10 02:32:38 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 9 Jul 2019 19:32:38 -0700 Subject: EnumSet.class serialization broken - twice - JDK-8227368 In-Reply-To: <3a163c20-3c9d-8a61-5fab-ca52a354391f@gmail.com> References: <323f32f3-c242-c083-4d15-2754a3480730@oracle.com> <812af6a1-6836-2f51-ab18-ba9b202b0547@gmail.com> <72b10257-43a5-5959-5708-7de0ef7c27e4@oracle.com> <3a163c20-3c9d-8a61-5fab-ca52a354391f@gmail.com> Message-ID: >> 1. New changeset with constant version of EnumSet.serialVersionUID. > > This is already in the webrev.01 changeset. webrev.02 is an attempt to sneak the change without being visible in the serialized-form.html. Ah. I skipped webrev.01 because I thought that webrev.02 had superseded it. Looking at webrev.01, I see > + // value computed from JDK 8 (and previous) EnumSet class > + // needed to properly cross-(de)serialize EnumSet.class objects > + // between JDK 8- <-> JDK 9+ > + private static final long serialVersionUID = 1009687484059888093L; > + I don't think this comment can cover the entire history here. We'll have to rely on the bug report, the CSR, and the email archives. Most declarations of serialVersionUID don't have a comment at all. So, we could just omit it. If you feel a comment is necessary, perhaps something like // declare serialization compatibility with JDK 8 (see JDK-8227368) might be sufficient. Otherwise, webrev.01 looks fine. > On 7/9/19 1:57 AM, Stuart Marks wrote: >> 2. Create draft CSR. > > Created: > > https://bugs.openjdk.java.net/browse/JDK-8227432 I've done some editing on this CSR and I've marked myself as a reviewer. Please move this to Finalized. While we're waiting for the CSR to be approved (I hope this takes only a day or two) I'll do some testing with your patch. Thanks, s'marks From jai.forums2013 at gmail.com Wed Jul 10 05:47:17 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Wed, 10 Jul 2019 11:17:17 +0530 Subject: RFR [14] JDK-8225763 Inflater and Deflater should implement AutoCloseable In-Reply-To: <78E885C6-733F-46D7-A21F-F83E09E20DAE@oracle.com> References: <1a0052f8-dc3f-9102-942e-e66e6f5ad694@gmail.com> <78E885C6-733F-46D7-A21F-F83E09E20DAE@oracle.com> Message-ID: <2cc872bb-1220-22dc-0840-c00bff799944@gmail.com> Hello Lance, On 10/07/19 2:25 AM, Lance Andersen wrote: > Hi Jaikiran, > > Again, thank you for your efforts here. > > Is there a CSR for this yet?? There isn't one yet. I will need help on this part, since I haven't created a CSR before. Is this something that I can create (I'm just a "author" in the JDK project)? If yes, is there some specific things I need to do? I'll reply to the rest of the review comments soon. Thank you very much for doing this review and offering to sponsor. -Jaikiran > This will need to approved prior to moving forward with committing the > feature. > > I can sponsor once everything has been approved and finalized. > > > > > ??? > @implSpec This method is a no-op if this compressor has already > 886 * been previously closed, > > ???? > > Please remove ?already? in both the close() and end() methods. ?I > believe the preference is the @implSpec and its relatives are on their > own line as in?https://openjdk.java.net/jeps/8068562?and was done for > @apiNote earlier > > ?- Undefined behavior after close()/end() > > I am not convinced the new?wording is an improvement and I know Stuart > was not thrilled with the existing wording. ?However given the classes > may be subclassed, I am not sure we ?can truly specify the?behavior > which could be why the original authors used that wording. ? Stuart > thoughts? > > > Outside of the @ImplSpec, I am not sure the initial wording for end() > and close() really need to differ: > > end(): > > Closes the decompressor and discards any unprocessed input. > > close(): > > Releases resources held by this decompressor and discards any > unprocessed input.This method should be called when the > decompressor is no longer needed > > > > >> On Jul 9, 2019, at 9:18 AM, Jaikiran Pai > > wrote: >> >> Can I please get a review and a sponsor for the patch that implements >> the enhancement noted in >> https://bugs.openjdk.java.net/browse/JDK-8225763 ? >> >> There has been a recent discussion about this change in the >> core-libs-dev mailing list here[1]. The latest version of the patch for >> this change is now available at [2]. >> >> Here's a summary of what's contained in this patch: >> >> - The Inflater/Deflater class now implements AutoCloseable >> >> - The class level javadoc of both these classes has been to updated to >> use newer style of code, with try-with-resources, for the example >> contained in that javadoc. The @apiNote in these class level javadoc has >> also been updated to mention the use of close() method for releasing >> resources. >> >> - The javadoc of end() method in both these classes has been updated to >> encourage the use of close() method instead of this one. It now also has >> a @implSpec which states that it's a no-op if called more than once. >> >> In addition, this javadoc has also been updated to replace the >> "undefined behaviour" statement with a mention that the usage of the >> Inflater/Deflater instance after a call to end() may throw an exception >> in those subsequent usages. Please note that, there's no such explicit >> mention in the javadoc of the (newly added) close() method because IMO, >> it isn't needed for close() since I think it's kind of implied that a >> closed resource can no longer be used for further operations. > > We need to be specific in close() ?also for clarity >> >> - The new close() method has been added along with javadoc which uses an >> @implSpec to state that it internally calls end() >> >> - TotalInOut.java test has been updated to use the new >> try-with-resources construct for the inflater and deflater it uses. > > Please update @biug to include the bug number >> >> - A couple of new (testng) test classes have been added to test various >> scenarios where close() and end() method get called. These test mostly >> focus on ensuring that the close() and end(), either implicitly or >> explicitly, get called the right number of times on the subclasses of >> Inflater/Deflater. > > Overall they look OK. ?In your tests, you are testing the number of > calls for the sub-classes not for Deflate/Inflate so I would either > update your comments to clarify that or pull them into their own test > methods > > > Again, thank you for your efforts here. > > Best > Lance > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle?Java Engineering? > 1 Network Drive? > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From ying.z.zhou at oracle.com Wed Jul 10 06:53:31 2019 From: ying.z.zhou at oracle.com (Ying Zhou) Date: Wed, 10 Jul 2019 14:53:31 +0800 Subject: [14]RFR of JDK-8227289:Enable assertions for some shell to java conversion tests after JDK-8218960 Message-ID: Hello, Please review this patch for updating below tests by adding -ea/esa to launcher parameters. - /test/jdk/java/util/Calendar/SupplementalJapaneseEraTestRun.java - /test/jdk/java/util/TimeZone/TimeZoneDatePermissionCheckRun.java - /test/jdk/java/util/TimeZone/Bug8066652Run.java - /test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTestRun.java - /test/jdk/java/util/ResourceBundle/modules/ModuleTestUtil.java - /test/jdk/java/util/ResourceBundle/modules/layer/LayerTest.java - /test/jdk/java/util/ResourceBundle/modules/unnamed/UnNamedTest.java - /test/jdk/java/util/ResourceBundle/modules/visibility/VisibilityTest.java JDK Bug: JDK-8227289 webrev: http://cr.openjdk.java.net/~yzhou/8227289/webrev.00/ Thanks, Daisy From jai.forums2013 at gmail.com Wed Jul 10 06:56:51 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Wed, 10 Jul 2019 12:26:51 +0530 Subject: RFR [14] JDK-8225763 Inflater and Deflater should implement AutoCloseable In-Reply-To: <78E885C6-733F-46D7-A21F-F83E09E20DAE@oracle.com> References: <1a0052f8-dc3f-9102-942e-e66e6f5ad694@gmail.com> <78E885C6-733F-46D7-A21F-F83E09E20DAE@oracle.com> Message-ID: Hello Lance, On 10/07/19 2:25 AM, Lance Andersen wrote: > ??? > @implSpec This method is a no-op if this compressor has already > 886 * been previously closed, > > ???? > > Please remove ?already? in both the close() and end() methods. Done. > ?I believe the preference is the @implSpec and its relatives are on > their own line as in?https://openjdk.java.net/jeps/8068562?and was > done for @apiNote earlier Done. > > Outside of the @ImplSpec, I am not sure the initial wording for end() > and close() really need to differ: > > end(): > > Closes the decompressor and discards any unprocessed input. > > close(): > > Releases resources held by this decompressor and discards any > unprocessed input.This method should be called when the > decompressor is no longer needed > > I have now updated the javadoc of end() to be closer to the javadoc of close(). > >> - The javadoc of end() method in both these classes has been updated to >> encourage the use of close() method instead of this one. It now also has >> a @implSpec which states that it's a no-op if called more than once. >> >> In addition, this javadoc has also been updated to replace the >> "undefined behaviour" statement with a mention that the usage of the >> Inflater/Deflater instance after a call to end() may throw an exception >> in those subsequent usages. Please note that, there's no such explicit >> mention in the javadoc of the (newly added) close() method because IMO, >> it isn't needed for close() since I think it's kind of implied that a >> closed resource can no longer be used for further operations. > > We need to be specific in close() ?also for clarity I haven't updated this in the latest webrev version and will wait for us to come to a decision on how we word it for end(). >> >> >> - TotalInOut.java test has been updated to use the new >> try-with-resources construct for the inflater and deflater it uses. > > Please update @biug to include the bug number Done. >> >> - A couple of new (testng) test classes have been added to test various >> scenarios where close() and end() method get called. These test mostly >> focus on ensuring that the close() and end(), either implicitly or >> explicitly, get called the right number of times on the subclasses of >> Inflater/Deflater. > > Overall they look OK. ?In your tests, you are testing the number of > calls for the sub-classes not for Deflate/Inflate so I would either > update your comments to clarify that or pull them into their own test > methods > I did not understand this. Did you mean I should update the @summary part of these tests or was it the javadoc on these test methods? The latest webrev with the above noted changes is available at http://cr.openjdk.java.net/~jpai/webrev/8225763/3/webrev/ -Jaikiran From jai.forums2013 at gmail.com Wed Jul 10 06:58:08 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Wed, 10 Jul 2019 12:28:08 +0530 Subject: RFR [14] JDK-8225763 Inflater and Deflater should implement AutoCloseable In-Reply-To: References: <1a0052f8-dc3f-9102-942e-e66e6f5ad694@gmail.com> Message-ID: On 09/07/19 8:44 PM, David Lloyd wrote: > On Tue, Jul 9, 2019 at 8:19 AM Jaikiran Pai wrote: >> - In addition, I have sneaked in an unrelated change in this patch, into >> the Deflater.end() method: >> >> public void end() { >> synchronized (zsRef) { >> + // check if already closed >> + if (zsRef.address() == 0) { >> + return; >> + } >> zsRef.clean(); >> input = ZipUtils.defaultBuf; >> + inputArray = null; >> + } >> >> Unlike in the Inflater.end(), the Deflater.end() didn't previously have >> the "inputArray = null". I have included it in this patch, since it >> looks right to clean up that array too. If this isn't the right >> time/patch to do it, please do let me know and I'll take that up separately. > This was probably my mistake. The fix looks good to me! Thank you David. -Jaikiran From peter.levart at gmail.com Wed Jul 10 11:32:49 2019 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 10 Jul 2019 13:32:49 +0200 Subject: EnumSet.class serialization broken - twice - JDK-8227368 In-Reply-To: References: <323f32f3-c242-c083-4d15-2754a3480730@oracle.com> <812af6a1-6836-2f51-ab18-ba9b202b0547@gmail.com> <72b10257-43a5-5959-5708-7de0ef7c27e4@oracle.com> <3a163c20-3c9d-8a61-5fab-ca52a354391f@gmail.com> Message-ID: Hi Stuart, On 7/10/19 4:32 AM, Stuart Marks wrote: >>> 1. New changeset with constant version of EnumSet.serialVersionUID. >> >> This is already in the webrev.01 changeset. webrev.02 is an attempt >> to sneak the change without being visible in the serialized-form.html. > > Ah. I skipped webrev.01 because I thought that webrev.02 had > superseded it. Looking at webrev.01, I see > >> +??? // value computed from JDK 8 (and previous) EnumSet class >> +??? // needed to properly cross-(de)serialize EnumSet.class objects >> +??? // between JDK 8- <-> JDK 9+ >> +??? private static final long serialVersionUID = 1009687484059888093L; >> + > > I don't think this comment can cover the entire history here. We'll > have to rely on the bug report, the CSR, and the email archives. > > Most declarations of serialVersionUID don't have a comment at all. So, > we could just omit it. > > If you feel a comment is necessary, perhaps something like > > // declare serialization compatibility with JDK 8 (see JDK-8227368) I created webrev.03 with your proposed comment: http://cr.openjdk.java.net/~plevart/jdk-dev/8227368_EnumSet.class_serialization/webrev.03/ > > might be sufficient. Otherwise, webrev.01 looks fine. > >> On 7/9/19 1:57 AM, Stuart Marks wrote: >>> 2. Create draft CSR. >> >> Created: >> >> https://bugs.openjdk.java.net/browse/JDK-8227432 > > I've done some editing on this CSR and I've marked myself as a > reviewer. Please move this to Finalized. Thank you for your edits. It reads much better now :-) I have Finalized it. > > While we're waiting for the CSR to be approved (I hope this takes only > a day or two) I'll do some testing with your patch. Thank you for testing. Regards, Peter From peter.levart at gmail.com Wed Jul 10 12:36:07 2019 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 10 Jul 2019 14:36:07 +0200 Subject: 8193072: File.delete() should remove its path from DeleteOnExitHook.files In-Reply-To: <777C2632-ABF3-496A-BB82-01A9733DD747@oracle.com> References: <9608451A-321D-4CD7-9DD9-04524AC4F53D@oracle.com> <0525c4cf-4a02-1f9b-2950-a0750cbf4a48@oracle.com> <0d67cb9d-96d1-9e55-dda5-31ede2770cfd@oracle.com> <0ab34cb3-38c6-1e62-cc1c-13b9d343ab6c@oracle.com> <096A2B42-5635-4254-92CA-2EB2758BD5D1@oracle.com> <777C2632-ABF3-496A-BB82-01A9733DD747@oracle.com> Message-ID: Hi, On 7/9/19 8:08 PM, Brian Burkhalter wrote: >> On Jul 9, 2019, at 8:31 AM, Brian Burkhalter wrote: >> >>> Since deleteOnExit() is an deliberate act, perhaps there should be a corresponding withdrawDeleteOnExit() that reverses it so that it is intentional and not a side-effect of other File methods. >> I think this is a better idea. Perhaps ?cancelDeleteOnExit()?. > If we want to go this route, here is one possibility: > > http://cr.openjdk.java.net/~bpb/8193072/webrev.02/ > > With only one method (deleteOnExit) there are no races because the method is idempotent if called with the same File multiple times from different threads. Adding cancelDeleteOnExit() makes things problematic in concurrent setting. Imagine the following code: ??????? File f = new File("/path/to/file"); ??? ??? // 1st register hook... ??????? f.deleteOnExit(); ??????? // ...then attempt file creation so there's no chance ??????? // the file is left behind if VM unexpectedly exits ??????? if (f.createNewFile()) { ??????????? ... ??? ??? ??? ... process something using f ??????????? ... ??????????? // 1st delete file... ??????????? f.delete(); ??????? } ??????? // ...then unregister hook so there's no chance ??????? // the file is left behind if VM unexpectedly exits ??????? // unregister hook also after we registered it but ??????? // then file creation failed. ??????? f.undoDeleteOnExit(); This code is correct if executed in a single thread. But imagine two or more threads competing to create the same file and properly delete it afterwards with registering and un-registering the hook to cover cleanup when VM exits during processing... There are various interleavings of threads that could cause the file to be left undeleted when VM exits. To cover concurrent scenarios such as above, the code could use reference counting. Like in the following patch: http://cr.openjdk.java.net/~plevart/jdk-dev/8193072_File.undoDeleteOnExit/webrev.01/ Regards, Peter From sean.mullan at oracle.com Wed Jul 10 14:51:07 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 10 Jul 2019 10:51:07 -0400 Subject: 8193072: File.delete() should remove its path from DeleteOnExitHook.files In-Reply-To: <814660AF-A928-4A0A-93FE-9F8524EC7776@oracle.com> References: <9608451A-321D-4CD7-9DD9-04524AC4F53D@oracle.com> <0525c4cf-4a02-1f9b-2950-a0750cbf4a48@oracle.com> <0d67cb9d-96d1-9e55-dda5-31ede2770cfd@oracle.com> <0ab34cb3-38c6-1e62-cc1c-13b9d343ab6c@oracle.com> <096A2B42-5635-4254-92CA-2EB2758BD5D1@oracle.com> <777C2632-ABF3-496A-BB82-01A9733DD747@oracle.com> <814660AF-A928-4A0A-93FE-9F8524EC7776@oracle.com> Message-ID: On 7/9/19 7:40 PM, Brian Burkhalter wrote: > I don?t know. On the one hand this does not take an action like reading, writing, or deleting, but on the other it could end up causing files to be left lying around after VM termination which were expected to be deleted. I suppose that could be considered to be some sort of security issue. Yes I think so. I would probably just use the same permission (FilePermission(file,"delete")). If you have been granted permission to delete a file, then you should have permission to cancel that deletion as well. --Sean > > > Thanks, > > Brian > >> On Jul 9, 2019, at 2:26 PM, Jason Mehrens wrote: >> >> Would the SecurityManager need to for permissions (checkWrite or some new permission) before cancelDeleteOnExit() is allowed? > From joe.darcy at oracle.com Wed Jul 10 16:03:47 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 10 Jul 2019 09:03:47 -0700 Subject: EnumSet.class serialization broken - twice - JDK-8227368 In-Reply-To: References: <323f32f3-c242-c083-4d15-2754a3480730@oracle.com> <812af6a1-6836-2f51-ab18-ba9b202b0547@gmail.com> <72b10257-43a5-5959-5708-7de0ef7c27e4@oracle.com> <3a163c20-3c9d-8a61-5fab-ca52a354391f@gmail.com> Message-ID: <7019e96d-0281-875c-432a-8381eac82dcf@oracle.com> Hello, I'd advise against including at least part of the comment ??? // declare serialization compatibility with JDK 8 (see JDK-8227368) We generally don't include bug numbers in the text of the code and rely mapping from the SCM to the bug database to provide the (sometimes large!) additional context for a fix. Cheers, -Joe On 7/10/2019 4:32 AM, Peter Levart wrote: > Hi Stuart, > > On 7/10/19 4:32 AM, Stuart Marks wrote: >>>> 1. New changeset with constant version of EnumSet.serialVersionUID. >>> >>> This is already in the webrev.01 changeset. webrev.02 is an attempt >>> to sneak the change without being visible in the serialized-form.html. >> >> Ah. I skipped webrev.01 because I thought that webrev.02 had >> superseded it. Looking at webrev.01, I see >> >>> +??? // value computed from JDK 8 (and previous) EnumSet class >>> +??? // needed to properly cross-(de)serialize EnumSet.class objects >>> +??? // between JDK 8- <-> JDK 9+ >>> +??? private static final long serialVersionUID = 1009687484059888093L; >>> + >> >> I don't think this comment can cover the entire history here. We'll >> have to rely on the bug report, the CSR, and the email archives. >> >> Most declarations of serialVersionUID don't have a comment at all. >> So, we could just omit it. >> >> If you feel a comment is necessary, perhaps something like >> >> // declare serialization compatibility with JDK 8 (see JDK-8227368) > > I created webrev.03 with your proposed comment: > > http://cr.openjdk.java.net/~plevart/jdk-dev/8227368_EnumSet.class_serialization/webrev.03/ > > >> >> might be sufficient. Otherwise, webrev.01 looks fine. >> >>> On 7/9/19 1:57 AM, Stuart Marks wrote: >>>> 2. Create draft CSR. >>> >>> Created: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8227432 >> >> I've done some editing on this CSR and I've marked myself as a >> reviewer. Please move this to Finalized. > > Thank you for your edits. It reads much better now :-) I have > Finalized it. > >> >> While we're waiting for the CSR to be approved (I hope this takes >> only a day or two) I'll do some testing with your patch. > > Thank you for testing. > > Regards, Peter > From naoto.sato at oracle.com Wed Jul 10 16:12:32 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 10 Jul 2019 09:12:32 -0700 Subject: [14]RFR of JDK-8227289:Enable assertions for some shell to java conversion tests after JDK-8218960 In-Reply-To: References: Message-ID: Looks good to me. Naoto On 7/9/19 11:53 PM, Ying Zhou wrote: > Hello, > > Please review this patch for updating below tests by adding -ea/esa to > launcher parameters. > > - /test/jdk/java/util/Calendar/SupplementalJapaneseEraTestRun.java > - /test/jdk/java/util/TimeZone/TimeZoneDatePermissionCheckRun.java > - /test/jdk/java/util/TimeZone/Bug8066652Run.java > - > /test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTestRun.java > - /test/jdk/java/util/ResourceBundle/modules/ModuleTestUtil.java > - /test/jdk/java/util/ResourceBundle/modules/layer/LayerTest.java > - /test/jdk/java/util/ResourceBundle/modules/unnamed/UnNamedTest.java > - /test/jdk/java/util/ResourceBundle/modules/visibility/VisibilityTest.java > > JDK Bug: JDK-8227289 > > webrev: http://cr.openjdk.java.net/~yzhou/8227289/webrev.00/ > > Thanks, > > Daisy From peter.levart at gmail.com Wed Jul 10 16:54:33 2019 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 10 Jul 2019 18:54:33 +0200 Subject: EnumSet.class serialization broken - twice - JDK-8227368 In-Reply-To: <7019e96d-0281-875c-432a-8381eac82dcf@oracle.com> References: <323f32f3-c242-c083-4d15-2754a3480730@oracle.com> <812af6a1-6836-2f51-ab18-ba9b202b0547@gmail.com> <72b10257-43a5-5959-5708-7de0ef7c27e4@oracle.com> <3a163c20-3c9d-8a61-5fab-ca52a354391f@gmail.com> <7019e96d-0281-875c-432a-8381eac82dcf@oracle.com> Message-ID: On 7/10/19 6:03 PM, Joe Darcy wrote: > Hello, > > I'd advise against including at least part of the comment > > ??? // declare serialization compatibility with JDK 8 (see JDK-8227368) > > We generally don't include bug numbers in the text of the code and > rely mapping from the SCM to the bug database to provide the > (sometimes large!) additional context for a fix. Ok, Joe. I removed the reference to bug number and recreated webrev.03 in-place. Will that be OK? http://cr.openjdk.java.net/~plevart/jdk-dev/8227368_EnumSet.class_serialization/webrev.03/ Regards, Peter From brian.burkhalter at oracle.com Wed Jul 10 18:17:00 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 10 Jul 2019 11:17:00 -0700 Subject: 8193072: File.delete() should remove its path from DeleteOnExitHook.files In-Reply-To: References: <9608451A-321D-4CD7-9DD9-04524AC4F53D@oracle.com> <0525c4cf-4a02-1f9b-2950-a0750cbf4a48@oracle.com> <0d67cb9d-96d1-9e55-dda5-31ede2770cfd@oracle.com> <0ab34cb3-38c6-1e62-cc1c-13b9d343ab6c@oracle.com> <096A2B42-5635-4254-92CA-2EB2758BD5D1@oracle.com> <777C2632-ABF3-496A-BB82-01A9733DD747@oracle.com> Message-ID: <2D863386-A47C-491A-93A8-52F870F7F4E8@oracle.com> Peter / Sean, Thanks for the comments. > On Jul 10, 2019, at 5:36 AM, Peter Levart wrote: > > There are various interleavings of threads that could cause the file to be left undeleted when VM exits. > > To cover concurrent scenarios such as above, the code could use reference counting. Like in the following patch: > > http://cr.openjdk.java.net/~plevart/jdk-dev/8193072_File.undoDeleteOnExit/webrev.01/ This looks good to me modulo adding this SecurityManager security = System.getSecurityManager(); if (security != null) { security.checkDelete(path); } to cancelDeleteOnExit() as suggested below. > On Jul 10, 2019, at 7:51 AM, Sean Mullan wrote: > > On 7/9/19 7:40 PM, Brian Burkhalter wrote: >> I don?t know. On the one hand this does not take an action like reading, writing, or deleting, but on the other it could end up causing files to be left lying around after VM termination which were expected to be deleted. I suppose that could be considered to be some sort of security issue. > > Yes I think so. > > I would probably just use the same permission (FilePermission(file,"delete")). If you have been granted permission to delete a file, then you should have permission to cancel that deletion as well. That?s a good idea. Thanks, Brian From huizhe.wang at oracle.com Wed Jul 10 23:57:07 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 10 Jul 2019 16:57:07 -0700 Subject: RFR [14/java.xml] 8178843: A bug in an inner loop in MethodGenerator's getLocals method Message-ID: Please review a cleanup that removes unused code. This code has two errors, one as indicated in the bug report, another attempting to loop through allVarsEverDeclared that was just created (meaning size=0). It just ensures again that the code was never used. JBS: https://bugs.openjdk.java.net/browse/JDK-8178843 webrevs: http://cr.openjdk.java.net/~joehw/jdk14/8178843/webrev/ All tests passed. Thanks, Joe From brian.burkhalter at oracle.com Thu Jul 11 00:17:23 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 10 Jul 2019 17:17:23 -0700 Subject: 8193072: File.delete() should remove its path from DeleteOnExitHook.files In-Reply-To: <2D863386-A47C-491A-93A8-52F870F7F4E8@oracle.com> References: <9608451A-321D-4CD7-9DD9-04524AC4F53D@oracle.com> <0525c4cf-4a02-1f9b-2950-a0750cbf4a48@oracle.com> <0d67cb9d-96d1-9e55-dda5-31ede2770cfd@oracle.com> <0ab34cb3-38c6-1e62-cc1c-13b9d343ab6c@oracle.com> <096A2B42-5635-4254-92CA-2EB2758BD5D1@oracle.com> <777C2632-ABF3-496A-BB82-01A9733DD747@oracle.com> <2D863386-A47C-491A-93A8-52F870F7F4E8@oracle.com> Message-ID: <55C9CB46-46E5-4F80-84BC-95682A0D343B@oracle.com> I incorporated Peter?s version, adding the security check in cancelDeleteOnExit(), tweaking its verbiage along with that of deleteOnExit(), and modified the test DeleteOnExit to verify the new method. The updated version is here: http://cr.openjdk.java.net/~bpb/8193072/webrev.03/ Thanks, Brian > On Jul 10, 2019, at 11:17 AM, Brian Burkhalter wrote: > > On Jul 10, 2019, at 5:36 AM, Peter Levart wrote: >> >> There are various interleavings of threads that could cause the file to be left undeleted when VM exits. >> >> To cover concurrent scenarios such as above, the code could use reference counting. Like in the following patch: >> >> http://cr.openjdk.java.net/~plevart/jdk-dev/8193072_File.undoDeleteOnExit/webrev.01/ > This looks good to me modulo adding this > SecurityManager security = System.getSecurityManager(); > if (security != null) { > security.checkDelete(path); > } > to cancelDeleteOnExit() as suggested below. > >> On Jul 10, 2019, at 7:51 AM, Sean Mullan wrote: >> >> On 7/9/19 7:40 PM, Brian Burkhalter wrote: >>> I don?t know. On the one hand this does not take an action like reading, writing, or deleting, but on the other it could end up causing files to be left lying around after VM termination which were expected to be deleted. I suppose that could be considered to be some sort of security issue. >> >> Yes I think so. >> >> I would probably just use the same permission (FilePermission(file,"delete")). If you have been granted permission to delete a file, then you should have permission to cancel that deletion as well. > > That?s a good idea. From stuart.marks at oracle.com Thu Jul 11 01:34:35 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 10 Jul 2019 18:34:35 -0700 Subject: EnumSet.class serialization broken - twice - JDK-8227368 In-Reply-To: References: <323f32f3-c242-c083-4d15-2754a3480730@oracle.com> <812af6a1-6836-2f51-ab18-ba9b202b0547@gmail.com> <72b10257-43a5-5959-5708-7de0ef7c27e4@oracle.com> <3a163c20-3c9d-8a61-5fab-ca52a354391f@gmail.com> <7019e96d-0281-875c-432a-8381eac82dcf@oracle.com> Message-ID: <8dbef136-0f26-09eb-1739-b71faf4a8ebf@oracle.com> On 7/10/19 9:54 AM, Peter Levart wrote: > On 7/10/19 6:03 PM, Joe Darcy wrote: >> Hello, >> >> I'd advise against including at least part of the comment >> >> ??? // declare serialization compatibility with JDK 8 (see JDK-8227368) >> >> We generally don't include bug numbers in the text of the code and rely >> mapping from the SCM to the bug database to provide the (sometimes large!) >> additional context for a fix. > > Ok, Joe. I removed the reference to bug number and recreated webrev.03 in-place. > Will that be OK? > > http://cr.openjdk.java.net/~plevart/jdk-dev/8227368_EnumSet.class_serialization/webrev.03/ Hi Peter, I'm ok with this patch (i.e., without the bug id). I did a test run and it looks good. Given that Joe approved the CSR, you're now cleared to push. Remember to push to JDK 13! We should probably discuss the JDK 11 backport on jdk-updates, since it'll differ from the JDK 13 patch. Joe, For this patch having the bug id doesn't matter very much, since there is nothing unusual about this code as it stands, and it'll be ok for the long term. However, there are a bunch of places in the source code where we do reference bug reports; they're pretty easy to find. There are perhaps over 100 in java.base alone. (Some include full URLs, which I think is unnecessary.) I think it's easier to go directly to a bug report than to search through the history for bug ids in changeset comments. "hg anno" works reasonably well initially, but as time goes on the changeset associated with a particular line of code can be obscured by incidental refactorings, file renames, etc. For example, I expect the JDK 11 backport to assign the serialVersionUID in a static initializer block (which will require warnings suppression as well). This is unusual and warrants a comment. This could either be a complete explanation (which might run to a paragraph or more) or a reference to a bug id. Sometimes an in-line explanation is warranted, but there's enough history here that in this case a reference to a bug id seems more appropriate. s'marks From lance.andersen at oracle.com Thu Jul 11 01:38:11 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 10 Jul 2019 21:38:11 -0400 Subject: RFR [14/java.xml] 8178843: A bug in an inner loop in MethodGenerator's getLocals method In-Reply-To: References: Message-ID: <1F07D3A9-99F8-4C19-A1E5-092A07357E34@oracle.com> +1 > On Jul 10, 2019, at 7:57 PM, Joe Wang wrote: > > Please review a cleanup that removes unused code. This code has two errors, one as indicated in the bug report, another attempting to loop through allVarsEverDeclared that was just created (meaning size=0). It just ensures again that the code was never used. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8178843 > webrevs: http://cr.openjdk.java.net/~joehw/jdk14/8178843/webrev/ > > All tests passed. > > 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 ivan.gerasimov at oracle.com Thu Jul 11 01:51:08 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 10 Jul 2019 18:51:08 -0700 Subject: 8193072: File.delete() should remove its path from DeleteOnExitHook.files In-Reply-To: <55C9CB46-46E5-4F80-84BC-95682A0D343B@oracle.com> References: <9608451A-321D-4CD7-9DD9-04524AC4F53D@oracle.com> <0525c4cf-4a02-1f9b-2950-a0750cbf4a48@oracle.com> <0d67cb9d-96d1-9e55-dda5-31ede2770cfd@oracle.com> <0ab34cb3-38c6-1e62-cc1c-13b9d343ab6c@oracle.com> <096A2B42-5635-4254-92CA-2EB2758BD5D1@oracle.com> <777C2632-ABF3-496A-BB82-01A9733DD747@oracle.com> <2D863386-A47C-491A-93A8-52F870F7F4E8@oracle.com> <55C9CB46-46E5-4F80-84BC-95682A0D343B@oracle.com> Message-ID: <35f38610-f450-cace-3d21-068b482326ff@oracle.com> On 7/10/19 5:17 PM, Brian Burkhalter wrote: > I incorporated Peter?s version, adding the security check in cancelDeleteOnExit(), tweaking its verbiage along with that of deleteOnExit(), and modified the test DeleteOnExit to verify the new method. The updated version is here: > > http://cr.openjdk.java.net/~bpb/8193072/webrev.03/ There is possibility of a race here in a scenario like this: File dir = new File("dir"); File file = new File("dir/file"); -- thread 1 -- dir.deleteOnExit(); file.deleteOnExit(); /// dir.cancelDeleteOnExit(); ////? thread 2 intervenes file.cancelDeleteOnExit(); -- end -- -- thread 2 -- dir.deleteOnExit(); file.deleteOnExit(); -- end -- The result will be that the order of the registered files will change, and JVM will try to delete dir first (this will fail as it is not empty). Of course it could be avoided, if cancellation were done in reverse order, though it's not immediately obvious from the documentation. With kind regards, Ivan > Thanks, > > Brian > >> On Jul 10, 2019, at 11:17 AM, Brian Burkhalter wrote: >> >> On Jul 10, 2019, at 5:36 AM, Peter Levart wrote: >>> There are various interleavings of threads that could cause the file to be left undeleted when VM exits. >>> >>> To cover concurrent scenarios such as above, the code could use reference counting. Like in the following patch: >>> >>> http://cr.openjdk.java.net/~plevart/jdk-dev/8193072_File.undoDeleteOnExit/webrev.01/ >> This looks good to me modulo adding this >> SecurityManager security = System.getSecurityManager(); >> if (security != null) { >> security.checkDelete(path); >> } >> to cancelDeleteOnExit() as suggested below. >> >>> On Jul 10, 2019, at 7:51 AM, Sean Mullan wrote: >>> >>> On 7/9/19 7:40 PM, Brian Burkhalter wrote: >>>> I don?t know. On the one hand this does not take an action like reading, writing, or deleting, but on the other it could end up causing files to be left lying around after VM termination which were expected to be deleted. I suppose that could be considered to be some sort of security issue. >>> Yes I think so. >>> >>> I would probably just use the same permission (FilePermission(file,"delete")). If you have been granted permission to delete a file, then you should have permission to cancel that deletion as well. >> That?s a good idea. -- With kind regards, Ivan Gerasimov From peter.levart at gmail.com Thu Jul 11 07:47:11 2019 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 11 Jul 2019 09:47:11 +0200 Subject: 8193072: File.delete() should remove its path from DeleteOnExitHook.files In-Reply-To: <35f38610-f450-cace-3d21-068b482326ff@oracle.com> References: <9608451A-321D-4CD7-9DD9-04524AC4F53D@oracle.com> <0525c4cf-4a02-1f9b-2950-a0750cbf4a48@oracle.com> <0d67cb9d-96d1-9e55-dda5-31ede2770cfd@oracle.com> <0ab34cb3-38c6-1e62-cc1c-13b9d343ab6c@oracle.com> <096A2B42-5635-4254-92CA-2EB2758BD5D1@oracle.com> <777C2632-ABF3-496A-BB82-01A9733DD747@oracle.com> <2D863386-A47C-491A-93A8-52F870F7F4E8@oracle.com> <55C9CB46-46E5-4F80-84BC-95682A0D343B@oracle.com> <35f38610-f450-cace-3d21-068b482326ff@oracle.com> Message-ID: <1d81786f-0d4a-c140-38fa-60b7140dcc41@gmail.com> Hi, On 7/11/19 3:51 AM, Ivan Gerasimov wrote: > > On 7/10/19 5:17 PM, Brian Burkhalter wrote: >> I incorporated Peter?s version, adding the security check in >> cancelDeleteOnExit(), tweaking its verbiage along with that of >> deleteOnExit(), and modified the test DeleteOnExit to verify the new >> method. The updated version is here: >> >> http://cr.openjdk.java.net/~bpb/8193072/webrev.03/ >> > There is possibility of a race here in a scenario like this: > > File dir = new File("dir"); > File file = new File("dir/file"); > > -- thread 1 -- > dir.deleteOnExit(); > file.deleteOnExit(); > /// > dir.cancelDeleteOnExit(); > ////? thread 2 intervenes > file.cancelDeleteOnExit(); > -- end -- > > -- thread 2 -- > dir.deleteOnExit(); > file.deleteOnExit(); > -- end -- > > The result will be that the order of the registered files will change, > and JVM will try to delete dir first (this will fail as it is not empty). > > Of course it could be avoided, if cancellation were done in reverse > order, though it's not immediately obvious from the documentation. Hm, LinkedHashMap.computeIfAbsent/computeIfPresent can also honor the so called "access order" which always moves the entry to the end of the linked list regardless of whether the entry is already present or not. So in above scenario and if LinkedHashMap was constructed with accessOrder=true, the registration order of paths after each operation would be as follows (the order of deletion is the reverse order of the presented registration order): File dir = new File("dir"); File file = new File("dir/file"); -- thread 1 -- dir.deleteOnExit(); [dir] file.deleteOnExit(); [dir, dir/file] dir.cancelDeleteOnExit(); [dir/file] -- thread 2 -- dir.deleteOnExit(); [dir/file, dir] file.deleteOnExit(); [dir, dir/file] -- thread 1 -- file.cancelDeleteOnExit(); [dir, dir/file] But that is just coincidence. There are other interleavings which would cause LHM "access order" to reorder paths in undesired way. Perhaps the best behavior would be for deleteOnExit() to reorder the file to the end of the registration list while cancelDeleteOnExit() to not change the order of registered paths. For example, like this: http://cr.openjdk.java.net/~plevart/jdk-dev/8193072_File.undoDeleteOnExit/webrev.02/ This does however change the order of registration for sequences like the following: file1.deleteOnExit(); file2.deleteOnExit(); file1.deleteOnExit(); Order of deletion now: file2, file1 Order of deletion with this patch: file1, file2 But considering that programs that register multiple files do so consistently (always the same set of related files in one go in the same order) or register unrelated files in unimportant order, such behavior is perhaps acceptable. What do you think? Regards, Peter From peter.levart at gmail.com Thu Jul 11 07:52:31 2019 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 11 Jul 2019 09:52:31 +0200 Subject: 8193072: File.delete() should remove its path from DeleteOnExitHook.files In-Reply-To: <1d81786f-0d4a-c140-38fa-60b7140dcc41@gmail.com> References: <9608451A-321D-4CD7-9DD9-04524AC4F53D@oracle.com> <0525c4cf-4a02-1f9b-2950-a0750cbf4a48@oracle.com> <0d67cb9d-96d1-9e55-dda5-31ede2770cfd@oracle.com> <0ab34cb3-38c6-1e62-cc1c-13b9d343ab6c@oracle.com> <096A2B42-5635-4254-92CA-2EB2758BD5D1@oracle.com> <777C2632-ABF3-496A-BB82-01A9733DD747@oracle.com> <2D863386-A47C-491A-93A8-52F870F7F4E8@oracle.com> <55C9CB46-46E5-4F80-84BC-95682A0D343B@oracle.com> <35f38610-f450-cace-3d21-068b482326ff@oracle.com> <1d81786f-0d4a-c140-38fa-60b7140dcc41@gmail.com> Message-ID: On 7/11/19 9:47 AM, Peter Levart wrote: > > http://cr.openjdk.java.net/~plevart/jdk-dev/8193072_File.undoDeleteOnExit/webrev.02/ > > Another thing to consider (done in above webrev.02) is what to do with unbalanced cancelDeleteOnExit(). I think it is better to throw exception than to silently ignore it. This way unintentional bugs can be uncovered which would otherwise just cause erratic behavior. Regards, Peter From claes.redestad at oracle.com Thu Jul 11 13:43:34 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 11 Jul 2019 15:43:34 +0200 Subject: RFR: 8227587: Add internal privileged System.loadLibrary Message-ID: <8cf6ed4d-194a-4428-f381-e7e3c0452cd6@oracle.com> Hi, by adding a method to load libraries with privileges to JavaLangAccess, we can simplify a slew of places where we are currently implementing adhoc privileged actions. This is a tiny but measurable gain on a range of startup tests. Webrev: http://cr.openjdk.java.net/~redestad/8227587/open.00 Bug: https://bugs.openjdk.java.net/browse/JDK-8227587 Testing: tier1-3 Thanks! /Claes From jason_mehrens at hotmail.com Thu Jul 11 14:05:24 2019 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Thu, 11 Jul 2019 14:05:24 +0000 Subject: 8193072: File.delete() should remove its path from DeleteOnExitHook.files In-Reply-To: <35f38610-f450-cace-3d21-068b482326ff@oracle.com> References: <9608451A-321D-4CD7-9DD9-04524AC4F53D@oracle.com> <0525c4cf-4a02-1f9b-2950-a0750cbf4a48@oracle.com> <0d67cb9d-96d1-9e55-dda5-31ede2770cfd@oracle.com> <0ab34cb3-38c6-1e62-cc1c-13b9d343ab6c@oracle.com> <096A2B42-5635-4254-92CA-2EB2758BD5D1@oracle.com> <777C2632-ABF3-496A-BB82-01A9733DD747@oracle.com> <2D863386-A47C-491A-93A8-52F870F7F4E8@oracle.com> <55C9CB46-46E5-4F80-84BC-95682A0D343B@oracle.com>, <35f38610-f450-cace-3d21-068b482326ff@oracle.com> Message-ID: Would it work to fix this by making DeleteOnExitHook::runHooks deal with dependencies? 1. Remove If deleted, or not directory which also takes care of not exists. 2. Sort remaining files by deepest child files/directories first. 3. Run delete again on the list. Otherwise files need to be processed in reverse order before directories and directories need to be processed children first up to the root. Jason ________________________________________ From: core-libs-dev on behalf of Ivan Gerasimov Sent: Wednesday, July 10, 2019 8:51 PM To: Brian Burkhalter; core-libs-dev Subject: Re: 8193072: File.delete() should remove its path from DeleteOnExitHook.files On 7/10/19 5:17 PM, Brian Burkhalter wrote: > I incorporated Peter?s version, adding the security check in cancelDeleteOnExit(), tweaking its verbiage along with that of deleteOnExit(), and modified the test DeleteOnExit to verify the new method. The updated version is here: > > http://cr.openjdk.java.net/~bpb/8193072/webrev.03/ There is possibility of a race here in a scenario like this: File dir = new File("dir"); File file = new File("dir/file"); -- thread 1 -- dir.deleteOnExit(); file.deleteOnExit(); /// dir.cancelDeleteOnExit(); //// thread 2 intervenes file.cancelDeleteOnExit(); -- end -- -- thread 2 -- dir.deleteOnExit(); file.deleteOnExit(); -- end -- The result will be that the order of the registered files will change, and JVM will try to delete dir first (this will fail as it is not empty). Of course it could be avoided, if cancellation were done in reverse order, though it's not immediately obvious from the documentation. With kind regards, Ivan > Thanks, > > Brian > >> On Jul 10, 2019, at 11:17 AM, Brian Burkhalter wrote: >> >> On Jul 10, 2019, at 5:36 AM, Peter Levart wrote: >>> There are various interleavings of threads that could cause the file to be left undeleted when VM exits. >>> >>> To cover concurrent scenarios such as above, the code could use reference counting. Like in the following patch: >>> >>> http://cr.openjdk.java.net/~plevart/jdk-dev/8193072_File.undoDeleteOnExit/webrev.01/ >> This looks good to me modulo adding this >> SecurityManager security = System.getSecurityManager(); >> if (security != null) { >> security.checkDelete(path); >> } >> to cancelDeleteOnExit() as suggested below. >> >>> On Jul 10, 2019, at 7:51 AM, Sean Mullan wrote: >>> >>> On 7/9/19 7:40 PM, Brian Burkhalter wrote: >>>> I don?t know. On the one hand this does not take an action like reading, writing, or deleting, but on the other it could end up causing files to be left lying around after VM termination which were expected to be deleted. I suppose that could be considered to be some sort of security issue. >>> Yes I think so. >>> >>> I would probably just use the same permission (FilePermission(file,"delete")). If you have been granted permission to delete a file, then you should have permission to cancel that deletion as well. >> That?s a good idea. -- With kind regards, Ivan Gerasimov From Roger.Riggs at oracle.com Thu Jul 11 14:10:59 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 11 Jul 2019 10:10:59 -0400 Subject: RFR: 8227587: Add internal privileged System.loadLibrary In-Reply-To: <8cf6ed4d-194a-4428-f381-e7e3c0452cd6@oracle.com> References: <8cf6ed4d-194a-4428-f381-e7e3c0452cd6@oracle.com> Message-ID: <4943b69c-bc3a-f147-abb8-5b369eec5737@oracle.com> Hi Claes, JavaLangAccess.java: 316: Add @param tag System.java:? 2282, 2287 Runtime.loadLibrary0 makes a second check for a security manager. Is there any potential gain by calling ClassLoader.loadLibrary directly? None of the internal uses would have a separatorChar. I expect most of the files need a copyright update. The script in /make/scripts/update_copyright_year.sh should do the work for modified files. Roger On 7/11/19 9:43 AM, Claes Redestad wrote: > Hi, > > by adding a method to load libraries with privileges to JavaLangAccess, > we can simplify a slew of places where we are currently implementing > adhoc privileged actions. This is a tiny but measurable gain on a range > of startup tests. > > Webrev:? http://cr.openjdk.java.net/~redestad/8227587/open.00 > Bug:???? https://bugs.openjdk.java.net/browse/JDK-8227587 > Testing: tier1-3 > > Thanks! > > /Claes From claes.redestad at oracle.com Thu Jul 11 14:39:46 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 11 Jul 2019 16:39:46 +0200 Subject: RFR: 8227587: Add internal privileged System.loadLibrary In-Reply-To: <4943b69c-bc3a-f147-abb8-5b369eec5737@oracle.com> References: <8cf6ed4d-194a-4428-f381-e7e3c0452cd6@oracle.com> <4943b69c-bc3a-f147-abb8-5b369eec5737@oracle.com> Message-ID: <2cbfd5d8-c4a0-4a2d-ba62-6fed14dc7155@oracle.com> Hi Roger, On 2019-07-11 16:10, Roger Riggs wrote: > Hi Claes, > > JavaLangAccess.java: > 316: Add @param tag done. > > System.java:? 2282, 2287 > Runtime.loadLibrary0 makes a second check for a security manager. > Is there any potential gain by calling ClassLoader.loadLibrary directly? > None of the internal uses would have a separatorChar. Most of the gain comes from not having to load one-off PA classes or lambdas, but of course avoiding the indexOf and a few indirections are marginally helpful to startup. We should at least assert that the library names are sane, though. > > I expect most of the files need a copyright update. > The script in /make/scripts/update_copyright_year.sh should do the > work for modified files. Fixed copyrights and updated in place: http://cr.openjdk.java.net/~redestad/8227587/open.00 Thanks! /Claes From huizhe.wang at oracle.com Thu Jul 11 15:26:28 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 11 Jul 2019 08:26:28 -0700 Subject: RFR [14/java.xml] 8178843: A bug in an inner loop in MethodGenerator's getLocals method In-Reply-To: <1F07D3A9-99F8-4C19-A1E5-092A07357E34@oracle.com> References: <1F07D3A9-99F8-4C19-A1E5-092A07357E34@oracle.com> Message-ID: Thanks Lance! -Joe On 7/10/19 6:38 PM, Lance Andersen wrote: > +1 >> On Jul 10, 2019, at 7:57 PM, Joe Wang > > wrote: >> >> Please review a cleanup that removes unused code. This code has two >> errors, one as indicated in the bug report, another attempting to >> loop through allVarsEverDeclared that was just created (meaning >> size=0). It just ensures again that the code was never used. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8178843 >> webrevs: http://cr.openjdk.java.net/~joehw/jdk14/8178843/webrev/ >> >> All tests passed. >> >> 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 brian.burkhalter at oracle.com Thu Jul 11 17:44:44 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 11 Jul 2019 10:44:44 -0700 Subject: 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause Message-ID: https://bugs.openjdk.java.net/browse/JDK-8187898 http://cr.openjdk.java.net/~bpb/8187898/webrev.00/ Override FilterOutputStream.write(byte[]) not to throw IOException. Including 2d-dev as this creates a source compatibility issue in PSPrinterJob which I fix in this patch. A CSR would of course be needed for this. Thanks, Brian From brian.burkhalter at oracle.com Thu Jul 11 20:07:33 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 11 Jul 2019 13:07:33 -0700 Subject: 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: References: Message-ID: Testing revealed the need for some changes in test/jdk/java/lang/System/LoggerFinder/internal. Webrev updated in place. Brian > On Jul 11, 2019, at 10:44 AM, Brian Burkhalter wrote: > > https://bugs.openjdk.java.net/browse/JDK-8187898 > http://cr.openjdk.java.net/~bpb/8187898/webrev.00/ > > Override FilterOutputStream.write(byte[]) not to throw IOException. Including 2d-dev as this creates a source compatibility issue in PSPrinterJob which I fix in this patch. > > A CSR would of course be needed for this. From lance.andersen at oracle.com Fri Jul 12 00:23:04 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 11 Jul 2019 20:23:04 -0400 Subject: RFR [14] JDK-8225763 Inflater and Deflater should implement AutoCloseable In-Reply-To: References: <1a0052f8-dc3f-9102-942e-e66e6f5ad694@gmail.com> <78E885C6-733F-46D7-A21F-F83E09E20DAE@oracle.com> Message-ID: <0F439A98-36C5-436D-9F08-22C2DEDE522F@oracle.com> Hi Jaikiran, > On Jul 10, 2019, at 2:56 AM, Jaikiran Pai wrote: > > Hello Lance, > On 10/07/19 2:25 AM, Lance Andersen wrote: >> ??? >> @implSpec This method is a no-op if this compressor has already >> 886 * been previously closed, >> >> ???? >> >> Please remove ?already? in both the close() and end() methods. > Done. > > >> I believe the preference is the @implSpec and its relatives are on their own line as in https://openjdk.java.net/jeps/8068562 and was done for @apiNote earlier > Done. > > >> >> Outside of the @ImplSpec, I am not sure the initial wording for end() and close() really need to differ: >> >> end(): >> >> Closes the decompressor and discards any unprocessed input. >> >> close(): >> >> Releases resources held by this decompressor and discards any unprocessed input.This method should be called when the decompressor is no longer needed >> > I have now updated the javadoc of end() to be closer to the javadoc of close(). > > > Its better but end() should include the wording ???? This method should be called when the compressor is no longer needed. ?????? It could read This method or close() should be called when the compressor ?? Also, thinking about the following in end(): ??? * Use of {@link #close()} is encouraged instead of this method. ??? This might be better served as an @apiNote so it stands out >> >>> - The javadoc of end() method in both these classes has been updated to >>> encourage the use of close() method instead of this one. It now also has >>> a @implSpec which states that it's a no-op if called more than once. >>> >>> In addition, this javadoc has also been updated to replace the >>> "undefined behaviour" statement with a mention that the usage of the >>> Inflater/Deflater instance after a call to end() may throw an exception >>> in those subsequent usages. Please note that, there's no such explicit >>> mention in the javadoc of the (newly added) close() method because IMO, >>> it isn't needed for close() since I think it's kind of implied that a >>> closed resource can no longer be used for further operations. >> >> We need to be specific in close() also for clarity > I haven't updated this in the latest webrev version and will wait for us to come to a decision on how we word it for end(). > OK > >>> >>> >>> - TotalInOut.java test has been updated to use the new >>> try-with-resources construct for the inflater and deflater it uses. >> >> Please update @biug to include the bug number > Done. > > >>> >>> - A couple of new (testng) test classes have been added to test various >>> scenarios where close() and end() method get called. These test mostly >>> focus on ensuring that the close() and end(), either implicitly or >>> explicitly, get called the right number of times on the subclasses of >>> Inflater/Deflater. >> >> Overall they look OK. In your tests, you are testing the number of calls for the sub-classes not for Deflate/Inflate so I would either update your comments to clarify that or pull them into their own test methods >> > I did not understand this. Did you mean I should update the @summary part of these tests or was it the javadoc on these test methods? > > Sorry if my comment was confusing. For example: ???? public void testCloseThenEnd() throws Exception { 119 final Deflater simpleDeflater = new Deflater(); 120 closeThenEnd(simpleDeflater); 121 122 final OverrideClose overridenClose = new OverrideClose(); 123 closeThenEnd(overridenClose); 124 // make sure close was called once 125 assertEquals(overridenClose.numTimesCloseCalled, 1, "Unexpected number of calls to close()"); ?????? As there is not an assert() for simpleDeflater, which is understandable, the comment describing the test is not quite accurate should be slightly updated > The latest webrev with the above noted changes is available at http://cr.openjdk.java.net/~jpai/webrev/8225763/3/webrev/ > -Jaikiran Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From frank.yuan at oracle.com Fri Jul 12 06:32:46 2019 From: frank.yuan at oracle.com (Frank Yuan) Date: Fri, 12 Jul 2019 14:32:46 +0800 Subject: RFR [14]: 8227438: [TESTLIB] Determine if file exists by Files.exists in function FileUtils.deleteFileIfExistsWithRetry Message-ID: <00b101d5387b$9fc77700$df566500$@oracle.com> Hi Would you like to review the following patch for Bug: https://bugs.openjdk.java.net/browse/JDK-8227438 --- a/test/lib/jdk/test/lib/util/FileUtils.java Thu Jul 11 15:58:54 2019 +0000 +++ b/test/lib/jdk/test/lib/util/FileUtils.java Fri Jul 12 13:33:30 2019 +0800 @@ -96,7 +96,7 @@ */ public static void deleteFileIfExistsWithRetry(Path path) throws IOException { try { - if (Files.exists(path)) { + if (!Files.notExists(path)) { deleteFileWithRetry0(path); } } catch (InterruptedException x) { Files.exists returns false if the existence cannot be determined, so replace it with "!Files.notExists" like the change in JDK-8184961. Thanks Frank From chengjingwei1 at huawei.com Fri Jul 12 06:50:20 2019 From: chengjingwei1 at huawei.com (chengjingwei (A)) Date: Fri, 12 Jul 2019 06:50:20 +0000 Subject: [8u-dev] Deadlock involving FileSystems.getDefault and System.loadLibrary Message-ID: Hi there, We got a bug report from our customers some time ago, the situation was the same as described in http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-January/050819.html So we adopted the patch proposed in https://bugs.openjdk.java.net/browse/JDK-8194653 and https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-April/059811.html But after then, we've encountered 2 more issues: 1. Win32 jdk would crash on a win64 environment when running AsynchronousFileChannel test in the jck testsuite 2. Win32 jdk sometimes throw TimeoutException when running AysnchronousChannelGroup test in the jck testsuite We are pretty sure that these issues came up right after we applied this patch. As for the root cause, we are still investigating. If someone is interested in these newly introduced issues, I'd like to post more details about them. From jai.forums2013 at gmail.com Fri Jul 12 07:07:50 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 12 Jul 2019 12:37:50 +0530 Subject: RFR [14] JDK-8225763 Inflater and Deflater should implement AutoCloseable In-Reply-To: <0F439A98-36C5-436D-9F08-22C2DEDE522F@oracle.com> References: <1a0052f8-dc3f-9102-942e-e66e6f5ad694@gmail.com> <78E885C6-733F-46D7-A21F-F83E09E20DAE@oracle.com> <0F439A98-36C5-436D-9F08-22C2DEDE522F@oracle.com> Message-ID: Hello Lance, On 12/07/19 5:53 AM, Lance Andersen wrote: > Hi Jaikiran, >> I have now updated the javadoc of end() to be closer to the javadoc >> of close(). >> >> > > Its better but end() should include the wording? > > ???? > This method should be called when the compressor is no longer needed. > > ?????? > > It could read > > This method or close() should be called when the compressor ?? > > > Also, thinking about the following in end(): > > ??? > * Use of {@link #close()} is encouraged instead of this method. > ??? > > This might be better served as an @apiNote so it stands out You are right, the wording you use is better. I have now updated the javadoc of end() to use this wording. Furthermore, I have moved that above part to the @apiNote. >>> >>>> - The javadoc of end() method in both these classes has been updated to >>>> encourage the use of close() method instead of this one. It now >>>> also has >>>> a @implSpec which states that it's a no-op if called more than once. >>>> >>>> In addition, this javadoc has also been updated to replace the >>>> "undefined behaviour" statement with a mention that the usage of the >>>> Inflater/Deflater instance after a call to end() may throw an exception >>>> in those subsequent usages. Please note that, there's no such explicit >>>> mention in the javadoc of the (newly added) close() method because IMO, >>>> it isn't needed for close() since I think it's kind of implied that a >>>> closed resource can no longer be used for further operations. >>> >>> We need to be specific in close() ?also for clarity >> >> I haven't updated this in the latest webrev version and will wait for >> us to come to a decision on how we word it for end(). >> > > OK Given that we haven't yet come to a decision on how to word this, I went ahead and attempted to improve this wording a bit. I have now moved it into the @apiNote of both end() and close() javadoc and it now reads: "Once the {@link #end()} or {@link #close()} have been called on a compressor, the compressor may not be used for further operations. Doing so may cause an exception to be thrown." Of course, we can still change this to something else if this isn't yet accurate enough. >>> >>> Overall they look OK. ?In your tests, you are testing the number of >>> calls for the sub-classes not for Deflate/Inflate so I would either >>> update your comments to clarify that or pull them into their own >>> test methods >>> >> I did not understand this. Did you mean I should update the @summary >> part of these tests or was it the javadoc on these test methods? >> >> > Sorry if my comment was confusing. ?For example: > > ???? > public void testCloseThenEnd() throws Exception { > 119 final Deflater simpleDeflater = new Deflater(); > 120 closeThenEnd(simpleDeflater); > 121 > 122 final OverrideClose overridenClose = new OverrideClose(); > 123 closeThenEnd(overridenClose); > 124 // make sure close was called once > 125 assertEquals(overridenClose.numTimesCloseCalled, 1, "Unexpected number of calls to close()"); > > ?????? > > As there is not an assert() for simpleDeflater, which is > understandable, ?the comment describing the test is not quite accurate > should be slightly updated OK, I get it now, thank you. Indeed what you note makes sense. I have now updated both these new tests to move out the "simpleDeflater/Inflater" testing outside into a new test method of its own (along the lines to what you suggested in the previous reply) and added comment to that test method to explain what it does. Let me know if this looks better. The new updated webrev is at http://cr.openjdk.java.net/~jpai/webrev/8225763/4/webrev/ Thank you for your inputs so far. -Jaikiran From bourges.laurent at gmail.com Fri Jul 12 07:34:51 2019 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Fri, 12 Jul 2019 09:34:51 +0200 Subject: The final optimized version of Dual-Pivot Quicksort (ver.19.1) In-Reply-To: <5ab79374-a561-de15-6a35-0dde138fdcb9@oracle.com> References: <1560893862.105095134@f487.i.mail.ru> <5ab79374-a561-de15-6a35-0dde138fdcb9@oracle.com> Message-ID: Hi, I asked alan to update the webrev, but I can publish it myself... Will do it asap, Stay tuned, Laurent Le mar. 9 juil. 2019 ? 22:19, Brent Christian a ?crit : > Hi, > > Is the webrev incomplete? It only contains the changes for > DualPivotQuicksort.java, and not for Arrays.java, etc. > > Thanks, > -Brent > > On 6/18/19 2:37 PM, Vladimir Yaroslavskiy wrote: > > Hi team, > > > > Please review the final optimized version of Dual-Pivot Quicksort > (ver.19.1), > > see http://cr.openjdk.java.net/~alanb/8226297/0/webrev > > (link to Jira task https://bugs.openjdk.java.net/browse/JDK-8226297) > > > > The new version was published here more than one year ago (on Jan 19, > 2018). > > Since that time Dual-Pivot Quicksort has been significantly improved > > and this work was done in collaboration with Doug Lea and Laurent > Bourges. > > > > You can find summary of all changes below. > > > > DualPivotQuicksort.java > > ---------------------------------------------------------------------- > > * The 1-st and 5-th candidates are taken as pivots > > instead of 2-nd and 4-th > > * Pivots are chosen with another step > > * Pivot candidates are sorted by combination of > > 5-element network sorting and insertion sort > > * New backwards partitioning was introduced > > * Partitioning is related to the golden ratio > > * Quicksort tuning parameters were updated > > * Thresholds for byte / char / short sorting were updated > > * Additional steps for float / double were fully rewritten > > * Parallel sorting is based on combination of merge sort > > and Dual-Pivot Quicksort > > * Pair insertion sort was optimized and became a part > > of mixed insertion sort > > * Mixed insertion sort was introduced: combination > > of simple insertion sort, pin insertion sort and > > pair insertion sort > > * Simple insertion sort is invoked on tiny array > > * Pin insertion sort is started on small array > > * Pair insertion sort is continued on remain part > > * Merging of runs is invoked on each iteration of Quicksort > > * Merging of runs was fully rewritten > > * Optimal partitioning of merging is used > > * Not more than one copy of part to buffer during merging > > * Merging parameters were updated > > * Initial capacity of runs is based on size > > * Max number of runs is constant > > * Optimized version of heap sort was introduced > > * Heap sort is used as a guard against quadratic time > > (int / long / float / double) > > * Parallel merging of runs was also provided > > * Parallel sorting, heap sort and merging of runs > > are not used in byte / char / short sorting > > * Counting sort for byte / char / short were optimized > > * Counting sort is used as a guard against quadratic time > > (byte / char / short) > > * Code style and javadoc improvements > > > > Sorting.java > > ---------------------------------------------------------------------- > > * New test cases were added > > * Test cases are invoked for both: sequential and > > parallel sorting > > * Check for Object sorting was added > > * New tests were added against heap sort > > * Added test case against bug in parallel merge > > sort on float / double data > > > > ParallelSorting.java > > ---------------------------------------------------------------------- > > * This class was removed, because Sorting class > > covers all cases > > > > SortingHelper.java > > ---------------------------------------------------------------------- > > * The helper class provides access package-private > > methods of DualPivotQuicksort class during testing > > > > Arrays.java > > ---------------------------------------------------------------------- > > * Calls of Dual-Pivot Quicksort were updated > > * Parallel sorting of primitives was switched to parallel > > Dual-Pivot Quicksort > > * Javadoc was updated, double spaces were removed > > * Format changes > > > > ArraysParallelSortHelpers.java > > ---------------------------------------------------------------------- > > * Implementation of parallel sorting > > for primitives was removed > > * Javadoc was updated > > > > Thank you, > > Vladimir > > > From Roger.Riggs at oracle.com Fri Jul 12 13:27:51 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 12 Jul 2019 09:27:51 -0400 Subject: RFR: 8227587: Add internal privileged System.loadLibrary In-Reply-To: <2cbfd5d8-c4a0-4a2d-ba62-6fed14dc7155@oracle.com> References: <8cf6ed4d-194a-4428-f381-e7e3c0452cd6@oracle.com> <4943b69c-bc3a-f147-abb8-5b369eec5737@oracle.com> <2cbfd5d8-c4a0-4a2d-ba62-6fed14dc7155@oracle.com> Message-ID: <60d95350-c42c-1498-5c72-174736e863c0@oracle.com> Hi Claes, Looks fine. Thanks for the updates, Roger On 7/11/19 10:39 AM, Claes Redestad wrote: > Hi Roger, > > On 2019-07-11 16:10, Roger Riggs wrote: >> Hi Claes, >> >> JavaLangAccess.java: >> 316: Add @param tag > > done. > >> >> System.java:? 2282, 2287 >> Runtime.loadLibrary0 makes a second check for a security manager. >> Is there any potential gain by calling ClassLoader.loadLibrary directly? >> None of the internal uses would have a separatorChar. > > Most of the gain comes from not having to load one-off PA classes or > lambdas, but of course avoiding the indexOf and a few indirections are > marginally helpful to startup. We should at least assert that the > library names are sane, though. > >> >> I expect most of the files need a copyright update. >> The script in /make/scripts/update_copyright_year.sh should do >> the work for modified files. > > Fixed copyrights and updated in place: > http://cr.openjdk.java.net/~redestad/8227587/open.00 > > Thanks! > > /Claes From philip.race at oracle.com Fri Jul 12 14:14:55 2019 From: philip.race at oracle.com (Philip Race) Date: Fri, 12 Jul 2019 07:14:55 -0700 Subject: RFR: 8227587: Add internal privileged System.loadLibrary In-Reply-To: <60d95350-c42c-1498-5c72-174736e863c0@oracle.com> References: <8cf6ed4d-194a-4428-f381-e7e3c0452cd6@oracle.com> <4943b69c-bc3a-f147-abb8-5b369eec5737@oracle.com> <2cbfd5d8-c4a0-4a2d-ba62-6fed14dc7155@oracle.com> <60d95350-c42c-1498-5c72-174736e863c0@oracle.com> Message-ID: <5D2895DF.8070001@oracle.com> Hi, Regarding all the touches on the desktop module 1) awt-dev isn't the only list, you should have included swing-dev and 2d-dev at least 2) I am wondering what client testing you propose to do to verify this ? 3) I've spent spare time over a number of months trying to decrease unnecessary coupling between desktop and base modules. This seems to create additional technical debt there with minimal benefit, so in other words I'd much prefer that either you don't do this at all or the many, many, uses in the desktop module that are the heaviest Java->native code user in the JDK are dealt with entirely separately (separate bug) and at a minimum there is one place in the desktop module that they all call to and perhaps only then *through*. So do not push this. -phil. On 7/12/19, 6:27 AM, Roger Riggs wrote: > Hi Claes, > > Looks fine. > > Thanks for the updates, Roger > > > On 7/11/19 10:39 AM, Claes Redestad wrote: >> Hi Roger, >> >> On 2019-07-11 16:10, Roger Riggs wrote: >>> Hi Claes, >>> >>> JavaLangAccess.java: >>> 316: Add @param tag >> >> done. >> >>> >>> System.java: 2282, 2287 >>> Runtime.loadLibrary0 makes a second check for a security manager. >>> Is there any potential gain by calling ClassLoader.loadLibrary >>> directly? >>> None of the internal uses would have a separatorChar. >> >> Most of the gain comes from not having to load one-off PA classes or >> lambdas, but of course avoiding the indexOf and a few indirections are >> marginally helpful to startup. We should at least assert that the >> library names are sane, though. >> >>> >>> I expect most of the files need a copyright update. >>> The script in /make/scripts/update_copyright_year.sh should do >>> the work for modified files. >> >> Fixed copyrights and updated in place: >> http://cr.openjdk.java.net/~redestad/8227587/open.00 >> >> Thanks! >> >> /Claes > From andy.herrick at oracle.com Fri Jul 12 14:31:22 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 12 Jul 2019 10:31:22 -0400 Subject: RFR: JDK-8220807: excessive verbose output when running with --win-per-user-install Message-ID: <45e3c2d7-7032-ff7a-8b88-e75867c47c78@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). [1] https://bugs.openjdk.java.net/browse/JDK-8220807 [2] http://cr.openjdk.java.net/~herrick/8220807/ /Andy From claes.redestad at oracle.com Fri Jul 12 14:55:27 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 12 Jul 2019 16:55:27 +0200 Subject: RFR: 8227587: Add internal privileged System.loadLibrary In-Reply-To: <60d95350-c42c-1498-5c72-174736e863c0@oracle.com> References: <8cf6ed4d-194a-4428-f381-e7e3c0452cd6@oracle.com> <4943b69c-bc3a-f147-abb8-5b369eec5737@oracle.com> <2cbfd5d8-c4a0-4a2d-ba62-6fed14dc7155@oracle.com> <60d95350-c42c-1498-5c72-174736e863c0@oracle.com> Message-ID: Hi, I'm dropping the java.desktop changes, and Mandy has asked me to explore options that does not add a new @CallerSensitive entry point, even to a strongly encapsulated API like JavaLangAccess Easiest of these is to explicitly provide the class context we're calling from - with proper assertions. This is marginally more performant due avoiding the Reflection.getCallerClass, but slightly less convenient. http://cr.openjdk.java.net/~redestad/8227587/open.01/ /Claes On 2019-07-12 15:27, Roger Riggs wrote: > Hi Claes, > > Looks fine. > > Thanks for the updates, Roger > > > On 7/11/19 10:39 AM, Claes Redestad wrote: >> Hi Roger, >> >> On 2019-07-11 16:10, Roger Riggs wrote: >>> Hi Claes, >>> >>> JavaLangAccess.java: >>> 316: Add @param tag >> >> done. >> >>> >>> System.java:? 2282, 2287 >>> Runtime.loadLibrary0 makes a second check for a security manager. >>> Is there any potential gain by calling ClassLoader.loadLibrary directly? >>> None of the internal uses would have a separatorChar. >> >> Most of the gain comes from not having to load one-off PA classes or >> lambdas, but of course avoiding the indexOf and a few indirections are >> marginally helpful to startup. We should at least assert that the >> library names are sane, though. >> >>> >>> I expect most of the files need a copyright update. >>> The script in /make/scripts/update_copyright_year.sh should do >>> the work for modified files. >> >> Fixed copyrights and updated in place: >> http://cr.openjdk.java.net/~redestad/8227587/open.00 >> >> Thanks! >> >> /Claes > From mandy.chung at oracle.com Fri Jul 12 15:25:05 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 12 Jul 2019 08:25:05 -0700 Subject: RFR: 8227587: Add internal privileged System.loadLibrary In-Reply-To: References: <8cf6ed4d-194a-4428-f381-e7e3c0452cd6@oracle.com> <4943b69c-bc3a-f147-abb8-5b369eec5737@oracle.com> <2cbfd5d8-c4a0-4a2d-ba62-6fed14dc7155@oracle.com> <60d95350-c42c-1498-5c72-174736e863c0@oracle.com> Message-ID: <15a57e3c-065c-55c5-b6af-0644ed8f775b@oracle.com> Claes, Thanks for exploring this.? I would like to see if we can avoid introducing an internal @CS method (keep @CSM only for public APIs will help security analysis). There are other alternatives to improve the footprint performance. One idea is java.base and java.desktop each has its own utility method to load library.? No change is needed for java.net since only one loadLibrary call. Another idea is to add BootLoader.loadLibrary that skips the security permission overhead and only for boot loader use.? It would require refactoring. I think java.base and java.desktop having its own utility method is a simpler solution. Mandy On 7/12/19 7:55 AM, Claes Redestad wrote: > Hi, > > I'm dropping the java.desktop changes, and Mandy has asked me to explore > options that does not add a new @CallerSensitive entry point, even to a > strongly encapsulated API like JavaLangAccess > > Easiest of these is to explicitly provide the class context we're > calling from - with proper assertions. This is marginally more > performant due avoiding the Reflection.getCallerClass, but slightly less > convenient. > > http://cr.openjdk.java.net/~redestad/8227587/open.01/ > > /Claes > > On 2019-07-12 15:27, Roger Riggs wrote: >> Hi Claes, >> >> Looks fine. >> >> Thanks for the updates, Roger >> >> >> On 7/11/19 10:39 AM, Claes Redestad wrote: >>> Hi Roger, >>> >>> On 2019-07-11 16:10, Roger Riggs wrote: >>>> Hi Claes, >>>> >>>> JavaLangAccess.java: >>>> 316: Add @param tag >>> >>> done. >>> >>>> >>>> System.java:? 2282, 2287 >>>> Runtime.loadLibrary0 makes a second check for a security manager. >>>> Is there any potential gain by calling ClassLoader.loadLibrary >>>> directly? >>>> None of the internal uses would have a separatorChar. >>> >>> Most of the gain comes from not having to load one-off PA classes or >>> lambdas, but of course avoiding the indexOf and a few indirections are >>> marginally helpful to startup. We should at least assert that the >>> library names are sane, though. >>> >>>> >>>> I expect most of the files need a copyright update. >>>> The script in /make/scripts/update_copyright_year.sh should >>>> do the work for modified files. >>> >>> Fixed copyrights and updated in place: >>> http://cr.openjdk.java.net/~redestad/8227587/open.00 >>> >>> Thanks! >>> >>> /Claes >> From serban.iordache at gmail.com Fri Jul 12 07:53:41 2019 From: serban.iordache at gmail.com (Serban Iordache) Date: Fri, 12 Jul 2019 09:53:41 +0200 Subject: jpackage: spaces in --java-options Message-ID: Currently, there is no easy way to pass system properties containing spaces to the Java runtime. For example, if we execute jpackage with: --java-options -Dlabel="my great app" The resulting configuration file will contain: [JavaOptions] -Dlabel=my great app instead of the desired: [JavaOptions] -Dlabel=my great app Looking at the regexp used by jdk.jpackage.internal.Arguments, I came up with a workaround: surrounding the spaces with \" This means that executing jpackage with: --java-options -Dlabel="my\" \"great\" \"app" will produce the desired output in the configuration file: [JavaOptions] -Dlabel=my great app But this is an ugly hack. It would be nice to have a better way to handle JVM options containing spaces. Another issue is related to passing JVM options containing simple or double quotes. For example, I couldn't find a way to make jpackage generate a configuration file that contains: [JavaOptions] -Dlabel=my "great" app Best regards, Serban Iordache From lance.andersen at oracle.com Fri Jul 12 16:54:52 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 12 Jul 2019 12:54:52 -0400 Subject: RFR [14]: 8227438: [TESTLIB] Determine if file exists by Files.exists in function FileUtils.deleteFileIfExistsWithRetry In-Reply-To: <00b101d5387b$9fc77700$df566500$@oracle.com> References: <00b101d5387b$9fc77700$df566500$@oracle.com> Message-ID: Hi Frank, Took me a while to digest the proposed change, I understand it now and it makes sense to me So I think you are good to go. Best Lance > On Jul 12, 2019, at 2:32 AM, Frank Yuan wrote: > > JDK-8184961 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 Jul 12 16:56:46 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 12 Jul 2019 09:56:46 -0700 Subject: RFR [14]: 8227438: [TESTLIB] Determine if file exists by Files.exists in function FileUtils.deleteFileIfExistsWithRetry In-Reply-To: <00b101d5387b$9fc77700$df566500$@oracle.com> References: <00b101d5387b$9fc77700$df566500$@oracle.com> Message-ID: +1 -Joe On 7/11/19 11:32 PM, Frank Yuan wrote: > Hi > > > > Would you like to review the following patch for > > Bug: https://bugs.openjdk.java.net/browse/JDK-8227438 > > > > --- a/test/lib/jdk/test/lib/util/FileUtils.java Thu Jul 11 15:58:54 2019 +0000 > > +++ b/test/lib/jdk/test/lib/util/FileUtils.java Fri Jul 12 13:33:30 2019 +0800 > > @@ -96,7 +96,7 @@ > > */ > > public static void deleteFileIfExistsWithRetry(Path path) throws IOException { > > try { > > - if (Files.exists(path)) { > > + if (!Files.notExists(path)) { > > deleteFileWithRetry0(path); > > } > > } catch (InterruptedException x) { > > > > > > Files.exists returns false if the existence cannot be determined, so replace it with "!Files.notExists" like the change in > JDK-8184961. > > > > Thanks > > Frank > > > From andy.herrick at oracle.com Fri Jul 12 17:21:38 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 12 Jul 2019 13:21:38 -0400 Subject: jpackage: spaces in --java-options In-Reply-To: References: Message-ID: I can reproduce this problem and have created JDK-8227641 to address it. /Andy On 7/12/2019 3:53 AM, Serban Iordache wrote: > Currently, there is no easy way to pass system properties containing spaces > to the Java runtime. > > For example, if we execute jpackage with: > --java-options -Dlabel="my great app" > > The resulting configuration file will contain: > [JavaOptions] > -Dlabel=my > great > app > > > instead of the desired: > [JavaOptions] > -Dlabel=my great app > > > Looking at the regexp used by jdk.jpackage.internal.Arguments, I came up > with a workaround: surrounding the spaces with \" > This means that executing jpackage with: > --java-options -Dlabel="my\" \"great\" \"app" > > will produce the desired output in the configuration file: > [JavaOptions] > -Dlabel=my great app > > > But this is an ugly hack. It would be nice to have a better way to handle > JVM options containing spaces. > > > Another issue is related to passing JVM options containing simple or double > quotes. For example, I couldn't find a way to make jpackage generate a > configuration file that contains: > [JavaOptions] > -Dlabel=my "great" app > > > Best regards, > Serban Iordache From alexey.semenyuk at oracle.com Fri Jul 12 17:22:19 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Fri, 12 Jul 2019 13:22:19 -0400 Subject: RFR: JDK-8220807: excessive verbose output when running with --win-per-user-install In-Reply-To: <45e3c2d7-7032-ff7a-8b88-e75867c47c78@oracle.com> References: <45e3c2d7-7032-ff7a-8b88-e75867c47c78@oracle.com> Message-ID: Andy, The fix suppresses warning for system wide installations too,not just for per user. Is this by intention? - Alexey On 7/12/2019 10:31 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). > > [1] https://bugs.openjdk.java.net/browse/JDK-8220807 > > [2] http://cr.openjdk.java.net/~herrick/8220807/ > > /Andy > From mandy.chung at oracle.com Fri Jul 12 18:03:20 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 12 Jul 2019 11:03:20 -0700 Subject: RFR: 8227587: Add internal privileged System.loadLibrary In-Reply-To: <15a57e3c-065c-55c5-b6af-0644ed8f775b@oracle.com> References: <8cf6ed4d-194a-4428-f381-e7e3c0452cd6@oracle.com> <4943b69c-bc3a-f147-abb8-5b369eec5737@oracle.com> <2cbfd5d8-c4a0-4a2d-ba62-6fed14dc7155@oracle.com> <60d95350-c42c-1498-5c72-174736e863c0@oracle.com> <15a57e3c-065c-55c5-b6af-0644ed8f775b@oracle.com> Message-ID: Just to recap what we discussed offline: We could introduce BootLoader::loadLibrary to load a system native library for boot loader.? sys_path and systemNativeLibraries in ClassLoader implementation are solely for boot loader and it seems cleaner for BootLoader to handle loading of system native libraries where it can be optimized for boot loader.? This would require some refactoring. One possible solution is to add a shared secret to simply call package-private ClassLoader::loadLibrary(Class fromClass, String name) method and have BootLoader::loadLibrary to check if SM is present and wrap the call with doPriv; otherwise, just call the shared secret loadLibrary method. Then we can investigate in the future to refactor the native library loading implementation to jdk.internal.loader. what do you think? Mandy On 7/12/19 8:25 AM, Mandy Chung wrote: > Claes, > > Thanks for exploring this.? I would like to see if we can avoid > introducing > an internal @CS method (keep @CSM only for public APIs will help security > analysis). > > There are other alternatives to improve the footprint performance. > > One idea is java.base and java.desktop each has its own utility method > to load library.? No change is needed for java.net since only one > loadLibrary > call. > > Another idea is to add BootLoader.loadLibrary that skips the security > permission overhead and only for boot loader use.? It would require > refactoring. > > I think java.base and java.desktop having its own utility method is > a simpler solution. > > Mandy > > On 7/12/19 7:55 AM, Claes Redestad wrote: >> Hi, >> >> I'm dropping the java.desktop changes, and Mandy has asked me to explore >> options that does not add a new @CallerSensitive entry point, even to a >> strongly encapsulated API like JavaLangAccess >> >> Easiest of these is to explicitly provide the class context we're >> calling from - with proper assertions. This is marginally more >> performant due avoiding the Reflection.getCallerClass, but slightly less >> convenient. >> >> http://cr.openjdk.java.net/~redestad/8227587/open.01/ >> >> /Claes >> >> On 2019-07-12 15:27, Roger Riggs wrote: >>> Hi Claes, >>> >>> Looks fine. >>> >>> Thanks for the updates, Roger >>> >>> >>> On 7/11/19 10:39 AM, Claes Redestad wrote: >>>> Hi Roger, >>>> >>>> On 2019-07-11 16:10, Roger Riggs wrote: >>>>> Hi Claes, >>>>> >>>>> JavaLangAccess.java: >>>>> 316: Add @param tag >>>> >>>> done. >>>> >>>>> >>>>> System.java:? 2282, 2287 >>>>> Runtime.loadLibrary0 makes a second check for a security manager. >>>>> Is there any potential gain by calling ClassLoader.loadLibrary >>>>> directly? >>>>> None of the internal uses would have a separatorChar. >>>> >>>> Most of the gain comes from not having to load one-off PA classes or >>>> lambdas, but of course avoiding the indexOf and a few indirections are >>>> marginally helpful to startup. We should at least assert that the >>>> library names are sane, though. >>>> >>>>> >>>>> I expect most of the files need a copyright update. >>>>> The script in /make/scripts/update_copyright_year.sh should >>>>> do the work for modified files. >>>> >>>> Fixed copyrights and updated in place: >>>> http://cr.openjdk.java.net/~redestad/8227587/open.00 >>>> >>>> Thanks! >>>> >>>> /Claes >>> > From sgehwolf at redhat.com Fri Jul 12 18:08:18 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 12 Jul 2019 20:08:18 +0200 Subject: RFR: 8227642: [TESTBUG] Make docker tests podman compatible Message-ID: <32c8a1934bf07e4c9c6a961e60dcb7abd9931fe1.camel@redhat.com> Hi, There is an alternative container engine which is being used by Fedora and RHEL 8, called podman[1]. It's mostly compatible with docker. It looks like OpenJDK docker tests can be made podman compatible with a few little tweaks. One "interesting" one is to not assert "Successfully built" in the build output but only rely on the exit code, which seems to be OK for my testing. Interestingly the test would be skipped in that case. Bug: https://bugs.openjdk.java.net/browse/JDK-8227642 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227642/01/webrev/ Adjustments I've done: * Don't assert "Successfully built" in image build output[2]. * Add /usr/sbin to PATH as the podman binary relies on iptables for it to work which is in /usr/sbin on Fedora * Allow for Metrics.getCpuSystemUsage() and Metrics.getCpuUserUsage() to be equal to the previous value. I've found those counters to be slowly increasing, which made the tests unreliable. Testing: Running docker tests with docker as engine. Did the same with podman as engine via -Djdk.test.docker.command=podman on Linux x86_64. Both passed (non-trivially). Thoughts? Thanks, Severin [1] https://podman.io/ [2] Image builds with podman look like ("COMMIT" over "Successfully built"): STEP 1: FROM fedora:29 STEP 2: RUN dnf install -y java-11-openjdk-devel && dnf clean all --> Using cache 96f8b1a0dfe7dba581a64fc67a27002ddf52e032af55f9ddc765182a690afd9d STEP 3: COPY TestMetrics.class TestMetrics.java /opt/ 269042160f7a4e6a06789cd19640ea658a8f941bc53de0fd40a574dc3bdb49a8 STEP 4: CMD /usr/lib/jvm/java-11-openjdk/bin/java -cp /opt --add-modules java.base --add-exports java.base/jdk.internal.platform=ALL-UNNAMED TestMetrics STEP 5: COMMIT fedora-metrics-11 d749088d6ce4510f212820ad4eca55a9b05e5c5c245f2372b6cfe91926e8cd7e From Roger.Riggs at oracle.com Fri Jul 12 18:17:38 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 12 Jul 2019 14:17:38 -0400 Subject: 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: References: Message-ID: Hi Brian, Would it be appropriate to add @Override to the new method (and perhaps existing overridden methods). Previously, calling FilterOutputStream.write(byte[]) would delegate to write(byte[], 0, length). The proposed change duplicates the code and changes the ways that overridden classes might see the call. What's the benefit of duplicating the code and calling out.write(buf)? Not my call, but in PSPrinterJob.java (970-977) it might be cleaner to just delete the unused code and comment. (The CSR will need to note the source incompatibility due to the removal of a declared exception) Thanks, Roger On 7/11/19 1:44 PM, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8187898 > http://cr.openjdk.java.net/~bpb/8187898/webrev.00/ > > Override FilterOutputStream.write(byte[]) not to throw IOException. Including 2d-dev as this creates a source compatibility issue in PSPrinterJob which I fix in this patch. > > A CSR would of course be needed for this. > > Thanks, > > Brian From brian.burkhalter at oracle.com Fri Jul 12 19:01:46 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 12 Jul 2019 12:01:46 -0700 Subject: 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: References: Message-ID: Hi Roger, > On Jul 12, 2019, at 11:17 AM, Roger Riggs wrote: > > Would it be appropriate to add @Override to the new method (and perhaps existing overridden methods). Yes, I think so. > Previously, calling FilterOutputStream.write(byte[]) would delegate to write(byte[], 0, length). > The proposed change duplicates the code and changes the ways that overridden classes might see the call. > What's the benefit of duplicating the code and calling out.write(buf)? Probably nothing. Probably better to call write(b,0,b.length) directly. > Not my call, but in PSPrinterJob.java (970-977) it might be cleaner to just delete the unused code and comment. I agree but I was waiting for a suggestion from a 2D reviewer. > (The CSR will need to note the source incompatibility due to the removal of a declared exception) Right. Thanks, Brian From brian.burkhalter at oracle.com Fri Jul 12 19:54:30 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 12 Jul 2019 12:54:30 -0700 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: References: Message-ID: <86A0C35F-93C1-4F45-8723-72B723024B39@oracle.com> Here is new webrev incorporating the two changes below. http://cr.openjdk.java.net/~bpb/8187898/webrev.01/ Thanks, Brian > On Jul 12, 2019, at 12:01 PM, Brian Burkhalter wrote: > >> On Jul 12, 2019, at 11:17 AM, Roger Riggs > wrote: >> >> Would it be appropriate to add @Override to the new method (and perhaps existing overridden methods). > > Yes, I think so. > >> Previously, calling FilterOutputStream.write(byte[]) would delegate to write(byte[], 0, length). >> The proposed change duplicates the code and changes the ways that overridden classes might see the call. >> What's the benefit of duplicating the code and calling out.write(buf)? > > Probably nothing. Probably better to call write(b,0,b.length) directly. > >> Not my call, but in PSPrinterJob.java (970-977) it might be cleaner to just delete the unused code and comment. > > I agree but I was waiting for a suggestion from a 2D reviewer. From philip.race at oracle.com Fri Jul 12 20:02:08 2019 From: philip.race at oracle.com (Phil Race) Date: Fri, 12 Jul 2019 13:02:08 -0700 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: <86A0C35F-93C1-4F45-8723-72B723024B39@oracle.com> References: <86A0C35F-93C1-4F45-8723-72B723024B39@oracle.com> Message-ID: <2d6a465b-8f1d-6365-42f7-446381197474@oracle.com> > Not my call, but in PSPrinterJob.java (970-977) it might be cleaner to just delete the unused code and comment. Dilemma - since at 1036 we are throwing an Exception and the comment at 970-ish suggests the author was intending to do what s/he did at 1036 but never got around to it. I think I'd be more inclined to make the code at 970 like that at 1036. But (1) then the comment surely can go (2) I don't know why at 1034 you changed from PrinterIOException to PrinterException. And whilst great you are fixing up this code, we are but a small fraction of the world's code that use java.io and I wonder if this is worth the compatibility risk ? -phil On 7/12/19 12:54 PM, Brian Burkhalter wrote: > Here is new webrev incorporating the two changes below. > > http://cr.openjdk.java.net/~bpb/8187898/webrev.01/ > > Thanks, > > Brian > >> On Jul 12, 2019, at 12:01 PM, Brian Burkhalter wrote: >> >>> On Jul 12, 2019, at 11:17 AM, Roger Riggs > wrote: >>> >>> Would it be appropriate to add @Override to the new method (and perhaps existing overridden methods). >> Yes, I think so. >> >>> Previously, calling FilterOutputStream.write(byte[]) would delegate to write(byte[], 0, length). >>> The proposed change duplicates the code and changes the ways that overridden classes might see the call. >>> What's the benefit of duplicating the code and calling out.write(buf)? >> Probably nothing. Probably better to call write(b,0,b.length) directly. >> >>> Not my call, but in PSPrinterJob.java (970-977) it might be cleaner to just delete the unused code and comment. >> I agree but I was waiting for a suggestion from a 2D reviewer. From brian.burkhalter at oracle.com Fri Jul 12 20:10:18 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 12 Jul 2019 13:10:18 -0700 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: <2d6a465b-8f1d-6365-42f7-446381197474@oracle.com> References: <86A0C35F-93C1-4F45-8723-72B723024B39@oracle.com> <2d6a465b-8f1d-6365-42f7-446381197474@oracle.com> Message-ID: <2FB76DCE-B516-4520-84CA-09188CDE0C86@oracle.com> > On Jul 12, 2019, at 1:02 PM, Phil Race wrote: > >> Not my call, but in PSPrinterJob.java (970-977) it might be cleaner to just delete the unused code and comment. > > Dilemma - since at 1036 we are throwing an Exception and the comment at 970-ish suggests > the author was intending to do what s/he did at 1036 but never got around to it. > > I think I'd be more inclined to make the code at 970 like that at 1036. > But > (1) then the comment surely can go OK > (2) I don't know why at 1034 you changed from PrinterIOException to PrinterException. There is no PrinterIOException constructor which accepts a String as its only parameter and there is no IOException to pass to a PrinterIOException constructor. > And whilst great you are fixing up this code, we are but a small fraction of the world's code > that use java.io and I wonder if this is worth the compatibility risk ? I?m not sure either. I was leaving that decision to the CSR process. Thanks, Brian From roger.riggs at oracle.com Fri Jul 12 20:31:53 2019 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 12 Jul 2019 16:31:53 -0400 Subject: JDK 14 RFR of JDK-8202385: Annotation to mark serial-related fields and methods In-Reply-To: References: Message-ID: Hi Joe, As an annotation on a field or method, this is a use site annotation. From the description, the checks that could be added would only be done if the annotation was present and the annotation is a tag for existing fields and methods that are part of the serialization spec. The signatures of the fields and methods can be known to the compiler independent of the annotation and produce the same warnings. So this looks like a case of trying to have belt and suspenders. If the checks are not done when the annotation is not present, then it will still be the case that incorrect or misused fields and methods will still escape detection. Though the details of the compiler check are outside of the scope of this annotation, it seems unclear whether the annotation is necessary. Can the name of the annotation be more descriptive? Just "Serial" seems a bit too simple and does not have a strong binding to the Serialization classes and specification. Alternatives: ?? SerialMetadata ?? SerialControl ?? SerialFunction 39:? There should be a reference to the serialization specification for the definition of the fields and methods to make it clear where the authoritative identification is spec'd. 73-75:? Please align the
      and
    tags on separate lines with matching indentation. 77: Extra leading space. Regards, Roger On 7/9/19 7: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 philip.race at oracle.com Fri Jul 12 20:39:13 2019 From: philip.race at oracle.com (Phil Race) Date: Fri, 12 Jul 2019 13:39:13 -0700 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: <2FB76DCE-B516-4520-84CA-09188CDE0C86@oracle.com> References: <86A0C35F-93C1-4F45-8723-72B723024B39@oracle.com> <2d6a465b-8f1d-6365-42f7-446381197474@oracle.com> <2FB76DCE-B516-4520-84CA-09188CDE0C86@oracle.com> Message-ID: oh well ... in which I suppose this is the best you can do here. -phil. On 7/12/19 1:10 PM, Brian Burkhalter wrote: > >> (2) I don't know why at 1034 you changed from PrinterIOException to >> PrinterException. > > There is no PrinterIOException constructor which accepts a String as > its only parameter and there is no IOException to pass to a > PrinterIOException constructor. > From brian.burkhalter at oracle.com Fri Jul 12 22:12:55 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 12 Jul 2019 15:12:55 -0700 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: References: <86A0C35F-93C1-4F45-8723-72B723024B39@oracle.com> <2d6a465b-8f1d-6365-42f7-446381197474@oracle.com> <2FB76DCE-B516-4520-84CA-09188CDE0C86@oracle.com> Message-ID: <6C003DDC-E1CE-437D-A7B6-EF47B19D12C3@oracle.com> > I think I'd be more inclined to make the code at 970 like that at 1036. Can?t do this exactly as drawImageBGR at 903 does not throw a PrinterException. Have to use RuntimeException. Brian > On Jul 12, 2019, at 1:39 PM, Phil Race wrote: > > oh well ... in which I suppose this is the best you can do here. > > -phil. > > On 7/12/19 1:10 PM, Brian Burkhalter wrote: >> >>> (2) I don't know why at 1034 you changed from PrinterIOException to PrinterException. >> >> There is no PrinterIOException constructor which accepts a String as its only parameter and there is no IOException to pass to a PrinterIOException constructor. From mikhailo.seledtsov at oracle.com Fri Jul 12 22:19:49 2019 From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com) Date: Fri, 12 Jul 2019 15:19:49 -0700 Subject: RFR: 8227642: [TESTBUG] Make docker tests podman compatible In-Reply-To: <32c8a1934bf07e4c9c6a961e60dcb7abd9931fe1.camel@redhat.com> References: <32c8a1934bf07e4c9c6a961e60dcb7abd9931fe1.camel@redhat.com> Message-ID: <5bc3ac00-6ac9-99aa-052d-0a4aa6b04f8f@oracle.com> Hi Severin, ? The change looks good to me. Thank you for adding support for Podman container technology. Testing: I ran both HotSpot and JDK container tests with your patch; tests executed on Oracle Linux 7.6 using default container engine (Docker): ??? test/hotspot/jtreg/containers/?? AND test/jdk/jdk/internal/platform/docker/ All PASS Thanks, Misha On 7/12/19 11:08 AM, Severin Gehwolf wrote: > Hi, > > There is an alternative container engine which is being used by Fedora > and RHEL 8, called podman[1]. It's mostly compatible with docker. It > looks like OpenJDK docker tests can be made podman compatible with a > few little tweaks. One "interesting" one is to not assert "Successfully > built" in the build output but only rely on the exit code, which seems > to be OK for my testing. Interestingly the test would be skipped in > that case. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8227642 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227642/01/webrev/ > > Adjustments I've done: > * Don't assert "Successfully built" in image build output[2]. > * Add /usr/sbin to PATH as the podman binary relies on iptables for it > to work which is in /usr/sbin on Fedora > * Allow for Metrics.getCpuSystemUsage() and Metrics.getCpuUserUsage() > to be equal to the previous value. I've found those counters to be > slowly increasing, which made the tests unreliable. > > Testing: > > Running docker tests with docker as engine. Did the same with podman as > engine via -Djdk.test.docker.command=podman on Linux x86_64. Both > passed (non-trivially). > > Thoughts? > > Thanks, > Severin > > [1] https://podman.io/ > [2] Image builds with podman look > like ("COMMIT" over "Successfully built"): > STEP 1: FROM fedora:29 > STEP 2: RUN dnf install -y java-11-openjdk-devel && dnf clean all > --> Using cache 96f8b1a0dfe7dba581a64fc67a27002ddf52e032af55f9ddc765182a690afd9d > STEP 3: COPY TestMetrics.class TestMetrics.java /opt/ > 269042160f7a4e6a06789cd19640ea658a8f941bc53de0fd40a574dc3bdb49a8 > STEP 4: CMD /usr/lib/jvm/java-11-openjdk/bin/java -cp /opt --add-modules java.base --add-exports java.base/jdk.internal.platform=ALL-UNNAMED TestMetrics > STEP 5: COMMIT fedora-metrics-11 > d749088d6ce4510f212820ad4eca55a9b05e5c5c245f2372b6cfe91926e8cd7e > From philip.race at oracle.com Fri Jul 12 23:15:36 2019 From: philip.race at oracle.com (Philip Race) Date: Fri, 12 Jul 2019 16:15:36 -0700 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: <6C003DDC-E1CE-437D-A7B6-EF47B19D12C3@oracle.com> References: <86A0C35F-93C1-4F45-8723-72B723024B39@oracle.com> <2d6a465b-8f1d-6365-42f7-446381197474@oracle.com> <2FB76DCE-B516-4520-84CA-09188CDE0C86@oracle.com> <6C003DDC-E1CE-437D-A7B6-EF47B19D12C3@oracle.com> Message-ID: <5D291498.8070605@oracle.com> In that case just delete the comments and the commented out code ... -phil. On 7/12/19, 3:12 PM, Brian Burkhalter wrote: >> I think I'd be more inclined to make the code at 970 like that at 1036. > > Can?t do this exactly as drawImageBGR at 903 does not throw a > PrinterException. Have to use RuntimeException. > > Brian > >> On Jul 12, 2019, at 1:39 PM, Phil Race > > wrote: >> >> oh well ... in which I suppose this is the best you can do here. >> >> -phil. >> >> On 7/12/19 1:10 PM, Brian Burkhalter wrote: >>> >>>> (2) I don't know why at 1034 you changed from PrinterIOException to >>>> PrinterException. >>> >>> There is no PrinterIOException constructor which accepts a String as >>> its only parameter and there is no IOException to pass to a >>> PrinterIOException constructor. > From joe.darcy at oracle.com Sat Jul 13 03:19:16 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 12 Jul 2019 20:19:16 -0700 Subject: JDK 14 RFR of JDK-8202385: Annotation to mark serial-related fields and methods In-Reply-To: References: Message-ID: <83681e03-589b-b033-f0a1-75bfa3bb4114@oracle.com> Hi Roger, On 7/12/2019 1:31 PM, Roger Riggs wrote: > Hi Joe, > > As an annotation on a field or method, this is a use site annotation. It is an annotation intended for the declarations of fields and methods of Serializable types. > From the description, the checks that could be added would only be done > if the annotation was present and the annotation is a tag for existing > fields and methods that are part of the serialization spec. Right; the annotation is semantically only applicable to the fields and methods associated with the serialization system. > > The signatures of the fields and methods can be known to the compiler > independent > of the annotation and produce the same warnings. > So this looks like a case of trying to have belt and suspenders. > > If the checks are not done when the annotation is not present, then it > will still be > the case that incorrect or misused fields and methods will still > escape detection. > > Though the details of the compiler check are outside of the scope of > this annotation, > it seems unclear whether the annotation is necessary. I have a prototype annotation processor to implement checks for ??? JDK-8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields The current version of the processor does not assume the presence of java.io.Serial. The summarize the existing checking methodology: ??? If a type is Serialiazable and a field or method has a name matching the names of one of the special fields or methods to serialization, check that the field or method has the required modifiers, type, and, the the case of methods, parameter types and exception types. That is all well and good and represents a large fraction of the checking of interest. However, it does not catch a mis-declaration like "readobject" instead of "readObject". One could argue that sufficiently thorough testing should catch that kind of error; however, my impression is that thoroughness of testing is rare in practice. I don't think it would be reasonable for javac to have some kind of Hamming distance (https://en.wikipedia.org/wiki/Hamming_distance) check between the name of fields/methods and the name of the serialization related fields methods to try to catch such mis-declarations. An annotation like java.io.Serial is intended to allow the programmer to indicate "yes, this is supposed to be one of the serialization related fields or methods" and enable the compile to perform checks against that category of error. > > Can the name of the annotation be more descriptive? > Just "Serial" seems a bit too simple and does not have a strong > binding to the Serialization classes and specification. > Alternatives: > ?? SerialMetadata > ?? SerialControl > ?? SerialFunction From the earlier design iterations "Serial" was chosen to be evocative of the "@serial" javadoc tag. Thanks, -Joe > > > 39:? There should be a reference to the serialization specification > for the definition > of the fields and methods to make it clear where the authoritative > identification is spec'd. > > 73-75:? Please align the
      and
    tags on separate lines with > matching indentation. > > 77: Extra leading space. > > Regards, Roger > > On 7/9/19 7: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 peter.levart at gmail.com Sat Jul 13 09:20:09 2019 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 13 Jul 2019 11:20:09 +0200 Subject: RFR [14] JDK-8225763 Inflater and Deflater should implement AutoCloseable In-Reply-To: References: <1a0052f8-dc3f-9102-942e-e66e6f5ad694@gmail.com> <78E885C6-733F-46D7-A21F-F83E09E20DAE@oracle.com> <0F439A98-36C5-436D-9F08-22C2DEDE522F@oracle.com> Message-ID: <7c23c1bb-25c6-d7fc-3593-6d1198e9b640@gmail.com> Hi Jaikiran, On 7/12/19 9:07 AM, Jaikiran Pai wrote: > The new updated webrev is at > http://cr.openjdk.java.net/~jpai/webrev/8225763/4/webrev/ I don't know if there are any custom subclasses of Inflater/Deflater around and what they do, but hypothetically consider a subclass of Deflater similar to this: public class MyDeflater extends Deflater { ??? private final Object lock = new Object(); ??? @Override ??? public void finish() { ??????? synchronized (lock) { ??????????? super.finish(); ??????????? // ... my code ... ??????? } ??? } ??? @Override ??? public int deflate(byte[] output, int off, int len, int flush) { ??????? synchronized (lock) { ??????????? // ... my code ... ??????????? int result = super.deflate(output, off, len, flush); ??????????? // ... my code ... ??????????? return result; ??????? } ??? } ??? @Override ??? public int deflate(ByteBuffer output, int flush) { ??????? synchronized (lock) { ??????????? // ... my code ... ??????????? int result = super.deflate(output, flush); ??????????? // ... my code ... ??????????? return result; ??????? } ??? } ??? @Override ??? public void reset() { ??????? synchronized (lock) { ??????????? super.reset(); ??????????? // ... my code ... ??????? } ??? } ??? @Override ??? public void end() { ??????? synchronized (lock) { ??????????? super.end(); ??????????? // ... my code ... ??????? } ??? } } Currently, there's no problem with this subclass as Deflater never calls no overridable method while holding internal lock (zsref). The newly added close() method is different. It calls end() while holding a lock (zsref). Suppose that close() is called from one thread, while at the same time some other overridden method is called from another thread. Deadlock may happen. In your patch you are trying hard to prevent calling end() from close() if end() has already been called (directly or indirectly through close()) because a hypothetical subclass of Deflater that overrides end() might not be prepared for end() to be called multiple times (i.e. there was no specification requiring end() to be idempotent). But even in your implementation, there is a concurrent race possible that may allow the overridden end() method to be entered twice. Consider the following scenario: Thread A: calls end() explicitly Thread B: calls close() There's nothing preventing Thread B from entering overridden part of end() while thread A is executing this same part of code. Threads synchronize only at the point where the overridden end() calls super.end(): public class MyDeflater extends Deflater { ??? @Override ??? public void end() { ??? ??? // ... this part of code may execute concurrently ??? ??? super.end(); ??? ??? // ... this part of code may execute concurrently ??? } Well, the subclass may have it's own synchronization in place if it is used in a concurrent scenario, like in above hypothetical example: ??? @Override ??? public void end() { ??????? synchronized (lock) { ??? ?? ?? ? // ... this part of code may execute multiple times ??????????? super.end(); ??? ?? ?? ? // ... this part of code may execute multiple times ??????? } ??? } But such synchronization has the already mentioned dangerous property of causing deadlock when close() is called concurrently with end(). In addition it doesn't prevent parts of overridden end() method to be executed multiple times. The following implementation of close() is in no way less effective in preventing multiple executions of parts of code in overridden end() method: ??? public void close() { ??????? synchronized (zsRef) { ??????????? // check if already closed ??????????? if (zsRef.address() == 0) { ??????????????? return; ??????????? } ??????? } ??????? // call end() out of synchronized block to prevent ??????? // deadlock situations in concurrent scenarios ??????? end(); ??? } ...but it is deadlock safe. It can be argued that synchronization in Deflater is not meant to allow Deflater to be used from multiple threads effectively, because its API is not multithread friendly (there are races possible that would render such usage inpractical). I think synchronization in Deflater is only meant to keep Deflater internal state consistent which includes state used in native code. This is important to ensure stable operation of VM as inconsistency of state in native code may crash the VM. There could be intentional exploits in untrusted code that would try to crash the VM. So this is a VM stability measure, not an API that allows effective multithreaded usage. In single-threaded usage (that perhaps is the only practical usage), there are not problems with your implementation of close() as are no problems with proposed variant above. Regards, Peter From jai.forums2013 at gmail.com Sat Jul 13 14:18:04 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sat, 13 Jul 2019 19:48:04 +0530 Subject: RFR [14] JDK-8225763 Inflater and Deflater should implement AutoCloseable In-Reply-To: <7c23c1bb-25c6-d7fc-3593-6d1198e9b640@gmail.com> References: <1a0052f8-dc3f-9102-942e-e66e6f5ad694@gmail.com> <78E885C6-733F-46D7-A21F-F83E09E20DAE@oracle.com> <0F439A98-36C5-436D-9F08-22C2DEDE522F@oracle.com> <7c23c1bb-25c6-d7fc-3593-6d1198e9b640@gmail.com> Message-ID: Hello Peter, On 13/07/19 2:50 PM, Peter Levart wrote: > Hi Jaikiran, > > On 7/12/19 9:07 AM, Jaikiran Pai wrote: >> The new updated webrev is at >> http://cr.openjdk.java.net/~jpai/webrev/8225763/4/webrev/ > > > I don't know if there are any custom subclasses of Inflater/Deflater > around and what they do, but hypothetically consider a subclass of > Deflater similar to this: > > public class MyDeflater extends Deflater { > ??? private final Object lock = new Object(); > > ??? @Override > ??? public void finish() { > ??????? synchronized (lock) { > ??????????? super.finish(); > ??????????? // ... my code ... > ??????? } > ??? } > > ??? @Override > ??? public int deflate(byte[] output, int off, int len, int flush) { > ??????? synchronized (lock) { > ??????????? // ... my code ... > ??????????? int result = super.deflate(output, off, len, flush); > ??????????? // ... my code ... > ??????????? return result; > ??????? } > ??? } > > ??? @Override > ??? public int deflate(ByteBuffer output, int flush) { > ??????? synchronized (lock) { > ??????????? // ... my code ... > ??????????? int result = super.deflate(output, flush); > ??????????? // ... my code ... > ??????????? return result; > ??????? } > ??? } > > ??? @Override > ??? public void reset() { > ??????? synchronized (lock) { > ??????????? super.reset(); > ??????????? // ... my code ... > ??????? } > ??? } > > ??? @Override > ??? public void end() { > ??????? synchronized (lock) { > ??????????? super.end(); > ??????????? // ... my code ... > ??????? } > ??? } > } > > > Currently, there's no problem with this subclass as Deflater never > calls no overridable method while holding internal lock (zsref). The > newly added close() method is different. It calls end() while holding > a lock (zsref). Suppose that close() is called from one thread, while > at the same time some other overridden method is called from another > thread. Deadlock may happen. I'm really glad you brought this up. When I added this end() within the synchronized block of close(), I had the same question in mind and was wondering if it's something that we should consider. But I never pursued it enough to actual come up with a detailed analysis like the one you have done. Thank you for this. > > > In your patch you are trying hard to prevent calling end() from > close() if end() has already been called (directly or indirectly > through close()) because a hypothetical subclass of Deflater that > overrides end() might not be prepared for end() to be called multiple > times (i.e. there was no specification requiring end() to be > idempotent). But even in your implementation, there is a concurrent > race possible that may allow the overridden end() method to be entered > twice. Consider the following scenario: > > Thread A: calls end() explicitly > > Thread B: calls close() > > There's nothing preventing Thread B from entering overridden part of > end() while thread A is executing this same part of code. Threads > synchronize only at the point where the overridden end() calls > super.end(): > > public class MyDeflater extends Deflater { > ??? @Override > ??? public void end() { > ??? ??? // ... this part of code may execute concurrently > ??? ??? super.end(); > ??? ??? // ... this part of code may execute concurrently > ??? } > Good point. Agreed and it does defeat the code that tries to avoid having end() invoked more than once. > Well, the subclass may have it's own synchronization in place if it is > used in a concurrent scenario, like in above hypothetical example: > > ??? @Override > ??? public void end() { > ??????? synchronized (lock) { > ??? ?? ?? ? // ... this part of code may execute multiple times > ??????????? super.end(); > ??? ?? ?? ? // ... this part of code may execute multiple times > ??????? } > ??? } > > But such synchronization has the already mentioned dangerous property > of causing deadlock when close() is called concurrently with end(). In > addition it doesn't prevent parts of overridden end() method to be > executed multiple times. > > The following implementation of close() is in no way less effective in > preventing multiple executions of parts of code in overridden end() > method: > > ??? public void close() { > ??????? synchronized (zsRef) { > ??????????? // check if already closed > ??????????? if (zsRef.address() == 0) { > ??????????????? return; > ??????????? } > ??????? } > ??????? // call end() out of synchronized block to prevent > ??????? // deadlock situations in concurrent scenarios > ??????? end(); > ??? } > > ...but it is deadlock safe. > > It can be argued that synchronization in Deflater is not meant to > allow Deflater to be used from multiple threads effectively, because > its API is not multithread friendly (there are races possible that > would render such usage inpractical). I think synchronization in > Deflater is only meant to keep Deflater internal state consistent > which includes state used in native code. This is important to ensure > stable operation of VM as inconsistency of state in native code may > crash the VM. There could be intentional exploits in untrusted code > that would try to crash the VM. So this is a VM stability measure, not > an API that allows effective multithreaded usage. Thank you, I think that answers the question I had (in another thread[1] before this RFR was raised) about the thread safety expectations of these classes. > > In single-threaded usage (that perhaps is the only practical usage), > there are not problems with your implementation of close() as are no > problems with proposed variant above. > Right, so it all boils down to the expectation of the usage of these classes. I will need inputs from others who are more knowledgeable about these classes, to proceed further. Thank you very much for your detailed review and inputs. [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-June/061117.html -Jaikiran From amaembo at gmail.com Sat Jul 13 19:00:22 2019 From: amaembo at gmail.com (Tagir Valeev) Date: Sun, 14 Jul 2019 02:00:22 +0700 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: <2d6a465b-8f1d-6365-42f7-446381197474@oracle.com> References: <86A0C35F-93C1-4F45-8723-72B723024B39@oracle.com> <2d6a465b-8f1d-6365-42f7-446381197474@oracle.com> Message-ID: Hello! > And whilst great you are fixing up this code, we are but a small fraction > of the world's code > that use java.io and I wonder if this is worth the compatibility risk ? > Why not introducing a separate writeBytes method like it was done for ByteArrayOutputStream (JDK-8199713)? With best regards, Tagir Valeev > -phil > > > > On 7/12/19 12:54 PM, Brian Burkhalter wrote: > > Here is new webrev incorporating the two changes below. > > > > http://cr.openjdk.java.net/~bpb/8187898/webrev.01/ > > > > Thanks, > > > > Brian > > > >> On Jul 12, 2019, at 12:01 PM, Brian Burkhalter < > brian.burkhalter at oracle.com> wrote: > >> > >>> On Jul 12, 2019, at 11:17 AM, Roger Riggs > wrote: > >>> > >>> Would it be appropriate to add @Override to the new method (and > perhaps existing overridden methods). > >> Yes, I think so. > >> > >>> Previously, calling FilterOutputStream.write(byte[]) would delegate to > write(byte[], 0, length). > >>> The proposed change duplicates the code and changes the ways that > overridden classes might see the call. > >>> What's the benefit of duplicating the code and calling out.write(buf)? > >> Probably nothing. Probably better to call write(b,0,b.length) directly. > >> > >>> Not my call, but in PSPrinterJob.java (970-977) it might be cleaner to > just delete the unused code and comment. > >> I agree but I was waiting for a suggestion from a 2D reviewer. > > From joe.darcy at oracle.com Sat Jul 13 20:16:47 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Sat, 13 Jul 2019 13:16:47 -0700 Subject: JDK 14 RFR of JDK-8202385: Annotation to mark serial-related fields and methods In-Reply-To: <83681e03-589b-b033-f0a1-75bfa3bb4114@oracle.com> References: <83681e03-589b-b033-f0a1-75bfa3bb4114@oracle.com> Message-ID: <69ac9d9d-0fb8-5483-760c-97b3e6495539@oracle.com> PS I've uploaded an updated an iteration of the webrev ??? http://cr.openjdk.java.net/~darcy/8202385.4/ to address. the syntactic concerns previously raised. I added ??? ...defined by the? Java Object Serialization Specification... which is the current name of the document and is similar to the style of reference made in java.io.Serializable. Offhand, I didn't know of the correct idiom to refer to the document as a working hyperlink, but would be switch to that idiom. Cheers, -Joe On 7/12/2019 8:19 PM, Joe Darcy wrote: > Hi Roger, > > On 7/12/2019 1:31 PM, Roger Riggs wrote: >> Hi Joe, >> >> As an annotation on a field or method, this is a use site annotation. > > > It is an annotation intended for the declarations of fields and > methods of Serializable types. > > >> From the description, the checks that could be added would only be done >> if the annotation was present and the annotation is a tag for existing >> fields and methods that are part of the serialization spec. > > > Right; the annotation is semantically only applicable to the fields > and methods associated with the serialization system. > > >> >> The signatures of the fields and methods can be known to the compiler >> independent >> of the annotation and produce the same warnings. >> So this looks like a case of trying to have belt and suspenders. >> >> If the checks are not done when the annotation is not present, then >> it will still be >> the case that incorrect or misused fields and methods will still >> escape detection. >> >> Though the details of the compiler check are outside of the scope of >> this annotation, >> it seems unclear whether the annotation is necessary. > > I have a prototype annotation processor to implement checks for > > ??? JDK-8202056: Expand serial warning to check for bad overloads of > serial-related methods and ineffectual fields > > The current version of the processor does not assume the presence of > java.io.Serial. The summarize the existing checking methodology: > > ??? If a type is Serialiazable and a field or method has a name > matching the names of one of the special fields or methods to > serialization, check that the field or method has the required > modifiers, type, and, the the case of methods, parameter types and > exception types. > > That is all well and good and represents a large fraction of the > checking of interest. However, it does not catch a mis-declaration > like "readobject" instead of "readObject". One could argue that > sufficiently thorough testing should catch that kind of error; > however, my impression is that thoroughness of testing is rare in > practice. I don't think it would be reasonable for javac to have some > kind of Hamming distance > (https://en.wikipedia.org/wiki/Hamming_distance) check between the > name of fields/methods and the name of the serialization related > fields methods to try to catch such mis-declarations. An annotation > like java.io.Serial is intended to allow the programmer to indicate > "yes, this is supposed to be one of the serialization related fields > or methods" and enable the compile to perform checks against that > category of error. > > >> >> Can the name of the annotation be more descriptive? >> Just "Serial" seems a bit too simple and does not have a strong >> binding to the Serialization classes and specification. >> Alternatives: >> ?? SerialMetadata >> ?? SerialControl >> ?? SerialFunction > > From the earlier design iterations "Serial" was chosen to be evocative > of the "@serial" javadoc tag. > > Thanks, > > -Joe > >> >> >> 39:? There should be a reference to the serialization specification >> for the definition >> of the fields and methods to make it clear where the authoritative >> identification is spec'd. >> >> 73-75:? Please align the
      and
    tags on separate lines with >> matching indentation. >> >> 77: Extra leading space. >> >> Regards, Roger >> >> On 7/9/19 7: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 sgehwolf at redhat.com Mon Jul 15 08:04:17 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 15 Jul 2019 10:04:17 +0200 Subject: RFR: 8227642: [TESTBUG] Make docker tests podman compatible In-Reply-To: <5bc3ac00-6ac9-99aa-052d-0a4aa6b04f8f@oracle.com> References: <32c8a1934bf07e4c9c6a961e60dcb7abd9931fe1.camel@redhat.com> <5bc3ac00-6ac9-99aa-052d-0a4aa6b04f8f@oracle.com> Message-ID: Hi Misha, On Fri, 2019-07-12 at 15:19 -0700, mikhailo.seledtsov at oracle.com wrote: > Hi Severin, > > The change looks good to me. Thank you for adding support for Podman > container technology. > > Testing: I ran both HotSpot and JDK container tests with your patch; > tests executed on Oracle Linux 7.6 using default container engine (Docker): > > test/hotspot/jtreg/containers/ AND > test/jdk/jdk/internal/platform/docker/ > > All PASS Thanks for the review and check! Cheers, Severin > > Thanks, > > Misha > > > On 7/12/19 11:08 AM, Severin Gehwolf wrote: > > Hi, > > > > There is an alternative container engine which is being used by > > Fedora > > and RHEL 8, called podman[1]. It's mostly compatible with docker. > > It > > looks like OpenJDK docker tests can be made podman compatible with > > a > > few little tweaks. One "interesting" one is to not assert > > "Successfully > > built" in the build output but only rely on the exit code, which > > seems > > to be OK for my testing. Interestingly the test would be skipped in > > that case. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8227642 > > webrev: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227642/01/webrev/ > > > > Adjustments I've done: > > * Don't assert "Successfully built" in image build output[2]. > > * Add /usr/sbin to PATH as the podman binary relies on iptables > > for it > > to work which is in /usr/sbin on Fedora > > * Allow for Metrics.getCpuSystemUsage() and > > Metrics.getCpuUserUsage() > > to be equal to the previous value. I've found those counters to > > be > > slowly increasing, which made the tests unreliable. > > > > Testing: > > > > Running docker tests with docker as engine. Did the same with > > podman as > > engine via -Djdk.test.docker.command=podman on Linux x86_64. Both > > passed (non-trivially). > > > > Thoughts? > > > > Thanks, > > Severin > > > > [1] https://podman.io/ > > [2] Image builds with podman look > > like ("COMMIT" over "Successfully built"): > > STEP 1: FROM fedora:29 > > STEP 2: RUN dnf install -y java-11-openjdk-devel && dnf clean > > all > > --> Using cache > > 96f8b1a0dfe7dba581a64fc67a27002ddf52e032af55f9ddc765182a690afd9d > > STEP 3: COPY TestMetrics.class TestMetrics.java /opt/ > > 269042160f7a4e6a06789cd19640ea658a8f941bc53de0fd40a574dc3bdb49a8 > > STEP 4: CMD /usr/lib/jvm/java-11-openjdk/bin/java -cp /opt --add- > > modules java.base --add-exports > > java.base/jdk.internal.platform=ALL-UNNAMED TestMetrics > > STEP 5: COMMIT fedora-metrics-11 > > d749088d6ce4510f212820ad4eca55a9b05e5c5c245f2372b6cfe91926e8cd7e > > From frank.yuan at oracle.com Mon Jul 15 09:56:34 2019 From: frank.yuan at oracle.com (Frank Yuan) Date: Mon, 15 Jul 2019 17:56:34 +0800 Subject: RFR [14]: 8227438: [TESTLIB] Determine if file exists by Files.exists in function FileUtils.deleteFileIfExistsWithRetry In-Reply-To: References: <00b101d5387b$9fc77700$df566500$@oracle.com> Message-ID: <04f201d53af3$98e77ff0$cab67fd0$@oracle.com> Thank you, Joe and Lance! Pushed the change. Frank > -----Original Message----- > From: Joe Wang [mailto:huizhe.wang at oracle.com] > Subject: Re: RFR [14]: 8227438: [TESTLIB] Determine if file exists by Files.exists in function FileUtils.deleteFileIfExistsWithRetry > > +1 > > -Joe > > > On 7/11/19 11:32 PM, Frank Yuan wrote: > > Hi > > > > > > > > Would you like to review the following patch for > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8227438 > > > > > > > > --- a/test/lib/jdk/test/lib/util/FileUtils.java Thu Jul 11 15:58:54 2019 +0000 > > > > +++ b/test/lib/jdk/test/lib/util/FileUtils.java Fri Jul 12 13:33:30 2019 +0800 > > > > @@ -96,7 +96,7 @@ > > > > */ > > > > public static void deleteFileIfExistsWithRetry(Path path) throws IOException { > > > > try { > > > > - if (Files.exists(path)) { > > > > + if (!Files.notExists(path)) { > > > > deleteFileWithRetry0(path); > > > > } > > > > } catch (InterruptedException x) { > > > > > > > > > > > > Files.exists returns false if the existence cannot be determined, so replace it with "!Files.notExists" like the change in > > JDK-8184961. > > > > > > > > Thanks > > > > Frank > > > > > > From amaembo at gmail.com Mon Jul 15 10:58:00 2019 From: amaembo at gmail.com (Tagir Valeev) Date: Mon, 15 Jul 2019 17:58:00 +0700 Subject: RFR: 8176894 Provide specialized implementation for default methods putIfAbsent, computeIfAbsent, computeIfPresent, compute, merge in TreeMap Message-ID: Hello! 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 andy.herrick at oracle.com Mon Jul 15 11:48:37 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 15 Jul 2019 07:48:37 -0400 Subject: RFR: JDK-8220807: excessive verbose output when running with --win-per-user-install In-Reply-To: References: <45e3c2d7-7032-ff7a-8b88-e75867c47c78@oracle.com> Message-ID: <4c334144-0633-1aec-e0b0-a43fcabef22a@oracle.com> revised [3] to only suppress these warnings when --win-per-user-install option used [3] http://cr.openjdk.java.net/~herrick/8220807/webrev.02/ /Andy On 7/12/2019 1:22 PM, Alexey Semenyuk wrote: > Andy, > > The fix suppresses warning for system wide installations too,not just > for per user. Is this by intention? > > - Alexey > > On 7/12/2019 10:31 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). >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8220807 >> >> [2] http://cr.openjdk.java.net/~herrick/8220807/ >> >> /Andy >> > From alexey.semenyuk at oracle.com Mon Jul 15 12:27:39 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Mon, 15 Jul 2019 08:27:39 -0400 Subject: RFR: JDK-8220807: excessive verbose output when running with --win-per-user-install In-Reply-To: <4c334144-0633-1aec-e0b0-a43fcabef22a@oracle.com> References: <45e3c2d7-7032-ff7a-8b88-e75867c47c78@oracle.com> <4c334144-0633-1aec-e0b0-a43fcabef22a@oracle.com> Message-ID: Looks good. - Alexey On 7/15/2019 7:48 AM, Andy Herrick wrote: > revised [3] to only suppress these warnings when > --win-per-user-install option used > > [3] http://cr.openjdk.java.net/~herrick/8220807/webrev.02/ > > /Andy > > On 7/12/2019 1:22 PM, Alexey Semenyuk wrote: >> Andy, >> >> The fix suppresses warning for system wide installations too,not just >> for per user. Is this by intention? >> >> - Alexey >> >> On 7/12/2019 10:31 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). >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8220807 >>> >>> [2] http://cr.openjdk.java.net/~herrick/8220807/ >>> >>> /Andy >>> >> From sgehwolf at redhat.com Mon Jul 15 14:19:21 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 15 Jul 2019 16:19:21 +0200 Subject: [11u] RFR: 8227127: Era designator not displayed correctly using the COMPAT provider Message-ID: Hi, Could I please get a review of this 11u backport? The JDK 14 patch doesn't apply as is due to JDK-8221432 (CLDR data update) not being present. I've fixed LocaleDataTest.java's @bug line manually. Otherwise the patch is the same. Bug: https://bugs.openjdk.java.net/browse/JDK-8227127 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227127/01/webrev/ Testing: tier1 and manual test from the bug on Linux x86_64. Thanks, Severin From brian.burkhalter at oracle.com Mon Jul 15 15:58:32 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 15 Jul 2019 08:58:32 -0700 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: <5D291498.8070605@oracle.com> References: <86A0C35F-93C1-4F45-8723-72B723024B39@oracle.com> <2d6a465b-8f1d-6365-42f7-446381197474@oracle.com> <2FB76DCE-B516-4520-84CA-09188CDE0C86@oracle.com> <6C003DDC-E1CE-437D-A7B6-EF47B19D12C3@oracle.com> <5D291498.8070605@oracle.com> Message-ID: <8F1E9E38-D6F9-4DC0-BBAB-EC644E4628E3@oracle.com> So updated: http://cr.openjdk.java.net/~bpb/8187898/webrev.02/ Thanks, Brian > On Jul 12, 2019, at 4:15 PM, Philip Race wrote: > > In that case just delete the comments and the commented out code ... > > -phil. > > On 7/12/19, 3:12 PM, Brian Burkhalter wrote: >> >>> I think I'd be more inclined to make the code at 970 like that at 1036. >> >> Can?t do this exactly as drawImageBGR at 903 does not throw a PrinterException. Have to use RuntimeException. >> >> Brian >> >>> On Jul 12, 2019, at 1:39 PM, Phil Race > wrote: >>> >>> oh well ... in which I suppose this is the best you can do here. >>> >>> -phil. >>> >>> On 7/12/19 1:10 PM, Brian Burkhalter wrote: >>>> >>>>> (2) I don't know why at 1034 you changed from PrinterIOException to PrinterException. >>>> >>>> There is no PrinterIOException constructor which accepts a String as its only parameter and there is no IOException to pass to a PrinterIOException constructor. >> From brian.burkhalter at oracle.com Mon Jul 15 16:00:45 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 15 Jul 2019 09:00:45 -0700 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: References: <86A0C35F-93C1-4F45-8723-72B723024B39@oracle.com> <2d6a465b-8f1d-6365-42f7-446381197474@oracle.com> Message-ID: <71C745EA-D0C0-44FE-BBF8-0F9119078AD5@oracle.com> Hello, > On Jul 13, 2019, at 12:00 PM, Tagir Valeev wrote: > > And whilst great you are fixing up this code, we are but a small fraction of the world's code > that use java.io and I wonder if this is worth the compatibility risk ? > > Why not introducing a separate writeBytes method like it was done for ByteArrayOutputStream (JDK-8199713)? Actually that seems like a better idea: accomplishes the objective while not introducing a compatibility issue. Note: JDK 8199713 reference above is the CSR of the actual issue [1]. Thanks, [1] https://bugs.openjdk.java.net/browse/JDK-8180410 From vladimir.kozlov at oracle.com Mon Jul 15 16:27:38 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 15 Jul 2019 09:27:38 -0700 Subject: RFR: 8227574: Fix jtreg access denied failure with graal mode. In-Reply-To: References: Message-ID: Looks good to me. Thanks, Vladimir On 7/15/19 1:40 AM, Xiaohong Gong (Arm Technology China) wrote: > Hi, > > Please help to review the following patch that fixes two jtreg tests failure with graal mode due to the access denied issue. > Webrev: http://cr.openjdk.java.net/~pli/rfr/8227574/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8227574 > > JTReg tests: > jdk/java/net/URLPermission/URLTest.java > jdk/javax/sql/testng/test/rowset/spi/SyncFactoryPermissionsTests.java > fail due to losing permission of the JVMCI runtime. > This patch fixes the two tests by making their policy extending the default system policy which grants the permissions to jdk.internal.vm.compiler module and its dependencies. > > Thanks, > Xiaohong Gong > From vladimir.kozlov at oracle.com Mon Jul 15 16:30:14 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 15 Jul 2019 09:30:14 -0700 Subject: RFR: 8227615: [TESTBUG] Fix jtreg "jdk/sun/security/util/FilePermCompat/CompatImpact.java" failing with graal issue. In-Reply-To: References: Message-ID: <2a08e281-0f6f-d993-8213-c62f3e573559@oracle.com> Good. Thanks, Vladimir On 7/15/19 2:32 AM, Xiaohong Gong (Arm Technology China) wrote: > Hi, > > Please help to review this small patch: > Webrev: http://cr.openjdk.java.net/~pli/rfr/8227615/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8227615 > > Jtreg test "jdk/sun/security/util/FilePermCompat/CompatImpact.java" fails due to access denied to JVMCI runtime with graal mode. > This patch fixes the permission issue by making the application's own policy extending the default system policy. Besides it also fixes > the stderr file couldn't be found issue by renaming the file name to the right one. > > Thanks, > Xiaohong Gong > From naoto.sato at oracle.com Mon Jul 15 16:35:07 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 15 Jul 2019 09:35:07 -0700 Subject: [11u] RFR: 8227127: Era designator not displayed correctly using the COMPAT provider In-Reply-To: References: Message-ID: <054de3bb-2d10-9167-f2b2-d74a795510c5@oracle.com> Looks good to me. Naoto On 7/15/19 7:19 AM, Severin Gehwolf wrote: > Hi, > > Could I please get a review of this 11u backport? The JDK 14 patch > doesn't apply as is due to JDK-8221432 (CLDR data update) not being > present. I've fixed LocaleDataTest.java's @bug line manually. Otherwise > the patch is the same. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8227127 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227127/01/webrev/ > > Testing: tier1 and manual test from the bug on Linux x86_64. > > Thanks, > Severin > > > From Roger.Riggs at oracle.com Mon Jul 15 17:12:23 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 15 Jul 2019 13:12:23 -0400 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: <8F1E9E38-D6F9-4DC0-BBAB-EC644E4628E3@oracle.com> References: <86A0C35F-93C1-4F45-8723-72B723024B39@oracle.com> <2d6a465b-8f1d-6365-42f7-446381197474@oracle.com> <2FB76DCE-B516-4520-84CA-09188CDE0C86@oracle.com> <6C003DDC-E1CE-437D-A7B6-EF47B19D12C3@oracle.com> <5D291498.8070605@oracle.com> <8F1E9E38-D6F9-4DC0-BBAB-EC644E4628E3@oracle.com> Message-ID: Looks fine,? Brian. On 7/15/19 11:58 AM, Brian Burkhalter wrote: > So updated: http://cr.openjdk.java.net/~bpb/8187898/webrev.02/ > > Thanks, > > Brian > >> On Jul 12, 2019, at 4:15 PM, Philip Race wrote: >> >> In that case just delete the comments and the commented out code ... >> >> -phil. >> >> On 7/12/19, 3:12 PM, Brian Burkhalter wrote: >>>> I think I'd be more inclined to make the code at 970 like that at 1036. >>> Can?t do this exactly as drawImageBGR at 903 does not throw a PrinterException. Have to use RuntimeException. >>> >>> Brian >>> >>>> On Jul 12, 2019, at 1:39 PM, Phil Race > wrote: >>>> >>>> oh well ... in which I suppose this is the best you can do here. >>>> >>>> -phil. >>>> >>>> On 7/12/19 1:10 PM, Brian Burkhalter wrote: >>>>>> (2) I don't know why at 1034 you changed from PrinterIOException to PrinterException. >>>>> There is no PrinterIOException constructor which accepts a String as its only parameter and there is no IOException to pass to a PrinterIOException constructor. From brian.burkhalter at oracle.com Mon Jul 15 17:14:35 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 15 Jul 2019 10:14:35 -0700 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: <71C745EA-D0C0-44FE-BBF8-0F9119078AD5@oracle.com> References: <86A0C35F-93C1-4F45-8723-72B723024B39@oracle.com> <2d6a465b-8f1d-6365-42f7-446381197474@oracle.com> <71C745EA-D0C0-44FE-BBF8-0F9119078AD5@oracle.com> Message-ID: <714892D5-194F-4856-95F1-E38C6D7FF714@oracle.com> Here is an alternative version which adds a writeBytes(byte[]) method instead of overriding write(byte[]): http://cr.openjdk.java.net/~bpb/8187898/webrev-alt.00/ This has the advantage of allowing new code to call writeBytes() without a try-catch block without introducing a compatibility issue for code which is already calling write(byte[]) in a try-catch block. Thanks, Brian > On Jul 15, 2019, at 9:00 AM, Brian Burkhalter wrote: > >> On Jul 13, 2019, at 12:00 PM, Tagir Valeev > wrote: >> >> And whilst great you are fixing up this code, we are but a small fraction of the world's code >> that use java.io and I wonder if this is worth the compatibility risk ? >> >> Why not introducing a separate writeBytes method like it was done for ByteArrayOutputStream (JDK-8199713)? > > Actually that seems like a better idea: accomplishes the objective while not introducing a compatibility issue. Note: JDK 8199713 reference above is the CSR of the actual issue [1]. > > Thanks, > > [1] https://bugs.openjdk.java.net/browse/JDK-8180410 From jonathan.gibbons at oracle.com Mon Jul 15 18:50:45 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 15 Jul 2019 11:50:45 -0700 Subject: JDK 14 RFR of JDK-8202385: Annotation to mark serial-related fields and methods In-Reply-To: <69ac9d9d-0fb8-5483-760c-97b3e6495539@oracle.com> References: <83681e03-589b-b033-f0a1-75bfa3bb4114@oracle.com> <69ac9d9d-0fb8-5483-760c-97b3e6495539@oracle.com> Message-ID: Generally, the current idiom in JDK API docs is to use a link beginning "{@docRoot}/../specs/....." such as "{@docRoot}/../specs/serialization/index.html" -- Jon On 07/13/2019 01:16 PM, Joe Darcy wrote: > PS I've uploaded an updated an iteration of the webrev > > ??? http://cr.openjdk.java.net/~darcy/8202385.4/ > > to address. the syntactic concerns previously raised. I added > > ??? ...defined by the? Java Object Serialization > Specification... > > which is the current name of the document and is similar to the style > of reference made in java.io.Serializable. Offhand, I didn't know of > the correct idiom to refer to the document as a working hyperlink, but > would be switch to that idiom. > > Cheers, > > -Joe > > On 7/12/2019 8:19 PM, Joe Darcy wrote: >> Hi Roger, >> >> On 7/12/2019 1:31 PM, Roger Riggs wrote: >>> Hi Joe, >>> >>> As an annotation on a field or method, this is a use site annotation. >> >> >> It is an annotation intended for the declarations of fields and >> methods of Serializable types. >> >> >>> From the description, the checks that could be added would only be done >>> if the annotation was present and the annotation is a tag for existing >>> fields and methods that are part of the serialization spec. >> >> >> Right; the annotation is semantically only applicable to the fields >> and methods associated with the serialization system. >> >> >>> >>> The signatures of the fields and methods can be known to the >>> compiler independent >>> of the annotation and produce the same warnings. >>> So this looks like a case of trying to have belt and suspenders. >>> >>> If the checks are not done when the annotation is not present, then >>> it will still be >>> the case that incorrect or misused fields and methods will still >>> escape detection. >>> >>> Though the details of the compiler check are outside of the scope of >>> this annotation, >>> it seems unclear whether the annotation is necessary. >> >> I have a prototype annotation processor to implement checks for >> >> ??? JDK-8202056: Expand serial warning to check for bad overloads of >> serial-related methods and ineffectual fields >> >> The current version of the processor does not assume the presence of >> java.io.Serial. The summarize the existing checking methodology: >> >> ??? If a type is Serialiazable and a field or method has a name >> matching the names of one of the special fields or methods to >> serialization, check that the field or method has the required >> modifiers, type, and, the the case of methods, parameter types and >> exception types. >> >> That is all well and good and represents a large fraction of the >> checking of interest. However, it does not catch a mis-declaration >> like "readobject" instead of "readObject". One could argue that >> sufficiently thorough testing should catch that kind of error; >> however, my impression is that thoroughness of testing is rare in >> practice. I don't think it would be reasonable for javac to have some >> kind of Hamming distance >> (https://en.wikipedia.org/wiki/Hamming_distance) check between the >> name of fields/methods and the name of the serialization related >> fields methods to try to catch such mis-declarations. An annotation >> like java.io.Serial is intended to allow the programmer to indicate >> "yes, this is supposed to be one of the serialization related fields >> or methods" and enable the compile to perform checks against that >> category of error. >> >> >>> >>> Can the name of the annotation be more descriptive? >>> Just "Serial" seems a bit too simple and does not have a strong >>> binding to the Serialization classes and specification. >>> Alternatives: >>> ?? SerialMetadata >>> ?? SerialControl >>> ?? SerialFunction >> >> From the earlier design iterations "Serial" was chosen to be >> evocative of the "@serial" javadoc tag. >> >> Thanks, >> >> -Joe >> >>> >>> >>> 39:? There should be a reference to the serialization specification >>> for the definition >>> of the fields and methods to make it clear where the authoritative >>> identification is spec'd. >>> >>> 73-75:? Please align the
      and
    tags on separate lines with >>> matching indentation. >>> >>> 77: Extra leading space. >>> >>> Regards, Roger >>> >>> On 7/9/19 7: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 brian.burkhalter at oracle.com Mon Jul 15 20:03:40 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 15 Jul 2019 13:03:40 -0700 Subject: 8131664: Javadoc for PrintStream is now incorrect Message-ID: https://bugs.openjdk.java.net/browse/JDK-8131664 http://cr.openjdk.java.net/~bpb/8131664/webrev.00/ This patch proposes to clean up some verbiage in java.io .PrintStream with respect to the encoding being used to convert chars to bytes. Thanks, Brian From brian.burkhalter at oracle.com Mon Jul 15 20:07:22 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 15 Jul 2019 13:07:22 -0700 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: <714892D5-194F-4856-95F1-E38C6D7FF714@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> Message-ID: <91BF9F6F-5969-40AF-8E51-92D5E045F6D9@oracle.com> There is however this problematic statement in the PrintStream class doc that neither of the two alternative versions of the fix addresses: "Two other features are provided as well. Unlike other output streams, a PrintStream never throws an IOException; instead, exceptional situations merely set an internal flag that can be tested via the checkError method.? In both cases this would need to be changed as it is incorrect. Brian > On Jul 15, 2019, at 10:14 AM, Brian Burkhalter wrote: > > Here is an alternative version which adds a writeBytes(byte[]) method instead of overriding write(byte[]): > > http://cr.openjdk.java.net/~bpb/8187898/webrev-alt.00/ > > > This has the advantage of allowing new code to call writeBytes() without a try-catch block without introducing a compatibility issue for code which is already calling write(byte[]) in a try-catch block. From lance.andersen at oracle.com Mon Jul 15 20:33:04 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 15 Jul 2019 16:33:04 -0400 Subject: 8131664: Javadoc for PrintStream is now incorrect In-Reply-To: References: Message-ID: Hi Brian, Is there an existing CSR or are you waiting for the review to complete here? Overall, I think it is OK. The existing autoflush wording looks like it could use some wordsmithing at some point (as I know we do this a little differently in some of the APIs ) - ?A boolean? not sure we need to state this as it is obvious from the declaration. - Some places in the JDK, we say True if XXXX; false otherwise. I am not sure how many APIs after the really early ones start with ?if true?? Anyways, something to consider for a future todo list I guess :-) Best Lance > On Jul 15, 2019, at 4:03 PM, Brian Burkhalter wrote: > > https://bugs.openjdk.java.net/browse/JDK-8131664 > http://cr.openjdk.java.net/~bpb/8131664/webrev.00/ > > This patch proposes to clean up some verbiage in java.io .PrintStream with respect to the encoding being used to convert chars to bytes. > > Thanks, > > Brian > 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 Mon Jul 15 20:55:53 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 15 Jul 2019 13:55:53 -0700 Subject: 8131664: Javadoc for PrintStream is now incorrect In-Reply-To: References: Message-ID: <00A8BAF9-1E20-4AA5-A6E3-3A6031E2EC11@oracle.com> Hi Lance, > On Jul 15, 2019, at 1:33 PM, Lance Andersen wrote: > > Is there an existing CSR or are you waiting for the review to complete here? The latter. > Overall, I think it is OK. > > The existing autoflush wording looks like it could use some wordsmithing at some point (as I know we do this a little differently in some of the APIs ) > > - ?A boolean? not sure we need to state this as it is obvious from the declaration. It looks like here one could change "A boolean; if true,? to simply ?Whether?. > - Some places in the JDK, we say True if XXXX; false otherwise. I am not sure how many APIs after the really early ones start with ?if true?? > > Anyways, something to consider for a future todo list I guess :-) Might be worth doing. I?ll after any other comments come in. Thanks, Brian From andrewluotechnologies at outlook.com Mon Jul 15 23:10:44 2019 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Mon, 15 Jul 2019 23:10:44 +0000 Subject: [PATCH] Add const to input parameter for JNU_IsInstanceOfByName Message-ID: Hi Everyone, I'm making some const-correctness fixes to some downstream libraries that use JNU_* functions, and noticed that JNU_IsInstanceOfByName takes in the class name by char* instead of const char* when it does not need to modify the string. It would be useful to change this so that we don't have to (unnecessarily) const-cast every time and can safely pass string literals to this function. Patch is inline below - any comments/feedback welcome. Thanks, -Andrew diff -r 70fab3a8ff02 src/java.base/share/native/libjava/jni_util.c --- a/src/java.base/share/native/libjava/jni_util.c Tue Jul 16 07:29:12 2019 +0900 +++ b/src/java.base/share/native/libjava/jni_util.c Mon Jul 15 16:07:35 2019 -0700 @@ -1096,7 +1096,7 @@ } JNIEXPORT jint JNICALL -JNU_IsInstanceOfByName(JNIEnv *env, jobject object, char* classname) +JNU_IsInstanceOfByName(JNIEnv *env, jobject object, const char* classname) { jclass cls; if ((*env)->EnsureLocalCapacity(env, 1) < 0) diff -r 70fab3a8ff02 src/java.base/share/native/libjava/jni_util.h --- a/src/java.base/share/native/libjava/jni_util.h Tue Jul 16 07:29:12 2019 +0900 +++ b/src/java.base/share/native/libjava/jni_util.h Mon Jul 15 16:07:35 2019 -0700 @@ -208,7 +208,7 @@ * has been thrown. */ JNIEXPORT jint JNICALL -JNU_IsInstanceOfByName(JNIEnv *env, jobject object, char *classname); +JNU_IsInstanceOfByName(JNIEnv *env, jobject object, const char *classname); /* Get or set class and instance fields. From sgehwolf at redhat.com Tue Jul 16 12:36:05 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 16 Jul 2019 14:36:05 +0200 Subject: RFR: 8227642: [TESTBUG] Make docker tests podman compatible In-Reply-To: <5bc3ac00-6ac9-99aa-052d-0a4aa6b04f8f@oracle.com> References: <32c8a1934bf07e4c9c6a961e60dcb7abd9931fe1.camel@redhat.com> <5bc3ac00-6ac9-99aa-052d-0a4aa6b04f8f@oracle.com> Message-ID: Hi, I believe I still need a *R*eviewer for this. Any takers? Thanks, Severin On Fri, 2019-07-12 at 15:19 -0700, mikhailo.seledtsov at oracle.com wrote: > Hi Severin, > > The change looks good to me. Thank you for adding support for Podman > container technology. > > Testing: I ran both HotSpot and JDK container tests with your patch; > tests executed on Oracle Linux 7.6 using default container engine (Docker): > > test/hotspot/jtreg/containers/ AND > test/jdk/jdk/internal/platform/docker/ > > All PASS > > > Thanks, > > Misha > > > On 7/12/19 11:08 AM, Severin Gehwolf wrote: > > Hi, > > > > There is an alternative container engine which is being used by Fedora > > and RHEL 8, called podman[1]. It's mostly compatible with docker. It > > looks like OpenJDK docker tests can be made podman compatible with a > > few little tweaks. One "interesting" one is to not assert "Successfully > > built" in the build output but only rely on the exit code, which seems > > to be OK for my testing. Interestingly the test would be skipped in > > that case. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8227642 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227642/01/webrev/ > > > > Adjustments I've done: > > * Don't assert "Successfully built" in image build output[2]. > > * Add /usr/sbin to PATH as the podman binary relies on iptables for it > > to work which is in /usr/sbin on Fedora > > * Allow for Metrics.getCpuSystemUsage() and Metrics.getCpuUserUsage() > > to be equal to the previous value. I've found those counters to be > > slowly increasing, which made the tests unreliable. > > > > Testing: > > > > Running docker tests with docker as engine. Did the same with podman as > > engine via -Djdk.test.docker.command=podman on Linux x86_64. Both > > passed (non-trivially). > > > > Thoughts? > > > > Thanks, > > Severin > > > > [1] https://podman.io/ > > [2] Image builds with podman look > > like ("COMMIT" over "Successfully built"): > > STEP 1: FROM fedora:29 > > STEP 2: RUN dnf install -y java-11-openjdk-devel && dnf clean all > > --> Using cache 96f8b1a0dfe7dba581a64fc67a27002ddf52e032af55f9ddc765182a690afd9d > > STEP 3: COPY TestMetrics.class TestMetrics.java /opt/ > > 269042160f7a4e6a06789cd19640ea658a8f941bc53de0fd40a574dc3bdb49a8 > > STEP 4: CMD /usr/lib/jvm/java-11-openjdk/bin/java -cp /opt --add-modules java.base --add-exports java.base/jdk.internal.platform=ALL-UNNAMED TestMetrics > > STEP 5: COMMIT fedora-metrics-11 > > d749088d6ce4510f212820ad4eca55a9b05e5c5c245f2372b6cfe91926e8cd7e > > From claes.redestad at oracle.com Tue Jul 16 13:48:52 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 16 Jul 2019 15:48:52 +0200 Subject: RFR: 8227587: Add internal privileged System.loadLibrary In-Reply-To: References: <8cf6ed4d-194a-4428-f381-e7e3c0452cd6@oracle.com> <4943b69c-bc3a-f147-abb8-5b369eec5737@oracle.com> <2cbfd5d8-c4a0-4a2d-ba62-6fed14dc7155@oracle.com> <60d95350-c42c-1498-5c72-174736e863c0@oracle.com> <15a57e3c-065c-55c5-b6af-0644ed8f775b@oracle.com> Message-ID: <3d3ef452-48d8-caf0-75a7-bcc051b13f82@oracle.com> Hi, refactored to use a BootLoader::loadLibrary API that is only visible within the java.base module: http://cr.openjdk.java.net/~redestad/8227587/open.03/ I've retained the bridge to ClassLoader::loadLibrary for performance, but without any magic or privilege escalation involved. Moving sys_path / systemNativeLibraries out of ClassLoader seems quite complicated, so I've not attempted that refactoring for this RFE. /Claes On 2019-07-12 20:03, Mandy Chung wrote: > Just to recap what we discussed offline: > > We could introduce BootLoader::loadLibrary to load a system native > library for boot loader.? sys_path and systemNativeLibraries in > ClassLoader implementation are solely for boot loader and it seems > cleaner for BootLoader to handle loading of system native libraries > where it can be optimized for boot loader.? This would require > some refactoring. > > One possible solution is to add a shared secret to simply call > package-private ClassLoader::loadLibrary(Class fromClass, String name) > method and have BootLoader::loadLibrary to check if SM is present > and wrap the call with doPriv; otherwise, just call the shared > secret loadLibrary method. > > Then we can investigate in the future to refactor the native library > loading implementation to jdk.internal.loader. > > what do you think? > > Mandy > > On 7/12/19 8:25 AM, Mandy Chung wrote: >> Claes, >> >> Thanks for exploring this.? I would like to see if we can avoid >> introducing >> an internal @CS method (keep @CSM only for public APIs will help security >> analysis). >> >> There are other alternatives to improve the footprint performance. >> >> One idea is java.base and java.desktop each has its own utility method >> to load library.? No change is needed for java.net since only one >> loadLibrary >> call. >> >> Another idea is to add BootLoader.loadLibrary that skips the security >> permission overhead and only for boot loader use.? It would require >> refactoring. >> >> I think java.base and java.desktop having its own utility method is >> a simpler solution. >> >> Mandy >> >> On 7/12/19 7:55 AM, Claes Redestad wrote: >>> Hi, >>> >>> I'm dropping the java.desktop changes, and Mandy has asked me to explore >>> options that does not add a new @CallerSensitive entry point, even to a >>> strongly encapsulated API like JavaLangAccess >>> >>> Easiest of these is to explicitly provide the class context we're >>> calling from - with proper assertions. This is marginally more >>> performant due avoiding the Reflection.getCallerClass, but slightly less >>> convenient. >>> >>> http://cr.openjdk.java.net/~redestad/8227587/open.01/ >>> >>> /Claes >>> >>> On 2019-07-12 15:27, Roger Riggs wrote: >>>> Hi Claes, >>>> >>>> Looks fine. >>>> >>>> Thanks for the updates, Roger >>>> >>>> >>>> On 7/11/19 10:39 AM, Claes Redestad wrote: >>>>> Hi Roger, >>>>> >>>>> On 2019-07-11 16:10, Roger Riggs wrote: >>>>>> Hi Claes, >>>>>> >>>>>> JavaLangAccess.java: >>>>>> 316: Add @param tag >>>>> >>>>> done. >>>>> >>>>>> >>>>>> System.java:? 2282, 2287 >>>>>> Runtime.loadLibrary0 makes a second check for a security manager. >>>>>> Is there any potential gain by calling ClassLoader.loadLibrary >>>>>> directly? >>>>>> None of the internal uses would have a separatorChar. >>>>> >>>>> Most of the gain comes from not having to load one-off PA classes or >>>>> lambdas, but of course avoiding the indexOf and a few indirections are >>>>> marginally helpful to startup. We should at least assert that the >>>>> library names are sane, though. >>>>> >>>>>> >>>>>> I expect most of the files need a copyright update. >>>>>> The script in /make/scripts/update_copyright_year.sh should >>>>>> do the work for modified files. >>>>> >>>>> Fixed copyrights and updated in place: >>>>> http://cr.openjdk.java.net/~redestad/8227587/open.00 >>>>> >>>>> Thanks! >>>>> >>>>> /Claes >>>> >> > From chris.hegarty at oracle.com Tue Jul 16 14:52:40 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 16 Jul 2019 15:52:40 +0100 Subject: RFR: 8227587: Add internal privileged System.loadLibrary In-Reply-To: <3d3ef452-48d8-caf0-75a7-bcc051b13f82@oracle.com> References: <8cf6ed4d-194a-4428-f381-e7e3c0452cd6@oracle.com> <4943b69c-bc3a-f147-abb8-5b369eec5737@oracle.com> <2cbfd5d8-c4a0-4a2d-ba62-6fed14dc7155@oracle.com> <60d95350-c42c-1498-5c72-174736e863c0@oracle.com> <15a57e3c-065c-55c5-b6af-0644ed8f775b@oracle.com> <3d3ef452-48d8-caf0-75a7-bcc051b13f82@oracle.com> Message-ID: > On 16 Jul 2019, at 14:48, Claes Redestad wrote: > > Hi, > > refactored to use a BootLoader::loadLibrary API that is only visible > within the java.base module: > > http://cr.openjdk.java.net/~redestad/8227587/open.03/ I think that this is good Claes. Reviewed. -Chris. From Roger.Riggs at oracle.com Tue Jul 16 14:59:56 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 16 Jul 2019 10:59:56 -0400 Subject: RFR: 8227587: Add internal privileged System.loadLibrary In-Reply-To: References: <8cf6ed4d-194a-4428-f381-e7e3c0452cd6@oracle.com> <4943b69c-bc3a-f147-abb8-5b369eec5737@oracle.com> <2cbfd5d8-c4a0-4a2d-ba62-6fed14dc7155@oracle.com> <60d95350-c42c-1498-5c72-174736e863c0@oracle.com> <15a57e3c-065c-55c5-b6af-0644ed8f775b@oracle.com> <3d3ef452-48d8-caf0-75a7-bcc051b13f82@oracle.com> Message-ID: +1 On 7/16/19 10:52 AM, Chris Hegarty wrote: >> On 16 Jul 2019, at 14:48, Claes Redestad wrote: >> >> Hi, >> >> refactored to use a BootLoader::loadLibrary API that is only visible >> within the java.base module: >> >> http://cr.openjdk.java.net/~redestad/8227587/open.03/ > I think that this is good Claes. Reviewed. > > -Chris. From matthias.baesken at sap.com Tue Jul 16 15:04:19 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 16 Jul 2019 15:04:19 +0000 Subject: RFR : 8227737: avoid implicit-function-declaration on AIX Message-ID: Hello, please review the following AIX related change . It fixes a number of missing inclusions leading to implicit-function-declaration warnings when compiling with the recent xlc16 /xlclang . At various places in the native C coding in jdk, we miss header inclusions on AIX. This leads to warnings like : /nightly/jdk/src/java.base/unix/native/libjava/childproc.c:99:5: warning: implicitly declaring library function 'snprintf' with type 'int (char *, unsigned long, const char *, ...)' [-Wimplicit-function-declaration] snprintf(aix_fd_dir, 32, "/proc/%d/fd", getpid()); ^ /nightly/jdk/src/java.base/unix/native/libjava/childproc.c:99:5: note: include the header or explicitly provide a declaration for 'snprintf' or /nightly/jdk/src/java.base/aix/native/libjli/java_md_aix.c:38:5: warning: implicitly declaring library function 'memset' with type 'void *(void *, int, unsigned long)' [-Wimplicit-function-declaration] memset((void *)info, 0, sizeof(Dl_info)); /nightly/jdk/src/java.base/aix/native/libjli/java_md_aix.c:38:5: note: include the header or explicitly provide a declaration for 'memset' Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8227737 http://cr.openjdk.java.net/~mbaesken/webrevs/8227737.0/ Thanks, Matthias From brian.burkhalter at oracle.com Tue Jul 16 16:08:02 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 16 Jul 2019 16:08:02 +0000 (UTC) Subject: 8073213: javadoc of PushbackInputStream methods should specify NullPointerExceptions Message-ID: <2FCF047E-AD38-4335-B674-961917983C86@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8073213 Add javadoc of NPEs missing from two unread() methods; see below. It would not hurt in this class to also change ? to {@code ?} and @exception to @throws but that would clutter up the review. Thanks, Brian @@ -213,14 +213,15 @@ * of the pushback buffer. After this method returns, the next byte to be * read will have the value b[off], the byte after that will * have the value b[off+1], and so forth. * * @param b the byte array to push back. * @param off the start offset of the data. * @param len the number of bytes to push back. + * @exception NullPointerException If b is null. * @exception IOException If there is not enough room in the pushback * buffer for the specified number of bytes, * or this input stream has been closed by * invoking its {@link #close()} method. * @since 1.1 */ public void unread(byte[] b, int off, int len) throws IOException { @@ -235,14 +236,15 @@ /** * Pushes back an array of bytes by copying it to the front of the * pushback buffer. After this method returns, the next byte to be read * will have the value b[0], the byte after that will have the * value b[1], and so forth. * * @param b the byte array to push back + * @exception NullPointerException If b is null. * @exception IOException If there is not enough room in the pushback * buffer for the specified number of bytes, * or this input stream has been closed by * invoking its {@link #close()} method. * @since 1.1 */ public void unread(byte[] b) throws IOException { From huizhe.wang at oracle.com Tue Jul 16 16:34:30 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 16 Jul 2019 09:34:30 -0700 Subject: RFR [14/java.xml] 8176447: javax.xml.validation.Validator validates incorrectly on uniqueness constraint Message-ID: Please review a fix for the uniqueness constraint. The fix is at line 403 where the variable for tracking matches is reset. Without the reset, subsequent matches would have been skipped, thus not catching duplicate values. As the report's workaround indicated, this issue was fixed in Apache Xerces. This patch now brings the class up-to-date with the upstream source. All tests passed. JBS: https://bugs.openjdk.java.net/browse/JDK-8176447 webrevs: http://cr.openjdk.java.net/~joehw/jdk14/8176447/webrev/ Thanks, Joe From mandy.chung at oracle.com Tue Jul 16 16:42:56 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 16 Jul 2019 09:42:56 -0700 Subject: RFR: 8227587: Add internal privileged System.loadLibrary In-Reply-To: <3d3ef452-48d8-caf0-75a7-bcc051b13f82@oracle.com> References: <8cf6ed4d-194a-4428-f381-e7e3c0452cd6@oracle.com> <4943b69c-bc3a-f147-abb8-5b369eec5737@oracle.com> <2cbfd5d8-c4a0-4a2d-ba62-6fed14dc7155@oracle.com> <60d95350-c42c-1498-5c72-174736e863c0@oracle.com> <15a57e3c-065c-55c5-b6af-0644ed8f775b@oracle.com> <3d3ef452-48d8-caf0-75a7-bcc051b13f82@oracle.com> Message-ID: On 7/16/19 6:48 AM, Claes Redestad wrote: > Hi, > > refactored to use a BootLoader::loadLibrary API that is only visible > within the java.base module: > > http://cr.openjdk.java.net/~redestad/8227587/open.03/ > Looks good. Nit:? in JavaLangAccess ?? 321???? void loadLibrary(Class klass, String library); s/klass/caller/ > I've retained the bridge to ClassLoader::loadLibrary for performance, > but without any magic or privilege escalation involved. Moving sys_path > / systemNativeLibraries out of ClassLoader seems quite complicated, so > I've not attempted that refactoring for this RFE. Yes, it is non-trivial.? I will file a RFE for this possible clean up. Mandy From lance.andersen at oracle.com Tue Jul 16 17:19:25 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 16 Jul 2019 13:19:25 -0400 Subject: 8073213: javadoc of PushbackInputStream methods should specify NullPointerExceptions In-Reply-To: <2FCF047E-AD38-4335-B674-961917983C86@oracle.com> References: <2FCF047E-AD38-4335-B674-961917983C86@oracle.com> Message-ID: <08221CB5-DECF-437A-922F-6C5776FFA518@oracle.com> +1 > On Jul 16, 2019, at 12:08 PM, Brian Burkhalter wrote: > > https://bugs.openjdk.java.net/browse/JDK-8073213 > > Add javadoc of NPEs missing from two unread() methods; see below. > > It would not hurt in this class to also change ? to {@code ?} and @exception to @throws but that would clutter up the review. > > Thanks, > > Brian > > @@ -213,14 +213,15 @@ > * of the pushback buffer. After this method returns, the next byte to be > * read will have the value b[off], the byte after that will > * have the value b[off+1], and so forth. > * > * @param b the byte array to push back. > * @param off the start offset of the data. > * @param len the number of bytes to push back. > + * @exception NullPointerException If b is null. > * @exception IOException If there is not enough room in the pushback > * buffer for the specified number of bytes, > * or this input stream has been closed by > * invoking its {@link #close()} method. > * @since 1.1 > */ > public void unread(byte[] b, int off, int len) throws IOException { > @@ -235,14 +236,15 @@ > /** > * Pushes back an array of bytes by copying it to the front of the > * pushback buffer. After this method returns, the next byte to be read > * will have the value b[0], the byte after that will have the > * value b[1], and so forth. > * > * @param b the byte array to push back > + * @exception NullPointerException If b is null. > * @exception IOException If there is not enough room in the pushback > * buffer for the specified number of bytes, > * or this input stream has been closed by > * invoking its {@link #close()} method. > * @since 1.1 > */ > public void unread(byte[] b) throws IOException { 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 igor.ignatyev at oracle.com Tue Jul 16 18:49:08 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 16 Jul 2019 11:49:08 -0700 Subject: RFR: 8227642: [TESTBUG] Make docker tests podman compatible In-Reply-To: References: <32c8a1934bf07e4c9c6a961e60dcb7abd9931fe1.camel@redhat.com> <5bc3ac00-6ac9-99aa-052d-0a4aa6b04f8f@oracle.com> Message-ID: <47390A32-BD5B-4FF3-B93B-69ACECBC3E78@oracle.com> Hi Severin, I don't think that tests (or test libraries for that matter) should be responsible for setting correct PATH value, it should be a part of host configuration procedure (tests can/should check that all required bins are available though). in other words, I'd prefer if you remove 'env.put("PATH", ...)' lines from both DockerTestUtils and TestJFREvents. the rest looks good to me. Thanks, -- Igor > On Jul 16, 2019, at 5:36 AM, Severin Gehwolf wrote: > > Hi, > > I believe I still need a *R*eviewer for this. Any takers? > > Thanks, > Severin > > On Fri, 2019-07-12 at 15:19 -0700, mikhailo.seledtsov at oracle.com wrote: >> Hi Severin, >> >> The change looks good to me. Thank you for adding support for Podman >> container technology. >> >> Testing: I ran both HotSpot and JDK container tests with your patch; >> tests executed on Oracle Linux 7.6 using default container engine (Docker): >> >> test/hotspot/jtreg/containers/ AND >> test/jdk/jdk/internal/platform/docker/ >> >> All PASS >> >> >> Thanks, >> >> Misha >> >> >> On 7/12/19 11:08 AM, Severin Gehwolf wrote: >>> Hi, >>> >>> There is an alternative container engine which is being used by Fedora >>> and RHEL 8, called podman[1]. It's mostly compatible with docker. It >>> looks like OpenJDK docker tests can be made podman compatible with a >>> few little tweaks. One "interesting" one is to not assert "Successfully >>> built" in the build output but only rely on the exit code, which seems >>> to be OK for my testing. Interestingly the test would be skipped in >>> that case. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8227642 >>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227642/01/webrev/ >>> >>> Adjustments I've done: >>> * Don't assert "Successfully built" in image build output[2]. >>> * Add /usr/sbin to PATH as the podman binary relies on iptables for it >>> to work which is in /usr/sbin on Fedora >>> * Allow for Metrics.getCpuSystemUsage() and Metrics.getCpuUserUsage() >>> to be equal to the previous value. I've found those counters to be >>> slowly increasing, which made the tests unreliable. >>> >>> Testing: >>> >>> Running docker tests with docker as engine. Did the same with podman as >>> engine via -Djdk.test.docker.command=podman on Linux x86_64. Both >>> passed (non-trivially). >>> >>> Thoughts? >>> >>> Thanks, >>> Severin >>> >>> [1] https://podman.io/ >>> [2] Image builds with podman look >>> like ("COMMIT" over "Successfully built"): >>> STEP 1: FROM fedora:29 >>> STEP 2: RUN dnf install -y java-11-openjdk-devel && dnf clean all >>> --> Using cache 96f8b1a0dfe7dba581a64fc67a27002ddf52e032af55f9ddc765182a690afd9d >>> STEP 3: COPY TestMetrics.class TestMetrics.java /opt/ >>> 269042160f7a4e6a06789cd19640ea658a8f941bc53de0fd40a574dc3bdb49a8 >>> STEP 4: CMD /usr/lib/jvm/java-11-openjdk/bin/java -cp /opt --add-modules java.base --add-exports java.base/jdk.internal.platform=ALL-UNNAMED TestMetrics >>> STEP 5: COMMIT fedora-metrics-11 >>> d749088d6ce4510f212820ad4eca55a9b05e5c5c245f2372b6cfe91926e8cd7e >>> > From milan.mimica at gmail.com Tue Jul 16 19:07:31 2019 From: milan.mimica at gmail.com (Milan Mimica) Date: Tue, 16 Jul 2019 21:07:31 +0200 Subject: DnsClient TCP socket timeout Message-ID: Hello list Have you ever considered the problem reported here: https://stackoverflow.com/questions/14603553/dns-query-freezes-with-dnscontextfactory-in-java A DNS query gets stuck easily if read timeout is not set on the socket. The proposed solution is trivial. -- Milan Mimica From brian.burkhalter at oracle.com Tue Jul 16 19:16:34 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 16 Jul 2019 12:16:34 -0700 Subject: 8131664: Javadoc for PrintStream is now incorrect In-Reply-To: <00A8BAF9-1E20-4AA5-A6E3-3A6031E2EC11@oracle.com> References: <00A8BAF9-1E20-4AA5-A6E3-3A6031E2EC11@oracle.com> Message-ID: <3D4605B1-78A1-4F08-A9EE-152E3007D5BD@oracle.com> An updated version which includes the suggested change below is at [1] with a diff versus the reviewed version .00 at [2]. Thanks, Brian [1] http://cr.openjdk.java.net/~bpb/8131664/webrev.01/ [2] Version .01 vs. version .00 --- a/src/java.base/share/classes/java/io/PrintStream.java +++ b/src/java.base/share/classes/java/io/PrintStream.java @@ -141,7 +141,7 @@ * * @param out The output stream to which values and objects will be * printed - * @param autoFlush Whether the output buffer will be flushed + * @param autoFlush A boolean; if true, the output buffer will be flushed * whenever a byte array is written, one of the * {@code println} methods is invoked, or a newline * character or byte ({@code '\n'}) is written @@ -158,7 +158,7 @@ * * @param out The output stream to which values and objects will be * printed - * @param autoFlush Whether the output buffer will be flushed + * @param autoFlush A boolean; if true, the output buffer will be flushed * whenever a byte array is written, one of the * {@code println} methods is invoked, or a newline * character or byte ({@code '\n'}) is written @@ -185,7 +185,7 @@ * * @param out The output stream to which values and objects will be * printed - * @param autoFlush Whether the output buffer will be flushed + * @param autoFlush A boolean; if true, the output buffer will be flushed * whenever a byte array is written, one of the * {@code println} methods is invoked, or a newline * character or byte ({@code '\n'}) is written > On Jul 15, 2019, at 1:55 PM, Brian Burkhalter wrote: > >> The existing autoflush wording looks like it could use some wordsmithing at some point (as I know we do this a little differently in some of the APIs ) >> >> - ?A boolean? not sure we need to state this as it is obvious from the declaration. > > It looks like here one could change "A boolean; if true,? to simply ?Whether?. > >> - Some places in the JDK, we say True if XXXX; false otherwise. I am not sure how many APIs after the really early ones start with ?if true?? >> >> Anyways, something to consider for a future todo list I guess :-) > > Might be worth doing. I?ll after any other comments come in. From lance.andersen at oracle.com Tue Jul 16 19:20:26 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 16 Jul 2019 15:20:26 -0400 Subject: RFR [14/java.xml] 8176447: javax.xml.validation.Validator validates incorrectly on uniqueness constraint In-Reply-To: References: Message-ID: Looks OK Joe > On Jul 16, 2019, at 12:34 PM, Joe Wang wrote: > > Please review a fix for the uniqueness constraint. The fix is at line 403 where the variable for tracking matches is reset. Without the reset, subsequent matches would have been skipped, thus not catching duplicate values. > > As the report's workaround indicated, this issue was fixed in Apache Xerces. This patch now brings the class up-to-date with the upstream source. > > All tests passed. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8176447 > webrevs: http://cr.openjdk.java.net/~joehw/jdk14/8176447/webrev/ > > Thanks, > Joe Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From huizhe.wang at oracle.com Tue Jul 16 19:22:30 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 16 Jul 2019 12:22:30 -0700 Subject: RFR [14/java.xml] 8176447: javax.xml.validation.Validator validates incorrectly on uniqueness constraint In-Reply-To: References: Message-ID: <6da661a3-2a2f-b27c-89ff-b347e76f0e87@oracle.com> Thanks Lance! On 7/16/19 12:20 PM, Lance Andersen wrote: > Looks OK Joe > >> On Jul 16, 2019, at 12:34 PM, Joe Wang > > wrote: >> >> Please review a fix for the uniqueness constraint. The fix is at line >> 403 where the variable for tracking matches is reset. Without the >> reset, subsequent matches would have been skipped, thus not catching >> duplicate values. >> >> As the report's workaround indicated, this issue was fixed in Apache >> Xerces. This patch now brings the class up-to-date with the upstream >> source. >> >> All tests passed. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8176447 >> webrevs: http://cr.openjdk.java.net/~joehw/jdk14/8176447/webrev/ >> >> Thanks, >> Joe > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle?Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From lance.andersen at oracle.com Tue Jul 16 19:28:57 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 16 Jul 2019 15:28:57 -0400 Subject: 8131664: Javadoc for PrintStream is now incorrect In-Reply-To: <3D4605B1-78A1-4F08-A9EE-152E3007D5BD@oracle.com> References: <00A8BAF9-1E20-4AA5-A6E3-3A6031E2EC11@oracle.com> <3D4605B1-78A1-4F08-A9EE-152E3007D5BD@oracle.com> Message-ID: <3EEE6858-0AA7-48CF-B533-6AF209BF41EB@oracle.com> I think this is OK Brian > On Jul 16, 2019, at 3:16 PM, Brian Burkhalter wrote: > > An updated version which includes the suggested change below is at [1] with a diff versus the reviewed version .00 at [2]. > > Thanks, > > Brian > > [1] http://cr.openjdk.java.net/~bpb/8131664/webrev.01/ > [2] Version .01 vs. version .00 > > --- a/src/java.base/share/classes/java/io/PrintStream.java > +++ b/src/java.base/share/classes/java/io/PrintStream.java > @@ -141,7 +141,7 @@ > * > * @param out The output stream to which values and objects will be > * printed > - * @param autoFlush Whether the output buffer will be flushed > + * @param autoFlush A boolean; if true, the output buffer will be flushed > * whenever a byte array is written, one of the > * {@code println} methods is invoked, or a newline > * character or byte ({@code '\n'}) is written > @@ -158,7 +158,7 @@ > * > * @param out The output stream to which values and objects will be > * printed > - * @param autoFlush Whether the output buffer will be flushed > + * @param autoFlush A boolean; if true, the output buffer will be flushed > * whenever a byte array is written, one of the > * {@code println} methods is invoked, or a newline > * character or byte ({@code '\n'}) is written > @@ -185,7 +185,7 @@ > * > * @param out The output stream to which values and objects will be > * printed > - * @param autoFlush Whether the output buffer will be flushed > + * @param autoFlush A boolean; if true, the output buffer will be flushed > * whenever a byte array is written, one of the > * {@code println} methods is invoked, or a newline > * character or byte ({@code '\n'}) is written > > >> On Jul 15, 2019, at 1:55 PM, Brian Burkhalter wrote: >> >>> The existing autoflush wording looks like it could use some wordsmithing at some point (as I know we do this a little differently in some of the APIs ) >>> >>> - ?A boolean? not sure we need to state this as it is obvious from the declaration. >> >> It looks like here one could change "A boolean; if true,? to simply ?Whether?. >> >>> - Some places in the JDK, we say True if XXXX; false otherwise. I am not sure how many APIs after the really early ones start with ?if true?? >>> >>> Anyways, something to consider for a future todo list I guess :-) >> >> Might be worth doing. I?ll after any other comments come in. > 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 Tue Jul 16 19:45:58 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 16 Jul 2019 12:45:58 -0700 Subject: 8073213: javadoc of PushbackInputStream methods should specify NullPointerExceptions In-Reply-To: <08221CB5-DECF-437A-922F-6C5776FFA518@oracle.com> References: <2FCF047E-AD38-4335-B674-961917983C86@oracle.com> <08221CB5-DECF-437A-922F-6C5776FFA518@oracle.com> Message-ID: I changed ? to {@code ?} and @exception to @throws in [3]. The delta versus the original version [1] is at [2]. Thanks, Brian [1] http://cr.openjdk.java.net/~bpb/8073213/webrev.00/ [2] http://cr.openjdk.java.net/~bpb/8073213/webrev.00-01/ [3] http://cr.openjdk.java.net/~bpb/8073213/webrev.01/ > On Jul 16, 2019, at 10:19 AM, Lance Andersen wrote: > > +1 >> On Jul 16, 2019, at 12:08 PM, Brian Burkhalter > wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8073213 > >> >> Add javadoc of NPEs missing from two unread() methods; see below. >> >> It would not hurt in this class to also change ? to {@code ?} and @exception to @throws but that would clutter up the review. From lance.andersen at oracle.com Tue Jul 16 19:51:52 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 16 Jul 2019 15:51:52 -0400 Subject: 8073213: javadoc of PushbackInputStream methods should specify NullPointerExceptions In-Reply-To: References: <2FCF047E-AD38-4335-B674-961917983C86@oracle.com> <08221CB5-DECF-437A-922F-6C5776FFA518@oracle.com> Message-ID: <7BAD3A66-DFC8-47F0-AE60-92786E2DD86A@oracle.com> Looks fine Brian > On Jul 16, 2019, at 3:45 PM, Brian Burkhalter wrote: > > I changed ? to {@code ?} and @exception to @throws in [3]. The delta versus the original version [1] is at [2]. > > Thanks, > > Brian > > [1] http://cr.openjdk.java.net/~bpb/8073213/webrev.00/ > [2] http://cr.openjdk.java.net/~bpb/8073213/webrev.00-01/ > [3] http://cr.openjdk.java.net/~bpb/8073213/webrev.01/ > >> On Jul 16, 2019, at 10:19 AM, Lance Andersen wrote: >> >> +1 >>> On Jul 16, 2019, at 12:08 PM, Brian Burkhalter > wrote: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8073213 > >>> >>> Add javadoc of NPEs missing from two unread() methods; see below. >>> >>> It would not hurt in this class to also change ? to {@code ?} and @exception to @throws but that would clutter up the review. > 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 dmitry.chuyko at bell-sw.com Tue Jul 16 19:55:57 2019 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Tue, 16 Jul 2019 22:55:57 +0300 Subject: RFR (S): JDK-8222778: Packaging Tool (JEP 343) on Linux/AArch64 Message-ID: Hello, Please review a small patch that mostly fixes jpackage test for Linux aarch64 and also arm,x86,power. It is prepared for 'JDK-8200758-branch' branch of open 'sandbox' repo. There are few parts: 1. LinuxPlatform.cpp and IniFile.cpp got small fixes for compiler warnings. 2. LinuxDebBundler.getArch() now maps only x86_64 to amd64, x86 is still mapped to i386, and other archs map to themselves. 3. In tests, new method getRpmArch() was added to linux/base/Base.java, it maps JVMs os.arch to default rpmbuild arch. Multiple tests were modified to use that method instead of "x86_64" in rpm file name. Some timeouts were increased. bug: https://bugs.openjdk.java.net/browse/JDK-8222778 webrev: http://cr.openjdk.java.net/~dchuyko/8222778/webrev.00/ testing: test/jdk/tools/jpackage jtreg tests pass on Ubuntu 16.04 with rpmbuild on x86_64, aarch64, arm, x86 and power, except deb/MaintainerTest (fails everywhere similarly to x86_64 because of extra "Unknown" name in email). I didin't cover s390 as we in BellSoft currently don't build on that arch. On typical armv7 hw increased or default timeouts are still too low, while they are fine for some relatively weak aarch64 machines. Deb tests run especially slow because of dpkg-deb itself. I used "force-unsafe-io" option in /etc/dpkg/dpkg.cfg, it does reduce packaging time but still not enough to have really fast tests. -Dmitry From mikhailo.seledtsov at oracle.com Tue Jul 16 20:23:32 2019 From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com) Date: Tue, 16 Jul 2019 13:23:32 -0700 Subject: RFR: 8227642: [TESTBUG] Make docker tests podman compatible In-Reply-To: <47390A32-BD5B-4FF3-B93B-69ACECBC3E78@oracle.com> References: <32c8a1934bf07e4c9c6a961e60dcb7abd9931fe1.camel@redhat.com> <5bc3ac00-6ac9-99aa-052d-0a4aa6b04f8f@oracle.com> <47390A32-BD5B-4FF3-B93B-69ACECBC3E78@oracle.com> Message-ID: <99a03fcd-dd33-52ea-8f43-29c8aa2bcf78@oracle.com> Hi Igor, ?? In both cases the environment variable is set for the Docker/Podman container process, not the host system. This will not affect the host system in any way. The docker process has its own namespace for environment variables. Does this alleviate your concerns? Thank you, Misha On 7/16/19 11:49 AM, Igor Ignatyev wrote: > Hi Severin, > > I don't think that tests (or test libraries for that matter) should be responsible for setting correct PATH value, it should be a part of host configuration procedure (tests can/should check that all required bins are available though). in other words, I'd prefer if you remove 'env.put("PATH", ...)' lines from both DockerTestUtils and TestJFREvents. the rest looks good to me. > > Thanks, > -- Igor > >> On Jul 16, 2019, at 5:36 AM, Severin Gehwolf wrote: >> >> Hi, >> >> I believe I still need a *R*eviewer for this. Any takers? >> >> Thanks, >> Severin >> >> On Fri, 2019-07-12 at 15:19 -0700, mikhailo.seledtsov at oracle.com wrote: >>> Hi Severin, >>> >>> The change looks good to me. Thank you for adding support for Podman >>> container technology. >>> >>> Testing: I ran both HotSpot and JDK container tests with your patch; >>> tests executed on Oracle Linux 7.6 using default container engine (Docker): >>> >>> test/hotspot/jtreg/containers/ AND >>> test/jdk/jdk/internal/platform/docker/ >>> >>> All PASS >>> >>> >>> Thanks, >>> >>> Misha >>> >>> >>> On 7/12/19 11:08 AM, Severin Gehwolf wrote: >>>> Hi, >>>> >>>> There is an alternative container engine which is being used by Fedora >>>> and RHEL 8, called podman[1]. It's mostly compatible with docker. It >>>> looks like OpenJDK docker tests can be made podman compatible with a >>>> few little tweaks. One "interesting" one is to not assert "Successfully >>>> built" in the build output but only rely on the exit code, which seems >>>> to be OK for my testing. Interestingly the test would be skipped in >>>> that case. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8227642 >>>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227642/01/webrev/ >>>> >>>> Adjustments I've done: >>>> * Don't assert "Successfully built" in image build output[2]. >>>> * Add /usr/sbin to PATH as the podman binary relies on iptables for it >>>> to work which is in /usr/sbin on Fedora >>>> * Allow for Metrics.getCpuSystemUsage() and Metrics.getCpuUserUsage() >>>> to be equal to the previous value. I've found those counters to be >>>> slowly increasing, which made the tests unreliable. >>>> >>>> Testing: >>>> >>>> Running docker tests with docker as engine. Did the same with podman as >>>> engine via -Djdk.test.docker.command=podman on Linux x86_64. Both >>>> passed (non-trivially). >>>> >>>> Thoughts? >>>> >>>> Thanks, >>>> Severin >>>> >>>> [1] https://podman.io/ >>>> [2] Image builds with podman look >>>> like ("COMMIT" over "Successfully built"): >>>> STEP 1: FROM fedora:29 >>>> STEP 2: RUN dnf install -y java-11-openjdk-devel && dnf clean all >>>> --> Using cache 96f8b1a0dfe7dba581a64fc67a27002ddf52e032af55f9ddc765182a690afd9d >>>> STEP 3: COPY TestMetrics.class TestMetrics.java /opt/ >>>> 269042160f7a4e6a06789cd19640ea658a8f941bc53de0fd40a574dc3bdb49a8 >>>> STEP 4: CMD /usr/lib/jvm/java-11-openjdk/bin/java -cp /opt --add-modules java.base --add-exports java.base/jdk.internal.platform=ALL-UNNAMED TestMetrics >>>> STEP 5: COMMIT fedora-metrics-11 >>>> d749088d6ce4510f212820ad4eca55a9b05e5c5c245f2372b6cfe91926e8cd7e >>>> From igor.ignatyev at oracle.com Tue Jul 16 20:32:43 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 16 Jul 2019 13:32:43 -0700 Subject: RFR: 8227642: [TESTBUG] Make docker tests podman compatible In-Reply-To: <99a03fcd-dd33-52ea-8f43-29c8aa2bcf78@oracle.com> References: <32c8a1934bf07e4c9c6a961e60dcb7abd9931fe1.camel@redhat.com> <5bc3ac00-6ac9-99aa-052d-0a4aa6b04f8f@oracle.com> <47390A32-BD5B-4FF3-B93B-69ACECBC3E78@oracle.com> <99a03fcd-dd33-52ea-8f43-29c8aa2bcf78@oracle.com> Message-ID: <026F52EE-CD26-4E5F-B8D6-306C5DF358B8@oracle.com> Hi Misha, I understand that it doesn't alter the host system. my concern is that we move problem of host-configuration into tests. let's say tomorrow a new container engine will require something from /usr/local/sbin, or /usr/local/Cellar/docker/bin on another OS, or, god forbid, C:\Program Files(x86)\podman\bin. it has nothing to do w/ tests, it's a question of configuring a host, as I said, should be handled at another level by "scripts" run (once) prior test execution. -- Igor > On Jul 16, 2019, at 1:23 PM, mikhailo.seledtsov at oracle.com wrote: > > Hi Igor, > > In both cases the environment variable is set for the Docker/Podman container process, not the host system. This will not affect the host system in any way. The docker process has its own namespace for environment variables. Does this alleviate your concerns? > > > Thank you, > > Misha > > On 7/16/19 11:49 AM, Igor Ignatyev wrote: >> Hi Severin, >> >> I don't think that tests (or test libraries for that matter) should be responsible for setting correct PATH value, it should be a part of host configuration procedure (tests can/should check that all required bins are available though). in other words, I'd prefer if you remove 'env.put("PATH", ...)' lines from both DockerTestUtils and TestJFREvents. the rest looks good to me. >> >> Thanks, >> -- Igor >> >>> On Jul 16, 2019, at 5:36 AM, Severin Gehwolf wrote: >>> >>> Hi, >>> >>> I believe I still need a *R*eviewer for this. Any takers? >>> >>> Thanks, >>> Severin >>> >>> On Fri, 2019-07-12 at 15:19 -0700, mikhailo.seledtsov at oracle.com wrote: >>>> Hi Severin, >>>> >>>> The change looks good to me. Thank you for adding support for Podman >>>> container technology. >>>> >>>> Testing: I ran both HotSpot and JDK container tests with your patch; >>>> tests executed on Oracle Linux 7.6 using default container engine (Docker): >>>> >>>> test/hotspot/jtreg/containers/ AND >>>> test/jdk/jdk/internal/platform/docker/ >>>> >>>> All PASS >>>> >>>> >>>> Thanks, >>>> >>>> Misha >>>> >>>> >>>> On 7/12/19 11:08 AM, Severin Gehwolf wrote: >>>>> Hi, >>>>> >>>>> There is an alternative container engine which is being used by Fedora >>>>> and RHEL 8, called podman[1]. It's mostly compatible with docker. It >>>>> looks like OpenJDK docker tests can be made podman compatible with a >>>>> few little tweaks. One "interesting" one is to not assert "Successfully >>>>> built" in the build output but only rely on the exit code, which seems >>>>> to be OK for my testing. Interestingly the test would be skipped in >>>>> that case. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8227642 >>>>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227642/01/webrev/ >>>>> >>>>> Adjustments I've done: >>>>> * Don't assert "Successfully built" in image build output[2]. >>>>> * Add /usr/sbin to PATH as the podman binary relies on iptables for it >>>>> to work which is in /usr/sbin on Fedora >>>>> * Allow for Metrics.getCpuSystemUsage() and Metrics.getCpuUserUsage() >>>>> to be equal to the previous value. I've found those counters to be >>>>> slowly increasing, which made the tests unreliable. >>>>> >>>>> Testing: >>>>> >>>>> Running docker tests with docker as engine. Did the same with podman as >>>>> engine via -Djdk.test.docker.command=podman on Linux x86_64. Both >>>>> passed (non-trivially). >>>>> >>>>> Thoughts? >>>>> >>>>> Thanks, >>>>> Severin >>>>> >>>>> [1] https://podman.io/ >>>>> [2] Image builds with podman look >>>>> like ("COMMIT" over "Successfully built"): >>>>> STEP 1: FROM fedora:29 >>>>> STEP 2: RUN dnf install -y java-11-openjdk-devel && dnf clean all >>>>> --> Using cache 96f8b1a0dfe7dba581a64fc67a27002ddf52e032af55f9ddc765182a690afd9d >>>>> STEP 3: COPY TestMetrics.class TestMetrics.java /opt/ >>>>> 269042160f7a4e6a06789cd19640ea658a8f941bc53de0fd40a574dc3bdb49a8 >>>>> STEP 4: CMD /usr/lib/jvm/java-11-openjdk/bin/java -cp /opt --add-modules java.base --add-exports java.base/jdk.internal.platform=ALL-UNNAMED TestMetrics >>>>> STEP 5: COMMIT fedora-metrics-11 >>>>> d749088d6ce4510f212820ad4eca55a9b05e5c5c245f2372b6cfe91926e8cd7e >>>>> From sgehwolf at redhat.com Tue Jul 16 21:01:00 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 16 Jul 2019 23:01:00 +0200 Subject: RFR: 8227642: [TESTBUG] Make docker tests podman compatible In-Reply-To: <026F52EE-CD26-4E5F-B8D6-306C5DF358B8@oracle.com> References: <32c8a1934bf07e4c9c6a961e60dcb7abd9931fe1.camel@redhat.com> <5bc3ac00-6ac9-99aa-052d-0a4aa6b04f8f@oracle.com> <47390A32-BD5B-4FF3-B93B-69ACECBC3E78@oracle.com> <99a03fcd-dd33-52ea-8f43-29c8aa2bcf78@oracle.com> <026F52EE-CD26-4E5F-B8D6-306C5DF358B8@oracle.com> Message-ID: <73012440f0b8ea7c603ba1685717efc4734dd994.camel@redhat.com> Hi Igor, I understand the concern and I guess I could remove it and locally install a wrapper in /bin or /usr/bin for podman which adds /usr/sbin to the path. On the other hand... This seems to be an issue of code being run through jtreg. Looking at the jtr files I see this: ----------rerun:(21/1545)*---------- cd /disk/openjdk/upstream-sources/openjdk-head/JTwork/scratch && \\ DISPLAY=:0 \\ HOME=/home/sgehwolf \\ LANG=en_US.UTF-8 \\ PATH=/bin:/usr/bin \\ XMODIFIERS=@im=ibus \\ [...] So jtreg reduces the host's PATH to /bin:/usr/bin, which is insufficient for the podman case. The tag-spec docs[1] for jtreg mention for "shell" tests that it sets the PATH to the above settings. This affects Java tests as well it seems. ProcessBuilder outside jtreg has a sensible PATH as set up by the system, FWIW. So while my system is properly set up, jtreg interferes and renders this necessary. Any suggestions as to how to convince jtreg to use the host's PATH setting? Thanks, Severin [1] http://openjdk.java.net/jtreg/tag-spec.html On Tue, 2019-07-16 at 13:32 -0700, Igor Ignatyev wrote: > Hi Misha, > > I understand that it doesn't alter the host system. my concern is > that we move problem of host-configuration into tests. let's say > tomorrow a new container engine will require something from > /usr/local/sbin, or /usr/local/Cellar/docker/bin on another OS, or, > god forbid, C:\Program Files(x86)\podman\bin. it has nothing to do w/ > tests, it's a question of configuring a host, as I said, should be > handled at another level by "scripts" run (once) prior test > execution. > > -- Igor > > > On Jul 16, 2019, at 1:23 PM, mikhailo.seledtsov at oracle.com wrote: > > > > Hi Igor, > > > > In both cases the environment variable is set for the > > Docker/Podman container process, not the host system. This will not > > affect the host system in any way. The docker process has its own > > namespace for environment variables. Does this alleviate your > > concerns? > > > > > > Thank you, > > > > Misha > > > > On 7/16/19 11:49 AM, Igor Ignatyev wrote: > > > Hi Severin, > > > > > > I don't think that tests (or test libraries for that matter) > > > should be responsible for setting correct PATH value, it should > > > be a part of host configuration procedure (tests can/should check > > > that all required bins are available though). in other words, I'd > > > prefer if you remove 'env.put("PATH", ...)' lines from both > > > DockerTestUtils and TestJFREvents. the rest looks good to me. > > > > > > Thanks, > > > -- Igor > > > > > > > On Jul 16, 2019, at 5:36 AM, Severin Gehwolf < > > > > sgehwolf at redhat.com> wrote: > > > > > > > > Hi, > > > > > > > > I believe I still need a *R*eviewer for this. Any takers? > > > > > > > > Thanks, > > > > Severin > > > > > > > > On Fri, 2019-07-12 at 15:19 -0700, > > > > mikhailo.seledtsov at oracle.com wrote: > > > > > Hi Severin, > > > > > > > > > > The change looks good to me. Thank you for adding support > > > > > for Podman > > > > > container technology. > > > > > > > > > > Testing: I ran both HotSpot and JDK container tests with your > > > > > patch; > > > > > tests executed on Oracle Linux 7.6 using default container > > > > > engine (Docker): > > > > > > > > > > test/hotspot/jtreg/containers/ AND > > > > > test/jdk/jdk/internal/platform/docker/ > > > > > > > > > > All PASS > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Misha > > > > > > > > > > > > > > > On 7/12/19 11:08 AM, Severin Gehwolf wrote: > > > > > > Hi, > > > > > > > > > > > > There is an alternative container engine which is being > > > > > > used by Fedora > > > > > > and RHEL 8, called podman[1]. It's mostly compatible with > > > > > > docker. It > > > > > > looks like OpenJDK docker tests can be made podman > > > > > > compatible with a > > > > > > few little tweaks. One "interesting" one is to not assert > > > > > > "Successfully > > > > > > built" in the build output but only rely on the exit code, > > > > > > which seems > > > > > > to be OK for my testing. Interestingly the test would be > > > > > > skipped in > > > > > > that case. > > > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8227642 > > > > > > webrev: > > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227642/01/webrev/ > > > > > > > > > > > > Adjustments I've done: > > > > > > * Don't assert "Successfully built" in image build > > > > > > output[2]. > > > > > > * Add /usr/sbin to PATH as the podman binary relies on > > > > > > iptables for it > > > > > > to work which is in /usr/sbin on Fedora > > > > > > * Allow for Metrics.getCpuSystemUsage() and > > > > > > Metrics.getCpuUserUsage() > > > > > > to be equal to the previous value. I've found those > > > > > > counters to be > > > > > > slowly increasing, which made the tests unreliable. > > > > > > > > > > > > Testing: > > > > > > > > > > > > Running docker tests with docker as engine. Did the same > > > > > > with podman as > > > > > > engine via -Djdk.test.docker.command=podman on Linux > > > > > > x86_64. Both > > > > > > passed (non-trivially). > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > Thanks, > > > > > > Severin > > > > > > > > > > > > [1] https://podman.io/ > > > > > > [2] Image builds with podman look > > > > > > like ("COMMIT" over "Successfully built"): > > > > > > STEP 1: FROM fedora:29 > > > > > > STEP 2: RUN dnf install -y java-11-openjdk-devel && dnf > > > > > > clean all > > > > > > --> Using cache > > > > > > 96f8b1a0dfe7dba581a64fc67a27002ddf52e032af55f9ddc765182a690 > > > > > > afd9d > > > > > > STEP 3: COPY TestMetrics.class TestMetrics.java /opt/ > > > > > > 269042160f7a4e6a06789cd19640ea658a8f941bc53de0fd40a574dc3bd > > > > > > b49a8 > > > > > > STEP 4: CMD /usr/lib/jvm/java-11-openjdk/bin/java -cp /opt > > > > > > --add-modules java.base --add-exports > > > > > > java.base/jdk.internal.platform=ALL-UNNAMED TestMetrics > > > > > > STEP 5: COMMIT fedora-metrics-11 > > > > > > d749088d6ce4510f212820ad4eca55a9b05e5c5c245f2372b6cfe91926e > > > > > > 8cd7e > > > > > > From jonathan.gibbons at oracle.com Tue Jul 16 21:11:13 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 16 Jul 2019 14:11:13 -0700 Subject: RFR: 8227642: [TESTBUG] Make docker tests podman compatible In-Reply-To: <73012440f0b8ea7c603ba1685717efc4734dd994.camel@redhat.com> References: <32c8a1934bf07e4c9c6a961e60dcb7abd9931fe1.camel@redhat.com> <5bc3ac00-6ac9-99aa-052d-0a4aa6b04f8f@oracle.com> <47390A32-BD5B-4FF3-B93B-69ACECBC3E78@oracle.com> <99a03fcd-dd33-52ea-8f43-29c8aa2bcf78@oracle.com> <026F52EE-CD26-4E5F-B8D6-306C5DF358B8@oracle.com> <73012440f0b8ea7c603ba1685717efc4734dd994.camel@redhat.com> Message-ID: <6d0d25c5-9ca0-608e-93eb-f83093114b76@oracle.com> Severin, This might be a reasonable update to jtreg, to allow /usr/sbin on the path on Unix-like systems.? The intent of jtreg is to protect tests from random crufty stuff on the PATH, and /usr/sbin is not in that category. I've created CODETOOLS-7902505: Consider allowing /usr/sbin on $PATH https://bugs.openjdk.java.net/browse/CODETOOLS-7902505 The short-term workaround is to use the jtreg command-line option ??? -e:PATH which should override the default settign for PATH and pass through whatever you have set for $PATH. -- Jon On 07/16/2019 02:01 PM, Severin Gehwolf wrote: > Hi Igor, > > I understand the concern and I guess I could remove it and locally > install a wrapper in /bin or /usr/bin for podman which adds /usr/sbin > to the path. On the other hand... > > This seems to be an issue of code being run through jtreg. Looking at > the jtr files I see this: > > ----------rerun:(21/1545)*---------- > cd /disk/openjdk/upstream-sources/openjdk-head/JTwork/scratch && \\ > DISPLAY=:0 \\ > HOME=/home/sgehwolf \\ > LANG=en_US.UTF-8 \\ > PATH=/bin:/usr/bin \\ > XMODIFIERS=@im=ibus \\ > [...] > > So jtreg reduces the host's PATH to /bin:/usr/bin, which is > insufficient for the podman case. The tag-spec docs[1] for jtreg > mention for "shell" tests that it sets the PATH to the above settings. > This affects Java tests as well it seems. > > ProcessBuilder outside jtreg has a sensible PATH as set up by the > system, FWIW. > > So while my system is properly set up, jtreg interferes and renders > this necessary. Any suggestions as to how to convince jtreg to use the > host's PATH setting? > > Thanks, > Severin > > [1] http://openjdk.java.net/jtreg/tag-spec.html > > On Tue, 2019-07-16 at 13:32 -0700, Igor Ignatyev wrote: >> Hi Misha, >> >> I understand that it doesn't alter the host system. my concern is >> that we move problem of host-configuration into tests. let's say >> tomorrow a new container engine will require something from >> /usr/local/sbin, or /usr/local/Cellar/docker/bin on another OS, or, >> god forbid, C:\Program Files(x86)\podman\bin. it has nothing to do w/ >> tests, it's a question of configuring a host, as I said, should be >> handled at another level by "scripts" run (once) prior test >> execution. >> >> -- Igor >> >>> On Jul 16, 2019, at 1:23 PM, mikhailo.seledtsov at oracle.com wrote: >>> >>> Hi Igor, >>> >>> In both cases the environment variable is set for the >>> Docker/Podman container process, not the host system. This will not >>> affect the host system in any way. The docker process has its own >>> namespace for environment variables. Does this alleviate your >>> concerns? >>> >>> >>> Thank you, >>> >>> Misha >>> >>> On 7/16/19 11:49 AM, Igor Ignatyev wrote: >>>> Hi Severin, >>>> >>>> I don't think that tests (or test libraries for that matter) >>>> should be responsible for setting correct PATH value, it should >>>> be a part of host configuration procedure (tests can/should check >>>> that all required bins are available though). in other words, I'd >>>> prefer if you remove 'env.put("PATH", ...)' lines from both >>>> DockerTestUtils and TestJFREvents. the rest looks good to me. >>>> >>>> Thanks, >>>> -- Igor >>>> >>>>> On Jul 16, 2019, at 5:36 AM, Severin Gehwolf < >>>>> sgehwolf at redhat.com> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I believe I still need a *R*eviewer for this. Any takers? >>>>> >>>>> Thanks, >>>>> Severin >>>>> >>>>> On Fri, 2019-07-12 at 15:19 -0700, >>>>> mikhailo.seledtsov at oracle.com wrote: >>>>>> Hi Severin, >>>>>> >>>>>> The change looks good to me. Thank you for adding support >>>>>> for Podman >>>>>> container technology. >>>>>> >>>>>> Testing: I ran both HotSpot and JDK container tests with your >>>>>> patch; >>>>>> tests executed on Oracle Linux 7.6 using default container >>>>>> engine (Docker): >>>>>> >>>>>> test/hotspot/jtreg/containers/ AND >>>>>> test/jdk/jdk/internal/platform/docker/ >>>>>> >>>>>> All PASS >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Misha >>>>>> >>>>>> >>>>>> On 7/12/19 11:08 AM, Severin Gehwolf wrote: >>>>>>> Hi, >>>>>>> >>>>>>> There is an alternative container engine which is being >>>>>>> used by Fedora >>>>>>> and RHEL 8, called podman[1]. It's mostly compatible with >>>>>>> docker. It >>>>>>> looks like OpenJDK docker tests can be made podman >>>>>>> compatible with a >>>>>>> few little tweaks. One "interesting" one is to not assert >>>>>>> "Successfully >>>>>>> built" in the build output but only rely on the exit code, >>>>>>> which seems >>>>>>> to be OK for my testing. Interestingly the test would be >>>>>>> skipped in >>>>>>> that case. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8227642 >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227642/01/webrev/ >>>>>>> >>>>>>> Adjustments I've done: >>>>>>> * Don't assert "Successfully built" in image build >>>>>>> output[2]. >>>>>>> * Add /usr/sbin to PATH as the podman binary relies on >>>>>>> iptables for it >>>>>>> to work which is in /usr/sbin on Fedora >>>>>>> * Allow for Metrics.getCpuSystemUsage() and >>>>>>> Metrics.getCpuUserUsage() >>>>>>> to be equal to the previous value. I've found those >>>>>>> counters to be >>>>>>> slowly increasing, which made the tests unreliable. >>>>>>> >>>>>>> Testing: >>>>>>> >>>>>>> Running docker tests with docker as engine. Did the same >>>>>>> with podman as >>>>>>> engine via -Djdk.test.docker.command=podman on Linux >>>>>>> x86_64. Both >>>>>>> passed (non-trivially). >>>>>>> >>>>>>> Thoughts? >>>>>>> >>>>>>> Thanks, >>>>>>> Severin >>>>>>> >>>>>>> [1] https://podman.io/ >>>>>>> [2] Image builds with podman look >>>>>>> like ("COMMIT" over "Successfully built"): >>>>>>> STEP 1: FROM fedora:29 >>>>>>> STEP 2: RUN dnf install -y java-11-openjdk-devel && dnf >>>>>>> clean all >>>>>>> --> Using cache >>>>>>> 96f8b1a0dfe7dba581a64fc67a27002ddf52e032af55f9ddc765182a690 >>>>>>> afd9d >>>>>>> STEP 3: COPY TestMetrics.class TestMetrics.java /opt/ >>>>>>> 269042160f7a4e6a06789cd19640ea658a8f941bc53de0fd40a574dc3bd >>>>>>> b49a8 >>>>>>> STEP 4: CMD /usr/lib/jvm/java-11-openjdk/bin/java -cp /opt >>>>>>> --add-modules java.base --add-exports >>>>>>> java.base/jdk.internal.platform=ALL-UNNAMED TestMetrics >>>>>>> STEP 5: COMMIT fedora-metrics-11 >>>>>>> d749088d6ce4510f212820ad4eca55a9b05e5c5c245f2372b6cfe91926e >>>>>>> 8cd7e >>>>>>> From sgehwolf at redhat.com Tue Jul 16 21:21:33 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 16 Jul 2019 23:21:33 +0200 Subject: RFR: 8227642: [TESTBUG] Make docker tests podman compatible In-Reply-To: <6d0d25c5-9ca0-608e-93eb-f83093114b76@oracle.com> References: <32c8a1934bf07e4c9c6a961e60dcb7abd9931fe1.camel@redhat.com> <5bc3ac00-6ac9-99aa-052d-0a4aa6b04f8f@oracle.com> <47390A32-BD5B-4FF3-B93B-69ACECBC3E78@oracle.com> <99a03fcd-dd33-52ea-8f43-29c8aa2bcf78@oracle.com> <026F52EE-CD26-4E5F-B8D6-306C5DF358B8@oracle.com> <73012440f0b8ea7c603ba1685717efc4734dd994.camel@redhat.com> <6d0d25c5-9ca0-608e-93eb-f83093114b76@oracle.com> Message-ID: <0678d929475cde04c508da9c15ce2b9fcc36a738.camel@redhat.com> On Tue, 2019-07-16 at 14:11 -0700, Jonathan Gibbons wrote: > Severin, > > This might be a reasonable update to jtreg, to allow /usr/sbin on the path > on Unix-like systems. The intent of jtreg is to protect tests from random > crufty stuff on the PATH, and /usr/sbin is not in that category. > > I've created > CODETOOLS-7902505: Consider allowing /usr/sbin on $PATH > https://bugs.openjdk.java.net/browse/CODETOOLS-7902505 > > The short-term workaround is to use the jtreg command-line option > > -e:PATH > > which should override the default settign for PATH and pass through > whatever you have set for $PATH. Thanks, Jon! Cheers, Severin > -- Jon > > On 07/16/2019 02:01 PM, Severin Gehwolf wrote: > > Hi Igor, > > > > I understand the concern and I guess I could remove it and locally > > install a wrapper in /bin or /usr/bin for podman which adds > > /usr/sbin > > to the path. On the other hand... > > > > This seems to be an issue of code being run through jtreg. Looking > > at > > the jtr files I see this: > > > > ----------rerun:(21/1545)*---------- > > cd /disk/openjdk/upstream-sources/openjdk-head/JTwork/scratch && \\ > > DISPLAY=:0 \\ > > HOME=/home/sgehwolf \\ > > LANG=en_US.UTF-8 \\ > > PATH=/bin:/usr/bin \\ > > XMODIFIERS=@im=ibus \\ > > [...] > > > > So jtreg reduces the host's PATH to /bin:/usr/bin, which is > > insufficient for the podman case. The tag-spec docs[1] for jtreg > > mention for "shell" tests that it sets the PATH to the above > > settings. > > This affects Java tests as well it seems. > > > > ProcessBuilder outside jtreg has a sensible PATH as set up by the > > system, FWIW. > > > > So while my system is properly set up, jtreg interferes and renders > > this necessary. Any suggestions as to how to convince jtreg to use > > the > > host's PATH setting? > > > > Thanks, > > Severin > > > > [1] http://openjdk.java.net/jtreg/tag-spec.html > > > > On Tue, 2019-07-16 at 13:32 -0700, Igor Ignatyev wrote: > > > Hi Misha, > > > > > > I understand that it doesn't alter the host system. my concern is > > > that we move problem of host-configuration into tests. let's say > > > tomorrow a new container engine will require something from > > > /usr/local/sbin, or /usr/local/Cellar/docker/bin on another OS, > > > or, > > > god forbid, C:\Program Files(x86)\podman\bin. it has nothing to > > > do w/ > > > tests, it's a question of configuring a host, as I said, should > > > be > > > handled at another level by "scripts" run (once) prior test > > > execution. > > > > > > -- Igor > > > > > > > On Jul 16, 2019, at 1:23 PM, mikhailo.seledtsov at oracle.com > > > > wrote: > > > > > > > > Hi Igor, > > > > > > > > In both cases the environment variable is set for the > > > > Docker/Podman container process, not the host system. This will > > > > not > > > > affect the host system in any way. The docker process has its > > > > own > > > > namespace for environment variables. Does this alleviate your > > > > concerns? > > > > > > > > > > > > Thank you, > > > > > > > > Misha > > > > > > > > On 7/16/19 11:49 AM, Igor Ignatyev wrote: > > > > > Hi Severin, > > > > > > > > > > I don't think that tests (or test libraries for that matter) > > > > > should be responsible for setting correct PATH value, it > > > > > should > > > > > be a part of host configuration procedure (tests can/should > > > > > check > > > > > that all required bins are available though). in other words, > > > > > I'd > > > > > prefer if you remove 'env.put("PATH", ...)' lines from both > > > > > DockerTestUtils and TestJFREvents. the rest looks good to me. > > > > > > > > > > Thanks, > > > > > -- Igor > > > > > > > > > > > On Jul 16, 2019, at 5:36 AM, Severin Gehwolf < > > > > > > sgehwolf at redhat.com> wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > I believe I still need a *R*eviewer for this. Any takers? > > > > > > > > > > > > Thanks, > > > > > > Severin > > > > > > > > > > > > On Fri, 2019-07-12 at 15:19 -0700, > > > > > > mikhailo.seledtsov at oracle.com wrote: > > > > > > > Hi Severin, > > > > > > > > > > > > > > The change looks good to me. Thank you for adding > > > > > > > support > > > > > > > for Podman > > > > > > > container technology. > > > > > > > > > > > > > > Testing: I ran both HotSpot and JDK container tests with > > > > > > > your > > > > > > > patch; > > > > > > > tests executed on Oracle Linux 7.6 using default > > > > > > > container > > > > > > > engine (Docker): > > > > > > > > > > > > > > test/hotspot/jtreg/containers/ AND > > > > > > > test/jdk/jdk/internal/platform/docker/ > > > > > > > > > > > > > > All PASS > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Misha > > > > > > > > > > > > > > > > > > > > > On 7/12/19 11:08 AM, Severin Gehwolf wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > There is an alternative container engine which is being > > > > > > > > used by Fedora > > > > > > > > and RHEL 8, called podman[1]. It's mostly compatible > > > > > > > > with > > > > > > > > docker. It > > > > > > > > looks like OpenJDK docker tests can be made podman > > > > > > > > compatible with a > > > > > > > > few little tweaks. One "interesting" one is to not > > > > > > > > assert > > > > > > > > "Successfully > > > > > > > > built" in the build output but only rely on the exit > > > > > > > > code, > > > > > > > > which seems > > > > > > > > to be OK for my testing. Interestingly the test would > > > > > > > > be > > > > > > > > skipped in > > > > > > > > that case. > > > > > > > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8227642 > > > > > > > > webrev: > > > > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227642/01/webrev/ > > > > > > > > > > > > > > > > Adjustments I've done: > > > > > > > > * Don't assert "Successfully built" in image build > > > > > > > > output[2]. > > > > > > > > * Add /usr/sbin to PATH as the podman binary relies > > > > > > > > on > > > > > > > > iptables for it > > > > > > > > to work which is in /usr/sbin on Fedora > > > > > > > > * Allow for Metrics.getCpuSystemUsage() and > > > > > > > > Metrics.getCpuUserUsage() > > > > > > > > to be equal to the previous value. I've found those > > > > > > > > counters to be > > > > > > > > slowly increasing, which made the tests unreliable. > > > > > > > > > > > > > > > > Testing: > > > > > > > > > > > > > > > > Running docker tests with docker as engine. Did the > > > > > > > > same > > > > > > > > with podman as > > > > > > > > engine via -Djdk.test.docker.command=podman on Linux > > > > > > > > x86_64. Both > > > > > > > > passed (non-trivially). > > > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Severin > > > > > > > > > > > > > > > > [1] https://podman.io/ > > > > > > > > [2] Image builds with podman look > > > > > > > > like ("COMMIT" over "Successfully built"): > > > > > > > > STEP 1: FROM fedora:29 > > > > > > > > STEP 2: RUN dnf install -y java-11-openjdk-devel > > > > > > > > && dnf > > > > > > > > clean all > > > > > > > > --> Using cache > > > > > > > > 96f8b1a0dfe7dba581a64fc67a27002ddf52e032af55f9ddc765182 > > > > > > > > a690 > > > > > > > > afd9d > > > > > > > > STEP 3: COPY TestMetrics.class TestMetrics.java /opt/ > > > > > > > > 269042160f7a4e6a06789cd19640ea658a8f941bc53de0fd40a574d > > > > > > > > c3bd > > > > > > > > b49a8 > > > > > > > > STEP 4: CMD /usr/lib/jvm/java-11-openjdk/bin/java -cp > > > > > > > > /opt > > > > > > > > --add-modules java.base --add-exports > > > > > > > > java.base/jdk.internal.platform=ALL-UNNAMED TestMetrics > > > > > > > > STEP 5: COMMIT fedora-metrics-11 > > > > > > > > d749088d6ce4510f212820ad4eca55a9b05e5c5c245f2372b6cfe91 > > > > > > > > 926e > > > > > > > > 8cd7e > > > > > > > > From mikhailo.seledtsov at oracle.com Tue Jul 16 21:29:01 2019 From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com) Date: Tue, 16 Jul 2019 14:29:01 -0700 Subject: RFR: 8227642: [TESTBUG] Make docker tests podman compatible In-Reply-To: <026F52EE-CD26-4E5F-B8D6-306C5DF358B8@oracle.com> References: <32c8a1934bf07e4c9c6a961e60dcb7abd9931fe1.camel@redhat.com> <5bc3ac00-6ac9-99aa-052d-0a4aa6b04f8f@oracle.com> <47390A32-BD5B-4FF3-B93B-69ACECBC3E78@oracle.com> <99a03fcd-dd33-52ea-8f43-29c8aa2bcf78@oracle.com> <026F52EE-CD26-4E5F-B8D6-306C5DF358B8@oracle.com> Message-ID: <19774fe1-a49f-1fcf-cbbf-d3f55210d12d@oracle.com> On 7/16/19 1:32 PM, Igor Ignatyev wrote: > Hi Misha, > > I understand that it doesn't alter the host system. my concern is that we move problem of host-configuration into tests. let's say tomorrow a new container engine will require something from /usr/local/sbin, or /usr/local/Cellar/docker/bin on another OS, or, god forbid, C:\Program Files(x86)\podman\bin. it has nothing to do w/ tests, it's a question of configuring a host, as I said, should be handled at another level by "scripts" run (once) prior test execution. OK, it makes sense now. Thank you, Misha > > -- Igor > >> On Jul 16, 2019, at 1:23 PM, mikhailo.seledtsov at oracle.com wrote: >> >> Hi Igor, >> >> In both cases the environment variable is set for the Docker/Podman container process, not the host system. This will not affect the host system in any way. The docker process has its own namespace for environment variables. Does this alleviate your concerns? >> >> >> Thank you, >> >> Misha >> >> On 7/16/19 11:49 AM, Igor Ignatyev wrote: >>> Hi Severin, >>> >>> I don't think that tests (or test libraries for that matter) should be responsible for setting correct PATH value, it should be a part of host configuration procedure (tests can/should check that all required bins are available though). in other words, I'd prefer if you remove 'env.put("PATH", ...)' lines from both DockerTestUtils and TestJFREvents. the rest looks good to me. >>> >>> Thanks, >>> -- Igor >>> >>>> On Jul 16, 2019, at 5:36 AM, Severin Gehwolf wrote: >>>> >>>> Hi, >>>> >>>> I believe I still need a *R*eviewer for this. Any takers? >>>> >>>> Thanks, >>>> Severin >>>> >>>> On Fri, 2019-07-12 at 15:19 -0700, mikhailo.seledtsov at oracle.com wrote: >>>>> Hi Severin, >>>>> >>>>> The change looks good to me. Thank you for adding support for Podman >>>>> container technology. >>>>> >>>>> Testing: I ran both HotSpot and JDK container tests with your patch; >>>>> tests executed on Oracle Linux 7.6 using default container engine (Docker): >>>>> >>>>> test/hotspot/jtreg/containers/ AND >>>>> test/jdk/jdk/internal/platform/docker/ >>>>> >>>>> All PASS >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Misha >>>>> >>>>> >>>>> On 7/12/19 11:08 AM, Severin Gehwolf wrote: >>>>>> Hi, >>>>>> >>>>>> There is an alternative container engine which is being used by Fedora >>>>>> and RHEL 8, called podman[1]. It's mostly compatible with docker. It >>>>>> looks like OpenJDK docker tests can be made podman compatible with a >>>>>> few little tweaks. One "interesting" one is to not assert "Successfully >>>>>> built" in the build output but only rely on the exit code, which seems >>>>>> to be OK for my testing. Interestingly the test would be skipped in >>>>>> that case. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8227642 >>>>>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227642/01/webrev/ >>>>>> >>>>>> Adjustments I've done: >>>>>> * Don't assert "Successfully built" in image build output[2]. >>>>>> * Add /usr/sbin to PATH as the podman binary relies on iptables for it >>>>>> to work which is in /usr/sbin on Fedora >>>>>> * Allow for Metrics.getCpuSystemUsage() and Metrics.getCpuUserUsage() >>>>>> to be equal to the previous value. I've found those counters to be >>>>>> slowly increasing, which made the tests unreliable. >>>>>> >>>>>> Testing: >>>>>> >>>>>> Running docker tests with docker as engine. Did the same with podman as >>>>>> engine via -Djdk.test.docker.command=podman on Linux x86_64. Both >>>>>> passed (non-trivially). >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> Thanks, >>>>>> Severin >>>>>> >>>>>> [1] https://podman.io/ >>>>>> [2] Image builds with podman look >>>>>> like ("COMMIT" over "Successfully built"): >>>>>> STEP 1: FROM fedora:29 >>>>>> STEP 2: RUN dnf install -y java-11-openjdk-devel && dnf clean all >>>>>> --> Using cache 96f8b1a0dfe7dba581a64fc67a27002ddf52e032af55f9ddc765182a690afd9d >>>>>> STEP 3: COPY TestMetrics.class TestMetrics.java /opt/ >>>>>> 269042160f7a4e6a06789cd19640ea658a8f941bc53de0fd40a574dc3bdb49a8 >>>>>> STEP 4: CMD /usr/lib/jvm/java-11-openjdk/bin/java -cp /opt --add-modules java.base --add-exports java.base/jdk.internal.platform=ALL-UNNAMED TestMetrics >>>>>> STEP 5: COMMIT fedora-metrics-11 >>>>>> d749088d6ce4510f212820ad4eca55a9b05e5c5c245f2372b6cfe91926e8cd7e >>>>>> From alexander.matveev at oracle.com Tue Jul 16 21:30:05 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Tue, 16 Jul 2019 14:30:05 -0700 Subject: RFR (S): JDK-8222778: Packaging Tool (JEP 343) on Linux/AArch64 In-Reply-To: References: Message-ID: <547af6cd-de60-227b-8a1f-6889cbb0b1aa@oracle.com> Hi Dmitry, http://cr.openjdk.java.net/~dchuyko/8222778/webrev.00/src/jdk.jpackage/unix/native/libapplauncher/PosixPlatform.cpp.frames.html Why code between lines 215 and 219 was disabled? Not sure what it tries to do, if it tries to guarantee NULL termination we should probably keep it or allocate buffer with extra null or read (sizeof(buffer)-1). I think EOF defined as -1. Otherwise looks fine. Thanks, Alexander On 7/16/2019 12:55 PM, Dmitry Chuyko wrote: > Hello, > > Please review a small patch that mostly fixes jpackage test for Linux > aarch64 and also arm,x86,power. It is prepared for > 'JDK-8200758-branch' branch of open 'sandbox' repo. > > There are few parts: > > 1. LinuxPlatform.cpp and IniFile.cpp got small fixes for compiler > warnings. > > 2. LinuxDebBundler.getArch() now maps only x86_64 to amd64, x86 is > still mapped to i386, and other archs map to themselves. > > 3. In tests, new method getRpmArch() was added to > linux/base/Base.java, it maps JVMs os.arch to default rpmbuild arch. > Multiple tests were modified to use that method instead of "x86_64" in > rpm file name. Some timeouts were increased. > > bug: https://bugs.openjdk.java.net/browse/JDK-8222778 > > webrev: http://cr.openjdk.java.net/~dchuyko/8222778/webrev.00/ > > testing: test/jdk/tools/jpackage jtreg tests pass on Ubuntu 16.04 with > rpmbuild on x86_64, aarch64, arm, x86 and power, except > deb/MaintainerTest (fails everywhere similarly to x86_64 because of > extra "Unknown" name in email). > > I didin't cover s390 as we in BellSoft currently don't build on that > arch. On typical armv7 hw increased or default timeouts are still too > low, while they are fine for some relatively weak aarch64 machines. > Deb tests run especially slow because of dpkg-deb itself. I used > "force-unsafe-io" option in /etc/dpkg/dpkg.cfg, it does reduce > packaging time but still not enough to have really fast tests. > > -Dmitry > > From dmitry.chuyko at bell-sw.com Tue Jul 16 22:50:14 2019 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Wed, 17 Jul 2019 01:50:14 +0300 Subject: RFR (S): JDK-8222778: Packaging Tool (JEP 343) on Linux/AArch64 In-Reply-To: <547af6cd-de60-227b-8a1f-6889cbb0b1aa@oracle.com> References: <547af6cd-de60-227b-8a1f-6889cbb0b1aa@oracle.com> Message-ID: <0b27c1cc-2770-9e1c-3497-a281c0959b2e@bell-sw.com> Alexander, thanks for having a look, On 7/17/19 12:30 AM, Alexander Matveev wrote: > Hi Dmitry, > > http://cr.openjdk.java.net/~dchuyko/8222778/webrev.00/src/jdk.jpackage/unix/native/libapplauncher/PosixPlatform.cpp.frames.html > > Why code between lines 215 and 219 was disabled? Not sure what it > tries to do, if it tries to guarantee NULL termination we should > probably keep it or allocate buffer with extra null or read > (sizeof(buffer)-1). I think EOF defined as -1. gcc 5.4.0 on Linux reports an error: sandbox/src/jdk.jpackage/unix/native/libapplauncher/PosixPlatform.cpp: In member function ?bool PosixProcess::ReadOutput()?: sandbox/src/jdk.jpackage/unix/native/libapplauncher/PosixPlatform.cpp:215:35: error: comparison is always false due to limited range of data type [-Werror=type-limits] ???????????? if (buffer[count - 1] == EOF) { Here buffer is char[] and read(int, void *, size_t) is used. It won't be right to keep it commented, to me it looks like this block can be removed. If not, there should be some other fix like adding ifdefs for some platforms or using call different from read(). -Dmitry > Otherwise looks fine. > > Thanks, > Alexander > > On 7/16/2019 12:55 PM, Dmitry Chuyko wrote: >> Hello, >> >> Please review a small patch that mostly fixes jpackage test for Linux >> aarch64 and also arm,x86,power. It is prepared for >> 'JDK-8200758-branch' branch of open 'sandbox' repo. >> >> There are few parts: >> >> 1. LinuxPlatform.cpp and IniFile.cpp got small fixes for compiler >> warnings. >> >> 2. LinuxDebBundler.getArch() now maps only x86_64 to amd64, x86 is >> still mapped to i386, and other archs map to themselves. >> >> 3. In tests, new method getRpmArch() was added to >> linux/base/Base.java, it maps JVMs os.arch to default rpmbuild arch. >> Multiple tests were modified to use that method instead of "x86_64" >> in rpm file name. Some timeouts were increased. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8222778 >> >> webrev: http://cr.openjdk.java.net/~dchuyko/8222778/webrev.00/ >> >> testing: test/jdk/tools/jpackage jtreg tests pass on Ubuntu 16.04 >> with rpmbuild on x86_64, aarch64, arm, x86 and power, except >> deb/MaintainerTest (fails everywhere similarly to x86_64 because of >> extra "Unknown" name in email). >> >> I didin't cover s390 as we in BellSoft currently don't build on that >> arch. On typical armv7 hw increased or default timeouts are still too >> low, while they are fine for some relatively weak aarch64 machines. >> Deb tests run especially slow because of dpkg-deb itself. I used >> "force-unsafe-io" option in /etc/dpkg/dpkg.cfg, it does reduce >> packaging time but still not enough to have really fast tests. >> >> -Dmitry >> >> > From OGATAK at jp.ibm.com Wed Jul 17 06:48:44 2019 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Wed, 17 Jul 2019 15:48:44 +0900 Subject: RFR: JDK-8227831: Avoid using volatile for write-once, read-many class field Message-ID: Hi, May I have a review for "JDK-8227831: Avoid using volatile for write-once, read-many class field"? In jdk.internal.reflect.ReflectionFactory, there is a private class field named "langReflectAccess", which is referenced every time when the library handles various reflective operations. This field is initialized on the first access to the ReflectionFactory class. This field is declared as volatile to avoid (or reduce) race condition between initialization and references to the field. On the platforms with weak memory model (i.e, POWER and ARM), reading a volatile variable requires memory fence and incurs overhead. So it is preferable to avoid use of volatile for such a write-once, read-many variable. langReflectAccess can be modified only in setLangReflectAccess() method. So we can avoid using volatile by modifying setLangReflectAccess() to use a synchronized block to avoid race condition. This change reduced elapsed time of a micro benchmark by 9%, which repeatedly invoke Class.getMethods(). Bug: https://bugs.openjdk.java.net/browse/JDK-8227831 Webrev: http://cr.openjdk.java.net/~ogatak/8227831/webrev/ Regards, Ogata From christoph.langer at sap.com Wed Jul 17 07:35:47 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 17 Jul 2019 07:35:47 +0000 Subject: RFR: JDK-8227831: Avoid using volatile for write-once, read-many class field In-Reply-To: References: Message-ID: Hi Ogata, this seems to make sense. So, +1 from my end. Can you please add a space after "if" in line "734 if(langReflectAccess == null) {"? Thanks Christoph > -----Original Message----- > From: core-libs-dev On Behalf > Of Kazunori Ogata > Sent: Mittwoch, 17. Juli 2019 08:49 > To: core-libs-dev at openjdk.java.net > Subject: RFR: JDK-8227831: Avoid using volatile for write-once, read-many > class field > > Hi, > > May I have a review for "JDK-8227831: Avoid using volatile for write-once, > read-many class field"? > > In jdk.internal.reflect.ReflectionFactory, there is a private class field > named "langReflectAccess", which is referenced every time when the library > handles various reflective operations. This field is initialized on the > first access to the ReflectionFactory class. This field is declared as > volatile to avoid (or reduce) race condition between initialization and > references to the field. > > On the platforms with weak memory model (i.e, POWER and ARM), reading a > volatile variable requires memory fence and incurs overhead. So it is > preferable to avoid use of volatile for such a write-once, read-many > variable. > > langReflectAccess can be modified only in setLangReflectAccess() method. > So we can avoid using volatile by modifying setLangReflectAccess() to use > a synchronized block to avoid race condition. This change reduced elapsed > time of a micro benchmark by 9%, which repeatedly invoke > Class.getMethods(). > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8227831 > > Webrev: http://cr.openjdk.java.net/~ogatak/8227831/webrev/ > > > Regards, > Ogata From christoph.langer at sap.com Wed Jul 17 07:39:47 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 17 Jul 2019 07:39:47 +0000 Subject: RFR : 8227737: avoid implicit-function-declaration on AIX In-Reply-To: References: Message-ID: Hi Matthias, looks good, thanks for doing this. How far are we then from enabling "warnings as errors" on AIX? :P Best regards Christoph From: awt-dev On Behalf Of Baesken, Matthias Sent: Dienstag, 16. Juli 2019 17:04 To: Java Core Libs ; nio-dev at openjdk.java.net; net-dev at openjdk.java.net; awt-dev at openjdk.java.net Cc: 'ppc-aix-port-dev at openjdk.java.net' Subject: [CAUTION] RFR : 8227737: avoid implicit-function-declaration on AIX Hello, please review the following AIX related change . It fixes a number of missing inclusions leading to implicit-function-declaration warnings when compiling with the recent xlc16 /xlclang . At various places in the native C coding in jdk, we miss header inclusions on AIX. This leads to warnings like : /nightly/jdk/src/java.base/unix/native/libjava/childproc.c:99:5: warning: implicitly declaring library function 'snprintf' with type 'int (char *, unsigned long, const char *, ...)' [-Wimplicit-function-declaration] snprintf(aix_fd_dir, 32, "/proc/%d/fd", getpid()); ^ /nightly/jdk/src/java.base/unix/native/libjava/childproc.c:99:5: note: include the header or explicitly provide a declaration for 'snprintf' or /nightly/jdk/src/java.base/aix/native/libjli/java_md_aix.c:38:5: warning: implicitly declaring library function 'memset' with type 'void *(void *, int, unsigned long)' [-Wimplicit-function-declaration] memset((void *)info, 0, sizeof(Dl_info)); /nightly/jdk/src/java.base/aix/native/libjli/java_md_aix.c:38:5: note: include the header or explicitly provide a declaration for 'memset' Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8227737 http://cr.openjdk.java.net/~mbaesken/webrevs/8227737.0/ Thanks, Matthias From shade at redhat.com Wed Jul 17 07:49:08 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 17 Jul 2019 09:49:08 +0200 Subject: RFR: JDK-8227831: Avoid using volatile for write-once, read-many class field In-Reply-To: References: Message-ID: On 7/17/19 8:48 AM, Kazunori Ogata wrote: > Webrev: http://cr.openjdk.java.net/~ogatak/8227831/webrev/ Note this is generally not safe: it introduces data race on langReflectAccess field access. It has to be proved that everything that implements LangReflectAccess interface makes this data race benign: e.g. all fields that are accessed via those implementation are final, read once, etc. And briefly looking at that, I am not sure it is the case for the actual accessor generators. I'd cautiously leave "volatile" here. -- Thanks, -Aleksey From matthias.baesken at sap.com Wed Jul 17 07:55:38 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 17 Jul 2019 07:55:38 +0000 Subject: RFR : 8227737: avoid implicit-function-declaration on AIX In-Reply-To: References: Message-ID: Thanks ! * How far are we then from enabling "warnings as errors" on AIX? :P * I count in the opt/product jdk/jdk AIX build currently 60 remaining matches of compiler warnings . Plus additionally a number of those (probably linker warnings ?) : 1500-029: (W) WARNING: subprogram ... could not be inline Guess we have to suppress / ignore at least most of the linker inlining warnings (we ignore them for a decade IMHO). >From the 60 remaining compiler warnings I mentioned are ~ 30 of type Wformat : warning: format specifies type 'int *' but the argument has type 'int' [-Wformat] warning: format specifies type 'unsigned long long' but the argument has type 'size_t' (aka 'unsigned long') [-Wformat] Guess those can the easily fixed (and should be fixed). Regards, Matthias From: Langer, Christoph Sent: Mittwoch, 17. Juli 2019 09:40 To: Baesken, Matthias ; Java Core Libs ; nio-dev at openjdk.java.net; net-dev at openjdk.java.net; awt-dev at openjdk.java.net Cc: 'ppc-aix-port-dev at openjdk.java.net' Subject: RE: RFR : 8227737: avoid implicit-function-declaration on AIX Hi Matthias, looks good, thanks for doing this. How far are we then from enabling "warnings as errors" on AIX? :P Best regards Christoph From: awt-dev > On Behalf Of Baesken, Matthias Sent: Dienstag, 16. Juli 2019 17:04 To: Java Core Libs >; nio-dev at openjdk.java.net; net-dev at openjdk.java.net; awt-dev at openjdk.java.net Cc: 'ppc-aix-port-dev at openjdk.java.net' > Subject: [CAUTION] RFR : 8227737: avoid implicit-function-declaration on AIX Hello, please review the following AIX related change . It fixes a number of missing inclusions leading to implicit-function-declaration warnings when compiling with the recent xlc16 /xlclang . At various places in the native C coding in jdk, we miss header inclusions on AIX. This leads to warnings like : /nightly/jdk/src/java.base/unix/native/libjava/childproc.c:99:5: warning: implicitly declaring library function 'snprintf' with type 'int (char *, unsigned long, const char *, ...)' [-Wimplicit-function-declaration] snprintf(aix_fd_dir, 32, "/proc/%d/fd", getpid()); ^ /nightly/jdk/src/java.base/unix/native/libjava/childproc.c:99:5: note: include the header or explicitly provide a declaration for 'snprintf' or /nightly/jdk/src/java.base/aix/native/libjli/java_md_aix.c:38:5: warning: implicitly declaring library function 'memset' with type 'void *(void *, int, unsigned long)' [-Wimplicit-function-declaration] memset((void *)info, 0, sizeof(Dl_info)); /nightly/jdk/src/java.base/aix/native/libjli/java_md_aix.c:38:5: note: include the header or explicitly provide a declaration for 'memset' Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8227737 http://cr.openjdk.java.net/~mbaesken/webrevs/8227737.0/ Thanks, Matthias From OGATAK at jp.ibm.com Wed Jul 17 08:00:26 2019 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Wed, 17 Jul 2019 17:00:26 +0900 Subject: RFR: JDK-8227831: Avoid using volatile for write-once, read-many class field In-Reply-To: References: Message-ID: Hi Aleskey, Thank you for your comment. I forgot to mention one thing. I verified that all accesses to langReflectioAccess calls the accessor "langReflectAccess()". Since this variable is modified once from null to non-null, I think the write in the setter is guaranteed to be visible in the getter by putting the synchronized block in langReflectAccess(). Should I put comments about this assumption? Actually, in JDK11 there are some lines that do not call the getter, so backport needs to fix them, too. Regards, Ogata Aleksey Shipilev wrote on 2019/07/17 16:49:08: > From: Aleksey Shipilev > To: Kazunori Ogata , core-libs-dev at openjdk.java.net > Date: 2019/07/17 16:49 > Subject: [EXTERNAL] Re: RFR: JDK-8227831: Avoid using volatile for write- > once, read-many class field > > On 7/17/19 8:48 AM, Kazunori Ogata wrote: > > Webrev: http://cr.openjdk.java.net/~ogatak/8227831/webrev/ > > Note this is generally not safe: it introduces data race on > langReflectAccess field access. It has > to be proved that everything that implements LangReflectAccess interface > makes this data race > benign: e.g. all fields that are accessed via those implementation are > final, read once, etc. And > briefly looking at that, I am not sure it is the case for the actual > accessor generators. > > I'd cautiously leave "volatile" here. > > -- > Thanks, > -Aleksey > > [attachment "signature.asc" deleted by Kazunori Ogata/Japan/IBM] From peter.levart at gmail.com Wed Jul 17 08:29:12 2019 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 17 Jul 2019 10:29:12 +0200 Subject: RFR: 8227587: Add internal privileged System.loadLibrary In-Reply-To: <3d3ef452-48d8-caf0-75a7-bcc051b13f82@oracle.com> References: <8cf6ed4d-194a-4428-f381-e7e3c0452cd6@oracle.com> <4943b69c-bc3a-f147-abb8-5b369eec5737@oracle.com> <2cbfd5d8-c4a0-4a2d-ba62-6fed14dc7155@oracle.com> <60d95350-c42c-1498-5c72-174736e863c0@oracle.com> <15a57e3c-065c-55c5-b6af-0644ed8f775b@oracle.com> <3d3ef452-48d8-caf0-75a7-bcc051b13f82@oracle.com> Message-ID: Hi Claes, Am I reading correct that package-private ClassLoader.loadLibrary(Class fromClass, String name, boolean isAbsolute) wouldn't need to consult SecurityManager wasn't it for accessing system properties in private ClassLoader.initializePath(String propName). So perhaps if the two calls to initializePath() in the if block of ClassLoader.loadLibrary() are wrapped with a single doPrivileged(), you wouldn't have to wrap the call to JavaLangAccess.loadLibrary in BootLoader. And since initializePath() would only be called once and then the results cached, you end up with less doPrivileged() wrappings when SecurityManager is present as soon as BootLoader.loadLibrary is called the 2nd time. BTW, there is a data race when accessing usr_paths and sys_paths static fields in multi-threaded scenario. Their type is String[] which means that the contents of the arrays could be observed uninitialized (elements being null) in some thread. Both fields should be made volatile (not only sys_paths) as assignment to them can be performed more than once in idempotent racy initialization. Regards, Peter On 7/16/19 3:48 PM, Claes Redestad wrote: > Hi, > > refactored to use a BootLoader::loadLibrary API that is only visible > within the java.base module: > > http://cr.openjdk.java.net/~redestad/8227587/open.03/ > > I've retained the bridge to ClassLoader::loadLibrary for performance, > but without any magic or privilege escalation involved. Moving sys_path > / systemNativeLibraries out of ClassLoader seems quite complicated, so > I've not attempted that refactoring for this RFE. > > /Claes > > On 2019-07-12 20:03, Mandy Chung wrote: >> Just to recap what we discussed offline: >> >> We could introduce BootLoader::loadLibrary to load a system native >> library for boot loader.? sys_path and systemNativeLibraries in >> ClassLoader implementation are solely for boot loader and it seems >> cleaner for BootLoader to handle loading of system native libraries >> where it can be optimized for boot loader.? This would require >> some refactoring. >> >> One possible solution is to add a shared secret to simply call >> package-private ClassLoader::loadLibrary(Class fromClass, String >> name) >> method and have BootLoader::loadLibrary to check if SM is present >> and wrap the call with doPriv; otherwise, just call the shared >> secret loadLibrary method. >> >> Then we can investigate in the future to refactor the native library >> loading implementation to jdk.internal.loader. >> >> what do you think? >> >> Mandy >> >> On 7/12/19 8:25 AM, Mandy Chung wrote: >>> Claes, >>> >>> Thanks for exploring this.? I would like to see if we can avoid >>> introducing >>> an internal @CS method (keep @CSM only for public APIs will help >>> security >>> analysis). >>> >>> There are other alternatives to improve the footprint performance. >>> >>> One idea is java.base and java.desktop each has its own utility method >>> to load library.? No change is needed for java.net since only one >>> loadLibrary >>> call. >>> >>> Another idea is to add BootLoader.loadLibrary that skips the security >>> permission overhead and only for boot loader use.? It would require >>> refactoring. >>> >>> I think java.base and java.desktop having its own utility method is >>> a simpler solution. >>> >>> Mandy >>> >>> On 7/12/19 7:55 AM, Claes Redestad wrote: >>>> Hi, >>>> >>>> I'm dropping the java.desktop changes, and Mandy has asked me to >>>> explore >>>> options that does not add a new @CallerSensitive entry point, even >>>> to a >>>> strongly encapsulated API like JavaLangAccess >>>> >>>> Easiest of these is to explicitly provide the class context we're >>>> calling from - with proper assertions. This is marginally more >>>> performant due avoiding the Reflection.getCallerClass, but slightly >>>> less >>>> convenient. >>>> >>>> http://cr.openjdk.java.net/~redestad/8227587/open.01/ >>>> >>>> /Claes >>>> >>>> On 2019-07-12 15:27, Roger Riggs wrote: >>>>> Hi Claes, >>>>> >>>>> Looks fine. >>>>> >>>>> Thanks for the updates, Roger >>>>> >>>>> >>>>> On 7/11/19 10:39 AM, Claes Redestad wrote: >>>>>> Hi Roger, >>>>>> >>>>>> On 2019-07-11 16:10, Roger Riggs wrote: >>>>>>> Hi Claes, >>>>>>> >>>>>>> JavaLangAccess.java: >>>>>>> 316: Add @param tag >>>>>> >>>>>> done. >>>>>> >>>>>>> >>>>>>> System.java:? 2282, 2287 >>>>>>> Runtime.loadLibrary0 makes a second check for a security manager. >>>>>>> Is there any potential gain by calling ClassLoader.loadLibrary >>>>>>> directly? >>>>>>> None of the internal uses would have a separatorChar. >>>>>> >>>>>> Most of the gain comes from not having to load one-off PA classes or >>>>>> lambdas, but of course avoiding the indexOf and a few >>>>>> indirections are >>>>>> marginally helpful to startup. We should at least assert that the >>>>>> library names are sane, though. >>>>>> >>>>>>> >>>>>>> I expect most of the files need a copyright update. >>>>>>> The script in /make/scripts/update_copyright_year.sh >>>>>>> should do the work for modified files. >>>>>> >>>>>> Fixed copyrights and updated in place: >>>>>> http://cr.openjdk.java.net/~redestad/8227587/open.00 >>>>>> >>>>>> Thanks! >>>>>> >>>>>> /Claes >>>>> >>> >> From aph at redhat.com Wed Jul 17 08:52:20 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 17 Jul 2019 09:52:20 +0100 Subject: RFR (S): JDK-8222778: Packaging Tool (JEP 343) on Linux/AArch64 In-Reply-To: References: Message-ID: On 7/16/19 8:55 PM, Dmitry Chuyko wrote: > Hello, > > Please review a small patch that mostly fixes jpackage test for Linux > aarch64 and also arm,x86,power. It is prepared for 'JDK-8200758-branch' > branch of open 'sandbox' repo. > > There are few parts: > > 1. LinuxPlatform.cpp and IniFile.cpp got small fixes for compiler warnings. This is weird: --- old/src/jdk.jpackage/linux/native/libapplauncher/LinuxPlatform.cpp 2019-07-16 22:11:30.200258978 +0300 +++ new/src/jdk.jpackage/linux/native/libapplauncher/LinuxPlatform.cpp 2019-07-16 22:11:29.867374851 +0300 @@ -127,7 +127,7 @@ } void LinuxPlatform::SetCurrentDirectory(TString Value) { - chdir(PlatformString(Value).toPlatformString()); + int ignored = chdir(PlatformString(Value).toPlatformString()); } Firstly it does not fix the problem: you've gone from an unused value to an unused variable. Secondly, we ignore the return value of printf all the time; what's different about this one? This: @@ -212,9 +212,11 @@ } else if (count == 0) { // break; } else { +/* if (buffer[count - 1] == EOF) { buffer[count - 1] = '\0'; } +*/ I'm wondering if this bogus code might have been inherited from Windows. > 2. LinuxDebBundler.getArch() now maps only x86_64 to amd64, x86 is still > mapped to i386, and other archs map to themselves. > > 3. In tests, new method getRpmArch() was added to linux/base/Base.java, > it maps JVMs os.arch to default rpmbuild arch. Multiple tests were > modified to use that method instead of "x86_64" in rpm file name. Some > timeouts were increased. + if ("arm".equals(arch)) + return "armv7hl"; Is this actually correct? How do you know it's not, say, armv7hf? I would have thought there must be some better way to get the RPM arch. Isn't running /bin/arch right on your systems? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From claes.redestad at oracle.com Wed Jul 17 10:25:15 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 17 Jul 2019 12:25:15 +0200 Subject: RFR: 8227587: Add internal privileged System.loadLibrary In-Reply-To: References: <8cf6ed4d-194a-4428-f381-e7e3c0452cd6@oracle.com> <4943b69c-bc3a-f147-abb8-5b369eec5737@oracle.com> <2cbfd5d8-c4a0-4a2d-ba62-6fed14dc7155@oracle.com> <60d95350-c42c-1498-5c72-174736e863c0@oracle.com> <15a57e3c-065c-55c5-b6af-0644ed8f775b@oracle.com> <3d3ef452-48d8-caf0-75a7-bcc051b13f82@oracle.com> Message-ID: <37ec9df1-4ff3-b888-ecee-dfbd109466d5@oracle.com> Hi Peter, On 2019-07-17 10:29, Peter Levart wrote: > Hi Claes, > > Am I reading correct that package-private > ClassLoader.loadLibrary(Class fromClass, String name, boolean > isAbsolute) wouldn't need to consult SecurityManager wasn't it for > accessing system properties in private ClassLoader.initializePath(String > propName). So perhaps if the two calls to initializePath() in the if > block of ClassLoader.loadLibrary() are wrapped with a single > doPrivileged(), you wouldn't have to wrap the call to > JavaLangAccess.loadLibrary in BootLoader. And since initializePath() > would only be called once and then the results cached, you end up with > less doPrivileged() wrappings when SecurityManager is present as soon as > BootLoader.loadLibrary is called the 2nd time. hmm, fromClass.getClassLoader() also does a security check, though. That said, there's a case for wrapping the initializePath calls in a doPriv of their own, since we now have an implicit requirement that some system library is loaded first (so that sys_paths is initialized) before any user code attempts to load a library of their own... > > BTW, there is a data race when accessing usr_paths and sys_paths static > fields in multi-threaded scenario. Their type is String[] which means > that the contents of the arrays could be observed uninitialized > (elements being null) in some thread. Both fields should be made > volatile (not only sys_paths) as assignment to them can be performed > more than once in idempotent racy initialization. .. and we typically seem to be loading at least one library before initializing any user code, which is probably why this has never been an issue. It seems like a good idea to remove this subtle fragility, though. I wonder if we shouldn't "simply" initialize the two paths during bootstrap and put them in final fields. These are pre-existing issues though, so I think I'll take my reviews and push this enhancement for now. :-) Thanks! /Claes > > Regards, Peter > > On 7/16/19 3:48 PM, Claes Redestad wrote: >> Hi, >> >> refactored to use a BootLoader::loadLibrary API that is only visible >> within the java.base module: >> >> http://cr.openjdk.java.net/~redestad/8227587/open.03/ >> >> I've retained the bridge to ClassLoader::loadLibrary for performance, >> but without any magic or privilege escalation involved. Moving sys_path >> / systemNativeLibraries out of ClassLoader seems quite complicated, so >> I've not attempted that refactoring for this RFE. >> >> /Claes >> >> On 2019-07-12 20:03, Mandy Chung wrote: >>> Just to recap what we discussed offline: >>> >>> We could introduce BootLoader::loadLibrary to load a system native >>> library for boot loader.? sys_path and systemNativeLibraries in >>> ClassLoader implementation are solely for boot loader and it seems >>> cleaner for BootLoader to handle loading of system native libraries >>> where it can be optimized for boot loader.? This would require >>> some refactoring. >>> >>> One possible solution is to add a shared secret to simply call >>> package-private ClassLoader::loadLibrary(Class fromClass, String >>> name) >>> method and have BootLoader::loadLibrary to check if SM is present >>> and wrap the call with doPriv; otherwise, just call the shared >>> secret loadLibrary method. >>> >>> Then we can investigate in the future to refactor the native library >>> loading implementation to jdk.internal.loader. >>> >>> what do you think? >>> >>> Mandy >>> >>> On 7/12/19 8:25 AM, Mandy Chung wrote: >>>> Claes, >>>> >>>> Thanks for exploring this.? I would like to see if we can avoid >>>> introducing >>>> an internal @CS method (keep @CSM only for public APIs will help >>>> security >>>> analysis). >>>> >>>> There are other alternatives to improve the footprint performance. >>>> >>>> One idea is java.base and java.desktop each has its own utility method >>>> to load library.? No change is needed for java.net since only one >>>> loadLibrary >>>> call. >>>> >>>> Another idea is to add BootLoader.loadLibrary that skips the security >>>> permission overhead and only for boot loader use.? It would require >>>> refactoring. >>>> >>>> I think java.base and java.desktop having its own utility method is >>>> a simpler solution. >>>> >>>> Mandy >>>> >>>> On 7/12/19 7:55 AM, Claes Redestad wrote: >>>>> Hi, >>>>> >>>>> I'm dropping the java.desktop changes, and Mandy has asked me to >>>>> explore >>>>> options that does not add a new @CallerSensitive entry point, even >>>>> to a >>>>> strongly encapsulated API like JavaLangAccess >>>>> >>>>> Easiest of these is to explicitly provide the class context we're >>>>> calling from - with proper assertions. This is marginally more >>>>> performant due avoiding the Reflection.getCallerClass, but slightly >>>>> less >>>>> convenient. >>>>> >>>>> http://cr.openjdk.java.net/~redestad/8227587/open.01/ >>>>> >>>>> /Claes >>>>> >>>>> On 2019-07-12 15:27, Roger Riggs wrote: >>>>>> Hi Claes, >>>>>> >>>>>> Looks fine. >>>>>> >>>>>> Thanks for the updates, Roger >>>>>> >>>>>> >>>>>> On 7/11/19 10:39 AM, Claes Redestad wrote: >>>>>>> Hi Roger, >>>>>>> >>>>>>> On 2019-07-11 16:10, Roger Riggs wrote: >>>>>>>> Hi Claes, >>>>>>>> >>>>>>>> JavaLangAccess.java: >>>>>>>> 316: Add @param tag >>>>>>> >>>>>>> done. >>>>>>> >>>>>>>> >>>>>>>> System.java:? 2282, 2287 >>>>>>>> Runtime.loadLibrary0 makes a second check for a security manager. >>>>>>>> Is there any potential gain by calling ClassLoader.loadLibrary >>>>>>>> directly? >>>>>>>> None of the internal uses would have a separatorChar. >>>>>>> >>>>>>> Most of the gain comes from not having to load one-off PA classes or >>>>>>> lambdas, but of course avoiding the indexOf and a few >>>>>>> indirections are >>>>>>> marginally helpful to startup. We should at least assert that the >>>>>>> library names are sane, though. >>>>>>> >>>>>>>> >>>>>>>> I expect most of the files need a copyright update. >>>>>>>> The script in /make/scripts/update_copyright_year.sh >>>>>>>> should do the work for modified files. >>>>>>> >>>>>>> Fixed copyrights and updated in place: >>>>>>> http://cr.openjdk.java.net/~redestad/8227587/open.00 >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> /Claes >>>>>> >>>> >>> > From sgehwolf at redhat.com Wed Jul 17 12:44:10 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 17 Jul 2019 14:44:10 +0200 Subject: RFR: 8227642: [TESTBUG] Make docker tests podman compatible In-Reply-To: <47390A32-BD5B-4FF3-B93B-69ACECBC3E78@oracle.com> References: <32c8a1934bf07e4c9c6a961e60dcb7abd9931fe1.camel@redhat.com> <5bc3ac00-6ac9-99aa-052d-0a4aa6b04f8f@oracle.com> <47390A32-BD5B-4FF3-B93B-69ACECBC3E78@oracle.com> Message-ID: <243091d0e29604851d100b94d5ad777d9cf59127.camel@redhat.com> Hi Igor, Misha, On Tue, 2019-07-16 at 11:49 -0700, Igor Ignatyev wrote: > Hi Severin, > > I don't think that tests (or test libraries for that matter) should > be responsible for setting correct PATH value, it should be a part of > host configuration procedure (tests can/should check that all > required bins are available though). in other words, I'd prefer if > you remove 'env.put("PATH", ...)' lines from both DockerTestUtils and > TestJFREvents. the rest looks good to me. Updated webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227642/02/webrev/ No more additions to PATH are being done. I've discovered that VMProps.java which defines "docker.required", used the "docker" binary even for podman test runs. This ended up not running most of the tests even with -Djdk.test.docker.command=podman specified. I've fixed that by moving DOCKER_COMMAND to Platform.java so that it can be used in both places. Testing: Container tests with docker daemon running on Linux x86_64, container tests without docker daemon running (podman is daemon-less) via the podman binary on Linux x86_64 (with -e:PATH). All pass. More thoughts? Thanks, Severin > Thanks, > -- Igor > > > On Jul 16, 2019, at 5:36 AM, Severin Gehwolf wrote: > > > > Hi, > > > > I believe I still need a *R*eviewer for this. Any takers? > > > > Thanks, > > Severin > > > > On Fri, 2019-07-12 at 15:19 -0700, mikhailo.seledtsov at oracle.com wrote: > > > Hi Severin, > > > > > > The change looks good to me. Thank you for adding support for Podman > > > container technology. > > > > > > Testing: I ran both HotSpot and JDK container tests with your patch; > > > tests executed on Oracle Linux 7.6 using default container engine (Docker): > > > > > > test/hotspot/jtreg/containers/ AND > > > test/jdk/jdk/internal/platform/docker/ > > > > > > All PASS > > > > > > > > > Thanks, > > > > > > Misha > > > > > > > > > On 7/12/19 11:08 AM, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > There is an alternative container engine which is being used by Fedora > > > > and RHEL 8, called podman[1]. It's mostly compatible with docker. It > > > > looks like OpenJDK docker tests can be made podman compatible with a > > > > few little tweaks. One "interesting" one is to not assert "Successfully > > > > built" in the build output but only rely on the exit code, which seems > > > > to be OK for my testing. Interestingly the test would be skipped in > > > > that case. > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8227642 > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227642/01/webrev/ > > > > > > > > Adjustments I've done: > > > > * Don't assert "Successfully built" in image build output[2]. > > > > * Add /usr/sbin to PATH as the podman binary relies on iptables for it > > > > to work which is in /usr/sbin on Fedora > > > > * Allow for Metrics.getCpuSystemUsage() and Metrics.getCpuUserUsage() > > > > to be equal to the previous value. I've found those counters to be > > > > slowly increasing, which made the tests unreliable. > > > > > > > > Testing: > > > > > > > > Running docker tests with docker as engine. Did the same with podman as > > > > engine via -Djdk.test.docker.command=podman on Linux x86_64. Both > > > > passed (non-trivially). > > > > > > > > Thoughts? > > > > > > > > Thanks, > > > > Severin > > > > > > > > [1] https://podman.io/ > > > > [2] Image builds with podman look > > > > like ("COMMIT" over "Successfully built"): > > > > STEP 1: FROM fedora:29 > > > > STEP 2: RUN dnf install -y java-11-openjdk-devel && dnf clean all > > > > --> Using cache 96f8b1a0dfe7dba581a64fc67a27002ddf52e032af55f9ddc765182a690afd9d > > > > STEP 3: COPY TestMetrics.class TestMetrics.java /opt/ > > > > 269042160f7a4e6a06789cd19640ea658a8f941bc53de0fd40a574dc3bdb49a8 > > > > STEP 4: CMD /usr/lib/jvm/java-11-openjdk/bin/java -cp /opt --add-modules java.base --add-exports java.base/jdk.internal.platform=ALL-UNNAMED TestMetrics > > > > STEP 5: COMMIT fedora-metrics-11 > > > > d749088d6ce4510f212820ad4eca55a9b05e5c5c245f2372b6cfe91926e8cd7e > > > > From claes.redestad at oracle.com Wed Jul 17 15:04:45 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 17 Jul 2019 17:04:45 +0200 Subject: RFR: JDK-8227831: Avoid using volatile for write-once, read-many class field In-Reply-To: References: Message-ID: <38d9abc4-71c6-c26d-f820-7845c5d375bd@oracle.com> Hi, removing volatile aligns LangReflectAccess initialization with the pattern used for other access objects: it's only initialized in the static initializer of some class which we ensure is initialized, which means any initialization race is guarded by the initialization of said class - in this case j.l.r.Modifier. Initialization of other access objects are not guarded by any explicit synchronization, however, since similar load/store barriers will be in effect by ensuring the class that constructs the object has been initialized. So I think you could remove the explicit synchronization. I'm not sure why LangReflectAccess has not moved in with other SharedSecrets. Perhaps this is just an artefact of having been around for a long time, but maybe that'd cause some cyclic bootstrap dependency. Either way it's nice to see it align to use the same pattern. Thanks! /Claes On 2019-07-17 10:00, Kazunori Ogata wrote: > Hi Aleskey, > > Thank you for your comment. > > I forgot to mention one thing. I verified that all accesses to > langReflectioAccess calls the accessor "langReflectAccess()". Since this > variable is modified once from null to non-null, I think the write in the > setter is guaranteed to be visible in the getter by putting the > synchronized block in langReflectAccess(). > > Should I put comments about this assumption? Actually, in JDK11 there are > some lines that do not call the getter, so backport needs to fix them, > too. > > > Regards, > Ogata > > > Aleksey Shipilev wrote on 2019/07/17 16:49:08: > >> From: Aleksey Shipilev >> To: Kazunori Ogata , core-libs-dev at openjdk.java.net >> Date: 2019/07/17 16:49 >> Subject: [EXTERNAL] Re: RFR: JDK-8227831: Avoid using volatile for > write- >> once, read-many class field >> >> On 7/17/19 8:48 AM, Kazunori Ogata wrote: >>> Webrev: http://cr.openjdk.java.net/~ogatak/8227831/webrev/ >> >> Note this is generally not safe: it introduces data race on >> langReflectAccess field access. It has >> to be proved that everything that implements LangReflectAccess interface > >> makes this data race >> benign: e.g. all fields that are accessed via those implementation are >> final, read once, etc. And >> briefly looking at that, I am not sure it is the case for the actual >> accessor generators. >> >> I'd cautiously leave "volatile" here. >> >> -- >> Thanks, >> -Aleksey >> >> [attachment "signature.asc" deleted by Kazunori Ogata/Japan/IBM] > From bourges.laurent at gmail.com Wed Jul 17 15:12:30 2019 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 17 Jul 2019 17:12:30 +0200 Subject: The final optimized version of Dual-Pivot Quicksort (ver.19.1) In-Reply-To: References: <1560893862.105095134@f487.i.mail.ru> <5ab79374-a561-de15-6a35-0dde138fdcb9@oracle.com> Message-ID: Hi, I integrated locally the complete DPQS 19.2 patch from Vladimir Yaroslavskiy with up-to-date jdk14 (client) repository: build OK and jtreg passed OK (java/util/Arrays). Here is the corresponding webrev for review: http://cr.openjdk.java.net/~lbourges/dpqs/dpqs-8226297/webrev/ Cheers, Laurent Le ven. 12 juil. 2019 ? 09:34, Laurent Bourg?s a ?crit : > Hi, > I asked alan to update the webrev, but I can publish it myself... > > Will do it asap, > Stay tuned, > Laurent > > Le mar. 9 juil. 2019 ? 22:19, Brent Christian > a ?crit : > >> Hi, >> >> Is the webrev incomplete? It only contains the changes for >> DualPivotQuicksort.java, and not for Arrays.java, etc. >> >> Thanks, >> -Brent >> >> On 6/18/19 2:37 PM, Vladimir Yaroslavskiy wrote: >> > Hi team, >> > >> > Please review the final optimized version of Dual-Pivot Quicksort >> (ver.19.1), >> > see http://cr.openjdk.java.net/~alanb/8226297/0/webrev >> > (link to Jira task https://bugs.openjdk.java.net/browse/JDK-8226297) >> > >> > The new version was published here more than one year ago (on Jan 19, >> 2018). >> > Since that time Dual-Pivot Quicksort has been significantly improved >> > and this work was done in collaboration with Doug Lea and Laurent >> Bourges. >> > >> > You can find summary of all changes below. >> > >> > DualPivotQuicksort.java >> > ---------------------------------------------------------------------- >> > * The 1-st and 5-th candidates are taken as pivots >> > instead of 2-nd and 4-th >> > * Pivots are chosen with another step >> > * Pivot candidates are sorted by combination of >> > 5-element network sorting and insertion sort >> > * New backwards partitioning was introduced >> > * Partitioning is related to the golden ratio >> > * Quicksort tuning parameters were updated >> > * Thresholds for byte / char / short sorting were updated >> > * Additional steps for float / double were fully rewritten >> > * Parallel sorting is based on combination of merge sort >> > and Dual-Pivot Quicksort >> > * Pair insertion sort was optimized and became a part >> > of mixed insertion sort >> > * Mixed insertion sort was introduced: combination >> > of simple insertion sort, pin insertion sort and >> > pair insertion sort >> > * Simple insertion sort is invoked on tiny array >> > * Pin insertion sort is started on small array >> > * Pair insertion sort is continued on remain part >> > * Merging of runs is invoked on each iteration of Quicksort >> > * Merging of runs was fully rewritten >> > * Optimal partitioning of merging is used >> > * Not more than one copy of part to buffer during merging >> > * Merging parameters were updated >> > * Initial capacity of runs is based on size >> > * Max number of runs is constant >> > * Optimized version of heap sort was introduced >> > * Heap sort is used as a guard against quadratic time >> > (int / long / float / double) >> > * Parallel merging of runs was also provided >> > * Parallel sorting, heap sort and merging of runs >> > are not used in byte / char / short sorting >> > * Counting sort for byte / char / short were optimized >> > * Counting sort is used as a guard against quadratic time >> > (byte / char / short) >> > * Code style and javadoc improvements >> > >> > Sorting.java >> > ---------------------------------------------------------------------- >> > * New test cases were added >> > * Test cases are invoked for both: sequential and >> > parallel sorting >> > * Check for Object sorting was added >> > * New tests were added against heap sort >> > * Added test case against bug in parallel merge >> > sort on float / double data >> > >> > ParallelSorting.java >> > ---------------------------------------------------------------------- >> > * This class was removed, because Sorting class >> > covers all cases >> > >> > SortingHelper.java >> > ---------------------------------------------------------------------- >> > * The helper class provides access package-private >> > methods of DualPivotQuicksort class during testing >> > >> > Arrays.java >> > ---------------------------------------------------------------------- >> > * Calls of Dual-Pivot Quicksort were updated >> > * Parallel sorting of primitives was switched to parallel >> > Dual-Pivot Quicksort >> > * Javadoc was updated, double spaces were removed >> > * Format changes >> > >> > ArraysParallelSortHelpers.java >> > ---------------------------------------------------------------------- >> > * Implementation of parallel sorting >> > for primitives was removed >> > * Javadoc was updated >> > >> > Thank you, >> > Vladimir >> > >> > -- -- Laurent Bourg?s From brian.burkhalter at oracle.com Wed Jul 17 16:12:56 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 17 Jul 2019 09:12:56 -0700 Subject: 8067801: Enforce null check for underlying I/O streams Message-ID: https://bugs.openjdk.java.net/browse/JDK-8067801 http://cr.openjdk.java.net/~bpb/8067801/webrev.00/ Add null check to Filter{In,Out}putStream constructors. This covers all the cases listed in the issue as those are all subclasses of these two classes. No javadoc update is need due to this statement in the java.io package doc: "Unless otherwise noted, passing a null argument to a constructor or method in any class or interface in this package will cause a NullPointerException to be thrown." Thanks, Brian From mikhailo.seledtsov at oracle.com Wed Jul 17 17:22:10 2019 From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com) Date: Wed, 17 Jul 2019 10:22:10 -0700 Subject: RFR: 8227642: [TESTBUG] Make docker tests podman compatible In-Reply-To: <243091d0e29604851d100b94d5ad777d9cf59127.camel@redhat.com> References: <32c8a1934bf07e4c9c6a961e60dcb7abd9931fe1.camel@redhat.com> <5bc3ac00-6ac9-99aa-052d-0a4aa6b04f8f@oracle.com> <47390A32-BD5B-4FF3-B93B-69ACECBC3E78@oracle.com> <243091d0e29604851d100b94d5ad777d9cf59127.camel@redhat.com> Message-ID: Hi Severin, On 7/17/19 5:44 AM, Severin Gehwolf wrote: > Hi Igor, Misha, > > On Tue, 2019-07-16 at 11:49 -0700, Igor Ignatyev wrote: >> Hi Severin, >> >> I don't think that tests (or test libraries for that matter) should >> be responsible for setting correct PATH value, it should be a part of >> host configuration procedure (tests can/should check that all >> required bins are available though). in other words, I'd prefer if >> you remove 'env.put("PATH", ...)' lines from both DockerTestUtils and >> TestJFREvents. the rest looks good to me. > Updated webrev: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227642/02/webrev/ > > No more additions to PATH are being done. > > I've discovered that VMProps.java which defines "docker.required", used > the "docker" binary even for podman test runs. This ended up not > running most of the tests even with -Djdk.test.docker.command=podman > specified. Good catch. > I've fixed that by moving DOCKER_COMMAND to Platform.java so > that it can be used in both places. Sounds good to me. (of course, the alternative would be to import jdk.test.lib.containers.docker.DockerTestUtils into VMProps.java -- not sure if there are any potential problems doing it this way) > Testing: Container tests with docker daemon running on Linux x86_64, > container tests without docker daemon running (podman is daemon-less) > via the podman binary on Linux x86_64 (with -e:PATH). All pass. Sounds good. Overall looks good to me. One minor nit: DockerTestUtils.java does not need "import java.util.Map;" (no need to post updated webrev for this change) Thank you, Misha > > More thoughts? > > Thanks, > Severin > >> Thanks, >> -- Igor >> >>> On Jul 16, 2019, at 5:36 AM, Severin Gehwolf wrote: >>> >>> Hi, >>> >>> I believe I still need a *R*eviewer for this. Any takers? >>> >>> Thanks, >>> Severin >>> >>> On Fri, 2019-07-12 at 15:19 -0700, mikhailo.seledtsov at oracle.com wrote: >>>> Hi Severin, >>>> >>>> The change looks good to me. Thank you for adding support for Podman >>>> container technology. >>>> >>>> Testing: I ran both HotSpot and JDK container tests with your patch; >>>> tests executed on Oracle Linux 7.6 using default container engine (Docker): >>>> >>>> test/hotspot/jtreg/containers/ AND >>>> test/jdk/jdk/internal/platform/docker/ >>>> >>>> All PASS >>>> >>>> >>>> Thanks, >>>> >>>> Misha >>>> >>>> >>>> On 7/12/19 11:08 AM, Severin Gehwolf wrote: >>>>> Hi, >>>>> >>>>> There is an alternative container engine which is being used by Fedora >>>>> and RHEL 8, called podman[1]. It's mostly compatible with docker. It >>>>> looks like OpenJDK docker tests can be made podman compatible with a >>>>> few little tweaks. One "interesting" one is to not assert "Successfully >>>>> built" in the build output but only rely on the exit code, which seems >>>>> to be OK for my testing. Interestingly the test would be skipped in >>>>> that case. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8227642 >>>>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227642/01/webrev/ >>>>> >>>>> Adjustments I've done: >>>>> * Don't assert "Successfully built" in image build output[2]. >>>>> * Add /usr/sbin to PATH as the podman binary relies on iptables for it >>>>> to work which is in /usr/sbin on Fedora >>>>> * Allow for Metrics.getCpuSystemUsage() and Metrics.getCpuUserUsage() >>>>> to be equal to the previous value. I've found those counters to be >>>>> slowly increasing, which made the tests unreliable. >>>>> >>>>> Testing: >>>>> >>>>> Running docker tests with docker as engine. Did the same with podman as >>>>> engine via -Djdk.test.docker.command=podman on Linux x86_64. Both >>>>> passed (non-trivially). >>>>> >>>>> Thoughts? >>>>> >>>>> Thanks, >>>>> Severin >>>>> >>>>> [1] https://podman.io/ >>>>> [2] Image builds with podman look >>>>> like ("COMMIT" over "Successfully built"): >>>>> STEP 1: FROM fedora:29 >>>>> STEP 2: RUN dnf install -y java-11-openjdk-devel && dnf clean all >>>>> --> Using cache 96f8b1a0dfe7dba581a64fc67a27002ddf52e032af55f9ddc765182a690afd9d >>>>> STEP 3: COPY TestMetrics.class TestMetrics.java /opt/ >>>>> 269042160f7a4e6a06789cd19640ea658a8f941bc53de0fd40a574dc3bdb49a8 >>>>> STEP 4: CMD /usr/lib/jvm/java-11-openjdk/bin/java -cp /opt --add-modules java.base --add-exports java.base/jdk.internal.platform=ALL-UNNAMED TestMetrics >>>>> STEP 5: COMMIT fedora-metrics-11 >>>>> d749088d6ce4510f212820ad4eca55a9b05e5c5c245f2372b6cfe91926e8cd7e >>>>> From sgehwolf at redhat.com Wed Jul 17 17:34:18 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 17 Jul 2019 19:34:18 +0200 Subject: RFR: 8227642: [TESTBUG] Make docker tests podman compatible In-Reply-To: References: <32c8a1934bf07e4c9c6a961e60dcb7abd9931fe1.camel@redhat.com> <5bc3ac00-6ac9-99aa-052d-0a4aa6b04f8f@oracle.com> <47390A32-BD5B-4FF3-B93B-69ACECBC3E78@oracle.com> <243091d0e29604851d100b94d5ad777d9cf59127.camel@redhat.com> Message-ID: <60f8f5a9003dd199f2384360c16032d21c881dbb.camel@redhat.com> Hi Misha, On Wed, 2019-07-17 at 10:22 -0700, mikhailo.seledtsov at oracle.com wrote: > Hi Severin, > > On 7/17/19 5:44 AM, Severin Gehwolf wrote: > > Hi Igor, Misha, > > > > On Tue, 2019-07-16 at 11:49 -0700, Igor Ignatyev wrote: > > > Hi Severin, > > > > > > I don't think that tests (or test libraries for that matter) should > > > be responsible for setting correct PATH value, it should be a part of > > > host configuration procedure (tests can/should check that all > > > required bins are available though). in other words, I'd prefer if > > > you remove 'env.put("PATH", ...)' lines from both DockerTestUtils and > > > TestJFREvents. the rest looks good to me. > > Updated webrev: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227642/02/webrev/ > > > > No more additions to PATH are being done. > > > > I've discovered that VMProps.java which defines "docker.required", used > > the "docker" binary even for podman test runs. This ended up not > > running most of the tests even with -Djdk.test.docker.command=podman > > specified. > Good catch. > > I've fixed that by moving DOCKER_COMMAND to Platform.java so > > that it can be used in both places. > > Sounds good to me. > > (of course, the alternative would be to import > jdk.test.lib.containers.docker.DockerTestUtils into VMProps.java -- not > sure if there are any potential problems doing it this way) I've tried that but for some reason this was a problem and VMProps failed to compile. I don't know exactly how those jtreg extensions work and went with the Platform approach. Hope that's OK. > > Testing: Container tests with docker daemon running on Linux x86_64, > > container tests without docker daemon running (podman is daemon-less) > > via the podman binary on Linux x86_64 (with -e:PATH). All pass. > > Sounds good. > > > Overall looks good to me. Thanks for the review! > One minor nit: DockerTestUtils.java does not need "import > java.util.Map;" (no need to post updated webrev for this change) OK, good catch. Fixed locally. Thanks, Severin > > Thank you, > > Misha > > > More thoughts? > > > > Thanks, > > Severin > > > > > Thanks, > > > -- Igor > > > > > > > On Jul 16, 2019, at 5:36 AM, Severin Gehwolf wrote: > > > > > > > > Hi, > > > > > > > > I believe I still need a *R*eviewer for this. Any takers? > > > > > > > > Thanks, > > > > Severin > > > > > > > > On Fri, 2019-07-12 at 15:19 -0700, mikhailo.seledtsov at oracle.com wrote: > > > > > Hi Severin, > > > > > > > > > > The change looks good to me. Thank you for adding support for Podman > > > > > container technology. > > > > > > > > > > Testing: I ran both HotSpot and JDK container tests with your patch; > > > > > tests executed on Oracle Linux 7.6 using default container engine (Docker): > > > > > > > > > > test/hotspot/jtreg/containers/ AND > > > > > test/jdk/jdk/internal/platform/docker/ > > > > > > > > > > All PASS > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Misha > > > > > > > > > > > > > > > On 7/12/19 11:08 AM, Severin Gehwolf wrote: > > > > > > Hi, > > > > > > > > > > > > There is an alternative container engine which is being used by Fedora > > > > > > and RHEL 8, called podman[1]. It's mostly compatible with docker. It > > > > > > looks like OpenJDK docker tests can be made podman compatible with a > > > > > > few little tweaks. One "interesting" one is to not assert "Successfully > > > > > > built" in the build output but only rely on the exit code, which seems > > > > > > to be OK for my testing. Interestingly the test would be skipped in > > > > > > that case. > > > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8227642 > > > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227642/01/webrev/ > > > > > > > > > > > > Adjustments I've done: > > > > > > * Don't assert "Successfully built" in image build output[2]. > > > > > > * Add /usr/sbin to PATH as the podman binary relies on iptables for it > > > > > > to work which is in /usr/sbin on Fedora > > > > > > * Allow for Metrics.getCpuSystemUsage() and Metrics.getCpuUserUsage() > > > > > > to be equal to the previous value. I've found those counters to be > > > > > > slowly increasing, which made the tests unreliable. > > > > > > > > > > > > Testing: > > > > > > > > > > > > Running docker tests with docker as engine. Did the same with podman as > > > > > > engine via -Djdk.test.docker.command=podman on Linux x86_64. Both > > > > > > passed (non-trivially). > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > Thanks, > > > > > > Severin > > > > > > > > > > > > [1] https://podman.io/ > > > > > > [2] Image builds with podman look > > > > > > like ("COMMIT" over "Successfully built"): > > > > > > STEP 1: FROM fedora:29 > > > > > > STEP 2: RUN dnf install -y java-11-openjdk-devel && dnf clean all > > > > > > --> Using cache 96f8b1a0dfe7dba581a64fc67a27002ddf52e032af55f9ddc765182a690afd9d > > > > > > STEP 3: COPY TestMetrics.class TestMetrics.java /opt/ > > > > > > 269042160f7a4e6a06789cd19640ea658a8f941bc53de0fd40a574dc3bdb49a8 > > > > > > STEP 4: CMD /usr/lib/jvm/java-11-openjdk/bin/java -cp /opt --add-modules java.base --add-exports java.base/jdk.internal.platform=ALL-UNNAMED TestMetrics > > > > > > STEP 5: COMMIT fedora-metrics-11 > > > > > > d749088d6ce4510f212820ad4eca55a9b05e5c5c245f2372b6cfe91926e8cd7e > > > > > > From mikhailo.seledtsov at oracle.com Wed Jul 17 18:15:12 2019 From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com) Date: Wed, 17 Jul 2019 11:15:12 -0700 Subject: RFR: 8227642: [TESTBUG] Make docker tests podman compatible In-Reply-To: <60f8f5a9003dd199f2384360c16032d21c881dbb.camel@redhat.com> References: <32c8a1934bf07e4c9c6a961e60dcb7abd9931fe1.camel@redhat.com> <5bc3ac00-6ac9-99aa-052d-0a4aa6b04f8f@oracle.com> <47390A32-BD5B-4FF3-B93B-69ACECBC3E78@oracle.com> <243091d0e29604851d100b94d5ad777d9cf59127.camel@redhat.com> <60f8f5a9003dd199f2384360c16032d21c881dbb.camel@redhat.com> Message-ID: <8f0b52df-51fc-a5d1-7d3a-ee795d6b6c18@oracle.com> On 7/17/19 10:34 AM, Severin Gehwolf wrote: > Hi Misha, > > On Wed, 2019-07-17 at 10:22 -0700, mikhailo.seledtsov at oracle.com wrote: >> Hi Severin, >> >> On 7/17/19 5:44 AM, Severin Gehwolf wrote: >>> Hi Igor, Misha, >>> >>> On Tue, 2019-07-16 at 11:49 -0700, Igor Ignatyev wrote: >>>> Hi Severin, >>>> >>>> I don't think that tests (or test libraries for that matter) should >>>> be responsible for setting correct PATH value, it should be a part of >>>> host configuration procedure (tests can/should check that all >>>> required bins are available though). in other words, I'd prefer if >>>> you remove 'env.put("PATH", ...)' lines from both DockerTestUtils and >>>> TestJFREvents. the rest looks good to me. >>> Updated webrev: >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227642/02/webrev/ >>> >>> No more additions to PATH are being done. >>> >>> I've discovered that VMProps.java which defines "docker.required", used >>> the "docker" binary even for podman test runs. This ended up not >>> running most of the tests even with -Djdk.test.docker.command=podman >>> specified. >> Good catch. >>> I've fixed that by moving DOCKER_COMMAND to Platform.java so >>> that it can be used in both places. >> Sounds good to me. >> >> (of course, the alternative would be to import >> jdk.test.lib.containers.docker.DockerTestUtils into VMProps.java -- not >> sure if there are any potential problems doing it this way) > I've tried that but for some reason this was a problem and VMProps > failed to compile. I don't know exactly how those jtreg extensions work > and went with the Platform approach. Hope that's OK. Thank you for the details. That's OK by me. Thank you, Misha > >>> Testing: Container tests with docker daemon running on Linux x86_64, >>> container tests without docker daemon running (podman is daemon-less) >>> via the podman binary on Linux x86_64 (with -e:PATH). All pass. >> Sounds good. >> >> >> Overall looks good to me. > Thanks for the review! > >> One minor nit: DockerTestUtils.java does not need "import >> java.util.Map;" (no need to post updated webrev for this change) > OK, good catch. Fixed locally. > > Thanks, > Severin > >> Thank you, >> >> Misha >> >>> More thoughts? >>> >>> Thanks, >>> Severin >>> >>>> Thanks, >>>> -- Igor >>>> >>>>> On Jul 16, 2019, at 5:36 AM, Severin Gehwolf wrote: >>>>> >>>>> Hi, >>>>> >>>>> I believe I still need a *R*eviewer for this. Any takers? >>>>> >>>>> Thanks, >>>>> Severin >>>>> >>>>> On Fri, 2019-07-12 at 15:19 -0700, mikhailo.seledtsov at oracle.com wrote: >>>>>> Hi Severin, >>>>>> >>>>>> The change looks good to me. Thank you for adding support for Podman >>>>>> container technology. >>>>>> >>>>>> Testing: I ran both HotSpot and JDK container tests with your patch; >>>>>> tests executed on Oracle Linux 7.6 using default container engine (Docker): >>>>>> >>>>>> test/hotspot/jtreg/containers/ AND >>>>>> test/jdk/jdk/internal/platform/docker/ >>>>>> >>>>>> All PASS >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Misha >>>>>> >>>>>> >>>>>> On 7/12/19 11:08 AM, Severin Gehwolf wrote: >>>>>>> Hi, >>>>>>> >>>>>>> There is an alternative container engine which is being used by Fedora >>>>>>> and RHEL 8, called podman[1]. It's mostly compatible with docker. It >>>>>>> looks like OpenJDK docker tests can be made podman compatible with a >>>>>>> few little tweaks. One "interesting" one is to not assert "Successfully >>>>>>> built" in the build output but only rely on the exit code, which seems >>>>>>> to be OK for my testing. Interestingly the test would be skipped in >>>>>>> that case. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8227642 >>>>>>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227642/01/webrev/ >>>>>>> >>>>>>> Adjustments I've done: >>>>>>> * Don't assert "Successfully built" in image build output[2]. >>>>>>> * Add /usr/sbin to PATH as the podman binary relies on iptables for it >>>>>>> to work which is in /usr/sbin on Fedora >>>>>>> * Allow for Metrics.getCpuSystemUsage() and Metrics.getCpuUserUsage() >>>>>>> to be equal to the previous value. I've found those counters to be >>>>>>> slowly increasing, which made the tests unreliable. >>>>>>> >>>>>>> Testing: >>>>>>> >>>>>>> Running docker tests with docker as engine. Did the same with podman as >>>>>>> engine via -Djdk.test.docker.command=podman on Linux x86_64. Both >>>>>>> passed (non-trivially). >>>>>>> >>>>>>> Thoughts? >>>>>>> >>>>>>> Thanks, >>>>>>> Severin >>>>>>> >>>>>>> [1] https://podman.io/ >>>>>>> [2] Image builds with podman look >>>>>>> like ("COMMIT" over "Successfully built"): >>>>>>> STEP 1: FROM fedora:29 >>>>>>> STEP 2: RUN dnf install -y java-11-openjdk-devel && dnf clean all >>>>>>> --> Using cache 96f8b1a0dfe7dba581a64fc67a27002ddf52e032af55f9ddc765182a690afd9d >>>>>>> STEP 3: COPY TestMetrics.class TestMetrics.java /opt/ >>>>>>> 269042160f7a4e6a06789cd19640ea658a8f941bc53de0fd40a574dc3bdb49a8 >>>>>>> STEP 4: CMD /usr/lib/jvm/java-11-openjdk/bin/java -cp /opt --add-modules java.base --add-exports java.base/jdk.internal.platform=ALL-UNNAMED TestMetrics >>>>>>> STEP 5: COMMIT fedora-metrics-11 >>>>>>> d749088d6ce4510f212820ad4eca55a9b05e5c5c245f2372b6cfe91926e8cd7e >>>>>>> From igor.ignatyev at oracle.com Wed Jul 17 18:37:58 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 17 Jul 2019 11:37:58 -0700 Subject: RFR: 8227642: [TESTBUG] Make docker tests podman compatible In-Reply-To: <60f8f5a9003dd199f2384360c16032d21c881dbb.camel@redhat.com> References: <32c8a1934bf07e4c9c6a961e60dcb7abd9931fe1.camel@redhat.com> <5bc3ac00-6ac9-99aa-052d-0a4aa6b04f8f@oracle.com> <47390A32-BD5B-4FF3-B93B-69ACECBC3E78@oracle.com> <243091d0e29604851d100b94d5ad777d9cf59127.camel@redhat.com> <60f8f5a9003dd199f2384360c16032d21c881dbb.camel@redhat.com> Message-ID: Hi Severin, the updated webrev looks good to me, please see a couple comments below. Cheers, -- Igor > On Jul 17, 2019, at 10:34 AM, Severin Gehwolf wrote: > > Hi Misha, > > On Wed, 2019-07-17 at 10:22 -0700, mikhailo.seledtsov at oracle.com wrote: >> Hi Severin, >> >> On 7/17/19 5:44 AM, Severin Gehwolf wrote: >>> Hi Igor, Misha, >>> >>> On Tue, 2019-07-16 at 11:49 -0700, Igor Ignatyev wrote: >>>> Hi Severin, >>>> >>>> I don't think that tests (or test libraries for that matter) should >>>> be responsible for setting correct PATH value, it should be a part of >>>> host configuration procedure (tests can/should check that all >>>> required bins are available though). in other words, I'd prefer if >>>> you remove 'env.put("PATH", ...)' lines from both DockerTestUtils and >>>> TestJFREvents. the rest looks good to me. >>> Updated webrev: >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227642/02/webrev/ >>> >>> No more additions to PATH are being done. >>> >>> I've discovered that VMProps.java which defines "docker.required", used >>> the "docker" binary even for podman test runs. This ended up not >>> running most of the tests even with -Djdk.test.docker.command=podman >>> specified. >> Good catch. should we rename docker.support and DOCKER_COMMAND to something more abstract? >>> I've fixed that by moving DOCKER_COMMAND to Platform.java so >>> that it can be used in both places. >> >> Sounds good to me. >> >> (of course, the alternative would be to import >> jdk.test.lib.containers.docker.DockerTestUtils into VMProps.java -- not >> sure if there are any potential problems doing it this way) > > I've tried that but for some reason this was a problem and VMProps > failed to compile. I don't know exactly how those jtreg extensions work > and went with the Platform approach. Hope that's OK. all files needed for VMProps (or other @requires expression class) have to be listed in requires.extraPropDefns or requires.extraPropDefns.bootlibs property in TEST.ROOT file in all the test suites which use these extensions. we are trying to be very cautious in what is used by VMProps (directly and indirectly) so these lists won't grow and we won't require any modules other than java.base, given DockerTestUtils has dependencies on a number of other library classes, the Platform approach is much better from that point of view. > >>> Testing: Container tests with docker daemon running on Linux x86_64, >>> container tests without docker daemon running (podman is daemon-less) >>> via the podman binary on Linux x86_64 (with -e:PATH). All pass. >> >> Sounds good. >> >> >> Overall looks good to me. > > Thanks for the review! > >> One minor nit: DockerTestUtils.java does not need "import >> java.util.Map;" (no need to post updated webrev for this change) > > OK, good catch. Fixed locally. > > Thanks, > Severin > >> >> Thank you, >> >> Misha >> >>> More thoughts? >>> >>> Thanks, >>> Severin >>> >>>> Thanks, >>>> -- Igor >>>> >>>>> On Jul 16, 2019, at 5:36 AM, Severin Gehwolf wrote: >>>>> >>>>> Hi, >>>>> >>>>> I believe I still need a *R*eviewer for this. Any takers? >>>>> >>>>> Thanks, >>>>> Severin >>>>> >>>>> On Fri, 2019-07-12 at 15:19 -0700, mikhailo.seledtsov at oracle.com wrote: >>>>>> Hi Severin, >>>>>> >>>>>> The change looks good to me. Thank you for adding support for Podman >>>>>> container technology. >>>>>> >>>>>> Testing: I ran both HotSpot and JDK container tests with your patch; >>>>>> tests executed on Oracle Linux 7.6 using default container engine (Docker): >>>>>> >>>>>> test/hotspot/jtreg/containers/ AND >>>>>> test/jdk/jdk/internal/platform/docker/ >>>>>> >>>>>> All PASS >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Misha >>>>>> >>>>>> >>>>>> On 7/12/19 11:08 AM, Severin Gehwolf wrote: >>>>>>> Hi, >>>>>>> >>>>>>> There is an alternative container engine which is being used by Fedora >>>>>>> and RHEL 8, called podman[1]. It's mostly compatible with docker. It >>>>>>> looks like OpenJDK docker tests can be made podman compatible with a >>>>>>> few little tweaks. One "interesting" one is to not assert "Successfully >>>>>>> built" in the build output but only rely on the exit code, which seems >>>>>>> to be OK for my testing. Interestingly the test would be skipped in >>>>>>> that case. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8227642 >>>>>>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227642/01/webrev/ >>>>>>> >>>>>>> Adjustments I've done: >>>>>>> * Don't assert "Successfully built" in image build output[2]. >>>>>>> * Add /usr/sbin to PATH as the podman binary relies on iptables for it >>>>>>> to work which is in /usr/sbin on Fedora >>>>>>> * Allow for Metrics.getCpuSystemUsage() and Metrics.getCpuUserUsage() >>>>>>> to be equal to the previous value. I've found those counters to be >>>>>>> slowly increasing, which made the tests unreliable. >>>>>>> >>>>>>> Testing: >>>>>>> >>>>>>> Running docker tests with docker as engine. Did the same with podman as >>>>>>> engine via -Djdk.test.docker.command=podman on Linux x86_64. Both >>>>>>> passed (non-trivially). >>>>>>> >>>>>>> Thoughts? >>>>>>> >>>>>>> Thanks, >>>>>>> Severin >>>>>>> >>>>>>> [1] https://podman.io/ >>>>>>> [2] Image builds with podman look >>>>>>> like ("COMMIT" over "Successfully built"): >>>>>>> STEP 1: FROM fedora:29 >>>>>>> STEP 2: RUN dnf install -y java-11-openjdk-devel && dnf clean all >>>>>>> --> Using cache 96f8b1a0dfe7dba581a64fc67a27002ddf52e032af55f9ddc765182a690afd9d >>>>>>> STEP 3: COPY TestMetrics.class TestMetrics.java /opt/ >>>>>>> 269042160f7a4e6a06789cd19640ea658a8f941bc53de0fd40a574dc3bdb49a8 >>>>>>> STEP 4: CMD /usr/lib/jvm/java-11-openjdk/bin/java -cp /opt --add-modules java.base --add-exports java.base/jdk.internal.platform=ALL-UNNAMED TestMetrics >>>>>>> STEP 5: COMMIT fedora-metrics-11 >>>>>>> d749088d6ce4510f212820ad4eca55a9b05e5c5c245f2372b6cfe91926e8cd7e From lance.andersen at oracle.com Wed Jul 17 19:28:20 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 17 Jul 2019 15:28:20 -0400 Subject: 8067801: Enforce null check for underlying I/O streams In-Reply-To: References: Message-ID: Hi Brian, I think this looks good. I might consider adding the NPE message to the individual classes as it is easy to miss in the java.io package but that is just a suggestion. Especially with the new search feature of javadoc, I usually go straight to the method so would never see the info in the package comments. Did you give any thought of using TestNG/assertThrows? Not a big deal, I just a personal preference :-) HTH Best Lance > On Jul 17, 2019, at 12:12 PM, Brian Burkhalter wrote: > > https://bugs.openjdk.java.net/browse/JDK-8067801 > http://cr.openjdk.java.net/~bpb/8067801/webrev.00/ > > Add null check to Filter{In,Out}putStream constructors. This covers all the cases listed in the issue as those are all subclasses of these two classes. No javadoc update is need due to this statement in the java.io package doc: > > "Unless otherwise noted, passing a null argument to a constructor or method in any class or interface in this package will cause a NullPointerException to be thrown." > > Thanks, > > Brian 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 Wed Jul 17 19:35:08 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 17 Jul 2019 12:35:08 -0700 Subject: 8067801: Enforce null check for underlying I/O streams In-Reply-To: References: Message-ID: Hi Lance, > On Jul 17, 2019, at 12:28 PM, Lance Andersen wrote: > > I think this looks good. Thanks. > I might consider adding the NPE message to the individual classes as it is easy to miss in the java.io package but that is just a suggestion. Especially with the new search feature of javadoc, I usually go straight to the method so would never see the info in the package comments. It might be better but I don?t know where else in java.io an NPE is thrown without being documented on the ctor/method itself. If there are other places then a general inspection might be in order. Note that the practice of using the package-level doc occurs also in java.nio: "Unless otherwise noted, passing a null argument to a constructor or method in any class or interface in this package will cause a NullPointerException to be thrown." > Did you give any thought of using TestNG/assertThrows? Not a big deal, I just a personal preference :-) I don?t see how that would work in this case as we do *not* expect an exception. Thanks, Brian From brian.burkhalter at oracle.com Wed Jul 17 19:46:41 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 17 Jul 2019 12:46:41 -0700 Subject: 8067801: Enforce null check for underlying I/O streams In-Reply-To: References: Message-ID: <08FF244A-A7FB-4125-BE25-00840A6C2D66@oracle.com> Hi Lance, > On Jul 17, 2019, at 12:35 PM, Brian Burkhalter wrote: > >> I might consider adding the NPE message to the individual classes as it is easy to miss in the java.io > package but that is just a suggestion. Especially with the new search feature of javadoc, I usually go straight to the method so would never see the info in the package comments. > > It might be better but I don?t know where else in java.io an NPE is thrown without being documented on the ctor/method itself. If there are other places then a general inspection might be in order. I looked through some of the other classes and there are not-locally-documented NPEs in a number of constructors including all the Readers and Writers. I think for now I?d rather leave it as is. > Note that the practice of using the package-level doc occurs also in java.nio: > > "Unless otherwise noted, passing a null argument to a constructor or method in any class or interface in this package will cause a NullPointerException to be thrown." > >> Did you give any thought of using TestNG/assertThrows? Not a big deal, I just a personal preference :-) > > I don?t see how that would work in this case as we do *not* expect an exception. Sorry: I had it backwards - d?oh! You are correct, that would work. I?ll look into revising it. What I was actually wondering about with respect to the tests is whether one can have the same bug ID in two different tests. Also I was not sure whether there might be a location where the two merged into a single test would be appropriate. Thanks, Brian From lance.andersen at oracle.com Wed Jul 17 20:02:08 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 17 Jul 2019 16:02:08 -0400 Subject: 8067801: Enforce null check for underlying I/O streams In-Reply-To: <08FF244A-A7FB-4125-BE25-00840A6C2D66@oracle.com> References: <08FF244A-A7FB-4125-BE25-00840A6C2D66@oracle.com> Message-ID: <2AC643FD-CA97-4EDA-8756-5E4A40E36C75@oracle.com> Hi Brian, > On Jul 17, 2019, at 3:46 PM, Brian Burkhalter wrote: > > Hi Lance, > >> On Jul 17, 2019, at 12:35 PM, Brian Burkhalter > wrote: >> >>> I might consider adding the NPE message to the individual classes as it is easy to miss in the java.io > package but that is just a suggestion. Especially with the new search feature of javadoc, I usually go straight to the method so would never see the info in the package comments. >> >> It might be better but I don?t know where else in java.io an NPE is thrown without being documented on the ctor/method itself. If there are other places then a general inspection might be in order. > > I looked through some of the other classes and there are not-locally-documented NPEs in a number of constructors including all the Readers and Writers. I think for now I?d rather leave it as is. Understand, go with what makes sense, BTW, I was not suggesting adding it to the individual constructor javadoc, but to the Class overview javadoc at the top of the class. Totally get leaving it as is. :-) > >> Note that the practice of using the package-level doc occurs also in java.nio: >> >> "Unless otherwise noted, passing a null argument to a constructor or method in any class or interface in this package will cause a NullPointerException to be thrown." >> >>> Did you give any thought of using TestNG/assertThrows? Not a big deal, I just a personal preference :-) >> >> I don?t see how that would work in this case as we do *not* expect an exception. > > Sorry: I had it backwards - d?oh! :-) Blame me as I could have been clearer in my comment, apologizes for that :-) > You are correct, that would work. I?ll look into revising it. > > What I was actually wondering about with respect to the tests is whether one can have the same bug ID in two different tests. Yes that should be OK as @bug is just an informational tag: https://openjdk.java.net/jtreg/tag-spec.html > Also I was not sure whether there might be a location where the two merged into a single test would be appropriate. I think what you have is fine, a unique test in each subdirectory as it is organized by class. What you might consider is having a generic NPE Test class, which validates the error for Constructors and methods as described in the package javadoc. Maybe this is a TBD, but if you decide that is a good idea, consider renaming the test now to maybe NPETests.java Either way you are good to go. Best Lance > > Thanks, > > Brian 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 Wed Jul 17 20:03:45 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Wed, 17 Jul 2019 13:03:45 -0700 Subject: RFR (S): JDK-8222778: Packaging Tool (JEP 343) on Linux/AArch64 In-Reply-To: <0b27c1cc-2770-9e1c-3497-a281c0959b2e@bell-sw.com> References: <547af6cd-de60-227b-8a1f-6889cbb0b1aa@oracle.com> <0b27c1cc-2770-9e1c-3497-a281c0959b2e@bell-sw.com> Message-ID: <5c117f91-d028-717a-de74-e1d8b97edc16@oracle.com> Hi Dmitry, I also do not see point of keeping this block, so lets remove it instead of keeping it commented. Thanks, Alexander On 7/16/2019 3:50 PM, Dmitry Chuyko wrote: > Alexander, thanks for having a look, > > On 7/17/19 12:30 AM, Alexander Matveev wrote: >> Hi Dmitry, >> >> http://cr.openjdk.java.net/~dchuyko/8222778/webrev.00/src/jdk.jpackage/unix/native/libapplauncher/PosixPlatform.cpp.frames.html >> >> Why code between lines 215 and 219 was disabled? Not sure what it >> tries to do, if it tries to guarantee NULL termination we should >> probably keep it or allocate buffer with extra null or read >> (sizeof(buffer)-1). I think EOF defined as -1. > > gcc 5.4.0 on Linux reports an error: > > sandbox/src/jdk.jpackage/unix/native/libapplauncher/PosixPlatform.cpp: > In member function ?bool PosixProcess::ReadOutput()?: > > sandbox/src/jdk.jpackage/unix/native/libapplauncher/PosixPlatform.cpp:215:35: > error: comparison is always false due to limited range of data type > [-Werror=type-limits] > ???????????? if (buffer[count - 1] == EOF) { > > Here buffer is char[] and read(int, void *, size_t) is used. > > It won't be right to keep it commented, to me it looks like this block > can be removed. If not, there should be some other fix like adding > ifdefs for some platforms or using call different from read(). > > -Dmitry > >> Otherwise looks fine. >> >> Thanks, >> Alexander >> >> On 7/16/2019 12:55 PM, Dmitry Chuyko wrote: >>> Hello, >>> >>> Please review a small patch that mostly fixes jpackage test for >>> Linux aarch64 and also arm,x86,power. It is prepared for >>> 'JDK-8200758-branch' branch of open 'sandbox' repo. >>> >>> There are few parts: >>> >>> 1. LinuxPlatform.cpp and IniFile.cpp got small fixes for compiler >>> warnings. >>> >>> 2. LinuxDebBundler.getArch() now maps only x86_64 to amd64, x86 is >>> still mapped to i386, and other archs map to themselves. >>> >>> 3. In tests, new method getRpmArch() was added to >>> linux/base/Base.java, it maps JVMs os.arch to default rpmbuild arch. >>> Multiple tests were modified to use that method instead of "x86_64" >>> in rpm file name. Some timeouts were increased. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8222778 >>> >>> webrev: http://cr.openjdk.java.net/~dchuyko/8222778/webrev.00/ >>> >>> testing: test/jdk/tools/jpackage jtreg tests pass on Ubuntu 16.04 >>> with rpmbuild on x86_64, aarch64, arm, x86 and power, except >>> deb/MaintainerTest (fails everywhere similarly to x86_64 because of >>> extra "Unknown" name in email). >>> >>> I didin't cover s390 as we in BellSoft currently don't build on that >>> arch. On typical armv7 hw increased or default timeouts are still >>> too low, while they are fine for some relatively weak aarch64 >>> machines. Deb tests run especially slow because of dpkg-deb itself. >>> I used "force-unsafe-io" option in /etc/dpkg/dpkg.cfg, it does >>> reduce packaging time but still not enough to have really fast tests. >>> >>> -Dmitry >>> >>> >> From brian.burkhalter at oracle.com Wed Jul 17 20:39:06 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 17 Jul 2019 13:39:06 -0700 Subject: 8067801: Enforce null check for underlying I/O streams In-Reply-To: <2AC643FD-CA97-4EDA-8756-5E4A40E36C75@oracle.com> References: <08FF244A-A7FB-4125-BE25-00840A6C2D66@oracle.com> <2AC643FD-CA97-4EDA-8756-5E4A40E36C75@oracle.com> Message-ID: <2FD612A7-E139-43E9-96E5-1919002F7CBE@oracle.com> Hi Lance, > On Jul 17, 2019, at 1:02 PM, Lance Andersen wrote: > > I think what you have is fine, a unique test in each subdirectory as it is organized by class. What you might consider is having a generic NPE Test class, which validates the error for Constructors and methods as described in the package javadoc. Maybe this is a TBD, but if you decide that is a good idea, consider renaming the test now to maybe NPETests.java I merged the two tests into one and converted to TestNG [1]. There is precedent for having a test which deals with multiple classes in test/jdk/java/io [2]. Thanks, Brian [1] http://cr.openjdk.java.net/~bpb/8067801/webrev.01/ [2] test/jdk/java/io/NegativeInitSize.java From dmitry.chuyko at bell-sw.com Wed Jul 17 20:44:30 2019 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Wed, 17 Jul 2019 23:44:30 +0300 Subject: RFR (S): JDK-8222778: Packaging Tool (JEP 343) on Linux/AArch64 In-Reply-To: <5c117f91-d028-717a-de74-e1d8b97edc16@oracle.com> References: <547af6cd-de60-227b-8a1f-6889cbb0b1aa@oracle.com> <0b27c1cc-2770-9e1c-3497-a281c0959b2e@bell-sw.com> <5c117f91-d028-717a-de74-e1d8b97edc16@oracle.com> Message-ID: Ok, here is the updated webrev: http://cr.openjdk.java.net/~dchuyko/8222778/webrev.01/ -Dmitry On 7/17/19 11:03 PM, Alexander Matveev wrote: > Hi Dmitry, > > I also do not see point of keeping this block, so lets remove it > instead of keeping it commented. > > Thanks, > Alexander > > On 7/16/2019 3:50 PM, Dmitry Chuyko wrote: >> Alexander, thanks for having a look, >> >> On 7/17/19 12:30 AM, Alexander Matveev wrote: >>> Hi Dmitry, >>> >>> http://cr.openjdk.java.net/~dchuyko/8222778/webrev.00/src/jdk.jpackage/unix/native/libapplauncher/PosixPlatform.cpp.frames.html >>> >>> Why code between lines 215 and 219 was disabled? Not sure what it >>> tries to do, if it tries to guarantee NULL termination we should >>> probably keep it or allocate buffer with extra null or read >>> (sizeof(buffer)-1). I think EOF defined as -1. >> >> gcc 5.4.0 on Linux reports an error: >> >> sandbox/src/jdk.jpackage/unix/native/libapplauncher/PosixPlatform.cpp: >> In member function ?bool PosixProcess::ReadOutput()?: >> >> sandbox/src/jdk.jpackage/unix/native/libapplauncher/PosixPlatform.cpp:215:35: >> error: comparison is always false due to limited range of data type >> [-Werror=type-limits] >> ???????????? if (buffer[count - 1] == EOF) { >> >> Here buffer is char[] and read(int, void *, size_t) is used. >> >> It won't be right to keep it commented, to me it looks like this >> block can be removed. If not, there should be some other fix like >> adding ifdefs for some platforms or using call different from read(). >> >> -Dmitry >> >>> Otherwise looks fine. >>> >>> Thanks, >>> Alexander >>> >>> On 7/16/2019 12:55 PM, Dmitry Chuyko wrote: >>>> Hello, >>>> >>>> Please review a small patch that mostly fixes jpackage test for >>>> Linux aarch64 and also arm,x86,power. It is prepared for >>>> 'JDK-8200758-branch' branch of open 'sandbox' repo. >>>> >>>> There are few parts: >>>> >>>> 1. LinuxPlatform.cpp and IniFile.cpp got small fixes for compiler >>>> warnings. >>>> >>>> 2. LinuxDebBundler.getArch() now maps only x86_64 to amd64, x86 is >>>> still mapped to i386, and other archs map to themselves. >>>> >>>> 3. In tests, new method getRpmArch() was added to >>>> linux/base/Base.java, it maps JVMs os.arch to default rpmbuild >>>> arch. Multiple tests were modified to use that method instead of >>>> "x86_64" in rpm file name. Some timeouts were increased. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8222778 >>>> >>>> webrev: http://cr.openjdk.java.net/~dchuyko/8222778/webrev.00/ >>>> >>>> testing: test/jdk/tools/jpackage jtreg tests pass on Ubuntu 16.04 >>>> with rpmbuild on x86_64, aarch64, arm, x86 and power, except >>>> deb/MaintainerTest (fails everywhere similarly to x86_64 because of >>>> extra "Unknown" name in email). >>>> >>>> I didin't cover s390 as we in BellSoft currently don't build on >>>> that arch. On typical armv7 hw increased or default timeouts are >>>> still too low, while they are fine for some relatively weak aarch64 >>>> machines. Deb tests run especially slow because of dpkg-deb itself. >>>> I used "force-unsafe-io" option in /etc/dpkg/dpkg.cfg, it does >>>> reduce packaging time but still not enough to have really fast tests. >>>> >>>> -Dmitry >>>> >>>> >>> > From lance.andersen at oracle.com Wed Jul 17 20:55:28 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 17 Jul 2019 16:55:28 -0400 Subject: 8067801: Enforce null check for underlying I/O streams In-Reply-To: <2FD612A7-E139-43E9-96E5-1919002F7CBE@oracle.com> References: <08FF244A-A7FB-4125-BE25-00840A6C2D66@oracle.com> <2AC643FD-CA97-4EDA-8756-5E4A40E36C75@oracle.com> <2FD612A7-E139-43E9-96E5-1919002F7CBE@oracle.com> Message-ID: <48CD15F2-9E94-471A-997E-E71A3BD921CC@oracle.com> Hi Brian > On Jul 17, 2019, at 4:39 PM, Brian Burkhalter wrote: > > Hi Lance, > >> On Jul 17, 2019, at 1:02 PM, Lance Andersen > wrote: >> >> I think what you have is fine, a unique test in each subdirectory as it is organized by class. What you might consider is having a generic NPE Test class, which validates the error for Constructors and methods as described in the package javadoc. Maybe this is a TBD, but if you decide that is a good idea, consider renaming the test now to maybe NPETests.java > > I merged the two tests into one and converted to TestNG [1]. There is precedent for having a test which deals with multiple classes in test/jdk/java/io [2]. Thanks for the pointer. Looks fine and You are good to go?.. I guess the next question(here he goes again ;-) is do you want to test all of the constructors such as BufferedInputStream(InputStream, int) or just one per class? I realize the BufferedInputStream(InputStream) just calls into BufferedInputStream(InputStream, int). Sorry for the continual questions and extra work Best Lance > > Thanks, > > Brian > > [1] http://cr.openjdk.java.net/~bpb/8067801/webrev.01/ > [2] test/jdk/java/io/NegativeInitSize.java 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 Wed Jul 17 21:01:29 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Wed, 17 Jul 2019 14:01:29 -0700 Subject: RFR (S): JDK-8222778: Packaging Tool (JEP 343) on Linux/AArch64 In-Reply-To: References: <547af6cd-de60-227b-8a1f-6889cbb0b1aa@oracle.com> <0b27c1cc-2770-9e1c-3497-a281c0959b2e@bell-sw.com> <5c117f91-d028-717a-de74-e1d8b97edc16@oracle.com> Message-ID: Hi Dmitry, Updated webrev looks fine. Thanks, Alexander On 7/17/2019 1:44 PM, Dmitry Chuyko wrote: > Ok, here is the updated webrev: > http://cr.openjdk.java.net/~dchuyko/8222778/webrev.01/ > > -Dmitry > > On 7/17/19 11:03 PM, Alexander Matveev wrote: >> Hi Dmitry, >> >> I also do not see point of keeping this block, so lets remove it >> instead of keeping it commented. >> >> Thanks, >> Alexander >> >> On 7/16/2019 3:50 PM, Dmitry Chuyko wrote: >>> Alexander, thanks for having a look, >>> >>> On 7/17/19 12:30 AM, Alexander Matveev wrote: >>>> Hi Dmitry, >>>> >>>> http://cr.openjdk.java.net/~dchuyko/8222778/webrev.00/src/jdk.jpackage/unix/native/libapplauncher/PosixPlatform.cpp.frames.html >>>> >>>> Why code between lines 215 and 219 was disabled? Not sure what it >>>> tries to do, if it tries to guarantee NULL termination we should >>>> probably keep it or allocate buffer with extra null or read >>>> (sizeof(buffer)-1). I think EOF defined as -1. >>> >>> gcc 5.4.0 on Linux reports an error: >>> >>> sandbox/src/jdk.jpackage/unix/native/libapplauncher/PosixPlatform.cpp: >>> In member function ?bool PosixProcess::ReadOutput()?: >>> >>> sandbox/src/jdk.jpackage/unix/native/libapplauncher/PosixPlatform.cpp:215:35: >>> error: comparison is always false due to limited range of data type >>> [-Werror=type-limits] >>> ???????????? if (buffer[count - 1] == EOF) { >>> >>> Here buffer is char[] and read(int, void *, size_t) is used. >>> >>> It won't be right to keep it commented, to me it looks like this >>> block can be removed. If not, there should be some other fix like >>> adding ifdefs for some platforms or using call different from read(). >>> >>> -Dmitry >>> >>>> Otherwise looks fine. >>>> >>>> Thanks, >>>> Alexander >>>> >>>> On 7/16/2019 12:55 PM, Dmitry Chuyko wrote: >>>>> Hello, >>>>> >>>>> Please review a small patch that mostly fixes jpackage test for >>>>> Linux aarch64 and also arm,x86,power. It is prepared for >>>>> 'JDK-8200758-branch' branch of open 'sandbox' repo. >>>>> >>>>> There are few parts: >>>>> >>>>> 1. LinuxPlatform.cpp and IniFile.cpp got small fixes for compiler >>>>> warnings. >>>>> >>>>> 2. LinuxDebBundler.getArch() now maps only x86_64 to amd64, x86 is >>>>> still mapped to i386, and other archs map to themselves. >>>>> >>>>> 3. In tests, new method getRpmArch() was added to >>>>> linux/base/Base.java, it maps JVMs os.arch to default rpmbuild >>>>> arch. Multiple tests were modified to use that method instead of >>>>> "x86_64" in rpm file name. Some timeouts were increased. >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8222778 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~dchuyko/8222778/webrev.00/ >>>>> >>>>> testing: test/jdk/tools/jpackage jtreg tests pass on Ubuntu 16.04 >>>>> with rpmbuild on x86_64, aarch64, arm, x86 and power, except >>>>> deb/MaintainerTest (fails everywhere similarly to x86_64 because >>>>> of extra "Unknown" name in email). >>>>> >>>>> I didin't cover s390 as we in BellSoft currently don't build on >>>>> that arch. On typical armv7 hw increased or default timeouts are >>>>> still too low, while they are fine for some relatively weak >>>>> aarch64 machines. Deb tests run especially slow because of >>>>> dpkg-deb itself. I used "force-unsafe-io" option in >>>>> /etc/dpkg/dpkg.cfg, it does reduce packaging time but still not >>>>> enough to have really fast tests. >>>>> >>>>> -Dmitry >>>>> >>>>> >>>> >> From brian.burkhalter at oracle.com Wed Jul 17 21:08:17 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 17 Jul 2019 14:08:17 -0700 Subject: 8067801: Enforce null check for underlying I/O streams In-Reply-To: <48CD15F2-9E94-471A-997E-E71A3BD921CC@oracle.com> References: <08FF244A-A7FB-4125-BE25-00840A6C2D66@oracle.com> <2AC643FD-CA97-4EDA-8756-5E4A40E36C75@oracle.com> <2FD612A7-E139-43E9-96E5-1919002F7CBE@oracle.com> <48CD15F2-9E94-471A-997E-E71A3BD921CC@oracle.com> Message-ID: <231197C8-312F-4376-A077-09A87B22F47F@oracle.com> Hi Lance, > On Jul 17, 2019, at 1:55 PM, Lance Andersen wrote: > > I guess the next question(here he goes again ;-) is do you want to test all of the constructors such as BufferedInputStream(InputStream, int) or just one per class? I realize the BufferedInputStream(InputStream) just calls into BufferedInputStream(InputStream, int). Might as well add them in: http://cr.openjdk.java.net/~bpb/8067801/webrev.02/ > Sorry for the continual questions and extra work No worries: it?s good to have things pointed out! Thanks, Brian From dmitry.chuyko at bell-sw.com Wed Jul 17 21:19:31 2019 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Thu, 18 Jul 2019 00:19:31 +0300 Subject: RFR (S): JDK-8222778: Packaging Tool (JEP 343) on Linux/AArch64 In-Reply-To: References: Message-ID: <234f1c54-bd2a-c90b-367b-e279062218ff@bell-sw.com> Hi Andrew, On 7/17/19 11:52 AM, Andrew Haley wrote: > On 7/16/19 8:55 PM, Dmitry Chuyko wrote: >> Hello, >> >> Please review a small patch that mostly fixes jpackage test for Linux >> aarch64 and also arm,x86,power. It is prepared for 'JDK-8200758-branch' >> branch of open 'sandbox' repo. >> >> There are few parts: >> >> 1. LinuxPlatform.cpp and IniFile.cpp got small fixes for compiler warnings. > This is weird: > > --- old/src/jdk.jpackage/linux/native/libapplauncher/LinuxPlatform.cpp 2019-07-16 22:11:30.200258978 +0300 > +++ new/src/jdk.jpackage/linux/native/libapplauncher/LinuxPlatform.cpp 2019-07-16 22:11:29.867374851 +0300 > @@ -127,7 +127,7 @@ > } > > void LinuxPlatform::SetCurrentDirectory(TString Value) { > - chdir(PlatformString(Value).toPlatformString()); > + int ignored = chdir(PlatformString(Value).toPlatformString()); > } > > Firstly it does not fix the problem: you've gone from an unused value to an > unused variable. Secondly, we ignore the return value of printf all the time; > what's different about this one? chdir() is __wur, which is /usr/include/aarch64-linux-gnu/sys/cdefs.h:#? define __wur __attribute_warn_unused_result__ In some places this warning is disabled (CoreLibraries.gmk, Awt2dLibraries.gmk). It would be more correct to handle the result here as chdir might not succeeded in fact. > > This: > > @@ -212,9 +212,11 @@ > } else if (count == 0) { > // break; > } else { > +/* > if (buffer[count - 1] == EOF) { > buffer[count - 1] = '\0'; > } > +*/ > > I'm wondering if this bogus code might have been inherited from Windows. Yes, something not-posix in ...-posix file. Removed in webrev.01. > >> 2. LinuxDebBundler.getArch() now maps only x86_64 to amd64, x86 is still >> mapped to i386, and other archs map to themselves. >> >> 3. In tests, new method getRpmArch() was added to linux/base/Base.java, >> it maps JVMs os.arch to default rpmbuild arch. Multiple tests were >> modified to use that method instead of "x86_64" in rpm file name. Some >> timeouts were increased. > + if ("arm".equals(arch)) > + return "armv7hl"; > > Is this actually correct? How do you know it's not, say, armv7hf? I would > have thought there must be some better way to get the RPM arch. Isn't > running /bin/arch right on your systems? Using $(arch) is an interesting question. For now implementation decides what kind of bundle to create looking at JVM binary arch. This should guarantee that the bundle will fit the same arch of host and some compatible architectures (app will be be installable and runnable). And it also mean current tests may fail if host and VM archs are different (because packages won't be found while may be created and may be working). 'arvmv7hl' is a common build environment/target for arm port and looks like a compatible option. We may look into VM binary metadata though to get exact build arch. -Dmitry > From lance.andersen at oracle.com Wed Jul 17 21:19:47 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 17 Jul 2019 17:19:47 -0400 Subject: 8067801: Enforce null check for underlying I/O streams In-Reply-To: <231197C8-312F-4376-A077-09A87B22F47F@oracle.com> References: <08FF244A-A7FB-4125-BE25-00840A6C2D66@oracle.com> <2AC643FD-CA97-4EDA-8756-5E4A40E36C75@oracle.com> <2FD612A7-E139-43E9-96E5-1919002F7CBE@oracle.com> <48CD15F2-9E94-471A-997E-E71A3BD921CC@oracle.com> <231197C8-312F-4376-A077-09A87B22F47F@oracle.com> Message-ID: Hi Brian > On Jul 17, 2019, at 5:08 PM, Brian Burkhalter wrote: > > Hi Lance, > >> On Jul 17, 2019, at 1:55 PM, Lance Andersen > wrote: >> >> I guess the next question(here he goes again ;-) is do you want to test all of the constructors such as BufferedInputStream(InputStream, int) or just one per class? I realize the BufferedInputStream(InputStream) just calls into BufferedInputStream(InputStream, int). > > Might as well add them in: http://cr.openjdk.java.net/~bpb/8067801/webrev.02/ >> Sorry for the continual questions and extra work > > No worries: it?s good to have things pointed out! Looks good. Maybe consider expanding to some of the other classes when you have cycles. But in the meantime, ship it! > > Thanks, > > Brian 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 Wed Jul 17 21:20:36 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 17 Jul 2019 14:20:36 -0700 Subject: 8067801: Enforce null check for underlying I/O streams In-Reply-To: References: <08FF244A-A7FB-4125-BE25-00840A6C2D66@oracle.com> <2AC643FD-CA97-4EDA-8756-5E4A40E36C75@oracle.com> <2FD612A7-E139-43E9-96E5-1919002F7CBE@oracle.com> <48CD15F2-9E94-471A-997E-E71A3BD921CC@oracle.com> <231197C8-312F-4376-A077-09A87B22F47F@oracle.com> Message-ID: <17329D68-0ED5-4925-AC7E-2BBAC41FCE3F@oracle.com> Thanks, Lance! > On Jul 17, 2019, at 2:19 PM, Lance Andersen wrote: > > Looks good. Maybe consider expanding to some of the other classes when you have cycles. But in the meantime, ship it! From brian.burkhalter at oracle.com Wed Jul 17 21:43:45 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 17 Jul 2019 14:43:45 -0700 Subject: 8228204: Fix for JDK-8067801 breaks java/io/NegativeInitSize.java Message-ID: https://bugs.openjdk.java.net/browse/JDK-8228204 I lamely did not catch this before the push of the patch for [1]. The diff is below. Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8067801 [2] diff @@ -22,7 +22,7 @@ */ /* @test - @bug 4015701 4127654 + @bug 4015701 4127654 8067801 @summary Test if the constructor would detect illegal arguments. */ @@ -49,8 +49,10 @@ ("PushbackReader failed to detect negative init size"); } + byte[] ba = { 123 }; + ByteArrayInputStream goodbis = new ByteArrayInputStream(ba); try { - PushbackInputStream pbis = new PushbackInputStream(null, -1); + PushbackInputStream pbis = new PushbackInputStream(goodbis, -1); } catch (IllegalArgumentException e) { } catch (Exception e) { throw new Exception @@ -66,8 +68,6 @@ ("BufferedOutputStream failed to detect negative init size"); } - byte[] ba = { 123 }; - ByteArrayInputStream goodbis = new ByteArrayInputStream(ba); try { BufferedInputStream bis = new BufferedInputStream(goodbis, -1); } catch (IllegalArgumentException e) { From mandy.chung at oracle.com Wed Jul 17 22:09:21 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 17 Jul 2019 15:09:21 -0700 Subject: RFR: 8227587: Add internal privileged System.loadLibrary In-Reply-To: <37ec9df1-4ff3-b888-ecee-dfbd109466d5@oracle.com> References: <8cf6ed4d-194a-4428-f381-e7e3c0452cd6@oracle.com> <4943b69c-bc3a-f147-abb8-5b369eec5737@oracle.com> <2cbfd5d8-c4a0-4a2d-ba62-6fed14dc7155@oracle.com> <60d95350-c42c-1498-5c72-174736e863c0@oracle.com> <15a57e3c-065c-55c5-b6af-0644ed8f775b@oracle.com> <3d3ef452-48d8-caf0-75a7-bcc051b13f82@oracle.com> <37ec9df1-4ff3-b888-ecee-dfbd109466d5@oracle.com> Message-ID: <9ee8b751-37e9-bb8a-b2b6-62fe0f55b0e7@oracle.com> On 7/17/19 3:25 AM, Claes Redestad wrote: > Hi Peter, > > On 2019-07-17 10:29, Peter Levart wrote: >> Hi Claes, >> >> Am I reading correct that package-private >> ClassLoader.loadLibrary(Class fromClass, String name, boolean >> isAbsolute) wouldn't need to consult SecurityManager wasn't it for >> accessing system properties in private >> ClassLoader.initializePath(String propName). So perhaps if the two >> calls to initializePath() in the if block of >> ClassLoader.loadLibrary() are wrapped with a single doPrivileged(), >> you wouldn't have to wrap the call to JavaLangAccess.loadLibrary in >> BootLoader. And since initializePath() would only be called once and >> then the results cached, you end up with less doPrivileged() >> wrappings when SecurityManager is present as soon as >> BootLoader.loadLibrary is called the 2nd time. > > hmm, fromClass.getClassLoader() also does a security check, though. > Class::getClassLoader is caller-sensitive and the call to fromClass.getClassLoader() does not trigger any security permission check as it's called from NativeLibrary who is loaded by the boot loader. > That said, there's a case for wrapping the initializePath calls in a > doPriv of their own, since we now have an implicit requirement that some > system library is loaded first (so that sys_paths is initialized) before > any user code attempts to load a library of their own... > I created https://bugs.openjdk.java.net/browse/JDK-8228336 to track the idea to refactor the system native library loading to BootLoader.?? I also have JDK-8228336 capturing Peter's observation. >> >> BTW, there is a data race when accessing usr_paths and sys_paths >> static fields in multi-threaded scenario. Their type is String[] >> which means that the contents of the arrays could be observed >> uninitialized (elements being null) in some thread. Both fields >> should be made volatile (not only sys_paths) as assignment to them >> can be performed more than once in idempotent racy initialization. > > .. and we typically seem to be loading at least one library before > initializing any user code, which is probably why this has never been an > issue. It seems like a good idea to remove this subtle fragility, > though. I wonder if we shouldn't "simply" initialize the two paths > during bootstrap and put them in final fields. > JDK-8228336 tracks this. Mandy From lance.andersen at oracle.com Wed Jul 17 22:10:33 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 17 Jul 2019 18:10:33 -0400 Subject: 8228204: Fix for JDK-8067801 breaks java/io/NegativeInitSize.java In-Reply-To: References: Message-ID: <6AFC375A-FD00-401F-AF7B-4459A7E1E4DB@oracle.com> Hi Brian, Looks OK, please add noreg-self label or equivalent to the issue > On Jul 17, 2019, at 5:43 PM, Brian Burkhalter wrote: > > https://bugs.openjdk.java.net/browse/JDK-8228204 > > I lamely did not catch this before the push of the patch for [1]. The diff is below. > > Thanks, > > Brian > > [1] https://bugs.openjdk.java.net/browse/JDK-8067801 > [2] diff > > @@ -22,7 +22,7 @@ > */ > > /* @test > - @bug 4015701 4127654 > + @bug 4015701 4127654 8067801 > @summary Test if the constructor would detect > illegal arguments. > */ > @@ -49,8 +49,10 @@ > ("PushbackReader failed to detect negative init size"); > } > > + byte[] ba = { 123 }; > + ByteArrayInputStream goodbis = new ByteArrayInputStream(ba); > try { > - PushbackInputStream pbis = new PushbackInputStream(null, -1); > + PushbackInputStream pbis = new PushbackInputStream(goodbis, -1); > } catch (IllegalArgumentException e) { > } catch (Exception e) { > throw new Exception > @@ -66,8 +68,6 @@ > ("BufferedOutputStream failed to detect negative init size"); > } > > - byte[] ba = { 123 }; > - ByteArrayInputStream goodbis = new ByteArrayInputStream(ba); > try { > BufferedInputStream bis = new BufferedInputStream(goodbis, -1); > } catch (IllegalArgumentException e) { > 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 Wed Jul 17 22:14:54 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 17 Jul 2019 15:14:54 -0700 Subject: 8228204: Fix for JDK-8067801 breaks java/io/NegativeInitSize.java In-Reply-To: <6AFC375A-FD00-401F-AF7B-4459A7E1E4DB@oracle.com> References: <6AFC375A-FD00-401F-AF7B-4459A7E1E4DB@oracle.com> Message-ID: Hi Lance, > On Jul 17, 2019, at 3:10 PM, Lance Andersen wrote: > > Looks OK, please add noreg-self label or equivalent to the issue Done and removed bug number from @bug tag. Pushed. Sorry for the noise. Thanks, Brian From brian.burkhalter at oracle.com Wed Jul 17 23:14:03 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 17 Jul 2019 16:14:03 -0700 Subject: 8228338: tools/pack200/TimeStamp.java fails with NullPointerException Message-ID: https://bugs.openjdk.java.net/browse/JDK-8228338 http://cr.openjdk.java.net/~bpb/8228338/webrev.00/ Another slip up due to not having tested the JDK-8067801 patch sufficiently. Thanks, Brian From lance.andersen at oracle.com Wed Jul 17 23:17:40 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 17 Jul 2019 19:17:40 -0400 Subject: 8228338: tools/pack200/TimeStamp.java fails with NullPointerException In-Reply-To: References: Message-ID: Looks OK Brian > On Jul 17, 2019, at 7:14 PM, Brian Burkhalter wrote: > > https://bugs.openjdk.java.net/browse/JDK-8228338 > http://cr.openjdk.java.net/~bpb/8228338/webrev.00/ > > Another slip up due to not having tested the JDK-8067801 patch sufficiently. > > Thanks, > > Brian 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 Jul 18 00:04:23 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 17 Jul 2019 17:04:23 -0700 Subject: 8228338: tools/pack200/TimeStamp.java fails with NullPointerException In-Reply-To: References: Message-ID: <80C8B7DE-C3FD-4DB8-A180-141A101A5076@oracle.com> Sorry Lance but there was another failure which I?ve lumped into the same issue and updated the webrev in place. I think it would be better to wait until tiers 1-3 are done before looking at it to avoid more spinning. Thanks, Brian > On Jul 17, 2019, at 4:17 PM, Lance Andersen wrote: > > Looks OK Brian >> On Jul 17, 2019, at 7:14 PM, Brian Burkhalter > wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8228338 >> http://cr.openjdk.java.net/~bpb/8228338/webrev.00/ >> >> Another slip up due to not having tested the JDK-8067801 patch sufficiently. >> >> Thanks, >> >> Brian > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From lance.andersen at oracle.com Thu Jul 18 00:09:18 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 17 Jul 2019 20:09:18 -0400 Subject: 8228338: tools/pack200/TimeStamp.java fails with NullPointerException In-Reply-To: <80C8B7DE-C3FD-4DB8-A180-141A101A5076@oracle.com> References: <80C8B7DE-C3FD-4DB8-A180-141A101A5076@oracle.com> Message-ID: <2F18DAED-24AE-4FA8-A4EA-D4A8198A432D@oracle.com> All good Brian, I agree and the latest update also looks OK > On Jul 17, 2019, at 8:04 PM, Brian Burkhalter wrote: > > Sorry Lance but there was another failure which I?ve lumped into the same issue and updated the webrev in place. I think it would be better to wait until tiers 1-3 are done before looking at it to avoid more spinning. > > Thanks, > > Brian > >> On Jul 17, 2019, at 4:17 PM, Lance Andersen > wrote: >> >> Looks OK Brian >>> On Jul 17, 2019, at 7:14 PM, Brian Burkhalter > wrote: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8228338 >>> http://cr.openjdk.java.net/~bpb/8228338/webrev.00/ >>> >>> Another slip up due to not having tested the JDK-8067801 patch sufficiently. >>> >>> Thanks, >>> >>> Brian >> >> >> >> 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 brian.burkhalter at oracle.com Thu Jul 18 00:11:03 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 17 Jul 2019 17:11:03 -0700 Subject: 8228338: tools/pack200/TimeStamp.java fails with NullPointerException In-Reply-To: <2F18DAED-24AE-4FA8-A4EA-D4A8198A432D@oracle.com> References: <80C8B7DE-C3FD-4DB8-A180-141A101A5076@oracle.com> <2F18DAED-24AE-4FA8-A4EA-D4A8198A432D@oracle.com> Message-ID: A test job I launched before the CI tests just finished now and it looks like this catches all the failures but let?s wait until the CI is done to be certain. Thanks, Brian > On Jul 17, 2019, at 5:09 PM, Lance Andersen wrote: > > All good Brian, I agree and the latest update also looks OK > > >> On Jul 17, 2019, at 8:04 PM, Brian Burkhalter > wrote: >> >> Sorry Lance but there was another failure which I?ve lumped into the same issue and updated the webrev in place. I think it would be better to wait until tiers 1-3 are done before looking at it to avoid more spinning. From mikhailo.seledtsov at oracle.com Thu Jul 18 01:38:11 2019 From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com) Date: Wed, 17 Jul 2019 18:38:11 -0700 Subject: RFR: 8227642: [TESTBUG] Make docker tests podman compatible In-Reply-To: References: <32c8a1934bf07e4c9c6a961e60dcb7abd9931fe1.camel@redhat.com> <5bc3ac00-6ac9-99aa-052d-0a4aa6b04f8f@oracle.com> <47390A32-BD5B-4FF3-B93B-69ACECBC3E78@oracle.com> <243091d0e29604851d100b94d5ad777d9cf59127.camel@redhat.com> <60f8f5a9003dd199f2384360c16032d21c881dbb.camel@redhat.com> Message-ID: <4899d2fa-bfd1-153a-7d8b-ade73cba0289@oracle.com> On 7/17/19 11:37 AM, Igor Ignatyev wrote: > > Hi Severin, > > the updated webrev looks good to me, please see a couple comments below. > > Cheers, > -- Igor > >> On Jul 17, 2019, at 10:34 AM, Severin Gehwolf > > wrote: >> >> Hi Misha, >> >> On Wed, 2019-07-17 at 10:22 -0700,mikhailo.seledtsov at oracle.com >> wrote: >>> Hi Severin, >>> >>> On 7/17/19 5:44 AM, Severin Gehwolf wrote: >>>> Hi Igor, Misha, >>>> >>>> On Tue, 2019-07-16 at 11:49 -0700, Igor Ignatyev wrote: >>>>> Hi Severin, >>>>> >>>>> I don't think that tests (or test libraries for that matter) should >>>>> be responsible for setting correct PATH value, it should be a part of >>>>> host configuration procedure (tests can/should check that all >>>>> required bins are available though). in other words, I'd prefer if >>>>> you remove 'env.put("PATH", ...)' lines from both DockerTestUtils and >>>>> TestJFREvents. the rest looks good to me. >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227642/02/webrev/ >>>> >>>> No more additions to PATH are being done. >>>> >>>> I've discovered that VMProps.java which defines "docker.required", used >>>> the "docker" binary even for podman test runs. This ended up not >>>> running most of the tests even with -Djdk.test.docker.command=podman >>>> specified. >>> Good catch. > should we rename docker.support and DOCKER_COMMAND to something more > abstract? Now that more container technologies are coming online we could consider more generic names for these properties/variables. Here are some thoughts: ? - container.support (CONTAINER_COMMAND) - may be too generic ? - linux.container.support (LINUX_CONTAINER_COMMAND) - more narrow ? - even more narrow/specific: oci.container.support (OCI_CONTAINER_COMMAND) ???? OCI in this case is " Open Container Initiative", ( Linux Foundation project to design open standards for Linux Container technology) ???? I believe both Docker and Podman are OCI compliant. However, I would recommend to do this work as part of a new RFE. If we agree, I will create an RFE, and we can continue discussion in the context of that RFE. Thank you, Misha > >>>> I've fixed that by moving DOCKER_COMMAND to Platform.java so >>>> that it can be used in both places. >>> >>> Sounds good to me. >>> >>> (of course, the alternative would be to import >>> jdk.test.lib.containers.docker.DockerTestUtils into VMProps.java -- not >>> sure if there are any potential problems doing it this way) >> >> I've tried that but for some reason this was a problem and VMProps >> failed to compile. I don't know exactly how those jtreg extensions work >> and went with the Platform approach. Hope that's OK. > > all files needed for VMProps (or other @requires expression class) > have to be listed in requires.extraPropDefns or > requires.extraPropDefns.bootlibs property in TEST.ROOT file in all the > test suites which use?these extensions. we are trying to be very > cautious in what is used by VMProps (directly and indirectly) so these > lists won't grow and we won't require any modules other than > java.base, given?DockerTestUtils has dependencies on a number of other > library classes, the Platform approach is much better from that point > of view. > >> >>>> Testing: Container tests with docker daemon running on Linux x86_64, >>>> container tests without docker daemon running (podman is daemon-less) >>>> via the podman binary on Linux x86_64 (with -e:PATH). All pass. >>> >>> Sounds good. >>> >>> >>> Overall looks good to me. >> >> Thanks for the review! >> >>> One minor nit: DockerTestUtils.java does not need "import >>> java.util.Map;" (no need to post updated webrev for this change) >> >> OK, good catch. Fixed locally. >> >> Thanks, >> Severin >> >>> >>> Thank you, >>> >>> Misha >>> >>>> More thoughts? >>>> >>>> Thanks, >>>> Severin >>>> >>>>> Thanks, >>>>> -- Igor >>>>> >>>>>> On Jul 16, 2019, at 5:36 AM, Severin Gehwolf >>>>> > wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I believe I still need a *R*eviewer for this. Any takers? >>>>>> >>>>>> Thanks, >>>>>> Severin >>>>>> >>>>>> On Fri, 2019-07-12 at 15:19 -0700, mikhailo.seledtsov at oracle.com >>>>>> wrote: >>>>>>> Hi Severin, >>>>>>> >>>>>>> ??The change looks good to me. Thank you for adding support for >>>>>>> Podman >>>>>>> container technology. >>>>>>> >>>>>>> Testing: I ran both HotSpot and JDK container tests with your patch; >>>>>>> tests executed on Oracle Linux 7.6 using default container >>>>>>> engine (Docker): >>>>>>> >>>>>>> ????test/hotspot/jtreg/containers/ ??AND >>>>>>> test/jdk/jdk/internal/platform/docker/ >>>>>>> >>>>>>> All PASS >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Misha >>>>>>> >>>>>>> >>>>>>> On 7/12/19 11:08 AM, Severin Gehwolf wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> There is an alternative container engine which is being used by >>>>>>>> Fedora >>>>>>>> and RHEL 8, called podman[1]. It's mostly compatible with >>>>>>>> docker. It >>>>>>>> looks like OpenJDK docker tests can be made podman compatible >>>>>>>> with a >>>>>>>> few little tweaks. One "interesting" one is to not assert >>>>>>>> "Successfully >>>>>>>> built" in the build output but only rely on the exit code, >>>>>>>> which seems >>>>>>>> to be OK for my testing. Interestingly the test would be skipped in >>>>>>>> that case. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8227642 >>>>>>>> webrev: >>>>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227642/01/webrev/ >>>>>>>> >>>>>>>> Adjustments I've done: >>>>>>>> ?* Don't assert "Successfully built" in image build output[2]. >>>>>>>> ?* Add /usr/sbin to PATH as the podman binary relies on >>>>>>>> iptables for it >>>>>>>> ???to work which is in /usr/sbin on Fedora >>>>>>>> ?* Allow for Metrics.getCpuSystemUsage() and >>>>>>>> Metrics.getCpuUserUsage() >>>>>>>> ???to be equal to the previous value. I've found those counters >>>>>>>> to be >>>>>>>> ???slowly increasing, which made the tests unreliable. >>>>>>>> >>>>>>>> Testing: >>>>>>>> >>>>>>>> Running docker tests with docker as engine. Did the same with >>>>>>>> podman as >>>>>>>> engine via -Djdk.test.docker.command=podman on Linux x86_64. Both >>>>>>>> passed (non-trivially). >>>>>>>> >>>>>>>> Thoughts? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Severin >>>>>>>> >>>>>>>> [1] https://podman.io/ >>>>>>>> [2] Image builds with podman look >>>>>>>> ????like ("COMMIT" over "Successfully built"): >>>>>>>> STEP 1: FROM fedora:29 >>>>>>>> STEP 2: RUN dnf install -y java-11-openjdk-devel && ????dnf >>>>>>>> clean all >>>>>>>> --> Using cache >>>>>>>> 96f8b1a0dfe7dba581a64fc67a27002ddf52e032af55f9ddc765182a690afd9d >>>>>>>> STEP 3: COPY TestMetrics.class ?TestMetrics.java /opt/ >>>>>>>> 269042160f7a4e6a06789cd19640ea658a8f941bc53de0fd40a574dc3bdb49a8 >>>>>>>> STEP 4: CMD /usr/lib/jvm/java-11-openjdk/bin/java -cp /opt >>>>>>>> --add-modules java.base --add-exports >>>>>>>> java.base/jdk.internal.platform=ALL-UNNAMED TestMetrics >>>>>>>> STEP 5: COMMIT fedora-metrics-11 >>>>>>>> d749088d6ce4510f212820ad4eca55a9b05e5c5c245f2372b6cfe91926e8cd7e > From igor.ignatyev at oracle.com Thu Jul 18 01:45:10 2019 From: igor.ignatyev at oracle.com (Igor Ignatev) Date: Wed, 17 Jul 2019 18:45:10 -0700 Subject: RFR: 8227642: [TESTBUG] Make docker tests podman compatible In-Reply-To: <4899d2fa-bfd1-153a-7d8b-ade73cba0289@oracle.com> References: <32c8a1934bf07e4c9c6a961e60dcb7abd9931fe1.camel@redhat.com> <5bc3ac00-6ac9-99aa-052d-0a4aa6b04f8f@oracle.com> <47390A32-BD5B-4FF3-B93B-69ACECBC3E78@oracle.com> <243091d0e29604851d100b94d5ad777d9cf59127.camel@redhat.com> <60f8f5a9003dd199f2384360c16032d21c881dbb.camel@redhat.com> <4899d2fa-bfd1-153a-7d8b-ade73cba0289@oracle.com> Message-ID: <39875294-AD67-4255-9E52-792A31A4F233@oracle.com> We definitely should do it as a separate RFE, I meant to write it in my email, but was interrupted by a fire drill, and forgot about it when returned. ? Igor > On Jul 17, 2019, at 6:38 PM, mikhailo.seledtsov at oracle.com wrote: > > However, I would recommend to do this work as part of a new RFE. If we agree, I will create an RFE, and we can continue discussion in the context of that RFE. > From mikhailo.seledtsov at oracle.com Thu Jul 18 01:58:51 2019 From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com) Date: Wed, 17 Jul 2019 18:58:51 -0700 Subject: RFR: 8227642: [TESTBUG] Make docker tests podman compatible In-Reply-To: <39875294-AD67-4255-9E52-792A31A4F233@oracle.com> References: <32c8a1934bf07e4c9c6a961e60dcb7abd9931fe1.camel@redhat.com> <5bc3ac00-6ac9-99aa-052d-0a4aa6b04f8f@oracle.com> <47390A32-BD5B-4FF3-B93B-69ACECBC3E78@oracle.com> <243091d0e29604851d100b94d5ad777d9cf59127.camel@redhat.com> <60f8f5a9003dd199f2384360c16032d21c881dbb.camel@redhat.com> <4899d2fa-bfd1-153a-7d8b-ade73cba0289@oracle.com> <39875294-AD67-4255-9E52-792A31A4F233@oracle.com> Message-ID: <636b3321-f04d-b537-6d24-c4b3a17c37f0@oracle.com> Sounds good, Thank you, Misha On 7/17/19 6:45 PM, Igor Ignatev wrote: > We definitely should do it as a separate RFE, I meant to write it in > my email, but was interrupted by a fire drill, and forgot about it > when returned. > > ? Igor > > On Jul 17, 2019, at 6:38 PM, mikhailo.seledtsov at oracle.com > wrote: > >> However, I would recommend to do this work as part of a new RFE. If >> we agree, I will create an RFE, and we can continue discussion in the >> context of that RFE. >> From david.holmes at oracle.com Thu Jul 18 04:26:09 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 18 Jul 2019 14:26:09 +1000 Subject: RFR: JDK-8227831: Avoid using volatile for write-once, read-many class field In-Reply-To: <38d9abc4-71c6-c26d-f820-7845c5d375bd@oracle.com> References: <38d9abc4-71c6-c26d-f820-7845c5d375bd@oracle.com> Message-ID: <10d1ff61-cd7f-00f9-15da-189f63c1f35a@oracle.com> Hi Claes, On 18/07/2019 1:04 am, Claes Redestad wrote: > Hi, > > removing volatile aligns LangReflectAccess initialization with the > pattern used for other access objects: it's only initialized in the > static initializer of some class which we ensure is initialized, which > means any initialization race is guarded by the initialization of said > class - in this case j.l.r.Modifier. If the field is not volatile then we are not guaranteed to correctly see the constructed LangReflectAccess instance. Without volatile (or without additional use of unconditional sync in the accessor) we do not have a happens-before relationship between the construction of the LRA instance, and the setting of the field. > Initialization of other access objects are not guarded by any > explicit synchronization, however, since similar load/store barriers > will be in effect by ensuring the class that constructs the object has > been initialized. So I think you could remove the explicit > synchronization. We are not guaranteed to hit the class initialization checks that would guarantee the necessary ordering. David ----- > I'm not sure why LangReflectAccess has not moved in with other > SharedSecrets. Perhaps this is just an artefact of having been around > for a long time, but maybe that'd cause some cyclic bootstrap > dependency. Either way it's nice to see it align to use the same > pattern. > > Thanks! > /Claes > > On 2019-07-17 10:00, Kazunori Ogata wrote: >> Hi Aleskey, >> >> Thank you for your comment. >> >> I forgot to mention one thing.? I verified that all accesses to >> langReflectioAccess calls the accessor "langReflectAccess()".? Since this >> variable is modified once from null to non-null, I think the write in the >> setter is guaranteed to be visible in the getter by putting the >> synchronized block in langReflectAccess(). >> >> Should I put comments about this assumption?? Actually, in JDK11 there >> are >> some lines that do not call the getter, so backport needs to fix them, >> too. >> >> >> Regards, >> Ogata >> >> >> Aleksey Shipilev wrote on 2019/07/17 16:49:08: >> >>> From: Aleksey Shipilev >>> To: Kazunori Ogata , core-libs-dev at openjdk.java.net >>> Date: 2019/07/17 16:49 >>> Subject: [EXTERNAL] Re: RFR: JDK-8227831: Avoid using volatile for >> write- >>> once, read-many class field >>> >>> On 7/17/19 8:48 AM, Kazunori Ogata wrote: >>>> Webrev: http://cr.openjdk.java.net/~ogatak/8227831/webrev/ >>> >>> Note this is generally not safe: it introduces data race on >>> langReflectAccess field access. It has >>> to be proved that everything that implements LangReflectAccess interface >> >>> makes this data race >>> benign: e.g. all fields that are accessed via those implementation are >>> final, read once, etc. And >>> briefly looking at that, I am not sure it is the case for the actual >>> accessor generators. >>> >>> I'd cautiously leave "volatile" here. >>> >>> -- >>> Thanks, >>> -Aleksey >>> >>> [attachment "signature.asc" deleted by Kazunori Ogata/Japan/IBM] >> From dmitry.chuyko at bell-sw.com Thu Jul 18 06:08:55 2019 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Thu, 18 Jul 2019 09:08:55 +0300 Subject: RFR (S): JDK-8222778: Packaging Tool (JEP 343) on Linux/AArch64 In-Reply-To: <234f1c54-bd2a-c90b-367b-e279062218ff@bell-sw.com> References: <234f1c54-bd2a-c90b-367b-e279062218ff@bell-sw.com> Message-ID: On 7/18/19 12:19 AM, Dmitry Chuyko wrote: > .................. >>> 2. LinuxDebBundler.getArch() now maps only x86_64 to amd64, x86 is >>> still >>> mapped to i386, and other archs map to themselves. >>> >>> 3. In tests, new method getRpmArch() was added to linux/base/Base.java, >>> it maps JVMs os.arch to default rpmbuild arch. Multiple tests were >>> modified to use that method instead of "x86_64" in rpm file name. Some >>> timeouts were increased. >> +??????? if ("arm".equals(arch)) >> +??????????? return "armv7hl"; >> >> Is this actually correct? How do you know it's not, say, armv7hf? I >> would >> have thought there must be some better way to get the RPM arch. Isn't >> running /bin/arch right on your systems? > > Using $(arch) is an interesting question. For now implementation > decides what kind of bundle to create looking at JVM binary arch. This > should guarantee that the bundle will fit the same arch of host and > some compatible architectures (app will be be installable and > runnable). And it also mean current tests may fail if host and VM > archs are different (because packages won't be found while may be > created and may be working). > > 'arvmv7hl' is a common build environment/target for arm port and looks > like a compatible option. We may look into VM binary metadata though > to get exact build arch. > Currently jpackage relies on underlying tool defaults at the host. rpmbuild makes difference, so then arch is armv7l packages may be for example armv7hl. In tests exact rpm arch can be determined using cpu flags or the tool itself. So we can add a bit of rpmbuild logic in getRpmArch(), it actually can be made by getting _target_cpu from rpmbuild. -Dmitry > > >> From aph at redhat.com Thu Jul 18 08:57:22 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 18 Jul 2019 09:57:22 +0100 Subject: RFR (S): JDK-8222778: Packaging Tool (JEP 343) on Linux/AArch64 In-Reply-To: <234f1c54-bd2a-c90b-367b-e279062218ff@bell-sw.com> References: <234f1c54-bd2a-c90b-367b-e279062218ff@bell-sw.com> Message-ID: Hi, On 7/17/19 10:19 PM, Dmitry Chuyko wrote: > > On 7/17/19 11:52 AM, Andrew Haley wrote: >> This is weird: >> >> --- old/src/jdk.jpackage/linux/native/libapplauncher/LinuxPlatform.cpp 2019-07-16 22:11:30.200258978 +0300 >> +++ new/src/jdk.jpackage/linux/native/libapplauncher/LinuxPlatform.cpp 2019-07-16 22:11:29.867374851 +0300 >> @@ -127,7 +127,7 @@ >> } >> >> void LinuxPlatform::SetCurrentDirectory(TString Value) { >> - chdir(PlatformString(Value).toPlatformString()); >> + int ignored = chdir(PlatformString(Value).toPlatformString()); >> } >> >> Firstly it does not fix the problem: you've gone from an unused value to an >> unused variable. Secondly, we ignore the return value of printf all the time; >> what's different about this one? > > chdir() is __wur, which is /usr/include/aarch64-linux-gnu/sys/cdefs.h:#? > define __wur __attribute_warn_unused_result__ OK, got it. > In some places this warning is disabled (CoreLibraries.gmk, > Awt2dLibraries.gmk). > > It would be more correct to handle the result here as chdir might not > succeeded in fact. Very much so. We shouldn't try to "shut up the compiler" in this way. > 'arvmv7hl' is a common build environment/target for arm port and looks > like a compatible option. We may look into VM binary metadata though to > get exact build arch. That would be wise. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From milan.mimica at gmail.com Thu Jul 18 09:16:29 2019 From: milan.mimica at gmail.com (Milan Mimica) Date: Thu, 18 Jul 2019 11:16:29 +0200 Subject: DnsClient TCP socket timeout Message-ID: Hello list Have you ever considered the problem reported here: https://stackoverflow.com/questions/14603553/dns-query-freezes-with-dnscontextfactory-in-java A DNS query gets stuck easily if read timeout is not set on the socket. The proposed solution is trivial. I can author the change, if I can have it sponsored. -- Milan Mimica From chris.hegarty at oracle.com Thu Jul 18 09:23:33 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 18 Jul 2019 10:23:33 +0100 Subject: DnsClient TCP socket timeout In-Reply-To: References: Message-ID: <28555AB2-8015-4423-8CD9-BDE2298BD920@oracle.com> > On 18 Jul 2019, at 10:16, Milan Mimica wrote: > > Hello list > > Have you ever considered the problem reported here: > https://stackoverflow.com/questions/14603553/dns-query-freezes-with-dnscontextfactory-in-java I posted a comment on that SO thread yesterday, no reply since. -Chris From milan.mimica at gmail.com Thu Jul 18 09:32:42 2019 From: milan.mimica at gmail.com (Milan Mimica) Date: Thu, 18 Jul 2019 11:32:42 +0200 Subject: DnsClient TCP socket timeout In-Reply-To: <28555AB2-8015-4423-8CD9-BDE2298BD920@oracle.com> References: <28555AB2-8015-4423-8CD9-BDE2298BD920@oracle.com> Message-ID: On Thu, 18 Jul 2019 at 11:23, Chris Hegarty wrote: > > Have you ever considered the problem reported here: > > https://stackoverflow.com/questions/14603553/dns-query-freezes-with-dnscontextfactory-in-java > > I posted a comment on that SO thread yesterday, no reply since. Hi Chris This exception must have been thrown from DatagramSocket::receive(DatagramPacket p), not from TCP socket. So it does not cover the case when TCP socket gets stuck, in the fallback flow for truncated UDP responses. -- Milan Mimica From milan.mimica at gmail.com Thu Jul 18 09:35:45 2019 From: milan.mimica at gmail.com (Milan Mimica) Date: Thu, 18 Jul 2019 11:35:45 +0200 Subject: DnsClient TCP socket timeout In-Reply-To: References: <28555AB2-8015-4423-8CD9-BDE2298BD920@oracle.com> Message-ID: Stack trace for reference: java.net.SocketInputStream.socketRead0 line: not available [native method] java.net.SocketInputStream.read line: 150 java.net.SocketInputStream.read line: 121 java.io.BufferedInputStream.fill line: 246 java.io.BufferedInputStream.read line: 265 com.sun.jndi.dns.DnsClient.continueTcpQuery line: 455 com.sun.jndi.dns.DnsClient.doTcpQuery line: 443 com.sun.jndi.dns.DnsClient.query line: 245 com.sun.jndi.dns.Resolver.query line: 81 com.sun.jndi.dns.DnsContext.c_getAttributes line: 434 com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes line: 235 com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes line: 141 com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes line: 129 javax.naming.directory.InitialDirContext.getAttributes line: 142 On Thu, 18 Jul 2019 at 11:32, Milan Mimica wrote: > > On Thu, 18 Jul 2019 at 11:23, Chris Hegarty wrote: > > > Have you ever considered the problem reported here: > > > https://stackoverflow.com/questions/14603553/dns-query-freezes-with-dnscontextfactory-in-java > > > > I posted a comment on that SO thread yesterday, no reply since. > > Hi Chris > > This exception must have been thrown from > DatagramSocket::receive(DatagramPacket p), not from TCP socket. So it > does not cover the case when TCP socket gets stuck, in the fallback > flow for truncated UDP responses. > > > -- > Milan Mimica -- Milan Mimica From claes.redestad at oracle.com Thu Jul 18 09:53:00 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 18 Jul 2019 11:53:00 +0200 Subject: RFR: JDK-8227831: Avoid using volatile for write-once, read-many class field In-Reply-To: <10d1ff61-cd7f-00f9-15da-189f63c1f35a@oracle.com> References: <38d9abc4-71c6-c26d-f820-7845c5d375bd@oracle.com> <10d1ff61-cd7f-00f9-15da-189f63c1f35a@oracle.com> Message-ID: Hi David, On 2019-07-18 06:26, David Holmes wrote: > Hi Claes, > > On 18/07/2019 1:04 am, Claes Redestad wrote: >> Hi, >> >> removing volatile aligns LangReflectAccess initialization with the >> pattern used for other access objects: it's only initialized in the >> static initializer of some class which we ensure is initialized, which >> means any initialization race is guarded by the initialization of said >> class - in this case j.l.r.Modifier. > > If the field is not volatile then we are not guaranteed to correctly see > the constructed LangReflectAccess instance. Without volatile (or without > additional use of unconditional sync in the accessor) we do not have a > happens-before relationship between the construction of the LRA > instance, and the setting of the field > >> Initialization of other access objects are not guarded by any >> explicit synchronization, however, since similar load/store barriers >> will be in effect by ensuring the class that constructs the object has >> been initialized. So I think you could remove the explicit >> synchronization. > > We are not guaranteed to hit the class initialization checks that would > guarantee the necessary ordering. You better not look at the existing code in jdk.internal.access.SharedSecrets :-) Would the unsafe.ensureClassInitialized(..) pattern used there bring stronger guarantees? That would be the pattern I'm suggesting the code under review here to align with. And for the record none of the *Access objects carry state and are strictly delegating to either static methods/constructors or instance methods on their arguments. /Claes > > David > ----- > >> I'm not sure why LangReflectAccess has not moved in with other >> SharedSecrets. Perhaps this is just an artefact of having been around >> for a long time, but maybe that'd cause some cyclic bootstrap >> dependency. Either way it's nice to see it align to use the same >> pattern. >> >> Thanks! >> /Claes >> >> On 2019-07-17 10:00, Kazunori Ogata wrote: >>> Hi Aleskey, >>> >>> Thank you for your comment. >>> >>> I forgot to mention one thing.? I verified that all accesses to >>> langReflectioAccess calls the accessor "langReflectAccess()".? Since >>> this >>> variable is modified once from null to non-null, I think the write in >>> the >>> setter is guaranteed to be visible in the getter by putting the >>> synchronized block in langReflectAccess(). >>> >>> Should I put comments about this assumption?? Actually, in JDK11 >>> there are >>> some lines that do not call the getter, so backport needs to fix them, >>> too. >>> >>> >>> Regards, >>> Ogata >>> >>> >>> Aleksey Shipilev wrote on 2019/07/17 16:49:08: >>> >>>> From: Aleksey Shipilev >>>> To: Kazunori Ogata , core-libs-dev at openjdk.java.net >>>> Date: 2019/07/17 16:49 >>>> Subject: [EXTERNAL] Re: RFR: JDK-8227831: Avoid using volatile for >>> write- >>>> once, read-many class field >>>> >>>> On 7/17/19 8:48 AM, Kazunori Ogata wrote: >>>>> Webrev: http://cr.openjdk.java.net/~ogatak/8227831/webrev/ >>>> >>>> Note this is generally not safe: it introduces data race on >>>> langReflectAccess field access. It has >>>> to be proved that everything that implements LangReflectAccess >>>> interface >>> >>>> makes this data race >>>> benign: e.g. all fields that are accessed via those implementation are >>>> final, read once, etc. And >>>> briefly looking at that, I am not sure it is the case for the actual >>>> accessor generators. >>>> >>>> I'd cautiously leave "volatile" here. >>>> >>>> -- >>>> Thanks, >>>> -Aleksey >>>> >>>> [attachment "signature.asc" deleted by Kazunori Ogata/Japan/IBM] >>> From chris.hegarty at oracle.com Thu Jul 18 11:11:09 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 18 Jul 2019 12:11:09 +0100 Subject: DnsClient TCP socket timeout In-Reply-To: References: <28555AB2-8015-4423-8CD9-BDE2298BD920@oracle.com> Message-ID: <0F6D84BD-B90D-43F3-8AD9-EC62BE1DC069@oracle.com> Milan, You could be right, I?d need to look into the code a little more. It was not clear to me, from either your post or SO, that the issue only occurs when falling back to TCP. -Chris. > On 18 Jul 2019, at 10:35, Milan Mimica wrote: > > Stack trace for reference: > java.net.SocketInputStream.socketRead0 line: not available [native method] > java.net.SocketInputStream.read line: 150 > java.net.SocketInputStream.read line: 121 > java.io.BufferedInputStream.fill line: 246 > java.io.BufferedInputStream.read line: 265 > com.sun.jndi.dns.DnsClient.continueTcpQuery line: 455 > com.sun.jndi.dns.DnsClient.doTcpQuery line: 443 > com.sun.jndi.dns.DnsClient.query line: 245 > com.sun.jndi.dns.Resolver.query line: 81 > com.sun.jndi.dns.DnsContext.c_getAttributes line: 434 > com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes line: 235 > com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes line: 141 > com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes line: 129 > javax.naming.directory.InitialDirContext.getAttributes line: 142 > > On Thu, 18 Jul 2019 at 11:32, Milan Mimica wrote: >> >> On Thu, 18 Jul 2019 at 11:23, Chris Hegarty wrote: >>>> Have you ever considered the problem reported here: >>>> https://stackoverflow.com/questions/14603553/dns-query-freezes-with-dnscontextfactory-in-java >>> >>> I posted a comment on that SO thread yesterday, no reply since. >> >> Hi Chris >> >> This exception must have been thrown from >> DatagramSocket::receive(DatagramPacket p), not from TCP socket. So it >> does not cover the case when TCP socket gets stuck, in the fallback >> flow for truncated UDP responses. >> >> >> -- >> Milan Mimica > > > > -- > Milan Mimica From sgehwolf at redhat.com Thu Jul 18 15:14:47 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 18 Jul 2019 17:14:47 +0200 Subject: RFR: 8227642: [TESTBUG] Make docker tests podman compatible In-Reply-To: References: <32c8a1934bf07e4c9c6a961e60dcb7abd9931fe1.camel@redhat.com> <5bc3ac00-6ac9-99aa-052d-0a4aa6b04f8f@oracle.com> <47390A32-BD5B-4FF3-B93B-69ACECBC3E78@oracle.com> <243091d0e29604851d100b94d5ad777d9cf59127.camel@redhat.com> <60f8f5a9003dd199f2384360c16032d21c881dbb.camel@redhat.com> Message-ID: <0147c2dfb1fec34bce4128ec8af2ca5fc725d79c.camel@redhat.com> Hi Igor, On Wed, 2019-07-17 at 11:37 -0700, Igor Ignatyev wrote: > > Hi Severin, > > the updated webrev looks good to me, please see a couple comments below. Thanks. More below. > Cheers, > -- Igor > > > On Jul 17, 2019, at 10:34 AM, Severin Gehwolf wrote: > > > > Hi Misha, > > > > On Wed, 2019-07-17 at 10:22 -0700, mikhailo.seledtsov at oracle.com wrote: > > > Hi Severin, > > > > > > On 7/17/19 5:44 AM, Severin Gehwolf wrote: > > > > Hi Igor, Misha, > > > > > > > > On Tue, 2019-07-16 at 11:49 -0700, Igor Ignatyev wrote: > > > > > Hi Severin, > > > > > > > > > > I don't think that tests (or test libraries for that matter) should > > > > > be responsible for setting correct PATH value, it should be a part of > > > > > host configuration procedure (tests can/should check that all > > > > > required bins are available though). in other words, I'd prefer if > > > > > you remove 'env.put("PATH", ...)' lines from both DockerTestUtils and > > > > > TestJFREvents. the rest looks good to me. > > > > Updated webrev: > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227642/02/webrev/ > > > > > > > > No more additions to PATH are being done. > > > > > > > > I've discovered that VMProps.java which defines "docker.required", used > > > > the "docker" binary even for podman test runs. This ended up not > > > > running most of the tests even with -Djdk.test.docker.command=podman > > > > specified. > > > Good catch. > should we rename docker.support and DOCKER_COMMAND to something more abstract? container.support and CONTAINER_ENGINE_COMMAND perhaps? > > > > I've fixed that by moving DOCKER_COMMAND to Platform.java so > > > > that it can be used in both places. > > > > > > Sounds good to me. > > > > > > (of course, the alternative would be to import > > > jdk.test.lib.containers.docker.DockerTestUtils into VMProps.java -- not > > > sure if there are any potential problems doing it this way) > > > > I've tried that but for some reason this was a problem and VMProps > > failed to compile. I don't know exactly how those jtreg extensions work > > and went with the Platform approach. Hope that's OK. > > all files needed for VMProps (or other @requires expression class) > have to be listed in requires.extraPropDefns or > requires.extraPropDefns.bootlibs property in TEST.ROOT file in all > the test suites which use these extensions. we are trying to be very > cautious in what is used by VMProps (directly and indirectly) so > these lists won't grow and we won't require any modules other than > java.base, given DockerTestUtils has dependencies on a number of > other library classes, the Platform approach is much better from that > point of view. I had a feeling it was something like that. Thanks for the explanation! Cheers, Severin From brian.burkhalter at oracle.com Thu Jul 18 15:32:36 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 18 Jul 2019 08:32:36 -0700 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: <91BF9F6F-5969-40AF-8E51-92D5E045F6D9@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> Message-ID: <532398EA-B7F8-4803-A038-A0F54DCD460F@oracle.com> Resuming this topic, what is the general view on the three possible paths: 1. Override write(byte[]) at the risk of incompatibility. 2. Instead add writeBytes(byte[]) as in ByteArrayOutputStream. 3. Resolve as Won?t Fix. For 2 or 3 the incorrect class level statement about overriding all methods not to throw IOE would need to be dealt with. Thanks, Brian > On Jul 15, 2019, at 1:07 PM, Brian Burkhalter wrote: > > There is however this problematic statement in the PrintStream class doc that neither of the two alternative versions of the fix addresses: > > "Two other features are provided as well. Unlike other output streams, a PrintStream never throws an IOException; instead, exceptional situations merely set an internal flag that can be tested via the checkError method.? > > In both cases this would need to be changed as it is incorrect. > > Brian > >> On Jul 15, 2019, at 10:14 AM, Brian Burkhalter > wrote: >> >> Here is an alternative version which adds a writeBytes(byte[]) method instead of overriding write(byte[]): >> >> http://cr.openjdk.java.net/~bpb/8187898/webrev-alt.00/ > >> >> This has the advantage of allowing new code to call writeBytes() without a try-catch block without introducing a compatibility issue for code which is already calling write(byte[]) in a try-catch block. From Alan.Bateman at oracle.com Thu Jul 18 15:52:19 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 18 Jul 2019 16:52:19 +0100 Subject: 8067801: Enforce null check for underlying I/O streams In-Reply-To: References: Message-ID: <0ef53258-4434-e534-3519-100532bfd266@oracle.com> On 17/07/2019 17:12, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8067801 > http://cr.openjdk.java.net/~bpb/8067801/webrev.00/ > > Add null check to Filter{In,Out}putStream constructors. This covers all the cases listed in the issue as those are all subclasses of these two classes. No javadoc update is need due to this statement in the java.io package doc: > > "Unless otherwise noted, passing a null argument to a constructor or method in any class or interface in this package will cause a NullPointerException to be thrown." > > I see this is has pushed but I think it will need to be re-examined because the javadoc allows `in` and `out` to be specified as null and set after the stream is created (the javadoc for the parameters overrides the "Unless otherwise ..." text in the package description). -Alan From brian.burkhalter at oracle.com Thu Jul 18 15:55:46 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 18 Jul 2019 08:55:46 -0700 Subject: 8067801: Enforce null check for underlying I/O streams In-Reply-To: <0ef53258-4434-e534-3519-100532bfd266@oracle.com> References: <0ef53258-4434-e534-3519-100532bfd266@oracle.com> Message-ID: <0A8FD7A1-3DA7-41DD-B965-4181ED9EA711@oracle.com> > On Jul 18, 2019, at 8:52 AM, Alan Bateman wrote: > > On 17/07/2019 17:12, Brian Burkhalter wrote: >> https://bugs.openjdk.java.net/browse/JDK-8067801 >> http://cr.openjdk.java.net/~bpb/8067801/webrev.00/ >> >> Add null check to Filter{In,Out}putStream constructors. This covers all the cases listed in the issue as those are all subclasses of these two classes. No javadoc update is need due to this statement in the java.io package doc: >> >> "Unless otherwise noted, passing a null argument to a constructor or method in any class or interface in this package will cause a NullPointerException to be thrown." >> >> > I see this is has pushed but I think it will need to be re-examined because the javadoc allows `in` and `out` to be specified as null and set after the stream is created (the javadoc for the parameters overrides the "Unless otherwise ..." text in the package description) Argh. I guess you are correct. Brian From brian.burkhalter at oracle.com Thu Jul 18 16:21:03 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 18 Jul 2019 09:21:03 -0700 Subject: 8067801: Enforce null check for underlying I/O streams In-Reply-To: <0A8FD7A1-3DA7-41DD-B965-4181ED9EA711@oracle.com> References: <0ef53258-4434-e534-3519-100532bfd266@oracle.com> <0A8FD7A1-3DA7-41DD-B965-4181ED9EA711@oracle.com> Message-ID: <1D497875-23BA-4B84-BA40-6DE3AE095749@oracle.com> > On Jul 18, 2019, at 8:55 AM, Brian Burkhalter wrote: > >> I see this is has pushed but I think it will need to be re-examined because the javadoc allows `in` and `out` to be specified as null and set after the stream is created (the javadoc for the parameters overrides the "Unless otherwise ..." text in the package description) > > Argh. I guess you are correct. Filed https://bugs.openjdk.java.net/browse/JDK-8228392 . Brian From huizhe.wang at oracle.com Thu Jul 18 17:40:45 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 18 Jul 2019 10:40:45 -0700 Subject: RFR [14/java.xml] 8157830: Errors in XSLT stylesheet are not dispatched correctly to ErrorListener Message-ID: <3e879ac9-f1c1-49f1-b454-cc5e0d742754@oracle.com> Please review a patch to eliminate the [Fatal Error] message printed out to the console. Whether the parser should have written the error out in the first place is up to debate, not covered in this patch, but when the request is for the Transformer to handle errors through a registered ErrorListener, all errors should have been passed onto the ErrorListener. The fix is to set a proxy handler to the parser that simply hands the errors over to the Transformer's ErrorListener. JBS: https://bugs.openjdk.java.net/browse/JDK-8157830 webrev: http://cr.openjdk.java.net/~joehw/jdk14/8157830/webrev/ Thanks, Joe From mandy.chung at oracle.com Thu Jul 18 17:58:50 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 18 Jul 2019 10:58:50 -0700 Subject: RFR: JDK-8227831: Avoid using volatile for write-once, read-many class field In-Reply-To: References: <38d9abc4-71c6-c26d-f820-7845c5d375bd@oracle.com> <10d1ff61-cd7f-00f9-15da-189f63c1f35a@oracle.com> Message-ID: <4b453fbb-da83-3566-5005-60567dfe9c7c@oracle.com> JDK-8219774 is relevant to this patch (this was discussed in the code review for JDK-8219378: NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized). This cleans up the initialization of LangReflectAccess: ?? http://cr.openjdk.java.net/~mchung/jdk14/8219774/webrev.00/ I moved LangReflectAccess to jdk.internal.access to be consistent with other *Access classes (LangReflectAccess was added before the common SharedSecrets class was introduced).?? AccessibleObject was initialized early during startup and this patch causes initializing SharedSecret and LangReflectAccess earlier.? This is not an official review for JDK-8219774 but I'm interested if this improves the performance comparing with Ogata's patch. Ogato - can you help running the micro benchmark you have with the patch for JDK-8219774? thanks Mandy On 7/18/19 2:53 AM, Claes Redestad wrote: > Hi David, > > On 2019-07-18 06:26, David Holmes wrote: >> Hi Claes, >> >> On 18/07/2019 1:04 am, Claes Redestad wrote: >>> Hi, >>> >>> removing volatile aligns LangReflectAccess initialization with the >>> pattern used for other access objects: it's only initialized in the >>> static initializer of some class which we ensure is initialized, which >>> means any initialization race is guarded by the initialization of said >>> class - in this case j.l.r.Modifier. >> >> If the field is not volatile then we are not guaranteed to correctly >> see the constructed LangReflectAccess instance. Without volatile (or >> without additional use of unconditional sync in the accessor) we do >> not have a happens-before relationship between the construction of >> the LRA instance, and the setting of the field > >>> Initialization of other access objects are not guarded by any >>> explicit synchronization, however, since similar load/store barriers >>> will be in effect by ensuring the class that constructs the object has >>> been initialized. So I think you could remove the explicit >>> synchronization. >> >> We are not guaranteed to hit the class initialization checks that >> would guarantee the necessary ordering. > > You better not look at the existing code in > jdk.internal.access.SharedSecrets :-) > > Would the unsafe.ensureClassInitialized(..) pattern used there bring > stronger guarantees? That would be the pattern I'm suggesting the code > under review here to align with. > > And for the record none of the *Access objects carry state and are > strictly delegating to either static methods/constructors or instance > methods on their arguments. > > /Claes > >> >> David >> ----- >> >>> I'm not sure why LangReflectAccess has not moved in with other >>> SharedSecrets. Perhaps this is just an artefact of having been around >>> for a long time, but maybe that'd cause some cyclic bootstrap >>> dependency. Either way it's nice to see it align to use the same >>> pattern. >>> >>> Thanks! >>> /Claes >>> >>> On 2019-07-17 10:00, Kazunori Ogata wrote: >>>> Hi Aleskey, >>>> >>>> Thank you for your comment. >>>> >>>> I forgot to mention one thing.? I verified that all accesses to >>>> langReflectioAccess calls the accessor "langReflectAccess()".? >>>> Since this >>>> variable is modified once from null to non-null, I think the write >>>> in the >>>> setter is guaranteed to be visible in the getter by putting the >>>> synchronized block in langReflectAccess(). >>>> >>>> Should I put comments about this assumption?? Actually, in JDK11 >>>> there are >>>> some lines that do not call the getter, so backport needs to fix them, >>>> too. >>>> >>>> >>>> Regards, >>>> Ogata >>>> >>>> >>>> Aleksey Shipilev wrote on 2019/07/17 16:49:08: >>>> >>>>> From: Aleksey Shipilev >>>>> To: Kazunori Ogata , >>>>> core-libs-dev at openjdk.java.net >>>>> Date: 2019/07/17 16:49 >>>>> Subject: [EXTERNAL] Re: RFR: JDK-8227831: Avoid using volatile for >>>> write- >>>>> once, read-many class field >>>>> >>>>> On 7/17/19 8:48 AM, Kazunori Ogata wrote: >>>>>> Webrev: http://cr.openjdk.java.net/~ogatak/8227831/webrev/ >>>>> >>>>> Note this is generally not safe: it introduces data race on >>>>> langReflectAccess field access. It has >>>>> to be proved that everything that implements LangReflectAccess >>>>> interface >>>> >>>>> makes this data race >>>>> benign: e.g. all fields that are accessed via those implementation >>>>> are >>>>> final, read once, etc. And >>>>> briefly looking at that, I am not sure it is the case for the actual >>>>> accessor generators. >>>>> >>>>> I'd cautiously leave "volatile" here. >>>>> >>>>> -- >>>>> Thanks, >>>>> -Aleksey >>>>> >>>>> [attachment "signature.asc" deleted by Kazunori Ogata/Japan/IBM] >>>> From brian.burkhalter at oracle.com Thu Jul 18 19:01:11 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 18 Jul 2019 12:01:11 -0700 Subject: 8228392: java.io.Filter{In,Out}put stream constructors should allow null stream parameter Message-ID: <55F7A3DE-BF8D-4FD3-9B4F-097AAEC406F5@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8228392 http://cr.openjdk.java.net/~bpb/8228392/webrev.00/ This moves the NPE from the Filter{In,Out}putStream constructors to the subclass constructors. One thing which should be considered as an alternative would be not to check for null at all in these constructors but update the subclass constructor specifications to override the class documentation and indicate that the underlying stream parameter may be null. This change has passed the tier 1-3 tests modulo one timeout of an unrelated tier 2 test. Thanks, Brian From lance.andersen at oracle.com Thu Jul 18 19:34:44 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 18 Jul 2019 15:34:44 -0400 Subject: 8228392: java.io.Filter{In,Out}put stream constructors should allow null stream parameter In-Reply-To: <55F7A3DE-BF8D-4FD3-9B4F-097AAEC406F5@oracle.com> References: <55F7A3DE-BF8D-4FD3-9B4F-097AAEC406F5@oracle.com> Message-ID: HI Brian, > On Jul 18, 2019, at 3:01 PM, Brian Burkhalter wrote: > > https://bugs.openjdk.java.net/browse/JDK-8228392 > http://cr.openjdk.java.net/~bpb/8228392/webrev.00/ > > This moves the NPE from the Filter{In,Out}putStream constructors to the subclass constructors. > > One thing which should be considered as an alternative would be not to check for null at all in these constructors but update the subclass constructor specifications to override the class documentation and indicate that the underlying stream parameter may be null. I think this might be the better way to go.. > > This change has passed the tier 1-3 tests modulo one timeout of an unrelated tier 2 test. > > Thanks, > > Brian 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 Jul 18 19:35:52 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 18 Jul 2019 12:35:52 -0700 Subject: 8228392: java.io.Filter{In,Out}put stream constructors should allow null stream parameter In-Reply-To: References: <55F7A3DE-BF8D-4FD3-9B4F-097AAEC406F5@oracle.com> Message-ID: <2119A209-E194-4A5C-B8B3-F13D9321795D@oracle.com> Hi Lance, > On Jul 18, 2019, at 12:34 PM, Lance Andersen wrote: > >> One thing which should be considered as an alternative would be not to check for null at all in these constructors but update the subclass constructor specifications to override the class documentation and indicate that the underlying stream parameter may be null. > > I think this might be the better way to go.. Agreed. I therefore withdraw this patch and will use this issue for the back out. Thanks, Brian From brian.burkhalter at oracle.com Thu Jul 18 20:01:20 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 18 Jul 2019 13:01:20 -0700 Subject: 8228392: java.io.Filter{In,Out}put stream constructors should allow null stream parameter In-Reply-To: <2119A209-E194-4A5C-B8B3-F13D9321795D@oracle.com> References: <55F7A3DE-BF8D-4FD3-9B4F-097AAEC406F5@oracle.com> <2119A209-E194-4A5C-B8B3-F13D9321795D@oracle.com> Message-ID: > On Jul 18, 2019, at 12:35 PM, Brian Burkhalter wrote: > >> On Jul 18, 2019, at 12:34 PM, Lance Andersen > wrote: >> >>> One thing which should be considered as an alternative would be not to check for null at all in these constructors but update the subclass constructor specifications to override the class documentation and indicate that the underlying stream parameter may be null. >> >> I think this might be the better way to go.. > > Agreed. I therefore withdraw this patch and will use this issue for the back out. A patch which backs out the java.io.Filter{In,Out}put stream constructors null underlying stream check (and consequent changes) is at [1]. A tier 1-3 test run is in progress. Thanks, Brian [1] http://cr.openjdk.java.net/~bpb/8228392/webrev.01/ From lance.andersen at oracle.com Thu Jul 18 20:25:47 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 18 Jul 2019 16:25:47 -0400 Subject: 8228392: java.io.Filter{In,Out}put stream constructors should allow null stream parameter In-Reply-To: References: <55F7A3DE-BF8D-4FD3-9B4F-097AAEC406F5@oracle.com> <2119A209-E194-4A5C-B8B3-F13D9321795D@oracle.com> Message-ID: <4BF4BC94-E1B4-47C7-AA86-5F24018C2420@oracle.com> Hi Brian, Are we having fun yet ;-) The back out looks good > On Jul 18, 2019, at 4:01 PM, Brian Burkhalter wrote: > > >> On Jul 18, 2019, at 12:35 PM, Brian Burkhalter wrote: >> >>> On Jul 18, 2019, at 12:34 PM, Lance Andersen > wrote: >>> >>>> One thing which should be considered as an alternative would be not to check for null at all in these constructors but update the subclass constructor specifications to override the class documentation and indicate that the underlying stream parameter may be null. >>> >>> I think this might be the better way to go.. >> >> Agreed. I therefore withdraw this patch and will use this issue for the back out. > > A patch which backs out the java.io.Filter{In,Out}put stream constructors null underlying stream check (and consequent changes) is at [1]. > > A tier 1-3 test run is in progress. > > Thanks, > > Brian > > [1] http://cr.openjdk.java.net/~bpb/8228392/webrev.01/ Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From lance.andersen at oracle.com Thu Jul 18 22:06:16 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 18 Jul 2019 18:06:16 -0400 Subject: RFR [14/java.xml] 8157830: Errors in XSLT stylesheet are not dispatched correctly to ErrorListener In-Reply-To: <3e879ac9-f1c1-49f1-b454-cc5e0d742754@oracle.com> References: <3e879ac9-f1c1-49f1-b454-cc5e0d742754@oracle.com> Message-ID: <4E8B8F62-0B22-4D12-8906-1B9C6FF05DF6@oracle.com> +1 > On Jul 18, 2019, at 1:40 PM, Joe Wang wrote: > > Please review a patch to eliminate the [Fatal Error] message printed out to the console. Whether the parser should have written the error out in the first place is up to debate, not covered in this patch, but when the request is for the Transformer to handle errors through a registered ErrorListener, all errors should have been passed onto the ErrorListener. > > The fix is to set a proxy handler to the parser that simply hands the errors over to the Transformer's ErrorListener. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8157830 > webrev: http://cr.openjdk.java.net/~joehw/jdk14/8157830/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 Thu Jul 18 22:39:26 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 18 Jul 2019 15:39:26 -0700 Subject: RFR [14/java.xml] 8157830: Errors in XSLT stylesheet are not dispatched correctly to ErrorListener In-Reply-To: <4E8B8F62-0B22-4D12-8906-1B9C6FF05DF6@oracle.com> References: <3e879ac9-f1c1-49f1-b454-cc5e0d742754@oracle.com> <4E8B8F62-0B22-4D12-8906-1B9C6FF05DF6@oracle.com> Message-ID: Thanks Lance! On 7/18/19 3:06 PM, Lance Andersen wrote: > +1 >> On Jul 18, 2019, at 1:40 PM, Joe Wang > > wrote: >> >> Please review a patch to eliminate the [Fatal Error] message printed >> out to the console. Whether the parser should have written the error >> out in the first place is up to debate, not covered in this patch, >> but when the request is for the Transformer to handle errors through >> a registered ErrorListener, all errors should have been passed onto >> the ErrorListener. >> >> The fix is to set a proxy handler to the parser that simply hands the >> errors over to the Transformer's ErrorListener. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8157830 >> webrev: http://cr.openjdk.java.net/~joehw/jdk14/8157830/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 dmitry.chuyko at bell-sw.com Thu Jul 18 23:36:30 2019 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Fri, 19 Jul 2019 02:36:30 +0300 Subject: RFR (S): JDK-8222778: Packaging Tool (JEP 343) on Linux/AArch64 In-Reply-To: References: <234f1c54-bd2a-c90b-367b-e279062218ff@bell-sw.com> Message-ID: <0ec8f547-8e21-7fd2-1091-886dc7a4d2b1@bell-sw.com> On 7/18/19 11:57 AM, Andrew Haley wrote: > Hi, > > On 7/17/19 10:19 PM, Dmitry Chuyko wrote: >> On 7/17/19 11:52 AM, Andrew Haley wrote: >>> This is weird: >>> >>> --- old/src/jdk.jpackage/linux/native/libapplauncher/LinuxPlatform.cpp 2019-07-16 22:11:30.200258978 +0300 >>> +++ new/src/jdk.jpackage/linux/native/libapplauncher/LinuxPlatform.cpp 2019-07-16 22:11:29.867374851 +0300 >>> @@ -127,7 +127,7 @@ >>> } >>> >>> void LinuxPlatform::SetCurrentDirectory(TString Value) { >>> - chdir(PlatformString(Value).toPlatformString()); >>> + int ignored = chdir(PlatformString(Value).toPlatformString()); >>> } >>> >>> Firstly it does not fix the problem: you've gone from an unused value to an >>> unused variable. Secondly, we ignore the return value of printf all the time; >>> what's different about this one? >> chdir() is __wur, which is /usr/include/aarch64-linux-gnu/sys/cdefs.h:# >> define __wur __attribute_warn_unused_result__ > OK, got it. > >> In some places this warning is disabled (CoreLibraries.gmk, >> Awt2dLibraries.gmk). >> >> It would be more correct to handle the result here as chdir might not >> succeeded in fact. > Very much so. We shouldn't try to "shut up the compiler" in this way.Andrew Haley I created a separate bug about chdir() and write() usages: https://bugs.openjdk.java.net/browse/JDK-8228402 Does it look good to silence warnings for platforms support changes? One more option could be to exclude related changes from current review. > >> 'arvmv7hl' is a common build environment/target for arm port and looks >> like a compatible option. We may look into VM binary metadata though to >> get exact build arch. > That would be wise. getRpmArch() now asks rpmbuild to evaluate _target_cpu macro on current test host. That allows tests to find rpms that are created by the tool as it also uses default arch. Updated webrev: http://cr.openjdk.java.net/~dchuyko/8222778/webrev.02/ -Dmitry > From igor.ignatyev at oracle.com Fri Jul 19 01:29:59 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 18 Jul 2019 18:29:59 -0700 Subject: RFR: 8227642: [TESTBUG] Make docker tests podman compatible In-Reply-To: <0147c2dfb1fec34bce4128ec8af2ca5fc725d79c.camel@redhat.com> References: <32c8a1934bf07e4c9c6a961e60dcb7abd9931fe1.camel@redhat.com> <5bc3ac00-6ac9-99aa-052d-0a4aa6b04f8f@oracle.com> <47390A32-BD5B-4FF3-B93B-69ACECBC3E78@oracle.com> <243091d0e29604851d100b94d5ad777d9cf59127.camel@redhat.com> <60f8f5a9003dd199f2384360c16032d21c881dbb.camel@redhat.com> <0147c2dfb1fec34bce4128ec8af2ca5fc725d79c.camel@redhat.com> Message-ID: <271B3583-A5E1-4562-B728-1208F4476731@oracle.com> > On Jul 18, 2019, at 8:14 AM, Severin Gehwolf wrote: > >> should we rename docker.support and DOCKER_COMMAND to something more abstract? > > container.support and CONTAINER_ENGINE_COMMAND perhaps? sounds good to me, but as Misha suggested (and I originally intended to write), let's do this renaming in a separate RFE. that's to say, you can consider 8227642 as fully reviewed. Thanks, -- Igor From OGATAK at jp.ibm.com Fri Jul 19 05:35:25 2019 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Fri, 19 Jul 2019 14:35:25 +0900 Subject: RFR: JDK-8227831: Avoid using volatile for write-once, read-many class field In-Reply-To: <4b453fbb-da83-3566-5005-60567dfe9c7c@oracle.com> References: <38d9abc4-71c6-c26d-f820-7845c5d375bd@oracle.com> <10d1ff61-cd7f-00f9-15da-189f63c1f35a@oracle.com> <4b453fbb-da83-3566-5005-60567dfe9c7c@oracle.com> Message-ID: Hi Mandy, Thank you for your reply. I measured your patch, and the performance was about 4% better than mine. Since it is faster and cleaner, I agree your patch looks better. Regards, Ogata "core-libs-dev" wrote on 2019/07/19 02:58:50: > From: Mandy Chung > To: Claes Redestad , David Holmes > > Cc: core-libs-dev at openjdk.java.net > Date: 2019/07/19 02:59 > Subject: [EXTERNAL] Re: RFR: JDK-8227831: Avoid using volatile for write- > once, read-many class field > Sent by: "core-libs-dev" > > JDK-8219774 is relevant to this patch (this was discussed in the code > review for JDK-8219378: NPE in ReflectionFactory.newMethodAccessor > when langReflectAccess not initialized). > > This cleans up the initialization of LangReflectAccess: > http://cr.openjdk.java.net/~mchung/jdk14/8219774/webrev.00/ > > I moved LangReflectAccess to jdk.internal.access to be consistent with > other *Access classes (LangReflectAccess was added before the common > SharedSecrets class was introduced). AccessibleObject was initialized > early during startup and this patch causes initializing SharedSecret and > LangReflectAccess earlier. This is not an official review for JDK-8219774 > but I'm interested if this improves the performance comparing with > Ogata's patch. > > Ogato - can you help running the micro benchmark you have with > the patch for JDK-8219774? > > thanks > Mandy > > On 7/18/19 2:53 AM, Claes Redestad wrote: > > Hi David, > > > > On 2019-07-18 06:26, David Holmes wrote: > >> Hi Claes, > >> > >> On 18/07/2019 1:04 am, Claes Redestad wrote: > >>> Hi, > >>> > >>> removing volatile aligns LangReflectAccess initialization with the > >>> pattern used for other access objects: it's only initialized in the > >>> static initializer of some class which we ensure is initialized, which > >>> means any initialization race is guarded by the initialization of said > >>> class - in this case j.l.r.Modifier. > >> > >> If the field is not volatile then we are not guaranteed to correctly > >> see the constructed LangReflectAccess instance. Without volatile (or > >> without additional use of unconditional sync in the accessor) we do > >> not have a happens-before relationship between the construction of > >> the LRA instance, and the setting of the field > > >>> Initialization of other access objects are not guarded by any > >>> explicit synchronization, however, since similar load/store barriers > >>> will be in effect by ensuring the class that constructs the object has > >>> been initialized. So I think you could remove the explicit > >>> synchronization. > >> > >> We are not guaranteed to hit the class initialization checks that > >> would guarantee the necessary ordering. > > > > You better not look at the existing code in > > jdk.internal.access.SharedSecrets :-) > > > > Would the unsafe.ensureClassInitialized(..) pattern used there bring > > stronger guarantees? That would be the pattern I'm suggesting the code > > under review here to align with. > > > > And for the record none of the *Access objects carry state and are > > strictly delegating to either static methods/constructors or instance > > methods on their arguments. > > > > /Claes > > > >> > >> David > >> ----- > >> > >>> I'm not sure why LangReflectAccess has not moved in with other > >>> SharedSecrets. Perhaps this is just an artefact of having been around > >>> for a long time, but maybe that'd cause some cyclic bootstrap > >>> dependency. Either way it's nice to see it align to use the same > >>> pattern. > >>> > >>> Thanks! > >>> /Claes > >>> > >>> On 2019-07-17 10:00, Kazunori Ogata wrote: > >>>> Hi Aleskey, > >>>> > >>>> Thank you for your comment. > >>>> > >>>> I forgot to mention one thing. I verified that all accesses to > >>>> langReflectioAccess calls the accessor "langReflectAccess()". > >>>> Since this > >>>> variable is modified once from null to non-null, I think the write > >>>> in the > >>>> setter is guaranteed to be visible in the getter by putting the > >>>> synchronized block in langReflectAccess(). > >>>> > >>>> Should I put comments about this assumption? Actually, in JDK11 > >>>> there are > >>>> some lines that do not call the getter, so backport needs to fix them, > >>>> too. > >>>> > >>>> > >>>> Regards, > >>>> Ogata > >>>> > >>>> > >>>> Aleksey Shipilev wrote on 2019/07/17 16:49:08: > >>>> > >>>>> From: Aleksey Shipilev > >>>>> To: Kazunori Ogata , > >>>>> core-libs-dev at openjdk.java.net > >>>>> Date: 2019/07/17 16:49 > >>>>> Subject: [EXTERNAL] Re: RFR: JDK-8227831: Avoid using volatile for > >>>> write- > >>>>> once, read-many class field > >>>>> > >>>>> On 7/17/19 8:48 AM, Kazunori Ogata wrote: > >>>>>> Webrev: http://cr.openjdk.java.net/~ogatak/8227831/webrev/ > >>>>> > >>>>> Note this is generally not safe: it introduces data race on > >>>>> langReflectAccess field access. It has > >>>>> to be proved that everything that implements LangReflectAccess > >>>>> interface > >>>> > >>>>> makes this data race > >>>>> benign: e.g. all fields that are accessed via those implementation > >>>>> are > >>>>> final, read once, etc. And > >>>>> briefly looking at that, I am not sure it is the case for the actual > >>>>> accessor generators. > >>>>> > >>>>> I'd cautiously leave "volatile" here. > >>>>> > >>>>> -- > >>>>> Thanks, > >>>>> -Aleksey > >>>>> > >>>>> [attachment "signature.asc" deleted by Kazunori Ogata/Japan/IBM] > >>>> > > From Alan.Bateman at oracle.com Fri Jul 19 06:20:19 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 19 Jul 2019 07:20:19 +0100 Subject: 8228392: java.io.Filter{In,Out}put stream constructors should allow null stream parameter In-Reply-To: <55F7A3DE-BF8D-4FD3-9B4F-097AAEC406F5@oracle.com> References: <55F7A3DE-BF8D-4FD3-9B4F-097AAEC406F5@oracle.com> Message-ID: <15fe1922-b8f7-6c78-8e73-e3440072eb5e@oracle.com> On 18/07/2019 20:01, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8228392 > http://cr.openjdk.java.net/~bpb/8228392/webrev.00/ > > This moves the NPE from the Filter{In,Out}putStream constructors to the subclass constructors. > > One thing which should be considered as an alternative would be not to check for null at all in these constructors but update the subclass constructor specifications to override the class documentation and indicate that the underlying stream parameter may be null. > > This change has passed the tier 1-3 tests modulo one timeout of an unrelated tier 2 test. > Can we split this one into two issues - one to revert JDK-8067801 as the JDK 14 is badly broken due to this change, the second to re-examine the original issue as that will take time to figure out the compatibility impact (e.g. the current patch retrofits several 20+ year classes to throw NPE and this will likely break existing code or require a spec change to align the spec with long standing behavior). -Alan From Alan.Bateman at oracle.com Fri Jul 19 06:22:09 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 19 Jul 2019 07:22:09 +0100 Subject: 8228392: java.io.Filter{In,Out}put stream constructors should allow null stream parameter In-Reply-To: References: <55F7A3DE-BF8D-4FD3-9B4F-097AAEC406F5@oracle.com> <2119A209-E194-4A5C-B8B3-F13D9321795D@oracle.com> Message-ID: On 18/07/2019 21:01, Brian Burkhalter wrote: > : > A patch which backs out the java.io.Filter{In,Out}put stream constructors null underlying stream check (and consequent changes) is at [1]. > > A tier 1-3 test run is in progress. > > Thanks, > > Brian > > [1] http://cr.openjdk.java.net/~bpb/8228392/webrev.01/ The backout looks good. The follow-up issue will need a CSR as there are significant compatibility issues that will need to be agreed. -Alan From matthias.baesken at sap.com Fri Jul 19 07:50:03 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 19 Jul 2019 07:50:03 +0000 Subject: RFR : 8227737: avoid implicit-function-declaration on AIX In-Reply-To: References: Message-ID: Thanks for the additional review ! Best regards, Matthias From: Lindenmaier, Goetz Sent: Freitag, 19. Juli 2019 09:33 To: Baesken, Matthias ; Schmidt, Lutz ; Doerr, Martin Subject: RE: RFR : 8227737: avoid implicit-function-declaration on AIX Hi Matthias, This looks good, thanks for doing this. Best regards, Goetz. From: Langer, Christoph Sent: Mittwoch, 17. Juli 2019 09:40 To: Baesken, Matthias >; Java Core Libs >; nio-dev at openjdk.java.net; net-dev at openjdk.java.net; awt-dev at openjdk.java.net Cc: 'ppc-aix-port-dev at openjdk.java.net' > Subject: RE: RFR : 8227737: avoid implicit-function-declaration on AIX Hi Matthias, looks good, thanks for doing this. How far are we then from enabling "warnings as errors" on AIX? :P Best regards Christoph From: awt-dev > On Behalf Of Baesken, Matthias Sent: Dienstag, 16. Juli 2019 17:04 To: Java Core Libs >; nio-dev at openjdk.java.net; net-dev at openjdk.java.net; awt-dev at openjdk.java.net Cc: 'ppc-aix-port-dev at openjdk.java.net' > Subject: [CAUTION] RFR : 8227737: avoid implicit-function-declaration on AIX Hello, please review the following AIX related change . It fixes a number of missing inclusions leading to implicit-function-declaration warnings when compiling with the recent xlc16 /xlclang . At various places in the native C coding in jdk, we miss header inclusions on AIX. This leads to warnings like : /nightly/jdk/src/java.base/unix/native/libjava/childproc.c:99:5: warning: implicitly declaring library function 'snprintf' with type 'int (char *, unsigned long, const char *, ...)' [-Wimplicit-function-declaration] snprintf(aix_fd_dir, 32, "/proc/%d/fd", getpid()); ^ /nightly/jdk/src/java.base/unix/native/libjava/childproc.c:99:5: note: include the header or explicitly provide a declaration for 'snprintf' or /nightly/jdk/src/java.base/aix/native/libjli/java_md_aix.c:38:5: warning: implicitly declaring library function 'memset' with type 'void *(void *, int, unsigned long)' [-Wimplicit-function-declaration] memset((void *)info, 0, sizeof(Dl_info)); /nightly/jdk/src/java.base/aix/native/libjli/java_md_aix.c:38:5: note: include the header or explicitly provide a declaration for 'memset' Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8227737 http://cr.openjdk.java.net/~mbaesken/webrevs/8227737.0/ Thanks, Matthias From aph at redhat.com Fri Jul 19 08:31:44 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 19 Jul 2019 09:31:44 +0100 Subject: RFR (S): JDK-8222778: Packaging Tool (JEP 343) on Linux/AArch64 In-Reply-To: <0ec8f547-8e21-7fd2-1091-886dc7a4d2b1@bell-sw.com> References: <234f1c54-bd2a-c90b-367b-e279062218ff@bell-sw.com> <0ec8f547-8e21-7fd2-1091-886dc7a4d2b1@bell-sw.com> Message-ID: <28da2683-40a9-80be-9d35-63d7976557c6@redhat.com> On 7/19/19 12:36 AM, Dmitry Chuyko wrote: > On 7/18/19 11:57 AM, Andrew Haley wrote: >> Hi, >> >> On 7/17/19 10:19 PM, Dmitry Chuyko wrote: >>> On 7/17/19 11:52 AM, Andrew Haley wrote: >>>> This is weird: >>>> >>>> --- old/src/jdk.jpackage/linux/native/libapplauncher/LinuxPlatform.cpp 2019-07-16 22:11:30.200258978 +0300 >>>> +++ new/src/jdk.jpackage/linux/native/libapplauncher/LinuxPlatform.cpp 2019-07-16 22:11:29.867374851 +0300 >>>> @@ -127,7 +127,7 @@ >>>> } >>>> >>>> void LinuxPlatform::SetCurrentDirectory(TString Value) { >>>> - chdir(PlatformString(Value).toPlatformString()); >>>> + int ignored = chdir(PlatformString(Value).toPlatformString()); >>>> } >>>> >>>> Firstly it does not fix the problem: you've gone from an unused value to an >>>> unused variable. Secondly, we ignore the return value of printf all the time; >>>> what's different about this one? >>> chdir() is __wur, which is /usr/include/aarch64-linux-gnu/sys/cdefs.h:# >>> define __wur __attribute_warn_unused_result__ >> OK, got it. >> >>> In some places this warning is disabled (CoreLibraries.gmk, >>> Awt2dLibraries.gmk). >>> >>> It would be more correct to handle the result here as chdir might not >>> succeeded in fact. >> Very much so. We shouldn't try to "shut up the compiler" in this way.Andrew Haley > > I created a separate bug about chdir() and write() usages: > https://bugs.openjdk.java.net/browse/JDK-8228402 > > Does it look good to silence warnings for platforms support changes? I think we should fix the bugs, not silence the warnings. > One > more option could be to exclude related changes from current review. OK. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Alan.Bateman at oracle.com Fri Jul 19 10:58:15 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 19 Jul 2019 11:58:15 +0100 Subject: RFR: 8227642: [TESTBUG] Make docker tests podman compatible In-Reply-To: <32c8a1934bf07e4c9c6a961e60dcb7abd9931fe1.camel@redhat.com> References: <32c8a1934bf07e4c9c6a961e60dcb7abd9931fe1.camel@redhat.com> Message-ID: <2bd4e000-6008-a0f0-d17e-aeaf5336569b@oracle.com> On 12/07/2019 19:08, Severin Gehwolf wrote: > Hi, > > There is an alternative container engine which is being used by Fedora > and RHEL 8, called podman[1]. It's mostly compatible with docker. It > looks like OpenJDK docker tests can be made podman compatible with a > few little tweaks. One "interesting" one is to not assert "Successfully > built" in the build output but only rely on the exit code, which seems > to be OK for my testing. Interestingly the test would be skipped in > that case. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8227642 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227642/01/webrev/ > Just looking at 02/webrev and I see it adds a System.getProperty to test/lib/jdk/test/lib/Platform.java. That may cause issues for tests that use this test infrastructure and have their own security policy (we've run into issues in the past with test infrastructure requiring permissions that the tests using the test library don't know about). In this case it might be better to create Platform.Docker.COMMAND so that only the container tests need to be concerned with it. -Alan From Alan.Bateman at oracle.com Fri Jul 19 11:02:45 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 19 Jul 2019 12:02:45 +0100 Subject: [PATCH] Add const to input parameter for JNU_IsInstanceOfByName In-Reply-To: References: Message-ID: <8b5e9d1c-9ad1-a903-ef09-5a0b37a7f49c@oracle.com> On 16/07/2019 00:10, Andrew Luo wrote: > Hi Everyone, > > I'm making some const-correctness fixes to some downstream libraries that use JNU_* functions, and noticed that JNU_IsInstanceOfByName takes in the class name by char* instead of const char* when it does not need to modify the string. It would be useful to change this so that we don't have to (unnecessarily) const-cast every time and can safely pass string literals to this function. Patch is inline below - any comments/feedback welcome. This looks okay to me. -Alan. From sgehwolf at redhat.com Fri Jul 19 11:24:10 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 19 Jul 2019 13:24:10 +0200 Subject: RFR: 8227642: [TESTBUG] Make docker tests podman compatible In-Reply-To: <2bd4e000-6008-a0f0-d17e-aeaf5336569b@oracle.com> References: <32c8a1934bf07e4c9c6a961e60dcb7abd9931fe1.camel@redhat.com> <2bd4e000-6008-a0f0-d17e-aeaf5336569b@oracle.com> Message-ID: <514c5818de749950d15da01adcae8fec720c726c.camel@redhat.com> Hi Alan, On Fri, 2019-07-19 at 11:58 +0100, Alan Bateman wrote: > On 12/07/2019 19:08, Severin Gehwolf wrote: > > Hi, > > > > There is an alternative container engine which is being used by Fedora > > and RHEL 8, called podman[1]. It's mostly compatible with docker. It > > looks like OpenJDK docker tests can be made podman compatible with a > > few little tweaks. One "interesting" one is to not assert "Successfully > > built" in the build output but only rely on the exit code, which seems > > to be OK for my testing. Interestingly the test would be skipped in > > that case. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8227642 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227642/01/webrev/ > > > Just looking at 02/webrev and I see it adds a System.getProperty to > test/lib/jdk/test/lib/Platform.java. That may cause issues for tests > that use this test infrastructure and have their own security policy > (we've run into issues in the past with test infrastructure requiring > permissions that the tests using the test library don't know about). In > this case it might be better to create Platform.Docker.COMMAND so that > only the container tests need to be concerned with it. Thanks for the heads-up. Unfortunately, it's too late. I've pushed it already: https://hg.openjdk.java.net/jdk/jdk/rev/709913d8ace9 Your comment leaves me confused, though. VMProps.java (which is being used for all @requires foo extensions) does System.getProperty() calls too but that's not a problem? If so why? Is there a way to reproduce this? Once I've got a reproducer I'd be happy to fix it. FWIW, jdk/submit came back green before this was pushed. Thanks, Severin From Alan.Bateman at oracle.com Fri Jul 19 11:48:18 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 19 Jul 2019 12:48:18 +0100 Subject: RFR: 8227642: [TESTBUG] Make docker tests podman compatible In-Reply-To: <514c5818de749950d15da01adcae8fec720c726c.camel@redhat.com> References: <32c8a1934bf07e4c9c6a961e60dcb7abd9931fe1.camel@redhat.com> <2bd4e000-6008-a0f0-d17e-aeaf5336569b@oracle.com> <514c5818de749950d15da01adcae8fec720c726c.camel@redhat.com> Message-ID: <675ce319-00cc-099b-a287-9c3cb97a8653@oracle.com> On 19/07/2019 12:24, Severin Gehwolf wrote: > : > Thanks for the heads-up. > > Unfortunately, it's too late. I've pushed it already: > https://hg.openjdk.java.net/jdk/jdk/rev/709913d8ace9 > > Your comment leaves me confused, though. VMProps.java (which is being > used for all @requires foo extensions) does System.getProperty() calls > too but that's not a problem? If so why? Is there a way to reproduce > this? Once I've got a reproducer I'd be happy to fix it. > > FWIW, jdk/submit came back green before this was pushed. > I didn't realize this was pushed (I'm just catching up after being out for a few days). I just checked the CI system in Oracle and it looks like jdk/net/Sockets/Test.java is failing because of this. I just checked it locally and it duplicate readily so should help with the follow-up issue. There may be more but can't confirm that until all tests have run. -Alan. From sgehwolf at redhat.com Fri Jul 19 11:56:28 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 19 Jul 2019 13:56:28 +0200 Subject: RFR: 8227642: [TESTBUG] Make docker tests podman compatible In-Reply-To: <675ce319-00cc-099b-a287-9c3cb97a8653@oracle.com> References: <32c8a1934bf07e4c9c6a961e60dcb7abd9931fe1.camel@redhat.com> <2bd4e000-6008-a0f0-d17e-aeaf5336569b@oracle.com> <514c5818de749950d15da01adcae8fec720c726c.camel@redhat.com> <675ce319-00cc-099b-a287-9c3cb97a8653@oracle.com> Message-ID: <3b9638b4321f6460a5b63d72247942c86d3b464a.camel@redhat.com> On Fri, 2019-07-19 at 12:48 +0100, Alan Bateman wrote: > On 19/07/2019 12:24, Severin Gehwolf wrote: > > : > > Thanks for the heads-up. > > > > Unfortunately, it's too late. I've pushed it already: > > https://hg.openjdk.java.net/jdk/jdk/rev/709913d8ace9 > > > > Your comment leaves me confused, though. VMProps.java (which is being > > used for all @requires foo extensions) does System.getProperty() calls > > too but that's not a problem? If so why? Is there a way to reproduce > > this? Once I've got a reproducer I'd be happy to fix it. > > > > FWIW, jdk/submit came back green before this was pushed. > > > I didn't realize this was pushed (I'm just catching up after being out > for a few days). I just checked the CI system in Oracle and it looks > like jdk/net/Sockets/Test.java is failing because of this. I just > checked it locally and it duplicate readily so should help with the > follow-up issue. There may be more but can't confirm that until all > tests have run. Thanks, reproduced. I'll have a look. Cheers, Severin From sgehwolf at redhat.com Fri Jul 19 13:40:10 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 19 Jul 2019 15:40:10 +0200 Subject: RFR: 8228434: jdk/net/Sockets/Test.java fails after JDK-8227642 Message-ID: <72e3b39ef12dc87ac730afc835110d8a1e8aec60.camel@redhat.com> Hi, Please review this fix for an issue introduced by JDK-8227642 pointed out by Alan Bateman. Thanks, Alan! That enhancement introduced a new constant in the test libraries' Platform class which can cause issues in tests which run with a security manager. One such instance is jdk/net/Sockets/Test.java. The proposed webrev addresses this issue by delaying loading of the DOCKER_COMMAND constant (which in turn triggers System.getProperty call). Bug: https://bugs.openjdk.java.net/browse/JDK-8228434 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8228434/01/webrev/ Testing: tier1 on Linux x86_64, jdk/net jtreg tests. Docker/podman testing. Thoughts? Thanks, Severin From claes.redestad at oracle.com Fri Jul 19 13:44:32 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 19 Jul 2019 15:44:32 +0200 Subject: RFR: 8228434: jdk/net/Sockets/Test.java fails after JDK-8227642 In-Reply-To: <72e3b39ef12dc87ac730afc835110d8a1e8aec60.camel@redhat.com> References: <72e3b39ef12dc87ac730afc835110d8a1e8aec60.camel@redhat.com> Message-ID: <2c5c953e-6d2c-da0b-066b-d357759010f8@oracle.com> Hi, why not just use the Platform.privilegedGetProperty method, which seems purpose built for avoiding issues with reading properties like these in tests running with a security manager? /Claes On 2019-07-19 15:40, Severin Gehwolf wrote: > Hi, > > Please review this fix for an issue introduced by JDK-8227642 pointed > out by Alan Bateman. Thanks, Alan! That enhancement introduced a new > constant in the test libraries' Platform class which can cause issues > in tests which run with a security manager. One such instance is > jdk/net/Sockets/Test.java. > > The proposed webrev addresses this issue by delaying loading of the > DOCKER_COMMAND constant (which in turn triggers System.getProperty > call). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8228434 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8228434/01/webrev/ > > Testing: tier1 on Linux x86_64, jdk/net jtreg tests. Docker/podman testing. > > Thoughts? > > Thanks, > Severin > From sgehwolf at redhat.com Fri Jul 19 14:00:20 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 19 Jul 2019 16:00:20 +0200 Subject: RFR: 8228434: jdk/net/Sockets/Test.java fails after JDK-8227642 In-Reply-To: <2c5c953e-6d2c-da0b-066b-d357759010f8@oracle.com> References: <72e3b39ef12dc87ac730afc835110d8a1e8aec60.camel@redhat.com> <2c5c953e-6d2c-da0b-066b-d357759010f8@oracle.com> Message-ID: <00f117d5f5cbce2776469a2401a9403105857d3a.camel@redhat.com> Hi Claes, On Fri, 2019-07-19 at 15:44 +0200, Claes Redestad wrote: > Hi, > > why not just use the Platform.privilegedGetProperty method, which seems > purpose built for avoiding issues with reading properties like these > in tests running with a security manager? Sure. By adding a method also accepting a default value it would work as well. If that's preferred, I can change it: diff --git a/test/lib/jdk/test/lib/Platform.java b/test/lib/jdk/test/lib/Platform.java --- a/test/lib/jdk/test/lib/Platform.java +++ b/test/lib/jdk/test/lib/Platform.java @@ -37,8 +37,7 @@ // E.g.: "/usr/local/bin/docker". We define this constant here so // that it can be used in VMProps as well which checks docker support // via this command - public static final String DOCKER_COMMAND = - System.getProperty("jdk.test.docker.command", "docker"); + public static final String DOCKER_COMMAND = privilegedGetProperty("jdk.test.docker.command", "docker"); public static final String vmName = privilegedGetProperty("java.vm.name"); public static final String vmInfo = privilegedGetProperty("java.vm.info"); private static final String osVersion = privilegedGetProperty("os.version"); @@ -57,6 +56,11 @@ PrivilegedAction) () -> System.getProperty(key)); } + private static String privilegedGetProperty(String key, String defVal) { + return AccessController.doPrivileged(( + PrivilegedAction) () -> System.getProperty(key, defVal)); + } + public static boolean isClient() { return vmName.endsWith(" Client VM"); } Alan suggested the approach in webrev 01. Thanks, Severin > /Claes > > On 2019-07-19 15:40, Severin Gehwolf wrote: > > Hi, > > > > Please review this fix for an issue introduced by JDK-8227642 pointed > > out by Alan Bateman. Thanks, Alan! That enhancement introduced a new > > constant in the test libraries' Platform class which can cause issues > > in tests which run with a security manager. One such instance is > > jdk/net/Sockets/Test.java. > > > > The proposed webrev addresses this issue by delaying loading of the > > DOCKER_COMMAND constant (which in turn triggers System.getProperty > > call). > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8228434 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8228434/01/webrev/ > > > > Testing: tier1 on Linux x86_64, jdk/net jtreg tests. Docker/podman testing. > > > > Thoughts? > > > > Thanks, > > Severin > > From Alan.Bateman at oracle.com Fri Jul 19 14:14:08 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 19 Jul 2019 15:14:08 +0100 Subject: RFR: 8228434: jdk/net/Sockets/Test.java fails after JDK-8227642 In-Reply-To: <00f117d5f5cbce2776469a2401a9403105857d3a.camel@redhat.com> References: <72e3b39ef12dc87ac730afc835110d8a1e8aec60.camel@redhat.com> <2c5c953e-6d2c-da0b-066b-d357759010f8@oracle.com> <00f117d5f5cbce2776469a2401a9403105857d3a.camel@redhat.com> Message-ID: On 19/07/2019 15:00, Severin Gehwolf wrote: > : > Sure. By adding a method also accepting a default value it would work > as well. If that's preferred, I can change it: > > diff --git a/test/lib/jdk/test/lib/Platform.java b/test/lib/jdk/test/lib/Platform.java > --- a/test/lib/jdk/test/lib/Platform.java > +++ b/test/lib/jdk/test/lib/Platform.java > @@ -37,8 +37,7 @@ > // E.g.: "/usr/local/bin/docker". We define this constant here so > // that it can be used in VMProps as well which checks docker support > // via this command > - public static final String DOCKER_COMMAND = > - System.getProperty("jdk.test.docker.command", "docker"); > + public static final String DOCKER_COMMAND = privilegedGetProperty("jdk.test.docker.command", "docker"); > public static final String vmName = privilegedGetProperty("java.vm.name"); > public static final String vmInfo = privilegedGetProperty("java.vm.info"); > private static final String osVersion = privilegedGetProperty("os.version"); > @@ -57,6 +56,11 @@ > PrivilegedAction) () -> System.getProperty(key)); > } > > + private static String privilegedGetProperty(String key, String defVal) { > + return AccessController.doPrivileged(( > + PrivilegedAction) () -> System.getProperty(key, defVal)); > + } > + > public static boolean isClient() { > return vmName.endsWith(" Client VM"); > } > > Alan suggested the approach in webrev 01. > Using privilegedGetProperty is okay as long as the test classes are granted permission to read this property. You should be able to verify that quickly by running a few tests that come with their own policy files. In passing, the cast privilegedGetProperty methods is a bit ugly, this might be a bit cleaner: PrivilegedAction pa = () -> System.getProperty(key, defaultValue); return AccessController.doPrivileged(pa); -Alan. From brian.burkhalter at oracle.com Fri Jul 19 14:58:09 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 19 Jul 2019 07:58:09 -0700 Subject: 8228392: java.io.Filter{In,Out}put stream constructors should allow null stream parameter In-Reply-To: References: <55F7A3DE-BF8D-4FD3-9B4F-097AAEC406F5@oracle.com> <2119A209-E194-4A5C-B8B3-F13D9321795D@oracle.com> Message-ID: > On Jul 18, 2019, at 11:22 PM, Alan Bateman wrote: > > On 18/07/2019 21:01, Brian Burkhalter wrote: >> : >> A patch which backs out the java.io.Filter{In,Out}put stream constructors null underlying stream check (and consequent changes) is at [1]. >> >> A tier 1-3 test run is in progress. >> >> Thanks, >> >> Brian >> >> [1] http://cr.openjdk.java.net/~bpb/8228392/webrev.01/ > The backout looks good. The follow-up issue will need a CSR as there are significant compatibility issues that will need to be agreed. Given the compatibility issues it might be best to modify the specifications of the Filter*Stream subclass constructors to allow a null underlying stream parameter, thereby overriding the package level javadoc. IOTW align the spec with longstanding behavior. Brian From sgehwolf at redhat.com Fri Jul 19 15:07:36 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 19 Jul 2019 17:07:36 +0200 Subject: RFR: 8228434: jdk/net/Sockets/Test.java fails after JDK-8227642 In-Reply-To: References: <72e3b39ef12dc87ac730afc835110d8a1e8aec60.camel@redhat.com> <2c5c953e-6d2c-da0b-066b-d357759010f8@oracle.com> <00f117d5f5cbce2776469a2401a9403105857d3a.camel@redhat.com> Message-ID: Hi Alan, Claes, Shouldn't we consider the less risky alternative? I.e. the original webrev? More below. On Fri, 2019-07-19 at 15:14 +0100, Alan Bateman wrote: > > On 19/07/2019 15:00, Severin Gehwolf wrote: > > : > > Sure. By adding a method also accepting a default value it would work > > as well. If that's preferred, I can change it: > > > > diff --git a/test/lib/jdk/test/lib/Platform.java b/test/lib/jdk/test/lib/Platform.java > > --- a/test/lib/jdk/test/lib/Platform.java > > +++ b/test/lib/jdk/test/lib/Platform.java > > @@ -37,8 +37,7 @@ > > // E.g.: "/usr/local/bin/docker". We define this constant here so > > // that it can be used in VMProps as well which checks docker support > > // via this command > > - public static final String DOCKER_COMMAND = > > - System.getProperty("jdk.test.docker.command", "docker"); > > + public static final String DOCKER_COMMAND = privilegedGetProperty("jdk.test.docker.command", "docker"); > > public static final String vmName = privilegedGetProperty("java.vm.name"); > > public static final String vmInfo = privilegedGetProperty("java.vm.info"); > > private static final String osVersion = privilegedGetProperty("os.version"); > > @@ -57,6 +56,11 @@ > > PrivilegedAction) () -> System.getProperty(key)); > > } > > > > + private static String privilegedGetProperty(String key, String defVal) { > > + return AccessController.doPrivileged(( > > + PrivilegedAction) () -> System.getProperty(key, defVal)); > > + } > > + > > public static boolean isClient() { > > return vmName.endsWith(" Client VM"); > > } > > > > Alan suggested the approach in webrev 01. > > > Using privilegedGetProperty is okay as long as the test classes are > granted permission to read this property. > You should be able to verify > that quickly by running a few tests that come with their own policy files. Since this is a case of a) test using Platform class from test library *and* b) using a security manager c) check policy files whether permissions have been granted. This isn't an easy task for me. My cursory query brought up this test set: test/jdk/com/oracle/security/ucrypto/TestAES.java test/jdk/java/net/httpclient/AsFileDownloadTest.java test/jdk/java/net/httpclient/RequestBodyTest.java test/jdk/javax/swing/JFileChooser/8062561/bug8062561.java test/jdk/jdk/net/Sockets/Test.java bug8062561.java is windows only :( Rather finding all tests which got broken, wouldn't the original proposed webrev be less risky? Do you have objections, to go with that, Claes? http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8228434/01/webrev/ Thanks, Severin From claes.redestad at oracle.com Fri Jul 19 15:21:32 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 19 Jul 2019 17:21:32 +0200 Subject: RFR: 8228434: jdk/net/Sockets/Test.java fails after JDK-8227642 In-Reply-To: References: <72e3b39ef12dc87ac730afc835110d8a1e8aec60.camel@redhat.com> <2c5c953e-6d2c-da0b-066b-d357759010f8@oracle.com> <00f117d5f5cbce2776469a2401a9403105857d3a.camel@redhat.com> Message-ID: <0d8f5c87-b6f0-426b-a133-8283a5b0bfa2@oracle.com> On 2019-07-19 17:07, Severin Gehwolf wrote: > Do you have objections, to go with that, Claes? > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8228434/01/webrev/ While I think the privilegedGetProperty alternative would work just fine regardless of security settings, I don't object to this if you're more comfortable with it. /Claes From mandy.chung at oracle.com Fri Jul 19 16:20:37 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 19 Jul 2019 09:20:37 -0700 Subject: Review Request: JDK-8219774: Reexamine the initialization of LangReflectAccess shared secret at AccessibleObject:: Message-ID: This was a follow up to the observation during the code review of JDK-82193798. Webrev: ?? http://cr.openjdk.java.net/~mchung/jdk14/8219774/webrev.01/ In the current implementation, Modifier:: provides a hook to initialize the static ReflectionFactory::langReflectAccess field lazily. This was introduced prior to the common shared secrets mechanism. Another observation is that when ReflectionFactory methods are called, there is a Method, Field or Constructor object in hand. In addition, Method class is initialized very early during startup by the VM and so does AccessibleObject class. The ReflectionFactory::newField and newMethod taking the Field/Method parameter are used but not the one without (dead code). This patch cleans up the initialization of LangReflectAccess to AccessibleObject:: during early startup initPhase1. I also move LangReflectAccess to jdk.internal.access to be consistent with other *Access classes (LangReflectAccess was added before the common SharedSecrets class was introduced). This also addresses JDK-8227831 the overhead of langReflectAcces being a volatile field on the platform with weak memory model (Thanks to Ogata confirming that this patch is 4% better than the proposed patch for JDK-8227831 [1]). The impact to the class initialization order is minimal. JavaLangReflectAccess is initialized during initPhase1 (which has been initialized during initPhase2). SharedSecrets is initialized in initPhase2 and this patch moves it to be initialized followed AccessibleObject. Mandy [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-July/061352.html From Alan.Bateman at oracle.com Fri Jul 19 16:40:03 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 19 Jul 2019 17:40:03 +0100 Subject: RFR: 8228434: jdk/net/Sockets/Test.java fails after JDK-8227642 In-Reply-To: <0d8f5c87-b6f0-426b-a133-8283a5b0bfa2@oracle.com> References: <72e3b39ef12dc87ac730afc835110d8a1e8aec60.camel@redhat.com> <2c5c953e-6d2c-da0b-066b-d357759010f8@oracle.com> <00f117d5f5cbce2776469a2401a9403105857d3a.camel@redhat.com> <0d8f5c87-b6f0-426b-a133-8283a5b0bfa2@oracle.com> Message-ID: <292d61d5-7ee4-c99d-42a9-731ed1cb76ec@oracle.com> On 19/07/2019 16:21, Claes Redestad wrote: > On 2019-07-19 17:07, Severin Gehwolf wrote: >> Do you have objections, to go with that, Claes? >> >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8228434/01/webrev/ > > While I think the privilegedGetProperty alternative would work just > fine regardless of security settings, I don't object to this if you're > more comfortable with it. privilegedGetProperty will work for the Sockets test because its policy file allows the test lib classes to read all properties: grant codeBase "file:${test.classes}/../../../../test/lib/-" { ??? permission java.util.PropertyPermission "*", "read"; ??? permission java.io.FilePermission "/etc/release", "read"; ??? permission java.io.FilePermission "<>", "execute"; }; There might be other tests with policy files where this is not the case. Severin - how about a combination of the two approaches, meaning add Docker.DOCKER_COMMAND as per the first version but use privilegedGetProperty to read the value. That way only container tests using a SM and their own policy files will need to grant the permission to read this property. -Alan From mandy.chung at oracle.com Fri Jul 19 16:43:20 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 19 Jul 2019 09:43:20 -0700 Subject: RFR: 8228434: jdk/net/Sockets/Test.java fails after JDK-8227642 In-Reply-To: References: <72e3b39ef12dc87ac730afc835110d8a1e8aec60.camel@redhat.com> <2c5c953e-6d2c-da0b-066b-d357759010f8@oracle.com> <00f117d5f5cbce2776469a2401a9403105857d3a.camel@redhat.com> Message-ID: On 7/19/19 7:14 AM, Alan Bateman wrote: > > > On 19/07/2019 15:00, Severin Gehwolf wrote: >> : >> Sure. By adding a method also accepting a default value it would work >> as well. If that's preferred, I can change it: >> >> diff --git a/test/lib/jdk/test/lib/Platform.java >> b/test/lib/jdk/test/lib/Platform.java >> --- a/test/lib/jdk/test/lib/Platform.java >> +++ b/test/lib/jdk/test/lib/Platform.java >> @@ -37,8 +37,7 @@ >> ????? // E.g.: "/usr/local/bin/docker". We define this constant here so >> ????? // that it can be used in VMProps as well which checks docker >> support >> ????? // via this command >> -??? public static final String DOCKER_COMMAND = >> -??????? System.getProperty("jdk.test.docker.command", "docker"); >> +??? public? static final String DOCKER_COMMAND = >> privilegedGetProperty("jdk.test.docker.command", "docker"); >> ????? public? static final String vmName????? = >> privilegedGetProperty("java.vm.name"); >> ????? public? static final String vmInfo????? = >> privilegedGetProperty("java.vm.info"); >> ????? private static final String osVersion?? = >> privilegedGetProperty("os.version"); >> @@ -57,6 +56,11 @@ >> ????????????????? PrivilegedAction) () -> >> System.getProperty(key)); >> ????? } >> ? +??? private static String privilegedGetProperty(String key, String >> defVal) { >> +??????? return AccessController.doPrivileged(( >> +??????????????? PrivilegedAction) () -> >> System.getProperty(key, defVal)); >> +??? } >> + >> ????? public static boolean isClient() { >> ????????? return vmName.endsWith(" Client VM"); >> ????? } >> >> Alan suggested the approach in webrev 01. >> > Using privilegedGetProperty is okay as long as the test classes are > granted permission to read this property. You should be able to verify > that quickly by running a few tests that come with their own policy > files. > Platform requires the tests using it to grant "PropertyPermission" to the code source of test library. test/jdk/jdk/net/Sockets/policy.* files are already doing that and so it's fine. It'd be nice if @library would be able to augment the security policy but it's a different issue. > In passing, the cast privilegedGetProperty methods is a bit ugly, this > might be a bit cleaner: > > PrivilegedAction pa = () -> System.getProperty(key, > defaultValue); > return AccessController.doPrivileged(pa); The proposed patch with this reformat looks okay. Mandy From sgehwolf at redhat.com Fri Jul 19 16:55:07 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 19 Jul 2019 18:55:07 +0200 Subject: RFR: 8228434: jdk/net/Sockets/Test.java fails after JDK-8227642 In-Reply-To: <292d61d5-7ee4-c99d-42a9-731ed1cb76ec@oracle.com> References: <72e3b39ef12dc87ac730afc835110d8a1e8aec60.camel@redhat.com> <2c5c953e-6d2c-da0b-066b-d357759010f8@oracle.com> <00f117d5f5cbce2776469a2401a9403105857d3a.camel@redhat.com> <0d8f5c87-b6f0-426b-a133-8283a5b0bfa2@oracle.com> <292d61d5-7ee4-c99d-42a9-731ed1cb76ec@oracle.com> Message-ID: On Fri, 2019-07-19 at 17:40 +0100, Alan Bateman wrote: > On 19/07/2019 16:21, Claes Redestad wrote: > > On 2019-07-19 17:07, Severin Gehwolf wrote: > > > Do you have objections, to go with that, Claes? > > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8228434/01/webrev/ > > > > While I think the privilegedGetProperty alternative would work just > > fine regardless of security settings, I don't object to this if you're > > more comfortable with it. > privilegedGetProperty will work for the Sockets test because its policy > file allows the test lib classes to read all properties: > > grant codeBase "file:${test.classes}/../../../../test/lib/-" { > permission java.util.PropertyPermission "*", "read"; > permission java.io.FilePermission "/etc/release", "read"; > permission java.io.FilePermission "<>", "execute"; > }; Yes. > There might be other tests with policy files where this is not the case. My issue is with finding those tests :-/ If we know the set of *all* tests affected by the breakage we could do approach 2. Approach 1 (or 3) seems safer. > Severin - how about a combination of the two approaches, meaning add > Docker.DOCKER_COMMAND as per the first version but use > privilegedGetProperty to read the value. That way only container tests > using a SM and their own policy files will need to grant the permission > to read this property. Sure, fine with me. Here you go: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8228434/02/webrev/ Thoughts? Thanks, Severin From mandy.chung at oracle.com Fri Jul 19 16:58:57 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 19 Jul 2019 09:58:57 -0700 Subject: RFR: 8228434: jdk/net/Sockets/Test.java fails after JDK-8227642 In-Reply-To: References: <72e3b39ef12dc87ac730afc835110d8a1e8aec60.camel@redhat.com> <2c5c953e-6d2c-da0b-066b-d357759010f8@oracle.com> <00f117d5f5cbce2776469a2401a9403105857d3a.camel@redhat.com> <0d8f5c87-b6f0-426b-a133-8283a5b0bfa2@oracle.com> <292d61d5-7ee4-c99d-42a9-731ed1cb76ec@oracle.com> Message-ID: Hi Severin, On 7/19/19 9:55 AM, Severin Gehwolf wrote: >> There might be other tests with policy files where this is not the case. > My issue is with finding those tests :-/ If we know the set of *all* > tests affected by the breakage we could do approach 2. Approach 1 (or > 3) seems safer. > >> Severin - how about a combination of the two approaches, meaning add >> Docker.DOCKER_COMMAND as per the first version but use >> privilegedGetProperty to read the value. That way only container tests >> using a SM and their own policy files will need to grant the permission >> to read this property. > Sure, fine with me. Here you go: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8228434/02/webrev/ > > It seems better to define Docker as a new top-level class as Platform doesn't seem the right place to define DOCKER_COMMAND. Otherwise looks good. Mandy From Alan.Bateman at oracle.com Fri Jul 19 16:59:44 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 19 Jul 2019 17:59:44 +0100 Subject: RFR: 8228434: jdk/net/Sockets/Test.java fails after JDK-8227642 In-Reply-To: References: <72e3b39ef12dc87ac730afc835110d8a1e8aec60.camel@redhat.com> <2c5c953e-6d2c-da0b-066b-d357759010f8@oracle.com> <00f117d5f5cbce2776469a2401a9403105857d3a.camel@redhat.com> <0d8f5c87-b6f0-426b-a133-8283a5b0bfa2@oracle.com> <292d61d5-7ee4-c99d-42a9-731ed1cb76ec@oracle.com> Message-ID: <2bfd9fd1-ea7f-806a-1f47-54fb9ab5a8dc@oracle.com> On 19/07/2019 17:55, Severin Gehwolf wrote: > : > My issue is with finding those tests :-/ If we know the set of *all* > tests affected by the breakage we could do approach 2. Approach 1 (or > 3) seems safer. Any impact will be limited to tests using the test infrastructure but using their own policy. I agree #1 or #3 is the safest. I just scanned the new webrev (02/webrev) and it looks good to me. -Alan From sgehwolf at redhat.com Fri Jul 19 17:13:08 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 19 Jul 2019 19:13:08 +0200 Subject: RFR: 8228434: jdk/net/Sockets/Test.java fails after JDK-8227642 In-Reply-To: References: <72e3b39ef12dc87ac730afc835110d8a1e8aec60.camel@redhat.com> <2c5c953e-6d2c-da0b-066b-d357759010f8@oracle.com> <00f117d5f5cbce2776469a2401a9403105857d3a.camel@redhat.com> <0d8f5c87-b6f0-426b-a133-8283a5b0bfa2@oracle.com> <292d61d5-7ee4-c99d-42a9-731ed1cb76ec@oracle.com> Message-ID: <4b2b739a3d9e8976cdc8fe056b958702a47b8498.camel@redhat.com> Hi Mandy, On Fri, 2019-07-19 at 09:58 -0700, Mandy Chung wrote: > Hi Severin, > > On 7/19/19 9:55 AM, Severin Gehwolf wrote: > > > There might be other tests with policy files where this is not the case. > > My issue is with finding those tests :-/ If we know the set of *all* > > tests affected by the breakage we could do approach 2. Approach 1 (or > > 3) seems safer. > > > > > Severin - how about a combination of the two approaches, meaning add > > > Docker.DOCKER_COMMAND as per the first version but use > > > privilegedGetProperty to read the value. That way only container tests > > > using a SM and their own policy files will need to grant the permission > > > to read this property. > > Sure, fine with me. Here you go: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8228434/02/webrev/ > > > > > > It seems better to define Docker as a new top-level class as Platform > doesn't seem the right place to define DOCKER_COMMAND. Note that Platform.java is already on the boot library path for jtreg and moving it to a separate class would need another entry here (in TEST.ROOT): requires.extraPropDefns.bootlibs = ../lib/sun ../lib/jdk/test/lib/Platform.java The reason I've moved it to Platform for JDK-8227642 was that VMProps.java previously hard-coded the docker command (it needs to use the property value instead). This seems work for little gain. Note that the intention is to change "Docker" and DOCKER_COMMAND to something more neutral, like Container or ContainerEngine. In light of that, Platform.ContainerEngine.COMMAND makes sense to me. Could I perhaps convince you to accept this version? http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8228434/02/webrev/ Thanks, Severin From mandy.chung at oracle.com Fri Jul 19 17:32:06 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 19 Jul 2019 10:32:06 -0700 Subject: RFR: 8228434: jdk/net/Sockets/Test.java fails after JDK-8227642 In-Reply-To: <4b2b739a3d9e8976cdc8fe056b958702a47b8498.camel@redhat.com> References: <72e3b39ef12dc87ac730afc835110d8a1e8aec60.camel@redhat.com> <2c5c953e-6d2c-da0b-066b-d357759010f8@oracle.com> <00f117d5f5cbce2776469a2401a9403105857d3a.camel@redhat.com> <0d8f5c87-b6f0-426b-a133-8283a5b0bfa2@oracle.com> <292d61d5-7ee4-c99d-42a9-731ed1cb76ec@oracle.com> <4b2b739a3d9e8976cdc8fe056b958702a47b8498.camel@redhat.com> Message-ID: <2dfdab04-a0db-b86d-c6c6-10846bbde146@oracle.com> On 7/19/19 10:13 AM, Severin Gehwolf wrote: > Hi Mandy, > > On Fri, 2019-07-19 at 09:58 -0700, Mandy Chung wrote: >> Hi Severin, >> >> On 7/19/19 9:55 AM, Severin Gehwolf wrote: >>>> There might be other tests with policy files where this is not the case. >>> My issue is with finding those tests :-/ If we know the set of *all* >>> tests affected by the breakage we could do approach 2. Approach 1 (or >>> 3) seems safer. >>> >>>> Severin - how about a combination of the two approaches, meaning add >>>> Docker.DOCKER_COMMAND as per the first version but use >>>> privilegedGetProperty to read the value. That way only container tests >>>> using a SM and their own policy files will need to grant the permission >>>> to read this property. >>> Sure, fine with me. Here you go: >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8228434/02/webrev/ >>> >>> >> It seems better to define Docker as a new top-level class as Platform >> doesn't seem the right place to define DOCKER_COMMAND. > Note that Platform.java is already on the boot library path for jtreg > and moving it to a separate class would need another entry here (in > TEST.ROOT): > > requires.extraPropDefns.bootlibs = ../lib/sun ../lib/jdk/test/lib/Platform.java > > The reason I've moved it to Platform for JDK-8227642 was that > VMProps.java previously hard-coded the docker command (it needs to use > the property value instead). It accepts multiple files, doesn't it? > This seems work for little gain. Note that the intention is to change > "Docker" and DOCKER_COMMAND to something more neutral, like Container > or ContainerEngine. In light of that, Platform.ContainerEngine.COMMAND > makes sense to me. This is a test library specific to containers.? "Container" sounds fine. ? Why not doing it now? > Could I perhaps convince you to accept this version? > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8228434/02/webrev/ I still think separating container-specific APIs in its own class will prevent running similar kind of issue in the future. Mandy From igor.ignatyev at oracle.com Fri Jul 19 17:59:19 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 19 Jul 2019 10:59:19 -0700 Subject: RFR: 8228434: jdk/net/Sockets/Test.java fails after JDK-8227642 In-Reply-To: <2bfd9fd1-ea7f-806a-1f47-54fb9ab5a8dc@oracle.com> References: <72e3b39ef12dc87ac730afc835110d8a1e8aec60.camel@redhat.com> <2c5c953e-6d2c-da0b-066b-d357759010f8@oracle.com> <00f117d5f5cbce2776469a2401a9403105857d3a.camel@redhat.com> <0d8f5c87-b6f0-426b-a133-8283a5b0bfa2@oracle.com> <292d61d5-7ee4-c99d-42a9-731ed1cb76ec@oracle.com> <2bfd9fd1-ea7f-806a-1f47-54fb9ab5a8dc@oracle.com> Message-ID: haven't we identified and *fixed* all the tests which use j.t.l.Platform class and their own security policy (as part of 8210039 or other testlibrary refactoring)? in other words, all the tests which use j.t.l.Platform must have a policy file which grants Platform java.util.PropertyPermission read. so there should be no impact at all, unless there are tests which grants permissions to specific properties, and such policies are relatively easy to find and correct. -- Igor > On Jul 19, 2019, at 9:59 AM, Alan Bateman wrote: > > On 19/07/2019 17:55, Severin Gehwolf wrote: >> : >> My issue is with finding those tests :-/ If we know the set of *all* >> tests affected by the breakage we could do approach 2. Approach 1 (or >> 3) seems safer. > Any impact will be limited to tests using the test infrastructure but using their own policy. I agree #1 or #3 is the safest. > > I just scanned the new webrev (02/webrev) and it looks good to me. > > -Alan From Alan.Bateman at oracle.com Fri Jul 19 19:44:26 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 19 Jul 2019 20:44:26 +0100 Subject: RFR: 8228434: jdk/net/Sockets/Test.java fails after JDK-8227642 In-Reply-To: References: <72e3b39ef12dc87ac730afc835110d8a1e8aec60.camel@redhat.com> <2c5c953e-6d2c-da0b-066b-d357759010f8@oracle.com> <00f117d5f5cbce2776469a2401a9403105857d3a.camel@redhat.com> <0d8f5c87-b6f0-426b-a133-8283a5b0bfa2@oracle.com> <292d61d5-7ee4-c99d-42a9-731ed1cb76ec@oracle.com> <2bfd9fd1-ea7f-806a-1f47-54fb9ab5a8dc@oracle.com> Message-ID: <756abdc3-1991-f0dd-e560-8c905c0b7b0a@oracle.com> On 19/07/2019 18:59, Igor Ignatyev wrote: > haven't we identified and *fixed* all the tests which use j.t.l.Platform class and their own security policy (as part of 8210039 or other testlibrary refactoring)? in other words, all the tests which use j.t.l.Platform must have a policy file which grants Platform java.util.PropertyPermission read. so there should be no impact at all, unless there are tests which grants permissions to specific properties, and such policies are relatively easy to find and correct. > Test infrastructure classes that need permissions are a bit of a pain for tests that want to run with a security manager or use their own policy files. It's just not easy to change these test libraries without fear of breaking tests in random places. I think we have to compartmentalize (as per the latest webrev) to avoid every test with a policy file needing to grant permissions do do container stuff when they aren't container tests. One thing that would be helpful is to have a page on the wiki with info on how to these test libraries with a security manager - is this something that you (or maybe Mikhailo) would have cycles to do? -Alan. From igor.ignatyev at oracle.com Fri Jul 19 22:39:49 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 19 Jul 2019 15:39:49 -0700 Subject: RFR: 8228434: jdk/net/Sockets/Test.java fails after JDK-8227642 In-Reply-To: <756abdc3-1991-f0dd-e560-8c905c0b7b0a@oracle.com> References: <72e3b39ef12dc87ac730afc835110d8a1e8aec60.camel@redhat.com> <2c5c953e-6d2c-da0b-066b-d357759010f8@oracle.com> <00f117d5f5cbce2776469a2401a9403105857d3a.camel@redhat.com> <0d8f5c87-b6f0-426b-a133-8283a5b0bfa2@oracle.com> <292d61d5-7ee4-c99d-42a9-731ed1cb76ec@oracle.com> <2bfd9fd1-ea7f-806a-1f47-54fb9ab5a8dc@oracle.com> <756abdc3-1991-f0dd-e560-8c905c0b7b0a@oracle.com> Message-ID: > On Jul 19, 2019, at 12:44 PM, Alan Bateman wrote: > > On 19/07/2019 18:59, Igor Ignatyev wrote: >> haven't we identified and *fixed* all the tests which use j.t.l.Platform class and their own security policy (as part of 8210039 or other testlibrary refactoring)? in other words, all the tests which use j.t.l.Platform must have a policy file which grants Platform java.util.PropertyPermission read. so there should be no impact at all, unless there are tests which grants permissions to specific properties, and such policies are relatively easy to find and correct. >> > Test infrastructure classes that need permissions are a bit of a pain for tests that want to run with a security manager or use their own policy files. It's just not easy to change these test libraries without fear of breaking tests in random places. I think we have to compartmentalize (as per the latest webrev) to avoid every test with a policy file needing to grant permissions do do container stuff when they aren't container tests. good point, but I was rather suggesting that tests which use Platform should grant permissions to do "Platform" stuff which, one might argue, should have rights to read any system properties. > One thing that would be helpful is to have a page on the wiki with info on how to these test libraries with a security manager - is this something that you (or maybe Mikhailo) would have cycles to do? improving documentation of "common" test library classes has been in my todo list for a long time, and is definitely an overdue. I'll try to either reprioritize that work or at least compose the wiki-page you suggested. > > -Alan. Cheers, -- Igor From Alan.Bateman at oracle.com Sat Jul 20 07:44:08 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 20 Jul 2019 08:44:08 +0100 Subject: 8228392: java.io.Filter{In,Out}put stream constructors should allow null stream parameter In-Reply-To: References: <55F7A3DE-BF8D-4FD3-9B4F-097AAEC406F5@oracle.com> <2119A209-E194-4A5C-B8B3-F13D9321795D@oracle.com> Message-ID: On 19/07/2019 15:58, Brian Burkhalter wrote: > > Given the compatibility issues it might be best to modify the > specifications of the Filter*Stream subclass constructors to allow a > null underlying stream parameter, thereby overriding the package level > javadoc. IOTW align the spec with longstanding behavior. > I think it will need a detailed examination to see how each one behaves when the input stream is null. As the field is protected it means that sub-classes can change its value at any time, maybe because they want to set it lazily or maybe they want to set it to null when the stream is closed. For classes such as DIS/DOS then it probably means NPE in many operations when the stream is null. Other classes (suchas BIS and BOS) will interpret it as the closed stream. So it will need a detailed analysis but more than likely you will not be able to change long standing behavior because it will break existing code. -Alan From Alan.Bateman at oracle.com Sat Jul 20 15:08:08 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 20 Jul 2019 16:08:08 +0100 Subject: Review Request: JDK-8219774: Reexamine the initialization of LangReflectAccess shared secret at AccessibleObject:: In-Reply-To: References: Message-ID: On 19/07/2019 17:20, Mandy Chung wrote: > This was a follow up to the observation during the code review > of JDK-82193798. > > Webrev: > ?? http://cr.openjdk.java.net/~mchung/jdk14/8219774/webrev.01/ > This cleanup looks good to me. A minor nit is that ReflectAccess is in jl.reflect so the usages in say AccessibleObject don't need to use the fully qualified class name. -Alan From Alan.Bateman at oracle.com Sat Jul 20 15:23:04 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 20 Jul 2019 16:23:04 +0100 Subject: RFR: 8227587: Add internal privileged System.loadLibrary In-Reply-To: <3d3ef452-48d8-caf0-75a7-bcc051b13f82@oracle.com> References: <8cf6ed4d-194a-4428-f381-e7e3c0452cd6@oracle.com> <4943b69c-bc3a-f147-abb8-5b369eec5737@oracle.com> <2cbfd5d8-c4a0-4a2d-ba62-6fed14dc7155@oracle.com> <60d95350-c42c-1498-5c72-174736e863c0@oracle.com> <15a57e3c-065c-55c5-b6af-0644ed8f775b@oracle.com> <3d3ef452-48d8-caf0-75a7-bcc051b13f82@oracle.com> Message-ID: <8abe1b0e-9439-5059-fa6d-8b0b2a3ef860@oracle.com> On 16/07/2019 14:48, Claes Redestad wrote: > Hi, > > refactored to use a BootLoader::loadLibrary API that is only visible > within the java.base module: > > http://cr.openjdk.java.net/~redestad/8227587/open.03/ > > I've retained the bridge to ClassLoader::loadLibrary for performance, > but without any magic or privilege escalation involved. Moving sys_path > / systemNativeLibraries out of ClassLoader seems quite complicated, so > I've not attempted that refactoring for this RFE Adding BootLoader.loadLibrary is okay but we should try to keep method description consistent with the other methods in this class. Also I think we can clean up the SM path while we are there. Several of the NIO classes have been changed to the following, which looks a bit odd jdk.internal.loader.BootLoader.loadLibrary("net"); jdk.internal.loader.BootLoader.loadLibrary("nio"); I see this has been pushed so I'll create a follow-on issue for the cleanups. -Alan. From Alan.Bateman at oracle.com Sat Jul 20 16:15:10 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 20 Jul 2019 17:15:10 +0100 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: <532398EA-B7F8-4803-A038-A0F54DCD460F@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> Message-ID: On 18/07/2019 16:32, Brian Burkhalter wrote: > Resuming this topic, what is the general view on the three possible paths: > > 1. Override write(byte[]) at the risk of incompatibility. > 2. Instead add writeBytes(byte[]) as in ByteArrayOutputStream. > 3. Resolve as Won?t Fix. > > For 2 or 3 the incorrect class level statement about overriding all methods not to throw IOE would need to be dealt with. > PrintStream dates from JDK 1.0 so I don't think it's feasible to add an override now that doesn't throw IOE. Tagir's suggestion to add a writeBytes(byte[]) seem fine, assuming there is a great need. Alternatively you can add an override (that throws IOE) so that you have somewhere for an @apiNote that suggests using write(b,0,b.len) as "exception-less" write. -Alan From fujie at loongson.cn Mon Jul 22 06:18:20 2019 From: fujie at loongson.cn (Jie Fu) Date: Mon, 22 Jul 2019 14:18:20 +0800 Subject: Fwd: Re: RFR: 8225648:[TESTBUG] java/lang/annotation/loaderLeak/Main.java fails with -Xcomp In-Reply-To: <3067ee48-ad14-f465-65b7-2aa85c592424@oracle.com> References: <3067ee48-ad14-f465-65b7-2aa85c592424@oracle.com> Message-ID: <9e42f9e8-5432-4de6-a3ee-7a50dc83ecf5@loongson.cn> Hi all, Could someone help to push this: http://cr.openjdk.java.net/~jiefu/8225648/webrev.01/ ? I need a sponsor. It had been fully reviewed by Alan and Ioi and can be applied cleanly. Thanks a lot. Best regards, Jie -------- Forwarded Message -------- Subject: Re: RFR: 8225648:[TESTBUG] java/lang/annotation/loaderLeak/Main.java fails with -Xcomp Date: Thu, 20 Jun 2019 12:09:24 +0100 From: Alan Bateman To: Jie Fu CC: core-libs-dev at openjdk.java.net On 19/06/2019 07:36, Jie Fu wrote: > Hi Alan, > > I've updated the patch by adding the review info. > http://cr.openjdk.java.net/~jiefu/8225648/webrev.01/ > > Is it OK to be pushed? I don't see any objections so go ahead. -Alan From david.holmes at oracle.com Mon Jul 22 06:19:00 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 22 Jul 2019 16:19:00 +1000 Subject: Review Request: JDK-8219774: Reexamine the initialization of LangReflectAccess shared secret at AccessibleObject:: In-Reply-To: References: Message-ID: <4d936b7b-7fc7-f859-a96c-914426548278@oracle.com> Hi Mandy, This approach looks much cleaner and safer to me, and the slight shuffling in the init order should not cause any startup issues. Thanks, David ----- On 20/07/2019 2:20 am, Mandy Chung wrote: > This was a follow up to the observation during the code review > of JDK-82193798. > > Webrev: > ?? http://cr.openjdk.java.net/~mchung/jdk14/8219774/webrev.01/ > > In the current implementation, Modifier:: provides a hook > to initialize the static ReflectionFactory::langReflectAccess field > lazily. This was introduced prior to the common shared secrets > mechanism. > > Another observation is that when ReflectionFactory methods are called, > there is a Method, Field or Constructor object in hand. In addition, > Method class is initialized very early during startup by the VM and > so does AccessibleObject class. The ReflectionFactory::newField and > newMethod taking the Field/Method parameter are used but not the > one without (dead code). > > This patch cleans up the initialization of LangReflectAccess to > AccessibleObject:: during early startup initPhase1. > I also move LangReflectAccess to jdk.internal.access to be consistent > with other *Access classes (LangReflectAccess was added before the common > SharedSecrets class was introduced). > > This also addresses JDK-8227831 the overhead of langReflectAcces being > a volatile field on the platform with weak memory model (Thanks to > Ogata confirming that this patch is 4% better than the proposed patch > for JDK-8227831 [1]). > > The impact to the class initialization order is minimal. > JavaLangReflectAccess > is initialized during initPhase1 (which has been initialized during > initPhase2). > SharedSecrets is initialized in initPhase2 and this patch moves it to be > initialized followed AccessibleObject. > > Mandy > [1] > https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-July/061352.html From david.holmes at oracle.com Mon Jul 22 06:22:54 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 22 Jul 2019 16:22:54 +1000 Subject: Fwd: Re: RFR: 8225648:[TESTBUG] java/lang/annotation/loaderLeak/Main.java fails with -Xcomp In-Reply-To: <9e42f9e8-5432-4de6-a3ee-7a50dc83ecf5@loongson.cn> References: <3067ee48-ad14-f465-65b7-2aa85c592424@oracle.com> <9e42f9e8-5432-4de6-a3ee-7a50dc83ecf5@loongson.cn> Message-ID: Hi Jie, On 22/07/2019 4:18 pm, Jie Fu wrote: > Hi all, > > Could someone help to push this: > http://cr.openjdk.java.net/~jiefu/8225648/webrev.01/ ? > I need a sponsor. To prepare your patch for your sponsor you should commit it with the correct format commit message, including reviewers, so that the sponsor can just do an hg import from the URL of the changeset in your webrev - or somewhere else you point them to. Cheers, David > It had been fully reviewed by Alan and Ioi and can be applied cleanly. > > Thanks a lot. > Best regards, > Jie > > > -------- Forwarded Message -------- > Subject:???? Re: RFR: 8225648:[TESTBUG] > java/lang/annotation/loaderLeak/Main.java fails with -Xcomp > Date:???? Thu, 20 Jun 2019 12:09:24 +0100 > From:???? Alan Bateman > To:???? Jie Fu > CC:???? core-libs-dev at openjdk.java.net > > > > On 19/06/2019 07:36, Jie Fu wrote: >> Hi Alan, >> >> I've updated the patch by adding the review info. >> http://cr.openjdk.java.net/~jiefu/8225648/webrev.01/ >> >> Is it OK to be pushed? > I don't see any objections so go ahead. > > -Alan > From fujie at loongson.cn Mon Jul 22 06:39:24 2019 From: fujie at loongson.cn (Jie Fu) Date: Mon, 22 Jul 2019 14:39:24 +0800 Subject: Fwd: Re: RFR: 8225648:[TESTBUG] java/lang/annotation/loaderLeak/Main.java fails with -Xcomp In-Reply-To: References: <3067ee48-ad14-f465-65b7-2aa85c592424@oracle.com> <9e42f9e8-5432-4de6-a3ee-7a50dc83ecf5@loongson.cn> Message-ID: Hi David, Thanks for correcting me and sorry for that. Updated: http://cr.openjdk.java.net/~jiefu/8225648/webrev.02/ Thanks a lot. Best regards, Jie On 2019/7/22 ??2:22, David Holmes wrote: > Hi Jie, > > On 22/07/2019 4:18 pm, Jie Fu wrote: >> Hi all, >> >> Could someone help to push this: >> http://cr.openjdk.java.net/~jiefu/8225648/webrev.01/ ? >> I need a sponsor. > > To prepare your patch for your sponsor you should commit it with the > correct format commit message, including reviewers, so that the > sponsor can just do an hg import from the URL of the changeset in your > webrev - or somewhere else you point them to. > > Cheers, > David > >> It had been fully reviewed by Alan and Ioi and can be applied cleanly. >> >> Thanks a lot. >> Best regards, >> Jie >> >> >> -------- Forwarded Message -------- >> Subject:???? Re: RFR: 8225648:[TESTBUG] >> java/lang/annotation/loaderLeak/Main.java fails with -Xcomp >> Date:???? Thu, 20 Jun 2019 12:09:24 +0100 >> From:???? Alan Bateman >> To:???? Jie Fu >> CC:???? core-libs-dev at openjdk.java.net >> >> >> >> On 19/06/2019 07:36, Jie Fu wrote: >>> Hi Alan, >>> >>> I've updated the patch by adding the review info. >>> http://cr.openjdk.java.net/~jiefu/8225648/webrev.01/ >>> >>> Is it OK to be pushed? >> I don't see any objections so go ahead. >> >> -Alan >> From david.holmes at oracle.com Mon Jul 22 06:55:57 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 22 Jul 2019 16:55:57 +1000 Subject: Fwd: Re: RFR: 8225648:[TESTBUG] java/lang/annotation/loaderLeak/Main.java fails with -Xcomp In-Reply-To: References: <3067ee48-ad14-f465-65b7-2aa85c592424@oracle.com> <9e42f9e8-5432-4de6-a3ee-7a50dc83ecf5@loongson.cn> Message-ID: <1da58867-a298-d9ad-52af-e07772a54ed8@oracle.com> Hi Jie, On 22/07/2019 4:39 pm, Jie Fu wrote: > Hi David, > > Thanks for correcting me and sorry for that. No problem, it's a learning curve for everyone. > Updated: http://cr.openjdk.java.net/~jiefu/8225648/webrev.02/ The patch is still not a proper changeset: http://cr.openjdk.java.net/~jiefu/8225648/webrev.02/jdk-dev.patch --- old/test/jdk/java/lang/annotation/loaderLeak/Main.java 2019-07-22 14:33:23.086509297 +0800 +++ new/test/jdk/java/lang/annotation/loaderLeak/Main.java 2019-07-22 14:33:22.850508806 +0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2004, 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2004, 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 @@ -56,6 +56,7 @@ if (c.get() == null) throw new AssertionError(); System.gc(); System.gc(); + Reference.reachabilityFence(loader); loader = null; // Might require multiple calls to System.gc() for weak-references Did you use -N when generating the webrev? You shouldn't in this case. Thanks, David > Thanks a lot. > Best regards, > Jie > > On 2019/7/22 ??2:22, David Holmes wrote: >> Hi Jie, >> >> On 22/07/2019 4:18 pm, Jie Fu wrote: >>> Hi all, >>> >>> Could someone help to push this: >>> http://cr.openjdk.java.net/~jiefu/8225648/webrev.01/ ? >>> I need a sponsor. >> >> To prepare your patch for your sponsor you should commit it with the >> correct format commit message, including reviewers, so that the >> sponsor can just do an hg import from the URL of the changeset in your >> webrev - or somewhere else you point them to. >> >> Cheers, >> David >> >>> It had been fully reviewed by Alan and Ioi and can be applied cleanly. >>> >>> Thanks a lot. >>> Best regards, >>> Jie >>> >>> >>> -------- Forwarded Message -------- >>> Subject:???? Re: RFR: 8225648:[TESTBUG] >>> java/lang/annotation/loaderLeak/Main.java fails with -Xcomp >>> Date:???? Thu, 20 Jun 2019 12:09:24 +0100 >>> From:???? Alan Bateman >>> To:???? Jie Fu >>> CC:???? core-libs-dev at openjdk.java.net >>> >>> >>> >>> On 19/06/2019 07:36, Jie Fu wrote: >>>> Hi Alan, >>>> >>>> I've updated the patch by adding the review info. >>>> http://cr.openjdk.java.net/~jiefu/8225648/webrev.01/ >>>> >>>> Is it OK to be pushed? >>> I don't see any objections so go ahead. >>> >>> -Alan >>> > From fujie at loongson.cn Mon Jul 22 07:14:01 2019 From: fujie at loongson.cn (Jie Fu) Date: Mon, 22 Jul 2019 15:14:01 +0800 Subject: Fwd: Re: RFR: 8225648:[TESTBUG] java/lang/annotation/loaderLeak/Main.java fails with -Xcomp In-Reply-To: <1da58867-a298-d9ad-52af-e07772a54ed8@oracle.com> References: <3067ee48-ad14-f465-65b7-2aa85c592424@oracle.com> <9e42f9e8-5432-4de6-a3ee-7a50dc83ecf5@loongson.cn> <1da58867-a298-d9ad-52af-e07772a54ed8@oracle.com> Message-ID: <90256bbb-e360-a09d-5638-4ccb34f3dcc1@loongson.cn> Hi David, On 2019/7/22 ??2:55, David Holmes wrote: > Did you use -N when generating the webrev? You shouldn't in this case. > Yes, I had used `ksh webrev.ksh -u jiefu -N -r 55752` to generate webrev.02. Updated: http://cr.openjdk.java.net/~jiefu/8225648/webrev.03/ webrev.03 was generated by `ksh webrev.ksh -c 8225648`. Is that right? Thanks a lot. Best regards, Jie From david.holmes at oracle.com Mon Jul 22 07:26:39 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 22 Jul 2019 17:26:39 +1000 Subject: Fwd: Re: RFR: 8225648:[TESTBUG] java/lang/annotation/loaderLeak/Main.java fails with -Xcomp In-Reply-To: <90256bbb-e360-a09d-5638-4ccb34f3dcc1@loongson.cn> References: <3067ee48-ad14-f465-65b7-2aa85c592424@oracle.com> <9e42f9e8-5432-4de6-a3ee-7a50dc83ecf5@loongson.cn> <1da58867-a298-d9ad-52af-e07772a54ed8@oracle.com> <90256bbb-e360-a09d-5638-4ccb34f3dcc1@loongson.cn> Message-ID: On 22/07/2019 5:14 pm, Jie Fu wrote: > Hi David, > > On 2019/7/22 ??2:55, David Holmes wrote: >> Did you use -N when generating the webrev? You shouldn't in this case. >> > Yes, I had used `ksh webrev.ksh -u jiefu -N -r 55752` to generate > webrev.02. > > Updated: http://cr.openjdk.java.net/~jiefu/8225648/webrev.03/ > webrev.03 was generated by `ksh webrev.ksh -c 8225648`. > Is that right? Yep :) Sponsored. Cheers, David ----- > Thanks a lot. > Best regards, > Jie > > From fujie at loongson.cn Mon Jul 22 07:28:13 2019 From: fujie at loongson.cn (Jie Fu) Date: Mon, 22 Jul 2019 15:28:13 +0800 Subject: Fwd: Re: RFR: 8225648:[TESTBUG] java/lang/annotation/loaderLeak/Main.java fails with -Xcomp In-Reply-To: References: <3067ee48-ad14-f465-65b7-2aa85c592424@oracle.com> <9e42f9e8-5432-4de6-a3ee-7a50dc83ecf5@loongson.cn> <1da58867-a298-d9ad-52af-e07772a54ed8@oracle.com> <90256bbb-e360-a09d-5638-4ccb34f3dcc1@loongson.cn> Message-ID: <58dfd073-ab10-e8bf-67dd-4e9cad857aa3@loongson.cn> Thank you so much, David. On 2019/7/22 ??3:26, David Holmes wrote: > On 22/07/2019 5:14 pm, Jie Fu wrote: >> Hi David, >> >> On 2019/7/22 ??2:55, David Holmes wrote: >>> Did you use -N when generating the webrev? You shouldn't in this case. >>> >> Yes, I had used `ksh webrev.ksh -u jiefu -N -r 55752` to generate >> webrev.02. >> >> Updated: http://cr.openjdk.java.net/~jiefu/8225648/webrev.03/ >> webrev.03 was generated by `ksh webrev.ksh -c 8225648`. >> Is that right? > > Yep :) > > Sponsored. > > Cheers, > David > ----- > >> Thanks a lot. >> Best regards, >> Jie >> >> From sgehwolf at redhat.com Mon Jul 22 09:12:42 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 22 Jul 2019 11:12:42 +0200 Subject: RFR: 8228434: jdk/net/Sockets/Test.java fails after JDK-8227642 In-Reply-To: <2dfdab04-a0db-b86d-c6c6-10846bbde146@oracle.com> References: <72e3b39ef12dc87ac730afc835110d8a1e8aec60.camel@redhat.com> <2c5c953e-6d2c-da0b-066b-d357759010f8@oracle.com> <00f117d5f5cbce2776469a2401a9403105857d3a.camel@redhat.com> <0d8f5c87-b6f0-426b-a133-8283a5b0bfa2@oracle.com> <292d61d5-7ee4-c99d-42a9-731ed1cb76ec@oracle.com> <4b2b739a3d9e8976cdc8fe056b958702a47b8498.camel@redhat.com> <2dfdab04-a0db-b86d-c6c6-10846bbde146@oracle.com> Message-ID: Hi Mandy, On Fri, 2019-07-19 at 10:32 -0700, Mandy Chung wrote: > I still think separating container-specific APIs in its own class will > prevent running similar kind of issue in the future. Take 03: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8228434/03/webrev/ This now reverts Platform.java changes to the version prior JDK- 8227642, introduces a Container class with one constant, CONTAINER_ENGINE, and renames the jdk.test.docker.command property to jdk.test.container.command. Breakage as seen via jdk/net/Sockets/Test.java no longer exists as the Platform class no longer loads an extra property. Testing: jdk/net/Sockets/Test.java test, container tests with docker/podman on Linux x86_64. Thoughts? Thanks, Severin From matthias.baesken at sap.com Mon Jul 22 11:01:16 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 22 Jul 2019 11:01:16 +0000 Subject: java_props_macosx.c : CFLocaleCopyCurrent() needs CFRelease ? Message-ID: Hello , maybe someone with more OSX dev knowledge could comment on this . If I understand it correctly , the OSX Core Foundation Ownership Policy : https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFMemoryMgmt/Concepts/Ownership.html#//apple_ref/doc/uid/20001148-103029 says that "Object-duplication functions that have "Copy" embedded in the name." (like CFLocaleCopyCurrent ) need to relinquish ownership (using CFRelease) when you have finished with it. Should we better add then CFRelease to the 2 CFLocaleCopyCurrent usages in src/java.base/macosx/native/libjava/java_props_macosx.c (coding below) ? Or do I miss something ? Thanks , Matthias --- a/src/java.base/macosx/native/libjava/java_props_macosx.c Fri Jul 19 10:18:48 2019 +0200 +++ b/src/java.base/macosx/native/libjava/java_props_macosx.c Mon Jul 22 12:47:21 2019 +0200 @@ -91,18 +91,22 @@ if (hyphenPos == NULL || // languageString contains ISO639 only, e.g., "en" languageString + langStrLen - hyphenPos == 5) { // ISO639-ScriptCode, e.g., "en-Latn" - CFStringGetCString(CFLocaleGetIdentifier(CFLocaleCopyCurrent()), - localeString, LOCALEIDLENGTH, CFStringGetSystemEncoding()); - char *underscorePos = strrchr(localeString, '_'); - char *region = NULL; + CFLocaleRef cflocale = CFLocaleCopyCurrent(); + if (cflocale != NULL) { + CFStringGetCString(CFLocaleGetIdentifier(cflocale), + localeString, LOCALEIDLENGTH, CFStringGetSystemEncoding()); + char *underscorePos = strrchr(localeString, '_'); + char *region = NULL; - if (underscorePos != NULL) { - region = underscorePos + 1; - } + if (underscorePos != NULL) { + region = underscorePos + 1; + } - if (region != NULL) { - strcat(languageString, "-"); - strcat(languageString, region); + if (region != NULL) { + strcat(languageString, "-"); + strcat(languageString, region); + } + CFRelease(cflocale); } } @@ -112,12 +116,18 @@ default: { - if (!CFStringGetCString(CFLocaleGetIdentifier(CFLocaleCopyCurrent()), - localeString, LOCALEIDLENGTH, CFStringGetSystemEncoding())) { + CFLocaleRef cflocale = CFLocaleCopyCurrent(); + if (cflocale != NULL) { + if (!CFStringGetCString(CFLocaleGetIdentifier(cflocale), + localeString, LOCALEIDLENGTH, CFStringGetSystemEncoding())) { + return NULL; + } + + retVal = localeString; + CFRelease(cflocale); + } else { return NULL; } - - retVal = localeString; } break; } From Alan.Bateman at oracle.com Mon Jul 22 11:06:12 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 22 Jul 2019 12:06:12 +0100 Subject: RFR: 8228434: jdk/net/Sockets/Test.java fails after JDK-8227642 In-Reply-To: References: <72e3b39ef12dc87ac730afc835110d8a1e8aec60.camel@redhat.com> <2c5c953e-6d2c-da0b-066b-d357759010f8@oracle.com> <00f117d5f5cbce2776469a2401a9403105857d3a.camel@redhat.com> <0d8f5c87-b6f0-426b-a133-8283a5b0bfa2@oracle.com> <292d61d5-7ee4-c99d-42a9-731ed1cb76ec@oracle.com> <4b2b739a3d9e8976cdc8fe056b958702a47b8498.camel@redhat.com> <2dfdab04-a0db-b86d-c6c6-10846bbde146@oracle.com> Message-ID: <4237e614-e030-6654-2a3c-7db0977a6cbc@oracle.com> On 22/07/2019 10:12, Severin Gehwolf wrote: > : > Take 03: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8228434/03/webrev/ > > This now reverts Platform.java changes to the version prior JDK- > 8227642, introduces a Container class with one constant, > CONTAINER_ENGINE, and renames the jdk.test.docker.command property to > jdk.test.container.command. > > Breakage as seen via jdk/net/Sockets/Test.java no longer exists as the > Platform class no longer loads an extra property. > > Testing: jdk/net/Sockets/Test.java test, container tests with > docker/podman on Linux x86_64. > > Thoughts? > This looks okay, assuming that none of the container/docker tests uses a security manager. If they do (and maybe it's a tax on the first test to do us), then the System.getProperty in Container will need to read the value of the property in a privileged block to void the tests needing to grant the permission. Given that the Sockets test is failing for everyone since JDK-8227642, I think it should be okay to push what you have. Further cleanup can be done latter. -Alan From sgehwolf at redhat.com Mon Jul 22 12:43:33 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 22 Jul 2019 14:43:33 +0200 Subject: RFR: 8228434: jdk/net/Sockets/Test.java fails after JDK-8227642 In-Reply-To: <4237e614-e030-6654-2a3c-7db0977a6cbc@oracle.com> References: <72e3b39ef12dc87ac730afc835110d8a1e8aec60.camel@redhat.com> <2c5c953e-6d2c-da0b-066b-d357759010f8@oracle.com> <00f117d5f5cbce2776469a2401a9403105857d3a.camel@redhat.com> <0d8f5c87-b6f0-426b-a133-8283a5b0bfa2@oracle.com> <292d61d5-7ee4-c99d-42a9-731ed1cb76ec@oracle.com> <4b2b739a3d9e8976cdc8fe056b958702a47b8498.camel@redhat.com> <2dfdab04-a0db-b86d-c6c6-10846bbde146@oracle.com> <4237e614-e030-6654-2a3c-7db0977a6cbc@oracle.com> Message-ID: <2ba65135251dff87bb36a3c39afc5879e67c7fc8.camel@redhat.com> On Mon, 2019-07-22 at 12:06 +0100, Alan Bateman wrote: > On 22/07/2019 10:12, Severin Gehwolf wrote: > > : > > Take 03: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8228434/03/webrev/ > > > > This now reverts Platform.java changes to the version prior JDK- > > 8227642, introduces a Container class with one constant, > > CONTAINER_ENGINE, and renames the jdk.test.docker.command property to > > jdk.test.container.command. > > > > Breakage as seen via jdk/net/Sockets/Test.java no longer exists as the > > Platform class no longer loads an extra property. > > > > Testing: jdk/net/Sockets/Test.java test, container tests with > > docker/podman on Linux x86_64. > > > > Thoughts? > > > This looks okay, assuming that none of the container/docker tests uses a > security manager. If they do (and maybe it's a tax on the first test to > do us), then the System.getProperty in Container will need to read the > value of the property in a privileged block to void the tests needing to > grant the permission. Right. None of them do and the property is only read before java is run inside a container. > Given that the Sockets test is failing for everyone since JDK-8227642, I > think it should be okay to push what you have. Further cleanup can be > done latter. Thanks, pushed. Cheers, Severin From naoto.sato at oracle.com Mon Jul 22 14:54:40 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 22 Jul 2019 07:54:40 -0700 Subject: [13] RFR: 8228450: unicode.md and icu.md text should be pre-formatted Message-ID: Hi, Please review this doc only fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8228450 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8228450/webrev.00/ This is simply to supply triple back ticks (```) in the .md files so that the text will not be formatted on HTML conversion. Naoto From Roger.Riggs at oracle.com Mon Jul 22 15:01:14 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 22 Jul 2019 11:01:14 -0400 Subject: [13] RFR: 8228450: unicode.md and icu.md text should be pre-formatted In-Reply-To: References: Message-ID: Looks fine On 7/22/19 10:54 AM, naoto.sato at oracle.com wrote: > Hi, > > Please review this doc only fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8228450 > > The proposed changeset is located at: > > http://cr.openjdk.java.net/~naoto/8228450/webrev.00/ > > This is simply to supply triple back ticks (```) in the .md files so > that the text will not be formatted on HTML conversion. > > Naoto From brian.burkhalter at oracle.com Mon Jul 22 15:13:44 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 22 Jul 2019 08:13:44 -0700 Subject: 8228392: java.io.Filter{In,Out}put stream constructors should allow null stream parameter In-Reply-To: References: <55F7A3DE-BF8D-4FD3-9B4F-097AAEC406F5@oracle.com> <2119A209-E194-4A5C-B8B3-F13D9321795D@oracle.com> Message-ID: <759EC2D3-1B21-4D54-AA6B-19E3C64B59EA@oracle.com> > On Jul 20, 2019, at 12:44 AM, Alan Bateman wrote: > > On 19/07/2019 15:58, Brian Burkhalter wrote: >> >> Given the compatibility issues it might be best to modify the specifications of the Filter*Stream subclass constructors to allow a null underlying stream parameter, thereby overriding the package level javadoc. IOTW align the spec with longstanding behavior. >> > I think it will need a detailed examination to see how each one behaves when the input stream is null. As the field is protected it means that sub-classes can change its value at any time, maybe because they want to set it lazily or maybe they want to set it to null when the stream is closed. For classes such as DIS/DOS then it probably means NPE in many operations when the stream is null. Other classes (suchas BIS and BOS) will interpret it as the closed stream. So it will need a detailed analysis but more than likely you will not be able to change long standing behavior because it will break existing code. Agreed. For sure in at least two of the five subclasses in java.io (not counting the deprecated LineNumberInputStream) breakage was observed (BufferedInputStream and DataInputStream). I can take another look but I doubt it is modifiable aside from making the doc match the behavior. Brian From brian.burkhalter at oracle.com Mon Jul 22 15:15:26 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 22 Jul 2019 08:15:26 -0700 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: 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> Message-ID: <426428C0-F710-4262-9E5A-247D0D267059@oracle.com> > On Jul 20, 2019, at 9:15 AM, Alan Bateman wrote: > > On 18/07/2019 16:32, Brian Burkhalter wrote: >> Resuming this topic, what is the general view on the three possible paths: >> >> 1. Override write(byte[]) at the risk of incompatibility. >> 2. Instead add writeBytes(byte[]) as in ByteArrayOutputStream. >> 3. Resolve as Won?t Fix. >> >> For 2 or 3 the incorrect class level statement about overriding all methods not to throw IOE would need to be dealt with. >> > PrintStream dates from JDK 1.0 so I don't think it's feasible to add an override now that doesn't throw IOE. Agreed. > Tagir's suggestion to add a writeBytes(byte[]) seem fine, assuming there is a great need. Not sure of the need but there is the precedent of BAIS. > Alternatively you can add an override (that throws IOE) so that you have somewhere for an @apiNote that suggests using write(b,0,b.len) as "exception-less" write. That?s a good idea. Thanks, Brian From li.jiang at oracle.com Mon Jul 22 16:23:13 2019 From: li.jiang at oracle.com (li.jiang at oracle.com) Date: Tue, 23 Jul 2019 00:23:13 +0800 Subject: RFR: 8228397: Missing license copyright header in some resource properties files Message-ID: Hi all, Please review this change. We found the license copyright header are missing in some resource properties files, some of them are very old and no hg log since code forest consolidation. In this change, I added the license copyright header in the English and its localized resource files. Bug: https://bugs.openjdk.java.net/browse/JDK-8228397 Webrev: http://cr.openjdk.java.net/~ljiang/8228397/webrev.00/ Thanks, Leo From lance.andersen at oracle.com Mon Jul 22 16:47:12 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 22 Jul 2019 12:47:12 -0400 Subject: 8228392: java.io.Filter{In,Out}put stream constructors should allow null stream parameter In-Reply-To: <759EC2D3-1B21-4D54-AA6B-19E3C64B59EA@oracle.com> References: <55F7A3DE-BF8D-4FD3-9B4F-097AAEC406F5@oracle.com> <2119A209-E194-4A5C-B8B3-F13D9321795D@oracle.com> <759EC2D3-1B21-4D54-AA6B-19E3C64B59EA@oracle.com> Message-ID: <5CCB45FD-0A12-45A3-8930-D24CA4623345@oracle.com> > On Jul 22, 2019, at 11:13 AM, Brian Burkhalter wrote: > > >> On Jul 20, 2019, at 12:44 AM, Alan Bateman wrote: >> >> On 19/07/2019 15:58, Brian Burkhalter wrote: >>> >>> Given the compatibility issues it might be best to modify the specifications of the Filter*Stream subclass constructors to allow a null underlying stream parameter, thereby overriding the package level javadoc. IOTW align the spec with longstanding behavior. >>> >> I think it will need a detailed examination to see how each one behaves when the input stream is null. As the field is protected it means that sub-classes can change its value at any time, maybe because they want to set it lazily or maybe they want to set it to null when the stream is closed. For classes such as DIS/DOS then it probably means NPE in many operations when the stream is null. Other classes (suchas BIS and BOS) will interpret it as the closed stream. So it will need a detailed analysis but more than likely you will not be able to change long standing behavior because it will break existing code. > > Agreed. For sure in at least two of the five subclasses in java.io (not counting the deprecated LineNumberInputStream) breakage was observed (BufferedInputStream and DataInputStream). I can take another look but I doubt it is modifiable aside from making the doc match the behavior. > Yeah, I had similar issues in JDBC land where I just had to update the javadoc to match the actual behavior which dated back to 1997 vs the intended behavior :-( > Brian 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 iris.clark at oracle.com Mon Jul 22 17:41:36 2019 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 22 Jul 2019 10:41:36 -0700 (PDT) Subject: RFR: 8228397: Missing license copyright header in some resource properties files In-Reply-To: References: Message-ID: <251291bb-43a7-425e-a929-92f49b2ef336@default> Hi, Leo. Thanks for adding legal notices (copyright and license) to these resource .property files. For the files in src/demo/share/jfc/*.properties, is there any reason why the legal notices should not be in a separate comment block? Right now, it appears that you've prepended the legal notices to any existing comment block at the beginning of the file. I recommend that the first comment block contain only the legal notices, as is the convention for .java and other files. Thanks, iris -----Original Message----- From: Leo Jiang Sent: Monday, July 22, 2019 9:23 AM To: jdk-dev ; core-libs-dev Subject: RFR: 8228397: Missing license copyright header in some resource properties files Hi all, Please review this change. We found the license copyright header are missing in some resource properties files, some of them are very old and no hg log since code forest consolidation. In this change, I added the license copyright header in the English and its localized resource files. Bug: https://bugs.openjdk.java.net/browse/JDK-8228397 Webrev: http://cr.openjdk.java.net/~ljiang/8228397/webrev.00/ Thanks, Leo From rafael.wth at gmail.com Mon Jul 22 19:45:41 2019 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Mon, 22 Jul 2019 21:45:41 +0200 Subject: 8202469 / 8202473: Correct type annotation resolution for class type variables Message-ID: Hello, I created a patch and test cases for two bugs (JDK-8202469 and JDK-8202473) that I have reported a while ago: https://gist.github.com/raphw/c5d6222b990573aaeaf4571aad3a7fa3 This is my first direct contribution and I hope I am following the protocol correctly. I ran all tier1 tests after applying my changes and also tested a custom OpenJDK build against my library Byte Buddy where I run many tests for processing type annotations where I compare my custom class file parser against the reflection API. The related tests that previously failed do now work correctly also in the library. Thanks for looking into my changes, I hope the tests can also be included to avoid a future regression. Thanks, Rafael From mandy.chung at oracle.com Mon Jul 22 19:55:46 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 22 Jul 2019 12:55:46 -0700 Subject: RFR: 8228397: Missing license copyright header in some resource properties files In-Reply-To: References: Message-ID: Hi Leo, Thanks for adding the copyright and license header.? The patch looks okay assuming you will separate the legal notices from the existing comment block in JFC properties files. Mandy On 7/22/19 9:23 AM, li.jiang at oracle.com wrote: > Hi all, > > Please review this change. > > We found the license copyright header are missing in some resource > properties files, some of them are very old and no hg log since code > forest consolidation. In this change, I added the license copyright > header in the English and its localized resource files. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8228397 > Webrev: http://cr.openjdk.java.net/~ljiang/8228397/webrev.00/ > > Thanks, > Leo > From naoto.sato at oracle.com Mon Jul 22 19:56:50 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 22 Jul 2019 12:56:50 -0700 Subject: java_props_macosx.c : CFLocaleCopyCurrent() needs CFRelease ? In-Reply-To: References: Message-ID: <72d41e80-82d2-44fc-dead-3fa6a653d6af@oracle.com> Hi Matthias, Thanks for catching them. Yes, I believe they should be released appropriately. Naoto On 7/22/19 4:01 AM, Baesken, Matthias wrote: > Hello , maybe someone with more OSX dev knowledge could comment on this . > If I understand it correctly , the OSX Core Foundation Ownership Policy : > > https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFMemoryMgmt/Concepts/Ownership.html#//apple_ref/doc/uid/20001148-103029 > > says that "Object-duplication functions that have "Copy" embedded in the name." (like CFLocaleCopyCurrent ) need to > relinquish ownership (using CFRelease) when you have finished with it. > > Should we better add then CFRelease to the 2 CFLocaleCopyCurrent usages in src/java.base/macosx/native/libjava/java_props_macosx.c (coding below) ? > Or do I miss something ? > > Thanks , Matthias > > > > --- a/src/java.base/macosx/native/libjava/java_props_macosx.c Fri Jul 19 10:18:48 2019 +0200 > +++ b/src/java.base/macosx/native/libjava/java_props_macosx.c Mon Jul 22 12:47:21 2019 +0200 > @@ -91,18 +91,22 @@ > if (hyphenPos == NULL || // languageString contains ISO639 only, e.g., "en" > languageString + langStrLen - hyphenPos == 5) { // ISO639-ScriptCode, e.g., "en-Latn" > - CFStringGetCString(CFLocaleGetIdentifier(CFLocaleCopyCurrent()), > - localeString, LOCALEIDLENGTH, CFStringGetSystemEncoding()); > - char *underscorePos = strrchr(localeString, '_'); > - char *region = NULL; > + CFLocaleRef cflocale = CFLocaleCopyCurrent(); > + if (cflocale != NULL) { > + CFStringGetCString(CFLocaleGetIdentifier(cflocale), > + localeString, LOCALEIDLENGTH, CFStringGetSystemEncoding()); > + char *underscorePos = strrchr(localeString, '_'); > + char *region = NULL; > - if (underscorePos != NULL) { > - region = underscorePos + 1; > - } > + if (underscorePos != NULL) { > + region = underscorePos + 1; > + } > - if (region != NULL) { > - strcat(languageString, "-"); > - strcat(languageString, region); > + if (region != NULL) { > + strcat(languageString, "-"); > + strcat(languageString, region); > + } > + CFRelease(cflocale); > } > } > > @@ -112,12 +116,18 @@ > default: > { > - if (!CFStringGetCString(CFLocaleGetIdentifier(CFLocaleCopyCurrent()), > - localeString, LOCALEIDLENGTH, CFStringGetSystemEncoding())) { > + CFLocaleRef cflocale = CFLocaleCopyCurrent(); > + if (cflocale != NULL) { > + if (!CFStringGetCString(CFLocaleGetIdentifier(cflocale), > + localeString, LOCALEIDLENGTH, CFStringGetSystemEncoding())) { > + return NULL; > + } > + > + retVal = localeString; > + CFRelease(cflocale); > + } else { > return NULL; > } > - > - retVal = localeString; > } > break; > } > > From naoto.sato at oracle.com Mon Jul 22 20:19:14 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 22 Jul 2019 13:19:14 -0700 Subject: RFR: 8228397: Missing license copyright header in some resource properties files In-Reply-To: References: Message-ID: +1 Naoto On 7/22/19 12:55 PM, Mandy Chung wrote: > Hi Leo, > > Thanks for adding the copyright and license header.? The patch looks > okay assuming you will separate the legal notices from the existing > comment block in JFC properties files. > > Mandy > > On 7/22/19 9:23 AM, li.jiang at oracle.com wrote: >> Hi all, >> >> Please review this change. >> >> We found the license copyright header are missing in some resource >> properties files, some of them are very old and no hg log since code >> forest consolidation. In this change, I added the license copyright >> header in the English and its localized resource files. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8228397 >> Webrev: http://cr.openjdk.java.net/~ljiang/8228397/webrev.00/ >> >> Thanks, >> Leo >> > From rafael.wth at gmail.com Mon Jul 22 20:48:50 2019 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Mon, 22 Jul 2019 22:48:50 +0200 Subject: 8202471: Resolves generic receiver type for types with generic signatures Message-ID: Hello, I have created a patch such that getReceiverType() returns a parameterized type if the receiver type declaration is itself generic. Currently, the receiver type is always a type representation of Class such that annotations on the type variables or the receiver type's owner type cannot be resolved: https://gist.github.com/raphw/a155d5ef66d11e5fb131b7e6b8fb10e5 Note that this change can potentially break existing code if callers of the method expect this behavior for parameterized receiver types. However, without this change, the type information is lost and I would argue that the current behavior can be considered to be incorrect. Best regards, Rafael From mandy.chung at oracle.com Mon Jul 22 23:13:03 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 22 Jul 2019 16:13:03 -0700 Subject: Review Request: JDK-8219774: Reexamine the initialization of LangReflectAccess shared secret at AccessibleObject:: In-Reply-To: References: Message-ID: On 7/20/19 8:08 AM, Alan Bateman wrote: > On 19/07/2019 17:20, Mandy Chung wrote: >> This was a follow up to the observation during the code review >> of JDK-82193798. >> >> Webrev: >> ?? http://cr.openjdk.java.net/~mchung/jdk14/8219774/webrev.01/ >> > This cleanup looks good to me. A minor nit is that ReflectAccess is in > jl.reflect so the usages in say AccessibleObject don't need to use the > fully qualified class name. > Thanks for the review.?? Good catch on AccessibleObject and I have updated it to call "new ReflectAccess()". Mandy From brian.burkhalter at oracle.com Tue Jul 23 00:01:30 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 22 Jul 2019 17:01:30 -0700 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: <426428C0-F710-4262-9E5A-247D0D267059@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> Message-ID: <3B543968-6426-4FDC-AF27-D3962BA4814E@oracle.com> [Dropping 2d-dev mailing list from the discussion as desktop is no longer affected.] > On Jul 22, 2019, at 8:15 AM, Brian Burkhalter wrote: > >> On Jul 20, 2019, at 9:15 AM, Alan Bateman > wrote: >> >> On 18/07/2019 16:32, Brian Burkhalter wrote: >>> Resuming this topic, what is the general view on the three possible paths: >>> >>> 1. Override write(byte[]) at the risk of incompatibility. >>> 2. Instead add writeBytes(byte[]) as in ByteArrayOutputStream. >>> 3. Resolve as Won?t Fix. >>> >>> For 2 or 3 the incorrect class level statement about overriding all methods not to throw IOE would need to be dealt with. >>> >> PrintStream dates from JDK 1.0 so I don't think it's feasible to add an override now that doesn't throw IOE. > > Agreed. > >> Tagir's suggestion to add a writeBytes(byte[]) seem fine, assuming there is a great need. > > Not sure of the need but there is the precedent of BAIS. > >> Alternatively you can add an override (that throws IOE) so that you have somewhere for an @apiNote that suggests using write(b,0,b.len) as "exception-less" write. > > That?s a good idea. This version [1] adds writeBytes() and overrides write(byte[]) without changing its behavior. The documentation of write(byte[]) points the user to writeBytes() and write(byte[],int.int). Thanks, Brian [1] http://cr.openjdk.java.net/~bpb/8187898/webrev-alt.01/ From david.holmes at oracle.com Tue Jul 23 04:08:49 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Jul 2019 14:08:49 +1000 Subject: 8202471: Resolves generic receiver type for types with generic signatures In-Reply-To: References: Message-ID: <7d4ed84f-7b6e-e592-d0a9-10825fbd0b9e@oracle.com> Hi Rafael, A couple of comments on process here ... On 23/07/2019 6:48 am, Rafael Winterhalter wrote: > Hello, > > I have created a patch such that getReceiverType() returns a parameterized > type if the receiver type declaration is itself generic. Currently, the > receiver type is always a type representation of Class such that > annotations on the type variables or the receiver type's owner type cannot > be resolved: https://gist.github.com/raphw/a155d5ef66d11e5fb131b7e6b8fb10e5 All OpenJDK contributions must be provided via OpenJDK infrastructure, so either direct code in an email to a mailing list (attachments usually get stripped), or a webrev hosted on cr.openjdk.java.net (available directly to Authors else find someone to host for you). Links to github are not acceptable at this time. > Note that this change can potentially break existing code if callers of the > method expect this behavior for parameterized receiver types. However, > without this change, the type information is lost and I would argue that > the current behavior can be considered to be incorrect. That argument needs to be made via a Compatibility and Specification Review (CSR) request: https://wiki.openjdk.java.net/display/csr/Main Cheers, David > Best regards, Rafael > From rafael.wth at gmail.com Tue Jul 23 05:08:39 2019 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Tue, 23 Jul 2019 07:08:39 +0200 Subject: 8202471: Resolves generic receiver type for types with generic signatures In-Reply-To: <7d4ed84f-7b6e-e592-d0a9-10825fbd0b9e@oracle.com> References: <7d4ed84f-7b6e-e592-d0a9-10825fbd0b9e@oracle.com> Message-ID: Thanks, I'll send an inline version this evening. I have written a couple of reproducers for these issues. Should I add them to jtreg and also send them as an inline patch? I'll submit the CSR tonight, too. Thanks for the pointers! Best regards, Rafael David Holmes schrieb am Di., 23. Juli 2019, 06:10: > Hi Rafael, > > A couple of comments on process here ... > > On 23/07/2019 6:48 am, Rafael Winterhalter wrote: > > Hello, > > > > I have created a patch such that getReceiverType() returns a > parameterized > > type if the receiver type declaration is itself generic. Currently, the > > receiver type is always a type representation of Class such that > > annotations on the type variables or the receiver type's owner type > cannot > > be resolved: > https://gist.github.com/raphw/a155d5ef66d11e5fb131b7e6b8fb10e5 > > All OpenJDK contributions must be provided via OpenJDK infrastructure, > so either direct code in an email to a mailing list (attachments usually > get stripped), or a webrev hosted on cr.openjdk.java.net (available > directly to Authors else find someone to host for you). Links to github > are not acceptable at this time. > > > Note that this change can potentially break existing code if callers of > the > > method expect this behavior for parameterized receiver types. However, > > without this change, the type information is lost and I would argue that > > the current behavior can be considered to be incorrect. > > That argument needs to be made via a Compatibility and Specification > Review (CSR) request: > > https://wiki.openjdk.java.net/display/csr/Main > > Cheers, > David > > > Best regards, Rafael > > > From david.holmes at oracle.com Tue Jul 23 05:29:19 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Jul 2019 15:29:19 +1000 Subject: 8202471: Resolves generic receiver type for types with generic signatures In-Reply-To: References: <7d4ed84f-7b6e-e592-d0a9-10825fbd0b9e@oracle.com> Message-ID: <3d1f795e-86d2-633e-4a64-bf9d97dad57b@oracle.com> On 23/07/2019 3:08 pm, Rafael Winterhalter wrote: > Thanks, I'll send an inline version this evening. I have written a > couple of reproducers for these issues. Should I add them to jtreg and > also send them as an inline patch? Yes, please do. Thanks, David > I'll submit the CSR tonight, too. > > Thanks for the pointers! > Best regards, Rafael > > David Holmes > > schrieb am Di., 23. Juli 2019, 06:10: > > Hi Rafael, > > A couple of comments on process here ... > > On 23/07/2019 6:48 am, Rafael Winterhalter wrote: > > Hello, > > > > I have created a patch such that getReceiverType() returns a > parameterized > > type if the receiver type declaration is itself generic. > Currently, the > > receiver type is always a type representation of Class such that > > annotations on the type variables or the receiver type's owner > type cannot > > be resolved: > https://gist.github.com/raphw/a155d5ef66d11e5fb131b7e6b8fb10e5 > > All OpenJDK contributions must be provided via OpenJDK infrastructure, > so either direct code in an email to a mailing list (attachments > usually > get stripped), or a webrev hosted on cr.openjdk.java.net > (available > directly to Authors else find someone to host for you). Links to github > are not acceptable at this time. > > > Note that this change can potentially break existing code if > callers of the > > method expect this behavior for parameterized receiver types. > However, > > without this change, the type information is lost and I would > argue that > > the current behavior can be considered to be incorrect. > > That argument needs to be made via a Compatibility and Specification > Review (CSR) request: > > https://wiki.openjdk.java.net/display/csr/Main > > Cheers, > David > > > Best regards, Rafael > > > From matthias.baesken at sap.com Tue Jul 23 06:43:18 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 23 Jul 2019 06:43:18 +0000 Subject: java_props_macosx.c : CFLocaleCopyCurrent() needs CFRelease ? Message-ID: Thanks for your input ! I opened https://bugs.openjdk.java.net/browse/JDK-8228501 for this issue, will provide a patch . Best regards, Matthias > Date: Mon, 22 Jul 2019 12:56:50 -0700 > From: naoto.sato at oracle.com > To: core-libs-dev at openjdk.java.net > Subject: Re: java_props_macosx.c : CFLocaleCopyCurrent() needs > CFRelease ? > Message-ID: <72d41e80-82d2-44fc-dead-3fa6a653d6af at oracle.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > Hi Matthias, > > Thanks for catching them. Yes, I believe they should be released > appropriately. > > Naoto > > On 7/22/19 4:01 AM, Baesken, Matthias wrote: > > Hello , maybe someone with more OSX dev knowledge could comment > on this . > > If I understand it correctly , the OSX Core Foundation Ownership Policy : > > > > > https://developer.apple.com/library/archive/documentation/CoreFoundatio > n/Conceptual/CFMemoryMgmt/Concepts/Ownership.html#//apple_ref/doc > /uid/20001148-103029 > > > > says that "Object-duplication functions that have "Copy" embedded in the > name." (like CFLocaleCopyCurrent ) need to > > relinquish ownership (using > CFRelease 521153-cfrelease>) when you have finished with it. > > > > Should we better add then CFRelease to the 2 CFLocaleCopyCurrent > usages in src/java.base/macosx/native/libjava/java_props_macosx.c > (coding below) ? > > Or do I miss something ? > > > > Thanks , Matthias > > > > > > > > --- a/src/java.base/macosx/native/libjava/java_props_macosx.c Fri Jul 19 > 10:18:48 2019 +0200 > > +++ b/src/java.base/macosx/native/libjava/java_props_macosx.c Mon Jul > 22 12:47:21 2019 +0200 > > @@ -91,18 +91,22 @@ > > if (hyphenPos == NULL || // languageString contains ISO639 only, > e.g., "en" > > languageString + langStrLen - hyphenPos == 5) { // ISO639- > ScriptCode, e.g., "en-Latn" > > - > CFStringGetCString(CFLocaleGetIdentifier(CFLocaleCopyCurrent()), > > - localeString, LOCALEIDLENGTH, > CFStringGetSystemEncoding()); > > - char *underscorePos = strrchr(localeString, '_'); > > - char *region = NULL; > > + CFLocaleRef cflocale = CFLocaleCopyCurrent(); > > + if (cflocale != NULL) { > > + CFStringGetCString(CFLocaleGetIdentifier(cflocale), > > + localeString, LOCALEIDLENGTH, > CFStringGetSystemEncoding()); > > + char *underscorePos = strrchr(localeString, '_'); > > + char *region = NULL; > > - if (underscorePos != NULL) { > > - region = underscorePos + 1; > > - } > > + if (underscorePos != NULL) { > > + region = underscorePos + 1; > > + } > > - if (region != NULL) { > > - strcat(languageString, "-"); > > - strcat(languageString, region); > > + if (region != NULL) { > > + strcat(languageString, "-"); > > + strcat(languageString, region); > > + } > > + CFRelease(cflocale); > > } > > } > > > > @@ -112,12 +116,18 @@ > > default: > > { > > - if > (!CFStringGetCString(CFLocaleGetIdentifier(CFLocaleCopyCurrent()), > > - localeString, LOCALEIDLENGTH, > CFStringGetSystemEncoding())) { > > + CFLocaleRef cflocale = CFLocaleCopyCurrent(); > > + if (cflocale != NULL) { > > + if (!CFStringGetCString(CFLocaleGetIdentifier(cflocale), > > + localeString, LOCALEIDLENGTH, > CFStringGetSystemEncoding())) { > > + return NULL; > > + } > > + > > + retVal = localeString; > > + CFRelease(cflocale); > > + } else { > > return NULL; > > } > > - > > - retVal = localeString; > > } > > break; > > } > > > > > > From li.jiang at oracle.com Tue Jul 23 07:08:29 2019 From: li.jiang at oracle.com (li.jiang at oracle.com) Date: Tue, 23 Jul 2019 15:08:29 +0800 Subject: RFR: 8228397: Missing license copyright header in some resource properties files In-Reply-To: References: Message-ID: Thank you for your reviewing. Updated the webrev: http://cr.openjdk.java.net/~ljiang/8228397/webrev.01/ I know the update is trivial, if no more suggestion I will push the patch tomorrow. Thanks, Leo On 7/23/19 3:55 AM, Mandy Chung wrote: > Hi Leo, > > Thanks for adding the copyright and license header.? The patch looks > okay assuming you will separate the legal notices from the existing > comment block in JFC properties files. > > Mandy > > On 7/22/19 9:23 AM, li.jiang at oracle.com wrote: >> Hi all, >> >> Please review this change. >> >> We found the license copyright header are missing in some resource >> properties files, some of them are very old and no hg log since code >> forest consolidation. In this change, I added the license copyright >> header in the English and its localized resource files. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8228397 >> Webrev: http://cr.openjdk.java.net/~ljiang/8228397/webrev.00/ >> >> Thanks, >> Leo >> > From Alan.Bateman at oracle.com Tue Jul 23 07:45:37 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 23 Jul 2019 08:45:37 +0100 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: <3B543968-6426-4FDC-AF27-D3962BA4814E@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> Message-ID: <8b8eea87-8b5d-8561-7058-633184ce8976@oracle.com> On 23/07/2019 01:01, Brian Burkhalter wrote: > : > This version [1] adds writeBytes() and overrides write(byte[]) without changing its behavior. The documentation of write(byte[]) points the user to writeBytes() and write(byte[],int.int). > The overridden write(byte[]) declares that it throws IOE so it's source compatible but it behaves like the other PS.write methods in that checkError is used to check for an error rather than throwing IOE. This will need a bit more wording in the method description to make this clearer. The change to the class description is confusing as it suggests that the method throws IOE - maybe that change should be dropped to avoid trying to explain the oddity in two places. -Alan. From matthias.baesken at sap.com Tue Jul 23 11:23:48 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 23 Jul 2019 11:23:48 +0000 Subject: RFR: 8228501: java_props_macosx.c - provide missing CFRelease for CFLocaleCopyCurrent was: RE: java_props_macosx.c : CFLocaleCopyCurrent() needs CFRelease ? Message-ID: Hello, please review the following fix that adds CFRelease to 2 CFLocaleCopyCurrent usages . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8228501 http://cr.openjdk.java.net/~mbaesken/webrevs/8228501.0/ Best regards, Matthias > > Thanks for your input ! > > I opened > > https://bugs.openjdk.java.net/browse/JDK-8228501 > > for this issue, will provide a patch . > > Best regards, Matthias > > > > Date: Mon, 22 Jul 2019 12:56:50 -0700 > > From: naoto.sato at oracle.com > > To: core-libs-dev at openjdk.java.net > > Subject: Re: java_props_macosx.c : CFLocaleCopyCurrent() needs > > CFRelease ? > > Message-ID: <72d41e80-82d2-44fc-dead-3fa6a653d6af at oracle.com> > > Content-Type: text/plain; charset=utf-8; format=flowed > > > > Hi Matthias, > > > > Thanks for catching them. Yes, I believe they should be released > > appropriately. > > > > Naoto > > > > On 7/22/19 4:01 AM, Baesken, Matthias wrote: > > > Hello , maybe someone with more OSX dev knowledge could comment > > on this . > > > If I understand it correctly , the OSX Core Foundation Ownership Policy : > > > > > > > > > https://developer.apple.com/library/archive/documentation/CoreFoundatio > > > n/Conceptual/CFMemoryMgmt/Concepts/Ownership.html#//apple_ref/doc > > /uid/20001148-103029 > > > > > > says that "Object-duplication functions that have "Copy" embedded in > the > > name." (like CFLocaleCopyCurrent ) need to > > > relinquish ownership (using > > > CFRelease > 521153-cfrelease>) when you have finished with it. > > > > > > Should we better add then CFRelease to the 2 CFLocaleCopyCurrent > > usages in src/java.base/macosx/native/libjava/java_props_macosx.c > > (coding below) ? > > > Or do I miss something ? > > > From matthias.baesken at sap.com Tue Jul 23 12:27:24 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 23 Jul 2019 12:27:24 +0000 Subject: CFDataCreate/CFRelease - was : RE: java_props_macosx.c : CFLocaleCopyCurrent() needs CFRelease ? Message-ID: Hello , I checked a number of other CF*Create* / CF*Copy* methods (and corresp. CFRelease calls) we have in java.base and almost all looked good to me . However this one looked bad to me : https://hg.openjdk.java.net/jdk/jdk/file/aaa83519e723/src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m#l522 CFDataRef cfDataToImport = CFDataCreate(kCFAllocatorDefault, (UInt8 *)rawData, dataSize); .... err = SecKeychainItemImport(cfDataToImport, NULL, &dataFormat, NULL, 0, ¶mBlock, defaultKeychain, &createdItems); Don't we need a CFRelease here too , the docu https://developer.apple.com/documentation/corefoundation/1542359-cfdatacreate?language=objc says the ownership of the returned object follows the Create rule . Do I miss something ? Best regards, Matthias > -----Original Message----- > From: Baesken, Matthias > Sent: Dienstag, 23. Juli 2019 08:43 > To: core-libs-dev at openjdk.java.net; 'naoto.sato at oracle.com' > > Subject: Re: java_props_macosx.c : CFLocaleCopyCurrent() needs CFRelease > ? > > Thanks for your input ! > > I opened > > https://bugs.openjdk.java.net/browse/JDK-8228501 > > for this issue, will provide a patch . > > Best regards, Matthias > > > > Date: Mon, 22 Jul 2019 12:56:50 -0700 > > From: naoto.sato at oracle.com > > To: core-libs-dev at openjdk.java.net > > Subject: Re: java_props_macosx.c : CFLocaleCopyCurrent() needs > > CFRelease ? > > Message-ID: <72d41e80-82d2-44fc-dead-3fa6a653d6af at oracle.com> > > Content-Type: text/plain; charset=utf-8; format=flowed > > > > Hi Matthias, > > > > Thanks for catching them. Yes, I believe they should be released > > appropriately. > > > > Naoto > > > > On 7/22/19 4:01 AM, Baesken, Matthias wrote: > > > Hello , maybe someone with more OSX dev knowledge could comment > > on this . > > > If I understand it correctly , the OSX Core Foundation Ownership Policy : > > > > > > > > > https://developer.apple.com/library/archive/documentation/CoreFoundatio > > > n/Conceptual/CFMemoryMgmt/Concepts/Ownership.html#//apple_ref/doc > > /uid/20001148-103029 > > > > > > says that "Object-duplication functions that have "Copy" embedded in > the > > name." (like CFLocaleCopyCurrent ) need to > > > relinquish ownership (using > > > CFRelease > 521153-cfrelease>) when you have finished with it. > > > > > > Should we better add then CFRelease to the 2 CFLocaleCopyCurrent > > usages in src/java.base/macosx/native/libjava/java_props_macosx.c > > (coding below) ? > > > Or do I miss something ? > > > > > > Thanks , Matthias > > > > > > > > > > > > --- a/src/java.base/macosx/native/libjava/java_props_macosx.c Fri Jul > 19 > > 10:18:48 2019 +0200 > > > +++ b/src/java.base/macosx/native/libjava/java_props_macosx.c Mon > Jul > > 22 12:47:21 2019 +0200 > > > @@ -91,18 +91,22 @@ > > > if (hyphenPos == NULL || // languageString contains ISO639 only, > > e.g., "en" > > > languageString + langStrLen - hyphenPos == 5) { // ISO639- > > ScriptCode, e.g., "en-Latn" > > > - > > CFStringGetCString(CFLocaleGetIdentifier(CFLocaleCopyCurrent()), > > > - localeString, LOCALEIDLENGTH, > > CFStringGetSystemEncoding()); > > > - char *underscorePos = strrchr(localeString, '_'); > > > - char *region = NULL; > > > + CFLocaleRef cflocale = CFLocaleCopyCurrent(); > > > + if (cflocale != NULL) { > > > + CFStringGetCString(CFLocaleGetIdentifier(cflocale), > > > + localeString, LOCALEIDLENGTH, > > CFStringGetSystemEncoding()); > > > + char *underscorePos = strrchr(localeString, '_'); > > > + char *region = NULL; > > > - if (underscorePos != NULL) { > > > - region = underscorePos + 1; > > > - } > > > + if (underscorePos != NULL) { > > > + region = underscorePos + 1; > > > + } > > > - if (region != NULL) { > > > - strcat(languageString, "-"); > > > - strcat(languageString, region); > > > + if (region != NULL) { > > > + strcat(languageString, "-"); > > > + strcat(languageString, region); > > > + } > > > + CFRelease(cflocale); > > > } > > > } > > > > > > @@ -112,12 +116,18 @@ > > > default: > > > { > > > - if > > (!CFStringGetCString(CFLocaleGetIdentifier(CFLocaleCopyCurrent()), > > > - localeString, LOCALEIDLENGTH, > > CFStringGetSystemEncoding())) { > > > + CFLocaleRef cflocale = CFLocaleCopyCurrent(); > > > + if (cflocale != NULL) { > > > + if (!CFStringGetCString(CFLocaleGetIdentifier(cflocale), > > > + localeString, LOCALEIDLENGTH, > > CFStringGetSystemEncoding())) { > > > + return NULL; > > > + } > > > + > > > + retVal = localeString; > > > + CFRelease(cflocale); > > > + } else { > > > return NULL; > > > } > > > - > > > - retVal = localeString; > > > } > > > break; > > > } > > > > > > > > > > From brian.burkhalter at oracle.com Tue Jul 23 15:08:23 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 23 Jul 2019 08:08:23 -0700 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: <8b8eea87-8b5d-8561-7058-633184ce8976@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> Message-ID: <533DF576-7B8B-4BC7-BB09-50609116AA56@oracle.com> > On Jul 23, 2019, at 12:45 AM, Alan Bateman wrote: > > On 23/07/2019 01:01, Brian Burkhalter wrote: >> : >> This version [1] adds writeBytes() and overrides write(byte[]) without changing its behavior. The documentation of write(byte[]) points the user to writeBytes() and write(byte[],int.int). >> > The overridden write(byte[]) declares that it throws IOE so it's source compatible but it behaves like the other PS.write methods in that checkError is used to check for an error rather than throwing IOE. I don?t see what you mean. @Override public void write(byte buf[]) throws IOException { super.write(buf); } Should ?trouble? be set and the IOE re-thrown? > This will need a bit more wording in the method description to make this clearer. The change to the class description is confusing as it suggests that the method throws IOE - maybe that change should be dropped to avoid trying to explain the oddity in two places. The current statement in the class doc without any change is however incorrect "Unlike other output streams, a PrintStream never throws an IOException; [?]? so it seems something is needed here. Thanks, Brian From matthias.baesken at sap.com Tue Jul 23 15:14:52 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 23 Jul 2019 15:14:52 +0000 Subject: RFR: 8228482: fix xlc16/xlclang comparison of distinct pointer types and string literal conversion warnings Message-ID: 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 Alan.Bateman at oracle.com Tue Jul 23 15:20:51 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 23 Jul 2019 16:20:51 +0100 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: <533DF576-7B8B-4BC7-BB09-50609116AA56@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> Message-ID: <064ec92d-7e6d-b499-be9f-7578a1a5fb39@oracle.com> On 23/07/2019 16:08, Brian Burkhalter wrote: > > I don?t see what you mean. > @Override > public void write(byte buf[]) throws IOException { > super.write(buf); > } > Should ?trouble? be set and the IOE re-thrown? > super.write(byte[]) will invoke PrintStream overrides write(byte[], int, int) so IOE won't be thrown (and why the proposed change to the class description isn't right). The method description is probably the best place to describe the behavior. -Alan From brian.burkhalter at oracle.com Tue Jul 23 15:27:04 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 23 Jul 2019 08:27:04 -0700 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: <064ec92d-7e6d-b499-be9f-7578a1a5fb39@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> Message-ID: > On Jul 23, 2019, at 8:20 AM, Alan Bateman wrote: > > On 23/07/2019 16:08, Brian Burkhalter wrote: >> >> I don?t see what you mean. >> @Override >> public void write(byte buf[]) throws IOException { >> super.write(buf); >> } >> Should ?trouble? be set and the IOE re-thrown? >> > super.write(byte[]) will invoke PrintStream overrides write(byte[], int, int) so IOE won't be thrown (and why the proposed change to the class description isn't right). The method description is probably the best place to describe the behavior. Oh, you are right. D?oh. Will update. Thanks, Brian From naoto.sato at oracle.com Tue Jul 23 16:38:37 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 23 Jul 2019 09:38:37 -0700 Subject: RFR: 8228501: java_props_macosx.c - provide missing CFRelease for CFLocaleCopyCurrent was: RE: java_props_macosx.c : CFLocaleCopyCurrent() needs CFRelease ? In-Reply-To: References: Message-ID: <72555273-a397-502e-ee79-1d1679e1f47c@oracle.com> Thanks, Matthias. Changes look good to me. I think it is hard to provide a regression test for this change, then please add noreg-hard label to the issue. Naoto On 7/23/19 4:23 AM, Baesken, Matthias wrote: > Hello, please review the following fix that adds CFRelease to 2 CFLocaleCopyCurrent usages . > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8228501 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8228501.0/ > > Best regards, Matthias > > >> >> Thanks for your input ! >> >> I opened >> >> https://bugs.openjdk.java.net/browse/JDK-8228501 >> >> for this issue, will provide a patch . >> >> Best regards, Matthias >> >> >>> Date: Mon, 22 Jul 2019 12:56:50 -0700 >>> From: naoto.sato at oracle.com >>> To: core-libs-dev at openjdk.java.net >>> Subject: Re: java_props_macosx.c : CFLocaleCopyCurrent() needs >>> CFRelease ? >>> Message-ID: <72d41e80-82d2-44fc-dead-3fa6a653d6af at oracle.com> >>> Content-Type: text/plain; charset=utf-8; format=flowed >>> >>> Hi Matthias, >>> >>> Thanks for catching them. Yes, I believe they should be released >>> appropriately. >>> >>> Naoto >>> >>> On 7/22/19 4:01 AM, Baesken, Matthias wrote: >>>> Hello , maybe someone with more OSX dev knowledge could comment >>> on this . >>>> If I understand it correctly , the OSX Core Foundation Ownership Policy : >>>> >>>> >>> >> https://developer.apple.com/library/archive/documentation/CoreFoundatio >>> >> n/Conceptual/CFMemoryMgmt/Concepts/Ownership.html#//apple_ref/doc >>> /uid/20001148-103029 >>>> >>>> says that "Object-duplication functions that have "Copy" embedded in >> the >>> name." (like CFLocaleCopyCurrent ) need to >>>> relinquish ownership (using >>> >> CFRelease>> 521153-cfrelease>) when you have finished with it. >>>> >>>> Should we better add then CFRelease to the 2 CFLocaleCopyCurrent >>> usages in src/java.base/macosx/native/libjava/java_props_macosx.c >>> (coding below) ? >>>> Or do I miss something ? >>>> > From brian.burkhalter at oracle.com Tue Jul 23 16:41:19 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 23 Jul 2019 09:41:19 -0700 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: 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> Message-ID: > On Jul 23, 2019, at 8:27 AM, Brian Burkhalter wrote: > >> On Jul 23, 2019, at 8:20 AM, Alan Bateman > wrote: >> >> On 23/07/2019 16:08, Brian Burkhalter wrote: >>> >>> I don?t see what you mean. >>> @Override >>> public void write(byte buf[]) throws IOException { >>> super.write(buf); >>> } >>> Should ?trouble? be set and the IOE re-thrown? >>> >> super.write(byte[]) will invoke PrintStream overrides write(byte[], int, int) so IOE won't be thrown (and why the proposed change to the class description isn't right). The method description is probably the best place to describe the behavior. Here is an update which accounts for the foregoing comments. http://cr.openjdk.java.net/~bpb/8187898/webrev-alt.02/ Thanks, Brian From lance.andersen at oracle.com Tue Jul 23 17:03:22 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 23 Jul 2019 13:03:22 -0400 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: 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> Message-ID: <7C526E68-DB96-4355-BEEF-C8D98620AC2C@oracle.com> Hi Brian A couple of minor suggestions: For ??? @Override public void write(byte buf[]) throws IOException { super.write(buf, 0, buf.length); } ??? You will want to add an @throws The implSpec ????? * @implSpec * The default implementation is equivalent to * {@link java.io.FilterOutputStream#write(byte[],int,int) * super.write(buf,0,buf.length)}. * ?????? Not sure if ?The default implementation? is the correct wording given it is not a default method (not sure what the norm is for describing the implementation in this case). Perhaps something like ?This method is equivalent to calling ?.? Where you have ???? *

    Note that the bytes will be written as given; to write characters * that will be translated according to the platform's default character * encoding, use the {@code print(char[])} or {@code println(char[])} * methods. * ?????? Did you consider this as a candidate for @apiNote as well? HTH Lance > On Jul 23, 2019, at 12:41 PM, Brian Burkhalter wrote: > > > >> On Jul 23, 2019, at 8:27 AM, Brian Burkhalter wrote: >> >>> On Jul 23, 2019, at 8:20 AM, Alan Bateman > wrote: >>> >>> On 23/07/2019 16:08, Brian Burkhalter wrote: >>>> >>>> I don?t see what you mean. >>>> @Override >>>> public void write(byte buf[]) throws IOException { >>>> super.write(buf); >>>> } >>>> Should ?trouble? be set and the IOE re-thrown? >>>> >>> super.write(byte[]) will invoke PrintStream overrides write(byte[], int, int) so IOE won't be thrown (and why the proposed change to the class description isn't right). The method description is probably the best place to describe the behavior. > > Here is an update which accounts for the foregoing comments. > > http://cr.openjdk.java.net/~bpb/8187898/webrev-alt.02/ > > Thanks, > > Brian > 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 Tue Jul 23 17:09:56 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 23 Jul 2019 10:09:56 -0700 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: <7C526E68-DB96-4355-BEEF-C8D98620AC2C@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> <7C526E68-DB96-4355-BEEF-C8D98620AC2C@oracle.com> Message-ID: <5D97E070-D953-4442-BB01-38BF2121D571@oracle.com> Hi Lance, > On Jul 23, 2019, at 10:03 AM, Lance Andersen wrote: > > A couple of minor suggestions: > > For > > ??? > @Override > public void write(byte buf[]) throws IOException { > super.write(buf, 0, buf.length); > } > > ??? > > You will want to add an @throws Will do. > The implSpec > ????? > * @implSpec > * The default implementation is equivalent to > * {@link java.io.FilterOutputStream#write(byte[],int,int) > * super.write(buf,0,buf.length)}. > * > ?????? > > Not sure if ?The default implementation? is the correct wording given it is not a default method (not sure what the norm is for describing the implementation in this case). Perhaps something like ?This method is equivalent to calling ?.? I concur, that would be better. > Where you have > > ???? > *

    Note that the bytes will be written as given; to write characters > * that will be translated according to the platform's default character > * encoding, use the {@code print(char[])} or {@code println(char[])} > * methods. > * > ?????? > > Did you consider this as a candidate for @apiNote as well? No, because this wording exists elsewhere in the class but not as @apiNotes. Thanks, Brian From brian.burkhalter at oracle.com Tue Jul 23 18:40:44 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 23 Jul 2019 11:40:44 -0700 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: <5D97E070-D953-4442-BB01-38BF2121D571@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> <7C526E68-DB96-4355-BEEF-C8D98620AC2C@oracle.com> <5D97E070-D953-4442-BB01-38BF2121D571@oracle.com> Message-ID: <02C03E30-F32A-41A1-9EDB-B4F7BC20C66F@oracle.com> > On Jul 23, 2019, at 10:09 AM, Brian Burkhalter wrote: > >> You will want to add an @throws > > Will do. > >> The implSpec >> ????? >> * @implSpec >> * The default implementation is equivalent to >> * {@link java.io.FilterOutputStream#write(byte[],int,int) >> * super.write(buf,0,buf.length)}. >> * >> ?????? >> >> Not sure if ?The default implementation? is the correct wording given it is not a default method (not sure what the norm is for describing the implementation in this case). Perhaps something like ?This method is equivalent to calling ?.? > > I concur, that would be better. Above changes made in [1]. Thanks, Brian [1] http://cr.openjdk.java.net/~bpb/8187898/webrev-alt.03/ From mandy.chung at oracle.com Tue Jul 23 18:51:36 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 23 Jul 2019 11:51:36 -0700 Subject: Review Request: JDK-8173978: Lookup.in should allow teleporting from a lookup class in a named module without dropping all access In-Reply-To: <9d1efa00-d179-ebc4-42de-dcfd452ea3e9@gmail.com> References: <77478136-29fd-45f9-d122-6826099dfe84@oracle.com> <847246aa-fa7a-5781-a973-5eb021a294e3@oracle.com> <76395107-8da7-4bdf-66ec-b5f9f1459284@oracle.com> <4edca042-a3f9-0a4f-bc1c-a948da0fcf2f@oracle.com> <9d1efa00-d179-ebc4-42de-dcfd452ea3e9@gmail.com> Message-ID: (Coming back to this patch and ready to push this change later today) Here is the updated webrev: ?? http://cr.openjdk.java.net/~mchung/jdk14/8173978/webrev.02/ This includes the change that Peter suggested accepting m2 == null. Mandy On 7/5/19 12:29 PM, Peter Levart wrote: > Hi Mandy, > > Yes, either way will avoid double canRead/isExported calls against the > same module. Although perhaps, an API with null prevModule would be > more consistent with other API methods that use null prevLookupClass > etc... > > Regards, Peter From rafael.wth at gmail.com Tue Jul 23 18:51:22 2019 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Tue, 23 Jul 2019 20:51:22 +0200 Subject: 8202469 / 8202473: Correct type annotation resolution for class type variables In-Reply-To: References: Message-ID: I integrated the tests into the jtreg bits (to me it looks like they are running ok but since this is my first time, please double-check). I have already signed the OCA a few years ago when I did some work on Glassfish. Let me know if anything else is missing or if I need to do anything else. Here comes the inline changeset including the additional jtreg tests: Index: test/jdk/java/lang/reflect/AnnotatedElement/TestTypeAnnotationParameterizedNonInterfaceBound.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- test/jdk/java/lang/reflect/AnnotatedElement/TestTypeAnnotationParameterizedNonInterfaceBound.java (revision 55752+:8ae33203d600+) +++ test/jdk/java/lang/reflect/AnnotatedElement/TestTypeAnnotationParameterizedNonInterfaceBound.java (revision 55752+:8ae33203d600+) @@ -0,0 +1,52 @@ +/* + * Copyright (c) 2005, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * @test + * @bug 8202473 + * @summary Make sure a type variable bound on a parameterized non-interface bound does not receive a type path offset + */ + +import java.lang.annotation.Target; +import java.lang.annotation.*; +import java.lang.reflect.AnnotatedType; +import java.lang.reflect.TypeVariable; +import java.util.ArrayList; + +public class TestTypeAnnotationParameterizedNonInterfaceBound> { + + public static void main(String[] args) { + TypeVariable[] variables = TestTypeAnnotationParameterizedNonInterfaceBound.class.getTypeParameters(); + TypeVariable variable = variables[0]; + AnnotatedType[] bounds = variable.getAnnotatedBounds(); + AnnotatedType bound = bounds[0]; + Annotation[] annotations = bound.getAnnotations(); + if (annotations.length != 1) { + throw new AssertionError(); + } + } + + @Retention(RetentionPolicy.RUNTIME) + @Target(ElementType.TYPE_USE) + @interface TypeAnnotation { } +} Index: test/jdk/java/lang/reflect/AnnotatedElement/TestTypeAnnotationTwoVariables.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- test/jdk/java/lang/reflect/AnnotatedElement/TestTypeAnnotationTwoVariables.java (revision 55752+:8ae33203d600+) +++ test/jdk/java/lang/reflect/AnnotatedElement/TestTypeAnnotationTwoVariables.java (revision 55752+:8ae33203d600+) @@ -0,0 +1,61 @@ +/* + * Copyright (c) 2005, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * @test + * @bug 8202473 + * @summary Make sure a type path for a type variable's bound is filtered by variable index + */ + +import java.lang.annotation.Target; +import java.lang.annotation.*; +import java.lang.reflect.AnnotatedParameterizedType; +import java.lang.reflect.AnnotatedType; +import java.lang.reflect.TypeVariable; +import java.util.concurrent.Callable; + +public class TestTypeAnnotationTwoVariables< + U extends Callable<@TestTypeAnnotationTwoVariables.TypeAnnotation(0) ?>, + V extends Callable<@TestTypeAnnotationTwoVariables.TypeAnnotation(1) ?>> { + + public static void main(String[] args) { + TypeVariable[] variables = TestTypeAnnotationTwoVariables.class.getTypeParameters(); + for (int i = 0; i < 2; i++) { + TypeVariable variable = variables[i]; + AnnotatedType[] bounds = variable.getAnnotatedBounds(); + AnnotatedType bound = bounds[0]; + AnnotatedParameterizedType parameterizedType = (AnnotatedParameterizedType) bound; + AnnotatedType[] actualTypeArguments = parameterizedType.getAnnotatedActualTypeArguments(); + Annotation[] annotations = actualTypeArguments[0].getAnnotations(); + if (annotations.length != 1 || ((TypeAnnotation) annotations[0]).value() != i) { + throw new AssertionError(); + } + } + } + + @Retention(RetentionPolicy.RUNTIME) + @Target(ElementType.TYPE_USE) + @interface TypeAnnotation { + int value(); + } +} Index: test/jdk/java/lang/reflect/AnnotatedElement/TestTypeAnnotationTypeVariableBound.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- test/jdk/java/lang/reflect/AnnotatedElement/TestTypeAnnotationTypeVariableBound.java (revision 55752+:8ae33203d600+) +++ test/jdk/java/lang/reflect/AnnotatedElement/TestTypeAnnotationTypeVariableBound.java (revision 55752+:8ae33203d600+) @@ -0,0 +1,51 @@ +/* + * Copyright (c) 2005, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * @test + * @bug 8202469 + * @summary Make sure a type variable that has another type variable as its bound receives the correct type annotation + */ + +import java.lang.annotation.Target; +import java.lang.annotation.*; +import java.lang.reflect.AnnotatedType; +import java.lang.reflect.TypeVariable; + +public class TestTypeAnnotationTypeVariableBound { + + public static void main(String[] args) { + TypeVariable[] variables = TestTypeAnnotationTypeVariableBound.class.getTypeParameters(); + TypeVariable variable = variables[1]; + AnnotatedType[] bounds = variable.getAnnotatedBounds(); + AnnotatedType bound = bounds[0]; + Annotation[] annotations = bound.getAnnotations(); + if (annotations.length != 1) { + throw new AssertionError(); + } + } + + @Retention(RetentionPolicy.RUNTIME) + @Target(ElementType.TYPE_USE) + @interface TypeAnnotation { } +} Index: test/jdk/java/lang/reflect/AnnotatedElement/TestTypeAnnotationUnionBound.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- test/jdk/java/lang/reflect/AnnotatedElement/TestTypeAnnotationUnionBound.java (revision 55752+:8ae33203d600+) +++ test/jdk/java/lang/reflect/AnnotatedElement/TestTypeAnnotationUnionBound.java (revision 55752+:8ae33203d600+) @@ -0,0 +1,64 @@ +/* + * Copyright (c) 2005, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * @test + * @bug 8202473 + * @summary Make sure that the union bounds of a type variable receive the correct type annotations + */ + +import java.lang.annotation.Target; +import java.lang.annotation.*; +import java.lang.reflect.AnnotatedParameterizedType; +import java.lang.reflect.AnnotatedType; +import java.lang.reflect.TypeVariable; +import java.util.List; +import java.util.concurrent.Callable; + +public class TestTypeAnnotationUnionBound< + U extends Callable<@TestTypeAnnotationUnionBound.TypeAnnotation(0) ?> & List<@TestTypeAnnotationUnionBound.TypeAnnotation(1) ?>> { + + public static void main(String[] args) { + TypeVariable[] variables = TestTypeAnnotationUnionBound.class.getTypeParameters(); + TypeVariable variable = variables[0]; + if (variable.getAnnotations().length > 0) { + throw new AssertionError(); + } + AnnotatedType[] bounds = variable.getAnnotatedBounds(); + for (int i = 0; i < 2; i++) { + AnnotatedType bound = bounds[i]; + AnnotatedParameterizedType parameterizedType = (AnnotatedParameterizedType) bound; + AnnotatedType[] actualTypeArguments = parameterizedType.getAnnotatedActualTypeArguments(); + Annotation[] annotations = actualTypeArguments[0].getAnnotations(); + if (annotations.length != 1 || ((TypeAnnotation) annotations[0]).value() != i) { + throw new AssertionError(); + } + } + } + + @Retention(RetentionPolicy.RUNTIME) + @Target(ElementType.TYPE_USE) + @interface TypeAnnotation { + int value(); + } +} Index: src/java.base/share/classes/sun/reflect/annotation/TypeAnnotationParser.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- src/java.base/share/classes/sun/reflect/annotation/TypeAnnotationParser.java (revision 55752:8ae33203d600a7c9f9b2be9b31a0eb8197270ab1) +++ src/java.base/share/classes/sun/reflect/annotation/TypeAnnotationParser.java (revision 55752+:8ae33203d600+) @@ -276,11 +276,21 @@ // index 1. if (bounds.length > 0) { Type b0 = bounds[0]; - if (!(b0 instanceof Class)) { - startIndex = 1; - } else { - Class c = (Class)b0; - if (c.isInterface()) { + if (!(b0 instanceof TypeVariable)) { + if (b0 instanceof Class) { + Class c = (Class) b0; + if (c.isInterface()) { + startIndex = 1; + } + } else if (b0 instanceof ParameterizedType) { + ParameterizedType p = (ParameterizedType) b0; + Type r = p.getRawType(); + if (!(r instanceof Class)) { + throw new AnnotationFormatError("Unexpected raw type: " + r); + } else if (((Class) r).isInterface()) { + startIndex = 1; + } + } else { startIndex = 1; } } @@ -295,10 +305,11 @@ l.add(t); } } + TypeAnnotation[] annon = l.toArray(EMPTY_TYPE_ANNOTATION_ARRAY); res[i] = AnnotatedTypeFactory.buildAnnotatedType(bounds[i], AnnotatedTypeFactory.nestingForType(bounds[i], loc), - l.toArray(EMPTY_TYPE_ANNOTATION_ARRAY), - candidates.toArray(EMPTY_TYPE_ANNOTATION_ARRAY), + annon, + annon, (AnnotatedElement)decl); } return res; From rafael.wth at gmail.com Tue Jul 23 18:56:23 2019 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Tue, 23 Jul 2019 20:56:23 +0200 Subject: 8202471: Resolves generic receiver type for types with generic signatures In-Reply-To: References: Message-ID: I integrated the tests into the jtreg test suite (it seems to work for me, please double check since this is my first attempt). I will now also post a CSR to the corresponding list and reference this patch. Here comes the inline patch including the jtreg tests: Index: src/java.base/share/classes/java/lang/reflect/Constructor.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- src/java.base/share/classes/java/lang/reflect/Constructor.java (revision 55752:8ae33203d600a7c9f9b2be9b31a0eb8197270ab1) +++ src/java.base/share/classes/java/lang/reflect/Constructor.java (revision 55752+:8ae33203d600+) @@ -32,6 +32,7 @@ import jdk.internal.vm.annotation.ForceInline; import sun.reflect.annotation.TypeAnnotation; import sun.reflect.annotation.TypeAnnotationParser; +import sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl; import sun.reflect.generics.repository.ConstructorRepository; import sun.reflect.generics.factory.CoreReflectionFactory; import sun.reflect.generics.factory.GenericsFactory; @@ -653,6 +654,15 @@ // static nested return null; } + + TypeVariable[] v = enclosingClass.getTypeParameters(); + Type o = resolveOwner(enclosingClass); + Type t; + if (o != null || v.length > 0) { + t = ParameterizedTypeImpl.make(enclosingClass, v, o); + } else { + t = enclosingClass; + } // A Constructor for an inner class return TypeAnnotationParser.buildAnnotatedType(getTypeAnnotationBytes0(), @@ -660,7 +670,7 @@ getConstantPool(thisDeclClass), this, thisDeclClass, - enclosingClass, + t, TypeAnnotation.TypeAnnotationTarget.METHOD_RECEIVER); } } Index: src/java.base/share/classes/java/lang/reflect/Executable.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- src/java.base/share/classes/java/lang/reflect/Executable.java (revision 55752:8ae33203d600a7c9f9b2be9b31a0eb8197270ab1) +++ src/java.base/share/classes/java/lang/reflect/Executable.java (revision 55752+:8ae33203d600+) @@ -38,6 +38,7 @@ import sun.reflect.annotation.AnnotationSupport; import sun.reflect.annotation.TypeAnnotationParser; import sun.reflect.annotation.TypeAnnotation; +import sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl; import sun.reflect.generics.repository.ConstructorRepository; /** @@ -687,14 +688,29 @@ public AnnotatedType getAnnotatedReceiverType() { if (Modifier.isStatic(this.getModifiers())) return null; + Class c = getDeclaringClass(); + TypeVariable[] v = c.getTypeParameters(); + Type o = resolveOwner(c); + Type t; + if (o != null || v.length > 0) { + t = ParameterizedTypeImpl.make(c, v, o); + } else { + t = c; + } return TypeAnnotationParser.buildAnnotatedType(getTypeAnnotationBytes0(), - SharedSecrets.getJavaLangAccess(). - getConstantPool(getDeclaringClass()), + SharedSecrets.getJavaLangAccess().getConstantPool(c), this, - getDeclaringClass(), - getDeclaringClass(), + c, + t, TypeAnnotation.TypeAnnotationTarget.METHOD_RECEIVER); } + + static Type resolveOwner(Class t) { + if (Modifier.isStatic(t.getModifiers()) || !(t.isLocalClass() || t.isMemberClass() || t.isAnonymousClass())) + return null; + Class d = t.getDeclaringClass(); + return ParameterizedTypeImpl.make(d, d.getTypeParameters(), resolveOwner(d)); + } /** * Returns an array of {@code AnnotatedType} objects that represent the use Index: test/jdk/java/lang/reflect/Method/TestReceiverTypeOwner.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- test/jdk/java/lang/reflect/Method/TestReceiverTypeOwner.java (revision 55752+:8ae33203d600+) +++ test/jdk/java/lang/reflect/Method/TestReceiverTypeOwner.java (revision 55752+:8ae33203d600+) @@ -0,0 +1,56 @@ +/* + * Copyright (c) 2005, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * @test + * @bug 8202471 + * @summary Make sure a method of a type enclosed by a parameterized type is represented by a parameterized receiver type + */ + +import java.lang.annotation.Target; +import java.lang.annotation.*; +import java.lang.reflect.AnnotatedParameterizedType; +import java.lang.reflect.AnnotatedType; +import java.lang.reflect.Method; + +public class TestReceiverTypeOwner { + + public static void main(String[] args) throws NoSuchMethodException { + Method method = TestReceiverTypeOwner.Inner.class.getDeclaredMethod("m"); + AnnotatedType receiverType = method.getAnnotatedReceiverType(); + AnnotatedParameterizedType parameterizedType = (AnnotatedParameterizedType) receiverType; + AnnotatedType owner = parameterizedType.getAnnotatedOwnerType(); + Annotation[] annotations = owner.getAnnotations(); + if (annotations.length != 1 || !(annotations[0] instanceof TypeAnnotation)) { + throw new AssertionError(); + } + } + + class Inner { + void m(@TypeAnnotation TestReceiverTypeOwner.Inner this) { } + } + + @Retention(RetentionPolicy.RUNTIME) + @Target(ElementType.TYPE_USE) + @interface TypeAnnotation { } +} Index: test/jdk/java/lang/reflect/Constructor/TestReceiverTypeParameterized.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- test/jdk/java/lang/reflect/Constructor/TestReceiverTypeParameterized.java (revision 55752+:8ae33203d600+) +++ test/jdk/java/lang/reflect/Constructor/TestReceiverTypeParameterized.java (revision 55752+:8ae33203d600+) @@ -0,0 +1,56 @@ +/* + * Copyright (c) 2005, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * @test + * @bug 8202471 + * @summary Make sure a method of a parameterized type is represented by a parameterized receiver type + */ + +import java.lang.annotation.Target; +import java.lang.annotation.*; +import java.lang.reflect.AnnotatedParameterizedType; +import java.lang.reflect.AnnotatedType; +import java.lang.reflect.Constructor; + +public class TestReceiverTypeParameterized { + + public static void main(String[] args) throws NoSuchMethodException { + Constructor constructor = TestReceiverTypeParameterized.Inner.class.getDeclaredConstructor(TestReceiverTypeParameterized.class); + AnnotatedType receiverType = constructor.getAnnotatedReceiverType(); + AnnotatedParameterizedType parameterizedType = (AnnotatedParameterizedType) receiverType; + AnnotatedType[] arguments = parameterizedType.getAnnotatedActualTypeArguments(); + Annotation[] annotations = arguments[0].getAnnotations(); + if (annotations.length != 1 || !(annotations[0] instanceof TypeAnnotation)) { + throw new AssertionError(); + } + } + + class Inner { + Inner(TestReceiverTypeParameterized<@TypeAnnotation T> TestReceiverTypeParameterized.this) { } + } + + @Retention(RetentionPolicy.RUNTIME) + @Target(ElementType.TYPE_USE) + @interface TypeAnnotation { } +} Index: test/jdk/java/lang/reflect/Method/TestReceiverTypeParameterized.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- test/jdk/java/lang/reflect/Method/TestReceiverTypeParameterized.java (revision 55752+:8ae33203d600+) +++ test/jdk/java/lang/reflect/Method/TestReceiverTypeParameterized.java (revision 55752+:8ae33203d600+) @@ -0,0 +1,54 @@ +/* + * Copyright (c) 2005, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * @test + * @bug 8202471 + * @summary Make sure a method of a parameterized type is represented by a parameterized receiver type + */ + +import java.lang.annotation.Target; +import java.lang.annotation.*; +import java.lang.reflect.AnnotatedParameterizedType; +import java.lang.reflect.AnnotatedType; +import java.lang.reflect.Method; + +public class TestReceiverTypeParameterized { + + void m(TestReceiverTypeParameterized<@TypeAnnotation T> this) { } + + public static void main(String[] args) throws NoSuchMethodException { + Method method = TestReceiverTypeParameterized.class.getDeclaredMethod("m"); + AnnotatedType receiverType = method.getAnnotatedReceiverType(); + AnnotatedParameterizedType parameterizedType = (AnnotatedParameterizedType) receiverType; + AnnotatedType[] arguments = parameterizedType.getAnnotatedActualTypeArguments(); + Annotation[] annotations = arguments[0].getAnnotations(); + if (annotations.length != 1 || !(annotations[0] instanceof TypeAnnotation)) { + throw new AssertionError(); + } + } + + @Retention(RetentionPolicy.RUNTIME) + @Target(ElementType.TYPE_USE) + @interface TypeAnnotation { } +} From andy.herrick at oracle.com Tue Jul 23 21:01:35 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 23 Jul 2019 17:01:35 -0400 Subject: RFR: JDK-8224627: Creating installer with --runtime-image on OS X fails 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). [1] https://bugs.openjdk.java.net/browse/JDK-8224627 [2] http://cr.openjdk.java.net/~herrick/8224627/webrev.01/ /Andy From andy.herrick at oracle.com Tue Jul 23 21:05:05 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 23 Jul 2019 17:05:05 -0400 Subject: RFR: JDK-8226542: DMG tests failing with java.io.IOException: Exec failed with code 1 command Message-ID: <95564544-6774-fb9d-5e6e-e9b916be1622@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). [1] https://bugs.openjdk.java.net/browse/JDK-8226542 [2] http://cr.openjdk.java.net/~herrick/8226542/ /Andy From andy.herrick at oracle.com Tue Jul 23 21:07:33 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 23 Jul 2019 17:07:33 -0400 Subject: JDK-8228402: chdir() and write() errors are not handled in jpackage 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). [1] https://bugs.openjdk.java.net/browse/JDK-8228402 [2] http://cr.openjdk.java.net/~herrick/8228402/ /Andy From naoto.sato at oracle.com Tue Jul 23 22:15:44 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 23 Jul 2019 15:15:44 -0700 Subject: [14] RFR: 8212970: TZ database in "vanguard" format support Message-ID: Hi, Please review the fix to the following enhancement: https://bugs.openjdk.java.net/browse/JDK-8212970 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8212970/webrev.09/ This change aims to support the "vanguard" IANA time zone data format, which uses the negative savings and transition time beyond a day period. The change basically translates those negative savings and transition times, such as 25:00, into the ones that the current JDK recognizes, then produces the data file "tzdb.dat" at the build time. At the run time, the data file is read and interpreted as before. This way the produced tzdb.dat is compatible with the prior JDK releases so that the TZ Updater can also distribute it as a time zone update. I have also refactored redundant copy of ZoneRules file in the build directory, by dynamically importing the file under src. Thus some build related files are modified. I am hoping folks on the build-dev can review those changes. Naoto From brian.burkhalter at oracle.com Wed Jul 24 00:09:24 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 23 Jul 2019 17:09:24 -0700 Subject: 8078891: java.io.SequenceInputStream.close is not atomic and not idempotent Message-ID: <6824EDFA-BF3F-40A5-A872-527631868BD4@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8078891 http://cr.openjdk.java.net/~bpb/8078891/webrev.00/ Ensure that SequenceInputStream closes all component streams. Thanks, Brian From iris.clark at oracle.com Wed Jul 24 00:18:16 2019 From: iris.clark at oracle.com (Iris Clark) Date: Tue, 23 Jul 2019 17:18:16 -0700 (PDT) Subject: RFR: 8228397: Missing license copyright header in some resource properties files In-Reply-To: References: Message-ID: <75f1d9af-84f6-4a65-91f9-d5e6a013e1c7@default> Hi, Leo., This updated webrev looks fine. Thanks for fixing! iris -----Original Message----- From: Leo Jiang Sent: Tuesday, July 23, 2019 12:08 AM To: Mandy Chung Cc: jdk-dev ; core-libs-dev Subject: Re: RFR: 8228397: Missing license copyright header in some resource properties files Thank you for your reviewing. Updated the webrev: http://cr.openjdk.java.net/~ljiang/8228397/webrev.01/ I know the update is trivial, if no more suggestion I will push the patch tomorrow. Thanks, Leo On 7/23/19 3:55 AM, Mandy Chung wrote: > Hi Leo, > > Thanks for adding the copyright and license header.? The patch looks > okay assuming you will separate the legal notices from the existing > comment block in JFC properties files. > > Mandy > > On 7/22/19 9:23 AM, li.jiang at oracle.com wrote: >> Hi all, >> >> Please review this change. >> >> We found the license copyright header are missing in some resource >> properties files, some of them are very old and no hg log since code >> forest consolidation. In this change, I added the license copyright >> header in the English and its localized resource files. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8228397 >> Webrev: http://cr.openjdk.java.net/~ljiang/8228397/webrev.00/ >> >> Thanks, >> Leo >> > From david.holmes at oracle.com Wed Jul 24 01:31:00 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Jul 2019 11:31:00 +1000 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: 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> Message-ID: <8d3cb0c6-d399-c839-79d7-231a80d50226@oracle.com> Jumping in here as this change is starting to really confuse me ... On 24/07/2019 2:41 am, Brian Burkhalter wrote: > > >> On Jul 23, 2019, at 8:27 AM, Brian Burkhalter wrote: >> >>> On Jul 23, 2019, at 8:20 AM, Alan Bateman > wrote: >>> >>> On 23/07/2019 16:08, Brian Burkhalter wrote: >>>> >>>> I don?t see what you mean. >>>> @Override >>>> public void write(byte buf[]) throws IOException { >>>> super.write(buf); >>>> } >>>> Should ?trouble? be set and the IOE re-thrown? >>>> >>> super.write(byte[]) will invoke PrintStream overrides write(byte[], int, int) so IOE won't be thrown (and why the proposed change to the class description isn't right). The method description is probably the best place to describe the behavior. > > Here is an update which accounts for the foregoing comments. > > http://cr.openjdk.java.net/~bpb/8187898/webrev-alt.02/ 609 @Override 610 public void write(byte buf[]) throws IOException { 611 super.write(buf, 0, buf.length); 612 } This is wrong! The whole point of this bug is to ensure that PrintStream methods honour its contract of NEVER throwing IOException. I mean that is what the bug synopsis and description are all about! David ----- > Thanks, > > Brian > From david.holmes at oracle.com Wed Jul 24 02:00:44 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Jul 2019 12:00:44 +1000 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: <8d3cb0c6-d399-c839-79d7-231a80d50226@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> <8d3cb0c6-d399-c839-79d7-231a80d50226@oracle.com> Message-ID: <11bde446-9e16-8efa-e61b-e51cd0d4fd3c@oracle.com> Sorry I was obviously missing the part of this thread where it was decided to not actually fix this as requested in the bug due to compatibility issues. I agree with Brian that something must be added to the class-level javadoc explaining that due to a historical oversight there is one method that declares it throws IOException (and can actually throw it?). I don't see why that method couldn't still honour the checkError protocol as well though. David On 24/07/2019 11:31 am, David Holmes wrote: > Jumping in here as this change is starting to really confuse me ... > > On 24/07/2019 2:41 am, Brian Burkhalter wrote: >> >> >>> On Jul 23, 2019, at 8:27 AM, Brian Burkhalter >>> wrote: >>> >>>> On Jul 23, 2019, at 8:20 AM, Alan Bateman >>> > wrote: >>>> >>>> On 23/07/2019 16:08, Brian Burkhalter wrote: >>>>> >>>>> I don?t see what you mean. >>>>> ??? @Override >>>>> ??? public void write(byte buf[]) throws IOException { >>>>> ??????? super.write(buf); >>>>> ??? } >>>>> Should ?trouble? be set and the IOE re-thrown? >>>>> >>>> super.write(byte[]) will invoke PrintStream overrides write(byte[], >>>> int, int) so IOE won't be thrown (and why the proposed change to the >>>> class description isn't right). The method description is probably >>>> the best place to describe the behavior. >> >> Here is an update which accounts for the foregoing comments. >> >> http://cr.openjdk.java.net/~bpb/8187898/webrev-alt.02/ > > ?609???? @Override > ?610???? public void write(byte buf[]) throws IOException { > ?611???????? super.write(buf, 0, buf.length); > ?612???? } > > This is wrong! The whole point of this bug is to ensure that PrintStream > methods honour its contract of NEVER throwing IOException. I mean that > is what the bug synopsis and description are all about! > > David > ----- > >> Thanks, >> >> Brian >> From alexander.matveev at oracle.com Wed Jul 24 03:01:41 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Tue, 23 Jul 2019 20:01:41 -0700 Subject: RFR: JDK-8224627: Creating installer with --runtime-image on OS X fails In-Reply-To: References: Message-ID: Hi Andy, Looks fine. Thanks, Alexander On 7/23/2019 2:01 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). > > [1] https://bugs.openjdk.java.net/browse/JDK-8224627 > > [2] http://cr.openjdk.java.net/~herrick/8224627/webrev.01/ > > /Andy > From alexander.matveev at oracle.com Wed Jul 24 03:12:24 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Tue, 23 Jul 2019 20:12:24 -0700 Subject: RFR: JDK-8226542: DMG tests failing with java.io.IOException: Exec failed with code 1 command In-Reply-To: <95564544-6774-fb9d-5e6e-e9b916be1622@oracle.com> References: <95564544-6774-fb9d-5e6e-e9b916be1622@oracle.com> Message-ID: <1a9b1128-8499-5c33-70b9-5eddc75c6a0c@oracle.com> Hi Andy, Looks fine. If I understood correctly default script was just opening DMG file in finder after it was generated, correct? Thanks, Alexander On 7/23/2019 2:05 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). > > [1] https://bugs.openjdk.java.net/browse/JDK-8226542 > > [2] http://cr.openjdk.java.net/~herrick/8226542/ > > /Andy > > From alexander.matveev at oracle.com Wed Jul 24 03:21:46 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Tue, 23 Jul 2019 20:21:46 -0700 Subject: JDK-8228402: chdir() and write() errors are not handled in jpackage In-Reply-To: References: Message-ID: Hi Andy, I think it is better not to use assert() in this case since it terminates app abnormally. Do we really should terminate execution if write() fails in this case? Can we ignore error? It might be better to handle it gracefully and then return from main() with error if we cannot ignore error. Thanks, Alexander On 7/23/2019 2: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). > > [1] https://bugs.openjdk.java.net/browse/JDK-8228402 > > [2] http://cr.openjdk.java.net/~herrick/8228402/ > > /Andy > From matthias.baesken at sap.com Wed Jul 24 06:48:10 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 24 Jul 2019 06:48:10 +0000 Subject: RFR: 8228501: java_props_macosx.c - provide missing CFRelease for CFLocaleCopyCurrent was: RE: java_props_macosx.c : CFLocaleCopyCurrent() needs CFRelease ? In-Reply-To: <72555273-a397-502e-ee79-1d1679e1f47c@oracle.com> References: <72555273-a397-502e-ee79-1d1679e1f47c@oracle.com> Message-ID: Thanks for the review . Will push it tomorrow in case there are no objections . Could you (or someone ?? ) comment on the other one too ? https://hg.openjdk.java.net/jdk/jdk/file/aaa83519e723/src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m#l522 CFDataRef cfDataToImport = CFDataCreate(kCFAllocatorDefault, (UInt8 *)rawData, dataSize); .... err = SecKeychainItemImport(cfDataToImport, NULL, &dataFormat, NULL, 0, ¶mBlock, defaultKeychain, &createdItems); Thanks, Matthias > -----Original Message----- > From: naoto.sato at oracle.com > Sent: Dienstag, 23. Juli 2019 18:39 > To: Baesken, Matthias ; core-libs- > dev at openjdk.java.net > Subject: Re: RFR: 8228501: java_props_macosx.c - provide missing CFRelease > for CFLocaleCopyCurrent was: RE: java_props_macosx.c : > CFLocaleCopyCurrent() needs CFRelease ? > > Thanks, Matthias. Changes look good to me. > > I think it is hard to provide a regression test for this change, then > please add noreg-hard label to the issue. > > Naoto > > On 7/23/19 4:23 AM, Baesken, Matthias wrote: > > Hello, please review the following fix that adds CFRelease to 2 > CFLocaleCopyCurrent usages . > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8228501 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8228501.0/ > > > > Best regards, Matthias > > > > From Alan.Bateman at oracle.com Wed Jul 24 06:58:52 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 24 Jul 2019 07:58:52 +0100 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: 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> Message-ID: <4f71aae6-8250-67aa-c4ee-d206037af50e@oracle.com> On 23/07/2019 17:41, Brian Burkhalter wrote: > : > > Here is an update which accounts for the foregoing comments. > > http://cr.openjdk.java.net/~bpb/8187898/webrev-alt.02/ > I looked at this version, and webrev-alt.03, but I think PS.write(byte[]) will need further word smiting to properly explain the confusion on using PrintStream vs. sub-classes of PrintStream that override this method (the former does not throw IOE, the latter may). So I think the @apiNote will be expanded further and the recommendation to use writeBytes(byte[]) or write(byte[],0,len) instead should be dialed up. The @implSpec also needs to be expanded as it doesn't make it clear that the default implementation (by way of invoking super.write(byte[],int,int)) does not throw IOE. I'm also wondering if PS.write(byte[]) should be deprecated. Hard to know how much time to spend on this issue as it has existed since JDK 1.0. -Alan From matthias.baesken at sap.com Wed Jul 24 07:52:57 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 24 Jul 2019 07:52:57 +0000 Subject: RFR: 8228501: java_props_macosx.c - provide missing CFRelease for CFLocaleCopyCurrent was: RE: java_props_macosx.c : CFLocaleCopyCurrent() needs CFRelease ? References: <72555273-a397-502e-ee79-1d1679e1f47c@oracle.com> Message-ID: Hello, seems we need another "CFRelease(cflocale)" in an early return case (see the default: ...) , new webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8228501.1/ Best regards, Matthias > -----Original Message----- > From: Baesken, Matthias > Sent: Mittwoch, 24. Juli 2019 08:48 > To: 'naoto.sato at oracle.com' ; core-libs- > dev at openjdk.java.net > Subject: RE: RFR: 8228501: java_props_macosx.c - provide missing CFRelease > for CFLocaleCopyCurrent was: RE: java_props_macosx.c : > CFLocaleCopyCurrent() needs CFRelease ? > > Thanks for the review . > > Will push it tomorrow in case there are no objections . > > Could you (or someone ?? ) comment on the other one too ? > > https://hg.openjdk.java.net/jdk/jdk/file/aaa83519e723/src/java.base/macos > x/native/libosxsecurity/KeystoreImpl.m#l522 > > > CFDataRef cfDataToImport = CFDataCreate(kCFAllocatorDefault, (UInt8 > *)rawData, dataSize); > .... > > err = SecKeychainItemImport(cfDataToImport, NULL, &dataFormat, NULL, > 0, ¶mBlock, defaultKeychain, &createdItems); > > > Thanks, Matthias > > > > -----Original Message----- > > From: naoto.sato at oracle.com > > Sent: Dienstag, 23. Juli 2019 18:39 > > To: Baesken, Matthias ; core-libs- > > dev at openjdk.java.net > > Subject: Re: RFR: 8228501: java_props_macosx.c - provide missing > CFRelease > > for CFLocaleCopyCurrent was: RE: java_props_macosx.c : > > CFLocaleCopyCurrent() needs CFRelease ? > > > > Thanks, Matthias. Changes look good to me. > > > > I think it is hard to provide a regression test for this change, then > > please add noreg-hard label to the issue. > > > > Naoto > > > > On 7/23/19 4:23 AM, Baesken, Matthias wrote: > > > Hello, please review the following fix that adds CFRelease to 2 > > CFLocaleCopyCurrent usages . > > > > > > Bug/webrev : > > > > > > https://bugs.openjdk.java.net/browse/JDK-8228501 > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8228501.0/ > > > > > > Best regards, Matthias > > > > > > From claes.redestad at oracle.com Wed Jul 24 09:42:27 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 24 Jul 2019 11:42:27 +0200 Subject: RFR: 8228507: Archive FDBigInteger Message-ID: <56dfa19a-76c7-3318-bb6f-7e1a04c9cb44@oracle.com> Hi, any double<->String conversion will trigger load of jdk.internal.math.FDBigInteger, which has a static initializer pre-calculating a relatively large number of values. Archiving these pre-calculated values reduces the time spent in FDBigInteger. from a couple of milliseconds down to "nothing". Bug: https://bugs.openjdk.java.net/browse/JDK-8228507 Webrev: http://cr.openjdk.java.net/~redestad/8228507/open.00/ Testing: tier1-3 Thanks! /Claes From martin.doerr at sap.com Wed Jul 24 10:14:17 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 24 Jul 2019 10:14:17 +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, 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 On Behalf Of Baesken, Matthias Sent: Dienstag, 23. Juli 2019 17:15 To: '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' 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 vlv.spb.ru at mail.ru Wed Jul 24 10:53:01 2019 From: vlv.spb.ru at mail.ru (=?UTF-8?B?VmxhZGltaXIgWWFyb3NsYXZza2l5?=) Date: Wed, 24 Jul 2019 13:53:01 +0300 Subject: =?UTF-8?B?QnVnIGluIHBhcmFsbGVsIHNvcnRpbmcgb2YgZmxvYXQgLyBkb3VibGU=?= Message-ID: <1563965581.761373630@f352.i.mail.ru> Hi all, I've found bug in parallel sorting of float / double arrays in the latest JDK. When float / double values are sorted, additional actions are required: NaNs must be moved to the end and negative zeros must be placed before positive zeros. Current implementation of Arrays.parallelSort(float[] / double []) invokes parallel merge sort from ArraysParallelSortHelpers class, but it doesn't arrange NaNs and -0.0. @Alan, Brent, Laurent Could you please file a bug? New optimized version of DualPivotQuicksort (which is under review) works fine and doesn't contain this bug. Please, look at my test case to reproduce it. ---------------------------------------------------------------------------------------------------------------------- import java.util.Random; public class FailedFloat { private static final int MAX_N = (1 << 13) /* Arrays.MIN_ARRAY_SORT_GRAN */ + 10; public static void main(String[] args) { float[] a = new float[MAX_N]; random(a); java.util.Arrays.parallelSort(a); check(a); System.out.println("PASSED"); } private static void random(float[] a) { Random random = new Random(777); for (int i = 0; i < MAX_N; i++) { a[i] = random.nextBoolean() ? -0.0f : 0.0f; } } private static void check(float[] a) { for (int i = 0; i < a.length - 1; ++i) { if (Float.floatToRawIntBits(a[i]) == 0 && Float.floatToRawIntBits(a[i + 1]) < 0) { throw new RuntimeException(a[i] + " goes before "+ a[i + 1] + " at position " + i); } } } } ------------------------------------------------------------------------------------------------------------------------ Thank you, Vladimir From matcdac at gmail.com Wed Jul 24 12:19:00 2019 From: matcdac at gmail.com (Prakhar Makhija) Date: Wed, 24 Jul 2019 17:49:00 +0530 Subject: [JSR] [JEP] Java Specification Requirement / Java Enhancement Proposal : 'Parallel OR' and 'Parallel AND' Message-ID: Hi David / All, Earlier wanted to discuss just the implementation of 'OR operator', neither 'Conditional OR operator', nor 'Bitwise OR operator' Same goes with 'AND operator' Technically OR operator and AND operator are just binary operators, that's true I don't find it wrong considering there can be n operands, in an expression, with either of the two operators or a combination of both, where n >= 2 n can go nearby anything in powers of 10, it will take those many sequential clock cycles, to actually resolve the expression If you consider the same n as an expression of powers of 2, the same thing can be done in parallel clubbed with divide and conquer, taking the same number of clock cycles, but saving actual response time This can be given as a input from console, or as a property, specifying which implementation to use at runtime, sequential or parallel But with the latter would lead to very frequent resource starvage, this would need to be handled, to actually free the resources and give to pid or ppid, heirarically, or based upon who is the callee, or who asked who to wait, or some more other logic All the threads parallelly evaluating the same expression, with either operand, should be terminated and concluded as, when any thread results to: 'true' in case of OR 'false' in case of AND An expression can have further sub-expressions; so an expression with combination of both operands, will be considered as parent expression Yes it does change the conventional implementation of OR operator, and AND operator, in Java So it would be better to have two new operators/symbols itself Parallel OR ||| Parallel AND &&& We can go with the symbol |&& also in case of Parallel AND Looking forward to hearing your thoughts Best Wishes & Regards Prakhar Makhija ---- Hi Prakhar, On 22/06/2019 1:28 am, Prakhar Makhija wrote: > Topic: OR operator represented by || That should be the subject of your email - not a reply to a digest. > Query: The expression evaluation of the operands, of OR operator, does it > happen in parallel, when Java code runs, in the current versions? No, there is no parallel evaluation of anything in Java. It would be wrong to do so in this case as: "The conditional-or operator || operator is like | (?15.22.2), but evaluates its righthand operand only if the value of its left-hand operand is false." David From andy.herrick at oracle.com Wed Jul 24 12:18:40 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 24 Jul 2019 08:18:40 -0400 Subject: JDK-8228402: chdir() and write() errors are not handled in jpackage In-Reply-To: References: Message-ID: I used assert because: 1.) I don't think it could ever happen. 2.) If it did happen it might be easier to debug with the assert than without it 3.) I thought it would be difficult to propagate the error. but perhaps (3) is not true. would it be better (ignoring types for now) to: > ??? len = write(FInputHandle, Value.data(), Value.size()); > > ??? if (len != Value.size()) { > > ??????????? throw Exception(_T("Internal Error - write failed")); > > ??? } > /Andy On 7/23/2019 11:21 PM, Alexander Matveev wrote: > Hi Andy, > > I think it is better not to use assert() in this case since it > terminates app abnormally. > Do we really should terminate execution if write() fails in this case? > Can we ignore error? > It might be better to handle it gracefully and then return from main() > with error if we cannot ignore error. > > Thanks, > Alexander > > On 7/23/2019 2: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). >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8228402 >> >> [2] http://cr.openjdk.java.net/~herrick/8228402/ >> >> /Andy >> > From pavel.rappo at oracle.com Wed Jul 24 12:25:34 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 24 Jul 2019 13:25:34 +0100 Subject: DnsClient TCP socket timeout Message-ID: <726EF757-773A-4E02-BF1C-A1A5EFF106DF@oracle.com> I have created an issue to track this: https://bugs.openjdk.java.net/browse/JDK-8228580 > Hello list > > Have you ever considered the problem reported here: > > https://stackoverflow.com/questions/14603553/dns-query-freezes-with-dnscontextfactory-in-java > > > A DNS query gets stuck easily if read timeout is not set on the > socket. The proposed solution is trivial. I can author the change, if > I can have it sponsored. > > > -- > Milan Mimica From david.holmes at oracle.com Wed Jul 24 12:39:05 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Jul 2019 22:39:05 +1000 Subject: Bug in parallel sorting of float / double In-Reply-To: <1563965581.761373630@f352.i.mail.ru> References: <1563965581.761373630@f352.i.mail.ru> Message-ID: Hi Vladimir, On 24/07/2019 8:53 pm, Vladimir Yaroslavskiy wrote: > Hi all, > > I've found bug in parallel sorting of float / double arrays in the latest JDK. > > When float / double values are sorted, additional actions are > required: NaNs must be moved to the end and negative zeros > must be placed before positive zeros. > > Current implementation of Arrays.parallelSort(float[] / double []) > invokes parallel merge sort from ArraysParallelSortHelpers class, > but it doesn't arrange NaNs and -0.0. It ultimately uses DualPivotQuicksort which AFAICS does have code to arrange NaNS: static void sort(float[] a, int left, int right, float[] work, int workBase, int workLen) { /* * Phase 1: Move NaNs to the end of the array. */ while (left <= right && Float.isNaN(a[right])) { --right; } and also order +/-0 /* * Phase 3: Place negative zeros before positive zeros. */ where does the bug arise? Thanks, David ----- > @Alan, Brent, Laurent > Could you please file a bug? > > New optimized version of DualPivotQuicksort (which is under review) works fine and > doesn't contain this bug. Please, look at my test case to reproduce it. > > ---------------------------------------------------------------------------------------------------------------------- > import java.util.Random; > > public class FailedFloat { > > private static final int MAX_N = (1 << 13) /* Arrays.MIN_ARRAY_SORT_GRAN */ + 10; > > public static void main(String[] args) { > float[] a = new float[MAX_N]; > random(a); > java.util.Arrays.parallelSort(a); > check(a); > System.out.println("PASSED"); > } > > private static void random(float[] a) { > Random random = new Random(777); > for (int i = 0; i < MAX_N; i++) { > a[i] = random.nextBoolean() ? -0.0f : 0.0f; > } > } > > private static void check(float[] a) { > for (int i = 0; i < a.length - 1; ++i) { > if (Float.floatToRawIntBits(a[i]) == 0 && Float.floatToRawIntBits(a[i + 1]) < 0) { > throw new RuntimeException(a[i] + " goes before "+ a[i + 1] + " at position " + i); > } > } > } > } > ------------------------------------------------------------------------------------------------------------------------ > Thank you, > Vladimir > From vlv.spb.ru at mail.ru Wed Jul 24 12:58:19 2019 From: vlv.spb.ru at mail.ru (=?UTF-8?B?VmxhZGltaXIgWWFyb3NsYXZza2l5?=) Date: Wed, 24 Jul 2019 15:58:19 +0300 Subject: =?UTF-8?B?UmVbMl06IEJ1ZyBpbiBwYXJhbGxlbCBzb3J0aW5nIG9mIGZsb2F0IC8gZG91?= =?UTF-8?B?Ymxl?= In-Reply-To: References: <1563965581.761373630@f352.i.mail.ru> Message-ID: <1563973099.30911139@f507.i.mail.ru> Hi?David, Please, see how it works: Arrays.parallelSort(double[]) invokes?ArraysParallelSortHelpers.FJDouble.Sorter if size is big enough and?ForkJoinPool.getCommonPoolParallelism()) > 1. FJDouble.Sorter divides given array into 4 parts, sorts them recursively in parallel and merges these parts. Finally?DualPivotQuicksort is invoked on small parts and only on this step NaNs and -0.0s are arranged. In other words,?NaNs and -0.0s are?arranged inside each small parts, but this action must be done once before the first splitting of the array. Thank you, Vladimir >?????, 24 ???? 2019, 15:39 +03:00 ?? David Holmes : > >Hi Vladimir, > >On 24/07/2019 8:53 pm, Vladimir Yaroslavskiy wrote: >> Hi all, >> >> I've found bug in parallel sorting of float / double arrays in the latest JDK. >> >> When float / double values are sorted, additional actions are >> required: NaNs must be moved to the end and negative zeros >> must be placed before positive zeros. >> >> Current implementation of Arrays.parallelSort(float[] / double []) >> invokes parallel merge sort from ArraysParallelSortHelpers class, >> but it doesn't arrange NaNs and -0.0. > >It ultimately uses DualPivotQuicksort which AFAICS does have code to >arrange NaNS: > >?????static void sort(float[] a, int left, int right, >??????????????????????float[] work, int workBase, int workLen) { >?????????/* >??????????* Phase 1: Move NaNs to the end of the array. >??????????*/ >?????????while (left <= right && Float.isNaN(a[right])) { >?????????????--right; >?????????} > >and also order +/-0 > >??????/* >???????* Phase 3: Place negative zeros before positive zeros. >???????*/ > >where does the bug arise? > >Thanks, >David >----- > > >> @Alan, Brent, Laurent >> Could you please file a bug? >> >> New optimized version of DualPivotQuicksort (which is under review) works fine and >> doesn't contain this bug. Please, look at my test case to reproduce it. >> >> ---------------------------------------------------------------------------------------------------------------------- >> import java.util.Random; >> >> public class FailedFloat { >> >> private static final int MAX_N = (1 << 13) /* Arrays.MIN_ARRAY_SORT_GRAN */ + 10; >> >> public static void main(String[] args) { >> float[] a = new float[MAX_N]; >> random(a); >> java.util.Arrays.parallelSort(a); >> check(a); >> System.out.println("PASSED"); >> } >> >> private static void random(float[] a) { >> Random random = new Random(777); >> for (int i = 0; i < MAX_N; i++) { >> a[i] = random.nextBoolean() ? -0.0f : 0.0f; >> } >> } >> >> private static void check(float[] a) { >> for (int i = 0; i < a.length - 1; ++i) { >> if (Float.floatToRawIntBits(a[i]) == 0 && Float.floatToRawIntBits(a[i + 1]) < 0) { >> throw new RuntimeException(a[i] + " goes before "+ a[i + 1] + " at position " + i); >> } >> } >> } >> } >> ------------------------------------------------------------------------------------------------------------------------ >> Thank you, >> Vladimir From david.holmes at oracle.com Wed Jul 24 13:15:29 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Jul 2019 23:15:29 +1000 Subject: Bug in parallel sorting of float / double In-Reply-To: <1563973099.30911139@f507.i.mail.ru> References: <1563965581.761373630@f352.i.mail.ru> <1563973099.30911139@f507.i.mail.ru> Message-ID: <004c5e3c-f0f4-172c-6718-bc85667a2b24@oracle.com> Hi Vladimir, On 24/07/2019 10:58 pm, Vladimir Yaroslavskiy wrote: > Hi?David, > > Please, see how it works: Arrays.parallelSort(double[]) > invokes?ArraysParallelSortHelpers.FJDouble.Sorter > if size is big enough and?ForkJoinPool.getCommonPoolParallelism()) > 1. > > FJDouble.Sorter divides given array into 4 parts, sorts them recursively > in parallel and merges these parts. > Finally?DualPivotQuicksort is invoked on small parts and only on this > step NaNs and -0.0s are arranged. > In other words,?NaNs and -0.0s are?arranged inside each small parts, but > this action must be > done once before the first splitting of the array. My understanding** was that the merge of the correctly sorted sub-arrays would correctly cause NaNs to bubble to the end as required, while zeroes would also group - though I think I can see now that simply using < would not correctly order NaNs relative to other values, nor order -0.0 and +0.0 ** It's been 7 years since I helped Doug Lea put the parallelising code into the JDK so I'm a bit rusty on the details :) and I'm surprised such a bug has not been detected before now. Cheers, David > Thank you, > Vladimir > > ?????, 24 ???? 2019, 15:39 +03:00 ?? David Holmes > : > > Hi Vladimir, > > On 24/07/2019 8:53 pm, Vladimir Yaroslavskiy wrote: > > Hi all, > > > > I've found bug in parallel sorting of float / double arrays in > the latest JDK. > > > > When float / double values are sorted, additional actions are > > required: NaNs must be moved to the end and negative zeros > > must be placed before positive zeros. > > > > Current implementation of Arrays.parallelSort(float[] / double []) > > invokes parallel merge sort from ArraysParallelSortHelpers class, > > but it doesn't arrange NaNs and -0.0. > > It ultimately uses DualPivotQuicksort which AFAICS does have code to > arrange NaNS: > > ?????static void sort(float[] a, int left, int right, > ??????????????????????float[] work, int workBase, int workLen) { > ?????????/* > ??????????* Phase 1: Move NaNs to the end of the array. > ??????????*/ > ?????????while (left <= right && Float.isNaN(a[right])) { > ?????????????--right; > ?????????} > > and also order +/-0 > > ??????/* > ???????* Phase 3: Place negative zeros before positive zeros. > ???????*/ > > where does the bug arise? > > Thanks, > David > ----- > > > > @Alan, Brent, Laurent > > Could you please file a bug? > > > > New optimized version of DualPivotQuicksort (which is under > review) works fine and > > doesn't contain this bug. Please, look at my test case to > reproduce it. > > > > > ---------------------------------------------------------------------------------------------------------------------- > > import java.util.Random; > > > > public class FailedFloat { > > > > private static final int MAX_N = (1 << 13) /* > Arrays.MIN_ARRAY_SORT_GRAN */ + 10; > > > > public static void main(String[] args) { > > float[] a = new float[MAX_N]; > > random(a); > > java.util.Arrays.parallelSort(a); > > check(a); > > System.out.println("PASSED"); > > } > > > > private static void random(float[] a) { > > Random random = new Random(777); > > for (int i = 0; i < MAX_N; i++) { > > a[i] = random.nextBoolean() ? -0.0f : 0.0f; > > } > > } > > > > private static void check(float[] a) { > > for (int i = 0; i < a.length - 1; ++i) { > > if (Float.floatToRawIntBits(a[i]) == 0 && > Float.floatToRawIntBits(a[i + 1]) < 0) { > > throw new RuntimeException(a[i] + " goes before "+ a[i + 1] + " > at position " + i); > > } > > } > > } > > } > > > ------------------------------------------------------------------------------------------------------------------------ > > Thank you, > > Vladimir > From claes.redestad at oracle.com Wed Jul 24 13:28:11 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 24 Jul 2019 15:28:11 +0200 Subject: RFR: 8228581: Archive BigInteger constants Message-ID: <861003b5-4f12-cf12-9cfe-395177a1ba2f@oracle.com> Hi, BigInteger has a number of pre-calculated constants that are profitable to put up for archiving. This reduces initialization time of BigInteger by 0.3-0.5ms, and archives ~12Kb worth of objects. Bug: https://bugs.openjdk.java.net/browse/JDK-8228581 Webrev: http://cr.openjdk.java.net/~redestad/8228581/open.00/ Webrev is applied on top of patch for https://bugs.openjdk.java.net/browse/JDK-8228507 - which I've tested alongside this. Testing: tier1-2 Thanks! /Claes From dmitry.chuyko at bell-sw.com Wed Jul 24 14:30:17 2019 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Wed, 24 Jul 2019 17:30:17 +0300 Subject: RFR (S): JDK-8222778: Packaging Tool (JEP 343) on Linux/AArch64 In-Reply-To: <28da2683-40a9-80be-9d35-63d7976557c6@redhat.com> References: <234f1c54-bd2a-c90b-367b-e279062218ff@bell-sw.com> <0ec8f547-8e21-7fd2-1091-886dc7a4d2b1@bell-sw.com> <28da2683-40a9-80be-9d35-63d7976557c6@redhat.com> Message-ID: Webrev without chdir() and write() changes: http://cr.openjdk.java.net/~dchuyko/8222778/webrev.03/ When it is applied together with webrev.01 [1] from JDK-8228402, sandbox is compiled and passes same jpackage tests on x86, aarch64 and other platforms. -Dmitry [1] http://cr.openjdk.java.net/~herrick/8228402/ On 7/19/19 11:31 AM, Andrew Haley wrote: > On 7/19/19 12:36 AM, Dmitry Chuyko wrote: >> On 7/18/19 11:57 AM, Andrew Haley wrote: >>> Hi, >>> >>> On 7/17/19 10:19 PM, Dmitry Chuyko wrote: >>>> On 7/17/19 11:52 AM, Andrew Haley wrote: >>>>> This is weird: >>>>> >>>>> --- old/src/jdk.jpackage/linux/native/libapplauncher/LinuxPlatform.cpp 2019-07-16 22:11:30.200258978 +0300 >>>>> +++ new/src/jdk.jpackage/linux/native/libapplauncher/LinuxPlatform.cpp 2019-07-16 22:11:29.867374851 +0300 >>>>> @@ -127,7 +127,7 @@ >>>>> } >>>>> >>>>> void LinuxPlatform::SetCurrentDirectory(TString Value) { >>>>> - chdir(PlatformString(Value).toPlatformString()); >>>>> + int ignored = chdir(PlatformString(Value).toPlatformString()); >>>>> } >>>>> >>>>> Firstly it does not fix the problem: you've gone from an unused value to an >>>>> unused variable. Secondly, we ignore the return value of printf all the time; >>>>> what's different about this one? >>>> chdir() is __wur, which is /usr/include/aarch64-linux-gnu/sys/cdefs.h:# >>>> define __wur __attribute_warn_unused_result__ >>> OK, got it. >>> >>>> In some places this warning is disabled (CoreLibraries.gmk, >>>> Awt2dLibraries.gmk). >>>> >>>> It would be more correct to handle the result here as chdir might not >>>> succeeded in fact. >>> Very much so. We shouldn't try to "shut up the compiler" in this way.Andrew Haley >> I created a separate bug about chdir() and write() usages: >> https://bugs.openjdk.java.net/browse/JDK-8228402 >> >> Does it look good to silence warnings for platforms support changes? > I think we should fix the bugs, not silence the warnings. > >> One >> more option could be to exclude related changes from current review. > OK. > From Alan.Bateman at oracle.com Wed Jul 24 14:32:54 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 24 Jul 2019 15:32:54 +0100 Subject: Review Request: JDK-8173978: Lookup.in should allow teleporting from a lookup class in a named module without dropping all access In-Reply-To: References: <77478136-29fd-45f9-d122-6826099dfe84@oracle.com> <847246aa-fa7a-5781-a973-5eb021a294e3@oracle.com> <76395107-8da7-4bdf-66ec-b5f9f1459284@oracle.com> <4edca042-a3f9-0a4f-bc1c-a948da0fcf2f@oracle.com> <9d1efa00-d179-ebc4-42de-dcfd452ea3e9@gmail.com> Message-ID: On 23/07/2019 19:51, Mandy Chung wrote: > (Coming back to this patch and ready to push this change later today) > > Here is the updated webrev: > ?? http://cr.openjdk.java.net/~mchung/jdk14/8173978/webrev.02/ > > This includes the change that Peter suggested accepting m2 == null. The updated isModuleAccessible looks okay to me. -Alan From mandy.chung at oracle.com Wed Jul 24 15:06:43 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 24 Jul 2019 08:06:43 -0700 Subject: Review Request: JDK-8219774: Reexamine the initialization of LangReflectAccess shared secret at AccessibleObject:: In-Reply-To: <4d936b7b-7fc7-f859-a96c-914426548278@oracle.com> References: <4d936b7b-7fc7-f859-a96c-914426548278@oracle.com> Message-ID: <641a862f-3047-9dc6-7b08-d36fcb39b5d6@oracle.com> Hi David, Thanks for the review.?? I missed to include you in the reviewer list.? Sorry about that. Mandy On 7/21/19 11:19 PM, David Holmes wrote: > Hi Mandy, > > This approach looks much cleaner and safer to me, and the slight > shuffling in the init order should not cause any startup issues. > > Thanks, > David > ----- > > On 20/07/2019 2:20 am, Mandy Chung wrote: >> This was a follow up to the observation during the code review >> of JDK-82193798. >> >> Webrev: >> ??? http://cr.openjdk.java.net/~mchung/jdk14/8219774/webrev.01/ >> >> In the current implementation, Modifier:: provides a hook >> to initialize the static ReflectionFactory::langReflectAccess field >> lazily. This was introduced prior to the common shared secrets >> mechanism. >> >> Another observation is that when ReflectionFactory methods are called, >> there is a Method, Field or Constructor object in hand. In addition, >> Method class is initialized very early during startup by the VM and >> so does AccessibleObject class. The ReflectionFactory::newField and >> newMethod taking the Field/Method parameter are used but not the >> one without (dead code). >> >> This patch cleans up the initialization of LangReflectAccess to >> AccessibleObject:: during early startup initPhase1. >> I also move LangReflectAccess to jdk.internal.access to be consistent >> with other *Access classes (LangReflectAccess was added before the >> common >> SharedSecrets class was introduced). >> >> This also addresses JDK-8227831 the overhead of langReflectAcces being >> a volatile field on the platform with weak memory model (Thanks to >> Ogata confirming that this patch is 4% better than the proposed patch >> for JDK-8227831 [1]). >> >> The impact to the class initialization order is minimal. >> JavaLangReflectAccess >> is initialized during initPhase1 (which has been initialized during >> initPhase2). >> SharedSecrets is initialized in initPhase2 and this patch moves it to be >> initialized followed AccessibleObject. >> >> Mandy >> [1] >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-July/061352.html From naoto.sato at oracle.com Wed Jul 24 15:42:56 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 24 Jul 2019 08:42:56 -0700 Subject: RFR: 8228501: java_props_macosx.c - provide missing CFRelease for CFLocaleCopyCurrent was: RE: java_props_macosx.c : CFLocaleCopyCurrent() needs CFRelease ? In-Reply-To: References: <72555273-a397-502e-ee79-1d1679e1f47c@oracle.com> Message-ID: <1fecc5dd-0af3-7438-bba7-f69ebf2ffe18@oracle.com> Looks good. Naoto On 7/24/19 12:52 AM, Baesken, Matthias wrote: > Hello, seems we need another "CFRelease(cflocale)" in an early return case (see the default: ...) , new webrev : > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8228501.1/ > > > Best regards, Matthias > > >> -----Original Message----- >> From: Baesken, Matthias >> Sent: Mittwoch, 24. Juli 2019 08:48 >> To: 'naoto.sato at oracle.com' ; core-libs- >> dev at openjdk.java.net >> Subject: RE: RFR: 8228501: java_props_macosx.c - provide missing CFRelease >> for CFLocaleCopyCurrent was: RE: java_props_macosx.c : >> CFLocaleCopyCurrent() needs CFRelease ? >> >> Thanks for the review . >> >> Will push it tomorrow in case there are no objections . >> >> Could you (or someone ?? ) comment on the other one too ? >> >> https://hg.openjdk.java.net/jdk/jdk/file/aaa83519e723/src/java.base/macos >> x/native/libosxsecurity/KeystoreImpl.m#l522 >> >> >> CFDataRef cfDataToImport = CFDataCreate(kCFAllocatorDefault, (UInt8 >> *)rawData, dataSize); >> .... >> >> err = SecKeychainItemImport(cfDataToImport, NULL, &dataFormat, NULL, >> 0, ¶mBlock, defaultKeychain, &createdItems); >> >> >> Thanks, Matthias >> >> >>> -----Original Message----- >>> From: naoto.sato at oracle.com >>> Sent: Dienstag, 23. Juli 2019 18:39 >>> To: Baesken, Matthias ; core-libs- >>> dev at openjdk.java.net >>> Subject: Re: RFR: 8228501: java_props_macosx.c - provide missing >> CFRelease >>> for CFLocaleCopyCurrent was: RE: java_props_macosx.c : >>> CFLocaleCopyCurrent() needs CFRelease ? >>> >>> Thanks, Matthias. Changes look good to me. >>> >>> I think it is hard to provide a regression test for this change, then >>> please add noreg-hard label to the issue. >>> >>> Naoto >>> >>> On 7/23/19 4:23 AM, Baesken, Matthias wrote: >>>> Hello, please review the following fix that adds CFRelease to 2 >>> CFLocaleCopyCurrent usages . >>>> >>>> Bug/webrev : >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8228501 >>>> >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8228501.0/ >>>> >>>> Best regards, Matthias >>>> >>>> > From aph at redhat.com Wed Jul 24 15:50:28 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 24 Jul 2019 16:50:28 +0100 Subject: RFR (S): JDK-8222778: Packaging Tool (JEP 343) on Linux/AArch64 In-Reply-To: References: <234f1c54-bd2a-c90b-367b-e279062218ff@bell-sw.com> <0ec8f547-8e21-7fd2-1091-886dc7a4d2b1@bell-sw.com> <28da2683-40a9-80be-9d35-63d7976557c6@redhat.com> Message-ID: On 7/24/19 3:30 PM, Dmitry Chuyko wrote: > Webrev without chdir() and write() changes: > http://cr.openjdk.java.net/~dchuyko/8222778/webrev.03/ > > When it is applied together with webrev.01 [1] from JDK-8228402, sandbox > is compiled and passes same jpackage tests on x86, aarch64 and other > platforms. Looks good, thanks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From jianglizhou at google.com Wed Jul 24 18:00:13 2019 From: jianglizhou at google.com (Jiangli Zhou) Date: Wed, 24 Jul 2019 11:00:13 -0700 Subject: RFR: 8228507: Archive FDBigInteger In-Reply-To: <56dfa19a-76c7-3318-bb6f-7e1a04c9cb44@oracle.com> References: <56dfa19a-76c7-3318-bb6f-7e1a04c9cb44@oracle.com> Message-ID: Hi Claes, This looks good to me. I wonder if FDBigInteger.archivedCaches could be placed in closed_archive_subgraph_entry_fields for the 'closed' archive region? The makeImmutable() is called for the cached FDBigInteger objects. Best regards, Jiangli On Wed, Jul 24, 2019 at 2:41 AM Claes Redestad wrote: > > Hi, > > any double<->String conversion will trigger load of > jdk.internal.math.FDBigInteger, which has a static > initializer pre-calculating a relatively large number > of values. > > Archiving these pre-calculated values reduces the time > spent in FDBigInteger. from a couple of > milliseconds down to "nothing". > > Bug: https://bugs.openjdk.java.net/browse/JDK-8228507 > Webrev: http://cr.openjdk.java.net/~redestad/8228507/open.00/ > > Testing: tier1-3 > > Thanks! > > /Claes From ecki at zusammenkunft.net Wed Jul 24 19:06:11 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 24 Jul 2019 19:06:11 +0000 Subject: [JSR] [JEP] Java Specification Requirement / Java Enhancement Proposal : 'Parallel OR' and 'Parallel AND' In-Reply-To: References: Message-ID: Hello, I don?t think you will get a new infix operator for this. And adding it to existing operators will be acquire risky change, might not improve performance for most situations - and most of all it is quite unlikely that you have a large number of terms at static compile time anyway. However if you want to evaluate expressions in parallel on a dynamic and large collection, you can easily use a parallel stream. Using predicates as the expression terms to evaluate you can use for example findAny() for checking a or condition. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev im Auftrag von Prakhar Makhija Gesendet: Mittwoch, Juli 24, 2019 4:49 PM An: David Holmes; core-libs-dev at openjdk.java.net Betreff: [JSR] [JEP] Java Specification Requirement / Java Enhancement Proposal : 'Parallel OR' and 'Parallel AND' Hi David / All, Earlier wanted to discuss just the implementation of 'OR operator', neither 'Conditional OR operator', nor 'Bitwise OR operator' Same goes with 'AND operator' Technically OR operator and AND operator are just binary operators, that's true I don't find it wrong considering there can be n operands, in an expression, with either of the two operators or a combination of both, where n >= 2 n can go nearby anything in powers of 10, it will take those many sequential clock cycles, to actually resolve the expression If you consider the same n as an expression of powers of 2, the same thing can be done in parallel clubbed with divide and conquer, taking the same number of clock cycles, but saving actual response time This can be given as a input from console, or as a property, specifying which implementation to use at runtime, sequential or parallel But with the latter would lead to very frequent resource starvage, this would need to be handled, to actually free the resources and give to pid or ppid, heirarically, or based upon who is the callee, or who asked who to wait, or some more other logic All the threads parallelly evaluating the same expression, with either operand, should be terminated and concluded as, when any thread results to: 'true' in case of OR 'false' in case of AND An expression can have further sub-expressions; so an expression with combination of both operands, will be considered as parent expression Yes it does change the conventional implementation of OR operator, and AND operator, in Java So it would be better to have two new operators/symbols itself Parallel OR ||| Parallel AND &&& We can go with the symbol |&& also in case of Parallel AND Looking forward to hearing your thoughts Best Wishes & Regards Prakhar Makhija ---- Hi Prakhar, On 22/06/2019 1:28 am, Prakhar Makhija wrote: > Topic: OR operator represented by || That should be the subject of your email - not a reply to a digest. > Query: The expression evaluation of the operands, of OR operator, does it > happen in parallel, when Java code runs, in the current versions? No, there is no parallel evaluation of anything in Java. It would be wrong to do so in this case as: "The conditional-or operator || operator is like | (?15.22.2), but evaluates its righthand operand only if the value of its left-hand operand is false." David From joe.darcy at oracle.com Wed Jul 24 19:38:17 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 24 Jul 2019 12:38:17 -0700 Subject: RFR: 8228581: Archive BigInteger constants In-Reply-To: <861003b5-4f12-cf12-9cfe-395177a1ba2f@oracle.com> References: <861003b5-4f12-cf12-9cfe-395177a1ba2f@oracle.com> Message-ID: <05507628-4b49-ff2f-6c05-71abec9c5085@oracle.com> Hi Claes, For those of us unfamiliar with the archive mechanism, can you describe its semantics or send a pointer to such a description? Thanks, -Joe On 7/24/2019 6:28 AM, Claes Redestad wrote: > Hi, > > BigInteger has a number of pre-calculated constants that are profitable > to put up for archiving. This reduces initialization time of BigInteger > by 0.3-0.5ms, and archives ~12Kb worth of objects. > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8228581 > Webrev: http://cr.openjdk.java.net/~redestad/8228581/open.00/ > > Webrev is applied on top of patch for > https://bugs.openjdk.java.net/browse/JDK-8228507 - which I've > tested alongside this. > > Testing: tier1-2 > > Thanks! > > /Claes From Roger.Riggs at oracle.com Wed Jul 24 19:47:52 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 24 Jul 2019 15:47:52 -0400 Subject: [14] RFR: 8212970: TZ database in "vanguard" format support In-Reply-To: References: Message-ID: <538525b0-3f7c-7556-e217-945c5c91d217@oracle.com> Hi Naoto, Adjusting the data during import looks fine. Typo: TzdbZoneRulesProvider.java:504? "ususally" -> "usually" Removing the source duplication is good. Is there a way to remove the duplication of the TZDATA files themselves? make/data/tzdata/* and test/jdk/sun/til/calendar/zi/* Looks good,? Roger On 7/23/19 6:15 PM, naoto.sato at oracle.com wrote: > Hi, > > Please review the fix to the following enhancement: > > https://bugs.openjdk.java.net/browse/JDK-8212970 > > The proposed changeset is located at: > > https://cr.openjdk.java.net/~naoto/8212970/webrev.09/ > > This change aims to support the "vanguard" IANA time zone data format, > which uses the negative savings and transition time beyond a day > period. The change basically translates those negative savings and > transition times, such as 25:00, into the ones that the current JDK > recognizes, then produces the data file "tzdb.dat" at the build time. > At the run time, the data file is read and interpreted as before. This > way the produced tzdb.dat is compatible with the prior JDK releases so > that the TZ Updater can also distribute it as a time zone update. > > I have also refactored redundant copy of ZoneRules file in the build > directory, by dynamically importing the file under src. Thus some > build related files are modified. I am hoping folks on the build-dev > can review those changes. > > Naoto From jianglizhou at google.com Wed Jul 24 19:54:33 2019 From: jianglizhou at google.com (Jiangli Zhou) Date: Wed, 24 Jul 2019 12:54:33 -0700 Subject: RFR: 8228581: Archive BigInteger constants In-Reply-To: <05507628-4b49-ff2f-6c05-71abec9c5085@oracle.com> References: <861003b5-4f12-cf12-9cfe-395177a1ba2f@oracle.com> <05507628-4b49-ff2f-6c05-71abec9c5085@oracle.com> Message-ID: On Wed, Jul 24, 2019 at 12:41 PM Joe Darcy wrote: > > Hi Claes, > > For those of us unfamiliar with the archive mechanism, can you describe > its semantics or send a pointer to such a description? That's a good point. There are some design docs describing how Java objects and object graphs archiving work. It might be good to put those in OpenJDK wiki. Best regards, Jiangli > > Thanks, > > -Joe > > On 7/24/2019 6:28 AM, Claes Redestad wrote: > > Hi, > > > > BigInteger has a number of pre-calculated constants that are profitable > > to put up for archiving. This reduces initialization time of BigInteger > > by 0.3-0.5ms, and archives ~12Kb worth of objects. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8228581 > > Webrev: http://cr.openjdk.java.net/~redestad/8228581/open.00/ > > > > Webrev is applied on top of patch for > > https://bugs.openjdk.java.net/browse/JDK-8228507 - which I've > > tested alongside this. > > > > Testing: tier1-2 > > > > Thanks! > > > > /Claes From claes.redestad at oracle.com Wed Jul 24 20:07:57 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 24 Jul 2019 22:07:57 +0200 Subject: RFR: 8228581: Archive BigInteger constants In-Reply-To: References: <861003b5-4f12-cf12-9cfe-395177a1ba2f@oracle.com> <05507628-4b49-ff2f-6c05-71abec9c5085@oracle.com> Message-ID: <1cb8c5c5-effd-a378-a178-99bb08af0f85@oracle.com> Hi Joe, Jiangli, On 2019-07-24 21:54, Jiangli Zhou wrote: > On Wed, Jul 24, 2019 at 12:41 PM Joe Darcy wrote: >> >> Hi Claes, >> >> For those of us unfamiliar with the archive mechanism, can you describe >> its semantics or send a pointer to such a description? > > That's a good point. There are some design docs describing how Java > objects and object graphs archiving work. It might be good to put > those in OpenJDK wiki. > > Best regards, > Jiangli getting the design up on the wiki would be great! Do you have a pointer to the docs and/or time to work on this? Quick outline of my understanding: effectively at time of -Xshare:dump, the contents of the static fields listed in heapShared.cpp will be serialized to the base CDS archive, .e., lib/classes.jsa, and on VM.initializeFromArchive the serialized heap state of the object graph will be mapped in, if possible. There are closed and open archive regions, and the rules differ somewhat between them. Objects archived in closed archive regions must be effectively immutable. Some mutable operations like synchronizing on objects are allowed, but GCs are allowed to ignore these regions, so if you wrote to a reference field pointing to something on the regular heap, you'd not be strongly referencing that object, and this might be disastrous. If you try to put things into the closed archive that are not fully immutable (not all fields are final etc), you'll get a lot of warnings to this effect. Open regions additionally allow writing to reference fields and referencing objects on the "regular" heap, so objects in such regions must be scanned by GCs as if they were a "normal" heap region. The powerCache field in this example, which is volatile, should be acceptable. This patch could probably be improved by moving everything but the initialPowerCache to the closed archive region.. /Claes From naoto.sato at oracle.com Wed Jul 24 20:09:33 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 24 Jul 2019 13:09:33 -0700 Subject: [14] RFR: 8212970: TZ database in "vanguard" format support In-Reply-To: <538525b0-3f7c-7556-e217-945c5c91d217@oracle.com> References: <538525b0-3f7c-7556-e217-945c5c91d217@oracle.com> Message-ID: <2c224e40-e5bd-60a6-2068-e2490104f1a4@oracle.com> Thanks for the review, Roger. On 7/24/19 12:47 PM, Roger Riggs wrote: > Hi Naoto, > > Adjusting the data during import looks fine. > > Typo: > > TzdbZoneRulesProvider.java:504? "ususally" -> "usually" Will fix it. > > Removing the source duplication is good. > > Is there a way to remove the duplication of the TZDATA files themselves? > make/data/tzdata/* and test/jdk/sun/til/calendar/zi/* I thought about it, but it turned out that the copyright is different (with/without classpath exception). So I just leave them as they are. Naoto > > Looks good,? Roger > > > > > On 7/23/19 6:15 PM, naoto.sato at oracle.com wrote: >> Hi, >> >> Please review the fix to the following enhancement: >> >> https://bugs.openjdk.java.net/browse/JDK-8212970 >> >> The proposed changeset is located at: >> >> https://cr.openjdk.java.net/~naoto/8212970/webrev.09/ >> >> This change aims to support the "vanguard" IANA time zone data format, >> which uses the negative savings and transition time beyond a day >> period. The change basically translates those negative savings and >> transition times, such as 25:00, into the ones that the current JDK >> recognizes, then produces the data file "tzdb.dat" at the build time. >> At the run time, the data file is read and interpreted as before. This >> way the produced tzdb.dat is compatible with the prior JDK releases so >> that the TZ Updater can also distribute it as a time zone update. >> >> I have also refactored redundant copy of ZoneRules file in the build >> directory, by dynamically importing the file under src. Thus some >> build related files are modified. I am hoping folks on the build-dev >> can review those changes. >> >> Naoto > From Roger.Riggs at oracle.com Wed Jul 24 20:16:02 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 24 Jul 2019 16:16:02 -0400 Subject: 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: <02C03E30-F32A-41A1-9EDB-B4F7BC20C66F@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> <7C526E68-DB96-4355-BEEF-C8D98620AC2C@oracle.com> <5D97E070-D953-4442-BB01-38BF2121D571@oracle.com> <02C03E30-F32A-41A1-9EDB-B4F7BC20C66F@oracle.com> Message-ID: <3494d657-dce5-5f0e-1e14-c7af45f67115@oracle.com> Hi Brian, Looks good. A nit,? In PrintStream.java 597 and 602 : put in the spaces after ",". Thanks, Roger On 7/23/19 2:40 PM, Brian Burkhalter wrote: >> On Jul 23, 2019, at 10:09 AM, Brian Burkhalter wrote: >> >>> You will want to add an @throws >> Will do. >> >>> The implSpec >>> ????? >>> * @implSpec >>> * The default implementation is equivalent to >>> * {@link java.io.FilterOutputStream#write(byte[],int,int) >>> * super.write(buf,0,buf.length)}. >>> * >>> ?????? >>> >>> Not sure if ?The default implementation? is the correct wording given it is not a default method (not sure what the norm is for describing the implementation in this case). Perhaps something like ?This method is equivalent to calling ?.? >> I concur, that would be better. > Above changes made in [1]. > > Thanks, > > Brian > > [1] http://cr.openjdk.java.net/~bpb/8187898/webrev-alt.03/ > From jianglizhou at google.com Wed Jul 24 20:38:01 2019 From: jianglizhou at google.com (Jiangli Zhou) Date: Wed, 24 Jul 2019 13:38:01 -0700 Subject: RFR: 8228581: Archive BigInteger constants In-Reply-To: <1cb8c5c5-effd-a378-a178-99bb08af0f85@oracle.com> References: <861003b5-4f12-cf12-9cfe-395177a1ba2f@oracle.com> <05507628-4b49-ff2f-6c05-71abec9c5085@oracle.com> <1cb8c5c5-effd-a378-a178-99bb08af0f85@oracle.com> Message-ID: Hi Claes, On Wed, Jul 24, 2019 at 1:06 PM Claes Redestad wrote: > > Hi Joe, Jiangli, > > On 2019-07-24 21:54, Jiangli Zhou wrote: > > On Wed, Jul 24, 2019 at 12:41 PM Joe Darcy wrote: > >> > >> Hi Claes, > >> > >> For those of us unfamiliar with the archive mechanism, can you describe > >> its semantics or send a pointer to such a description? > > > > That's a good point. There are some design docs describing how Java > > objects and object graphs archiving work. It might be good to put > > those in OpenJDK wiki. > > > > Best regards, > > Jiangli > > getting the design up on the wiki would be great! Do you have a pointer > to the docs and/or time to work on this? There are three existing design docs related to this area. They contain information: - GC (G1) Archive heap regions, closed archive region and open archive region - Archive object state transition - Targeted static field pre-initialization and caching using object graph archiving - Archived mirror (j.l.Objects) objects, Strings, etc. I don't have the internal links to those docs. I can help update the docs once they are moved to the OpenJDK wiki. Best regards, Jiangli > > Quick outline of my understanding: > > effectively at time of -Xshare:dump, the contents of the static fields > listed in heapShared.cpp will be serialized to the base CDS archive, > .e., lib/classes.jsa, and on VM.initializeFromArchive the serialized > heap state of the object graph will be mapped in, if possible. > > There are closed and open archive regions, and the rules differ somewhat > between them. > > Objects archived in closed archive regions must be effectively > immutable. Some mutable operations like synchronizing on objects are > allowed, but GCs are allowed to ignore these regions, so if you wrote to > a reference field pointing to something on the regular heap, you'd > not be strongly referencing that object, and this might be disastrous. > If you try to put things into the closed archive that are not > fully immutable (not all fields are final etc), you'll get a lot of > warnings to this effect. > > Open regions additionally allow writing to reference fields and > referencing objects on the "regular" heap, so objects in such regions > must be scanned by GCs as if they were a "normal" heap region. The > powerCache field in this example, which is volatile, should be > acceptable. > > This patch could probably be improved by moving everything but the > initialPowerCache to the closed archive region.. > > /Claes From brian.burkhalter at oracle.com Wed Jul 24 20:47:25 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 24 Jul 2019 13:47:25 -0700 Subject: 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: <3494d657-dce5-5f0e-1e14-c7af45f67115@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> <7C526E68-DB96-4355-BEEF-C8D98620AC2C@oracle.com> <5D97E070-D953-4442-BB01-38BF2121D571@oracle.com> <02C03E30-F32A-41A1-9EDB-B4F7BC20C66F@oracle.com> <3494d657-dce5-5f0e-1e14-c7af45f67115@oracle.com> Message-ID: Hi Roger, Modified locally. Thanks, Brian > On Jul 24, 2019, at 1:16 PM, Roger Riggs wrote: > > Looks good. > > A nit, In PrintStream.java 597 and 602 : put in the spaces after ",". From brian.burkhalter at oracle.com Wed Jul 24 20:54:44 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 24 Jul 2019 13:54:44 -0700 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: <4f71aae6-8250-67aa-c4ee-d206037af50e@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> Message-ID: > On Jul 23, 2019, at 11:58 PM, Alan Bateman wrote: > > On 23/07/2019 17:41, Brian Burkhalter wrote: >> : >> >> Here is an update which accounts for the foregoing comments. >> >> http://cr.openjdk.java.net/~bpb/8187898/webrev-alt.02/ >> > I looked at this version, and webrev-alt.03, but I think PS.write(byte[]) will need further word smiting to properly explain the confusion on using PrintStream vs. sub-classes of PrintStream that override this method (the former does not throw IOE, the latter may). So I think the @apiNote will be expanded further and the recommendation to use writeBytes(byte[]) or write(byte[],0,len) instead should be dialed up. The @implSpec also needs to be expanded as it doesn't make it clear that the default implementation (by way of invoking super.write(byte[],int,int)) does not throw IOE. I'm also wondering if PS.write(byte[]) should be deprecated. Hard to know how much time to spend on this issue as it has existed since JDK 1.0. Before addressing any of the above I wanted to note that in the fix for a very similar issue [1], where we added writeBytes(byte[]) to ByteArrayOutputStream, we did not do anything to its write(byte[]) method, i.e., it still does not override write(byte[]). I wonder whether doing the same here might simplify things. If we are going to keep the write(byte[]) override, then perhaps it would be better to implement it to call out.write(buf,0,buf.length) directly. Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8180410 From alexander.matveev at oracle.com Wed Jul 24 21:50:34 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Wed, 24 Jul 2019 14:50:34 -0700 Subject: JDK-8228402: chdir() and write() errors are not handled in jpackage In-Reply-To: References: Message-ID: Hi Andy, I think trowing exception should be better. We do it in several other places, not sure how well our code handles it. I think it might be good idea to file follow up task to cleanup/improve error handling in out native code. For example PosixProcess::Execute() will return false/true, throw exception and also terminates execution in some cases. http://cr.openjdk.java.net/~herrick/8228402/webrev.02/ Looks fine. Thanks, Alexander On 7/24/2019 5:18 AM, Andy Herrick wrote: > I used assert because: > > 1.) I don't think it could ever happen. > > 2.) If it did happen it might be easier to debug with the assert than > without it > > 3.) I thought it would be difficult to propagate the error. > > but perhaps (3) is not true. would it be better (ignoring types for > now) to: > >> ??? len = write(FInputHandle, Value.data(), Value.size()); >> >> ??? if (len != Value.size()) { >> >> ??????????? throw Exception(_T("Internal Error - write failed")); >> >> ??? } >> > /Andy > > > On 7/23/2019 11:21 PM, Alexander Matveev wrote: >> Hi Andy, >> >> I think it is better not to use assert() in this case since it >> terminates app abnormally. >> Do we really should terminate execution if write() fails in this >> case? Can we ignore error? >> It might be better to handle it gracefully and then return from >> main() with error if we cannot ignore error. >> >> Thanks, >> Alexander >> >> On 7/23/2019 2: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). >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8228402 >>> >>> [2] http://cr.openjdk.java.net/~herrick/8228402/ >>> >>> /Andy >>> >> From naoto.sato at oracle.com Wed Jul 24 21:52:55 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 24 Jul 2019 14:52:55 -0700 Subject: [14] RFR: 8212970: TZ database in "vanguard" format support In-Reply-To: <2c224e40-e5bd-60a6-2068-e2490104f1a4@oracle.com> References: <538525b0-3f7c-7556-e217-945c5c91d217@oracle.com> <2c224e40-e5bd-60a6-2068-e2490104f1a4@oracle.com> Message-ID: Hi Roger, On 7/24/19 1:09 PM, naoto.sato at oracle.com wrote: > Thanks for the review, Roger. > > On 7/24/19 12:47 PM, Roger Riggs wrote: >> Hi Naoto, >> >> Adjusting the data during import looks fine. >> >> Typo: >> >> TzdbZoneRulesProvider.java:504? "ususally" -> "usually" > > Will fix it. > >> >> Removing the source duplication is good. >> >> Is there a way to remove the duplication of the TZDATA files themselves? >> make/data/tzdata/* and test/jdk/sun/til/calendar/zi/* > > I thought about it, but it turned out that the copyright is different > (with/without classpath exception). So I just leave them as they are. I was wrong about this. Since we are trying to eliminate the duplicates, copyright difference does not matter :-) Here is the update: http://cr.openjdk.java.net/~naoto/8212970/webrev.10/ Naoto > > Naoto > >> >> Looks good,? Roger >> >> >> >> >> On 7/23/19 6:15 PM, naoto.sato at oracle.com wrote: >>> Hi, >>> >>> Please review the fix to the following enhancement: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8212970 >>> >>> The proposed changeset is located at: >>> >>> https://cr.openjdk.java.net/~naoto/8212970/webrev.09/ >>> >>> This change aims to support the "vanguard" IANA time zone data >>> format, which uses the negative savings and transition time beyond a >>> day period. The change basically translates those negative savings >>> and transition times, such as 25:00, into the ones that the current >>> JDK recognizes, then produces the data file "tzdb.dat" at the build >>> time. At the run time, the data file is read and interpreted as >>> before. This way the produced tzdb.dat is compatible with the prior >>> JDK releases so that the TZ Updater can also distribute it as a time >>> zone update. >>> >>> I have also refactored redundant copy of ZoneRules file in the build >>> directory, by dynamically importing the file under src. Thus some >>> build related files are modified. I am hoping folks on the build-dev >>> can review those changes. >>> >>> Naoto >> From alexander.matveev at oracle.com Wed Jul 24 21:56:49 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Wed, 24 Jul 2019 14:56:49 -0700 Subject: RFR (S): JDK-8222778: Packaging Tool (JEP 343) on Linux/AArch64 In-Reply-To: References: <234f1c54-bd2a-c90b-367b-e279062218ff@bell-sw.com> <0ec8f547-8e21-7fd2-1091-886dc7a4d2b1@bell-sw.com> <28da2683-40a9-80be-9d35-63d7976557c6@redhat.com> Message-ID: <5d757f33-fd75-8eb5-9d71-29c3481eb43b@oracle.com> Looks good. On 7/24/2019 7:30 AM, Dmitry Chuyko wrote: > Webrev without chdir() and write() changes: > http://cr.openjdk.java.net/~dchuyko/8222778/webrev.03/ > > When it is applied together with webrev.01 [1] from JDK-8228402, > sandbox is compiled and passes same jpackage tests on x86, aarch64 and > other platforms. > > -Dmitry > > [1] http://cr.openjdk.java.net/~herrick/8228402/ > > On 7/19/19 11:31 AM, Andrew Haley wrote: >> On 7/19/19 12:36 AM, Dmitry Chuyko wrote: >>> On 7/18/19 11:57 AM, Andrew Haley wrote: >>>> Hi, >>>> >>>> On 7/17/19 10:19 PM, Dmitry Chuyko wrote: >>>>> On 7/17/19 11:52 AM, Andrew Haley wrote: >>>>>> This is weird: >>>>>> >>>>>> --- >>>>>> old/src/jdk.jpackage/linux/native/libapplauncher/LinuxPlatform.cpp >>>>>> 2019-07-16 22:11:30.200258978 +0300 >>>>>> +++ >>>>>> new/src/jdk.jpackage/linux/native/libapplauncher/LinuxPlatform.cpp >>>>>> 2019-07-16 22:11:29.867374851 +0300 >>>>>> @@ -127,7 +127,7 @@ >>>>>> ??? } >>>>>> >>>>>> ??? void LinuxPlatform::SetCurrentDirectory(TString Value) { >>>>>> -??? chdir(PlatformString(Value).toPlatformString()); >>>>>> +??? int ignored = chdir(PlatformString(Value).toPlatformString()); >>>>>> ??? } >>>>>> >>>>>> Firstly it does not fix the problem: you've gone from an unused >>>>>> value to an >>>>>> unused variable. Secondly, we ignore the return value of printf >>>>>> all the time; >>>>>> what's different about this one? >>>>> chdir() is __wur, which is >>>>> /usr/include/aarch64-linux-gnu/sys/cdefs.h:# >>>>> define __wur __attribute_warn_unused_result__ >>>> OK, got it. >>>> >>>>> In some places this warning is disabled (CoreLibraries.gmk, >>>>> Awt2dLibraries.gmk). >>>>> >>>>> It would be more correct to handle the result here as chdir might not >>>>> succeeded in fact. >>>> Very much so. We shouldn't try to "shut up the compiler" in this >>>> way.Andrew Haley >>> I created a separate bug about chdir() and write() usages: >>> https://bugs.openjdk.java.net/browse/JDK-8228402 >>> >>> Does it look good to silence warnings for platforms support changes? >> I think we should fix the bugs, not silence the warnings. >> >>> One >>> more option could be to exclude related changes from current review. >> OK. >> From huizhe.wang at oracle.com Wed Jul 24 21:57:25 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 24 Jul 2019 14:57:25 -0700 Subject: [14] RFR: 8212970: TZ database in "vanguard" format support In-Reply-To: References: Message-ID: <82dadb56-b776-9741-fe5c-823c4f0948fa@oracle.com> Hi Naoto, The method findNegativeSavings method in TzdbZoneRulesProvider.java states that it "Find the minimum negative savings". While the result is correct since the rules all have the same value for SAVE, I wonder if that's ideal conceptually. Given a start LDT, shouldn't it be looking for the SAVE in the exact (narrower) date range (e.g. 1981 - 1989 vs 1981 - max)?. NegativeDSTTest verifies the tzdata, that is the adjusted data after import, is that correct? I wonder a comment and a bit of details in the test summary would be helpful since there is no negative data in the test itself. Best, Joe On 7/23/19 3:15 PM, naoto.sato at oracle.com wrote: > Hi, > > Please review the fix to the following enhancement: > > https://bugs.openjdk.java.net/browse/JDK-8212970 > > The proposed changeset is located at: > > https://cr.openjdk.java.net/~naoto/8212970/webrev.09/ > > This change aims to support the "vanguard" IANA time zone data format, > which uses the negative savings and transition time beyond a day > period. The change basically translates those negative savings and > transition times, such as 25:00, into the ones that the current JDK > recognizes, then produces the data file "tzdb.dat" at the build time. > At the run time, the data file is read and interpreted as before. This > way the produced tzdb.dat is compatible with the prior JDK releases so > that the TZ Updater can also distribute it as a time zone update. > > I have also refactored redundant copy of ZoneRules file in the build > directory, by dynamically importing the file under src. Thus some > build related files are modified. I am hoping folks on the build-dev > can review those changes. > > Naoto From claes.redestad at oracle.com Wed Jul 24 22:12:32 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 25 Jul 2019 00:12:32 +0200 Subject: RFR: 8228507: Archive FDBigInteger In-Reply-To: References: <56dfa19a-76c7-3318-bb6f-7e1a04c9cb44@oracle.com> Message-ID: <69f7689a-ab6f-5517-60a4-7036176930c5@oracle.com> Hi Jiangli, thank you for reviewing! The objects we're dealing with here are all effectively immutable, however, at least one reference field in FDBigInteger is non-final, so putting it in a closed archive region is causing a lot of warnings at dump time. Perhaps we should add a way to suppress such warnings on a case-by-case basis? Thanks! /Claes On 2019-07-24 20:00, Jiangli Zhou wrote: > Hi Claes, > > This looks good to me. I wonder if FDBigInteger.archivedCaches could > be placed in closed_archive_subgraph_entry_fields for the 'closed' > archive region? The makeImmutable() is called for the cached > FDBigInteger objects. > > Best regards, > Jiangli > > On Wed, Jul 24, 2019 at 2:41 AM Claes Redestad > wrote: >> >> Hi, >> >> any double<->String conversion will trigger load of >> jdk.internal.math.FDBigInteger, which has a static >> initializer pre-calculating a relatively large number >> of values. >> >> Archiving these pre-calculated values reduces the time >> spent in FDBigInteger. from a couple of >> milliseconds down to "nothing". >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8228507 >> Webrev: http://cr.openjdk.java.net/~redestad/8228507/open.00/ >> >> Testing: tier1-3 >> >> Thanks! >> >> /Claes From naoto.sato at oracle.com Wed Jul 24 22:24:57 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 24 Jul 2019 15:24:57 -0700 Subject: [14] RFR: 8212970: TZ database in "vanguard" format support In-Reply-To: <82dadb56-b776-9741-fe5c-823c4f0948fa@oracle.com> References: <82dadb56-b776-9741-fe5c-823c4f0948fa@oracle.com> Message-ID: Hi Joe, Thank you for the review. On 7/24/19 2:57 PM, Joe Wang wrote: > Hi Naoto, > > The method findNegativeSavings method in TzdbZoneRulesProvider.java > states that it "Find the minimum negative savings". While the result is > correct since the rules all have the same value for SAVE, I wonder if > that's ideal conceptually. Given a start LDT, shouldn't it be looking > for the SAVE in the exact (narrower) date range (e.g. 1981 - 1989 vs > 1981 - max)?. I believe it is working as such. The end year is retrieved within the method (line 879) and only the minimum negative saving values within the window is filtered. > > NegativeDSTTest verifies the tzdata, that is the adjusted data after > import, is that correct? I wonder a comment and a bit of details in the > test summary would be helpful since there is no negative data in the > test itself. Good point. It is confusing. I supplied summary text in the test (also the similar line in TestZoneRules.java) Here is the updated webrev: http://cr.openjdk.java.net/~naoto/8212970/webrev.11/ Naoto > > Best, > Joe > > On 7/23/19 3:15 PM, naoto.sato at oracle.com wrote: >> Hi, >> >> Please review the fix to the following enhancement: >> >> https://bugs.openjdk.java.net/browse/JDK-8212970 >> >> The proposed changeset is located at: >> >> https://cr.openjdk.java.net/~naoto/8212970/webrev.09/ >> >> This change aims to support the "vanguard" IANA time zone data format, >> which uses the negative savings and transition time beyond a day >> period. The change basically translates those negative savings and >> transition times, such as 25:00, into the ones that the current JDK >> recognizes, then produces the data file "tzdb.dat" at the build time. >> At the run time, the data file is read and interpreted as before. This >> way the produced tzdb.dat is compatible with the prior JDK releases so >> that the TZ Updater can also distribute it as a time zone update. >> >> I have also refactored redundant copy of ZoneRules file in the build >> directory, by dynamically importing the file under src. Thus some >> build related files are modified. I am hoping folks on the build-dev >> can review those changes. >> >> Naoto > From jianglizhou at google.com Wed Jul 24 22:50:57 2019 From: jianglizhou at google.com (Jiangli Zhou) Date: Wed, 24 Jul 2019 15:50:57 -0700 Subject: RFR: 8228507: Archive FDBigInteger In-Reply-To: <69f7689a-ab6f-5517-60a4-7036176930c5@oracle.com> References: <56dfa19a-76c7-3318-bb6f-7e1a04c9cb44@oracle.com> <69f7689a-ab6f-5517-60a4-7036176930c5@oracle.com> Message-ID: On Wed, Jul 24, 2019 at 3:11 PM Claes Redestad wrote: > > Hi Jiangli, > > thank you for reviewing! The objects we're dealing with here are all > effectively immutable, however, at least one reference field in > FDBigInteger is non-final, so putting it in a closed archive region is > causing a lot of warnings at dump time. Perhaps we should add a way > to suppress such warnings on a case-by-case basis? Agreed! Best regards, Jiangli > > Thanks! > > /Claes > > On 2019-07-24 20:00, Jiangli Zhou wrote: > > Hi Claes, > > > > This looks good to me. I wonder if FDBigInteger.archivedCaches could > > be placed in closed_archive_subgraph_entry_fields for the 'closed' > > archive region? The makeImmutable() is called for the cached > > FDBigInteger objects. > > > > Best regards, > > Jiangli > > > > On Wed, Jul 24, 2019 at 2:41 AM Claes Redestad > > wrote: > >> > >> Hi, > >> > >> any double<->String conversion will trigger load of > >> jdk.internal.math.FDBigInteger, which has a static > >> initializer pre-calculating a relatively large number > >> of values. > >> > >> Archiving these pre-calculated values reduces the time > >> spent in FDBigInteger. from a couple of > >> milliseconds down to "nothing". > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8228507 > >> Webrev: http://cr.openjdk.java.net/~redestad/8228507/open.00/ > >> > >> Testing: tier1-3 > >> > >> Thanks! > >> > >> /Claes From david.holmes at oracle.com Wed Jul 24 22:52:00 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 25 Jul 2019 08:52:00 +1000 Subject: Fwd: Verify error in hg:jdk/jdk -- repository now READ-ONLY In-Reply-To: <1d13b87c-55d4-4665-aeb3-1b3bc4323a08@default> References: <1d13b87c-55d4-4665-aeb3-1b3bc4323a08@default> Message-ID: <5895de6f-e445-9df9-b5e7-7c665ee7ddec@oracle.com> FYI in case this was not seen on jdk-dev list. David -------------- next part -------------- An embedded message was scrubbed... From: Iris Clark Subject: Verify error in hg:jdk/jdk -- repository now READ-ONLY Date: Wed, 24 Jul 2019 10:04:32 -0700 (PDT) Size: 5933 URL: From huizhe.wang at oracle.com Wed Jul 24 22:52:46 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 24 Jul 2019 15:52:46 -0700 Subject: [14] RFR: 8212970: TZ database in "vanguard" format support In-Reply-To: References: <82dadb56-b776-9741-fe5c-823c4f0948fa@oracle.com> Message-ID: <1dea8b31-9b8d-ef2a-fc21-8d06638235b4@oracle.com> Thanks Naoto.? Looks good. -Joe On 7/24/19 3:24 PM, naoto.sato at oracle.com wrote: > Hi Joe, > > Thank you for the review. > > On 7/24/19 2:57 PM, Joe Wang wrote: >> Hi Naoto, >> >> The method findNegativeSavings method in TzdbZoneRulesProvider.java >> states that it "Find the minimum negative savings". While the result >> is correct since the rules all have the same value for SAVE, I wonder >> if that's ideal conceptually. Given a start LDT, shouldn't it be >> looking for the SAVE in the exact (narrower) date range (e.g. 1981 - >> 1989 vs 1981 - max)?. > > I believe it is working as such. The end year is retrieved within the > method (line 879) and only the minimum negative saving values within > the window is filtered. > >> >> NegativeDSTTest verifies the tzdata, that is the adjusted data after >> import, is that correct? I wonder a comment and a bit of details in >> the test summary would be helpful since there is no negative data in >> the test itself. > > Good point. It is confusing. I supplied summary text in the test (also > the similar line in TestZoneRules.java) > > Here is the updated webrev: > > http://cr.openjdk.java.net/~naoto/8212970/webrev.11/ > > Naoto >> >> Best, >> Joe >> >> On 7/23/19 3:15 PM, naoto.sato at oracle.com wrote: >>> Hi, >>> >>> Please review the fix to the following enhancement: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8212970 >>> >>> The proposed changeset is located at: >>> >>> https://cr.openjdk.java.net/~naoto/8212970/webrev.09/ >>> >>> This change aims to support the "vanguard" IANA time zone data >>> format, which uses the negative savings and transition time beyond a >>> day period. The change basically translates those negative savings >>> and transition times, such as 25:00, into the ones that the current >>> JDK recognizes, then produces the data file "tzdb.dat" at the build >>> time. At the run time, the data file is read and interpreted as >>> before. This way the produced tzdb.dat is compatible with the prior >>> JDK releases so that the TZ Updater can also distribute it as a time >>> zone update. >>> >>> I have also refactored redundant copy of ZoneRules file in the build >>> directory, by dynamically importing the file under src. Thus some >>> build related files are modified. I am hoping folks on the build-dev >>> can review those changes. >>> >>> Naoto >> From david.holmes at oracle.com Thu Jul 25 01:12:12 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 25 Jul 2019 11:12:12 +1000 Subject: Fwd: Re: Verify error in hg:jdk/jdk -- repository now READ-ONLY In-Reply-To: <3bfb52e7-0eb4-4047-bb44-a42ba9059d71@default> References: <3bfb52e7-0eb4-4047-bb44-a42ba9059d71@default> Message-ID: FYI open again -------------- next part -------------- An embedded message was scrubbed... From: Iris Clark Subject: Re: Verify error in hg:jdk/jdk -- repository now READ-ONLY Date: Wed, 24 Jul 2019 16:02:22 -0700 (PDT) Size: 6546 URL: From david.holmes at oracle.com Thu Jul 25 05:33:14 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 25 Jul 2019 15:33:14 +1000 Subject: [JSR] [JEP] Java Specification Requirement / Java Enhancement Proposal : 'Parallel OR' and 'Parallel AND' In-Reply-To: References: Message-ID: Hi Prakhar, The bar for getting new language features added is extremely high - new operators even higher I think. New operators for parallelism ... well I don't see that ever happening. I'm not a fan of implicit parallelism like you propose, it simply raises too many issues for the system to be able to make good enough judgements in all cases. If you want to terminate parallel computations when the outcome of the operator has been determined then that gets very messy semantically as you basically have a race and can never know which computation will complete first, nor how far others got - you would have to use expressions that are completely side-effect free for this to not be an issue. (And we don't have very good mechanisms for cancelling computations in the first place.) There's also an underlying assumption that parallelising the expression and managing that parallelism will actually yield performance benefits, but that will only happen if the expressions are each extremely computationally intensive. Fibers might eventually change the "sweet spot" for such decisions, but in general forking off parallel tasks, managing them and combining results has significant overhead. Such things can already be written using library calls with the ForkJoin framework and/or parallel streams (as Bernd mentioned). Firing off a task for each sub-expression and then combining the results as desired. Having language syntax as a short-hand for that likely appeals to you as an end-user, but is less appealing to the language architects etc. As I said the bar is very high to get in new language features - parallel streams themselves don't have syntactic support. It is an interesting topic academically at least, but I don't expect you will find that much interest here. Cheers, David ----- On 24/07/2019 10:19 pm, Prakhar Makhija wrote: > Hi David / All, > > > Earlier wanted to discuss just the implementation of 'OR operator', > neither 'Conditional OR operator', nor 'Bitwise OR operator' > > Same goes with 'AND operator' > > Technically OR operator and AND operator are just binary operators, > that's true > > I don't find it wrong considering there can be n operands, in an > expression, with either of the two operators or a combination of both, > where n >= 2 > > n can go nearby anything in powers of 10, it will take those many > sequential clock cycles, to actually resolve the expression > > If you consider the same n as an expression of powers of 2, the same > thing can be done in parallel clubbed with divide and conquer, taking > the same number of clock cycles, but saving actual response time > > This can be given as a input from console, or as a property, specifying > which implementation to use at runtime, sequential or parallel > > But with the latter would lead to very frequent resource starvage, this > would need to be handled, to actually free the resources and give to pid > or ppid, heirarically, or based upon who is the callee, or who asked who > to wait, or some more other logic > > All the threads parallelly evaluating the same expression, with either > operand, should be terminated and concluded as, when any thread results to: > 'true' in case of OR > 'false' in case of AND > > An expression can have further sub-expressions; so an expression with > combination of both operands, will be considered as parent expression > > Yes it does change the conventional implementation of OR operator, and > AND operator, in Java > > So it would be better to have two new operators/symbols itself > > Parallel OR > ||| > > Parallel AND > &&& > > We can go with the symbol |&& also in case of Parallel AND > > > Looking forward to hearing your thoughts > > > Best Wishes & Regards > Prakhar Makhija > > ---- > > Hi Prakhar, > > > On 22/06/2019 1:28 am, Prakhar Makhija wrote: > > Topic: OR operator represented by || > > That should be the subject of your email - not a reply to a digest. > > > > Query: The expression evaluation of the operands, of OR operator, does it > > happen in parallel, when Java code runs, in the current versions? > > No, there is no parallel evaluation of anything in Java. It would be > wrong to do so in this case as: > > "The conditional-or operator || operator is like | (?15.22.2), but > evaluates its righthand operand only if the value of its left-hand > operand is false." > > > David From raffaello.giulietti at gmail.com Thu Jul 25 11:59:49 2019 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Thu, 25 Jul 2019 13:59:49 +0200 Subject: RFR CSR JDK-8202555: Double.toString(double) sometimes produces incorrect results Message-ID: Hi folks, as nothing has substantially moved towards approval of the patch [1] and the corresponding CSR [2], let's split the issue into its constituents. The CSR is currently finalized and needs a further review for approval. This requires much less time than a review of the implementation [1]. The CSR has been carefully written to match the observed behavior of the current OpenJDK 12 as close as possible while aiming at being more clear and 100% rigorous. It can be approved independently of the underlying implementation. So please review and approve the CSR [2], regardless of the proposed improved implementation [1], which can be tackled later. Greetings Raffaello ---- [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-April/059783.html [2] https://bugs.openjdk.java.net/browse/JDK-8202555 [3] https://drive.google.com/open?id=1KLtG_LaIbK9ETXI290zqCxvBW94dj058 From dmitry.chuyko at bell-sw.com Thu Jul 25 12:38:38 2019 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Thu, 25 Jul 2019 15:38:38 +0300 Subject: RFR (S): JDK-8222778: Packaging Tool (JEP 343) on Linux/AArch64 In-Reply-To: <5d757f33-fd75-8eb5-9d71-29c3481eb43b@oracle.com> References: <234f1c54-bd2a-c90b-367b-e279062218ff@bell-sw.com> <0ec8f547-8e21-7fd2-1091-886dc7a4d2b1@bell-sw.com> <28da2683-40a9-80be-9d35-63d7976557c6@redhat.com> <5d757f33-fd75-8eb5-9d71-29c3481eb43b@oracle.com> Message-ID: <258360f5-16e0-1735-e64c-fcdcf3a22010@bell-sw.com> I realized we also need better detection of arch for deb control file. It can be done by using 'dpkg --print-architecture' on host. LinuxDebBundler was corrected. New webrev: http://cr.openjdk.java.net/~dchuyko/8222778/webrev.04/ Patch was re-tested together with webrev.02 from JDK-8228402. -Dmitry On 7/25/19 12:56 AM, Alexander Matveev wrote: > Looks good. > > On 7/24/2019 7:30 AM, Dmitry Chuyko wrote: >> Webrev without chdir() and write() changes: >> http://cr.openjdk.java.net/~dchuyko/8222778/webrev.03/ >> >> When it is applied together with webrev.01 [1] from JDK-8228402, >> sandbox is compiled and passes same jpackage tests on x86, aarch64 >> and other platforms. >> >> -Dmitry >> >> [1] http://cr.openjdk.java.net/~herrick/8228402/ >> >> On 7/19/19 11:31 AM, Andrew Haley wrote: >>> On 7/19/19 12:36 AM, Dmitry Chuyko wrote: >>>> On 7/18/19 11:57 AM, Andrew Haley wrote: >>>>> Hi, >>>>> >>>>> On 7/17/19 10:19 PM, Dmitry Chuyko wrote: >>>>>> On 7/17/19 11:52 AM, Andrew Haley wrote: >>>>>>> This is weird: >>>>>>> >>>>>>> --- >>>>>>> old/src/jdk.jpackage/linux/native/libapplauncher/LinuxPlatform.cpp >>>>>>> 2019-07-16 22:11:30.200258978 +0300 >>>>>>> +++ >>>>>>> new/src/jdk.jpackage/linux/native/libapplauncher/LinuxPlatform.cpp >>>>>>> 2019-07-16 22:11:29.867374851 +0300 >>>>>>> @@ -127,7 +127,7 @@ >>>>>>> ??? } >>>>>>> >>>>>>> ??? void LinuxPlatform::SetCurrentDirectory(TString Value) { >>>>>>> -??? chdir(PlatformString(Value).toPlatformString()); >>>>>>> +??? int ignored = chdir(PlatformString(Value).toPlatformString()); >>>>>>> ??? } >>>>>>> >>>>>>> Firstly it does not fix the problem: you've gone from an unused >>>>>>> value to an >>>>>>> unused variable. Secondly, we ignore the return value of printf >>>>>>> all the time; >>>>>>> what's different about this one? >>>>>> chdir() is __wur, which is >>>>>> /usr/include/aarch64-linux-gnu/sys/cdefs.h:# >>>>>> define __wur __attribute_warn_unused_result__ >>>>> OK, got it. >>>>> >>>>>> In some places this warning is disabled (CoreLibraries.gmk, >>>>>> Awt2dLibraries.gmk). >>>>>> >>>>>> It would be more correct to handle the result here as chdir might >>>>>> not >>>>>> succeeded in fact. >>>>> Very much so. We shouldn't try to "shut up the compiler" in this >>>>> way.Andrew Haley >>>> I created a separate bug about chdir() and write() usages: >>>> https://bugs.openjdk.java.net/browse/JDK-8228402 >>>> >>>> Does it look good to silence warnings for platforms support changes? >>> I think we should fix the bugs, not silence the warnings. >>> >>>> One >>>> more option could be to exclude related changes from current review. >>> OK. >>> > From andy.herrick at oracle.com Thu Jul 25 13:20:04 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Thu, 25 Jul 2019 09:20:04 -0400 Subject: RFR: JDK-8227684 : jpackage must handle win32 mangled names in jli.dll 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). [1] https://bugs.openjdk.java.net/browse/JDK-8227684 [2] http://cr.openjdk.java.net/~herrick/8227684/webrev.01/ Submitted by: Robert Lichtenberger /Andy From andy.herrick at oracle.com Thu Jul 25 13:24:36 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Thu, 25 Jul 2019 09:24:36 -0400 Subject: RFR: JDK-8227312: Remove pkg bundle from DMG image. Message-ID: <1913b81b-e4da-bb35-38be-cad6f677ab55@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). [1] https://bugs.openjdk.java.net/browse/JDK-8227312 [2] http://cr.openjdk.java.net/~herrick/8227312/webrev.01/ /Andy From matthias.baesken at sap.com Thu Jul 25 13:45:11 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 25 Jul 2019 13:45:11 +0000 Subject: RFR: 8228482: fix xlc16/xlclang comparison of distinct pointer types and string literal conversion warnings In-Reply-To: References: Message-ID: 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' 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 > On Behalf Of Baesken, Matthias Sent: Dienstag, 23. Juli 2019 17:15 To: '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' > 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 vlv.spb.ru at mail.ru Thu Jul 25 14:04:41 2019 From: vlv.spb.ru at mail.ru (=?UTF-8?B?VmxhZGltaXIgWWFyb3NsYXZza2l5?=) Date: Thu, 25 Jul 2019 17:04:41 +0300 Subject: =?UTF-8?B?QmVuY2htYXJraW5nIG9mIG5ldyBvcHRpbWl6ZWQgRHVhbC1QaXZvdCBRdWlj?= =?UTF-8?B?a3NvcnQ=?= Message-ID: <1564063481.101106990@f551.i.mail.ru> Hi all, With the help of Laurent Bourges I run benchmarking of new optimized Dual-Pivot Quicksort and summarized results. The tests were run for all types (int / long / ... / double), for both types: sequential and parallel sorting, for small, medium and large sizes. The comparison was done on several data types, such as: random, period, sorted, equal, stagger, shuffle. Here is the summary of total gains. The gain is defined as (jdk_time - dpqs_time) / jdk_time, where jdk_time is sorting time by the current jdk14 and dpqs_time is sorting time by new optimized Dual-Pivot Quicksort. To get stable and reproducible results, min time of?many invocations is taken. You can find all detailed results?there https://github.com/iaroslavski/sorting/tree/master/benchmarking/results ? Sources of benchmarking tests are there https://github.com/iaroslavski/sorting/tree/master/benchmarking/sources You can see not good performance for float / double types (parallel sorting). This behavior can be explained by existing bug in jdk, when NaNs and -0.0s are not processed properly. New sorting has total losses for small float / double arrays, few percents only. For all other cases new optimized sorting is winner. -------------------------------------------------------------------------------------------------------- [int] sequential, Length = 150, Gain: 0.15 sequential, Length = 30000, Gain: 0.28 sequential, Length = 1000000, Gain: 0.31 parallel 8, Length = 150, Gain: 0.14 parallel 8, Length = 30000, Gain: 0.15 parallel 8, Length = 1000000, Gain: 0.14 [long] sequential, Length = 150, Gain: 0.12 sequential, Length = 30000, Gain: 0.23 sequential, Length = 1000000, Gain: 0.32 parallel 8, Length = 150, Gain: 0.11 parallel 8, Length = 30000, Gain: 0.16 parallel 8, Length = 1000000, Gain: 0.24 parallel 88 processors, Length = 1000000, Gain: 0.05 [byte] sequential, Length = 150, Gain: 0.06 sequential, Length = 30000, Gain: 0.36 sequential, Length = 1000000, Gain: 0.37 parallel 8, Length = 150, Gain: 0.13 parallel 8, Length = 30000, Gain: 0.73 parallel 8, Length = 1000000, Gain: 0.65 [char] sequential, Length = 150, Gain: 0.10 sequential, Length = 30000, Gain: 0.00 sequential, Length = 1000000, Gain: 0.17 parallel 8, Length = 150, Gain: 0.10 parallel 8, Length = 30000, Gain: 0.33 parallel 8, Length = 1000000, Gain: 0.62 [short] sequential, Length = 150, Gain: 0.14 sequential, Length = 30000, Gain: 0.10 sequential, Length = 1000000, Gain: 0.18 parallel 8, Length = 150, Gain: 0.13 parallel 8, Length = 30000, Gain: 0.41 parallel 8, Length = 1000000, Gain: 0.65 [float] sequential, Length = 150, Gain: -0.02 sequential, Length = 30000, Gain: 0.21 sequential, Length = 1000000, Gain: 0.24 parallel 8, Length = 150, Gain: -0.05 parallel 8, Length = 30000, Gain: -0.04 parallel 8, Length = 1000000, Gain: -0.12 [double] sequential, Length = 150, Gain: -0.03 sequential, Length = 30000, Gain: 0.19 sequential, Length = 1000000, Gain: 0.23 parallel 8, Length = 150, Gain: -0.05 parallel 8, Length = 30000, Gain: 0.05 parallel 8, Length = 1000000, Gain: 0.15 Thank you, Vladimir From Roger.Riggs at oracle.com Thu Jul 25 14:47:53 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 25 Jul 2019 10:47:53 -0400 Subject: [14] RFR: 8212970: TZ database in "vanguard" format support In-Reply-To: References: <82dadb56-b776-9741-fe5c-823c4f0948fa@oracle.com> Message-ID: Hi Naoto, TestZoneInfo310.java: With the composition of the tzdir path up and over to the make directory for the tzdir it might be useful to do an explicit check that the directory exists. That way if the directory structure on the build side changes, there will be a test failure makine it obvious that the dependency has changed. Looks fine. Thanks, Roger On 7/24/19 6:24 PM, naoto.sato at oracle.com wrote: > Hi Joe, > > Thank you for the review. > > On 7/24/19 2:57 PM, Joe Wang wrote: >> Hi Naoto, >> >> The method findNegativeSavings method in TzdbZoneRulesProvider.java >> states that it "Find the minimum negative savings". While the result >> is correct since the rules all have the same value for SAVE, I wonder >> if that's ideal conceptually. Given a start LDT, shouldn't it be >> looking for the SAVE in the exact (narrower) date range (e.g. 1981 - >> 1989 vs 1981 - max)?. > > I believe it is working as such. The end year is retrieved within the > method (line 879) and only the minimum negative saving values within > the window is filtered. > >> >> NegativeDSTTest verifies the tzdata, that is the adjusted data after >> import, is that correct? I wonder a comment and a bit of details in >> the test summary would be helpful since there is no negative data in >> the test itself. > > Good point. It is confusing. I supplied summary text in the test (also > the similar line in TestZoneRules.java) > > Here is the updated webrev: > > http://cr.openjdk.java.net/~naoto/8212970/webrev.11/ > > Naoto >> >> Best, >> Joe >> >> On 7/23/19 3:15 PM, naoto.sato at oracle.com wrote: >>> Hi, >>> >>> Please review the fix to the following enhancement: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8212970 >>> >>> The proposed changeset is located at: >>> >>> https://cr.openjdk.java.net/~naoto/8212970/webrev.09/ >>> >>> This change aims to support the "vanguard" IANA time zone data >>> format, which uses the negative savings and transition time beyond a >>> day period. The change basically translates those negative savings >>> and transition times, such as 25:00, into the ones that the current >>> JDK recognizes, then produces the data file "tzdb.dat" at the build >>> time. At the run time, the data file is read and interpreted as >>> before. This way the produced tzdb.dat is compatible with the prior >>> JDK releases so that the TZ Updater can also distribute it as a time >>> zone update. >>> >>> I have also refactored redundant copy of ZoneRules file in the build >>> directory, by dynamically importing the file under src. Thus some >>> build related files are modified. I am hoping folks on the build-dev >>> can review those changes. >>> >>> Naoto >> From kevin.rushforth at oracle.com Thu Jul 25 15:22:39 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 25 Jul 2019 08:22:39 -0700 Subject: RFR: JDK-8227684 : jpackage must handle win32 mangled names in jli.dll In-Reply-To: References: Message-ID: <38a0218b-7da9-cbea-2d76-510785454cd9@oracle.com> It looks fine. -- Kevin On 7/25/2019 6:20 AM, Andy Herrick wrote: > Please review the jpackage fix for bug [1] at [2]. > > This is a fix for the JDK-8200758-branch branch of the open sandbox > repository (jpackage). > > > [1] https://bugs.openjdk.java.net/browse/JDK-8227684 > > [2] http://cr.openjdk.java.net/~herrick/8227684/webrev.01/ > > Submitted by: Robert Lichtenberger > > /Andy > From kevin.rushforth at oracle.com Thu Jul 25 15:24:21 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 25 Jul 2019 08:24:21 -0700 Subject: RFR: JDK-8227312: Remove pkg bundle from DMG image. In-Reply-To: <1913b81b-e4da-bb35-38be-cad6f677ab55@oracle.com> References: <1913b81b-e4da-bb35-38be-cad6f677ab55@oracle.com> Message-ID: <5122a6e6-283b-3562-fcc0-c508cd4828fb@oracle.com> Looks fine. -- Kevin On 7/25/2019 6:24 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). > > [1] https://bugs.openjdk.java.net/browse/JDK-8227312 > > [2] http://cr.openjdk.java.net/~herrick/8227312/webrev.01/ > > /Andy > From li.jiang at oracle.com Thu Jul 25 16:27:17 2019 From: li.jiang at oracle.com (li.jiang at oracle.com) Date: Fri, 26 Jul 2019 00:27:17 +0800 Subject: RFR: 8228623 : Update copyright year to 2019 for several java properties file Message-ID: <8575c88a-b267-1b88-b5ac-3311a5c7459d@oracle.com> Hi, Please review this trivial change to correct the copyright year in several java properties file. I updated the copyright year in English, Simplified Chinese and Japanese resource files. Bug: https://bugs.openjdk.java.net/browse/JDK-8228623 Webrev: http://cr.openjdk.java.net/~ljiang/8228623/webrev/ Thanks, Leo From erik.joelsson at oracle.com Thu Jul 25 17:55:46 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 25 Jul 2019 10:55:46 -0700 Subject: [14] RFR: 8212970: TZ database in "vanguard" format support In-Reply-To: References: <82dadb56-b776-9741-fe5c-823c4f0948fa@oracle.com> Message-ID: Build change looks good. /Erik On 2019-07-24 15:24, naoto.sato at oracle.com wrote: > Hi Joe, > > Thank you for the review. > > On 7/24/19 2:57 PM, Joe Wang wrote: >> Hi Naoto, >> >> The method findNegativeSavings method in TzdbZoneRulesProvider.java >> states that it "Find the minimum negative savings". While the result >> is correct since the rules all have the same value for SAVE, I wonder >> if that's ideal conceptually. Given a start LDT, shouldn't it be >> looking for the SAVE in the exact (narrower) date range (e.g. 1981 - >> 1989 vs 1981 - max)?. > > I believe it is working as such. The end year is retrieved within the > method (line 879) and only the minimum negative saving values within > the window is filtered. > >> >> NegativeDSTTest verifies the tzdata, that is the adjusted data after >> import, is that correct? I wonder a comment and a bit of details in >> the test summary would be helpful since there is no negative data in >> the test itself. > > Good point. It is confusing. I supplied summary text in the test (also > the similar line in TestZoneRules.java) > > Here is the updated webrev: > > http://cr.openjdk.java.net/~naoto/8212970/webrev.11/ > > Naoto >> >> Best, >> Joe >> >> On 7/23/19 3:15 PM, naoto.sato at oracle.com wrote: >>> Hi, >>> >>> Please review the fix to the following enhancement: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8212970 >>> >>> The proposed changeset is located at: >>> >>> https://cr.openjdk.java.net/~naoto/8212970/webrev.09/ >>> >>> This change aims to support the "vanguard" IANA time zone data >>> format, which uses the negative savings and transition time beyond a >>> day period. The change basically translates those negative savings >>> and transition times, such as 25:00, into the ones that the current >>> JDK recognizes, then produces the data file "tzdb.dat" at the build >>> time. At the run time, the data file is read and interpreted as >>> before. This way the produced tzdb.dat is compatible with the prior >>> JDK releases so that the TZ Updater can also distribute it as a time >>> zone update. >>> >>> I have also refactored redundant copy of ZoneRules file in the build >>> directory, by dynamically importing the file under src. Thus some >>> build related files are modified. I am hoping folks on the build-dev >>> can review those changes. >>> >>> Naoto >> From pavel.rappo at oracle.com Thu Jul 25 19:43:43 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 25 Jul 2019 20:43:43 +0100 Subject: 8078891: java.io.SequenceInputStream.close is not atomic and not idempotent In-Reply-To: <6824EDFA-BF3F-40A5-A872-527631868BD4@oracle.com> References: <6824EDFA-BF3F-40A5-A872-527631868BD4@oracle.com> Message-ID: <4E569709-129A-4163-B19B-588680CD219C@oracle.com> Brian, Thanks a lot for picking up a bug I filled back in 2015. This looks like a good cleanup! I'm a bit concerned though with the added `finally` block in L98. Could that lead to a subtle behavioral change for (an unlikely) case where a `read` method exhausts the current stream, then tries to close it, fails (`close` throws IOException) and then jumps over to the next stream instead of staying on the current one? Previously, `read` would be tripping over a closed stream forever. Theoretically speaking, we might have a case of a "non-sticky" error in the InputStream. Try to read, fail, try to read again -- you might get lucky. Thanks, -Pavel > On 24 Jul 2019, at 01:09, Brian Burkhalter wrote: > > https://bugs.openjdk.java.net/browse/JDK-8078891 > http://cr.openjdk.java.net/~bpb/8078891/webrev.00/ > > Ensure that SequenceInputStream closes all component streams. > > Thanks, > > Brian From brian.burkhalter at oracle.com Thu Jul 25 20:01:54 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 25 Jul 2019 13:01:54 -0700 Subject: 8078891: java.io.SequenceInputStream.close is not atomic and not idempotent In-Reply-To: <4E569709-129A-4163-B19B-588680CD219C@oracle.com> References: <6824EDFA-BF3F-40A5-A872-527631868BD4@oracle.com> <4E569709-129A-4163-B19B-588680CD219C@oracle.com> Message-ID: <7A501E65-3AAA-4AE1-B7CE-AC1DA7E0AC98@oracle.com> Hi Pavel, > On Jul 25, 2019, at 12:43 PM, Pavel Rappo wrote: > > Thanks a lot for picking up a bug I filled back in 2015. This looks like a good > cleanup! Thanks for looking at it. > I'm a bit concerned though with the added `finally` block in L98. Could that > lead to a subtle behavioral change for (an unlikely) case where a `read` method > exhausts the current stream, then tries to close it, fails (`close` throws > IOException) and then jumps over to the next stream instead of staying on the > current one? > > Previously, `read` would be tripping over a closed stream forever. This concern would be fixed by changing the proposed patch as --- a/src/java.base/share/classes/java/io/SequenceInputStream.java +++ b/src/java.base/share/classes/java/io/SequenceInputStream.java @@ -91,13 +91,10 @@ * Continues reading in the next stream if an EOF is reached. */ final void nextStream() throws IOException { - try { - if (in != null) { - in.close(); - } - } finally { - peekNextStream(); + if (in != null) { + in.close(); } + peekNextStream(); } private void peekNextStream() { @@ -233,6 +230,7 @@ } else { ioe.addSuppressed(e); } + peekNextStream(); } } while (in != null); if (ioe != null) { That is to say reverting the nextStream() change and adding peekNextStream() in the catch branch of close(). I actually had it this way in a version I did not post. The scenario you suggest however would seem to be somewhat of a coding error by the caller. I would think that once a sequence stream were created the component streams should not be used. > Theoretically speaking, we might have a case of a "non-sticky" error in the > InputStream. Try to read, fail, try to read again -- you might get lucky. Thanks, Brian From naoto.sato at oracle.com Thu Jul 25 20:04:33 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 25 Jul 2019 13:04:33 -0700 Subject: [14] RFR: 8212970: TZ database in "vanguard" format support In-Reply-To: References: <82dadb56-b776-9741-fe5c-823c4f0948fa@oracle.com> Message-ID: <40d84ae9-5648-0b32-3daf-55a28022a489@oracle.com> Hi Roger, On 7/25/19 7:47 AM, Roger Riggs wrote: > Hi Naoto, > > TestZoneInfo310.java: > With the composition of the tzdir path up and over to the make directory > for the tzdir > it might be useful to do an explicit check that the directory exists. > That way if the directory structure on the build side changes, > there will be a test failure makine it obvious that the dependency has > changed. If the input tz data files, either in "test" tree or "make" tree, cannot be located, the test will fail which effectively reports if there is a repo structure change. So I believe it is ok as it is. Aside from it, the latest changes to eliminate the duplicates caused that regression test fail. The reason was that there were actually two "jdk11_backward" data files each in "tzdata" and "tzdata_jdk" test directories, and the contents differ! I am not sure the reason why there are two files this way (seems to be so for years), so I reverted that exact file as before. Here is the webrev reflected that: http://cr.openjdk.java.net/~naoto/8212970/webrev.12/ Naoto > > Looks fine. > > Thanks, Roger > > > > On 7/24/19 6:24 PM, naoto.sato at oracle.com wrote: >> Hi Joe, >> >> Thank you for the review. >> >> On 7/24/19 2:57 PM, Joe Wang wrote: >>> Hi Naoto, >>> >>> The method findNegativeSavings method in TzdbZoneRulesProvider.java >>> states that it "Find the minimum negative savings". While the result >>> is correct since the rules all have the same value for SAVE, I wonder >>> if that's ideal conceptually. Given a start LDT, shouldn't it be >>> looking for the SAVE in the exact (narrower) date range (e.g. 1981 - >>> 1989 vs 1981 - max)?. >> >> I believe it is working as such. The end year is retrieved within the >> method (line 879) and only the minimum negative saving values within >> the window is filtered. >> >>> >>> NegativeDSTTest verifies the tzdata, that is the adjusted data after >>> import, is that correct? I wonder a comment and a bit of details in >>> the test summary would be helpful since there is no negative data in >>> the test itself. >> >> Good point. It is confusing. I supplied summary text in the test (also >> the similar line in TestZoneRules.java) >> >> Here is the updated webrev: >> >> http://cr.openjdk.java.net/~naoto/8212970/webrev.11/ >> >> Naoto >>> >>> Best, >>> Joe >>> >>> On 7/23/19 3:15 PM, naoto.sato at oracle.com wrote: >>>> Hi, >>>> >>>> Please review the fix to the following enhancement: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8212970 >>>> >>>> The proposed changeset is located at: >>>> >>>> https://cr.openjdk.java.net/~naoto/8212970/webrev.09/ >>>> >>>> This change aims to support the "vanguard" IANA time zone data >>>> format, which uses the negative savings and transition time beyond a >>>> day period. The change basically translates those negative savings >>>> and transition times, such as 25:00, into the ones that the current >>>> JDK recognizes, then produces the data file "tzdb.dat" at the build >>>> time. At the run time, the data file is read and interpreted as >>>> before. This way the produced tzdb.dat is compatible with the prior >>>> JDK releases so that the TZ Updater can also distribute it as a time >>>> zone update. >>>> >>>> I have also refactored redundant copy of ZoneRules file in the build >>>> directory, by dynamically importing the file under src. Thus some >>>> build related files are modified. I am hoping folks on the build-dev >>>> can review those changes. >>>> >>>> Naoto >>> > From mandy.chung at oracle.com Thu Jul 25 20:12:49 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 25 Jul 2019 13:12:49 -0700 Subject: Review Request: JDK-8209005: Lookup.unreflectSpecial fails for default methods when Lookup.findSpecial works Message-ID: <8a3743fc-5ac3-0f79-2ee5-9814de6444e7@oracle.com> This patch fixes Lookup.unreflectSpecial to pass the declaring class of Method being unreflected (rather than null) so that it can accurately check if the special caller class is either the lookup class or a superinterface of the declaring class. Webrev: http://cr.openjdk.java.net/~mchung/jdk14/8209005/webrev.00/index.html The test runs in both unnamed module and named module to cover JDK-8209078 which has been resolved by JDK-8173978. thanks Mandy From alexander.matveev at oracle.com Thu Jul 25 20:33:31 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Thu, 25 Jul 2019 13:33:31 -0700 Subject: RFR (S): JDK-8222778: Packaging Tool (JEP 343) on Linux/AArch64 In-Reply-To: <258360f5-16e0-1735-e64c-fcdcf3a22010@bell-sw.com> References: <234f1c54-bd2a-c90b-367b-e279062218ff@bell-sw.com> <0ec8f547-8e21-7fd2-1091-886dc7a4d2b1@bell-sw.com> <28da2683-40a9-80be-9d35-63d7976557c6@redhat.com> <5d757f33-fd75-8eb5-9d71-29c3481eb43b@oracle.com> <258360f5-16e0-1735-e64c-fcdcf3a22010@bell-sw.com> Message-ID: Hi Dmitry, Looks good. Thanks, Alexander On 7/25/2019 5:38 AM, Dmitry Chuyko wrote: > I realized we also need better detection of arch for deb control file. > It can be done by using 'dpkg --print-architecture' on host. > LinuxDebBundler was corrected. > > New webrev: http://cr.openjdk.java.net/~dchuyko/8222778/webrev.04/ > > Patch was re-tested together with webrev.02 from JDK-8228402. > > -Dmitry > > On 7/25/19 12:56 AM, Alexander Matveev wrote: >> Looks good. >> >> On 7/24/2019 7:30 AM, Dmitry Chuyko wrote: >>> Webrev without chdir() and write() changes: >>> http://cr.openjdk.java.net/~dchuyko/8222778/webrev.03/ >>> >>> When it is applied together with webrev.01 [1] from JDK-8228402, >>> sandbox is compiled and passes same jpackage tests on x86, aarch64 >>> and other platforms. >>> >>> -Dmitry >>> >>> [1] http://cr.openjdk.java.net/~herrick/8228402/ >>> >>> On 7/19/19 11:31 AM, Andrew Haley wrote: >>>> On 7/19/19 12:36 AM, Dmitry Chuyko wrote: >>>>> On 7/18/19 11:57 AM, Andrew Haley wrote: >>>>>> Hi, >>>>>> >>>>>> On 7/17/19 10:19 PM, Dmitry Chuyko wrote: >>>>>>> On 7/17/19 11:52 AM, Andrew Haley wrote: >>>>>>>> This is weird: >>>>>>>> >>>>>>>> --- >>>>>>>> old/src/jdk.jpackage/linux/native/libapplauncher/LinuxPlatform.cpp >>>>>>>> 2019-07-16 22:11:30.200258978 +0300 >>>>>>>> +++ >>>>>>>> new/src/jdk.jpackage/linux/native/libapplauncher/LinuxPlatform.cpp >>>>>>>> 2019-07-16 22:11:29.867374851 +0300 >>>>>>>> @@ -127,7 +127,7 @@ >>>>>>>> ??? } >>>>>>>> >>>>>>>> ??? void LinuxPlatform::SetCurrentDirectory(TString Value) { >>>>>>>> - chdir(PlatformString(Value).toPlatformString()); >>>>>>>> +??? int ignored = >>>>>>>> chdir(PlatformString(Value).toPlatformString()); >>>>>>>> ??? } >>>>>>>> >>>>>>>> Firstly it does not fix the problem: you've gone from an unused >>>>>>>> value to an >>>>>>>> unused variable. Secondly, we ignore the return value of printf >>>>>>>> all the time; >>>>>>>> what's different about this one? >>>>>>> chdir() is __wur, which is >>>>>>> /usr/include/aarch64-linux-gnu/sys/cdefs.h:# >>>>>>> define __wur __attribute_warn_unused_result__ >>>>>> OK, got it. >>>>>> >>>>>>> In some places this warning is disabled (CoreLibraries.gmk, >>>>>>> Awt2dLibraries.gmk). >>>>>>> >>>>>>> It would be more correct to handle the result here as chdir >>>>>>> might not >>>>>>> succeeded in fact. >>>>>> Very much so. We shouldn't try to "shut up the compiler" in this >>>>>> way.Andrew Haley >>>>> I created a separate bug about chdir() and write() usages: >>>>> https://bugs.openjdk.java.net/browse/JDK-8228402 >>>>> >>>>> Does it look good to silence warnings for platforms support changes? >>>> I think we should fix the bugs, not silence the warnings. >>>> >>>>> One >>>>> more option could be to exclude related changes from current review. >>>> OK. >>>> >> From naoto.sato at oracle.com Thu Jul 25 20:36:48 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 25 Jul 2019 13:36:48 -0700 Subject: RFR: 8228623 : Update copyright year to 2019 for several java properties file In-Reply-To: <8575c88a-b267-1b88-b5ac-3311a5c7459d@oracle.com> References: <8575c88a-b267-1b88-b5ac-3311a5c7459d@oracle.com> Message-ID: <6590f8bd-b024-d912-7532-f3443c589f22@oracle.com> Hi Leo, Looks good to me. I rather prefer noreg-l10n other than noreg-doc for the Jira issue label. Naoto On 7/25/19 9:27 AM, li.jiang at oracle.com wrote: > Hi, > > Please review this trivial change to correct the copyright year in > several java properties file. I updated the copyright year in English, > Simplified Chinese and Japanese resource files. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8228623 > > Webrev: > http://cr.openjdk.java.net/~ljiang/8228623/webrev/ > > Thanks, > Leo From huizhe.wang at oracle.com Thu Jul 25 21:24:23 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 25 Jul 2019 14:24:23 -0700 Subject: [14] RFR: 8212970: TZ database in "vanguard" format support In-Reply-To: <40d84ae9-5648-0b32-3daf-55a28022a489@oracle.com> References: <82dadb56-b776-9741-fe5c-823c4f0948fa@oracle.com> <40d84ae9-5648-0b32-3daf-55a28022a489@oracle.com> Message-ID: Hi Naoto, The legacy trap :-) Relevant files: 1. make/data/tzdata/jdk11_backward 2. test/jdk/sun/util/calendar/zi/tzdata/jdk11_backward 3. test/jdk/sun/util/calendar/zi/tzdata_jdk/jdk11_backward 4. test/jdk/sun/util/calendar/zi/tzdata_jdk/jdk11_full_backward I see you reverted changes to (1) plus removing (2) and (4). (3) and (4) differs slightly, but contains the changes previously made in (1). Probably not something to worry about since only (3) is referenced, and (4) not. Just wonder whether you've checked on this one. I assume your build and test passed without any issues. Best, Joe On 7/25/19 1:04 PM, naoto.sato at oracle.com wrote: > Hi Roger, > > On 7/25/19 7:47 AM, Roger Riggs wrote: >> Hi Naoto, >> >> TestZoneInfo310.java: >> With the composition of the tzdir path up and over to the make >> directory for the tzdir >> it might be useful to do an explicit check that the directory exists. >> That way if the directory structure on the build side changes, >> there will be a test failure makine it obvious that the dependency >> has changed. > > If the input tz data files, either in "test" tree or "make" tree, > cannot be located, the test will fail which effectively reports if > there is a repo structure change. So I believe it is ok as it is. > > Aside from it, the latest changes to eliminate the duplicates caused > that regression test fail. The reason was that there were actually two > "jdk11_backward" data files each in "tzdata" and "tzdata_jdk" test > directories, and the contents differ! I am not sure the reason why > there are two files this way (seems to be so for years), so I reverted > that exact file as before. Here is the webrev reflected that: > > http://cr.openjdk.java.net/~naoto/8212970/webrev.12/ > > Naoto > >> >> Looks fine. >> >> Thanks, Roger >> >> >> >> On 7/24/19 6:24 PM, naoto.sato at oracle.com wrote: >>> Hi Joe, >>> >>> Thank you for the review. >>> >>> On 7/24/19 2:57 PM, Joe Wang wrote: >>>> Hi Naoto, >>>> >>>> The method findNegativeSavings method in TzdbZoneRulesProvider.java >>>> states that it "Find the minimum negative savings". While the >>>> result is correct since the rules all have the same value for SAVE, >>>> I wonder if that's ideal conceptually. Given a start LDT, shouldn't >>>> it be looking for the SAVE in the exact (narrower) date range (e.g. >>>> 1981 - 1989 vs 1981 - max)?. >>> >>> I believe it is working as such. The end year is retrieved within >>> the method (line 879) and only the minimum negative saving values >>> within the window is filtered. >>> >>>> >>>> NegativeDSTTest verifies the tzdata, that is the adjusted data >>>> after import, is that correct? I wonder a comment and a bit of >>>> details in the test summary would be helpful since there is no >>>> negative data in the test itself. >>> >>> Good point. It is confusing. I supplied summary text in the test >>> (also the similar line in TestZoneRules.java) >>> >>> Here is the updated webrev: >>> >>> http://cr.openjdk.java.net/~naoto/8212970/webrev.11/ >>> >>> Naoto >>>> >>>> Best, >>>> Joe >>>> >>>> On 7/23/19 3:15 PM, naoto.sato at oracle.com wrote: >>>>> Hi, >>>>> >>>>> Please review the fix to the following enhancement: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8212970 >>>>> >>>>> The proposed changeset is located at: >>>>> >>>>> https://cr.openjdk.java.net/~naoto/8212970/webrev.09/ >>>>> >>>>> This change aims to support the "vanguard" IANA time zone data >>>>> format, which uses the negative savings and transition time beyond >>>>> a day period. The change basically translates those negative >>>>> savings and transition times, such as 25:00, into the ones that >>>>> the current JDK recognizes, then produces the data file "tzdb.dat" >>>>> at the build time. At the run time, the data file is read and >>>>> interpreted as before. This way the produced tzdb.dat is >>>>> compatible with the prior JDK releases so that the TZ Updater can >>>>> also distribute it as a time zone update. >>>>> >>>>> I have also refactored redundant copy of ZoneRules file in the >>>>> build directory, by dynamically importing the file under src. Thus >>>>> some build related files are modified. I am hoping folks on the >>>>> build-dev can review those changes. >>>>> >>>>> Naoto >>>> >> From alexander.matveev at oracle.com Thu Jul 25 21:29:03 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Thu, 25 Jul 2019 14:29:03 -0700 Subject: RFR: JDK-8227684 : jpackage must handle win32 mangled names in jli.dll In-Reply-To: <38a0218b-7da9-cbea-2d76-510785454cd9@oracle.com> References: <38a0218b-7da9-cbea-2d76-510785454cd9@oracle.com> Message-ID: Do you know if all 32-bit builds will have "_JLI_Launch at 56"? Also, I think @56 is ordinal which can be used to load function by this number instead of the name, so I do not think you need to specify it. My suggestion is to try "JLI_Launch" first and then "_JLI_Launch" and then "_JLI_Launch at 56", if we doing 32-bit build. Thanks, Alexander On 7/25/2019 8:22 AM, Kevin Rushforth wrote: > It looks fine. > > -- Kevin > > > On 7/25/2019 6:20 AM, Andy Herrick wrote: >> Please review the jpackage fix for bug [1] at [2]. >> >> This is a fix for the JDK-8200758-branch branch of the open sandbox >> repository (jpackage). >> >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8227684 >> >> [2] http://cr.openjdk.java.net/~herrick/8227684/webrev.01/ >> >> Submitted by: Robert Lichtenberger >> >> /Andy >> > From naoto.sato at oracle.com Thu Jul 25 21:35:51 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 25 Jul 2019 14:35:51 -0700 Subject: [14] RFR: 8212970: TZ database in "vanguard" format support In-Reply-To: References: <82dadb56-b776-9741-fe5c-823c4f0948fa@oracle.com> <40d84ae9-5648-0b32-3daf-55a28022a489@oracle.com> Message-ID: Hi Joe, Yes, I only removed not in-use files, i.e., 2 & 4. I sent the previous email just after confirming that all tests (open/closed) passed on a platform :-) Naoto On 7/25/19 2:24 PM, Joe Wang wrote: > Hi Naoto, > > The legacy trap :-) > > Relevant files: > 1. make/data/tzdata/jdk11_backward > 2. test/jdk/sun/util/calendar/zi/tzdata/jdk11_backward > 3. test/jdk/sun/util/calendar/zi/tzdata_jdk/jdk11_backward > 4. test/jdk/sun/util/calendar/zi/tzdata_jdk/jdk11_full_backward > > I see you reverted changes to (1) plus removing (2) and (4). (3) and (4) > differs slightly, but contains the changes previously made in (1). > Probably not something to worry about since only (3) is referenced, and > (4) not. Just wonder whether you've checked on this one. I assume your > build and test passed without any issues. > > Best, > Joe > > On 7/25/19 1:04 PM, naoto.sato at oracle.com wrote: >> Hi Roger, >> >> On 7/25/19 7:47 AM, Roger Riggs wrote: >>> Hi Naoto, >>> >>> TestZoneInfo310.java: >>> With the composition of the tzdir path up and over to the make >>> directory for the tzdir >>> it might be useful to do an explicit check that the directory exists. >>> That way if the directory structure on the build side changes, >>> there will be a test failure makine it obvious that the dependency >>> has changed. >> >> If the input tz data files, either in "test" tree or "make" tree, >> cannot be located, the test will fail which effectively reports if >> there is a repo structure change. So I believe it is ok as it is. >> >> Aside from it, the latest changes to eliminate the duplicates caused >> that regression test fail. The reason was that there were actually two >> "jdk11_backward" data files each in "tzdata" and "tzdata_jdk" test >> directories, and the contents differ! I am not sure the reason why >> there are two files this way (seems to be so for years), so I reverted >> that exact file as before. Here is the webrev reflected that: >> >> http://cr.openjdk.java.net/~naoto/8212970/webrev.12/ >> >> Naoto >> >>> >>> Looks fine. >>> >>> Thanks, Roger >>> >>> >>> >>> On 7/24/19 6:24 PM, naoto.sato at oracle.com wrote: >>>> Hi Joe, >>>> >>>> Thank you for the review. >>>> >>>> On 7/24/19 2:57 PM, Joe Wang wrote: >>>>> Hi Naoto, >>>>> >>>>> The method findNegativeSavings method in TzdbZoneRulesProvider.java >>>>> states that it "Find the minimum negative savings". While the >>>>> result is correct since the rules all have the same value for SAVE, >>>>> I wonder if that's ideal conceptually. Given a start LDT, shouldn't >>>>> it be looking for the SAVE in the exact (narrower) date range (e.g. >>>>> 1981 - 1989 vs 1981 - max)?. >>>> >>>> I believe it is working as such. The end year is retrieved within >>>> the method (line 879) and only the minimum negative saving values >>>> within the window is filtered. >>>> >>>>> >>>>> NegativeDSTTest verifies the tzdata, that is the adjusted data >>>>> after import, is that correct? I wonder a comment and a bit of >>>>> details in the test summary would be helpful since there is no >>>>> negative data in the test itself. >>>> >>>> Good point. It is confusing. I supplied summary text in the test >>>> (also the similar line in TestZoneRules.java) >>>> >>>> Here is the updated webrev: >>>> >>>> http://cr.openjdk.java.net/~naoto/8212970/webrev.11/ >>>> >>>> Naoto >>>>> >>>>> Best, >>>>> Joe >>>>> >>>>> On 7/23/19 3:15 PM, naoto.sato at oracle.com wrote: >>>>>> Hi, >>>>>> >>>>>> Please review the fix to the following enhancement: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8212970 >>>>>> >>>>>> The proposed changeset is located at: >>>>>> >>>>>> https://cr.openjdk.java.net/~naoto/8212970/webrev.09/ >>>>>> >>>>>> This change aims to support the "vanguard" IANA time zone data >>>>>> format, which uses the negative savings and transition time beyond >>>>>> a day period. The change basically translates those negative >>>>>> savings and transition times, such as 25:00, into the ones that >>>>>> the current JDK recognizes, then produces the data file "tzdb.dat" >>>>>> at the build time. At the run time, the data file is read and >>>>>> interpreted as before. This way the produced tzdb.dat is >>>>>> compatible with the prior JDK releases so that the TZ Updater can >>>>>> also distribute it as a time zone update. >>>>>> >>>>>> I have also refactored redundant copy of ZoneRules file in the >>>>>> build directory, by dynamically importing the file under src. Thus >>>>>> some build related files are modified. I am hoping folks on the >>>>>> build-dev can review those changes. >>>>>> >>>>>> Naoto >>>>> >>> > From alexander.matveev at oracle.com Thu Jul 25 21:49:29 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Thu, 25 Jul 2019 14:49:29 -0700 Subject: RFR: JDK-8227312: Remove pkg bundle from DMG image. In-Reply-To: <5122a6e6-283b-3562-fcc0-c508cd4828fb@oracle.com> References: <1913b81b-e4da-bb35-38be-cad6f677ab55@oracle.com> <5122a6e6-283b-3562-fcc0-c508cd4828fb@oracle.com> Message-ID: Looks fine. On 7/25/2019 8:24 AM, Kevin Rushforth wrote: > Looks fine. > > -- Kevin > > On 7/25/2019 6:24 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). >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8227312 >> >> [2] http://cr.openjdk.java.net/~herrick/8227312/webrev.01/ >> >> /Andy >> > From huizhe.wang at oracle.com Thu Jul 25 22:08:58 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 25 Jul 2019 15:08:58 -0700 Subject: [14] RFR: 8212970: TZ database in "vanguard" format support In-Reply-To: References: <82dadb56-b776-9741-fe5c-823c4f0948fa@oracle.com> <40d84ae9-5648-0b32-3daf-55a28022a489@oracle.com> Message-ID: Looks all good Naoto :-) -Joe On 7/25/19 2:35 PM, naoto.sato at oracle.com wrote: > Hi Joe, > > Yes, I only removed not in-use files, i.e., 2 & 4. I sent the previous > email just after confirming that all tests (open/closed) passed on a > platform :-) > > Naoto > > On 7/25/19 2:24 PM, Joe Wang wrote: >> Hi Naoto, >> >> The legacy trap :-) >> >> Relevant files: >> 1. make/data/tzdata/jdk11_backward >> 2. test/jdk/sun/util/calendar/zi/tzdata/jdk11_backward >> 3. test/jdk/sun/util/calendar/zi/tzdata_jdk/jdk11_backward >> 4. test/jdk/sun/util/calendar/zi/tzdata_jdk/jdk11_full_backward >> >> I see you reverted changes to (1) plus removing (2) and (4). (3) and >> (4) differs slightly, but contains the changes previously made in >> (1). Probably not something to worry about since only (3) is >> referenced, and (4) not. Just wonder whether you've checked on this >> one. I assume your build and test passed without any issues. >> >> Best, >> Joe >> >> On 7/25/19 1:04 PM, naoto.sato at oracle.com wrote: >>> Hi Roger, >>> >>> On 7/25/19 7:47 AM, Roger Riggs wrote: >>>> Hi Naoto, >>>> >>>> TestZoneInfo310.java: >>>> With the composition of the tzdir path up and over to the make >>>> directory for the tzdir >>>> it might be useful to do an explicit check that the directory exists. >>>> That way if the directory structure on the build side changes, >>>> there will be a test failure makine it obvious that the dependency >>>> has changed. >>> >>> If the input tz data files, either in "test" tree or "make" tree, >>> cannot be located, the test will fail which effectively reports if >>> there is a repo structure change. So I believe it is ok as it is. >>> >>> Aside from it, the latest changes to eliminate the duplicates caused >>> that regression test fail. The reason was that there were actually >>> two "jdk11_backward" data files each in "tzdata" and "tzdata_jdk" >>> test directories, and the contents differ! I am not sure the reason >>> why there are two files this way (seems to be so for years), so I >>> reverted that exact file as before. Here is the webrev reflected that: >>> >>> http://cr.openjdk.java.net/~naoto/8212970/webrev.12/ >>> >>> Naoto >>> >>>> >>>> Looks fine. >>>> >>>> Thanks, Roger >>>> >>>> >>>> >>>> On 7/24/19 6:24 PM, naoto.sato at oracle.com wrote: >>>>> Hi Joe, >>>>> >>>>> Thank you for the review. >>>>> >>>>> On 7/24/19 2:57 PM, Joe Wang wrote: >>>>>> Hi Naoto, >>>>>> >>>>>> The method findNegativeSavings method in >>>>>> TzdbZoneRulesProvider.java states that it "Find the minimum >>>>>> negative savings". While the result is correct since the rules >>>>>> all have the same value for SAVE, I wonder if that's ideal >>>>>> conceptually. Given a start LDT, shouldn't it be looking for the >>>>>> SAVE in the exact (narrower) date range (e.g. 1981 - 1989 vs 1981 >>>>>> - max)?. >>>>> >>>>> I believe it is working as such. The end year is retrieved within >>>>> the method (line 879) and only the minimum negative saving values >>>>> within the window is filtered. >>>>> >>>>>> >>>>>> NegativeDSTTest verifies the tzdata, that is the adjusted data >>>>>> after import, is that correct? I wonder a comment and a bit of >>>>>> details in the test summary would be helpful since there is no >>>>>> negative data in the test itself. >>>>> >>>>> Good point. It is confusing. I supplied summary text in the test >>>>> (also the similar line in TestZoneRules.java) >>>>> >>>>> Here is the updated webrev: >>>>> >>>>> http://cr.openjdk.java.net/~naoto/8212970/webrev.11/ >>>>> >>>>> Naoto >>>>>> >>>>>> Best, >>>>>> Joe >>>>>> >>>>>> On 7/23/19 3:15 PM, naoto.sato at oracle.com wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review the fix to the following enhancement: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8212970 >>>>>>> >>>>>>> The proposed changeset is located at: >>>>>>> >>>>>>> https://cr.openjdk.java.net/~naoto/8212970/webrev.09/ >>>>>>> >>>>>>> This change aims to support the "vanguard" IANA time zone data >>>>>>> format, which uses the negative savings and transition time >>>>>>> beyond a day period. The change basically translates those >>>>>>> negative savings and transition times, such as 25:00, into the >>>>>>> ones that the current JDK recognizes, then produces the data >>>>>>> file "tzdb.dat" at the build time. At the run time, the data >>>>>>> file is read and interpreted as before. This way the produced >>>>>>> tzdb.dat is compatible with the prior JDK releases so that the >>>>>>> TZ Updater can also distribute it as a time zone update. >>>>>>> >>>>>>> I have also refactored redundant copy of ZoneRules file in the >>>>>>> build directory, by dynamically importing the file under src. >>>>>>> Thus some build related files are modified. I am hoping folks on >>>>>>> the build-dev can review those changes. >>>>>>> >>>>>>> Naoto >>>>>> >>>> >> From huizhe.wang at oracle.com Thu Jul 25 22:28:18 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 25 Jul 2019 15:28:18 -0700 Subject: RFR [14/java.xml] 8068376: Validator fails valid XML files due to String == in XSD validator code Message-ID: <4ee88b9e-f2b5-29f9-f773-755bc3e8e286@oracle.com> Please review a quite fix in a validation source where a String comparison was made as references. JBS: https://bugs.openjdk.java.net/browse/JDK-8068376 webrev: http://cr.openjdk.java.net/~joehw/jdk14/8068376/webrev/ Thanks, Joe From brian.burkhalter at oracle.com Thu Jul 25 22:42:43 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 25 Jul 2019 15:42:43 -0700 Subject: 8193072: File.delete() should remove its path from DeleteOnExitHook.files In-Reply-To: References: <9608451A-321D-4CD7-9DD9-04524AC4F53D@oracle.com> <0525c4cf-4a02-1f9b-2950-a0750cbf4a48@oracle.com> <0d67cb9d-96d1-9e55-dda5-31ede2770cfd@oracle.com> <0ab34cb3-38c6-1e62-cc1c-13b9d343ab6c@oracle.com> <096A2B42-5635-4254-92CA-2EB2758BD5D1@oracle.com> <777C2632-ABF3-496A-BB82-01A9733DD747@oracle.com> <2D863386-A47C-491A-93A8-52F870F7F4E8@oracle.com> <55C9CB46-46E5-4F80-84BC-95682A0D343B@oracle.com> <35f38610-f450-cace-3d21-068b482326ff@oracle.com> <1d81786f-0d4a-c140-38fa-60b7140dcc41@gmail.com> Message-ID: <1ABCCC42-38CF-43DC-AEF3-5B9722F348CC@oracle.com> > On Jul 11, 2019, at 12:52 AM, Peter Levart wrote: > > On 7/11/19 9:47 AM, Peter Levart wrote: >> >> http://cr.openjdk.java.net/~plevart/jdk-dev/8193072_File.undoDeleteOnExit/webrev.02/ >> > > Another thing to consider (done in above webrev.02) is what to do with unbalanced cancelDeleteOnExit(). I think it is better to throw exception than to silently ignore it. This way unintentional bugs can be uncovered which would otherwise just cause erratic behavior. The above patch looks pretty good but unless I am not comprehending the code I think there may still be behavioral incompatibilities which might not be acceptable. For example, for the existing code base with the following sequence of operations File file1, file2, file3; file1.deleteOnExit(); file2.deleteOnExit(); file3.deleteOnExit(); the deletion order is file3, file2, file1. For the proposed patch with the following sequence of operations file1.deleteOnExit(); file2.deleteOnExit(); file3.deleteOnExit(); file1.cancelDeleteOnExit(); // file1 is removed from the map file2.cancelDeleteOnExit(); // file2 is removed from the map file2.createNewFIle(); file2.deleteOnExit(); // file2 is added back into the map file1.createNewFIle(); file1.deleteOnExit(); // file1 is added back into the map the deletion order is (I think) file1, file2, file3 which is the reverse of the order of initial registration. Of course it is conceivable to change the specification but that seems dangerous somehow. Also for the patch above for this sequence of operations file1.deleteOnExit(); file2.deleteOnExit(); file3.deleteOnExit(); file1.cancelDeleteOnExit(); // file1 is removed from the map file2.cancelDeleteOnExit(); // file2 is removed from the map file2.createNewFIle(); file1.createNewFIle(); then file3 is deleted on exit but file1 and file2 are not which differs from current behavior. As Roger wrote > On Jul 9, 2019, at 7:34 AM, Roger Riggs wrote: > > The filename is the key and there is no way to determine if it is the original file or a replacement. deleteOnExit Wins! the filename is the key and if we toss the key then we lose the order of registration. Given this I am not sure any more that it is possible to fix this issue without introducing an incompatible behavioral change. Thanks, Brian From brian.burkhalter at oracle.com Thu Jul 25 22:58:20 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 25 Jul 2019 15:58:20 -0700 Subject: 8193072: File.delete() should remove its path from DeleteOnExitHook.files In-Reply-To: <1ABCCC42-38CF-43DC-AEF3-5B9722F348CC@oracle.com> References: <9608451A-321D-4CD7-9DD9-04524AC4F53D@oracle.com> <0525c4cf-4a02-1f9b-2950-a0750cbf4a48@oracle.com> <0d67cb9d-96d1-9e55-dda5-31ede2770cfd@oracle.com> <0ab34cb3-38c6-1e62-cc1c-13b9d343ab6c@oracle.com> <096A2B42-5635-4254-92CA-2EB2758BD5D1@oracle.com> <777C2632-ABF3-496A-BB82-01A9733DD747@oracle.com> <2D863386-A47C-491A-93A8-52F870F7F4E8@oracle.com> <55C9CB46-46E5-4F80-84BC-95682A0D343B@oracle.com> <35f38610-f450-cace-3d21-068b482326ff@oracle.com> <1d81786f-0d4a-c140-38fa-60b7140dcc41@gmail.com> <1ABCCC42-38CF-43DC-AEF3-5B9722F348CC@oracle.com> Message-ID: <04A27338-72E1-4C31-B526-6205C27D6098@oracle.com> > On Jul 25, 2019, at 3:42 PM, Brian Burkhalter wrote: > > the deletion order is (I think) file1, file2, file3 which is the reverse of the order of initial registration. I intended *not* the reverse order of initial registration. Brian From lance.andersen at oracle.com Thu Jul 25 23:04:05 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 25 Jul 2019 19:04:05 -0400 Subject: RFR [14/java.xml] 8068376: Validator fails valid XML files due to String == in XSD validator code In-Reply-To: <4ee88b9e-f2b5-29f9-f773-755bc3e8e286@oracle.com> References: <4ee88b9e-f2b5-29f9-f773-755bc3e8e286@oracle.com> Message-ID: <046ADEB0-CF88-4745-80E7-A845C28BBF8B@oracle.com> Hi Joe The change looks reasonable :-) > On Jul 25, 2019, at 6:28 PM, Joe Wang wrote: > > Please review a quite fix in a validation source where a String comparison was made as references. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8068376 > webrev: http://cr.openjdk.java.net/~joehw/jdk14/8068376/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 Thu Jul 25 23:26:55 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 25 Jul 2019 16:26:55 -0700 Subject: RFR [14/java.xml] 8068376: Validator fails valid XML files due to String == in XSD validator code In-Reply-To: <046ADEB0-CF88-4745-80E7-A845C28BBF8B@oracle.com> References: <4ee88b9e-f2b5-29f9-f773-755bc3e8e286@oracle.com> <046ADEB0-CF88-4745-80E7-A845C28BBF8B@oracle.com> Message-ID: Thanks Lance! -Joe On 7/25/19 4:04 PM, Lance Andersen wrote: > Hi Joe > > The change looks reasonable :-) > >> On Jul 25, 2019, at 6:28 PM, Joe Wang > > wrote: >> >> Please review a quite fix in a validation source where a String >> comparison was made as references. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8068376 >> webrev: http://cr.openjdk.java.net/~joehw/jdk14/8068376/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 bourges.laurent at gmail.com Fri Jul 26 07:39:30 2019 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Fri, 26 Jul 2019 09:39:30 +0200 Subject: Benchmarking of new optimized Dual-Pivot Quicksort In-Reply-To: <1564063481.101106990@f551.i.mail.ru> References: <1564063481.101106990@f551.i.mail.ru> Message-ID: Hi Vladimir, First Thank you for these impressive results: 15% to 70% overall gains is amazing and will make a big difference, Congratulations ! Could you publish the different test environment ? - HW: cpu (lscpu output) - OS version - JDK version + JVM settings Ideally you or I could write a shell script to collect setup and write a simple log file. PS: I suppose you tested DPQS only on intel cpus, could somebody test on ppc or arm cpus as well ? Cheers, Laurent Le jeu. 25 juil. 2019 ? 16:04, Vladimir Yaroslavskiy a ?crit : > Hi all, > > With the help of Laurent Bourges I run benchmarking of new optimized > Dual-Pivot Quicksort > and summarized results. The tests were run for all types (int / long / ... > / double), for both types: > sequential and parallel sorting, for small, medium and large sizes. The > comparison was done > on several data types, such as: random, period, sorted, equal, stagger, > shuffle. > > Here is the summary of total gains. The gain is defined as (jdk_time - > dpqs_time) / jdk_time, > where jdk_time is sorting time by the current jdk14 and dpqs_time is > sorting time by new > optimized Dual-Pivot Quicksort. To get stable and reproducible results, > min time of many > invocations is taken. > > You can find all detailed results there > https://github.com/iaroslavski/sorting/tree/master/benchmarking/results > > Sources of benchmarking tests are there > https://github.com/iaroslavski/sorting/tree/master/benchmarking/sources > > You > can see not good performance for float / double types (parallel sorting). > This behavior can be explained by existing bug in jdk, when NaNs and -0.0s > are not processed properly. New sorting has total losses for small float / > double > arrays, few percents only. For all other cases new optimized sorting is > winner. > > > -------------------------------------------------------------------------------------------------------- > [int] > > sequential, Length = 150, Gain: 0.15 > sequential, Length = 30000, Gain: 0.28 > sequential, Length = 1000000, Gain: 0.31 > parallel 8, Length = 150, Gain: 0.14 > parallel 8, Length = 30000, Gain: 0.15 > parallel 8, Length = 1000000, Gain: 0.14 > > [long] > sequential, Length = 150, Gain: 0.12 > sequential, Length = 30000, Gain: 0.23 > sequential, Length = 1000000, Gain: 0.32 > parallel 8, Length = 150, Gain: 0.11 > parallel 8, Length = 30000, Gain: 0.16 > parallel 8, Length = 1000000, Gain: 0.24 > parallel 88 processors, Length = 1000000, Gain: 0.05 > > [byte] > sequential, Length = 150, Gain: 0.06 > sequential, Length = 30000, Gain: 0.36 > sequential, Length = 1000000, Gain: 0.37 > parallel 8, Length = 150, Gain: 0.13 > parallel 8, Length = 30000, Gain: 0.73 > parallel 8, Length = 1000000, Gain: 0.65 > > [char] > sequential, Length = 150, Gain: 0.10 > sequential, Length = 30000, Gain: 0.00 > sequential, Length = 1000000, Gain: 0.17 > parallel 8, Length = 150, Gain: 0.10 > parallel 8, Length = 30000, Gain: 0.33 > parallel 8, Length = 1000000, Gain: 0.62 > > [short] > sequential, Length = 150, Gain: 0.14 > sequential, Length = 30000, Gain: 0.10 > sequential, Length = 1000000, Gain: 0.18 > parallel 8, Length = 150, Gain: 0.13 > parallel 8, Length = 30000, Gain: 0.41 > parallel 8, Length = 1000000, Gain: 0.65 > > [float] > sequential, Length = 150, Gain: -0.02 > sequential, Length = 30000, Gain: 0.21 > sequential, Length = 1000000, Gain: 0.24 > parallel 8, Length = 150, Gain: -0.05 > parallel 8, Length = 30000, Gain: -0.04 > parallel 8, Length = 1000000, Gain: -0.12 > > [double] > sequential, Length = 150, Gain: -0.03 > sequential, Length = 30000, Gain: 0.19 > sequential, Length = 1000000, Gain: 0.23 > parallel 8, Length = 150, Gain: -0.05 > parallel 8, Length = 30000, Gain: 0.05 > parallel 8, Length = 1000000, Gain: 0.15 > > Thank you, > Vladimir > From bourges.laurent at gmail.com Fri Jul 26 08:14:46 2019 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Fri, 26 Jul 2019 10:14:46 +0200 Subject: The final optimized version of Dual-Pivot Quicksort (ver.19.1) In-Reply-To: References: <1560893862.105095134@f487.i.mail.ru> <5ab79374-a561-de15-6a35-0dde138fdcb9@oracle.com> Message-ID: Hi all, I updated the DPQS patch thanks to latest release from Vladimir ([image: Pi?ces jointes]2019.07.25): http://cr.openjdk.java.net/~lbourges/dpqs/dpqs-8226297/dpqs-8226297.1/ " Updated version of Arrays and DualPivotQuicksort files, the summary of changes: 1. Corrected minimal threshold for parallelism argument (0 -> 1) 2. Added constant for common parallelism 3. Updated byte / char / short counting sort. " Incremental patch change: http://cr.openjdk.java.net/~lbourges/dpqs/dpqs-8226297/diff_dpqs_1_vs_0.log Cheers, Laurent Le mer. 17 juil. 2019 ? 17:12, Laurent Bourg?s a ?crit : > Hi, > > I integrated locally the complete DPQS 19.2 patch from Vladimir > Yaroslavskiy with up-to-date jdk14 (client) repository: > build OK and jtreg passed OK (java/util/Arrays). > > Here is the corresponding webrev for review: > http://cr.openjdk.java.net/~lbourges/dpqs/dpqs-8226297/webrev/ > > Cheers, > Laurent > From peter.levart at gmail.com Fri Jul 26 08:37:30 2019 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 26 Jul 2019 10:37:30 +0200 Subject: 8193072: File.delete() should remove its path from DeleteOnExitHook.files In-Reply-To: <1ABCCC42-38CF-43DC-AEF3-5B9722F348CC@oracle.com> References: <9608451A-321D-4CD7-9DD9-04524AC4F53D@oracle.com> <0525c4cf-4a02-1f9b-2950-a0750cbf4a48@oracle.com> <0d67cb9d-96d1-9e55-dda5-31ede2770cfd@oracle.com> <0ab34cb3-38c6-1e62-cc1c-13b9d343ab6c@oracle.com> <096A2B42-5635-4254-92CA-2EB2758BD5D1@oracle.com> <777C2632-ABF3-496A-BB82-01A9733DD747@oracle.com> <2D863386-A47C-491A-93A8-52F870F7F4E8@oracle.com> <55C9CB46-46E5-4F80-84BC-95682A0D343B@oracle.com> <35f38610-f450-cace-3d21-068b482326ff@oracle.com> <1d81786f-0d4a-c140-38fa-60b7140dcc41@gmail.com> <1ABCCC42-38CF-43DC-AEF3-5B9722F348CC@oracle.com> Message-ID: Hi Brian, On 7/26/19 12:42 AM, Brian Burkhalter wrote: > >> On Jul 11, 2019, at 12:52 AM, Peter Levart > > wrote: >> >> On 7/11/19 9:47 AM, Peter Levart wrote: >>> >>> http://cr.openjdk.java.net/~plevart/jdk-dev/8193072_File.undoDeleteOnExit/webrev.02/ >>> >> >> Another thing to consider (done in above webrev.02) is what to do >> with unbalanced cancelDeleteOnExit(). I think it is better to throw >> exception than to silently ignore it. This way unintentional bugs can >> be uncovered which would otherwise just cause erratic behavior. > > The above patch looks pretty good but unless I am not comprehending > the code I think there may still be behavioral incompatibilities which > might not be acceptable. For example, for the existing code base with > the following sequence of operations > > File file1, file2, file3; > > file1.deleteOnExit(); > file2.deleteOnExit(); > file3.deleteOnExit(); > > the deletion order is file3, file2, file1. ...and the same order remains with the proposed patch for above sequence of operations. > For the proposed patch with the following sequence of operations > > file1.deleteOnExit(); > file2.deleteOnExit(); > file3.deleteOnExit(); > file1.cancelDeleteOnExit(); // file1 is removed from the map > file2.cancelDeleteOnExit(); // file2 is removed from the map > file2.createNewFIle(); > file2.deleteOnExit(); // file2 is added back into the map > file1.createNewFIle(); > file1.deleteOnExit(); // file1 is added back into the map > > the deletion order is (I think) file1, file2, file3 which is the > reverse of the order of initial registration. Right, and above sequence of operations is something that is not present in current codebases as there is no cancelDeleteOnExit() method yet. So more to the point would be a comparison of behaviors with some code sequence that doesn't include the not yet present method. Suppose the following: file1.deleteOnExit(); file1.createNewFile(); file2.deleteOnExit(); file2.createNewFile(); file3.deleteOnExit(); file3.createNewFile(); file1.delete(); file2.delete(); file2.deleteOnExit(); file2.createNewFile(); file1.deleteOnExit(); file1.createNewFile(); Yes, with above sequence the order of deletion using current codebase will be file3, file2, file1, while with the patch, it would be file1, file2, file3. > Of course it is conceivable to change the specification but that seems > dangerous somehow. Of course there could be a situation where the change of order mattered for the correct logic of the program - imagine an empty "signal" file which guarantees with its presence that another "payload" file is present and fully written/consistent. You would want to maintain such an invariant so you would 1st register the payloadFile.deleteOnExit() following with signalFile.deleteOnExit(). But most such schemes are one-way only. If you wanted to somehow delete the signal file and then re-create it later after updating the payload file, you might already be doing the re-registration in the correct order (if you are just repeating the same code sequence as in initial registration), but you are making a concurrency mistake anyway as you are faced with a race inherent to an ABA problem that has nothing to do with registration to delete files on exit. So I argue that any working scheme that features multiple registrations of the same file must be because of dependencies among them stemming from the filesystem hierarchy. For example, you would 1st want to register a new File("/path/to/dir").deleteOnExit() followed by new File("/path/to/dir/file.ext").deleteOnExit() so that on exit, the file is deleted 1st and then the dir which must be empty for deletion to succeed. In this hypothetical example, you might, at some point delete the file and unregister it (keeping the dir present and registered) and later re-register and re-create the file. The deletion will still work correctly in this case. Or you might want to delete the file and dir and unregister them for them to be re-registered and re-created later. If such code is present now (modulo de-registering) it probably performs the re-registration in the correct order already. In other words, any code that changes the deletion order with the patch but doesn't with current codebase is re-registering the same file (in wrong order) relying on the fact that the file is already registered (in the correct order). Only such code could break, but the chances are great the it won't. > Also for the patch above for this sequence of operations > > file1.deleteOnExit(); > file2.deleteOnExit(); > file3.deleteOnExit(); > file1.cancelDeleteOnExit(); // file1 is removed from the map > file2.cancelDeleteOnExit(); // file2 is removed from the map > file2.createNewFIle(); > file1.createNewFIle(); > > then file3 is deleted on exit but file1 and file2 are not which > differs from current behavior. Right, because there is "no current behavior" with above sequence of operations, because there is currently no cancelDeleteOnExit() method. So there's no valid comparison. > > As Roger wrote > >> On Jul 9, 2019, at 7:34 AM, Roger Riggs > > wrote: >> >> The filename is the key and there is no way to determine if it is the >> original file or a replacement. deleteOnExit Wins! > > the filename is the key and if we toss the key then we lose the order > of registration. Given this I am not sure any more that it is possible > to fix this issue without introducing an incompatible behavioral change. What above a system property that restores the previous behavior and is deprecated at start with removal to be determined? Regards, Peter > > Thanks, > > Brian > > From vlv.spb.ru at mail.ru Fri Jul 26 10:03:40 2019 From: vlv.spb.ru at mail.ru (=?UTF-8?B?VmxhZGltaXIgWWFyb3NsYXZza2l5?=) Date: Fri, 26 Jul 2019 13:03:40 +0300 Subject: =?UTF-8?B?UmVbMl06IEJlbmNobWFya2luZyBvZiBuZXcgb3B0aW1pemVkIER1YWwtUGl2?= =?UTF-8?B?b3QgUXVpY2tzb3J0?= In-Reply-To: References: <1564063481.101106990@f551.i.mail.ru> Message-ID: <1564135420.972580843@f344.i.mail.ru> Hi?Laurent, Many thanks for feedback! I run tests on two computers under Windows (8 processors) and Linux (88 processors). The details of the first computer is:?Window 10 (64-bit), Intel Core i7 8650U 1.90 GHz and output of "uname -a" command for the second computer is: Linux rho 4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24 10:55:24 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux The JDK on Windows is?OpenJDK 64-Bit Server VM,?build 14-ea+6-171, on Linux - jdk13 latest version. The setting for JVM running is (one option -Xbatch only): java -Xbatch -classpath %CLASSES% Main Also I uploaded the results from Linux computer for sequential sorting of int / long arrays. details are there? https://github.com/iaroslavski/sorting/tree/master/benchmarking/results The files -s- and?-p- are related to the first (Windows) computer, the files -s88- and?-p88- are related to the second (Linux) computer. The summary is here: [int] sequential sorting, gain: Windows: size 1M: 0.31; size 30K: 0.28; size: 150: 0.15 ? ? ? Linux: size 1M: 0.31; size 30K: 0.27; size: 150: 0.07 [long] sequential sorting, gain: Windows: size 1M: 0.32; size 30K: 0.23; size 150: 0.12 ? ? ? Linux: size 1M: 0.30; size 30K: 0.23; size 150: 0.05 You can see that sorting shows the same results on large and medium sizes?for both types, and it works slower on small size on Linux, but shows positive gains. Thank you, Vladimir >???????, 26 ???? 2019, 10:43 +03:00 ?? Laurent Bourg?s : > >Hi Vladimir, > >First Thank you for these impressive results: 15% to 70% overall gains is amazing and will make a big difference, Congratulations ! > >Could you publish the different test environment ? >- HW: cpu (lscpu output) >- OS version >- JDK version + JVM settings? > >Ideally you or I could write a shell script to collect setup and write a simple log file. > >PS: I suppose you tested DPQS only on intel cpus, could somebody test on ppc or arm cpus as well ? > >Cheers, >Laurent >Le jeu. 25 juil. 2019 ? 16:04, Vladimir Yaroslavskiy < vlv.spb.ru at mail.ru > a ?crit?: >>Hi all, >>With the help of Laurent Bourges I run benchmarking of new optimized Dual-Pivot Quicksort >>and summarized results. The tests were run for all types (int / long / ... / double), for both types: >>sequential and parallel sorting, for small, medium and large sizes. The comparison was done >>on several data types, such as: random, period, sorted, equal, stagger, shuffle. >>Here is the summary of total gains. The gain is defined as (jdk_time - dpqs_time) / jdk_time, >>where jdk_time is sorting time by the current jdk14 and dpqs_time is sorting time by new >>optimized Dual-Pivot Quicksort. To get stable and reproducible results, min time of?many >>invocations is taken. >>You can find all detailed results?there >>https://github.com/iaroslavski/sorting/tree/master/benchmarking/results >> >>Sources of benchmarking tests are there >>https://github.com/iaroslavski/sorting/tree/master/benchmarking/sources >> >>You can see not good performance for float / double types (parallel sorting). >>This behavior can be explained by existing bug in jdk, when NaNs and -0.0s >>are not processed properly. New sorting has total losses for small float / double >>arrays, few percents only. For all other cases new optimized sorting is winner. >> >>-------------------------------------------------------------------------------------------------------- >>[int] >>sequential, Length = 150, Gain: 0.15 >>sequential, Length = 30000, Gain: 0.28 >>sequential, Length = 1000000, Gain: 0.31 >>parallel 8, Length = 150, Gain: 0.14 >>parallel 8, Length = 30000, Gain: 0.15 >>parallel 8, Length = 1000000, Gain: 0.14 >>[long] >>sequential, Length = 150, Gain: 0.12 >>sequential, Length = 30000, Gain: 0.23 >>sequential, Length = 1000000, Gain: 0.32 >>parallel 8, Length = 150, Gain: 0.11 >>parallel 8, Length = 30000, Gain: 0.16 >>parallel 8, Length = 1000000, Gain: 0.24 >>parallel 88 processors, Length = 1000000, Gain: 0.05 >>[byte] >>sequential, Length = 150, Gain: 0.06 >>sequential, Length = 30000, Gain: 0.36 >>sequential, Length = 1000000, Gain: 0.37 >>parallel 8, Length = 150, Gain: 0.13 >>parallel 8, Length = 30000, Gain: 0.73 >>parallel 8, Length = 1000000, Gain: 0.65 >>[char] >>sequential, Length = 150, Gain: 0.10 >>sequential, Length = 30000, Gain: 0.00 >>sequential, Length = 1000000, Gain: 0.17 >>parallel 8, Length = 150, Gain: 0.10 >>parallel 8, Length = 30000, Gain: 0.33 >>parallel 8, Length = 1000000, Gain: 0.62 >>[short] >>sequential, Length = 150, Gain: 0.14 >>sequential, Length = 30000, Gain: 0.10 >>sequential, Length = 1000000, Gain: 0.18 >>parallel 8, Length = 150, Gain: 0.13 >>parallel 8, Length = 30000, Gain: 0.41 >>parallel 8, Length = 1000000, Gain: 0.65 >>[float] >>sequential, Length = 150, Gain: -0.02 >>sequential, Length = 30000, Gain: 0.21 >>sequential, Length = 1000000, Gain: 0.24 >>parallel 8, Length = 150, Gain: -0.05 >>parallel 8, Length = 30000, Gain: -0.04 >>parallel 8, Length = 1000000, Gain: -0.12 >>[double] >>sequential, Length = 150, Gain: -0.03 >>sequential, Length = 30000, Gain: 0.19 >>sequential, Length = 1000000, Gain: 0.23 >>parallel 8, Length = 150, Gain: -0.05 >>parallel 8, Length = 30000, Gain: 0.05 >>parallel 8, Length = 1000000, Gain: 0.15 >>Thank you, >>Vladimir From pavel.rappo at oracle.com Fri Jul 26 11:14:47 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 26 Jul 2019 12:14:47 +0100 Subject: 8078891: java.io.SequenceInputStream.close is not atomic and not idempotent In-Reply-To: <7A501E65-3AAA-4AE1-B7CE-AC1DA7E0AC98@oracle.com> References: <6824EDFA-BF3F-40A5-A872-527631868BD4@oracle.com> <4E569709-129A-4163-B19B-588680CD219C@oracle.com> <7A501E65-3AAA-4AE1-B7CE-AC1DA7E0AC98@oracle.com> Message-ID: > On 25 Jul 2019, at 21:01, Brian Burkhalter wrote: > This concern would be fixed by changing the proposed patch as > > --- a/src/java.base/share/classes/java/io/SequenceInputStream.java > +++ b/src/java.base/share/classes/java/io/SequenceInputStream.java > @@ -91,13 +91,10 @@ > * Continues reading in the next stream if an EOF is reached. > */ > final void nextStream() throws IOException { > - try { > - if (in != null) { > - in.close(); > - } > - } finally { > - peekNextStream(); > + if (in != null) { > + in.close(); > } > + peekNextStream(); > } > > private void peekNextStream() { > @@ -233,6 +230,7 @@ > } else { > ioe.addSuppressed(e); > } > + peekNextStream(); > } > } while (in != null); > if (ioe != null) { > > That is to say reverting the nextStream() change and adding peekNextStream() in the catch branch of close(). I actually had it this way in a version I did not post. > > The scenario you suggest however would seem to be somewhat of a coding error by the caller. I would think that once a sequence stream were created the component streams should not be used. When I filed this bug I was mainly concerned with the fact that `close` may end up closing only some of the component streams. Both your original and amended patches seem to fix this problem. However, I prefer the amended version. As it both does the job and preserves the original behavior when consuming data from the current component stream. The scenario I mentioned in my previous email was about continuous attempts to read from the SequenceInputStream, not about reading component streams "out-of-band" (bypassing the aggregating SequenceInputStream). Sorry if I didn't make myself clear. This scenario doesn't seem to be a programming error, albeit a very strange use case. I must admit I haven't seen any code in the wild doing so. Yet the spec does not seem to prohibit this. A nit on the accompanying test. Please consider this change: diff -r 5a65ed97e38b test/jdk/java/io/SequenceInputStream/Close.java --- a/test/jdk/java/io/SequenceInputStream/Close.java Fri Jul 26 12:10:08 2019 +0100 +++ b/test/jdk/java/io/SequenceInputStream/Close.java Fri Jul 26 12:12:29 2019 +0100 @@ -27,17 +27,15 @@ */ import java.io.ByteArrayInputStream; -import java.io.InputStream; import java.io.IOException; import java.io.SequenceInputStream; -import java.util.ArrayList; import java.util.Collections; import java.util.Enumeration; import java.util.List; public class Close { - public static void main(String[] argv) throws IOException { + public static void main(String[] argv) { byte[] buf = new byte[42]; List list = List.of(new CloseableBAOS(buf), @@ -74,12 +72,12 @@ static class CloseableBAOS extends ByteArrayInputStream{ private boolean closed; - private int numCloses = 0; CloseableBAOS(byte[] buf) { super(buf); } + @Override public void close() throws IOException { closed = true; throw new IOException(); From andy.herrick at oracle.com Fri Jul 26 12:22:10 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 26 Jul 2019 08:22:10 -0400 Subject: RFR: JDK-8227684 : jpackage must handle win32 mangled names in jli.dll In-Reply-To: References: <38a0218b-7da9-cbea-2d76-510785454cd9@oracle.com> Message-ID: <61c382e2-7f63-ac5d-2f93-66a7a258e542@oracle.com> On 7/25/2019 5:29 PM, Alexander Matveev wrote: > Do you know if all 32-bit builds will have "_JLI_Launch at 56"? > Also, I think @56 is ordinal which can be used to load function by > this number instead of the name, so I do not think you need to specify > it. > > My suggestion is to try "JLI_Launch" first and then "_JLI_Launch" and > then "_JLI_Launch at 56", if we doing 32-bit build. > > Thanks, > Alexander > Oracle does not support, build, or test the jdk (or jpackage in particular) on 32 bit platforms, nor use jpackage to package 32 bit apps. We will take submitted fixes (such as this one) from others who do use 32 bit builds, provided they do not break our 64 bit builds in any way. That being said I think we should take this fix "as is", and allow Robert (or any other contributor who is using 32 bits) to propose any further 32 bit related changes, /Andy > On 7/25/2019 8:22 AM, Kevin Rushforth wrote: >> It looks fine. >> >> -- Kevin >> >> >> On 7/25/2019 6:20 AM, Andy Herrick wrote: >>> Please review the jpackage fix for bug [1] at [2]. >>> >>> This is a fix for the JDK-8200758-branch branch of the open sandbox >>> repository (jpackage). >>> >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8227684 >>> >>> [2] http://cr.openjdk.java.net/~herrick/8227684/webrev.01/ >>> >>> Submitted by: Robert Lichtenberger >>> >>> /Andy >>> >> > From jens at lidestrom.se Fri Jul 26 12:26:40 2019 From: jens at lidestrom.se (=?UTF-8?Q?Jens_Lidestr=c3=b6m?=) Date: Fri, 26 Jul 2019 14:26:40 +0200 Subject: RFR (M): JDK-6394757: rev1: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes In-Reply-To: References: <78809c47-590b-2662-b4d9-77c66948dcb6@oracle.com> <0B02F956-F964-4E00-9261-3B2D0A38DA55@cbfiddle.com> <38db52aa-74a9-a008-94f1-d80e5c3acae3@oracle.com> <32291cb3-a2e2-b3ba-5396-f6b8c8deb17f@oracle.com> <3BAF7EFF-8229-402E-B8F5-09EA80434313@cbfiddle.com> Message-ID: <8bf55a11-bcf4-0218-9a09-a977786f0e56@lidestrom.se> Hello core-lib-dev, I think it is a mistake to make `AbstractSet#removeAll` use the membership semantics of the argument collection instead of those of the receiver set, and to iterate over the receiver instead of the argument collection. I think that there are much stronger arguments for doing it the other way around: to use the membership semantics of the receiver and to iterate over the argument. This is what Stuart suggest in his first prototype [1], but unlike the how it looks in the current webrev [2]. After having read through the original thread (most importantly this message: [3]) and the review threads, it is my impression that the disadvantages of this solution have been over-emphasised and the advantages under-emphasised. This is my impression of the advantages and disadvantages of making `removeAll` use the membership semantics of the receiver set: ## Advantages 1. It leads to the expected behaviour when custom membership semantics are used. 2. It preserves the behaviour in the common case when custom membership semantics are used. 3. It has better performance for hashed sets in the common case. ## Disadvantages 4. It is different from `AbstractCollection`. 5. It is not possible to do in `retainAll`, and thus make the two methods inconsistent. (See [3].) I don't think 1-2 has been given enough weight in the discussion, and that 4-5 have been given too much. ## Details 1. I think that often `removeAll` is called without much tough about the properties of the argument collection, except for its members. It will be confusing, annoying and error prone if code like this doesn't work as expected: var s = new TreeSet<>(String::compareToIgnoreCase); s.addAll(List.of("a", "b", "c"); // Should remove "a" and "b" s.removeAll(List.of("A", "B")); Non-set collections on the other hand are probably much less likely to have custom membership semantics. Because of this they can get away with using the membership semantics of the argument, without exhibiting unexpected behaviour for code that is similar to the above. 2. The consequences are even more sever if code like the above stops working as expected. This will probably cause some code that has been working for years (decades?) to suddenly fails. * I think that it is much more common to use `removeAll` to remove a small number of elements from a bigger set. If the membership semantics of the argument are to be used in that case, then the behaviour of existing code will change. If on the other hand the membership semantics of the receiver are to be used, then existing code will continue to behave in the same way. * I think that existing code that works in the opposite way, that depends on the custom membership semantics of the argument of `removeAll`, is much more uncommon, and thus that it is more acceptable that such code stops working. 3. Alan Snyder wrote about performance at length in his mails. This is an important point, even if the arguments above are more important. For example, some applications with large HashSet-based caches might stop working in a satisfactory way. 4. I think that consistency with `AbstractCollection#removeAll` has been given too much importance in the discussion. Sets are different from lists, and it seem justified that the implementation of `removeAll` in AbstractSet works in a different way from `AbstractCollection`. * Collections that allow duplicates are forced to iterate `this` out of necessity. * But sets have no duplicates. It is natural take advantage of this fact and iterate the argument. It seems unlikely that this would be unexpected for anyone or lead to problems. * Non-set collections are probably much less likely to have custom equality semantics, which makes iterating over the argument less problematic. 5. The difference in behaviour between `retainAll` and `removeAll` that is the result of using the membership semantics of the receiver is, I think, the most serious disadvantage of this solution. This disadvantage is not as strong as the advantages in 1-2 above, however. Also, I think that there is some justification to it. I think `retainAll` is perceived much more as a set theoretic operation than `removeAll`. This makes it more intuitive for a user that you should ensure that the argument to that method is a collection with the right membership semantics. ### Conclusion I think the following original suggestion [1] is a much better choice for an implementation of `AbstractSet#removeAll` than the existing implementation in `AbstractCollection`: public boolean removeAll(Collection c) { Objects.requireNonNull(c); boolean modified = false; for (Object e : c) modified |= remove(e); return modified; } [1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/058172.html [2]: http://cr.openjdk.java.net/~smarks/reviews/6394757/webrev.1/ [3]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058539.html BR, Jens Lidestr?m Proud new Eclipse committer From brian.burkhalter at oracle.com Fri Jul 26 15:41:30 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 26 Jul 2019 08:41:30 -0700 Subject: 8078891: java.io.SequenceInputStream.close is not atomic and not idempotent In-Reply-To: References: <6824EDFA-BF3F-40A5-A872-527631868BD4@oracle.com> <4E569709-129A-4163-B19B-588680CD219C@oracle.com> <7A501E65-3AAA-4AE1-B7CE-AC1DA7E0AC98@oracle.com> Message-ID: <232EA0BC-AA13-4157-95AA-2D92B5D5B2ED@oracle.com> > On Jul 26, 2019, at 4:14 AM, Pavel Rappo wrote: > > [?] I prefer the amended version. As it > both does the job and preserves the original behavior when consuming data from > the current component stream. > > [?] > > A nit on the accompanying test. Please consider this change: Please see the updated patch which switches the implementation to the amended version and incorporates the proposed change to the test: http://cr.openjdk.java.net/~bpb/8078891/webrev.01/ Thanks, Brian From daniel.fuchs at oracle.com Fri Jul 26 16:20:44 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 26 Jul 2019 18:20:44 +0200 Subject: 8078891: java.io.SequenceInputStream.close is not atomic and not idempotent In-Reply-To: <232EA0BC-AA13-4157-95AA-2D92B5D5B2ED@oracle.com> References: <6824EDFA-BF3F-40A5-A872-527631868BD4@oracle.com> <4E569709-129A-4163-B19B-588680CD219C@oracle.com> <7A501E65-3AAA-4AE1-B7CE-AC1DA7E0AC98@oracle.com> <232EA0BC-AA13-4157-95AA-2D92B5D5B2ED@oracle.com> Message-ID: On 26/07/2019 17:41, Brian Burkhalter wrote: > Please see the updated patch which switches the implementation to the amended version and incorporates the proposed change to the test: > > http://cr.openjdk.java.net/~bpb/8078891/webrev.01/ That looks good to me Brian. I had a look at the API documentation of AutoCloseable::close() Though the further behavior of the closed object when close throws an exception is a bit fuzzy - your amended implementation has greater compatibility with preexisting behavior of SequenceInputStream, and is in line with what one would expect by reading AutoCloseable::close(). Thanks Pavel for suggesting this! best regards, -- daniel > > Thanks, > > Brian From mandy.chung at oracle.com Fri Jul 26 17:41:22 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 26 Jul 2019 10:41:22 -0700 Subject: Review Request: JDK-8209005: Lookup.unreflectSpecial fails for default methods when Lookup.findSpecial works In-Reply-To: <8a3743fc-5ac3-0f79-2ee5-9814de6444e7@oracle.com> References: <8a3743fc-5ac3-0f79-2ee5-9814de6444e7@oracle.com> Message-ID: <6c13f13b-e08f-af91-f583-8acf48ee7182@oracle.com> Daniel noticed that `unreflectSpecial` is missing in the "Lookup Factory Methods" section in the class spec.? In fact there are a duplicated `lookup.unreflect(aMethod)` row that might originally be for `unreflectSpecial`.?? I fix the javadoc in this patch: http://cr.openjdk.java.net/~mchung/jdk14/8209005/webrev.01/ Mandy On 7/25/19 1:12 PM, Mandy Chung wrote: > This patch fixes Lookup.unreflectSpecial to pass the declaring class > of Method being unreflected (rather than null) so that it can > accurately check if the special caller class is either the lookup > class or a superinterface of the declaring class. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk14/8209005/webrev.00/index.html > > The test runs in both unnamed module and named module to cover > JDK-8209078 which has been resolved by JDK-8173978. > > thanks > Mandy From naoto.sato at oracle.com Fri Jul 26 18:03:33 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 26 Jul 2019 11:03:33 -0700 Subject: [14] RFR: 8228465: HOST locale provider holds wrong era name for GregorianCalendar in US locale Message-ID: <896001db-ee9f-b5c6-09ff-a605f2429c4f@oracle.com> Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8228465 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8228465/webrev.00/ Similar issue was reported with JDK-8039301, in which Calendar.getDisplayName() method was modified. The same fix needs to be applied to Calendar.getDisplayNames(). Naoto From lance.andersen at oracle.com Fri Jul 26 18:17:06 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 26 Jul 2019 14:17:06 -0400 Subject: RFR 8226808: PreparedStatement javadoc typo Message-ID: <21851EBF-D777-4F3D-89A6-E558D82757F9@oracle.com> Hi all, Please review this trivial change for JDK-8226808 which corrects a javadoc error that dates back to JDK 1.1 where the example for BigDecimal is not correct: ????? $ hg diff diff -r 550a1a6ca596 src/java.sql/share/classes/java/sql/PreparedStatement.java --- a/src/java.sql/share/classes/java/sql/PreparedStatement.java Fri Jul 26 17:15:17 2019 +0000 +++ b/src/java.sql/share/classes/java/sql/PreparedStatement.java Fri Jul 26 14:13:09 2019 -0400 @@ -47,12 +47,13 @@ *

    * In the following example of setting a parameter, con represents * an active connection: - * 

    + * 
    {@code
+ *   BigDecimal sal = new BigDecimal("153833.00");
  *   PreparedStatement pstmt = con.prepareStatement("UPDATE EMPLOYEES
  *                                     SET SALARY = ? WHERE ID = ?");
- *   pstmt.setBigDecimal(1, 153833.00)
- *   pstmt.setInt(2, 110592)
- * 
    
+ *   pstmt.setBigDecimal(1, sal);
+ *   pstmt.setInt(2, 110592);
+ * }
    * * @see Connection#prepareStatement * @see ResultSet ljanders-mac:open ljanders$ ??????? Best, Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From lance.andersen at oracle.com Fri Jul 26 18:23:48 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 26 Jul 2019 14:23:48 -0400 Subject: [14] RFR: 8228465: HOST locale provider holds wrong era name for GregorianCalendar in US locale In-Reply-To: <896001db-ee9f-b5c6-09ff-a605f2429c4f@oracle.com> References: <896001db-ee9f-b5c6-09ff-a605f2429c4f@oracle.com> Message-ID: <11C84D42-898B-43D2-AB51-724349F00339@oracle.com> Hi Naoto, This looks good > On Jul 26, 2019, at 2:03 PM, naoto.sato at oracle.com wrote: > > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8228465 > > The proposed changeset is located at: > > https://cr.openjdk.java.net/~naoto/8228465/webrev.00/ > > Similar issue was reported with JDK-8039301, in which Calendar.getDisplayName() method was modified. The same fix needs to be applied to Calendar.getDisplayNames(). > > Naoto Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From huizhe.wang at oracle.com Fri Jul 26 18:29:08 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 26 Jul 2019 11:29:08 -0700 Subject: RFR 8226808: PreparedStatement javadoc typo In-Reply-To: <21851EBF-D777-4F3D-89A6-E558D82757F9@oracle.com> References: <21851EBF-D777-4F3D-89A6-E558D82757F9@oracle.com> Message-ID: +1, and +1 for the salary at the time of JDK 1.1 ;-) -Joe On 7/26/19 11:17 AM, Lance Andersen wrote: > Hi all, > > Please review this trivial change for JDK-8226808 which corrects a javadoc error that dates back to JDK 1.1 where the example for BigDecimal is not correct: > > ????? > $ hg diff > diff -r 550a1a6ca596 src/java.sql/share/classes/java/sql/PreparedStatement.java > --- a/src/java.sql/share/classes/java/sql/PreparedStatement.java Fri Jul 26 17:15:17 2019 +0000 > +++ b/src/java.sql/share/classes/java/sql/PreparedStatement.java Fri Jul 26 14:13:09 2019 -0400 > @@ -47,12 +47,13 @@ > *

    > * In the following example of setting a parameter, con represents > * an active connection: > - * 

    > + * 
    {@code
> + *   BigDecimal sal = new BigDecimal("153833.00");
>    *   PreparedStatement pstmt = con.prepareStatement("UPDATE EMPLOYEES
>    *                                     SET SALARY = ? WHERE ID = ?");
> - *   pstmt.setBigDecimal(1, 153833.00)
> - *   pstmt.setInt(2, 110592)
> - * 
    
> + *   pstmt.setBigDecimal(1, sal);
> + *   pstmt.setInt(2, 110592);
> + * }
    > * > * @see Connection#prepareStatement > * @see ResultSet > ljanders-mac:open ljanders$ > ??????? > > Best, > Lance > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From brian.burkhalter at oracle.com Fri Jul 26 18:32:11 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 26 Jul 2019 11:32:11 -0700 Subject: RFR 8226808: PreparedStatement javadoc typo In-Reply-To: References: <21851EBF-D777-4F3D-89A6-E558D82757F9@oracle.com> Message-ID: <69037FDD-FCBD-429D-ADE3-D72EBD12FAB7@oracle.com> ++1 Brian > On Jul 26, 2019, at 11:29 AM, Joe Wang wrote: > > +1, and +1 for the salary at the time of JDK 1.1 ;-) > > -Joe > > On 7/26/19 11:17 AM, Lance Andersen wrote: >> Hi all, >> >> Please review this trivial change for JDK-8226808 which corrects a javadoc error that dates back to JDK 1.1 where the example for BigDecimal is not correct: >> >> ????? >> $ hg diff >> diff -r 550a1a6ca596 src/java.sql/share/classes/java/sql/PreparedStatement.java >> --- a/src/java.sql/share/classes/java/sql/PreparedStatement.java Fri Jul 26 17:15:17 2019 +0000 >> +++ b/src/java.sql/share/classes/java/sql/PreparedStatement.java Fri Jul 26 14:13:09 2019 -0400 >> @@ -47,12 +47,13 @@ >> *

    >> * In the following example of setting a parameter, con represents >> * an active connection: >> - * 

    >> + * 
    {@code
>> + *   BigDecimal sal = new BigDecimal("153833.00");
>>   *   PreparedStatement pstmt = con.prepareStatement("UPDATE EMPLOYEES
>>   *                                     SET SALARY = ? WHERE ID = ?");
>> - *   pstmt.setBigDecimal(1, 153833.00)
>> - *   pstmt.setInt(2, 110592)
>> - * 
    
>> + *   pstmt.setBigDecimal(1, sal);
>> + *   pstmt.setInt(2, 110592);
>> + * }
    >> * >> * @see Connection#prepareStatement >> * @see ResultSet >> ljanders-mac:open ljanders$ >> ??????? >> >> Best, >> Lance >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> > From Alan.Bateman at oracle.com Fri Jul 26 18:36:31 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 26 Jul 2019 19:36:31 +0100 Subject: 8078891: java.io.SequenceInputStream.close is not atomic and not idempotent In-Reply-To: <232EA0BC-AA13-4157-95AA-2D92B5D5B2ED@oracle.com> References: <6824EDFA-BF3F-40A5-A872-527631868BD4@oracle.com> <4E569709-129A-4163-B19B-588680CD219C@oracle.com> <7A501E65-3AAA-4AE1-B7CE-AC1DA7E0AC98@oracle.com> <232EA0BC-AA13-4157-95AA-2D92B5D5B2ED@oracle.com> Message-ID: On 26/07/2019 16:41, Brian Burkhalter wrote: > : > Please see the updated patch which switches the implementation to the amended version and incorporates the proposed change to the test: > > http://cr.openjdk.java.net/~bpb/8078891/webrev.01/ The bug summary might be a big misleading as SequenceInputStream isn't thread safe and close isn't atomic. The changes are really to attempt to close all the remaining streams rather than bailing out when closing one of them fails. In any case, the change looks okay but it might be simpler to restructure to use: while (in != null) { ??? try { in.close() } catch (IOException e) { ... } ? ? peekNextStream(); } to simplify the error handling and avoid mixing nextStream and peekNextStream. There is also some curious code in peekNextStream where it handles nextElement returning null - I don't know the history on that but it looks like it's trying to handling a broken Enumeration. -Alan From brian.burkhalter at oracle.com Fri Jul 26 19:01:01 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 26 Jul 2019 12:01:01 -0700 Subject: 8078891: java.io.SequenceInputStream.close is not atomic and not idempotent In-Reply-To: References: <6824EDFA-BF3F-40A5-A872-527631868BD4@oracle.com> <4E569709-129A-4163-B19B-588680CD219C@oracle.com> <7A501E65-3AAA-4AE1-B7CE-AC1DA7E0AC98@oracle.com> <232EA0BC-AA13-4157-95AA-2D92B5D5B2ED@oracle.com> Message-ID: <38899479-59E4-493C-90BC-0B76C04AC2AE@oracle.com> > On Jul 26, 2019, at 11:36 AM, Alan Bateman wrote: > > On 26/07/2019 16:41, Brian Burkhalter wrote: >> : >> Please see the updated patch which switches the implementation to the amended version and incorporates the proposed change to the test: >> >> http://cr.openjdk.java.net/~bpb/8078891/webrev.01/ > The bug summary might be a big misleading as SequenceInputStream isn't thread safe and close isn't atomic. The changes are really to attempt to close all the remaining streams rather than bailing out when closing one of them fails. > > In any case, the change looks okay but it might be simpler to restructure to use: > > while (in != null) { > try { in.close() } catch (IOException e) { ... } > peekNextStream(); > } > > to simplify the error handling and avoid mixing nextStream and peekNextStream. So updated: http://cr.openjdk.java.net/~bpb/8078891/webrev.02/ > There is also some curious code in peekNextStream where it handles nextElement returning null - I don't know the history on that but it looks like it's trying to handling a broken Enumeration. Strange but not changed. Thanks, Brian From pavel.rappo at oracle.com Fri Jul 26 19:14:09 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 26 Jul 2019 20:14:09 +0100 Subject: 8078891: java.io.SequenceInputStream.close is not atomic and not idempotent In-Reply-To: References: <6824EDFA-BF3F-40A5-A872-527631868BD4@oracle.com> <4E569709-129A-4163-B19B-588680CD219C@oracle.com> <7A501E65-3AAA-4AE1-B7CE-AC1DA7E0AC98@oracle.com> <232EA0BC-AA13-4157-95AA-2D92B5D5B2ED@oracle.com> Message-ID: <8375B2C2-6707-4C24-95B7-9FE1E7A05DF2@oracle.com> > On 26 Jul 2019, at 19:36, Alan Bateman wrote: > > The bug summary might be a big misleading as SequenceInputStream isn't thread safe and close isn't atomic. The changes are really to attempt to close all the remaining streams rather than bailing out when closing one of them fails. I'm not a native English speaker and I used this word as a synonym to "indivisible". In this particular case "all or nothing". Am I using it wrong? Or are you saying that the word "atomic" is owned exclusively by the concurrency domain? What word (or phrase) would you use in this case? The aim of the subject line is to convey the crux of the issue succinctly. I hope no one goes and fixes the issue after reading just the subject line without looking any further into "details" and "description". > In any case, the change looks okay but it might be simpler to restructure to use: > > while (in != null) { > try { in.close() } catch (IOException e) { ... } > peekNextStream(); > } > > to simplify the error handling and avoid mixing nextStream and peekNextStream. Possibly. > There is also some curious code in peekNextStream where it handles nextElement returning null - I don't know the history on that but it looks like it's trying to handling a broken Enumeration. I wouldn't touch that code. In the case of `peekNextStream` we could only remove the needless cast (generics) without compromising compatibility. From pavel.rappo at oracle.com Fri Jul 26 19:37:11 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 26 Jul 2019 20:37:11 +0100 Subject: 8078891: java.io.SequenceInputStream.close is not atomic and not idempotent In-Reply-To: References: <6824EDFA-BF3F-40A5-A872-527631868BD4@oracle.com> <4E569709-129A-4163-B19B-588680CD219C@oracle.com> <7A501E65-3AAA-4AE1-B7CE-AC1DA7E0AC98@oracle.com> <232EA0BC-AA13-4157-95AA-2D92B5D5B2ED@oracle.com> Message-ID: <06DE38EF-07AC-475D-875E-C216F0E8B825@oracle.com> > On 26 Jul 2019, at 19:36, Alan Bateman wrote: > > > > In any case, the change looks okay but it might be simpler to restructure to use: > > while (in != null) { > try { in.close() } catch (IOException e) { ... } > peekNextStream(); > } > > to simplify the error handling and avoid mixing nextStream and peekNextStream. There is also some curious code in peekNextStream where it handles nextElement returning null - I don't know the history on that but it looks like it's trying to handling a broken Enumeration. For the record. If we change this as you suggested, the code will behave differently in the case of a single `null` element found in the midst of iteration (broken enumeration?). The stream won't be able to close after running into it. But this most likely is a programming error anyway. Not sure. From mandy.chung at oracle.com Fri Jul 26 21:12:42 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 26 Jul 2019 14:12:42 -0700 Subject: Review Request: JDK-8228671: Fastdebug VM throws InternalError when publicLookup.in(T) is used to resolve a member Message-ID: Debug VM checks if a class is accessible to the lookup class except if the lookup class is java.lang.Object (which was the lookup class of publicLookup previously). WithJDK-8173978, Lookup::in has changed and it can be used to create a new public Lookup on a different lookup class. A quick fix for this bug is to pass Object.class for resolution for a Lookup object with UNCONDITIONAL mode as previously.? The lookup class and allowed modes are used to check if the resolved member is accessible to this Lookup object.? We should re-examine this area in particular publicLookup (see JDK-8173977). diff --git a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java --- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java @@ -1329,7 +1329,14 @@ ???????? // This is just for calling out to MethodHandleImpl. ???????? private Class lookupClassOrNull() { -??????????? return (allowedModes == TRUSTED) ? null : lookupClass; +??????????? if (allowedModes == TRUSTED) { +??????????????? return null; +??????????? } +??????????? if (allowedModes == UNCONDITIONAL) { +??????????????? // use Object as the caller to pass to VM doing resolution +??????????????? return Object.class; +??????????? } +??????????? return lookupClass; ???????? } ???????? /** Tells which access-protection classes of members this lookup object can produce. Mandy From mark.reinhold at oracle.com Fri Jul 26 22:58:57 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 26 Jul 2019 15:58:57 -0700 (PDT) Subject: New candidate JEP: 358: Helpful NullPointerExceptions Message-ID: <20190726225857.1D16E2B8265@eggemoggin.niobe.net> https://openjdk.java.net/jeps/358 - Mark From Alan.Bateman at oracle.com Sat Jul 27 06:51:54 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 27 Jul 2019 07:51:54 +0100 Subject: Review Request: JDK-8228671: Fastdebug VM throws InternalError when publicLookup.in(T) is used to resolve a member In-Reply-To: References: Message-ID: <5237a938-2a60-0836-0f3d-3792807d1929@oracle.com> On 26/07/2019 22:12, Mandy Chung wrote: > Debug VM checks if a class is accessible to the lookup class except if > the lookup class is java.lang.Object (which was the lookup class of > publicLookup previously). WithJDK-8173978, Lookup::in has changed and > it can be used to create a new public Lookup on a different lookup class. > > A quick fix for this bug is to pass Object.class for resolution for a > Lookup object with UNCONDITIONAL mode as previously.? The lookup class > and allowed modes are used to check if the resolved member is > accessible to this Lookup object.? We should re-examine this area in > particular publicLookup (see JDK-8173977). Looks okay as a quick fix, surprised it is only caught with tier5 or 6 testing. I assume JDK-8173977 will need a priority boost. -Alan From Alan.Bateman at oracle.com Sat Jul 27 07:28:06 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 27 Jul 2019 08:28:06 +0100 Subject: 8078891: java.io.SequenceInputStream.close is not atomic and not idempotent In-Reply-To: <06DE38EF-07AC-475D-875E-C216F0E8B825@oracle.com> References: <6824EDFA-BF3F-40A5-A872-527631868BD4@oracle.com> <4E569709-129A-4163-B19B-588680CD219C@oracle.com> <7A501E65-3AAA-4AE1-B7CE-AC1DA7E0AC98@oracle.com> <232EA0BC-AA13-4157-95AA-2D92B5D5B2ED@oracle.com> <06DE38EF-07AC-475D-875E-C216F0E8B825@oracle.com> Message-ID: On 26/07/2019 20:37, Pavel Rappo wrote: > For the record. If we change this as you suggested, the code will behave > differently in the case of a single `null` element found in the midst of > iteration (broken enumeration?). The stream won't be able to close after > running into it. But this most likely is a programming error anyway. The changes in webrev.01 probably have the same issue because nextStream will throw NPE when nextElement returns null and this will terminate the close without closing the streams that follow the null. Yeah, it's a usage/programming error. peekNextStream could include an exception message to help with such cases but it hardly seems worth trying to do more. -Alan From Alan.Bateman at oracle.com Sat Jul 27 07:30:10 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 27 Jul 2019 08:30:10 +0100 Subject: 8078891: java.io.SequenceInputStream.close is not atomic and not idempotent In-Reply-To: <38899479-59E4-493C-90BC-0B76C04AC2AE@oracle.com> References: <6824EDFA-BF3F-40A5-A872-527631868BD4@oracle.com> <4E569709-129A-4163-B19B-588680CD219C@oracle.com> <7A501E65-3AAA-4AE1-B7CE-AC1DA7E0AC98@oracle.com> <232EA0BC-AA13-4157-95AA-2D92B5D5B2ED@oracle.com> <38899479-59E4-493C-90BC-0B76C04AC2AE@oracle.com> Message-ID: <9e76edcf-d1d4-f253-3cf3-5675a712fc25@oracle.com> On 26/07/2019 20:01, Brian Burkhalter wrote: > > So updated: http://cr.openjdk.java.net/~bpb/8078891/webrev.02/ > This version is a lot cleaner and looks okay to me. -Alan From openjdk at icemanx.nl Sat Jul 27 10:44:23 2019 From: openjdk at icemanx.nl (Rob Spoor) Date: Sat, 27 Jul 2019 12:44:23 +0200 Subject: Bad performance in Writer.append(CharSequence) Message-ID: Hi, I noticed the performance of Writer.append(CharSequence) (and its indexed version) can be quite bad (especially with large CharSequences), because they create a new String each time. I think that could be prevented. Consider appending a StringBuilder or StringBuffer. Writer.append(CharSequence, int, int) calls csq.subSequence(start, end). That creates a new String, which copies part of the backing array. Writer.append(CharSequence) on the other hand calls String.valueOf(csq), which also creates a nwe String, which copies the entire backing array. The String is then passed to Writer.write(String), which delegates to Writer.write(String, int, int), which calls String.getChars. However, StringBuilder and StringBuffer each have their own getChars method. It would be more efficient to skip the intermediate String, and directly call the StringBuilder / StringBuffer getChars method. This leaves us with a few possibilities: 1) Have special cases in the Writer.append methods that check for StringBuilder / StringBuffer; checking for AbstractStringBuilder isn't possible because that's package private. 2) Add getChars as a default method to CharSequence. It would perform the index checks and use length() and charAt(int) in the default implementation; String, StringBuilder and StringBuffer automatically provide better implementations. In the second case, Writer.append(CharSequence, int, int) would then look like Writer.write(String, int, int). Writer.append(CharSequence) could simply do the following: public Writer append(CharSequence csq) throws IOException { if (csq == null) csq = "null"; return append(csq, 0, csq.length); } Any thoughts? Kind regards, Rob From mandy.chung at oracle.com Sat Jul 27 21:33:54 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 27 Jul 2019 14:33:54 -0700 Subject: Review Request: JDK-8228671: Fastdebug VM throws InternalError when publicLookup.in(T) is used to resolve a member In-Reply-To: <5237a938-2a60-0836-0f3d-3792807d1929@oracle.com> References: <5237a938-2a60-0836-0f3d-3792807d1929@oracle.com> Message-ID: <78f03724-1650-c57a-189e-ff1cecd317ea@oracle.com> On 7/26/19 11:51 PM, Alan Bateman wrote: > On 26/07/2019 22:12, Mandy Chung wrote: >> Debug VM checks if a class is accessible to the lookup class except >> if the lookup class is java.lang.Object (which was the lookup class >> of publicLookup previously). WithJDK-8173978, Lookup::in has changed >> and it can be used to create a new public Lookup on a different >> lookup class. >> >> A quick fix for this bug is to pass Object.class for resolution for a >> Lookup object with UNCONDITIONAL mode as previously.? The lookup >> class and allowed modes are used to check if the resolved member is >> accessible to this Lookup object.? We should re-examine this area in >> particular publicLookup (see JDK-8173977). > Looks okay as a quick fix, surprised it is only caught with tier5 or 6 > testing. It was a surprise that this was not caught in our tier1-3 testing. We shall revisit and expand tier1-3 to execute certain tests such as jdk_lang group in fastdebug mode. > I assume JDK-8173977 will need a priority boost. It may be time to revisit this together with loader constraints (although they are orthogonal). Mandy From scolebourne at joda.org Mon Jul 29 14:40:45 2019 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 29 Jul 2019 15:40:45 +0100 Subject: [14] RFR: 8212970: TZ database in "vanguard" format support In-Reply-To: References: Message-ID: Thanks for these changes, +1 Stephen On Tue, 23 Jul 2019 at 23:18, wrote: > > Hi, > > Please review the fix to the following enhancement: > > https://bugs.openjdk.java.net/browse/JDK-8212970 > > The proposed changeset is located at: > > https://cr.openjdk.java.net/~naoto/8212970/webrev.09/ > > This change aims to support the "vanguard" IANA time zone data format, > which uses the negative savings and transition time beyond a day period. > The change basically translates those negative savings and transition > times, such as 25:00, into the ones that the current JDK recognizes, > then produces the data file "tzdb.dat" at the build time. At the run > time, the data file is read and interpreted as before. This way the > produced tzdb.dat is compatible with the prior JDK releases so that the > TZ Updater can also distribute it as a time zone update. > > I have also refactored redundant copy of ZoneRules file in the build > directory, by dynamically importing the file under src. Thus some build > related files are modified. I am hoping folks on the build-dev can > review those changes. > > Naoto From dmitry.chuyko at bell-sw.com Mon Jul 29 14:43:58 2019 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Mon, 29 Jul 2019 17:43:58 +0300 Subject: RFR (XXS): 8228722: jpackage RPM tests fail on some versions of rpmbuild Message-ID: Hello, Please review a tiny fix of a test bug that appears in some environments. While extending jpackage platforms support in JDK-8222778 I used "-E" rpmbuild shortcut for arch detection. It seems to be missing in some versions while full "--eval" flag name is more generic. bug: https://bugs.openjdk.java.net/browse/JDK-8228722 webrev: http://cr.openjdk.java.net/~dchuyko/8228722/webrev.00/ testing: jpackage jtreg tests on x86_64, aarch64 and other archs, Ubuntu 16.04. Webrev is made for 'JDK-8200758-branch' branch of open 'sandbox' repo. -Dmitry From andy.herrick at oracle.com Mon Jul 29 14:57:33 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 29 Jul 2019 10:57:33 -0400 Subject: RFR (XXS): 8228722: jpackage RPM tests fail on some versions of rpmbuild In-Reply-To: References: Message-ID: <7efd758c-4bb4-ef48-c994-6af1e9de9c02@oracle.com> looks good. /Andy On 7/29/2019 10:43 AM, Dmitry Chuyko wrote: > Hello, > > Please review a tiny fix of a test bug that appears in some > environments. While extending jpackage platforms support in > JDK-8222778 I used "-E" rpmbuild shortcut for arch detection. It seems > to be missing in some versions while full "--eval" flag name is more > generic. > > bug: https://bugs.openjdk.java.net/browse/JDK-8228722 > > webrev: http://cr.openjdk.java.net/~dchuyko/8228722/webrev.00/ > > testing: jpackage jtreg tests on x86_64, aarch64 and other archs, > Ubuntu 16.04. > > Webrev is made for 'JDK-8200758-branch' branch of open 'sandbox' repo. > > -Dmitry > From roger.riggs at oracle.com Mon Jul 29 15:02:01 2019 From: roger.riggs at oracle.com (Roger Riggs) Date: Mon, 29 Jul 2019 11:02:01 -0400 Subject: [14] RFR: 8212970: TZ database in "vanguard" format support In-Reply-To: <40d84ae9-5648-0b32-3daf-55a28022a489@oracle.com> References: <82dadb56-b776-9741-fe5c-823c4f0948fa@oracle.com> <40d84ae9-5648-0b32-3daf-55a28022a489@oracle.com> Message-ID: <0f9bb60b-9356-52e3-a102-0d20fa422c8e@oracle.com> Hi Naoto, Thanks for the explanation. Looks good. Roger On 7/25/19 4:04 PM, naoto.sato at oracle.com wrote: > Hi Roger, > > On 7/25/19 7:47 AM, Roger Riggs wrote: >> Hi Naoto, >> >> TestZoneInfo310.java: >> With the composition of the tzdir path up and over to the make >> directory for the tzdir >> it might be useful to do an explicit check that the directory exists. >> That way if the directory structure on the build side changes, >> there will be a test failure makine it obvious that the dependency >> has changed. > > If the input tz data files, either in "test" tree or "make" tree, > cannot be located, the test will fail which effectively reports if > there is a repo structure change. So I believe it is ok as it is. > > Aside from it, the latest changes to eliminate the duplicates caused > that regression test fail. The reason was that there were actually two > "jdk11_backward" data files each in "tzdata" and "tzdata_jdk" test > directories, and the contents differ! I am not sure the reason why > there are two files this way (seems to be so for years), so I reverted > that exact file as before. Here is the webrev reflected that: > > http://cr.openjdk.java.net/~naoto/8212970/webrev.12/ > > Naoto > >> >> Looks fine. >> >> Thanks, Roger >> >> >> >> On 7/24/19 6:24 PM, naoto.sato at oracle.com wrote: >>> Hi Joe, >>> >>> Thank you for the review. >>> >>> On 7/24/19 2:57 PM, Joe Wang wrote: >>>> Hi Naoto, >>>> >>>> The method findNegativeSavings method in TzdbZoneRulesProvider.java >>>> states that it "Find the minimum negative savings". While the >>>> result is correct since the rules all have the same value for SAVE, >>>> I wonder if that's ideal conceptually. Given a start LDT, shouldn't >>>> it be looking for the SAVE in the exact (narrower) date range (e.g. >>>> 1981 - 1989 vs 1981 - max)?. >>> >>> I believe it is working as such. The end year is retrieved within >>> the method (line 879) and only the minimum negative saving values >>> within the window is filtered. >>> >>>> >>>> NegativeDSTTest verifies the tzdata, that is the adjusted data >>>> after import, is that correct? I wonder a comment and a bit of >>>> details in the test summary would be helpful since there is no >>>> negative data in the test itself. >>> >>> Good point. It is confusing. I supplied summary text in the test >>> (also the similar line in TestZoneRules.java) >>> >>> Here is the updated webrev: >>> >>> http://cr.openjdk.java.net/~naoto/8212970/webrev.11/ >>> >>> Naoto >>>> >>>> Best, >>>> Joe >>>> >>>> On 7/23/19 3:15 PM, naoto.sato at oracle.com wrote: >>>>> Hi, >>>>> >>>>> Please review the fix to the following enhancement: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8212970 >>>>> >>>>> The proposed changeset is located at: >>>>> >>>>> https://cr.openjdk.java.net/~naoto/8212970/webrev.09/ >>>>> >>>>> This change aims to support the "vanguard" IANA time zone data >>>>> format, which uses the negative savings and transition time beyond >>>>> a day period. The change basically translates those negative >>>>> savings and transition times, such as 25:00, into the ones that >>>>> the current JDK recognizes, then produces the data file "tzdb.dat" >>>>> at the build time. At the run time, the data file is read and >>>>> interpreted as before. This way the produced tzdb.dat is >>>>> compatible with the prior JDK releases so that the TZ Updater can >>>>> also distribute it as a time zone update. >>>>> >>>>> I have also refactored redundant copy of ZoneRules file in the >>>>> build directory, by dynamically importing the file under src. Thus >>>>> some build related files are modified. I am hoping folks on the >>>>> build-dev can review those changes. >>>>> >>>>> Naoto >>>> >> From nicolas.roduit at gmail.com Sat Jul 27 06:30:12 2019 From: nicolas.roduit at gmail.com (Nicolas Roduit) Date: Sat, 27 Jul 2019 08:30:12 +0200 Subject: jpackage: packaging a real application Message-ID: Hi all, I'm trying to use jpackage to replace deployment by Java Web Start. I have set up a continuous build to allow the construction of a package on Windows, Mac and Linux. The latest changes to the directory change of the launch binaries and the change in the value of the current working directory required a series of modification in my build. However, there is a bug on Linux for the installation of the file association, see the proposed patch in attachment. There is another problem that seems to me to be major. It is to no longer possible to overload the construction of the MSI. I modified the code to be able to add my own main.wxs file. I think that being able to fully overload main.wxs is essential even if many users will just use the default template. Best, Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: linux-jpackage.patch Type: text/x-patch Size: 2646 bytes Desc: not available URL: From amaembo at gmail.com Mon Jul 29 16:11:38 2019 From: amaembo at gmail.com (Tagir Valeev) Date: Mon, 29 Jul 2019 23:11:38 +0700 Subject: [Ping] RFR: 8176894 Provide specialized implementation for default methods putIfAbsent, computeIfAbsent, computeIfPresent, compute, merge in TreeMap In-Reply-To: References: Message-ID: Hello everybody! A gentle reminder: please review the changeset and the CSR. Thanks! With best regards, Tagir Valeev On Mon, Jul 15, 2019 at 5:58 PM Tagir Valeev wrote: > Hello! > > 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 andy.herrick at oracle.com Mon Jul 29 17:58:24 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 29 Jul 2019 13:58:24 -0400 Subject: jpackage: packaging a real application In-Reply-To: References: Message-ID: <385039ea-5e96-7c7a-fe22-6c2f50579856@oracle.com> Thanks for the heads up on linux file associations.? I have filed JDK-8228744 and make sure it is fixed. As to the customization of the msi scripts, it is generally the intention of the implementation that all resources would be fetched by calling fetchResource() in AbstractBundler.java.? I can see from the current implementation that only the post install script (for which there is no default resource) is fetched in this way (all others, including main.wxs, just calling getResourceAsStream() which will only get the default resources). If the code were to call fetchResource()? (as intended) instead of getResourceAsStream(), you would have the capability to use option "--resource-dir " with pointing to a directory containing any resource you want to override. I will investigate this further and get back to you. /Andy On 7/27/2019 2:30 AM, Nicolas Roduit wrote: > Hi all, > > I'm trying to use jpackage to replace deployment by Java Web Start. I > have set up a continuous build to allow the construction of a package > on Windows, Mac and Linux. > > The latest changes to the directory change of the launch binaries and > the change in the value of the current working directory required a > series of modification in my build. However, there is a bug on Linux > for the installation of the file association, see the proposed patch > in attachment. > > There is another problem that seems to me to be major. It is to no > longer possible to overload the construction of the MSI. I modified > the code to be able to add my own main.wxs file. I think that being > able to fully overload main.wxs is essential even if many users will > just use the default template. > > Best, > > Nicolas > From andy.herrick at oracle.com Mon Jul 29 19:19:48 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 29 Jul 2019 15:19:48 -0400 Subject: RFR: JDK-8228744: file associations broken on linux. Message-ID: <8fdcd0fb-e921-1507-4802-5749b252b768@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). [1] https://bugs.openjdk.java.net/browse/JDK-8228744 [2] http://cr.openjdk.java.net/~herrick/8228744/ /Andy From kevin.rushforth at oracle.com Mon Jul 29 19:44:25 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 29 Jul 2019 12:44:25 -0700 Subject: RFR: JDK-8228744: file associations broken on linux. In-Reply-To: <8fdcd0fb-e921-1507-4802-5749b252b768@oracle.com> References: <8fdcd0fb-e921-1507-4802-5749b252b768@oracle.com> Message-ID: Looks good. -- Kevin On 7/29/2019 12:19 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). > > [1] https://bugs.openjdk.java.net/browse/JDK-8228744 > > [2] http://cr.openjdk.java.net/~herrick/8228744/ > > /Andy > > From alexey.semenyuk at oracle.com Tue Jul 30 08:12:14 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Tue, 30 Jul 2019 04:12:14 -0400 Subject: RFR: JDK-8228744: file associations broken on linux. In-Reply-To: <8fdcd0fb-e921-1507-4802-5749b252b768@oracle.com> References: <8fdcd0fb-e921-1507-4802-5749b252b768@oracle.com> Message-ID: <1de40704-5eb8-c332-12a4-50257457205c@oracle.com> Looks good. - Alexey On 7/29/2019 3:19 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). > > [1] https://bugs.openjdk.java.net/browse/JDK-8228744 > > [2] http://cr.openjdk.java.net/~herrick/8228744/ > > /Andy > > From chengjingwei1 at huawei.com Tue Jul 30 08:21:09 2019 From: chengjingwei1 at huawei.com (chengjingwei (A)) Date: Tue, 30 Jul 2019 08:21:09 +0000 Subject: Issue with SSL handshake implementation Message-ID: Hi, There may be some issue with the SSL handshake implementation. In sun.security.x509.X500Name.java, there's a static hashmap field named *internedOIDs*, used for caching X.500 attributes. Each time a new oid is encountered, jdk will cache them into the static hashmap. With a purposely crafted cert on the client side, it's possible to create some long oids, and letting the server save them permanently during SSL handshake, which will eat server memory, and cause OOM & DoS in the end. Is it necessary to make some changes to this? BTW, The issue was reported by one of our customers, with the following stacktrace. Although they got this on jdk8u212, I believe the same issue exists in jdk11 too. ``` http-bio-172.24.18.21-443-exec-4 at java.lang.OutOfMemoryError.()V (OutOfMemoryError.java:48) at java.util.Arrays.copyOf([Ljava/lang/Object;I)[Ljava/lang/Object; (Arrays.java:3181) at java.util.Vector.grow(I)V (Vector.java:269) at java.util.Vector.ensureCapacityHelper(I)V (Vector.java:249) at java.util.Vector.addElement(Ljava/lang/Object;)V (Vector.java:623) at sun.security.util.DerInputStream.readVector(I)[Lsun/security/util/DerValue; (DerInputStream.java:425) at sun.security.util.DerInputStream.getSequence(I)[Lsun/security/util/DerValue; (DerInputStream.java:331) at sun.security.x509.X500Name.parseDER(Lsun/security/util/DerInputStream;)V (X500Name.java:793) at sun.security.x509.X500Name.(Lsun/security/util/DerInputStream;)V (X500Name.java:306) at sun.security.x509.X509CertInfo.parse(Lsun/security/util/DerValue;)V (X509CertInfo.java:649) at sun.security.x509.X509CertInfo.(Lsun/security/util/DerValue;)V (X509CertInfo.java:167) at sun.security.x509.X509CertImpl.parse(Lsun/security/util/DerValue;)V (X509CertImpl.java:1804) at sun.security.x509.X509CertImpl.([B)V (X509CertImpl.java:195) at sun.security.provider.X509Factory.engineGenerateCertificate(Ljava/io/InputStream;)Ljava/security/cert/Certificate; (X509Factory.java:102) at java.security.cert.CertificateFactory.generateCertificate(Ljava/io/InputStream;)Ljava/security/cert/Certificate; (CertificateFactory.java:339) at sun.security.ssl.HandshakeMessage$CertificateMsg.(Lsun/security/ssl/HandshakeInStream;)V (HandshakeMessage.java:455) at sun.security.ssl.ServerHandshaker.processMessage(BI)V (ServerHandshaker.java:230) at sun.security.ssl.Handshaker.processLoop()V (Handshaker.java:1037) at sun.security.ssl.Handshaker.process_record(Lsun/security/ssl/InputRecord;Z)V (Handshaker.java:965) at sun.security.ssl.SSLSocketImpl.readRecord(Lsun/security/ssl/InputRecord;Z)V (SSLSocketImpl.java:1064) at sun.security.ssl.SSLSocketImpl.performInitialHandshake()V (SSLSocketImpl.java:1367) at sun.security.ssl.SSLSocketImpl.startHandshake(Z)V (SSLSocketImpl.java:1395) at sun.security.ssl.SSLSocketImpl.getSession()Ljavax/net/ssl/SSLSession; (SSLSocketImpl.java:2288) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.handshake(Ljava/net/Socket;)V (JSSESocketFactory.java:293) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run()V (JIoEndpoint.java:343) at java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V (ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run()V (ThreadPoolExecutor.java:624) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run()V (TaskThread.java:61) at java.lang.Thread.run()V (Thread.java:748) ``` From daniel.fuchs at oracle.com Tue Jul 30 10:22:10 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 30 Jul 2019 11:22:10 +0100 Subject: Review Request: JDK-8209005: Lookup.unreflectSpecial fails for default methods when Lookup.findSpecial works In-Reply-To: <6c13f13b-e08f-af91-f583-8acf48ee7182@oracle.com> References: <8a3743fc-5ac3-0f79-2ee5-9814de6444e7@oracle.com> <6c13f13b-e08f-af91-f583-8acf48ee7182@oracle.com> Message-ID: Hi Mandy, 380 * {@link java.lang.invoke.MethodHandles.Lookup#unreflectSpecial lookup.unreflectSpecial(aMethod,this.class)} 381 * {@code T m(A*);}{@code (T) aMethod.invoke(this, arg*);} Is this exactly true? I mean - if `this` is an instance of a subclass of `aMethod.getDeclaringClass()`, and if that subclass overrides `aMethod`, then I would expect `aMethod.invoke(this, arg*)` to execute the bytecode of the method defined in the subclass. If I'm not mistaken, the test does expect that the bytecode in the super class is executed instead. I suspect that `unreflectSpecial` can only be specified in terms of `findSpecial`. But maybe I'm missing something. I'm not too familiar with the intricacies of MethodHandle. best regards, -- daniel On 26/07/2019 18:41, Mandy Chung wrote: > Daniel noticed that `unreflectSpecial` is missing in the "Lookup Factory > Methods" section in the class spec.? In fact there are a duplicated > `lookup.unreflect(aMethod)` row that might originally be for > `unreflectSpecial`.?? I fix the javadoc in this patch: > > http://cr.openjdk.java.net/~mchung/jdk14/8209005/webrev.01/ > > Mandy > > On 7/25/19 1:12 PM, Mandy Chung wrote: >> This patch fixes Lookup.unreflectSpecial to pass the declaring class >> of Method being unreflected (rather than null) so that it can >> accurately check if the special caller class is either the lookup >> class or a superinterface of the declaring class. >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk14/8209005/webrev.00/index.html >> >> The test runs in both unnamed module and named module to cover >> JDK-8209078 which has been resolved by JDK-8173978. >> >> thanks >> Mandy > From thejasvi.v.voniadka at oracle.com Tue Jul 30 12:54:27 2019 From: thejasvi.v.voniadka at oracle.com (Thejasvi Voniadka) Date: Tue, 30 Jul 2019 05:54:27 -0700 (PDT) Subject: RFR: 8160225: java.time.format.DateTimeFormatter issues for month-of-year Message-ID: Hi, Request your review of this simple change. JBS: https://bugs.openjdk.java.net/browse/JDK-8160225 (java.time.format.DateTimeFormatter issues for month-of-year) Description: It is a simple documentation change. The DateTimeFormatter expects the month format to be represented by "L" for number and "M" for text (eg: "Jul" may be accepted by a format string "MMM"; "07" may be accepted by a format string "LL", and so on). However, the documentation lists this somewhat confusingly: "M/L month-of-year number/text 7; 07; Jul; July; J" A casual reader may interpret "M" as the numeric representation and "L" as the textual representation of the month-of-year, whereas the actual behavior of the API is the other way around. This patch fixes it. Webrev: http://cr.openjdk.java.net/~vagarwal/8160225/webrev.0/ From li.jiang at oracle.com Tue Jul 30 13:55:06 2019 From: li.jiang at oracle.com (li.jiang at oracle.com) Date: Tue, 30 Jul 2019 21:55:06 +0800 Subject: RFR: 8228778: JDK 13 L10n resource files update - msg drop 20 Message-ID: <9751e202-3677-ef1a-8d47-4382a27fba75@oracle.com> Hi, Please help to review the update of L10n resource files in JDK13 msg drop 20. Bug: https://bugs.openjdk.java.net/browse/JDK-8228778 Webrev: http://cr.openjdk.java.net/~ljiang/8228778/webrev/read/ Thanks, Leo From mandy.chung at oracle.com Tue Jul 30 14:47:41 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 30 Jul 2019 07:47:41 -0700 Subject: Review Request: JDK-8209005: Lookup.unreflectSpecial fails for default methods when Lookup.findSpecial works In-Reply-To: References: <8a3743fc-5ac3-0f79-2ee5-9814de6444e7@oracle.com> <6c13f13b-e08f-af91-f583-8acf48ee7182@oracle.com> Message-ID: <4b7cae81-2066-1b66-9f44-085b29bd5215@oracle.com> Think about aMethod is a protected method inherited from its superclass T.? To invoke aMethod, the receiver must be an instance of T or a subclass of T. Mandy On 7/30/19 3:22 AM, Daniel Fuchs wrote: > Hi Mandy, > > ?380????? *???? {@link > java.lang.invoke.MethodHandles.Lookup#unreflectSpecial > lookup.unreflectSpecial(aMethod,this.class)} > ?381????? *???? {@code T m(A*);}{@code (T) > aMethod.invoke(this, arg*);} > > Is this exactly true? I mean - if `this` is an instance of > a subclass of `aMethod.getDeclaringClass()`, and if that > subclass overrides `aMethod`, then I would expect > `aMethod.invoke(this, arg*)` to execute the bytecode > of the method defined in the subclass. > > If I'm not mistaken, the test does expect that the > bytecode in the super class is executed instead. > I suspect that `unreflectSpecial` can only be specified > in terms of `findSpecial`. But maybe I'm missing something. > I'm not too familiar with the intricacies of MethodHandle. > > best regards, > > -- daniel > > On 26/07/2019 18:41, Mandy Chung wrote: >> Daniel noticed that `unreflectSpecial` is missing in the "Lookup >> Factory Methods" section in the class spec.? In fact there are a >> duplicated `lookup.unreflect(aMethod)` row that might originally be >> for `unreflectSpecial`.?? I fix the javadoc in this patch: >> >> http://cr.openjdk.java.net/~mchung/jdk14/8209005/webrev.01/ >> >> Mandy >> >> On 7/25/19 1:12 PM, Mandy Chung wrote: >>> This patch fixes Lookup.unreflectSpecial to pass the declaring class >>> of Method being unreflected (rather than null) so that it can >>> accurately check if the special caller class is either the lookup >>> class or a superinterface of the declaring class. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mchung/jdk14/8209005/webrev.00/index.html >>> >>> The test runs in both unnamed module and named module to cover >>> JDK-8209078 which has been resolved by JDK-8173978. >>> >>> thanks >>> Mandy >> > From adinn at redhat.com Tue Jul 30 15:04:58 2019 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 30 Jul 2019 16:04:58 +0100 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <8f72d3b5-3a01-a7de-3b09-35571266a87d@redhat.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com> <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> <892f3b0b-55f1-872d-15f4-5af907fa8437@redhat.com> <8f72d3b5-3a01-a7de-3b09-35571266a87d@redhat.com> Message-ID: JEP 352 has now been targeted for inclusion in JDK14. The latest webrev for the implementation JIRA has been rebased to apply to the current tree. Is it now ok to push this change set? JIRA: https://bugs.openjdk.java.net/browse/JDK-8224974 webrev: http://cr.openjdk.java.net/~adinn/8224974/webrev.09 n.b. by way of sanity test I pushed this to the submit repo and it came back with no failed tests. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From naoto.sato at oracle.com Tue Jul 30 15:08:39 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 30 Jul 2019 08:08:39 -0700 Subject: RFR: 8228778: JDK 13 L10n resource files update - msg drop 20 In-Reply-To: <9751e202-3677-ef1a-8d47-4382a27fba75@oracle.com> References: <9751e202-3677-ef1a-8d47-4382a27fba75@oracle.com> Message-ID: Looks good to me. Naoto On 7/30/19 6:55 AM, li.jiang at oracle.com wrote: > Hi, > > Please help to review the update of L10n resource files in JDK13 msg > drop 20. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8228778 > Webrev: http://cr.openjdk.java.net/~ljiang/8228778/webrev/read/ > > Thanks, > Leo From shade at redhat.com Tue Jul 30 16:00:08 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 30 Jul 2019 18:00:08 +0200 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com> <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> <892f3b0b-55f1-872d-15f4-5af907fa8437@redhat.com> <8f72d3b5-3a01-a7de-3b09-35571266a87d@redhat.com> Message-ID: <671c7ba1-9597-a990-190b-145d9cb5349e@redhat.com> On 7/30/19 5:04 PM, Andrew Dinn wrote: > JEP 352 has now been targeted for inclusion in JDK14. The latest webrev > for the implementation JIRA has been rebased to apply to the current > tree. Is it now ok to push this change set? > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8224974 > webrev: http://cr.openjdk.java.net/~adinn/8224974/webrev.09 Is it okay to have a late code review? Here it goes: === General: So if pre wbsync is no-op, why do we need to handle it everywhere? We seem to be falling through all the way to the stub to do nothing there, maybe we should instead cut much earlier, e.g. when inlining Unsafe.writeBackPresync0? Would it be better to not emit CacheWBPreSync at all? === General: IIRC, notproduct and PRODUCT defines are legacy, and should be avoided? develop and ASSERT must be the substitutes for this. See some discussion here: https://bugs.openjdk.java.net/browse/JDK-8183287 === src/hotspot/cpu/aarch64/aarch64.ad src/hotspot/cpu/x86/x86.ad This should probably be just "!VM_Version...". Braces around the statement would not hurt either. 2196 if (VM_Version::supports_data_cache_line_flush() == false) 2197 ret_value = false; === src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp src/hotspot/cpu/x86/macroAssembler_x86.cpp Braces style mismatch, should be on the same line, as in the rest of the file: 5837 void MacroAssembler::cache_wb(Address line) 5838 { 5856 void MacroAssembler::cache_wbsync(bool is_pre) 5857 { === src/hotspot/cpu/x86/assembler_x86.cpp It feels like these comments are redundant, especially L8630 and L8646 which mention magic values "6" and "7", not present in the code: 8624 // instruction prefix is 0x66 8627 // opcode family is 0x0f 0xAE 8630 // extended opcode byte is 7 == rdi 8640 // instruction prefix is 0x66 8643 // opcode family is 0x0f 0xAE 8646 // extended opcode byte is 6 == rsi === src/hotspot/cpu/x86/macroAssembler_x86.cpp These comments feel redundant too. Well, maybe they should instead talk about the choices the subsequent code makes. 9915 // pick the correct implementation 9936 // pick the correct implementation === src/hotspot/cpu/x86/macroAssembler_x86.cpp src/hotspot/cpu/x86/vm_version_x86.hpp The docs say "The CLFLUSH instruction was introduced with the SSE2 extensions; however, because it has its own CPUID feature flag, it can be implemented in IA-32 processors that do not include the SSE2 extensions. Also, detecting the presence of the SSE2 extensions with the CPUID instruction does not guarantee that the CLFLUSH instruction is implemented in the processor." Yet, we have: 9910 // 64 bit cpus always support clflush 9911 assert(VM_Version::supports_clflush(), "should not reach here on 32-bit"); 505 #ifdef _LP64 506 // cpflush is always available on x86_64 507 result |= CPU_FLUSH; 508 #else 509 if (_cpuid_info.std_cpuid1_edx.bits.clflush != 0) 510 result |= CPU_FLUSH; 511 #endif 967 // 64 bit cpus always support clflush which writes back and evicts 968 // on 32 bit cpus support is recorded via a feature flag 980 static bool supports_clflush() { return true; } I think the assert should just say "clflush should be available", and clflush cpu flag detected for 64-bits too? === src/hotspot/cpu/x86/macroAssembler_x86.hpp Accidental camelCase, while hotspot code expects snake_case: 1794 void cache_wbsync(bool isPre); === src/hotspot/cpu/x86/stubGenerator_x86_64.cpp Any reason to avoid inline here, e.g. "__ cache_wb(Address(src, 0))"? 2921 const Address line(src, 0); 2922 __ cache_wb(line); === src/hotspot/cpu/x86/stubGenerator_x86_64.cpp Is it really "cmpl" here, not "cmpb"? I think aarch64 code tests for byte. 2942 __ cmpl(is_pre, 0); === src/hotspot/share/classfile/vmSymbols.hpp Excess space before "jdk_internal..." here: 1096 do_intrinsic(_writebackPostSync0, jdk_internal_misc_Unsafe, writebackPostSync0_name, void_method_signature , F_RN) \ === src/hotspot/share/opto/c2compiler.cpp Why inject new cases here, instead of at the end of switch? Saves sudden "break": 578 break; 579 case vmIntrinsics::_writeback0: 580 if (!Matcher::match_rule_supported(Op_CacheWB)) return false; 581 break; 582 case vmIntrinsics::_writebackPreSync0: 583 if (!Matcher::match_rule_supported(Op_CacheWBPreSync)) return false; 584 break; 585 case vmIntrinsics::_writebackPostSync0: 586 if (!Matcher::match_rule_supported(Op_CacheWBPostSync)) return false; 587 break; === src/hotspot/share/opto/library_call.cpp Accidental camelCase here, should be snake_case: 257 bool inline_unsafe_writebackSync0(bool isPre); 2870 bool LibraryCallKit::inline_unsafe_writebackSync0(bool isPre) { === src/hotspot/share/prims/unsafe.cpp Odd indenting near "CC": 1122 {CC "writeback0", CC "(" "J" ")V", FN_PTR(Unsafe_WriteBack0)}, 1123 {CC "writebackPreSync0", CC "()V", FN_PTR(Unsafe_WriteBackPreSync0)}, 1124 {CC "writebackPostSync0", CC "()V", FN_PTR(Unsafe_WriteBackPostSync0)}, camelCase: 464 static void doWriteBackSync0(bool isPre) === src/hotspot/share/prims/unsafe.cpp Do we really need this function pointer mess? 457 void (*wb)(void *); 458 void *a = addr_from_java(line); 459 wb = (void (*)(void *)) StubRoutines::data_cache_writeback(); 460 assert(wb != NULL, "generate writeback stub!"); 461 (*wb)(a); Seems easier to: assert(StubRoutines::data_cache_writeback() != NULL, "sanity"); StubRoutines::data_cache_writeback()(addr_from_java(line)); Thanks, -Aleksey From weijun.wang at oracle.com Tue Jul 30 16:01:25 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 31 Jul 2019 00:01:25 +0800 Subject: RFR: 8228778: JDK 13 L10n resource files update - msg drop 20 In-Reply-To: <9751e202-3677-ef1a-8d47-4382a27fba75@oracle.com> References: <9751e202-3677-ef1a-8d47-4382a27fba75@oracle.com> Message-ID: This is not a review to this change. The super long lines in translated properties files are really unreadable. Is it possible to reformat them like the English version? i.e. break the line at every non-terminal \n? Thanks, Max > On Jul 30, 2019, at 9:55 PM, li.jiang at oracle.com wrote: > > Hi, > > Please help to review the update of L10n resource files in JDK13 msg drop 20. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8228778 > Webrev: http://cr.openjdk.java.net/~ljiang/8228778/webrev/read/ > > Thanks, > Leo From kumargauravgupta3 at gmail.com Tue Jul 30 03:07:18 2019 From: kumargauravgupta3 at gmail.com (Kumar Gaurav) Date: Tue, 30 Jul 2019 08:37:18 +0530 Subject: jdk.serial filter is not working for restricting depth of treemap in java Message-ID: Hi All, I'm mailing here for the first time and I am unaware of any rules for mailing here. If there is any mistake please let me know. Below is my question JEP 290 solves the problem of deserialization vulnerabilities except some collection classes which includes TreeMap and LinkedList. Can we have any solution or any work around to counter that? In our RMI interface we are accepting Objects which may have TreeMap and since there's no check on the size of treemap it is vulnerable to DDos Attack. We have solution for ArrayList, Hashmap etc, Can we have something similar for TreeMap and LinkedList as well? Regards, Kumar Gaurav From naoto.sato at oracle.com Tue Jul 30 16:09:26 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 30 Jul 2019 09:09:26 -0700 Subject: RFR: 8160225: java.time.format.DateTimeFormatter issues for month-of-year In-Reply-To: References: Message-ID: <59eda23b-dcfe-ef25-d3c1-26e7e3c8ded7@oracle.com> Hi Thejasvi, M/L does not designate textual nor numeric. Thus I don't think that the suggested documentation fix is correct. Furthermore, although the exception in JDK8 looks like a bug, the test result with JDK9 looks correct to me. The month displayed as "04" is the result of ZonedDateTime.toString() so should not be localized. Naoto On 7/30/19 5:54 AM, Thejasvi Voniadka wrote: > Hi, > > Request your review of this simple change. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8160225 (java.time.format.DateTimeFormatter issues for month-of-year) > > Description: It is a simple documentation change. The DateTimeFormatter expects the month format to be represented by "L" for number and "M" for text (eg: "Jul" may be accepted by a format string "MMM"; "07" may be accepted by a format string "LL", and so on). However, the documentation lists this somewhat confusingly: > > "M/L month-of-year number/text 7; 07; Jul; July; J" > > A casual reader may interpret "M" as the numeric representation and "L" as the textual representation of the month-of-year, whereas the actual behavior of the API is the other way around. This patch fixes it. > > > Webrev: http://cr.openjdk.java.net/~vagarwal/8160225/webrev.0/ > > > > From thejasvi.v.voniadka at oracle.com Wed Jul 31 05:29:21 2019 From: thejasvi.v.voniadka at oracle.com (Thejasvi Voniadka) Date: Tue, 30 Jul 2019 22:29:21 -0700 (PDT) Subject: RFR: 8160225: java.time.format.DateTimeFormatter issues for month-of-year In-Reply-To: <59eda23b-dcfe-ef25-d3c1-26e7e3c8ded7@oracle.com> References: <59eda23b-dcfe-ef25-d3c1-26e7e3c8ded7@oracle.com> Message-ID: Hi Naoto, Thank you for the response. You are correct. I ran the reproducer against JDK13 and JDK9, and they appear not to differentiate between L and M as long as the input is consistent. I will update the bug and revise the effort accordingly. Thanks!! -----Original Message----- From: Naoto Sato Sent: Tuesday, July 30, 2019 9:39 PM To: Thejasvi Voniadka ; core-libs-dev at openjdk.java.net; i18n-dev at openjdk.java.net Subject: Re: RFR: 8160225: java.time.format.DateTimeFormatter issues for month-of-year Hi Thejasvi, M/L does not designate textual nor numeric. Thus I don't think that the suggested documentation fix is correct. Furthermore, although the exception in JDK8 looks like a bug, the test result with JDK9 looks correct to me. The month displayed as "04" is the result of ZonedDateTime.toString() so should not be localized. Naoto On 7/30/19 5:54 AM, Thejasvi Voniadka wrote: > Hi, > > Request your review of this simple change. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8160225 (java.time.format.DateTimeFormatter issues for month-of-year) > > Description: It is a simple documentation change. The DateTimeFormatter expects the month format to be represented by "L" for number and "M" for text (eg: "Jul" may be accepted by a format string "MMM"; "07" may be accepted by a format string "LL", and so on). However, the documentation lists this somewhat confusingly: > > "M/L month-of-year number/text 7; 07; Jul; July; J" > > A casual reader may interpret "M" as the numeric representation and "L" as the textual representation of the month-of-year, whereas the actual behavior of the API is the other way around. This patch fixes it. > > > Webrev: http://cr.openjdk.java.net/~vagarwal/8160225/webrev.0/ > > > > From peter.levart at gmail.com Wed Jul 31 07:59:27 2019 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 31 Jul 2019 09:59:27 +0200 Subject: Review Request: JDK-8209005: Lookup.unreflectSpecial fails for default methods when Lookup.findSpecial works In-Reply-To: <4b7cae81-2066-1b66-9f44-085b29bd5215@oracle.com> References: <8a3743fc-5ac3-0f79-2ee5-9814de6444e7@oracle.com> <6c13f13b-e08f-af91-f583-8acf48ee7182@oracle.com> <4b7cae81-2066-1b66-9f44-085b29bd5215@oracle.com> Message-ID: Hi, I think Daniel is talking about the "dispatch" semantics of unreflectSpecial here, right Daniel? The findSpecial / unreflectSpecial is a MethodHandle equivalent for bytecode instruction invokespecial (sans actual invoking). invokespecial is typically used for implementing the super.method(args) Java invocations. In that case, the superclass method is targeted - this is not a virtual method dispatch like aMethod.invoke(this, arg*) - i.e. the reflective invocation is always a virtual invocation (for non-private methods). Likewise findSpecial and unreflectSpecial produce a MethodHandle that dispatches to the method in the superclass (the aMethod.getDeclatingClass() in case of unreflectSpecial) regardless of whether that method is overridden in the subclass or not. Regards, Peter On 7/30/19 4:47 PM, Mandy Chung wrote: > > Think about aMethod is a protected method inherited from its > superclass T.? To invoke aMethod, the receiver must be an instance of > T or a subclass of T. > > Mandy > > On 7/30/19 3:22 AM, Daniel Fuchs wrote: >> Hi Mandy, >> >> ?380????? *???? {@link >> java.lang.invoke.MethodHandles.Lookup#unreflectSpecial >> lookup.unreflectSpecial(aMethod,this.class)} >> ?381????? *???? {@code T m(A*);}{@code (T) >> aMethod.invoke(this, arg*);} >> >> Is this exactly true? I mean - if `this` is an instance of >> a subclass of `aMethod.getDeclaringClass()`, and if that >> subclass overrides `aMethod`, then I would expect >> `aMethod.invoke(this, arg*)` to execute the bytecode >> of the method defined in the subclass. >> >> If I'm not mistaken, the test does expect that the >> bytecode in the super class is executed instead. >> I suspect that `unreflectSpecial` can only be specified >> in terms of `findSpecial`. But maybe I'm missing something. >> I'm not too familiar with the intricacies of MethodHandle. >> >> best regards, >> >> -- daniel >> >> On 26/07/2019 18:41, Mandy Chung wrote: >>> Daniel noticed that `unreflectSpecial` is missing in the "Lookup >>> Factory Methods" section in the class spec.? In fact there are a >>> duplicated `lookup.unreflect(aMethod)` row that might originally be >>> for `unreflectSpecial`.?? I fix the javadoc in this patch: >>> >>> http://cr.openjdk.java.net/~mchung/jdk14/8209005/webrev.01/ >>> >>> Mandy >>> >>> On 7/25/19 1:12 PM, Mandy Chung wrote: >>>> This patch fixes Lookup.unreflectSpecial to pass the declaring >>>> class of Method being unreflected (rather than null) so that it can >>>> accurately check if the special caller class is either the lookup >>>> class or a superinterface of the declaring class. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~mchung/jdk14/8209005/webrev.00/index.html >>>> >>>> The test runs in both unnamed module and named module to cover >>>> JDK-8209078 which has been resolved by JDK-8173978. >>>> >>>> thanks >>>> Mandy >>> >> > From peter.levart at gmail.com Wed Jul 31 08:44:51 2019 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 31 Jul 2019 10:44:51 +0200 Subject: Review Request: JDK-8209005: Lookup.unreflectSpecial fails for default methods when Lookup.findSpecial works In-Reply-To: References: <8a3743fc-5ac3-0f79-2ee5-9814de6444e7@oracle.com> <6c13f13b-e08f-af91-f583-8acf48ee7182@oracle.com> <4b7cae81-2066-1b66-9f44-085b29bd5215@oracle.com> Message-ID: On 7/31/19 9:59 AM, Peter Levart wrote: > Hi, > > I think Daniel is talking about the "dispatch" semantics of > unreflectSpecial here, right Daniel? > > The findSpecial / unreflectSpecial is a MethodHandle equivalent for > bytecode instruction invokespecial (sans actual invoking). > invokespecial is typically used for implementing the > super.method(args) Java invocations. In that case, the superclass > method is targeted - this is not a virtual method dispatch like > aMethod.invoke(this, arg*) - i.e. the reflective invocation is always > a virtual invocation (for non-private methods). Likewise findSpecial > and unreflectSpecial produce a MethodHandle that dispatches to the > method in the superclass (the aMethod.getDeclatingClass() in case of > unreflectSpecial) regardless of whether that method is overridden in > the subclass or not. > Expanding on this a little. The javadocs of MethodHandles.Lookup starts talking about the Lookup factory methods methods and their equivalence to bytecode instructions, but then present the equivalence between find* and Java source code (which is OK given that translation to bytecode is known) followed by equivalence between unreflect* and reflective invocations. Public reflection API does not implement the equivalent behavior to unreflectSpecial. So perhaps, this line only could present the equivalence in terms of Java code like findSpecial does with a comment stating that there's no equivalence with reflective invocation API. For example: ???? * ???? *???? lookup expression ???? *???? member ???? *???? bytecode / reflection behavior Added "/ reflection" above; and: ???? * ???? *???? {@link java.lang.invoke.MethodHandles.Lookup#unreflectSpecial lookup.unreflectSpecial(aMethod,this.class)} ???? *???? {@code T m(A*);}{@code (T) super.m(arg*); // no equivalent reflective invocation} ???? * Regards, Peter > Regards, Peter > > On 7/30/19 4:47 PM, Mandy Chung wrote: >> >> Think about aMethod is a protected method inherited from its >> superclass T.? To invoke aMethod, the receiver must be an instance of >> T or a subclass of T. >> >> Mandy >> >> On 7/30/19 3:22 AM, Daniel Fuchs wrote: >>> Hi Mandy, >>> >>> ?380????? *???? {@link >>> java.lang.invoke.MethodHandles.Lookup#unreflectSpecial >>> lookup.unreflectSpecial(aMethod,this.class)} >>> ?381????? *???? {@code T m(A*);}{@code (T) >>> aMethod.invoke(this, arg*);} >>> >>> Is this exactly true? I mean - if `this` is an instance of >>> a subclass of `aMethod.getDeclaringClass()`, and if that >>> subclass overrides `aMethod`, then I would expect >>> `aMethod.invoke(this, arg*)` to execute the bytecode >>> of the method defined in the subclass. >>> >>> If I'm not mistaken, the test does expect that the >>> bytecode in the super class is executed instead. >>> I suspect that `unreflectSpecial` can only be specified >>> in terms of `findSpecial`. But maybe I'm missing something. >>> I'm not too familiar with the intricacies of MethodHandle. >>> >>> best regards, >>> >>> -- daniel >>> >>> On 26/07/2019 18:41, Mandy Chung wrote: >>>> Daniel noticed that `unreflectSpecial` is missing in the "Lookup >>>> Factory Methods" section in the class spec.? In fact there are a >>>> duplicated `lookup.unreflect(aMethod)` row that might originally be >>>> for `unreflectSpecial`.?? I fix the javadoc in this patch: >>>> >>>> http://cr.openjdk.java.net/~mchung/jdk14/8209005/webrev.01/ >>>> >>>> Mandy >>>> >>>> On 7/25/19 1:12 PM, Mandy Chung wrote: >>>>> This patch fixes Lookup.unreflectSpecial to pass the declaring >>>>> class of Method being unreflected (rather than null) so that it >>>>> can accurately check if the special caller class is either the >>>>> lookup class or a superinterface of the declaring class. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~mchung/jdk14/8209005/webrev.00/index.html >>>>> >>>>> The test runs in both unnamed module and named module to cover >>>>> JDK-8209078 which has been resolved by JDK-8173978. >>>>> >>>>> thanks >>>>> Mandy >>>> >>> >> > From chengjingwei1 at huawei.com Wed Jul 31 09:46:14 2019 From: chengjingwei1 at huawei.com (chengjingwei) Date: Wed, 31 Jul 2019 17:46:14 +0800 Subject: [8u] Request for backporting a series of issues affecting core-libs Message-ID: Hi, all Would someone help to approve the backport of the following issues? - Issue list: JDK-8151788 JDK-8026049 JDK-8149469 JDK-8149469 - Details: JDK-8151788 Reproduced on 8u:[Yes] Bug: https://bugs.openjdk.java.net/browse/JDK-8151788 Patch is clean:[Yes] JDK9 Changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3b503af253a4 JDK-8026049 Reproduced on 8u:[Yes] Bug: https://bugs.openjdk.java.net/browse/JDK-8026049 Patch is clean:[Yes] JDK9 Changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/662f01f35702 JDK-8151163 Reproduced on 8u:[Yes] Bug: https://bugs.openjdk.java.net/browse/JDK-8151163 Patch is clean:[Yes] JDK9 Changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/f9dcefa42da3 JDK-8149469 Reproduced on 8u:[Yes] Bug: https://bugs.openjdk.java.net/browse/JDK-8149469 Patch is clean:[Yes] JDK9 Changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/5e0fd2cdcd55 These issues are decreasing the stability of our applications. They are always reproducible with jdk built from the latest jdk8u master repo. From daniel.fuchs at oracle.com Wed Jul 31 09:57:40 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 31 Jul 2019 10:57:40 +0100 Subject: Review Request: JDK-8209005: Lookup.unreflectSpecial fails for default methods when Lookup.findSpecial works In-Reply-To: References: <8a3743fc-5ac3-0f79-2ee5-9814de6444e7@oracle.com> <6c13f13b-e08f-af91-f583-8acf48ee7182@oracle.com> <4b7cae81-2066-1b66-9f44-085b29bd5215@oracle.com> Message-ID: <5ab6982a-f45f-022b-63cc-4315121d0de1@oracle.com> Hi Peter, Mandy, On 31/07/2019 08:59, Peter Levart wrote: > Hi, > > I think Daniel is talking about the "dispatch" semantics of > unreflectSpecial here, right Daniel? Yes, exactly! > The findSpecial / unreflectSpecial is a MethodHandle equivalent for > bytecode instruction invokespecial (sans actual invoking). invokespecial > is typically used for implementing the super.method(args) Java > invocations. In that case, the superclass method is targeted - this is > not a virtual method dispatch like aMethod.invoke(this, arg*) - i.e. the > reflective invocation is always a virtual invocation (for non-private > methods). Likewise findSpecial and unreflectSpecial produce a > MethodHandle that dispatches to the method in the superclass (the > aMethod.getDeclatingClass() in case of unreflectSpecial) regardless of > whether that method is overridden in the subclass or not. Thanks Peter, that's exactly what I wanted to say. Apologies for not being clear enough. best regards, -- daniel > > Regards, Peter From shade at redhat.com Wed Jul 31 10:00:59 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 31 Jul 2019 12:00:59 +0200 Subject: [8u] Request for backporting a series of issues affecting core-libs In-Reply-To: References: Message-ID: On 7/31/19 11:46 AM, chengjingwei wrote: > Would someone help to approve the backport of the following issues? Same here. You have to follow the process outlined here: https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix At very least, do not lump multiple issues together, and do not use generic topic like "backporting some issues". The mail archives should be searchable by bug ID. Please start over. -- Thanks, -Aleksey From daniel.fuchs at oracle.com Wed Jul 31 10:15:08 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 31 Jul 2019 11:15:08 +0100 Subject: Review Request: JDK-8209005: Lookup.unreflectSpecial fails for default methods when Lookup.findSpecial works In-Reply-To: References: <8a3743fc-5ac3-0f79-2ee5-9814de6444e7@oracle.com> <6c13f13b-e08f-af91-f583-8acf48ee7182@oracle.com> <4b7cae81-2066-1b66-9f44-085b29bd5215@oracle.com> Message-ID: <8b2ac69f-41af-dd0b-9cbf-e361cda90c2d@oracle.com> Hi Peter, Mandy, On 31/07/2019 09:44, Peter Levart wrote: > Expanding on this a little. The javadocs of MethodHandles.Lookup starts > talking about the Lookup factory methods methods and their equivalence > to bytecode instructions, but then present the equivalence between find* > and Java source code (which is OK given that translation to bytecode is > known) followed by equivalence between unreflect* and reflective > invocations. Public reflection API does not implement the equivalent > behavior to unreflectSpecial. So perhaps, this line only could present > the equivalence in terms of Java code like findSpecial does with a > comment stating that there's no equivalence with reflective invocation > API. For example: > > ???? * > ???? *???? lookup expression > ???? *???? member > ???? *???? bytecode / reflection behavior > > Added "/ reflection" above; and: > > ???? * > ???? *???? {@link > java.lang.invoke.MethodHandles.Lookup#unreflectSpecial > lookup.unreflectSpecial(aMethod,this.class)} > ???? *???? {@code T m(A*);}{@code (T) super.m(arg*); // no > equivalent reflective invocation} > ???? * Yes - I would find this description better. Additionally maybe it could say that the MH returned is equivalent to that returned by `findSpecial(aMethod.getDeclaringClass(), aMethod.getName(), MT, this.class)` - as there's no reflection equivalent? >> On 7/30/19 4:47 PM, Mandy Chung wrote: >>> >>> Think about aMethod is a protected method inherited from its >>> superclass T.? To invoke aMethod, the receiver must be an instance of >>> T or a subclass of T. Ah - that's a very good explanation for the nature of the fix itself. Thanks for that! But my comment was about virtual vs special invocation as Peter noted. best regards, -- daniel From adinn at redhat.com Wed Jul 31 10:55:31 2019 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 31 Jul 2019 11:55:31 +0100 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <671c7ba1-9597-a990-190b-145d9cb5349e@redhat.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> <892f3b0b-55f1-872d-15f4-5af907fa8437@redhat.com> <8f72d3b5-3a01-a7de-3b09-35571266a87d@redhat.com> <671c7ba1-9597-a990-190b-145d9cb5349e@redhat.com> Message-ID: <81098801-31b2-e3a8-5c25-043ab47c80bc@redhat.com> Hi Aleksey On 30/07/2019 17:00, Aleksey Shipilev wrote: > On 7/30/19 5:04 PM, Andrew Dinn wrote: >> JEP 352 has now been targeted for inclusion in JDK14. The latest webrev >> for the implementation JIRA has been rebased to apply to the current >> tree. Is it now ok to push this change set? >> >> JIRA: https://bugs.openjdk.java.net/browse/JDK-8224974 >> webrev: http://cr.openjdk.java.net/~adinn/8224974/webrev.09 > Is it okay to have a late code review? Here it goes: Sure, welcome to the party even if most of the booze has been drunk :-) Thank you for a very thorough review. Comments (mostly in agreement) are inline below. They include a few refusals and a walk past some of the jumps pending confirmation they truly form part of the obstacle course. A new webrev against the latest jdk/jdk dev tree including all uncontested changes is here: http://cr.openjdk.java.net/~adinn/8224974/webrev.10/ > === General: > > So if pre wbsync is no-op, why do we need to handle it everywhere? We seem to be falling through all > the way to the stub to do nothing there, maybe we should instead cut much earlier, e.g. when > inlining Unsafe.writeBackPresync0? Would it be better to not emit CacheWBPreSync at all? Ah, I see you brought your own bottle ;-) The pre sync is definitely not needed at present. However, I put it there because I didn't know for sure if some future port of this capability (e.g. to ppc) might need to sync prior writes before writing back cache lines. [Indeed, the old Intel documentation stated that pre-sync was needed on x86 for clflush to be safe but it is definitely not needed.] Anyway, folding out the pre-sync as you suggest would mean taking what is still potentially an architecture-specific decision in generic code. That may well prove to be a redundant precaution but it also costs little -- every affected /compile/ will last a tad longer and be a tad fatter in its memory footprint. If you think change is important I will happily oblige. > === General: > > IIRC, notproduct and PRODUCT defines are legacy, and should be avoided? develop and ASSERT must be > the substitutes for this. See some discussion here: https://bugs.openjdk.java.net/browse/JDK-8183287 Ok done. I changed #ifndef PRODUCT to #ifdef ASSERT in library_call.cpp and unsafe.cpp. I also redefined global flag TraceMemoryWriteback using develop rather than notproduct. I also removed the AArch64 /product/ compiler option UsePOCForPOP. This allowed the JIT to use a memory writeback instruction with weakened semantics if the full writeback is not available in a product build. product was chosen because this was needed to establish a benchmark for writeback on existing kit when using a pseudo-NVRAM memory device based on volatile memory. The point was to be able to do an apples to apples comparison with writeback to a disk device. Obviously, it's not much use doing that test with a a non-product build. This is only important during development as a one-off test once the OS support for pseudo-NVRAM devices arrives in Linux AArch64 (which should happen well before new kit with the POP writeback arrives). I can still perform it using a custom build so I dropped this from the patch. > === src/hotspot/cpu/aarch64/aarch64.ad > src/hotspot/cpu/x86/x86.ad > > This should probably be just "!VM_Version...". Braces around the statement would not hurt either. > > 2196 if (VM_Version::supports_data_cache_line_flush() == false) > 2197 ret_value = false; Done. > === src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp > src/hotspot/cpu/x86/macroAssembler_x86.cpp > > Braces style mismatch, should be on the same line, as in the rest of the file: > > 5837 void MacroAssembler::cache_wb(Address line) > 5838 { > > 5856 void MacroAssembler::cache_wbsync(bool is_pre) > 5857 { Done. > === src/hotspot/cpu/x86/assembler_x86.cpp > > It feels like these comments are redundant, especially L8630 and L8646 which mention magic values > "6" and "7", not present in the code: > > 8624 // instruction prefix is 0x66 > > 8627 // opcode family is 0x0f 0xAE > > 8630 // extended opcode byte is 7 == rdi > > 8640 // instruction prefix is 0x66 > > 8643 // opcode family is 0x0f 0xAE > > 8646 // extended opcode byte is 6 == rsi Well, I think the question of redundancy depends on how you look at it. The comments are not there to explain that these values are the ones being passed to the emit functions -- that is pretty obvious. They are there to explain what those values mean i.e. to explain what elements of the fully assembled instruction the emit calls assembling piecemeal. Perhaps that reading woudl be clearer if each such equation of terms was done in reverse order: 8624 // 0x66 is instruction prefix 8627 // 0x0f 0xAE is opcode family 8630 // rdi == 7 is extended opcode byte . . . Given that the code is simply stuffing numbers (whether supplied as literals or as symbolic constants) into a byte stream I think these comments are a help when it comes to cross-checking each specific assembly against the corresponding numbers declared in the Intel manuals. So, I don't really want to remove them. Would you prefer me to reverse the wording as above? > === src/hotspot/cpu/x86/macroAssembler_x86.cpp > > These comments feel redundant too. Well, maybe they should instead talk about the choices the > subsequent code makes. > > 9915 // pick the correct implementation > > 9936 // pick the correct implementation I agree it would help to expand the comment to explain the logic of the choice in the first case: // prefer clwb (potentially parallel writeback without evict) // otherwise prefer clflushopt (potentially parallel writeback // with evict) // otherwise fallback on clflush (serial writeback with evict) In the second case the comment is redundant because the need for an sfence is covered by the existing comment inside the if: // need an sfence for post flush when using clflushopt or clwb // otherwise no no need for any synchroniaztion > === src/hotspot/cpu/x86/macroAssembler_x86.cpp > src/hotspot/cpu/x86/vm_version_x86.hpp > > The docs say "The CLFLUSH instruction was introduced with the SSE2 extensions; however, because it > has its own CPUID feature flag, it can be implemented in IA-32 processors that do not include the > SSE2 extensions. Also, detecting the presence of the SSE2 extensions with the CPUID instruction does > not guarantee that the CLFLUSH instruction is implemented in the processor." > > Yet, we have: > > 9910 // 64 bit cpus always support clflush > 9911 assert(VM_Version::supports_clflush(), "should not reach here on 32-bit"); > > 505 #ifdef _LP64 > 506 // cpflush is always available on x86_64 > 507 result |= CPU_FLUSH; > 508 #else > 509 if (_cpuid_info.std_cpuid1_edx.bits.clflush != 0) > 510 result |= CPU_FLUSH; > 511 #endif > > 967 // 64 bit cpus always support clflush which writes back and evicts > 968 // on 32 bit cpus support is recorded via a feature flag > > 980 static bool supports_clflush() { return true; } > > I think the assert should just say "clflush should be available", and clflush cpu flag detected for > 64-bits too? I think that documentation is only talking about x86_32. I remember reading somewhere that clflush is always guaranteed to be available on x86_64 only I cannot remember where (I think maybe it was in Intel's libpmem code?). Anyway, I do not take the above to imply that clflush has been, or even can be, omitted on a 64-bit processor. However, let us assume that it can in principle be omitted from an x86_64 implementation. If so then I'll suggest that such a beast is a thing only in the sense that the Kingdom of Antarctica is a thing (i.e. it is an unactualized possible). As a non-existence proof I'll note that the JVM already relies implicitly (i.e. without checking any CPU bits) on being able to call clflush on x86_64 (see icache_x86.cpp). Anyway, granted the possibility of said Magic Kingdom I have changed the assert to say "clflush should be available". I have also i) modified setting of the CPU_FLUSH flag to test the relevant bit on both 32 and 64 bits + // cpflush should always be available on x86_64 + // test the flag anyway and assert later + if (_cpuid_info.std_cpuid1_edx.bits.clflush != 0) + result |= CPU_FLUSH; . . . ii) added an assert that it is set to the 64-bit version of supports_clflush: +#ifdef _LP64 + static bool supports_clflush() { + assert((_features & CPU_FLUSH) != 0, "clflush should be available"); + return true; + } . . . > === src/hotspot/cpu/x86/macroAssembler_x86.hpp > > Accidental camelCase, while hotspot code expects snake_case: > > 1794 void cache_wbsync(bool isPre); Fixed. > === src/hotspot/cpu/x86/stubGenerator_x86_64.cpp > > Any reason to avoid inline here, e.g. "__ cache_wb(Address(src, 0))"? > > 2921 const Address line(src, 0); > 2922 __ cache_wb(line); Well, I guess only if you're "not into that whole brevity thing" (c.f. The Big Lebowski). Condensed accordingly. > === src/hotspot/cpu/x86/stubGenerator_x86_64.cpp > > Is it really "cmpl" here, not "cmpb"? I think aarch64 code tests for byte. > > 2942 __ cmpl(is_pre, 0); This is a Java boolean input. I believe that means the value will be loaded into c_arg0 as an int so this test ought to be adequate. The Arch64 code actually tests the input value as a long word: __ enter(); __ cbnz(is_pre, skip); . . . n.b. cbnz == compare and branch if non-zero (64 bit). This latter code could (arguably) employ a cbnzw (i.e. 32-bit variant). However, the argument will have been loaded into c_rarg0 using an AArch64 int load which guarantees to zero the top 32 bits. So, it doesn't really make any difference whether this uses cbnz or cbnzw. > === src/hotspot/share/classfile/vmSymbols.hpp > > Excess space before "jdk_internal..." here: > > 1096 do_intrinsic(_writebackPostSync0, jdk_internal_misc_Unsafe, > writebackPostSync0_name, void_method_signature , F_RN) \ Fixed. > === src/hotspot/share/opto/c2compiler.cpp > > Why inject new cases here, instead of at the end of switch? Saves sudden "break": > > 578 break; > 579 case vmIntrinsics::_writeback0: > 580 if (!Matcher::match_rule_supported(Op_CacheWB)) return false; > 581 break; > 582 case vmIntrinsics::_writebackPreSync0: > 583 if (!Matcher::match_rule_supported(Op_CacheWBPreSync)) return false; > 584 break; > 585 case vmIntrinsics::_writebackPostSync0: > 586 if (!Matcher::match_rule_supported(Op_CacheWBPostSync)) return false; > 587 break; I placed them here so they were close to the other Unsafe intrinsics. In particular they precede _allocateInstance, an ordering which is also the case in the declarations in vmSymbols.hpp. In what sense do you mean that an extra 'break' is saved? That would be true as regards the textual layout. It wouldn't affect the logic of folding different ranges of values into branching range tests (which is only determined by the numeric values of the intrinsics). If you are concerned about the former then I would argue that placing the values in declaration order seems to me to be the more important concern. > === src/hotspot/share/opto/library_call.cpp > > Accidental camelCase here, should be snake_case: > > 257 bool inline_unsafe_writebackSync0(bool isPre); > > 2870 bool LibraryCallKit::inline_unsafe_writebackSync0(bool isPre) { Fixed. > === src/hotspot/share/prims/unsafe.cpp > > Odd indenting near "CC": > > 1122 {CC "writeback0", CC "(" "J" ")V", FN_PTR(Unsafe_WriteBack0)}, > 1123 {CC "writebackPreSync0", CC "()V", FN_PTR(Unsafe_WriteBackPreSync0)}, > 1124 {CC "writebackPostSync0", CC "()V", FN_PTR(Unsafe_WriteBackPostSync0)}, Fixed. > camelCase: > 464 static void doWriteBackSync0(bool isPre) Fixed. > === src/hotspot/share/prims/unsafe.cpp > > Do we really need this function pointer mess? > > 457 void (*wb)(void *); > 458 void *a = addr_from_java(line); > 459 wb = (void (*)(void *)) StubRoutines::data_cache_writeback(); > 460 assert(wb != NULL, "generate writeback stub!"); > 461 (*wb)(a); > > Seems easier to: > > assert(StubRoutines::data_cache_writeback() != NULL, "sanity"); > StubRoutines::data_cache_writeback()(addr_from_java(line)); Hmm, "that whole brevity thing" again? Well, I guess you must now call me "El Duderino". Are you sure that all the compilers used to build openJDK will happily eat the second line of your replacement? If you can guarantee that I'll happily remove the type declarations. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Wed Jul 31 11:29:15 2019 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 31 Jul 2019 12:29:15 +0100 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <81098801-31b2-e3a8-5c25-043ab47c80bc@redhat.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> <892f3b0b-55f1-872d-15f4-5af907fa8437@redhat.com> <8f72d3b5-3a01-a7de-3b09-35571266a87d@redhat.com> <671c7ba1-9597-a990-190b-145d9cb5349e@redhat.com> <81098801-31b2-e3a8-5c25-043ab47c80bc@redhat.com> Message-ID: <27916ded-74e2-94d8-891c-95d87730b69d@redhat.com> Hi Aleksey, I have an update regarding the change to the computation of the CPU_FLUSH flag. After posting the new webrev I built a debug version with the change that tests the clflush bit on x86_64. It crashed when the assert is reached in VM_Version::supports_cpuflush: # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (src/hotspot/cpu/x86/vm_version_x86.hpp:978), pid=29597, tid=29602 # assert((_features & ((uint64_t)(0x20000000000ULL))) != 0) failed: clflush should be available So, it seems the clflush bit is not set on my x86_64 box even though I am able to execute clflush quite happily. "Toto, it looks like we are no longer in Antarctica." So, I will revert this change (in the next webrev). regards, Andrew Dinn ----------- On 31/07/2019 11:55, Andrew Dinn wrote: > Hi Aleksey > > On 30/07/2019 17:00, Aleksey Shipilev wrote: >> On 7/30/19 5:04 PM, Andrew Dinn wrote: >>> JEP 352 has now been targeted for inclusion in JDK14. The latest webrev >>> for the implementation JIRA has been rebased to apply to the current >>> tree. Is it now ok to push this change set? >>> >>> JIRA: https://bugs.openjdk.java.net/browse/JDK-8224974 >>> webrev: http://cr.openjdk.java.net/~adinn/8224974/webrev.09 >> Is it okay to have a late code review? Here it goes: > > Sure, welcome to the party even if most of the booze has been drunk :-) > > Thank you for a very thorough review. Comments (mostly in agreement) are > inline below. They include a few refusals and a walk past some of the > jumps pending confirmation they truly form part of the obstacle course. > > A new webrev against the latest jdk/jdk dev tree including all > uncontested changes is here: > > http://cr.openjdk.java.net/~adinn/8224974/webrev.10/ > >> === General: >> >> So if pre wbsync is no-op, why do we need to handle it everywhere? We seem to be falling through all >> the way to the stub to do nothing there, maybe we should instead cut much earlier, e.g. when >> inlining Unsafe.writeBackPresync0? Would it be better to not emit CacheWBPreSync at all? > > Ah, I see you brought your own bottle ;-) > > The pre sync is definitely not needed at present. However, I put it > there because I didn't know for sure if some future port of this > capability (e.g. to ppc) might need to sync prior writes before writing > back cache lines. [Indeed, the old Intel documentation stated that > pre-sync was needed on x86 for clflush to be safe but it is definitely > not needed.] > > Anyway, folding out the pre-sync as you suggest would mean taking what > is still potentially an architecture-specific decision in generic code. > That may well prove to be a redundant precaution but it also costs > little -- every affected /compile/ will last a tad longer and be a tad > fatter in its memory footprint. If you think change is important I will > happily oblige. > >> === General: >> >> IIRC, notproduct and PRODUCT defines are legacy, and should be avoided? develop and ASSERT must be >> the substitutes for this. See some discussion here: https://bugs.openjdk.java.net/browse/JDK-8183287 > > Ok done. > > I changed #ifndef PRODUCT to #ifdef ASSERT in library_call.cpp and > unsafe.cpp. I also redefined global flag TraceMemoryWriteback using > develop rather than notproduct. > > I also removed the AArch64 /product/ compiler option UsePOCForPOP. This > allowed the JIT to use a memory writeback instruction with weakened > semantics if the full writeback is not available in a product build. > product was chosen because this was needed to establish a benchmark for > writeback on existing kit when using a pseudo-NVRAM memory device based > on volatile memory. The point was to be able to do an apples to apples > comparison with writeback to a disk device. Obviously, it's not much > use doing that test with a a non-product build. This is only important > during development as a one-off test once the OS support for > pseudo-NVRAM devices arrives in Linux AArch64 (which should happen well > before new kit with the POP writeback arrives). I can still perform it > using a custom build so I dropped this from the patch. > >> === src/hotspot/cpu/aarch64/aarch64.ad >> src/hotspot/cpu/x86/x86.ad >> >> This should probably be just "!VM_Version...". Braces around the statement would not hurt either. >> >> 2196 if (VM_Version::supports_data_cache_line_flush() == false) >> 2197 ret_value = false; > > Done. > >> === src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp >> src/hotspot/cpu/x86/macroAssembler_x86.cpp >> >> Braces style mismatch, should be on the same line, as in the rest of the file: >> >> 5837 void MacroAssembler::cache_wb(Address line) >> 5838 { >> >> 5856 void MacroAssembler::cache_wbsync(bool is_pre) >> 5857 { > > Done. > >> === src/hotspot/cpu/x86/assembler_x86.cpp >> >> It feels like these comments are redundant, especially L8630 and L8646 which mention magic values >> "6" and "7", not present in the code: >> >> 8624 // instruction prefix is 0x66 >> >> 8627 // opcode family is 0x0f 0xAE >> >> 8630 // extended opcode byte is 7 == rdi >> >> 8640 // instruction prefix is 0x66 >> >> 8643 // opcode family is 0x0f 0xAE >> >> 8646 // extended opcode byte is 6 == rsi > > Well, I think the question of redundancy depends on how you look at it. > The comments are not there to explain that these values are the ones > being passed to the emit functions -- that is pretty obvious. They are > there to explain what those values mean i.e. to explain what elements of > the fully assembled instruction the emit calls assembling piecemeal. > Perhaps that reading woudl be clearer if each such equation of terms was > done in reverse order: > > 8624 // 0x66 is instruction prefix > > 8627 // 0x0f 0xAE is opcode family > > 8630 // rdi == 7 is extended opcode byte > . . . > > Given that the code is simply stuffing numbers (whether supplied as > literals or as symbolic constants) into a byte stream I think these > comments are a help when it comes to cross-checking each specific > assembly against the corresponding numbers declared in the Intel > manuals. So, I don't really want to remove them. Would you prefer me to > reverse the wording as above? > >> === src/hotspot/cpu/x86/macroAssembler_x86.cpp >> >> These comments feel redundant too. Well, maybe they should instead talk about the choices the >> subsequent code makes. >> >> 9915 // pick the correct implementation >> >> 9936 // pick the correct implementation > > I agree it would help to expand the comment to explain the logic of the > choice in the first case: > > // prefer clwb (potentially parallel writeback without evict) > // otherwise prefer clflushopt (potentially parallel writeback > // with evict) > // otherwise fallback on clflush (serial writeback with evict) > > In the second case the comment is redundant because the need for an > sfence is covered by the existing comment inside the if: > > // need an sfence for post flush when using clflushopt or clwb > // otherwise no no need for any synchroniaztion > >> === src/hotspot/cpu/x86/macroAssembler_x86.cpp >> src/hotspot/cpu/x86/vm_version_x86.hpp >> >> The docs say "The CLFLUSH instruction was introduced with the SSE2 extensions; however, because it >> has its own CPUID feature flag, it can be implemented in IA-32 processors that do not include the >> SSE2 extensions. Also, detecting the presence of the SSE2 extensions with the CPUID instruction does >> not guarantee that the CLFLUSH instruction is implemented in the processor." >> >> Yet, we have: >> >> 9910 // 64 bit cpus always support clflush >> 9911 assert(VM_Version::supports_clflush(), "should not reach here on 32-bit"); >> >> 505 #ifdef _LP64 >> 506 // cpflush is always available on x86_64 >> 507 result |= CPU_FLUSH; >> 508 #else >> 509 if (_cpuid_info.std_cpuid1_edx.bits.clflush != 0) >> 510 result |= CPU_FLUSH; >> 511 #endif >> >> 967 // 64 bit cpus always support clflush which writes back and evicts >> 968 // on 32 bit cpus support is recorded via a feature flag >> >> 980 static bool supports_clflush() { return true; } >> >> I think the assert should just say "clflush should be available", and clflush cpu flag detected for >> 64-bits too? > > I think that documentation is only talking about x86_32. I remember > reading somewhere that clflush is always guaranteed to be available on > x86_64 only I cannot remember where (I think maybe it was in Intel's > libpmem code?). Anyway, I do not take the above to imply that clflush > has been, or even can be, omitted on a 64-bit processor. However, let us > assume that it can in principle be omitted from an x86_64 > implementation. If so then I'll suggest that such a beast is a thing > only in the sense that the Kingdom of Antarctica is a thing (i.e. it is > an unactualized possible). As a non-existence proof I'll note that the > JVM already relies implicitly (i.e. without checking any CPU bits) on > being able to call clflush on x86_64 (see icache_x86.cpp). > > Anyway, granted the possibility of said Magic Kingdom I have changed the > assert to say "clflush should be available". I have also > > i) modified setting of the CPU_FLUSH flag to test the relevant bit on > both 32 and 64 bits > > + // cpflush should always be available on x86_64 > + // test the flag anyway and assert later > + if (_cpuid_info.std_cpuid1_edx.bits.clflush != 0) > + result |= CPU_FLUSH; > . . . > > ii) added an assert that it is set to the 64-bit version of > supports_clflush: > > +#ifdef _LP64 > + static bool supports_clflush() { > + assert((_features & CPU_FLUSH) != 0, "clflush should be available"); > + return true; > + } > . . . > >> === src/hotspot/cpu/x86/macroAssembler_x86.hpp >> >> Accidental camelCase, while hotspot code expects snake_case: >> >> 1794 void cache_wbsync(bool isPre); > > Fixed. > >> === src/hotspot/cpu/x86/stubGenerator_x86_64.cpp >> >> Any reason to avoid inline here, e.g. "__ cache_wb(Address(src, 0))"? >> >> 2921 const Address line(src, 0); >> 2922 __ cache_wb(line); > > Well, I guess only if you're "not into that whole brevity thing" (c.f. > The Big Lebowski). Condensed accordingly. > >> === src/hotspot/cpu/x86/stubGenerator_x86_64.cpp >> >> Is it really "cmpl" here, not "cmpb"? I think aarch64 code tests for byte. >> >> 2942 __ cmpl(is_pre, 0); > > This is a Java boolean input. I believe that means the value will be > loaded into c_arg0 as an int so this test ought to be adequate. > > The Arch64 code actually tests the input value as a long word: > > __ enter(); > __ cbnz(is_pre, skip); > . . . > > n.b. cbnz == compare and branch if non-zero (64 bit). This latter code > could (arguably) employ a cbnzw (i.e. 32-bit variant). However, the > argument will have been loaded into c_rarg0 using an AArch64 int load > which guarantees to zero the top 32 bits. So, it doesn't really make any > difference whether this uses cbnz or cbnzw. > >> === src/hotspot/share/classfile/vmSymbols.hpp >> >> Excess space before "jdk_internal..." here: >> >> 1096 do_intrinsic(_writebackPostSync0, jdk_internal_misc_Unsafe, >> writebackPostSync0_name, void_method_signature , F_RN) \ > > Fixed. > >> === src/hotspot/share/opto/c2compiler.cpp >> >> Why inject new cases here, instead of at the end of switch? Saves sudden "break": >> >> 578 break; >> 579 case vmIntrinsics::_writeback0: >> 580 if (!Matcher::match_rule_supported(Op_CacheWB)) return false; >> 581 break; >> 582 case vmIntrinsics::_writebackPreSync0: >> 583 if (!Matcher::match_rule_supported(Op_CacheWBPreSync)) return false; >> 584 break; >> 585 case vmIntrinsics::_writebackPostSync0: >> 586 if (!Matcher::match_rule_supported(Op_CacheWBPostSync)) return false; >> 587 break; > > I placed them here so they were close to the other Unsafe intrinsics. In > particular they precede _allocateInstance, an ordering which is also the > case in the declarations in vmSymbols.hpp. > > In what sense do you mean that an extra 'break' is saved? That would be > true as regards the textual layout. It wouldn't affect the logic of > folding different ranges of values into branching range tests (which is > only determined by the numeric values of the intrinsics). If you are > concerned about the former then I would argue that placing the values in > declaration order seems to me to be the more important concern. > >> === src/hotspot/share/opto/library_call.cpp >> >> Accidental camelCase here, should be snake_case: >> >> 257 bool inline_unsafe_writebackSync0(bool isPre); >> >> 2870 bool LibraryCallKit::inline_unsafe_writebackSync0(bool isPre) { > > Fixed. > >> === src/hotspot/share/prims/unsafe.cpp >> >> Odd indenting near "CC": >> >> 1122 {CC "writeback0", CC "(" "J" ")V", FN_PTR(Unsafe_WriteBack0)}, >> 1123 {CC "writebackPreSync0", CC "()V", FN_PTR(Unsafe_WriteBackPreSync0)}, >> 1124 {CC "writebackPostSync0", CC "()V", FN_PTR(Unsafe_WriteBackPostSync0)}, > > Fixed. > >> camelCase: >> 464 static void doWriteBackSync0(bool isPre) > > Fixed. > >> === src/hotspot/share/prims/unsafe.cpp >> >> Do we really need this function pointer mess? >> >> 457 void (*wb)(void *); >> 458 void *a = addr_from_java(line); >> 459 wb = (void (*)(void *)) StubRoutines::data_cache_writeback(); >> 460 assert(wb != NULL, "generate writeback stub!"); >> 461 (*wb)(a); >> >> Seems easier to: >> >> assert(StubRoutines::data_cache_writeback() != NULL, "sanity"); >> StubRoutines::data_cache_writeback()(addr_from_java(line)); > Hmm, "that whole brevity thing" again? Well, I guess you must now call > me "El Duderino". > > Are you sure that all the compilers used to build openJDK will happily > eat the second line of your replacement? If you can guarantee that I'll > happily remove the type declarations. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > -- regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From shade at redhat.com Wed Jul 31 11:40:06 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 31 Jul 2019 13:40:06 +0200 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <27916ded-74e2-94d8-891c-95d87730b69d@redhat.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> <892f3b0b-55f1-872d-15f4-5af907fa8437@redhat.com> <8f72d3b5-3a01-a7de-3b09-35571266a87d@redhat.com> <671c7ba1-9597-a990-190b-145d9cb5349e@redhat.com> <81098801-31b2-e3a8-5c25-043ab47c80bc@redhat.com> <27916ded-74e2-94d8-891c-95d87730b69d@redhat.com> Message-ID: On 7/31/19 1:29 PM, Andrew Dinn wrote: > I have an update regarding the change to the computation of the > CPU_FLUSH flag. After posting the new webrev I built a debug version > with the change that tests the clflush bit on x86_64. It crashed when > the assert is reached in VM_Version::supports_cpuflush: > > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (src/hotspot/cpu/x86/vm_version_x86.hpp:978), > pid=29597, tid=29602 > # assert((_features & ((uint64_t)(0x20000000000ULL))) != 0) failed: > clflush should be available > > So, it seems the clflush bit is not set on my x86_64 box even though I > am able to execute clflush quite happily. > > "Toto, it looks like we are no longer in Antarctica." > > So, I will revert this change (in the next webrev). But wait, that might mean the clflush is indeed not available, by either hardware or software switch? I believe some security mitigations disable clflush. Linux kernel, for example, has "noclflush" option to do this. Ignoring the cpu bit and emitting clflush anyway might circumvent that mitigation then? -Aleksey From adinn at redhat.com Wed Jul 31 13:08:06 2019 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 31 Jul 2019 14:08:06 +0100 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> <892f3b0b-55f1-872d-15f4-5af907fa8437@redhat.com> <8f72d3b5-3a01-a7de-3b09-35571266a87d@redhat.com> Message-ID: <4fd3cdac-f72a-30ca-7a53-1d465644d973@redhat.com> On 31/07/2019 13:01, Boris Ulasevich wrote: > I did a quick check of the change across our platforms. Arm32 and x86_64 > built successfully. But I see it fails due to minor issues on aarch64 > and x86_32 with webrev.09. > Can you please have a look at this? > >> src/hotspot/cpu/aarch64/aarch64.ad:2202:1: error: expected ?;? before > ?}? token >> src/hotspot/cpu/x86/macroAssembler_x86.cpp:9925: undefined reference > to `Assembler::clflush(Address)' Sure, will do. I'm surprised by the x86_32 result as I /thought/ I had pushed the very same change set to the submit repo and it came back with no errors: > Job: mach5-one-adinn-JDK-8224974-8-20190730-1325-4068436 > BuildId: 2019-07-30-1324012.adinn.source > No failed tests . . . Is x86_32 tested as part of a submit run? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From shade at redhat.com Wed Jul 31 13:10:45 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 31 Jul 2019 15:10:45 +0200 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <4fd3cdac-f72a-30ca-7a53-1d465644d973@redhat.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> <892f3b0b-55f1-872d-15f4-5af907fa8437@redhat.com> <8f72d3b5-3a01-a7de-3b09-35571266a87d@redhat.com> <4fd3cdac-f72a-30ca-7a53-1d465644d973@redhat.com> Message-ID: On 7/31/19 3:08 PM, Andrew Dinn wrote: > On 31/07/2019 13:01, Boris Ulasevich wrote: > I'm surprised by the x86_32 result as I /thought/ I had pushed the very > same change set to the submit repo and it came back with no errors: > >> Job: mach5-one-adinn-JDK-8224974-8-20190730-1325-4068436 >> BuildId: 2019-07-30-1324012.adinn.source >> No failed tests > . . . > > Is x86_32 tested as part of a submit run? It does not. jdk-submit tests quite a limited number of configurations, mostly x86_64. -Aleksey From adinn at redhat.com Wed Jul 31 14:46:42 2019 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 31 Jul 2019 15:46:42 +0100 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> <892f3b0b-55f1-872d-15f4-5af907fa8437@redhat.com> <8f72d3b5-3a01-a7de-3b09-35571266a87d@redhat.com> <671c7ba1-9597-a990-190b-145d9cb5349e@redhat.com> <81098801-31b2-e3a8-5c25-043ab47c80bc@redhat.com> <27916ded-74e2-94d8-891c-95d87730b69d@redhat.com> Message-ID: <3cfda7cd-3517-d156-304f-5b8d7876b1cd@redhat.com> On 31/07/2019 12:40, Aleksey Shipilev wrote: > On 7/31/19 1:29 PM, Andrew Dinn wrote: >> I have an update regarding the change to the computation of the >> CPU_FLUSH flag. After posting the new webrev I built a debug version >> with the change that tests the clflush bit on x86_64. It crashed when >> the assert is reached in VM_Version::supports_cpuflush: >> >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (src/hotspot/cpu/x86/vm_version_x86.hpp:978), >> pid=29597, tid=29602 >> # assert((_features & ((uint64_t)(0x20000000000ULL))) != 0) failed: >> clflush should be available >> >> So, it seems the clflush bit is not set on my x86_64 box even though I >> am able to execute clflush quite happily. >> >> "Toto, it looks like we are no longer in Antarctica." >> >> So, I will revert this change (in the next webrev). > > But wait, that might mean the clflush is indeed not available, by either hardware or software > switch? I believe some security mitigations disable clflush. Linux kernel, for example, has > "noclflush" option to do this. Ignoring the cpu bit and emitting clflush anyway might circumvent > that mitigation then? Ok, so investigating further I have found out what is wrong here. Significanlty, I get this result when I look at /proc/cpuinfo. [root at localhost ~]# cat /proc/cpuinfo | grep flush | head -1 flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 *clflush* dts acpi mmx fxsr sse sse2 ... So, the hardware does flag support for clflush. In which case why does the assert in supports_clflush fail? Well, the failure happened during the build process so I didn't (couldn't) debug it. I disabled the assert in supports_cpuflush() in order to allow the build to complete and then ran up the resulting JVM inside gdb to check what was going on. The problem is that with my patch supports_cpuflush() is called from Assembler::clflush() and the latter is called from icache_x86.cpp very early during bootstrap (I think this is neded to flush the flush routine used to flush the code cache). Anyway, the call happens so early that it precedes the call to VM_Version::get_processor_features which sets up the _features mask tested by the assert. So, I think the only option is to remove the assert from the x86_64 version of supports_cpuflush from Assemmbler::cpu_flush and instead add an assert in get_processor_features that CPU_FLUSH is set on x86_64. However, by that stage on x86_64 we will already have called clflush and, in the case where the assert might actually fail, we may not reach there because we have tripped up with an illegal instruction error. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From shade at redhat.com Wed Jul 31 15:46:18 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 31 Jul 2019 17:46:18 +0200 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: <3cfda7cd-3517-d156-304f-5b8d7876b1cd@redhat.com> References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> <892f3b0b-55f1-872d-15f4-5af907fa8437@redhat.com> <8f72d3b5-3a01-a7de-3b09-35571266a87d@redhat.com> <671c7ba1-9597-a990-190b-145d9cb5349e@redhat.com> <81098801-31b2-e3a8-5c25-043ab47c80bc@redhat.com> <27916ded-74e2-94d8-891c-95d87730b69d@redhat.com> <3cfda7cd-3517-d156-304f-5b8d7876b1cd@redhat.com> Message-ID: On 7/31/19 4:46 PM, Andrew Dinn wrote: > Well, the failure happened during the build process so I didn't > (couldn't) debug it. I disabled the assert in supports_cpuflush() in > order to allow the build to complete and then ran up the resulting JVM > inside gdb to check what was going on. The problem is that with my patch > supports_cpuflush() is called from Assembler::clflush() and the latter > is called from icache_x86.cpp very early during bootstrap (I think this > is neded to flush the flush routine used to flush the code cache). > Anyway, the call happens so early that it precedes the call to > VM_Version::get_processor_features which sets up the _features mask > tested by the assert. I believe you can untie this bootstrapping circularity by relaxing the assert with Universe::is_fully_unitialized(). It still gives us window to fail with SIGILL if the stub is called early during bootstrap, but that would be something to fix *if* we ever find ourselves there. -Aleksey From adinn at redhat.com Wed Jul 31 16:22:51 2019 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 31 Jul 2019 17:22:51 +0100 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> <892f3b0b-55f1-872d-15f4-5af907fa8437@redhat.com> <8f72d3b5-3a01-a7de-3b09-35571266a87d@redhat.com> <671c7ba1-9597-a990-190b-145d9cb5349e@redhat.com> <81098801-31b2-e3a8-5c25-043ab47c80bc@redhat.com> <27916ded-74e2-94d8-891c-95d87730b69d@redhat.com> <3cfda7cd-3517-d156-304f-5b8d7876b1cd@redhat.com> Message-ID: On 31/07/2019 16:46, Aleksey Shipilev wrote: > On 7/31/19 4:46 PM, Andrew Dinn wrote: >> Well, the failure happened during the build process so I didn't >> (couldn't) debug it. I disabled the assert in supports_cpuflush() in >> order to allow the build to complete and then ran up the resulting JVM >> inside gdb to check what was going on. The problem is that with my patch >> supports_cpuflush() is called from Assembler::clflush() and the latter >> is called from icache_x86.cpp very early during bootstrap (I think this >> is neded to flush the flush routine used to flush the code cache). >> Anyway, the call happens so early that it precedes the call to >> VM_Version::get_processor_features which sets up the _features mask >> tested by the assert. > > I believe you can untie this bootstrapping circularity by relaxing the assert with > Universe::is_fully_unitialized(). It still gives us window to fail with SIGILL if the stub is called > early during bootstrap, but that would be something to fix *if* we ever find ourselves there. Yes indeed, that seems like by far the cleanest solution. The only other alternative is to move the call to VM_Version::initalize earlier in the Universe bootstrap sequence and I doubt anyone wants to risk that. So, now I have #ifdef _LP64 static bool supports_clflush() { // clflush should always be available on x86_64 // if not we are in real trouble because we rely on it // to flush the code cache. // Unfortunately, Assembler::clflush is currently called as part // of generation of the code cache flush routine. This happens // under Universe::init before the processor features are set // up. Assembler::flush calls this routine to check that clflush // is allowed. So, we give the caller a free pass if Universe init // is still in progress. assert ((!Universe::is_fully_initialized() || (_features & CPU_FLUSH) != 0), "clflush should be available"); return true; } . . . which seems to work ok. I'll post a new webrev when I have handled Brian's comments and also any other feedback you may still have on my last reply. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From boris.ulasevich at bell-sw.com Wed Jul 31 12:01:38 2019 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Wed, 31 Jul 2019 15:01:38 +0300 Subject: RFR: 8224974: Implement JEP 352 In-Reply-To: References: <80da32b2-7acb-7b94-b82c-5dcd5cf95539@redhat.com> <0a41e686-0931-5054-b314-2c015fbae62a@redhat.com> <36326F5E-12CD-487A-8FE2-1049631FE908@oracle.com> <8B1A8EDC-F9D7-4085-A34F-69100DBD7D5C@oracle.com> <5c78b5d7-dc9e-fbbd-41a9-5139ed6ee32c@redhat.com> <86d000f3-9eca-6089-5f7e-5698444d99ce@oracle.com> <7fe8d17d-6170-fcc9-b87a-eccfda2bb546@redhat.com> <7b39f68d-5698-4079-425c-c86ec161e361@oracle.com> <72810832-eb88-3418-f336-b95af95d9dcc@redhat.com> <20c8bbcb-2cd3-77af-cd40-29f7bd752166@oracle.com> <68566847-de80-82af-a928-d30c75f2b1b2@redhat.com> <892f3b0b-55f1-872d-15f4-5af907fa8437@redhat.com> <8f72d3b5-3a01-a7de-3b09-35571266a87d@redhat.com> Message-ID: Hi Andrew, I did a quick check of the change across our platforms. Arm32 and x86_64 built successfully. But I see it fails due to minor issues on aarch64 and x86_32 with webrev.09. Can you please have a look at this? > src/hotspot/cpu/aarch64/aarch64.ad:2202:1: error: expected ?;? before ?}? token > src/hotspot/cpu/x86/macroAssembler_x86.cpp:9925: undefined reference to `Assembler::clflush(Address)' thanks, Boris On 30.07.2019 18:04, Andrew Dinn wrote: > JEP 352 has now been targeted for inclusion in JDK14. The latest webrev > for the implementation JIRA has been rebased to apply to the current > tree. Is it now ok to push this change set? > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8224974 > webrev: http://cr.openjdk.java.net/~adinn/8224974/webrev.09 > > n.b. by way of sanity test I pushed this to the submit repo and it came > back with no failed tests. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > From mandy.chung at oracle.com Wed Jul 31 20:59:23 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 31 Jul 2019 13:59:23 -0700 Subject: Review Request: JDK-8209005: Lookup.unreflectSpecial fails for default methods when Lookup.findSpecial works In-Reply-To: References: <8a3743fc-5ac3-0f79-2ee5-9814de6444e7@oracle.com> <6c13f13b-e08f-af91-f583-8acf48ee7182@oracle.com> <4b7cae81-2066-1b66-9f44-085b29bd5215@oracle.com> Message-ID: <94fc96c4-84bb-7425-25c2-f55f3c3a844b@oracle.com> Hi Peter, Daniel On 7/31/19 1:44 AM, Peter Levart wrote: > > > On 7/31/19 9:59 AM, Peter Levart wrote: >> Hi, >> >> I think Daniel is talking about the "dispatch" semantics of >> unreflectSpecial here, right Daniel? >> Thanks for clarifying this. >> The findSpecial / unreflectSpecial is a MethodHandle equivalent for >> bytecode instruction invokespecial (sans actual invoking). >> invokespecial is typically used for implementing the >> super.method(args) Java invocations. In that case, the superclass >> method is targeted - this is not a virtual method dispatch like >> aMethod.invoke(this, arg*) - i.e. the reflective invocation is always >> a virtual invocation (for non-private methods). Likewise findSpecial >> and unreflectSpecial produce a MethodHandle that dispatches to the >> method in the superclass (the aMethod.getDeclatingClass() in case of >> unreflectSpecial) regardless of whether that method is overridden in >> the subclass or not. >> > > Expanding on this a little. The javadocs of MethodHandles.Lookup > starts talking about the Lookup factory methods methods and their > equivalence to bytecode instructions, but then present the equivalence > between find* and Java source code (which is OK given that translation > to bytecode is known) followed by equivalence between unreflect* and > reflective invocations. Public reflection API does not implement the > equivalent behavior to unreflectSpecial. So perhaps, this line only > could present the equivalence in terms of Java code like findSpecial > does with a comment stating that there's no equivalence with > reflective invocation API. For example: > > ???? * > ???? *???? lookup expression > ???? *???? member > ???? *???? bytecode / reflection behavior > > Added "/ reflection" above; and: > I prefer to keep the original header and revisit this separately. It intends to talk about bytecode behavior and perhaps handle this unreflect* exception differently. > ???? * > ???? *???? {@link > java.lang.invoke.MethodHandles.Lookup#unreflectSpecial > lookup.unreflectSpecial(aMethod,this.class)} > ???? *???? {@code T m(A*);}{@code (T) super.m(arg*); // > no equivalent reflective invocation} > ???? * > This is correct when this class is a subclass of C.?? A slight clarification to indicate that aMethod's declaring class is C might help.? I also fixed another typo: --- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java @@ -334,7 +334,7 @@ * * * {@link java.lang.invoke.MethodHandles.Lookup#findStaticGetter lookup.findStaticGetter(C.class,"f",FT.class)} - * {@code static}
    {@code FT f;}{@code (T) C.f;} + * {@code static}
    {@code FT f;}{@code (FT) C.f;} * * * {@link java.lang.invoke.MethodHandles.Lookup#findSetter lookup.findSetter(C.class,"f",FT.class)} @@ -377,8 +377,8 @@ * {@code C(A*);}{@code (C) aConstructor.newInstance(arg*);} * * - * {@link java.lang.invoke.MethodHandles.Lookup#unreflect lookup.unreflect(aMethod)} - * ({@code static})?
    {@code T m(A*);}{@code (T) aMethod.invoke(thisOrNull, arg*);} + * {@link java.lang.invoke.MethodHandles.Lookup#unreflectSpecial lookup.unreflectSpecial(aMethod,this.class)} + * {@code T m(A*);}{@code (T) super.m(arg*);} * * * {@link java.lang.invoke.MethodHandles.Lookup#findClass lookup.findClass("C")} @@ -403,7 +403,7 @@ * stands for a null reference if the accessed method or field is static, * and {@code this} otherwise. * The names {@code aMethod}, {@code aField}, and {@code aConstructor} stand - * for reflective objects corresponding to the given members. + * for reflective objects corresponding to the given members declared in type {@code C}. *

    * The bytecode behavior for a {@code findClass} operation is a load of a constant class, * as if by {@code ldc CONSTANT_Class}. Thanks. Mandy