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

John suggests to deprecate Lookup::hasPrivateAccess and introduce a correctly named method `hasFullPrivilegeAccess`.    Also clarify `Lookup::findClass` javadoc that it's equivalent to `ldc` instruction. Here is the updated webrev and specdiff:

Re: [14] RFR: 8232860: Error formatting integer values with MessageFormat.format() using HOST provider

+1, Thanks On 11/12/19 4:47 PM, naoto.s...@oracle.com wrote: Hi Roger, Thank you for your review. The method description was modified per your suggestion: https://cr.openjdk.java.net/~naoto/8232860/webrev.01/ Naoto On 11/12/19 1:16 PM, Roger Riggs wrote: Hi Naoto, Looks fine. (You

Re: [14] RFR: 8232860: Error formatting integer values with MessageFormat.format() using HOST provider

Hi Roger, Thank you for your review. The method description was modified per your suggestion: https://cr.openjdk.java.net/~naoto/8232860/webrev.01/ Naoto On 11/12/19 1:16 PM, Roger Riggs wrote: Hi Naoto, Looks fine. (You might make the comment clear that makeIntegerFormatter modifies its

Re: [14] RFR: 8232860: Error formatting integer values with MessageFormat.format() using HOST provider

Hi Naoto, Looks fine. (You might make the comment clear that makeIntegerFormatter modifies its argument and returns it. ) Thanks, Roger On 11/12/19 12:10 PM, naoto.s...@oracle.com wrote: Hi, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8232860

Re: Jar manifest and EOF character (code 26)

I have created a CSR, https://bugs.openjdk.java.net/browse/JDK-8233722 , to address the EOF issue. The CSR has been approved. Unless I hear any last minute reservations, I will move forward with the update to the JAR spec. Best Lance > On

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

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

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

+1 > On Nov 12, 2019, at 2:13 AM, Joe Darcy wrote: > > Hello, > > To remove the need to modify tests when the JDK version is updated, the tests > of the preview API in String should use "${jdk.version}" as an argument to > -source rather than a fixed version string: > > JDK-8233940:

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

On 11/12/19 4:56 AM, Alan Bateman wrote: On 11/11/2019 21:23, Mandy Chung wrote: This is a follow-up of JDK-8226916. Lookup::hasPrivateAccess intends to test if this lookup is a full-power lookup; that is created by the original caller class calling MethodHandles::lookup. The current

[14] RFR: 8232860: Error formatting integer values with MessageFormat.format() using HOST provider

Hi, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8232860 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8232860/webrev.00/ Although this was reported for German locale, it is reproducible on any locale. The root cause of

Re: Jpackage bug: Failed to find runtime/bin/jli.dll

Tobias: I have tried to reproduce what you have done and can't reproduce any of the problems you describe. Can you supply which jpackage build you are using and exactly what steps you use to get these problems. /Andy On 11/8/2019 6:38 AM, Tobias Diez wrote: Hello everybody, I used the

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

Hi, since you've already done the work I guess I'm ok with it. :-) While I don't expect there to be a noticeable performance difference, it seems prudent to investigate and add a simple microbenchmark. This can be done as a future RFE. /Claes On 2019-11-12 17:05, Jorn Vernee wrote: Hi Rémi,

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

Hi Rémi, Claes, Thanks for the suggestion, Rémi. I avoided using a store/load for all types since I didn't want to alter the existing code shape. But, using store/load for all types simplifies the generator code & javadoc, so it would be nice to do that I think. However, this might have other

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

Interesting, and you might be right. However I think it'd be better to file a follow-up to examine this (pre-existing) behavior than to expand the scope of this bug fix. /Claes On 2019-11-12 16:08, Remi Forax wrote: Hi Jorn, Claes, Is it not better to always store in a local variable, like

Re: RFR: JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview)

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

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

Hi Jorn, Claes, Is it not better to always store in a local variable, like javac does, instead of doing the double SWAP if there is a return value of size 1 ? Rémi - Mail original - > De: "Jorn Vernee" > À: "Claes Redestad" , "core-libs-dev" > > Envoyé: Mardi 12 Novembre 2019

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

Hi Claes, Thanks for the comments! Updated webrev: http://cr.openjdk.java.net/~jvernee/8233920/webrev.02/ Also, thanks for sponsoring. Jorn On 12/11/2019 15:30, Claes Redestad wrote: Hi Jorn, good catch! Some minor stylistic concerns: "* = depends on whether the return type is a category

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

Hi Jorn, good catch! Some minor stylistic concerns: "* = depends on whether the return type is a category 2 type, which takes up 2 stack slots." While long/double are known to use two stack slots, "category 2 type" isn't used much outside the specification. I'd either simplify to "* =

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

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

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

Hi, Please review the following patch that fixes handling of long/double returns for the tryFinally MethodHandle combinator. Bug: https://bugs.openjdk.java.net/browse/JDK-8233920 Webrev: http://cr.openjdk.java.net/~jvernee/8233920/webrev.01/ (Testing=tier1) FWIW, I also added some missing

Re: [JDK 14] RFR 8233961: Problem list tools/jlink/JLinkReproducibleTest.java for windows-all

On 12/11/2019 06:04, Amy Lu wrote: tools/jlink/JLinkReproducibleTest.java This test has been seen to fail frequently due to JDK-8217166. Please review the patch to problem list it  until issue is addressed. I see JDK-8217166 has been bumped to a P2 - good, as this test is important to check