Integrated: 8252919: JDK built with --enable-cds=no fails with NoClassDefFoundError

On Wed, 9 Sep 2020 19:38:38 GMT, Mandy Chung wrote: > `jlink --generate-jli-classes` plugin should retain the original holder > classes if the default_jli_trace.txt > file does not exist. > > Before JDK-8252725, `JavaLangInvokeAccess::generateXXXHolderClassesBytes` > m

RFR: 8252919: JDK built with --enable-cds=no fails with NoClassDefFoundError

`jlink --generate-jli-classes` plugin should retain the original holder classes if the default_jli_trace.txt file does not exist. Before JDK-8252725, `JavaLangInvokeAccess::generateXXXHolderClassesBytes` methods are invoked unconditionally and therefore the holder classes are "regenerated" when

Re: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode

On Wed, 9 Sep 2020 08:18:11 GMT, Gilles Duboscq wrote: > [JDK-8232806](https://bugs.openjdk.java.net/browse/JDK-8232806) introduced the > jdk.internal.lambda.disableEagerInitialization system property to be able to > disable eager initialization of lambda > classes. This was necessary to

Re: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode

On Wed, 9 Sep 2020 12:19:04 GMT, Jan Lahoda wrote: >> [JDK-8232806](https://bugs.openjdk.java.net/browse/JDK-8232806) introduced >> the >> jdk.internal.lambda.disableEagerInitialization system property to be able to >> disable eager initialization of lambda >> classes. This was necessary to

Re: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode

On Wed, 9 Sep 2020 08:18:11 GMT, Gilles Duboscq wrote: > [JDK-8232806](https://bugs.openjdk.java.net/browse/JDK-8232806) introduced the > jdk.internal.lambda.disableEagerInitialization system property to be able to > disable eager initialization of lambda > classes. This was necessary to

Re: JDK 15 hidden classes & stack trace visibility

ecuted scoring formula is part of the filename attribute in class file. As this is missing, test fails.  Uwe Am September 7, 2020 4:44:18 PM UTC schrieb Mandy Chung : Hi Uwe, It's a future enhancement to allow a class/method to request filtering from stack trace:

Re: JDK 15 hidden classes & stack trace visibility

Hi Uwe, It's a future enhancement to allow a class/method to request filtering from stack trace:     https://bugs.openjdk.java.net/browse/JDK-8212620 This RFE should also take hidden classes into account. Mandy On 9/5/20 4:55 AM, Uwe Schindler wrote: Hi, I am doing a mockup for

Re: RFR: 8252725: Refactor jlink GenerateJLIClassesPlugin code

On 9/3/20 8:36 AM, Yumin Qi wrote: Hi, Please review bug: https://bugs.openjdk.java.net/browse/JDK-8252725 webrev: http://cr.openjdk.java.net/~minqi/2020/8252725/webrev-01/ Looks good to me.   Sundar should also review it. A few things to mention compared to the proposed patch from

Re: RFR: 8188055: (ref) Add Reference.refersTo predicate

On 8/25/20 10:11 PM, Kim Barrett wrote: Finally getting back to this after some internal discussion that dragged along because folks have been busy. On Apr 8, 2020, at 12:05 PM, Gil Tene wrote: Lifting out of response from the JIRA issue: I always worry when proposing a change to an

Re: RFR: JDK-8242451 : ensure semantics of non-capturing lambdas are preserved independent of execution mode

On 8/26/20 10:16 AM, Gilles Duboscq wrote: Hi Mandy, Thanks for your review. I have added a test as you suggested and switched to `.descriptorString()`. https://cr.openjdk.java.net/~gdub/8242451/webrev.2/ Looks fine.    This test is a javac test.  I'm including compiler-dev if anyone

Re: RFR: JDK-8242451 : ensure semantics of non-capturing lambdas are preserved independent of execution mode

On 8/25/20 3:16 AM, Gilles Duboscq wrote: Since this patch caches a singleton instance in the generated class, it could apply to the eager initialization case as well and replace the current use of core reflection to new an instance except that the target of the returning callsite would

Re: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive

On 8/24/20 3:53 PM, Ioi Lam wrote: : However, I suspect most people won't do this, because the benefit is relatively small. Also, jlink doesn't support classpath apps, so you would need to figure out what to use for "--add-modules". In the worst case, the custom JDK would be over 100MB

Re: RFR 8251203: Fix "no comment" warnings in java.base/java.lang and java/io

On 8/21/20 8:09 AM, Roger Riggs wrote: Please review the addition of comments to classes and fields to resolve javadoc "no comment" warnings in the java.lang and java.io packages. The comments are derived from the existing behavior and context. Webrev:   

Re: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive

On 8/19/20 10:14 PM, Yumin Qi wrote: HI, Mandy   Thanks for the review, I took one day off yesterday so just got a detail look of your reply. On 8/19/20 1:30 PM, Mandy Chung wrote: On 8/17/20 12:37 PM, Yumin Qi wrote: Hi, Ioi   Thanks for review/suggestion. I have updated the webrev

Re: Optimize sun.invoke.util.BytecodeDescriptor.unparse

On 8/20/20 11:01 AM, Christoph Dreis wrote: === PATCH === --- a/src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java Thu Aug 13 09:33:28 2020 -0700 +++ b/src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java Thu Aug 20 19:44:57

Re: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive

On 8/17/20 12:37 PM, Yumin Qi wrote: Hi, Ioi   Thanks for review/suggestion. I have updated the webrev at the following link: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-02/ This patch leverages the TRACE_RESOLVE output and passes the trace output to VM.  VM then calls

Re: Fix for Javadoc errors in java.base

Looks fine. Thanks Mandy On 8/18/20 10:02 AM, Julia Boes wrote: Hi, The two changes below still need to be reviewed. Any takers? Cheers, Julia --- old/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java2020-08-14 23:55:41.953638446 +0530 +++

Re: RFR(L) 8244778 Archive full module graph in CDS

On 8/12/20 3:06 PM, Ioi Lam wrote: Hi Lois, Thanks for the comments. I have an updated webrev http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v02/ http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v02.delta/ This is very good work.  

Re: SoftCleanable and WeakCleanable

It's a fine idea to remove these 2 classes and resurrect them when it finds a need for it.  I will file a JBS issue. Mandy On 8/15/20 2:34 AM, Peter Levart wrote: Hi, You are right. For public Cleanable API, only the PhantomCleanable is used currently. It is subclassed by

Re: 8251160: Fix "no comment" warnings in java.logging

On 8/14/20 2:17 AM, Daniel Fuchs wrote: new webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8251160/webrev.01/index.html +1 CSR updated as well: https://bugs.openjdk.java.net/browse/JDK-8251534 Reviewed. Mandy

Re: 8251160: Fix "no comment" warnings in java.logging

On 8/13/20 5:00 AM, Daniel Fuchs wrote: Hi, Please find below a doc-only fix for: 8251160: Fix "no comment" warnings in java.logging https://bugs.openjdk.java.net/browse/JDK-8251160 CSR: https://bugs.openjdk.java.net/browse/JDK-8251534 webrev:

Re: Review Request JDK-8244090: public lookup should find public members of public exported types

/webrevs/8244090/webrev.01/index.html Thanks Mandy On 6/18/20 2:12 PM, Mandy Chung wrote: Prior to JDK-8173978, publicLookup().in(C.class) produces a Lookup object on C with PUBLIC access which can be used to look up unconditionally exported public types from the module of C. Such lookup can only

Re: RFR (JDK 15) 8251276: two jdeps files have extra whitespace in copyright header

Hi Sundar, Mark clarifies that either fix (fix the whitespace or backout) requires another RC build.  We should go with your proposed patch to fix the whitespace. I reviewed webrev.00. thanks Mandy On 8/7/20 10:28 AM, Mandy Chung wrote: Hi Sundar, Another alternative is to backout

Re: RFR (JDK 15) 8251276: two jdeps files have extra whitespace in copyright header

Hi Sundar, Another alternative is to backout the fix for JDK-8248299.   This needs approval. Mandy On 8/6/20 10:01 PM, sundararajan.athijegannat...@oracle.com wrote: Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8251276 Webrev:

Re: RFR (JDK 15) 8248299: two jdeps files miss copyright header

To clarify, I actually reviewed webrev.01. Mandy On 8/6/20 9:34 AM, Mandy Chung wrote: +1 Mandy On 8/6/20 8:03 AM, sundararajan.athijegannat...@oracle.com wrote: Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8248299 Webrev: http://cr.openjdk.java.net/~sundar/8248299/webrev

Re: RFR (JDK 15) 8248299: two jdeps files miss copyright header

+1 Mandy On 8/6/20 8:03 AM, sundararajan.athijegannat...@oracle.com wrote: Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8248299 Webrev: http://cr.openjdk.java.net/~sundar/8248299/webrev.00/ Thanks, -Sundar

Re: JDK 16 RFR of JDK-8250660: Clarify that WildcardType and AnnotatedWildcardType bounds methods return one

This looks good.  This will prepare for the future when Java supports multiple bounds. Mandy On 8/5/20 2:37 PM, Joe Darcy wrote: Hello, Addressing some feedback from off-list discussions with Mandy, I propose changing the API notes to:     @apiNote While to date a wildcard may have at

RFR JDK-8250929: Missing "classpath exception" in LambdaProxyClassArchive.java

Trivial update on license header. diff --git a/src/java.base/share/classes/java/lang/invoke/LambdaProxyClassArchive.java b/src/java.base/share/classes/java/lang/invoke/LambdaProxyClassArchive.java --- a/src/java.base/share/classes/java/lang/invoke/LambdaProxyClassArchive.java +++

Re: JDK 16 RFR of JDK-8250920: Increase @jls usage in core reflection

+1 Mandy On 8/4/20 7:42 PM, Joe Darcy wrote: Hello, While JDK-8250660: "Clarify that WildcardType and AnnotatedWildcardType bounds methods return one" is still under discussion, please review a change for     JDK-8250920: Increase @jls usage in core reflection    

RFR JDK-8250219: Proxy::newProxyInstance spec should specify the behavior if a given proxy interface is hidden

CSR: https://bugs.openjdk.java.net/browse/JDK-8250224 Webrev: http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8250219/webrev.00/ This patch updates the `|Proxy::newProxyInstance` |spec to explicitly list that the given interfaces must be non-hidden interfaces.|  Proxy::newProxyInstance|

Re: RFR: JDK-8247592: refactor test/jdk/tools/launcher/Test7029048.java

Hi Aleksei, Looks good.  I can sponsor this. Mandy On 7/22/20 1:32 AM, Aleksei Voitylov wrote: Hi Mandy, here is the webrev which addresses your comments: http://cr.openjdk.java.net/~avoitylov/webrev.8247592.02/ Thanks, -Aleksei On 22/07/2020 02:26, Mandy Chung wrote: Hi Aleksei

Re: RFR (trivial) 8249940: Remove unnecessary includes of jni_util.h in native tests

Hi David, Looks good. Mandy On 7/22/20 4:00 PM, David Holmes wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8249940 webrev: http://cr.openjdk.java.net/~dholmes/8249940/webrev/ A number of native tests in hotspot and jdk include the jni_util.h header file which is part of the sources

Re: RFR JDK-8022795: Method.isVarargs of dynamic proxy generated method to match the proxy interface method

Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8249939 Thanks Mandy On 7/22/20 1:55 PM, Joe Darcy wrote: Hi Mandy, The behavior change looks okay; please file a CSR for this too. Thanks, -Joe On 7/22/2020 12:04 PM, Mandy Chung wrote: Webrev: http://cr.openjdk.java.net

RFR JDK-8022795: Method.isVarargs of dynamic proxy generated method to match the proxy interface method

Webrev: http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8022795/webrev.00/ A small improvement to the dynamic proxy generated method to have ACC_VARARGS matching the method declared in a proxy interface if set. If there are two or more proxy interfaces declaring such a method, it matches the

Re: RFR: JDK-8247592: refactor test/jdk/tools/launcher/Test7029048.java

Hi Aleksei, Webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8247592.01/ This refactoring seems okay.  I would suggest to change the run method to return an int or boolean to indicate the test passed or failed.   The caller of the run method (i.e. runTest will add to the failedTests

Re: [15] RFR(T) : 8249697 : java/lang/invoke/RicochetTest.java should use @requires instead of @ignore

test.java.lang.invoke.RicochetTest   */ and then the bug's summary would be smth like 'remove temporary fixes from java/lang/invoke/RicochetTest.java' . sure there is no reason for it to be pushed into 15, I've retargeted to 16. -- Igor On Jul 20, 2020, at 11:57 AM, Mandy Chung <mailto:mandy

Re: [15] RFR(T) : 8249697 : java/lang/invoke/RicochetTest.java should use @requires instead of @ignore

/ 0 failures. Thanks, -- Igor On Jul 18, 2020, at 9:32 PM, Mandy Chung <mailto:mandy.ch...@oracle.com>> wrote: On 7/17/20 8:54 PM, Igor Ignatyev wrote: http://cr.openjdk.java.net/~iignatyev/8249697/webrev.00/ I suggest to change this:   32  * @comment The following tes

Re: [15] RFR(T) : 8249697 : java/lang/invoke/RicochetTest.java should use @requires instead of @ignore

On 7/17/20 8:54 PM, Igor Ignatyev wrote: http://cr.openjdk.java.net/~iignatyev/8249697/webrev.00/ I suggest to change this:   32  * @comment The following test creates an unreasonable number of adapters in -Xcomp mode (7049122) To:    @bug 8249697    @summary verify very high number of

Re: [15] RFR(T) : 8249698 : java/lang/invoke/LFCaching/LFGarbageCollectedTest.java should be ProblemList-ed and not @ignored

+1 Mandy On 7/17/20 8:57 PM, Igor Ignatyev wrote: http://cr.openjdk.java.net/~iignatyev//8249698/webrev.00 3 lines changed: 1 ins; 1 del; 1 mod; Hi all, could you please review this trivial patch which removes @ignore from LFGarbageCollectedTest and adds it into problem-list instead?

Re: JDK 16 RFR of JDK-8249687: Use inline @jls and @jvm tages in more places in java.base

+1 Mandy On 7/17/20 4:04 PM, Joe Darcy wrote: A few more cases found with scripted assistance from Mikael; updated webrev: http://cr.openjdk.java.net/~darcy/8249687.1 Patches for new files below. Thanks, -Joe --- old/src/java.base/share/classes/java/lang/StackTraceElement.java

Re: RFR[15/java.xml] Re: RFR [16/java.xml] 8248486: SafeThread illegal access to java.lang private fields should be removed

JDK15 version. Please review. Thanks, Joe On 7/10/2020 3:02 PM, Mandy Chung wrote: On 7/10/20 2:25 PM, huizhe.w...@oracle.com wrote: Thanks Chris, Roger, and Mandy.  I've updated the webrev using AtomicInteger and removing java.base export. Here's the updated webrev: http

Re: RFR [16/java.xml] 8248486: SafeThread illegal access to java.lang private fields should be removed

On 7/10/20 2:25 PM, huizhe.w...@oracle.com wrote: Thanks Chris, Roger, and Mandy.  I've updated the webrev using AtomicInteger and removing java.base export. Here's the updated webrev: http://cr.openjdk.java.net/~joehw/jdk16/8248486/webrev/ Looks good. Mandy

Re: RFR [16/java.xml] 8248486: SafeThread illegal access to java.lang private fields should be removed

Hi Joe, The change looks good.   You can consider using AtomicInteger for the thread number.  Looks like this is the only use of jdk.internal.misc from java.xml.   You can remove the qualified exports from java.base to java.xml. $ ./bin/jdeps -verbose:class -p jdk.internal.misc

Re: RFR: 8249080 - Reduce MemberName class dependency on MethodHandles

On 7/8/20 11:21 AM, Bob Vandette wrote: On Jul 8, 2020, at 1:01 PM, Mandy Chung wrote: On 7/8/20 9:40 AM, Bob Vandette wrote: Should I add an assert or just let the NPE happen? What about Objects.requireNonNull(m); Thanks. Here’s the updated webrev: https://cr.openjdk.java.net

Re: RFR: 8249080 - Reduce MemberName class dependency on MethodHandles

On 7/8/20 9:40 AM, Bob Vandette wrote: Should I add an assert or just let the NPE happen? What about  Objects.requireNonNull(m); Mandy

Re: RFR: 8249080 - Reduce MemberName class dependency on MethodHandles

On 7/8/20 8:19 AM, Bob Vandette wrote: Please review this RFE for JDK 16 that reduces a class dependency in the MethodHandles.Lookup class. The ensureInitialized method from MethodHandles.Lookup creates a transient MemberName object only to be used to throw an exception. This exception can

Re: [15] RFR JDK-8247785: Small clarification to the javadoc about builtin class loaders

Hi Roger, David, Thanks for the help in improving this.  As a record, this webrev shows the version as David suggests: http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8247785/webrev.00/ Mandy On 6/24/20 9:33 AM, Roger Riggs wrote: Hi Mandy, I'm fine with this. Roger

Re: [15] RFR JDK-8247785: Small clarification to the javadoc about builtin class loaders

On 6/23/20 7:48 PM, David Holmes wrote: Hi Mandy, The trouble with small clarifications is that they tend to draw attention to larger issues :) On 24/06/2020 7:42 am, Mandy Chung wrote: On 6/23/20 12:01 PM, Roger Riggs wrote: Hi Mandy, There may be a missing

Re: RFR: JDK-8242451 : ensure semantics of non-capturing lambdas are preserved independent of execution mode

Hi Gilles, Additional comments: 215 try { 216 return new ConstantCallSite(Lookup.IMPL_LOOKUP.findStaticGetter(innerClass, LAMBDA_INSTANCE_FIELD, invokedType.returnType())); 217 } catch (ReflectiveOperationException e) { 218 throw new LambdaConversionException("Exception finding constructor",

Re: [15] RFR JDK-8247785: Small clarification to the javadoc about builtin class loaders

On 6/23/20 12:01 PM, Roger Riggs wrote: Hi Mandy, There may be a missing "to" in: + * Platform classes are visible the platform class loader ++ * Platform classes are visible *via* the platform class loader I caught this accidental change too. The second change seems to be

Re: RFR: JDK-8242451 : ensure semantics of non-capturing lambdas are preserved independent of execution mode

On 6/23/20 11:38 AM, Brian Goetz wrote: On 6/23/2020 2:08 PM, Gilles Duboscq wrote: In 8232806, a system property was introduce to disable eager initialization of the classes generated by the InnerClassLambdaMetafactory (`jdk.internal.lambda.disableEagerInitialization`). However, when

Re: [15] RFR JDK-8247785: Small clarification to the javadoc about builtin class loaders

s are difficult to read and understand. (  I think the originals are more readable). Thanks, Roger On 6/23/20 2:23 PM, Alan Bateman wrote: On 23/06/2020 19:03, Mandy Chung wrote: Small clarification about the parent of the system class loader in the ClassLoader class spec:

[15] RFR JDK-8247785: Small clarification to the javadoc about builtin class loaders

Small clarification about the parent of the system class loader in the ClassLoader class spec: diff --git a/src/java.base/share/classes/java/lang/ClassLoader.java b/src/java.base/share/classes/java/lang/ClassLoader.java --- a/src/java.base/share/classes/java/lang/ClassLoader.java +++

Re: RFR: 8248131: Simplify ServicesCatalog provider handling

On 6/23/20 1:56 AM, Claes Redestad wrote: Hi, the current implementation of ServicesCatalog uses an internal providers method, which is only used to add ServiceProviders. Providing an addProviders method instead means we can streamline this, to the tune of a very small startup win. Bug:   

Re: RFR: [15, docs] JDK-8247896, Invalid (@throw) tags in 2 java.io classes

+1 Mandy On 6/18/20 4:16 PM, Jonathan Gibbons wrote: Please review a trivial fix for a couple of misnamed tags in 2 classes in the java.io package. In both cases, @throw should be @throws -- Jon JBS: https://bugs.openjdk.java.net/browse/JDK-8247896 Patch inline: diff -r d66e8770295e

Re: RFR: [15,docs] JDK-8247894,Invalid @see in java.management

/management/package.html Thu Jun 18 15:51:09 2020 -0700 @@ -234,7 +234,7 @@   The java.lang.management API is thread-safe. -@see <mailto:-@see>{@linkplain javax.management JMX Specification} +@see javax.management JMX Specification  @author Mandy Chung  @since 1.5

Review Request JDK-8244090: public lookup should find public members of public exported types

Prior to JDK-8173978, publicLookup().in(C.class) produces a Lookup object on C with PUBLIC access which can be used to look up unconditionally exported public types from the module of C. Such lookup can only look up this C class defined by loader 1 but not another class named "C" defined by

Re: (15) RFR: JDK-8247444: Trust final fields in records

On 6/18/20 5:43 AM, Aleksey Shipilev wrote: On 6/17/20 6:50 PM, Mandy Chung wrote: On 6/17/20 8:11 AM, Aleksey Shipilev wrote: On 6/15/20 11:58 PM, Mandy Chung wrote: Amusingly, with the rest of Unsafe available the barn is still full open. Here's the sketch for the workaround: get

Re: RFR [15] 8247789: Remove use of reflection from test/jdk/java/io/Serializable/records/StreamRefTest.java

On 6/18/20 7:25 AM, Chris Hegarty wrote: On 18 Jun 2020, at 14:56, Roger Riggs wrote: Hi Chris, It may be prudent to check that the current value in the byte array is the one you expect before changing it. That would help catch tests if something else changes the contents of the stream.

Re: (15) RFR: JDK-8247444: Trust final fields in records

his API.   I will file a RFE to follow this up. Mandy Thanks, Serguei On 6/15/20 14:58, Mandy Chung wrote: This patch is joint contribution from Christoph Dreis [1] and me. Webrev: http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8247444/webrev.00/ CSR: https://bugs.openjdk.java.net/brows

Re: (15) RFR: JDK-8247444: Trust final fields in records

ch "trusts" the contents of a final field after its initialization is over (vmTrustedFinal/isVMTrustedFinalField). But I'm fine with keeping the patch as is. Best regards, Vladimir Ivanov On 16.06.2020 00:58, Mandy Chung wrote: This patch is joint contribution from Christoph Dreis [1] an

Re: (15) RFR: JDK-8247444: Trust final fields in records

On 6/17/20 8:11 AM, Aleksey Shipilev wrote: On 6/15/20 11:58 PM, Mandy Chung wrote: This patch also proposes `sun.misc.Unsafe::objectFieldOffset` and `sun.misc.Unsafe::staticField{Offset/Base}` not to support records. Note this would break otherwise innocuous introspection for records

Re: (15) RFR: JDK-8247444: Trust final fields in records

hanks. I'm unclear if the new TEST.properties file needs a copyright notice and header. We have 706 such files in the repo and 554 (mostly hotspot) do have the copyright notice and header. I will find out the recommendation and update you. Mandy Thanks, David On 16/06/2020 7:58 am, Mandy C

Re: (15) RFR: JDK-8247444: Trust final fields in records

if it's flattened which I am not satisfied either). So +1 Thanks Remi. Mandy Rémi - Mail original - De: "mandy chung" À: "hotspot-dev" , "core-libs-dev" , "amber-dev" Envoyé: Lundi 15 Juin 2020 23:58:19 Objet: (15) RFR: JDK-8247444: Trust fin

(15) RFR: JDK-8247444: Trust final fields in records

This patch is joint contribution from Christoph Dreis [1] and me. Webrev: http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8247444/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8247517 This proposes to make final fields in records notmodifiable via reflection.  Field::set throws IAE

Re: RFR [15] 8247115: Fix typos in java.lang.invoke and java.lang

Looks good. Mandy On 6/9/20 3:42 AM, Pavel Rappo wrote: Hello, Please review the change for https://bugs.openjdk.java.net/browse/JDK-8247115 http://cr.openjdk.java.net/~prappo/8247115/webrev.00/ The patch fixes 11 typos in doc comments and 2 typos in code. The typos in code are in

Re: RFR: JDK-8245958: j.l.Record need to mention that canonical constructor may not be public

Looks fine. Mandy On 6/8/20 12:58 PM, Vicente Romero wrote: Please review this API update. The API of java.lang.Record needs to be updated after the changes introduced by JEP 384: Records (Second Preview) [1], in particular this JEP changed the constraint that the canonical constructor had

Re: 8246632: StringConcatFactory::makeConcatWithConstants no longer throws NullPointerException when an unexpected constant is null

Looks good (minus the typo Roger caught). Mandy On 6/8/20 7:51 AM, Claes Redestad wrote: Hi, JDK-8246152 triggered a failure in a JCK test that expects a NPE rather than a StringConcatException. We can keep the old behavior, while retaining most of performance by removing the now superfluous

Re: Class.getCanonicalName() returns null for lambdas

On 6/5/20 6:42 AM, Christoph Dreis wrote: Hi, forgive me if this was discussed already, but I found that the implementation of hidden classes causes a change in behavior for Class.getCanonicalName(). A hidden class has no canonical name [1] and it can't be nominally referenced (like an

Re: Review Request: JDK-8235521: Replacement API for Unsafe::ensureClassInitialized

I create https://bugs.openjdk.java.net/browse/JDK-8246634 to track this. thanks Mandy On 6/4/20 4:35 PM, John Rose wrote: P.S.C. (post-send clarification) The workflow would be: static final MethodHandle MH_ensureInit = publicLookup().findVirtual(L…, “ensureInitialized”…); By that I

Re: Review Request: JDK-8235521: Replacement API for Unsafe::ensureClassInitialized

On 6/4/20 12:39 PM, mark.reinh...@oracle.com wrote: I agree that the `ensure` prefix is useful here. This method can only ensure that a class is initialized, so including `Class` in the method name seems redundant. I’d go with the shorter `ensureInitialized`. - Mark Thanks for the advice.  

Re: Review Request: JDK-8235521: Replacement API for Unsafe::ensureClassInitialized

Lookup::accessClass sets the precedence to return Class for method chaining.  So this new method follows the existing convention. Mandy On 6/4/20 12:31 PM, Florent Guillaume wrote: Hi, Why can't it just return void? Florent On Thu, Jun 4, 2020 at 9:22 PM Mandy Chung <mailto:mandy

Re: Review Request: JDK-8235521: Replacement API for Unsafe::ensureClassInitialized

this in the spec? e.g. this method does nothing if the class is already initialized or if the class is in the process of being initialized? Paul. On Jun 3, 2020, at 4:16 PM, Mandy Chung wrote: This proposes a new `Lookup::ensureClassInitialized` API as a replacement for `sun.misc.Unsafe

Re: Review Request: JDK-8235521: Replacement API for Unsafe::ensureClassInitialized

obviously by their descriptions? Maybe "@return targetClass, that is initialized" @return the class that has been initialized. I changed it to: * @return {@code targetClass} that has been initialized Mandy -Chris. On 4 Jun 2020, at 00:16, Mandy Chung wrote: This pr

Re: Review Request: JDK-8235521: Replacement API for Unsafe::ensureClassInitialized

On 6/3/20 6:24 PM, John Rose wrote: On Jun 3, 2020, at 5:16 PM, Paul Sandoz > wrote:  if (UNSAFE.shouldBeInitialized(cls)) {  UNSAFE.ensureClassInitialized(cls);  } Although it seems redundant to perform the check, suggesting it is not needed. It’s

Re: Review Request: JDK-8235521: Replacement API for Unsafe::ensureClassInitialized

will update the patch and CSR. Mandy Paul. On Jun 3, 2020, at 4:16 PM, Mandy Chung wrote: This proposes a new `Lookup::ensureClassInitialized` API as a replacement for `sun.misc.Unsafe::ensureClassInitialized`.The Lookup object must have the access to the given class being initialized. CSR: https

Review Request: JDK-8235521: Replacement API for Unsafe::ensureClassInitialized

This proposes a new `Lookup::ensureClassInitialized` API as a replacement for `sun.misc.Unsafe::ensureClassInitialized`.The Lookup object must have the access to the given class being initialized. CSR: https://bugs.openjdk.java.net/browse/JDK-8245871 webrev:

Re: RFR(XL) 8198698: Support Lambda proxy classes in dynamic CDS archive

On 6/3/20 12:34 PM, Calvin Cheung wrote: I saw David has commented on this. So I'll leave the assert as before and I've added another assert (see line 1691): 1687   // The following ensures that the caller's nest host is the same as the lambda proxy's 1688   // nest host recorded at

Re: RFR(XL) 8198698: Support Lambda proxy classes in dynamic CDS archive

Hi David, On 6/2/20 10:30 PM, David Holmes wrote: 1685 InstanceKlass* n_h = caller_ik->nest_host(THREAD); 1686   assert(n_h->has_nest_member(caller_ik, THREAD) || 1687  n_h == caller_ik, "mismatched nest host"); I think you meant to check n_h->has_nest_member(loaded_lambda, THREAD).

Re: RFR(XL) 8198698: Support Lambda proxy classes in dynamic CDS archive

Hi Calvin, To recap an offline discussion, I think we should use JDK bootcycle build to test this feature.  For example generating a boot JDK with archived lambda proxy classes for java.base and javac to build itself and also use it to run JDK tier 1-3 tests.  This would serve a good test

Re: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version

On 5/29/20 1:03 PM, Mandy Chung wrote: CSR: https://bugs.openjdk.java.net/browse/JDK-8246108 As CSR is approved,  I went ahead and pushed this patch: http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8245432/webrev.03/ This version has fixed the range check issue Johannes caught and also

Re: RFR: 8246241: LambdaFormEditor should use a transform lookup key that is not a SoftReference

On 6/1/20 12:57 PM, Claes Redestad wrote: Adjusted the webrev in-place based on your comments (A few methods were public that should be private, etc..) This looks okay to me. Mandy

Re: RFR: 8246251: Adjust HelloClasslist after JDK-8230301

Hi Claes, This looks okay. Mandy On 6/1/20 4:55 AM, Claes Redestad wrote: Hi, comparing startup profiles on a few application I found a few cases where a few more classes are being generated at runtime compared to JDK 14. This is due to the removal of hard-coded defaults in

Re: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version

On 29-May-20 21:23, Mandy Chung wrote: It's fixed.  Thanks Mandy On 5/28/20 4:35 PM, Johannes Kuhn wrote: Hi, just noticed a small thing: The magic is 4 bytes, but readUnsignedShort reads two bytes. - Johannes On 28-May-20 19:25, Mandy Chung wrote: On 5/28/20 6:55 AM, Alan Bateman wrote:

Re: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version

On 5/28/20 9:18 PM, David Holmes wrote: On 29/05/2020 1:52 pm, Mandy Chung wrote: On 5/28/20 5:44 PM, David Holmes wrote: This is to validate the given version.  The runtime will check if preview feature is enabled when such class file is loaded. I will make a comment to make it clear

Re: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version

On 5/29/20 11:29 AM, Alan Bateman wrote: I went through webrev.02 and the only issue is the magic is read as a u2 when it should be u4, otherwise looks good. Thanks.  Updated in place: http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8245432/webrev.02/index.html Mandy

Re: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version

It's fixed.  Thanks Mandy On 5/28/20 4:35 PM, Johannes Kuhn wrote: Hi, just noticed a small thing: The magic is 4 bytes, but readUnsignedShort reads two bytes. - Johannes On 28-May-20 19:25, Mandy Chung wrote: On 5/28/20 6:55 AM, Alan Bateman wrote: On 28/05/2020 05:13, Mandy Chung wrote

Re: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version

and remove these constants. That aside isn't the minor version, as set in java.class.version guaranteed to be zero? This is set at build time.   The minor version is zero for the current versioning scheme. Mandy David - Mandy Cheers, David Mandy On 5/27/20 10:57 AM, Mandy Chung

Re: RFR: JDK-8225056 VM support for sealed classes

overwrite it *verify_legal_class_name(class_name, CHECK);*     break;   } Thanks, Harold On 5/28/2020 5:12 PM, Mandy Chung wrote: I read the JVMS but it isn't clear to me that the VM will validate the names in `PermittedSubclasses`attribute are valid class descriptors.   I see Con

Re: RFR: JDK-8225056 VM support for sealed classes

Hi Harold, On 5/27/20 1:35 PM, Harold Seigel wrote: Incremental webrev: http://cr.openjdk.java.net/~hseigel/sealedClasses.8225056.incr.2/ full webrev: http://cr.openjdk.java.net/~hseigel/sealedClasses.8225056.2/webrev/ Class.java 4406 ReflectionData rd = reflectionData(); 4407

Re: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version

On 5/28/20 12:44 AM, David Holmes wrote: Hi Mandy, On 28/05/2020 2:13 pm, Mandy Chung wrote: Updated webrev: http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8245432/webrev.01/ I modify this patch to check the class file version and throws CFE if unsupported before creating ClassReader

Re: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version

On 5/28/20 6:55 AM, Alan Bateman wrote: On 28/05/2020 05:13, Mandy Chung wrote: Updated webrev: http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8245432/webrev.01/ I modify this patch to check the class file version and throws CFE if unsupported before creating ClassReader.  This also

Re: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version

On 5/27/20 12:24 AM, David Holmes wrote: Hi Mandy, On 27/05/2020 7:46 am, Mandy Chung wrote: Lookup::defineHiddenClass currently throws IAE by ASM if the given bytes are of unsupported class file version.  The implementation should catch and throw UnsupportedClassVersionError instead

Re: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version

will throw an exception if it's not a constant) and also ensures that `this_class` is a CONSTANT_Class_info by checking the descriptor string from Type. Mandy On 5/27/20 10:57 AM, Mandy Chung wrote: I'm reconsidering this fix along with JDK-8245061 that may require to do its own checking (a similar

Re: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version

: "Alan Bateman" À: "mandy chung" , "core-libs-dev" , "Remi Forax" Envoyé: Mercredi 27 Mai 2020 18:16:33 Objet: Re: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor

RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version

Lookup::defineHiddenClass currently throws IAE by ASM if the given bytes are of unsupported class file version.  The implementation should catch and throw UnsupportedClassVersionError instead. webrev: http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8245432/webrev.00/ This patch also includes

Re: RFR: 8245455: Remove alternative StringConcatFactory strategies

Has that system property ever documented in CSR?    It's not in CSR for JEP 280 [1].   Maybe other CSR? Mandy [1] https://bugs.openjdk.java.net/browse/CCC-8085796 On 5/23/20 6:18 AM, David Holmes wrote: Hi Claes, You are removing a property so this needs a CSR request. Thanks, David On

Re: 8239013: java.util.logging.Logger catalog cache keeps strong references to ResourceBundles

Hi Daniel, This looks good.  Surprisingly no one reports this long standing bug. thanks Mandy On 5/22/20 2:33 AM, Daniel Fuchs wrote: Hi, Please find below a fix for: 8239013: java.util.logging.Logger catalog cache keeps strong references to ResourceBundles

Re: RFR: 8245455: Remove alternative StringConcatFactory strategies

Hi Claes, The change looks good. I also support the removal of all non-default strategies.  The default strategy has been baked for long enough time and shown solid (the issues in j.l.invoke quoted already were 2 years old). Mandy On 5/22/20 10:28 AM, Paul Sandoz wrote: Hi, I support the

Re: RFR: JDK-8225056 VM support for sealed classes

Hi Vicente, On 5/20/20 8:40 AM, Vicente Romero wrote: Hi David, src/java.base/share/classes/java/lang/Class.java There needs to be a CSR request for these changes. yes there is one already: https://bugs.openjdk.java.net/browse/JDK-8244556 Adding to David's comment w.r.t. @throws IAE:

<    3   4   5   6   7   8   9   10   11   12   >