RFR 8233731: repeated typo "fro" for "for"

Hey Guys, Please review the correction of a typo from 'fro' to 'for' in java.util.Arrays class. Thanks, Kiran *Patch :* @@ -2599,7 +2599,7 @@   *   first array to be tested   * @param aToIndex the index (exclusive) of the last element in the   *

Re: RFR 8233731: repeated typo "fro" for "for"

Hi Kiran, Looks good to me. best regards, -- daniel On 13/11/2019 10:13, Kiran Ravikumar wrote: Hey Guys, Please review the correction of a typo from 'fro' to 'for' in java.util.Arrays class. Thanks, Kiran *Patch :* @@ -2599,7 +2599,7 @@   *   first array to be

Re: RFR 8233920: MethodHandles::tryFinally generates illegal bytecode for long/double return types

http://cr.openjdk.java.net/~jvernee/8233920/webrev.03/ I like how the patch shapes. Looks good. In addition, you can encapsulate the following code into a helper method: if (isNonVoid) { - mv.visitInsn(Opcodes.POP); + if (isDoubleWord) { +

Re: [JDK 14] RFR 8234079: ZipFileInputStreamSkipTest.java runs zero test

Looks fine > On Nov 13, 2019, at 6:11 AM, Amy Lu wrote: > > java/util/zip/ZipFile/ZipFileInputStreamSkipTest.java > > Test runs zero test. Please review the fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8234079 > webrev: http://cr.openjdk.java.net/~amlu/8234079/webrev.00 > > Thanks,

[JDK 14] RFR 8234079: ZipFileInputStreamSkipTest.java runs zero test

java/util/zip/ZipFile/ZipFileInputStreamSkipTest.java Test runs zero test. Please review the fix. bug: https://bugs.openjdk.java.net/browse/JDK-8234079 webrev: http://cr.openjdk.java.net/~amlu/8234079/webrev.00 Thanks, Amy --- old/test/jdk/java/util/zip/ZipFile/ZipFileInputStreamSkipTest.java

Re: RFR 8233920: MethodHandles::tryFinally generates illegal bytecode for long/double return types

http://cr.openjdk.java.net/~jvernee/8233920/webrev.04/ Looks good. Best regards, Vladimir Ivanov On 13/11/2019 11:28, Vladimir Ivanov wrote: http://cr.openjdk.java.net/~jvernee/8233920/webrev.03/ I like how the patch shapes. Looks good. In addition, you can encapsulate the following

RFR 8233272 : The Class.forName specification should be updated to match the long-standing implementation with respect to class linking

Hi, Recently, the 2-arg and 3-arg Class.forName() methods were updated[1] to perform class linking, per the specification. However this change had to be reverted[2]. Instead, let's clarify the Class.forName() spec not to guarantee linking (outside the case of also performing

RFR (M) 8223261 "JDK-8189208 followup - remove JDK_GetVersionInfo0 and the supporting code"

Hi all, Please review this cleanup, where we remove JDK_GetVersionInfo0 and related code, since we can get build versions directly from within the VM itself: I'm including core-libs and awt in this review because the proposed fix touches their corresponding files. bug:

Re: RFR (M) 8223261 "JDK-8189208 followup - remove JDK_GetVersionInfo0 and the supporting code"

On 2019-11-13 19:50, gerard ziemski wrote: webrev: http://cr.openjdk.java.net/~gziemski/8223261_rev1 Nice cleanup! Looks good to me. /Claes

Re: RFR(XS): 8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater()

Hi Volker, Thank you for doing this. As Christoph mentioned, you can just do Path.of() and create the file in the work directory for the test. If possible, I would use TestNG as that is consistent with the vast majority of the tests. I also believe the rest of the comments below are worth

RE: RFR(XS): 8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater()

Hi Volker, good catch in ZipFileSystem  The fix is the right thing to do. I have a few remarks to the test, though: Line 52, initialization of the File object: I think you should just do Path zipFile = Paths.get("file.zip"); When the test is run in the jtreg framework, it's running in its

RFR: 8234089: (zipfs) Remove classes JarFileSystemProvider and JarFileSystem

Hi, can I please get reviews for this cleanup change in zipfs. Bug: https://bugs.openjdk.java.net/browse/JDK-8234089 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234089.0/ I figured that JarFileSystemProvider is completely obsolete (please correct me if I'm wrong) and the reasons for

Re: RFR 8233920: MethodHandles::tryFinally generates illegal bytecode for long/double return types

On Nov 13, 2019, at 2:28 AM, Vladimir Ivanov mailto:vladimir.x.iva...@oracle.com>> wrote: > >private void emitPopInsn(BasicType type) { > mv.visitVarInsn(popInsnOpcode(type)); >} > Thanks for suggesting that Vladimir. That indeed is how the existing code is organized.

Re: RFR JDK-8233527: Update Lookup::hasPrivateAccess and Lookup::defineClass spec w.r.t. full power lookup

On 11/13/19 6:10 AM, Johannes Kuhn wrote: On 11.11.2019 22:23, Mandy Chung wrote: This is a follow-up of JDK-8226916. Lookup::hasPrivateAccess intends to test if this lookup is a full-power lookup; that is created by the original caller class calling MethodHandles::lookup. The current

Re: RFR JDK-8233527: Update Lookup::hasPrivateAccess and Lookup::defineClass spec w.r.t. full power lookup

On 11.11.2019 22:23, Mandy Chung wrote: This is a follow-up of JDK-8226916. Lookup::hasPrivateAccess intends to test if this lookup is a full-power lookup; that is created by the original caller class calling MethodHandles::lookup. The current specification for Lookup::hasPrivateAccess returns

RFR(XS): 8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater()

Hi, can I please get a review for this trivial fix of an old copy-and-paste error: http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011/ https://bugs.openjdk.java.net/browse/JDK-8234011 ZipFileSystem caches MAX_FLATER (currently 20) Inflater/Deflater objects. However the logic for reusing

Re: RFR 8233920: MethodHandles::tryFinally generates illegal bytecode for long/double return types

Hi Vladimir, Thanks for the suggestion, I think it sounds good. Here is the updated webrev: http://cr.openjdk.java.net/~jvernee/8233920/webrev.04/ Thanks, Jorn On 13/11/2019 11:28, Vladimir Ivanov wrote: http://cr.openjdk.java.net/~jvernee/8233920/webrev.03/ I like how the patch

Jpackage EA build available

The next EA build of JPackage is available at https://jdk.java.net/jpackage/ Build 14-jpackage+1-70 (2019/11/12) contains the following changes (since Build Build 14-jpackage+1-64 on 2019/10/28): JDK-8233594 create a new option --bind-services to pass on to jlink JDK-8233636 Make

Re: RFR 8233920: MethodHandles::tryFinally generates illegal bytecode for long/double return types

On 2019-11-13 20:05, John Rose wrote: On Nov 13, 2019, at 2:28 AM, Vladimir Ivanov mailto:vladimir.x.iva...@oracle.com>> wrote:    private void emitPopInsn(BasicType type) {  mv.visitVarInsn(popInsnOpcode(type));    } Thanks for suggesting that Vladimir.  That indeed is how the

Re: RFR (M) 8223261 "JDK-8189208 followup - remove JDK_GetVersionInfo0 and the supporting code"

On 11/13/19 10:50 AM, gerard ziemski wrote: Hi all, Please review this cleanup, where we remove JDK_GetVersionInfo0 and related code, since we can get build versions directly from within the VM itself: I'm including core-libs and awt in this review because the proposed fix touches their

Re: RFR JDK-8233527: Update Lookup::hasPrivateAccess and Lookup::defineClass spec w.r.t. full power lookup

On 13.11.2019 20:07, Mandy Chung wrote: Thank you for all those changes. It fixed two of my reported bugs (JDK-8209005, JDK-8209078). Thanks for filing these good reports.   JDK-8173978 resolved the issues reported by JDK-8209005 and JDK-8209078. I'm happy I could help. It also makes my

Re: RFR 8233920: MethodHandles::tryFinally generates illegal bytecode for long/double return types

On Nov 13, 2019, at 11:24 AM, Claes Redestad wrote: > >> Thanks for suggesting that Vladimir. That indeed is how the existing code >> is organized. > > Yes, not very startup friendly... ;-) No, but it’s maintainer friendly. We can walk and chew gum at the same time. Is it time to think

RE: RFR (M) 8223261 "JDK-8189208 followup - remove JDK_GetVersionInfo0 and the supporting code"

Hi Gerard, generally it looks like a nice cleanup. I've got a patch prepared though, which I was planning on posting tomorrow. It is about cleanup for the canonicalize function in libjava. I wanted to use jdk_util.h for the function prototype. I had not yet filed a bug but here is what I

Re: RFR JDK-8233527: Update Lookup::hasPrivateAccess and Lookup::defineClass spec w.r.t. full power lookup

On 11/13/19 11:45 AM, Johannes Kuhn wrote: This is a good idea, because full privilege access is a new concept, and should be mentioned at the places where it is used. To clarify, "full privilege access" (aka "full power") is not really a new concept. Module access was introduced in

Re: JDK 14 RFR of JDK-8233940: Preview API tests for String methods should use ${jdk.version} as -source arg

+1 On 11/12/2019 09:50 AM, Jan Lahoda wrote: Looks good to me. Jan On 12. 11. 19 7:13, Joe Darcy wrote: Hello, To remove the need to modify tests when the JDK version is updated, the tests of the preview API in String should use "${jdk.version}" as an argument to -source rather than a

Re: RFR 8233920: MethodHandles::tryFinally generates illegal bytecode for long/double return types

On 2019-11-13 21:04, John Rose wrote: On Nov 13, 2019, at 11:24 AM, Claes Redestad > wrote: Thanks for suggesting that Vladimir.  That indeed is how the existing code is organized. Yes, not very startup friendly... ;-) No, but it’s maintainer friendly.  

Re: RFR 8233920: MethodHandles::tryFinally generates illegal bytecode for long/double return types

On Nov 13, 2019, at 12:39 PM, Claes Redestad wrote: > Similar to other promising candidates like constant folding I think it > opens up some more general questions about observability. For example: > do we retain the original bytecode and mappings everything back to it > so that a debugger would

Re: RFR 8233920: MethodHandles::tryFinally generates illegal bytecode for long/double return types

On 2019-11-13 21:49, John Rose wrote: On Nov 13, 2019, at 12:39 PM, Claes Redestad wrote: Similar to other promising candidates like constant folding I think it opens up some more general questions about observability. For example: do we retain the original bytecode and mappings everything

Re: RFR (M) 8223261 "JDK-8189208 followup - remove JDK_GetVersionInfo0 and the supporting code"

Hi Gerard, On 14/11/2019 6:05 am, Langer, Christoph wrote: Hi Gerard, generally it looks like a nice cleanup. I've got a patch prepared though, which I was planning on posting tomorrow. It is about cleanup for the canonicalize function in libjava. I wanted to use jdk_util.h for the function

Re: RFR (M) 8223261 "JDK-8189208 followup - remove JDK_GetVersionInfo0 and the supporting code"

Looks fine. On 11/13/19 10:50 am, gerard ziemski wrote: Hi all, Please review this cleanup, where we remove JDK_GetVersionInfo0 and related code, since we can get build versions directly from within the VM itself: I'm including core-libs and awt in this review because the proposed fix

Re: [PATCH] Enhancement proposal for usage of Method::getParameterTypes

Hello, thanks for quick review! Tagir Valeev from JetBrains comes with suggestion to improve compiler optimizations here https://youtrack.jetbrains.com/issue/IDEA-226474. Rationale: in fact the cloned array could be a subject of allocation erasure as any property dereferenced from it can be

RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Please review  changes for [1] which is the implementation bug for JEP-343. The webrev at [2] is the total cumulative webrev of changes for the jpackage tool, currently in the JDK-8200758-branch branch of the open sandbox repository. The webrev at [3] shows the changes since EA-06 (Build

Re: RFR JDK-8233527: Update Lookup::hasPrivateAccess and Lookup::defineClass spec w.r.t. full power lookup

On 11/13/19 11:45 AM, Johannes Kuhn wrote: The two bullets about the caller lookup object must have MODULE and PRIVATE are important explanation for it to require such access. Maybe I can add a bullet to say "The caller lookup object must have full privilege access" and then move those two