From jonathan.gibbons at oracle.com Mon Mar 2 15:21:23 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 2 Mar 2020 07:21:23 -0800 Subject: RFR: JDK-8228451: NPE in Attr.java when -XDshould-stop.ifError=FLOW In-Reply-To: <07f2249d-36a3-022e-2c37-5badf7157d66@oracle.com> References: <07f2249d-36a3-022e-2c37-5badf7157d66@oracle.com> Message-ID: <1ee29dfc-a8bd-47c6-d61e-993479475d0e@oracle.com> Jan, In the test, the regex \r*\n can/should be replaced by \R. Otherwise, looks good. -- Jon On 7/26/19 8:25 AM, Jan Lahoda wrote: > Hi, > > Consider code like this: > --- > public class T { > ??? v + v n; > } > --- > > javac's parser will parse this as a variable of type "v" without a > name, and another variable of type "v" with a name "n", skipping the "+". > > But if the code is: > --- > public class T { > ??? v += v n; > } > --- > > (note the change of '+' to compound assignment '+='), javac will parse > it as a variable with name "n" and type "v += v" and allows the > compilation to continue to Attr, where it eventually fails with: > --- > java.lang.AssertionError: Unexpected tree: v += v with kind: > PLUS_ASSIGNMENT within: v += v with kind: PLUS_ASSIGNMENT > ??????? at > jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:162) > ??????? at > jdk.compiler/com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.validateAnnotatedType(Attr.java:5154) > ??????? at > jdk.compiler/com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.visitVarDef(Attr.java:5000) > ... > --- > > It seems the reason for this difference is incorrect reliance on > operator priorities in JavacParser.term(). The proposed fix is to > ignore compound operators in type mode in term(), and hence treat += > similarly to +, parsing "v += v n;" as two variables, skipping '+='. > > Part of the problem in the original testcase is insufficient error > recovery for parsing broken enums, I've split that into a separate bug > - JDK-8228647. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8228451 > Webrev: http://cr.openjdk.java.net/~jlahoda/8228451/webrev.00/ > > How does this look? > > Thanks, > ??? Jan From vicente.romero at oracle.com Mon Mar 2 17:41:51 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 2 Mar 2020 12:41:51 -0500 Subject: RFR: JDK-8228451: NPE in Attr.java when -XDshould-stop.ifError=FLOW In-Reply-To: <07f2249d-36a3-022e-2c37-5badf7157d66@oracle.com> References: <07f2249d-36a3-022e-2c37-5badf7157d66@oracle.com> Message-ID: looks good to me, Vicente On 7/26/19 11:25 AM, Jan Lahoda wrote: > Hi, > > Consider code like this: > --- > public class T { > ??? v + v n; > } > --- > > javac's parser will parse this as a variable of type "v" without a > name, and another variable of type "v" with a name "n", skipping the "+". > > But if the code is: > --- > public class T { > ??? v += v n; > } > --- > > (note the change of '+' to compound assignment '+='), javac will parse > it as a variable with name "n" and type "v += v" and allows the > compilation to continue to Attr, where it eventually fails with: > --- > java.lang.AssertionError: Unexpected tree: v += v with kind: > PLUS_ASSIGNMENT within: v += v with kind: PLUS_ASSIGNMENT > ??????? at > jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:162) > ??????? at > jdk.compiler/com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.validateAnnotatedType(Attr.java:5154) > ??????? at > jdk.compiler/com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.visitVarDef(Attr.java:5000) > ... > --- > > It seems the reason for this difference is incorrect reliance on > operator priorities in JavacParser.term(). The proposed fix is to > ignore compound operators in type mode in term(), and hence treat += > similarly to +, parsing "v += v n;" as two variables, skipping '+='. > > Part of the problem in the original testcase is insufficient error > recovery for parsing broken enums, I've split that into a separate bug > - JDK-8228647. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8228451 > Webrev: http://cr.openjdk.java.net/~jlahoda/8228451/webrev.00/ > > How does this look? > > Thanks, > ??? Jan From jan.lahoda at oracle.com Tue Mar 3 13:46:21 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 3 Mar 2020 14:46:21 +0100 Subject: RFR: JDK-8239575: javadoc triggers javac AssertionError for annos on modules Message-ID: <4b2f0eda-10a6-d29b-bf34-00e173190ba0@oracle.com> Hi, javadoc uses the javac's model to model the source files. But it starts javac in a very special way. As a consequence, if the module that is being documented is load from sources implicitly, it is loaded twice, which then may lead to trouble during annotation processing. The proposed patch is to change the code to load the module only once. Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8239575/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8239575 How does this look? Thanks, Jan From jonathan.gibbons at oracle.com Tue Mar 3 22:26:54 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 3 Mar 2020 14:26:54 -0800 Subject: RFR: JDK-8239575: javadoc triggers javac AssertionError for annos on modules In-Reply-To: <4b2f0eda-10a6-d29b-bf34-00e173190ba0@oracle.com> References: <4b2f0eda-10a6-d29b-bf34-00e173190ba0@oracle.com> Message-ID: +1 Very nice -- Jon On 03/03/2020 05:46 AM, Jan Lahoda wrote: > Hi, > > javadoc uses the javac's model to model the source files. But it > starts javac in a very special way. As a consequence, if the module > that is being documented is load from sources implicitly, it is loaded > twice, which then may lead to trouble during annotation processing. > > The proposed patch is to change the code to load the module only once. > > Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8239575/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8239575 > > How does this look? > > Thanks, > ???? Jan From vicente.romero at oracle.com Wed Mar 4 17:41:30 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 4 Mar 2020 12:41:30 -0500 Subject: RFR: JDK-8240454: incorrect error message: as of release 13, 'record' is a restricted type name Message-ID: <0feaedde-f326-2f8a-accf-ab0ad23eebe7@oracle.com> Please review the fix for [1] at [2]. For this code: class record {} javac was issuing this error message: class record {} ??????^ ??as of release 13, 'record' is a restricted type name and cannot be used for type declarations it should mention release 14 instead. This fix alters code that will affect similar error messages not only for uses of `record` but also of `yield`. In adding support for the test case I had modified several test libraries, in particular to be able to check not only the error key of the error issued by javac but also the parameters as in this case the difference was in the parameter passed to the error. Please review those changes too. Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8240454 [2] http://cr.openjdk.java.net/~vromero/8240454/webrev.00/ From jan.lahoda at oracle.com Thu Mar 5 14:25:06 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 5 Mar 2020 15:25:06 +0100 Subject: RFR: JDK-8240454: incorrect error message: as of release 13, 'record' is a restricted type name In-Reply-To: <0feaedde-f326-2f8a-accf-ab0ad23eebe7@oracle.com> References: <0feaedde-f326-2f8a-accf-ab0ad23eebe7@oracle.com> Message-ID: <1b9b1c76-f9fd-559c-80d0-bb2af73f523f@oracle.com> Looks reasonable to me. Jan On 04. 03. 20 18:41, Vicente Romero wrote: > Please review the fix for [1] at [2]. For this code: > > class record {} > > javac was issuing this error message: > > class record {} > ??????^ > ??as of release 13, 'record' is a restricted type name and cannot be > used for type declarations > > it should mention release 14 instead. This fix alters code that will > affect similar error messages not only for uses of `record` but also of > `yield`. In adding support for the test case I had modified several test > libraries, in particular to be able to check not only the error key of > the error issued by javac but also the parameters as in this case the > difference was in the parameter passed to the error. Please review those > changes too. > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8240454 > [2] http://cr.openjdk.java.net/~vromero/8240454/webrev.00/ From jonathan.gibbons at oracle.com Thu Mar 5 20:18:04 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 5 Mar 2020 12:18:04 -0800 Subject: JDK 15 RFR of JDK-8240130: Improve and update discussion of visitor evolution warnings In-Reply-To: References: Message-ID: <0a7353aa-9c06-aa47-145c-765bf2069f89@oracle.com> Looks good to me. Consider using a ':' instead of ',' on this line in the first file: 66 * visitUnknown}, behavior that will be overridden in concrete -- Jon On 2/26/20 10:00 PM, Joe Darcy wrote: > Hello, > > Please review the documentation changes for > > ??? JDK-8240130: Improve and update discussion of visitor evolution > warnings > ??? http://cr.openjdk.java.net/~darcy/8240130.0/ > > Patch below. Some discussion of and rationale for the changes, the > original javax.lang.model visitor interfaces and concrete visitor > types had various warning about the unusual compatibility policies > those types would use. Unlike other post-Java SE 6 era types, it was > anticipated methods would be added to interfaces. Prior to default > methods in JDK 8, such additions were a highly unusual occurrence for > public types in the JDK. After default methods were used commonly in > jDK 8, such additions are of less concern. The risk of a true source > compatibility is also low for a new "visitFoo" method since it will > have a parameter of type Foo, which is new to the release, and thus > not have an overloading conflict with a method in an existing visitor > outside of the JDK. > > The warnings are thus toned down and adjusted to note that the > envisioned additions have already occurred for prior language > additions. For example, the current policy is only to deprecate the > constructors of obsolete visitor classes rather than the whole class. > The "directly or indirectly call" visitUnknown is to accurately > describe, but not limit to, the current policy of the visitFoo methods > in affected concrete visitors calling the visitFoo default method on > the *interface*, which in turn calls visitUnknown. > > The warning text is pulled into an apiNote to avoid getting > inherit-doc-ed for any subclasses. Once the shape of the changes for > the interface and visitor classes are agree to, I'll replicated the > changes for the other types. > > Thanks, > > -Joe > > --- > old/src/java.compiler/share/classes/javax/lang/model/element/ElementVisitor.java > 2020-02-26 13:13:00.848880601 -0800 > +++ > new/src/java.compiler/share/classes/javax/lang/model/element/ElementVisitor.java > 2020-02-26 13:13:00.512880601 -0800 > @@ -40,10 +40,17 @@ > ? * is {@code null}; see documentation of the implementing class for > ? * details. > ? * > - *

WARNING: It is possible that methods will be added to > + * @apiNote > + * > + * WARNING: It is possible that methods will be added to > ? * this interface to accommodate new, currently unknown, language > ? * structures added to future versions of the Java™ programming > - * language.? Therefore, visitor classes directly implementing this > + * language. > + * > + * Such additions have already occurred to support language features > + * added after this API was introduced. > + * > + * Visitor classes directly implementing this > ? * interface may be source incompatible with future versions of the > ? * platform.? To avoid this source incompatibility, visitor > ? * implementations are encouraged to instead extend the appropriate > @@ -52,21 +59,15 @@ > ? * parameters, return type, etc. rather than one of the abstract > ? * classes. > ? * > - *

Note that methods to accommodate new language constructs could > - * be added in a source compatible way if they were added as > - * default methods.? However, default methods are only > - * available on Java SE 8 and higher releases and the {@code > - * javax.lang.model.*} packages bundled in Java SE 8 were required to > - * also be runnable on Java SE 7.? Therefore, default methods > - * were not used when extending {@code javax.lang.model.*} > - * to cover Java SE 8 language features.? However, default methods > - * are used in subsequent revisions of the {@code javax.lang.model.*} > - * packages that are only required to run on Java SE 8 and higher > - * platform versions. > - * > - * @apiNote > + *

Methods to accommodate new language constructs are expected to > + * be added as default methods to provide strong source compatibility, > + * as done for {@link visitModule visitModule}. The implementations of > + * the default methods will in turn call {@link visitUnknown > + * visitUnknown}, behavior that will be overridden in concrete > + * visitors supporting the source version with the new language > + * construct. > ? * > - * There are several families of classes implementing this visitor > + *

There are several families of classes implementing this visitor > ? * interface in the {@linkplain javax.lang.model.util util > ? * package}. The families follow a naming pattern along the lines of > ? * {@code FooVisitor}N where N indicates the > --- > old/src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor6.java > 2020-02-26 13:13:01.560880601 -0800 > +++ > new/src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor6.java > 2020-02-26 13:13:01.196880601 -0800 > @@ -36,7 +36,9 @@ > ? * appropriate for the {@link SourceVersion#RELEASE_6 RELEASE_6} > ? * source version. > ? * > - *

WARNING: The {@code ElementVisitor} interface > + * @apiNote > + * > + * WARNING: The {@code ElementVisitor} interface > ? * implemented by this class may have methods added to it in the > ? * future to accommodate new, currently unknown, language structures > ? * added to future versions of the Java™ programming language. > @@ -46,12 +48,12 @@ > ? * methods with names beginning with {@code "visit"}. > ? * > ? *

When such a new visit method is added, the default > - * implementation in this class will be to call the {@link > + * implementation in this class will be to directly or indirectly > call the {@link > ? * #visitUnknown visitUnknown} method.? A new abstract element visitor > ? * class will also be introduced to correspond to the new language > ? * level; this visitor will have different default behavior for the > - * visit method in question.? When the new visitor is introduced, all > - * or portions of this visitor may be deprecated. > + * visit method in question.? When a new visitor is introduced, > + * portions of this visitor class may be deprecated, including its > constructors. > ? * > ? * @param the return type of this visitor's methods. Use {@link > ? *??????????? Void} for visitors that do not need to return results. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Sat Mar 7 05:34:41 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Sat, 7 Mar 2020 00:34:41 -0500 Subject: RFR: JDK-8239447: compiler error for annotations applied to record components with target METHOD Message-ID: <0a251e05-1138-92e2-7b83-74fb3bb87db0@oracle.com> Please review fix for [1] at [2]. When there are APs involved, every time a new round of annotation processing will start, a visitor, see [3], sets the attribute field of annotation ASTs to null. This visitor was not visiting some annotations stored at the record component. This provoked that data from previous rounds could be accessible to later rounds provoking later annotation validation code to fail. Just visiting the annotations at the record component as it is done for the rest of the annotations has fixed the issue. Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8239447 [2] http://cr.openjdk.java.net/~vromero/8239447/webrev.00/ [3] http://hg.openjdk.java.net/jdk/jdk/file/7af6364e1792/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java#l1591 From adam.sotona at oracle.com Mon Mar 9 16:11:09 2020 From: adam.sotona at oracle.com (Adam Sotona) Date: Mon, 9 Mar 2020 17:11:09 +0100 Subject: RFR: JDK-8235216 typo in test filename Message-ID: <697D74B2-8AE8-4941-B441-72D1E00AA4F3@oracle.com> Hi, I would like to ask for review of fixed typo in the test name test/langtools/tools/javac/file/MultiReleaseJar/MultiReleaseModuleInfoTest.java JBS: https://bugs.openjdk.java.net/browse/JDK-8235216 webrev: http://cr.openjdk.java.net/~asotona/8235216/webrev.00/ Mach5 build passed Tier1, Tier2 and Tier3 tests. Thank you, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Mon Mar 9 17:33:41 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 9 Mar 2020 10:33:41 -0700 Subject: RFR: JDK-8235216 typo in test filename In-Reply-To: <697D74B2-8AE8-4941-B441-72D1E00AA4F3@oracle.com> References: <697D74B2-8AE8-4941-B441-72D1E00AA4F3@oracle.com> Message-ID: Ooops. OK. -- Jon On 03/09/2020 09:11 AM, Adam Sotona wrote: > Hi, > I would like to ask for review of fixed typo in the test name > test/langtools/tools/javac/file/MultiReleaseJar/MultiReleaseModuleInfoTest.java > > JBS: https://bugs.openjdk.java.net/browse/JDK-8235216 > webrev: http://cr.openjdk.java.net/~asotona/8235216/webrev.00/ > > > Mach5 build passed Tier1, Tier2 and Tier3 tests. > > Thank you, > Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Tue Mar 10 21:03:40 2020 From: bsrbnd at gmail.com (B. Blaser) Date: Tue, 10 Mar 2020 22:03:40 +0100 Subject: Enhancing expressions with mutability? Message-ID: Hi, Taking back the essential idea of the original publication on Lisp [1], I did the attached syntactic experiment [2] trying to bring some kind of mutability to expressions and thus giving more flexibility to the language. I hope this subject hasn't been covered too many times, otherwise I'd apologize for any disturbance. To build such mutable expressions, I've specified a new unary operator ` along with its resulting class 'java.lang.Term'. The quotation operator creates a 'Term' from any reference which can then be linked to other terms to finally be evaluated to the result of a function call for lambdas or the reference itself otherwise. Let's take some examples from the attached patch: + interface Get { + int op(); + } + + interface Sum { + int op(int i, int j); + } + int a = 0, b = 0; + Sum s = (x, y) -> x + y; + public void run() { + Get a = () -> this.a; + Get b = () -> this.b; + + Term e1 = (`s).link(`a, `b); + this.a = 1; this.b = 2; The above lines create a mutable expression e1 from the sum lambda s of the getter a and b which can then be evaluated to: (Integer)e1.value() == 3 or visualized as: e1.toString().equals("Sum( Get( ) Get( ) )") An interesting application similar to ?3.g from [1] is the computation of the partial derivative of a sum involving the mutation of the initial expression to produce a new resulting one: + // Derivative of sum e with respect to r + Term derivative(Term e, Term r) { + if (e.terms.isEmpty()) { + return `Integer.valueOf(e.that == r.that ? 1 : 0); + } + else if(e.that == (`s).that) { + return (`s).link(derivative(e.terms.get(0), r), derivative(e.terms.get(1), r)); + } + else throw new AssertionError(); + } Invoking the above method like this: + Term e2 = derivative(e1, `a); creates the resulting derivative expression e2 which can then be evaluated to: (Integer)e2.value() == 1 or visualized as: e2.toString().equals("Sum( `1 `0 )") Finally, we note that any term may be quoted to prevent its evaluation, for example: + Derivative d = this::derivative; + Term e3 = (`d).link(`e1, ``a); can be evaluated to: (Integer)((Term)e3.value()).value() == 1 or visualized as: e3.toString().equals("Derivative( `Sum( Get( ) Get( ) ) `Get( ) )") Of course, one of our main concern is how much do we need this and a reasonable answer would probably be as much as we need Lisp's S-expressions but with similar or maybe better performance than external interpreters and a more homogeneous integration to the language. Any feedback about this experiment would be welcome! Thanks, Bernard [1] http://www-formal.stanford.edu/jmc/recursive.html [2] quote.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: quote.patch Type: text/x-patch Size: 18205 bytes Desc: not available URL: From joe.darcy at oracle.com Wed Mar 11 05:09:05 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 10 Mar 2020 22:09:05 -0700 Subject: JDK 15 RFR of JDK-8240130: Improve and update discussion of visitor evolution warnings In-Reply-To: <0a7353aa-9c06-aa47-145c-765bf2069f89@oracle.com> References: <0a7353aa-9c06-aa47-145c-765bf2069f89@oracle.com> Message-ID: <12938504-53ab-57f6-7aea-86ed44a2cfbf@oracle.com> Hello, Updated and expanded version of the webrev: ??? http://cr.openjdk.java.net/~darcy/8240130.1 A few notes on reviewing: ??? * The delta for each FooVisitor$N utility visitor family should be the same. I confirmed this visually by aligning up the udiffs of each family and switching between tabs. ??? * To highlight the text differences, I did *not* reflow the paragraphs in this webrev. I'll do that before a push. ??? * Some visitors had a tip > Note that annotating methods in concrete > subclasses with {@link java.lang.Override @Override} will help > ?ensure that methods are overridden as intended. ??? While this may have been useful back in JDK 6, I don't think it is needed in JDK 15 and I'm proposing to remove these notes. ??? * The wording in TypeKindVisitor$N was updated to explicitly mention the possibility of new enum values being added, aligning with the wording already in use in ElementKindVisitor$N. Thanks, -Joe On 3/5/2020 12:18 PM, Jonathan Gibbons wrote: > > Looks good to me. > > Consider using a ':' instead of ',' on this line in the first file: > > 66 * visitUnknown}, behavior that will be overridden in concrete > -- Jon > > On 2/26/20 10:00 PM, Joe Darcy wrote: >> Hello, >> >> Please review the documentation changes for >> >> ??? JDK-8240130: Improve and update discussion of visitor evolution >> warnings >> http://cr.openjdk.java.net/~darcy/8240130.0/ >> >> Patch below. Some discussion of and rationale for the changes, the >> original javax.lang.model visitor interfaces and concrete visitor >> types had various warning about the unusual compatibility policies >> those types would use. Unlike other post-Java SE 6 era types, it was >> anticipated methods would be added to interfaces. Prior to default >> methods in JDK 8, such additions were a highly unusual occurrence for >> public types in the JDK. After default methods were used commonly in >> jDK 8, such additions are of less concern. The risk of a true source >> compatibility is also low for a new "visitFoo" method since it will >> have a parameter of type Foo, which is new to the release, and thus >> not have an overloading conflict with a method in an existing visitor >> outside of the JDK. >> >> The warnings are thus toned down and adjusted to note that the >> envisioned additions have already occurred for prior language >> additions. For example, the current policy is only to deprecate the >> constructors of obsolete visitor classes rather than the whole class. >> The "directly or indirectly call" visitUnknown is to accurately >> describe, but not limit to, the current policy of the visitFoo >> methods in affected concrete visitors calling the visitFoo default >> method on the *interface*, which in turn calls visitUnknown. >> >> The warning text is pulled into an apiNote to avoid getting >> inherit-doc-ed for any subclasses. Once the shape of the changes for >> the interface and visitor classes are agree to, I'll replicated the >> changes for the other types. >> >> Thanks, >> >> -Joe >> >> --- >> old/src/java.compiler/share/classes/javax/lang/model/element/ElementVisitor.java >> 2020-02-26 13:13:00.848880601 -0800 >> +++ >> new/src/java.compiler/share/classes/javax/lang/model/element/ElementVisitor.java >> 2020-02-26 13:13:00.512880601 -0800 >> @@ -40,10 +40,17 @@ >> ? * is {@code null}; see documentation of the implementing class for >> ? * details. >> ? * >> - *

WARNING: It is possible that methods will be added to >> + * @apiNote >> + * >> + * WARNING: It is possible that methods will be added to >> ? * this interface to accommodate new, currently unknown, language >> ? * structures added to future versions of the Java™ programming >> - * language.? Therefore, visitor classes directly implementing this >> + * language. >> + * >> + * Such additions have already occurred to support language features >> + * added after this API was introduced. >> + * >> + * Visitor classes directly implementing this >> ? * interface may be source incompatible with future versions of the >> ? * platform.? To avoid this source incompatibility, visitor >> ? * implementations are encouraged to instead extend the appropriate >> @@ -52,21 +59,15 @@ >> ? * parameters, return type, etc. rather than one of the abstract >> ? * classes. >> ? * >> - *

Note that methods to accommodate new language constructs could >> - * be added in a source compatible way if they were added as >> - * default methods.? However, default methods are only >> - * available on Java SE 8 and higher releases and the {@code >> - * javax.lang.model.*} packages bundled in Java SE 8 were required to >> - * also be runnable on Java SE 7.? Therefore, default methods >> - * were not used when extending {@code javax.lang.model.*} >> - * to cover Java SE 8 language features.? However, default methods >> - * are used in subsequent revisions of the {@code javax.lang.model.*} >> - * packages that are only required to run on Java SE 8 and higher >> - * platform versions. >> - * >> - * @apiNote >> + *

Methods to accommodate new language constructs are expected to >> + * be added as default methods to provide strong source compatibility, >> + * as done for {@link visitModule visitModule}. The implementations of >> + * the default methods will in turn call {@link visitUnknown >> + * visitUnknown}, behavior that will be overridden in concrete >> + * visitors supporting the source version with the new language >> + * construct. >> ? * >> - * There are several families of classes implementing this visitor >> + *

There are several families of classes implementing this visitor >> ? * interface in the {@linkplain javax.lang.model.util util >> ? * package}. The families follow a naming pattern along the lines of >> ? * {@code FooVisitor}N where N indicates the >> --- >> old/src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor6.java >> 2020-02-26 13:13:01.560880601 -0800 >> +++ >> new/src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor6.java >> 2020-02-26 13:13:01.196880601 -0800 >> @@ -36,7 +36,9 @@ >> ? * appropriate for the {@link SourceVersion#RELEASE_6 RELEASE_6} >> ? * source version. >> ? * >> - *

WARNING: The {@code ElementVisitor} interface >> + * @apiNote >> + * >> + * WARNING: The {@code ElementVisitor} interface >> ? * implemented by this class may have methods added to it in the >> ? * future to accommodate new, currently unknown, language structures >> ? * added to future versions of the Java™ programming language. >> @@ -46,12 +48,12 @@ >> ? * methods with names beginning with {@code "visit"}. >> ? * >> ? *

When such a new visit method is added, the default >> - * implementation in this class will be to call the {@link >> + * implementation in this class will be to directly or indirectly >> call the {@link >> ? * #visitUnknown visitUnknown} method.? A new abstract element visitor >> ? * class will also be introduced to correspond to the new language >> ? * level; this visitor will have different default behavior for the >> - * visit method in question.? When the new visitor is introduced, all >> - * or portions of this visitor may be deprecated. >> + * visit method in question.? When a new visitor is introduced, >> + * portions of this visitor class may be deprecated, including its >> constructors. >> ? * >> ? * @param the return type of this visitor's methods. Use {@link >> ? *??????????? Void} for visitors that do not need to return results. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Thu Mar 12 17:36:53 2020 From: bsrbnd at gmail.com (B. Blaser) Date: Thu, 12 Mar 2020 18:36:53 +0100 Subject: [Feedback request] Enhancing expressions with mutability? (other use cases) In-Reply-To: References: Message-ID: To go a bit further, it'd be also possible to add another field to the 'Term' class representing the name of any quoted identifier, which can concretely be made in 'Lower' by adding a couple of lines like 'makeLit(syms.stringType, ((JCIdent _or_ JCFieldAccess)arg).name.toString())' (I can share the full diff with the previous 'quote.patch' if requested). We can then use it like '(`d _or_ `this.d).name.equals("d")' in our initial example. So, not to misunderstand me, this isn't a meta-programming facility by itself but a fortunate consequence of the quotation operator which might be used to considerably reduce the amount of code in certain situations like persistence frameworks. And note also that mutable expressions might be used to build queries using a more declarative fashion, for example. Isn't that still a direction which is worth exploring? Thanks, Bernard On Tue, 10 Mar 2020 at 22:03, B. Blaser wrote: > > Hi, > > Taking back the essential idea of the original publication on Lisp > [1], I did the attached syntactic experiment [2] trying to bring some > kind of mutability to expressions and thus giving more flexibility to > the language. I hope this subject hasn't been covered too many times, > otherwise I'd apologize for any disturbance. > > To build such mutable expressions, I've specified a new unary operator > ` along with its resulting class 'java.lang.Term'. The quotation > operator creates a 'Term' from any reference which can then be linked > to other terms to finally be evaluated to the result of a function > call for lambdas or the reference itself otherwise. > > Let's take some examples from the attached patch: > > + interface Get { > + int op(); > + } > + > + interface Sum { > + int op(int i, int j); > + } > > + int a = 0, b = 0; > + Sum s = (x, y) -> x + y; > > + public void run() { > + Get a = () -> this.a; > + Get b = () -> this.b; > + > + Term e1 = (`s).link(`a, `b); > + this.a = 1; this.b = 2; > > The above lines create a mutable expression e1 from the sum lambda s > of the getter a and b which can then be evaluated to: > > (Integer)e1.value() == 3 > > or visualized as: > > e1.toString().equals("Sum( Get( ) Get( ) )") > > An interesting application similar to ?3.g from [1] is the computation > of the partial derivative of a sum involving the mutation of the > initial expression to produce a new resulting one: > > + // Derivative of sum e with respect to r > + Term derivative(Term e, Term r) { > + if (e.terms.isEmpty()) { > + return `Integer.valueOf(e.that == r.that ? 1 : 0); > + } > + else if(e.that == (`s).that) { > + return (`s).link(derivative(e.terms.get(0), r), > derivative(e.terms.get(1), r)); > + } > + else throw new AssertionError(); > + } > > Invoking the above method like this: > > + Term e2 = derivative(e1, `a); > > creates the resulting derivative expression e2 which can then be evaluated to: > > (Integer)e2.value() == 1 > > or visualized as: > > e2.toString().equals("Sum( `1 `0 )") > > Finally, we note that any term may be quoted to prevent its > evaluation, for example: > > + Derivative d = this::derivative; > > + Term e3 = (`d).link(`e1, ``a); > > can be evaluated to: > > (Integer)((Term)e3.value()).value() == 1 > > or visualized as: > > e3.toString().equals("Derivative( `Sum( Get( ) Get( ) ) `Get( ) )") > > Of course, one of our main concern is how much do we need this and a > reasonable answer would probably be as much as we need Lisp's > S-expressions but with similar or maybe better performance than > external interpreters and a more homogeneous integration to the > language. > > Any feedback about this experiment would be welcome! > > Thanks, > Bernard > > [1] http://www-formal.stanford.edu/jmc/recursive.html > [2] quote.patch From vicente.romero at oracle.com Thu Mar 12 17:57:08 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 12 Mar 2020 13:57:08 -0400 Subject: RFR: JDK-8239447: compiler error for annotations applied to record components with target METHOD In-Reply-To: <0a251e05-1138-92e2-7b83-74fb3bb87db0@oracle.com> References: <0a251e05-1138-92e2-7b83-74fb3bb87db0@oracle.com> Message-ID: ping On 3/7/20 12:34 AM, Vicente Romero wrote: > Please review fix for [1] at [2]. When there are APs involved, every > time a new round of annotation processing will start, a visitor, see > [3], sets the attribute field of annotation ASTs to null. This visitor > was not visiting some annotations stored at the record component. This > provoked that data from previous rounds could be accessible to later > rounds provoking later annotation validation code to fail. Just > visiting the annotations at the record component as it is done for the > rest of the annotations has fixed the issue. > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8239447 > [2] http://cr.openjdk.java.net/~vromero/8239447/webrev.00/ > [3] > http://hg.openjdk.java.net/jdk/jdk/file/7af6364e1792/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java#l1591 From maurizio.cimadamore at oracle.com Fri Mar 13 00:13:54 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 13 Mar 2020 00:13:54 +0000 Subject: RFR: JDK-8239447: compiler error for annotations applied to record components with target METHOD In-Reply-To: References: <0a251e05-1138-92e2-7b83-74fb3bb87db0@oracle.com> Message-ID: Looks good - I wonder: why wasn't this failing if TYPE_USE was used as a target? I know that processing for type annotations is quite different, but I'm still a bit surprised to see that the data from previous rounds doesn't cause issues in that case. Maurizio On 12/03/2020 17:57, Vicente Romero wrote: > ping > > On 3/7/20 12:34 AM, Vicente Romero wrote: >> Please review fix for [1] at [2]. When there are APs involved, every >> time a new round of annotation processing will start, a visitor, see >> [3], sets the attribute field of annotation ASTs to null. This >> visitor was not visiting some annotations stored at the record >> component. This provoked that data from previous rounds could be >> accessible to later rounds provoking later annotation validation code >> to fail. Just visiting the annotations at the record component as it >> is done for the rest of the annotations has fixed the issue. >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8239447 >> [2] http://cr.openjdk.java.net/~vromero/8239447/webrev.00/ >> [3] >> http://hg.openjdk.java.net/jdk/jdk/file/7af6364e1792/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java#l1591 > From vicente.romero at oracle.com Fri Mar 13 06:02:20 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 13 Mar 2020 02:02:20 -0400 Subject: RFR: JDK-8239447: compiler error for annotations applied to record components with target METHOD In-Reply-To: References: <0a251e05-1138-92e2-7b83-74fb3bb87db0@oracle.com> Message-ID: <3258575e-0be8-447c-5e1a-c92736a9ab84@oracle.com> Hi On 3/12/20 8:13 PM, Maurizio Cimadamore wrote: > Looks good - I wonder: why wasn't this failing if TYPE_USE was used as > a target? I know that processing for type annotations is quite > different, but I'm still a bit surprised to see that the data from > previous rounds doesn't cause issues in that case. I also thought that the difference was due to the different nature of type annotations. But while double checking to answer you I discovered that the cause is a bug in the records implementation, let's assume we have: record R(@MyAnno int i) {} currently what is happening is that the same AST created by the parser for the annotation in the record header is shared by the generated field, the record component, the accessor and the parameter in the generated constructor. Exactly the same AST. This is the root cause behind the reason why in some cases the information from a previous round was being cleared and sometimes not. I think that a cleaner solution should be to create different ASTs per each record member. So this way each member including record components will have their own AST. This fixes this bug and probably others that were potentially lurking in this area. I have uploaded a new iteration to [1]. > > Maurizio Thanks, Vicente [1] http://cr.openjdk.java.net/~vromero/8239447/webrev.01/ > > On 12/03/2020 17:57, Vicente Romero wrote: >> ping >> >> On 3/7/20 12:34 AM, Vicente Romero wrote: >>> Please review fix for [1] at [2]. When there are APs involved, every >>> time a new round of annotation processing will start, a visitor, see >>> [3], sets the attribute field of annotation ASTs to null. This >>> visitor was not visiting some annotations stored at the record >>> component. This provoked that data from previous rounds could be >>> accessible to later rounds provoking later annotation validation >>> code to fail. Just visiting the annotations at the record component >>> as it is done for the rest of the annotations has fixed the issue. >>> >>> Thanks, >>> Vicente >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8239447 >>> [2] http://cr.openjdk.java.net/~vromero/8239447/webrev.00/ >>> [3] >>> http://hg.openjdk.java.net/jdk/jdk/file/7af6364e1792/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java#l1591 >> From maurizio.cimadamore at oracle.com Fri Mar 13 10:39:42 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 13 Mar 2020 10:39:42 +0000 Subject: RFR: JDK-8239447: compiler error for annotations applied to record components with target METHOD In-Reply-To: <3258575e-0be8-447c-5e1a-c92736a9ab84@oracle.com> References: <0a251e05-1138-92e2-7b83-74fb3bb87db0@oracle.com> <3258575e-0be8-447c-5e1a-c92736a9ab84@oracle.com> Message-ID: I agree that this is a better solution, thanks for investigating. In general sharing trees is best avoided as it can lead (as in this case) to very odd, and hard to diagnose failures. It is possible that the patch you had yesterday is also needed - you might want to double check with Jan about that; perhaps a different test case might reveal some issues with the lack of cleanup in the annotation processing round. Maurizio On 13/03/2020 06:02, Vicente Romero wrote: > Hi > > On 3/12/20 8:13 PM, Maurizio Cimadamore wrote: >> Looks good - I wonder: why wasn't this failing if TYPE_USE was used >> as a target? I know that processing for type annotations is quite >> different, but I'm still a bit surprised to see that the data from >> previous rounds doesn't cause issues in that case. > > I also thought that the difference was due to the different nature of > type annotations. But while double checking to answer you I discovered > that the cause is a bug in the records implementation, let's assume we > have: > > record R(@MyAnno int i) {} > > currently what is happening is that the same AST created by the parser > for the annotation in the record header is shared by the generated > field, the record component, the accessor and the parameter in the > generated constructor. Exactly the same AST. This is the root cause > behind the reason why in some cases the information from a previous > round was being cleared and sometimes not. I think that a cleaner > solution should be to create different ASTs per each record member. So > this way each member including record components will have their own > AST. This fixes this bug and probably others that were potentially > lurking in this area. I have uploaded a new iteration to [1]. > >> >> Maurizio > > Thanks, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8239447/webrev.01/ >> >> On 12/03/2020 17:57, Vicente Romero wrote: >>> ping >>> >>> On 3/7/20 12:34 AM, Vicente Romero wrote: >>>> Please review fix for [1] at [2]. When there are APs involved, >>>> every time a new round of annotation processing will start, a >>>> visitor, see [3], sets the attribute field of annotation ASTs to >>>> null. This visitor was not visiting some annotations stored at the >>>> record component. This provoked that data from previous rounds >>>> could be accessible to later rounds provoking later annotation >>>> validation code to fail. Just visiting the annotations at the >>>> record component as it is done for the rest of the annotations has >>>> fixed the issue. >>>> >>>> Thanks, >>>> Vicente >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8239447 >>>> [2] http://cr.openjdk.java.net/~vromero/8239447/webrev.00/ >>>> [3] >>>> http://hg.openjdk.java.net/jdk/jdk/file/7af6364e1792/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java#l1591 >>> > From vicente.romero at oracle.com Fri Mar 13 12:19:50 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 13 Mar 2020 08:19:50 -0400 Subject: RFR: JDK-8239447: compiler error for annotations applied to record components with target METHOD In-Reply-To: References: <0a251e05-1138-92e2-7b83-74fb3bb87db0@oracle.com> <3258575e-0be8-447c-5e1a-c92736a9ab84@oracle.com> Message-ID: <621ed885-6c2b-2695-a671-5afd027eec4e@oracle.com> On 3/13/20 6:39 AM, Maurizio Cimadamore wrote: > I agree that this is a better solution, thanks for investigating. > > In general sharing trees is best avoided as it can lead (as in this > case) to very odd, and hard to diagnose failures. > > It is possible that the patch you had yesterday is also needed I can add that code to be extra cautious but given the way annotations are copied, the annotations in the record component will always have that field to null. And from there the annotation is copied to the accessor and to the parameter in the canonical constructor. We can do it but I think that it is not necessary > - you might want to double check with Jan about that; perhaps a > different test case might reveal some issues with the lack of cleanup > in the annotation processing round. > > Maurizio Vicente > > On 13/03/2020 06:02, Vicente Romero wrote: >> Hi >> >> On 3/12/20 8:13 PM, Maurizio Cimadamore wrote: >>> Looks good - I wonder: why wasn't this failing if TYPE_USE was used >>> as a target? I know that processing for type annotations is quite >>> different, but I'm still a bit surprised to see that the data from >>> previous rounds doesn't cause issues in that case. >> >> I also thought that the difference was due to the different nature of >> type annotations. But while double checking to answer you I >> discovered that the cause is a bug in the records implementation, >> let's assume we have: >> >> record R(@MyAnno int i) {} >> >> currently what is happening is that the same AST created by the >> parser for the annotation in the record header is shared by the >> generated field, the record component, the accessor and the parameter >> in the generated constructor. Exactly the same AST. This is the root >> cause behind the reason why in some cases the information from a >> previous round was being cleared and sometimes not. I think that a >> cleaner solution should be to create different ASTs per each record >> member. So this way each member including record components will have >> their own AST. This fixes this bug and probably others that were >> potentially lurking in this area. I have uploaded a new iteration to >> [1]. >> >>> >>> Maurizio >> >> Thanks, >> Vicente >> >> [1] http://cr.openjdk.java.net/~vromero/8239447/webrev.01/ >>> >>> On 12/03/2020 17:57, Vicente Romero wrote: >>>> ping >>>> >>>> On 3/7/20 12:34 AM, Vicente Romero wrote: >>>>> Please review fix for [1] at [2]. When there are APs involved, >>>>> every time a new round of annotation processing will start, a >>>>> visitor, see [3], sets the attribute field of annotation ASTs to >>>>> null. This visitor was not visiting some annotations stored at the >>>>> record component. This provoked that data from previous rounds >>>>> could be accessible to later rounds provoking later annotation >>>>> validation code to fail. Just visiting the annotations at the >>>>> record component as it is done for the rest of the annotations has >>>>> fixed the issue. >>>>> >>>>> Thanks, >>>>> Vicente >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8239447 >>>>> [2] http://cr.openjdk.java.net/~vromero/8239447/webrev.00/ >>>>> [3] >>>>> http://hg.openjdk.java.net/jdk/jdk/file/7af6364e1792/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java#l1591 >>>> >> From jan.lahoda at oracle.com Fri Mar 13 12:20:48 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 13 Mar 2020 13:20:48 +0100 Subject: RFR: JDK-8240658: Code completion not working for lambdas in method invocations that require type inference Message-ID: Hi, When a method invocation requires type inference, and the user is in the process of typing of a (block) lambda that is a parameter to the method invocation, javac may not, in some cases, perform the type inference, which then may lead to non working code completion in JShell (and possibly other tools). For example (in JShell): Arrays.stream(new Integer[]{1}).forEach(v -> { System.err.println(v. and press - this leads to no proposals currently, as the type of "v" is not inferred. The idea of the proposed patch is to improve the recovery in cases significant for cases where the text is being typed, and allow type inference in these cases. The type of "v" is then inferred, and the code completion works. Proposed patch: http://cr.openjdk.java.net/~jlahoda/8240658/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8240658 Thanks, Jan From jan.lahoda at oracle.com Fri Mar 13 12:24:47 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 13 Mar 2020 13:24:47 +0100 Subject: RFR: JDK-8240964: Compilation error thrown when long literal used with yield Message-ID: <9d924347-b3d1-0ac3-d12e-aa70a04a5899@oracle.com> Hi, The code that detects whether "yield" is a keyword for the yield statement or not is accidentally not handling long literals properly, and decides "yield 0L;" is not a yield statement, which leads to an improper compile-time error. The proposed patch is to simply handle the long literals properly. Proposed patch: http://cr.openjdk.java.net/~jlahoda/8240964/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8240964 How does this look? Thanks, Jan From vicente.romero at oracle.com Fri Mar 13 12:45:55 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 13 Mar 2020 08:45:55 -0400 Subject: RFR: JDK-8239447: compiler error for annotations applied to record components with target METHOD In-Reply-To: References: <0a251e05-1138-92e2-7b83-74fb3bb87db0@oracle.com> <3258575e-0be8-447c-5e1a-c92736a9ab84@oracle.com> Message-ID: <78b741bb-2e33-cf6a-4c20-24328bae420e@oracle.com> I have modified the patch to include the previous code too, please check [1] Thanks, Vicente [1] http://cr.openjdk.java.net/~vromero/8239447/webrev.02/ On 3/13/20 6:39 AM, Maurizio Cimadamore wrote: > I agree that this is a better solution, thanks for investigating. > > In general sharing trees is best avoided as it can lead (as in this > case) to very odd, and hard to diagnose failures. > > It is possible that the patch you had yesterday is also needed - you > might want to double check with Jan about that; perhaps a different > test case might reveal some issues with the lack of cleanup in the > annotation processing round. > > Maurizio > > On 13/03/2020 06:02, Vicente Romero wrote: >> Hi >> >> On 3/12/20 8:13 PM, Maurizio Cimadamore wrote: >>> Looks good - I wonder: why wasn't this failing if TYPE_USE was used >>> as a target? I know that processing for type annotations is quite >>> different, but I'm still a bit surprised to see that the data from >>> previous rounds doesn't cause issues in that case. >> >> I also thought that the difference was due to the different nature of >> type annotations. But while double checking to answer you I >> discovered that the cause is a bug in the records implementation, >> let's assume we have: >> >> record R(@MyAnno int i) {} >> >> currently what is happening is that the same AST created by the >> parser for the annotation in the record header is shared by the >> generated field, the record component, the accessor and the parameter >> in the generated constructor. Exactly the same AST. This is the root >> cause behind the reason why in some cases the information from a >> previous round was being cleared and sometimes not. I think that a >> cleaner solution should be to create different ASTs per each record >> member. So this way each member including record components will have >> their own AST. This fixes this bug and probably others that were >> potentially lurking in this area. I have uploaded a new iteration to >> [1]. >> >>> >>> Maurizio >> >> Thanks, >> Vicente >> >> [1] http://cr.openjdk.java.net/~vromero/8239447/webrev.01/ >>> >>> On 12/03/2020 17:57, Vicente Romero wrote: >>>> ping >>>> >>>> On 3/7/20 12:34 AM, Vicente Romero wrote: >>>>> Please review fix for [1] at [2]. When there are APs involved, >>>>> every time a new round of annotation processing will start, a >>>>> visitor, see [3], sets the attribute field of annotation ASTs to >>>>> null. This visitor was not visiting some annotations stored at the >>>>> record component. This provoked that data from previous rounds >>>>> could be accessible to later rounds provoking later annotation >>>>> validation code to fail. Just visiting the annotations at the >>>>> record component as it is done for the rest of the annotations has >>>>> fixed the issue. >>>>> >>>>> Thanks, >>>>> Vicente >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8239447 >>>>> [2] http://cr.openjdk.java.net/~vromero/8239447/webrev.00/ >>>>> [3] >>>>> http://hg.openjdk.java.net/jdk/jdk/file/7af6364e1792/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java#l1591 >>>> >> From maurizio.cimadamore at oracle.com Fri Mar 13 13:07:57 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 13 Mar 2020 13:07:57 +0000 Subject: RFR: JDK-8239447: compiler error for annotations applied to record components with target METHOD In-Reply-To: <78b741bb-2e33-cf6a-4c20-24328bae420e@oracle.com> References: <0a251e05-1138-92e2-7b83-74fb3bb87db0@oracle.com> <3258575e-0be8-447c-5e1a-c92736a9ab84@oracle.com> <78b741bb-2e33-cf6a-4c20-24328bae420e@oracle.com> Message-ID: <4dab6210-7f38-9ba9-fe49-8073d1d33090@oracle.com> Looks good Maurizio On 13/03/2020 12:45, Vicente Romero wrote: > I have modified the patch to include the previous code too, please > check [1] > > Thanks, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8239447/webrev.02/ > > On 3/13/20 6:39 AM, Maurizio Cimadamore wrote: >> I agree that this is a better solution, thanks for investigating. >> >> In general sharing trees is best avoided as it can lead (as in this >> case) to very odd, and hard to diagnose failures. >> >> It is possible that the patch you had yesterday is also needed - you >> might want to double check with Jan about that; perhaps a different >> test case might reveal some issues with the lack of cleanup in the >> annotation processing round. >> >> Maurizio >> >> On 13/03/2020 06:02, Vicente Romero wrote: >>> Hi >>> >>> On 3/12/20 8:13 PM, Maurizio Cimadamore wrote: >>>> Looks good - I wonder: why wasn't this failing if TYPE_USE was used >>>> as a target? I know that processing for type annotations is quite >>>> different, but I'm still a bit surprised to see that the data from >>>> previous rounds doesn't cause issues in that case. >>> >>> I also thought that the difference was due to the different nature >>> of type annotations. But while double checking to answer you I >>> discovered that the cause is a bug in the records implementation, >>> let's assume we have: >>> >>> record R(@MyAnno int i) {} >>> >>> currently what is happening is that the same AST created by the >>> parser for the annotation in the record header is shared by the >>> generated field, the record component, the accessor and the >>> parameter in the generated constructor. Exactly the same AST. This >>> is the root cause behind the reason why in some cases the >>> information from a previous round was being cleared and sometimes >>> not. I think that a cleaner solution should be to create different >>> ASTs per each record member. So this way each member including >>> record components will have their own AST. This fixes this bug and >>> probably others that were potentially lurking in this area. I have >>> uploaded a new iteration to [1]. >>> >>>> >>>> Maurizio >>> >>> Thanks, >>> Vicente >>> >>> [1] http://cr.openjdk.java.net/~vromero/8239447/webrev.01/ >>>> >>>> On 12/03/2020 17:57, Vicente Romero wrote: >>>>> ping >>>>> >>>>> On 3/7/20 12:34 AM, Vicente Romero wrote: >>>>>> Please review fix for [1] at [2]. When there are APs involved, >>>>>> every time a new round of annotation processing will start, a >>>>>> visitor, see [3], sets the attribute field of annotation ASTs to >>>>>> null. This visitor was not visiting some annotations stored at >>>>>> the record component. This provoked that data from previous >>>>>> rounds could be accessible to later rounds provoking later >>>>>> annotation validation code to fail. Just visiting the annotations >>>>>> at the record component as it is done for the rest of the >>>>>> annotations has fixed the issue. >>>>>> >>>>>> Thanks, >>>>>> Vicente >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8239447 >>>>>> [2] http://cr.openjdk.java.net/~vromero/8239447/webrev.00/ >>>>>> [3] >>>>>> http://hg.openjdk.java.net/jdk/jdk/file/7af6364e1792/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java#l1591 >>>>> >>> > From maurizio.cimadamore at oracle.com Fri Mar 13 13:14:32 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 13 Mar 2020 13:14:32 +0000 Subject: RFR: JDK-8240964: Compilation error thrown when long literal used with yield In-Reply-To: <9d924347-b3d1-0ac3-d12e-aa70a04a5899@oracle.com> References: <9d924347-b3d1-0ac3-d12e-aa70a04a5899@oracle.com> Message-ID: <44ba7d08-0345-8a18-a4c8-62c4877fdeec@oracle.com> Looks good Maurizio On 13/03/2020 12:24, Jan Lahoda wrote: > Hi, > > The code that detects whether "yield" is a keyword for the yield > statement or not is accidentally not handling long literals properly, > and decides "yield 0L;" is not a yield statement, which leads to an > improper compile-time error. The proposed patch is to simply handle > the long literals properly. > > Proposed patch: > http://cr.openjdk.java.net/~jlahoda/8240964/webrev.00/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8240964 > > How does this look? > > Thanks, > ??? Jan > From vicente.romero at oracle.com Fri Mar 13 13:24:08 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 13 Mar 2020 09:24:08 -0400 Subject: RFR: JDK-8239447: compiler error for annotations applied to record components with target METHOD In-Reply-To: <4dab6210-7f38-9ba9-fe49-8073d1d33090@oracle.com> References: <0a251e05-1138-92e2-7b83-74fb3bb87db0@oracle.com> <3258575e-0be8-447c-5e1a-c92736a9ab84@oracle.com> <78b741bb-2e33-cf6a-4c20-24328bae420e@oracle.com> <4dab6210-7f38-9ba9-fe49-8073d1d33090@oracle.com> Message-ID: thanks, Vicente On 3/13/20 9:07 AM, Maurizio Cimadamore wrote: > Looks good > > Maurizio > > On 13/03/2020 12:45, Vicente Romero wrote: >> I have modified the patch to include the previous code too, please >> check [1] >> >> Thanks, >> Vicente >> >> [1] http://cr.openjdk.java.net/~vromero/8239447/webrev.02/ >> >> On 3/13/20 6:39 AM, Maurizio Cimadamore wrote: >>> I agree that this is a better solution, thanks for investigating. >>> >>> In general sharing trees is best avoided as it can lead (as in this >>> case) to very odd, and hard to diagnose failures. >>> >>> It is possible that the patch you had yesterday is also needed - you >>> might want to double check with Jan about that; perhaps a different >>> test case might reveal some issues with the lack of cleanup in the >>> annotation processing round. >>> >>> Maurizio >>> >>> On 13/03/2020 06:02, Vicente Romero wrote: >>>> Hi >>>> >>>> On 3/12/20 8:13 PM, Maurizio Cimadamore wrote: >>>>> Looks good - I wonder: why wasn't this failing if TYPE_USE was >>>>> used as a target? I know that processing for type annotations is >>>>> quite different, but I'm still a bit surprised to see that the >>>>> data from previous rounds doesn't cause issues in that case. >>>> >>>> I also thought that the difference was due to the different nature >>>> of type annotations. But while double checking to answer you I >>>> discovered that the cause is a bug in the records implementation, >>>> let's assume we have: >>>> >>>> record R(@MyAnno int i) {} >>>> >>>> currently what is happening is that the same AST created by the >>>> parser for the annotation in the record header is shared by the >>>> generated field, the record component, the accessor and the >>>> parameter in the generated constructor. Exactly the same AST. This >>>> is the root cause behind the reason why in some cases the >>>> information from a previous round was being cleared and sometimes >>>> not. I think that a cleaner solution should be to create different >>>> ASTs per each record member. So this way each member including >>>> record components will have their own AST. This fixes this bug and >>>> probably others that were potentially lurking in this area. I have >>>> uploaded a new iteration to [1]. >>>> >>>>> >>>>> Maurizio >>>> >>>> Thanks, >>>> Vicente >>>> >>>> [1] http://cr.openjdk.java.net/~vromero/8239447/webrev.01/ >>>>> >>>>> On 12/03/2020 17:57, Vicente Romero wrote: >>>>>> ping >>>>>> >>>>>> On 3/7/20 12:34 AM, Vicente Romero wrote: >>>>>>> Please review fix for [1] at [2]. When there are APs involved, >>>>>>> every time a new round of annotation processing will start, a >>>>>>> visitor, see [3], sets the attribute field of annotation ASTs to >>>>>>> null. This visitor was not visiting some annotations stored at >>>>>>> the record component. This provoked that data from previous >>>>>>> rounds could be accessible to later rounds provoking later >>>>>>> annotation validation code to fail. Just visiting the >>>>>>> annotations at the record component as it is done for the rest >>>>>>> of the annotations has fixed the issue. >>>>>>> >>>>>>> Thanks, >>>>>>> Vicente >>>>>>> >>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8239447 >>>>>>> [2] http://cr.openjdk.java.net/~vromero/8239447/webrev.00/ >>>>>>> [3] >>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/7af6364e1792/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java#l1591 >>>>>> >>>> >> From pavel.rappo at oracle.com Fri Mar 13 15:42:03 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 13 Mar 2020 15:42:03 +0000 Subject: RFR [15] 8241014: Miscellaneous typos in documentation comments Message-ID: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> Hello, Please review the change for https://bugs.openjdk.java.net/browse/JDK-8241014: http://cr.openjdk.java.net/~prappo/8241014/webrev.00/ This is a documentation cleanup. There are no code changes involved, and the changes in documentation are mostly trivial. The following packages are affected: java.lang, java.nio.file, java.nio.file.attribute, java.security, java.time.chrono, java.time.temporal, java.util, java.util.regex, java.util.stream, javax.crypto, javax.security.cert, javax.tools That said, there are two changes that I'd prefer to be carefully reviewed by the experts in the corresponding areas. The first one is for a suspected typo in the javax.crypto.CryptoPolicyParser class, "AlgrithomParameterSpec". It is not unheard-of for typos to be kept and supported for the sake of backward compatibility. Sadly, we have a number of those in OpenJDK. Even though I performed reasonable checks, the proposed fix should better be verified by the security folk. The second one is for the doc comment for the java.util.stream.Stream.collect method. @apiNote The following will accumulate strings into an ArrayList: List asList = stringStream.collect(Collectors.toList()); Given that the spec for Collectors.toList() clearly says that ...There are no guarantees on the type, mutability, serializability, or thread-safety of the List returned;... I'd assume that @apiNote should be fixed as proposed. -Pavel P.S. Apologies for spamming multiple mailing lists. From Roger.Riggs at oracle.com Fri Mar 13 18:15:10 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 13 Mar 2020 14:15:10 -0400 Subject: RFR [15] 8241014: Miscellaneous typos in documentation comments In-Reply-To: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> References: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> Message-ID: Looks fine. On 3/13/20 11:42 AM, Pavel Rappo wrote: > Hello, > > Please review the change for https://bugs.openjdk.java.net/browse/JDK-8241014: > > http://cr.openjdk.java.net/~prappo/8241014/webrev.00/ > > This is a documentation cleanup. There are no code changes involved, > and the changes in documentation are mostly trivial. > > The following packages are affected: > > java.lang, > java.nio.file, > java.nio.file.attribute, > java.security, > java.time.chrono, > java.time.temporal, > java.util, > java.util.regex, > java.util.stream, > javax.crypto, > javax.security.cert, > javax.tools > > That said, there are two changes that I'd prefer to be carefully reviewed by > the experts in the corresponding areas. > > The first one is for a suspected typo in the javax.crypto.CryptoPolicyParser > class, "AlgrithomParameterSpec". It is not unheard-of for typos to be kept and > supported for the sake of backward compatibility. Sadly, we have a number of > those in OpenJDK. Even though I performed reasonable checks, the proposed fix > should better be verified by the security folk. > > The second one is for the doc comment for the java.util.stream.Stream.collect method. > > @apiNote > The following will accumulate strings into an ArrayList: > > List asList = stringStream.collect(Collectors.toList()); > > Given that the spec for Collectors.toList() clearly says that > > ...There are no guarantees on the type, mutability, serializability, or > thread-safety of the List returned;... > > I'd assume that @apiNote should be fixed as proposed. > > -Pavel > > P.S. Apologies for spamming multiple mailing lists. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Fri Mar 13 18:16:46 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 13 Mar 2020 11:16:46 -0700 Subject: JDK 15 RFR of JDK-8240130: Improve and update discussion of visitor evolution warnings In-Reply-To: <12938504-53ab-57f6-7aea-86ed44a2cfbf@oracle.com> References: <0a7353aa-9c06-aa47-145c-765bf2069f89@oracle.com> <12938504-53ab-57f6-7aea-86ed44a2cfbf@oracle.com> Message-ID: <307df662-474b-3558-1df4-1069628ddd67@oracle.com> Hello, Following an off-list suggestion from Jon, I've re-worked the change to remove most of the WARNING paragraphs and replace them with @see links: ??? http://cr.openjdk.java.net/~darcy/8240130.2 Each root visitor/scanner has a slightly different wording; the element kind visitor is not strictly correct without a specialized wording. Therefore, visitors other than the AbstractFooVisitor6 have warning paragraphs. Thanks Jon for the helpful suggestion. -Joe On 3/10/2020 10:09 PM, Joe Darcy wrote: > > Hello, > > Updated and expanded version of the webrev: > > http://cr.openjdk.java.net/~darcy/8240130.1 > > A few notes on reviewing: > > ??? * The delta for each FooVisitor$N utility visitor family should be > the same. I confirmed this visually by aligning up the udiffs of each > family and switching between tabs. > > ??? * To highlight the text differences, I did *not* reflow the > paragraphs in this webrev. I'll do that before a push. > > ??? * Some visitors had a tip > >> Note that annotating methods in concrete >> subclasses with {@link java.lang.Override @Override} will help >> ?ensure that methods are overridden as intended. > > ??? While this may have been useful back in JDK 6, I don't think it is > needed in JDK 15 and I'm proposing to remove these notes. > > ??? * The wording in TypeKindVisitor$N was updated to explicitly > mention the possibility of new enum values being added, aligning with > the wording already in use in ElementKindVisitor$N. > > Thanks, > > -Joe > > > On 3/5/2020 12:18 PM, Jonathan Gibbons wrote: >> >> Looks good to me. >> >> Consider using a ':' instead of ',' on this line in the first file: >> >> 66 * visitUnknown}, behavior that will be overridden in concrete >> -- Jon >> >> On 2/26/20 10:00 PM, Joe Darcy wrote: >>> Hello, >>> >>> Please review the documentation changes for >>> >>> ??? JDK-8240130: Improve and update discussion of visitor evolution >>> warnings >>> http://cr.openjdk.java.net/~darcy/8240130.0/ >>> >>> Patch below. Some discussion of and rationale for the changes, the >>> original javax.lang.model visitor interfaces and concrete visitor >>> types had various warning about the unusual compatibility policies >>> those types would use. Unlike other post-Java SE 6 era types, it was >>> anticipated methods would be added to interfaces. Prior to default >>> methods in JDK 8, such additions were a highly unusual occurrence >>> for public types in the JDK. After default methods were used >>> commonly in jDK 8, such additions are of less concern. The risk of a >>> true source compatibility is also low for a new "visitFoo" method >>> since it will have a parameter of type Foo, which is new to the >>> release, and thus not have an overloading conflict with a method in >>> an existing visitor outside of the JDK. >>> >>> The warnings are thus toned down and adjusted to note that the >>> envisioned additions have already occurred for prior language >>> additions. For example, the current policy is only to deprecate the >>> constructors of obsolete visitor classes rather than the whole >>> class. The "directly or indirectly call" visitUnknown is to >>> accurately describe, but not limit to, the current policy of the >>> visitFoo methods in affected concrete visitors calling the visitFoo >>> default method on the *interface*, which in turn calls visitUnknown. >>> >>> The warning text is pulled into an apiNote to avoid getting >>> inherit-doc-ed for any subclasses. Once the shape of the changes for >>> the interface and visitor classes are agree to, I'll replicated the >>> changes for the other types. >>> >>> Thanks, >>> >>> -Joe >>> >>> --- >>> old/src/java.compiler/share/classes/javax/lang/model/element/ElementVisitor.java >>> 2020-02-26 13:13:00.848880601 -0800 >>> +++ >>> new/src/java.compiler/share/classes/javax/lang/model/element/ElementVisitor.java >>> 2020-02-26 13:13:00.512880601 -0800 >>> @@ -40,10 +40,17 @@ >>> ? * is {@code null}; see documentation of the implementing class for >>> ? * details. >>> ? * >>> - *

WARNING: It is possible that methods will be added to >>> + * @apiNote >>> + * >>> + * WARNING: It is possible that methods will be added to >>> ? * this interface to accommodate new, currently unknown, language >>> ? * structures added to future versions of the Java™ programming >>> - * language.? Therefore, visitor classes directly implementing this >>> + * language. >>> + * >>> + * Such additions have already occurred to support language features >>> + * added after this API was introduced. >>> + * >>> + * Visitor classes directly implementing this >>> ? * interface may be source incompatible with future versions of the >>> ? * platform.? To avoid this source incompatibility, visitor >>> ? * implementations are encouraged to instead extend the appropriate >>> @@ -52,21 +59,15 @@ >>> ? * parameters, return type, etc. rather than one of the abstract >>> ? * classes. >>> ? * >>> - *

Note that methods to accommodate new language constructs could >>> - * be added in a source compatible way if they were added as >>> - * default methods.? However, default methods are only >>> - * available on Java SE 8 and higher releases and the {@code >>> - * javax.lang.model.*} packages bundled in Java SE 8 were required to >>> - * also be runnable on Java SE 7.? Therefore, default methods >>> - * were not used when extending {@code javax.lang.model.*} >>> - * to cover Java SE 8 language features.? However, default methods >>> - * are used in subsequent revisions of the {@code javax.lang.model.*} >>> - * packages that are only required to run on Java SE 8 and higher >>> - * platform versions. >>> - * >>> - * @apiNote >>> + *

Methods to accommodate new language constructs are expected to >>> + * be added as default methods to provide strong source compatibility, >>> + * as done for {@link visitModule visitModule}. The implementations of >>> + * the default methods will in turn call {@link visitUnknown >>> + * visitUnknown}, behavior that will be overridden in concrete >>> + * visitors supporting the source version with the new language >>> + * construct. >>> ? * >>> - * There are several families of classes implementing this visitor >>> + *

There are several families of classes implementing this visitor >>> ? * interface in the {@linkplain javax.lang.model.util util >>> ? * package}. The families follow a naming pattern along the lines of >>> ? * {@code FooVisitor}N where N indicates the >>> --- >>> old/src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor6.java >>> 2020-02-26 13:13:01.560880601 -0800 >>> +++ >>> new/src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor6.java >>> 2020-02-26 13:13:01.196880601 -0800 >>> @@ -36,7 +36,9 @@ >>> ? * appropriate for the {@link SourceVersion#RELEASE_6 RELEASE_6} >>> ? * source version. >>> ? * >>> - *

WARNING: The {@code ElementVisitor} interface >>> + * @apiNote >>> + * >>> + * WARNING: The {@code ElementVisitor} interface >>> ? * implemented by this class may have methods added to it in the >>> ? * future to accommodate new, currently unknown, language structures >>> ? * added to future versions of the Java™ programming language. >>> @@ -46,12 +48,12 @@ >>> ? * methods with names beginning with {@code "visit"}. >>> ? * >>> ? *

When such a new visit method is added, the default >>> - * implementation in this class will be to call the {@link >>> + * implementation in this class will be to directly or indirectly >>> call the {@link >>> ? * #visitUnknown visitUnknown} method.? A new abstract element visitor >>> ? * class will also be introduced to correspond to the new language >>> ? * level; this visitor will have different default behavior for the >>> - * visit method in question.? When the new visitor is introduced, all >>> - * or portions of this visitor may be deprecated. >>> + * visit method in question.? When a new visitor is introduced, >>> + * portions of this visitor class may be deprecated, including its >>> constructors. >>> ? * >>> ? * @param the return type of this visitor's methods. Use {@link >>> ? *??????????? Void} for visitors that do not need to return results. >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Fri Mar 13 18:38:02 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 13 Mar 2020 11:38:02 -0700 Subject: JDK 15 RFR of JDK-8240130: Improve and update discussion of visitor evolution warnings In-Reply-To: <307df662-474b-3558-1df4-1069628ddd67@oracle.com> References: <0a7353aa-9c06-aa47-145c-765bf2069f89@oracle.com> <12938504-53ab-57f6-7aea-86ed44a2cfbf@oracle.com> <307df662-474b-3558-1df4-1069628ddd67@oracle.com> Message-ID: <322a55d0-08e9-1609-370c-07fc0b38f60f@oracle.com> Generally OK, although you may have removed a bit too much text (i.e. the @param tags) in src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor8.java I note inconsistent use of a blank line after `@apiNote`. I'm not sure if that is intentional. -- Jon On 03/13/2020 11:16 AM, Joe Darcy wrote: > > Hello, > > Following an off-list suggestion from Jon, I've re-worked the change > to remove most of the WARNING paragraphs and replace them with @see links: > > http://cr.openjdk.java.net/~darcy/8240130.2 > > Each root visitor/scanner has a slightly different wording; the > element kind visitor is not strictly correct without a specialized > wording. Therefore, visitors other than the AbstractFooVisitor6 have > warning paragraphs. > > Thanks Jon for the helpful suggestion. > > -Joe > > On 3/10/2020 10:09 PM, Joe Darcy wrote: >> >> Hello, >> >> Updated and expanded version of the webrev: >> >> http://cr.openjdk.java.net/~darcy/8240130.1 >> >> A few notes on reviewing: >> >> ??? * The delta for each FooVisitor$N utility visitor family should >> be the same. I confirmed this visually by aligning up the udiffs of >> each family and switching between tabs. >> >> ??? * To highlight the text differences, I did *not* reflow the >> paragraphs in this webrev. I'll do that before a push. >> >> ??? * Some visitors had a tip >> >>> Note that annotating methods in concrete >>> subclasses with {@link java.lang.Override @Override} will help >>> ?ensure that methods are overridden as intended. >> >> ??? While this may have been useful back in JDK 6, I don't think it >> is needed in JDK 15 and I'm proposing to remove these notes. >> >> ??? * The wording in TypeKindVisitor$N was updated to explicitly >> mention the possibility of new enum values being added, aligning with >> the wording already in use in ElementKindVisitor$N. >> >> Thanks, >> >> -Joe >> >> >> On 3/5/2020 12:18 PM, Jonathan Gibbons wrote: >>> >>> Looks good to me. >>> >>> Consider using a ':' instead of ',' on this line in the first file: >>> >>> 66 * visitUnknown}, behavior that will be overridden in concrete >>> -- Jon >>> >>> On 2/26/20 10:00 PM, Joe Darcy wrote: >>>> Hello, >>>> >>>> Please review the documentation changes for >>>> >>>> ??? JDK-8240130: Improve and update discussion of visitor evolution >>>> warnings >>>> http://cr.openjdk.java.net/~darcy/8240130.0/ >>>> >>>> Patch below. Some discussion of and rationale for the changes, the >>>> original javax.lang.model visitor interfaces and concrete visitor >>>> types had various warning about the unusual compatibility policies >>>> those types would use. Unlike other post-Java SE 6 era types, it >>>> was anticipated methods would be added to interfaces. Prior to >>>> default methods in JDK 8, such additions were a highly unusual >>>> occurrence for public types in the JDK. After default methods were >>>> used commonly in jDK 8, such additions are of less concern. The >>>> risk of a true source compatibility is also low for a new >>>> "visitFoo" method since it will have a parameter of type Foo, which >>>> is new to the release, and thus not have an overloading conflict >>>> with a method in an existing visitor outside of the JDK. >>>> >>>> The warnings are thus toned down and adjusted to note that the >>>> envisioned additions have already occurred for prior language >>>> additions. For example, the current policy is only to deprecate the >>>> constructors of obsolete visitor classes rather than the whole >>>> class. The "directly or indirectly call" visitUnknown is to >>>> accurately describe, but not limit to, the current policy of the >>>> visitFoo methods in affected concrete visitors calling the visitFoo >>>> default method on the *interface*, which in turn calls visitUnknown. >>>> >>>> The warning text is pulled into an apiNote to avoid getting >>>> inherit-doc-ed for any subclasses. Once the shape of the changes >>>> for the interface and visitor classes are agree to, I'll replicated >>>> the changes for the other types. >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>>> --- >>>> old/src/java.compiler/share/classes/javax/lang/model/element/ElementVisitor.java >>>> 2020-02-26 13:13:00.848880601 -0800 >>>> +++ >>>> new/src/java.compiler/share/classes/javax/lang/model/element/ElementVisitor.java >>>> 2020-02-26 13:13:00.512880601 -0800 >>>> @@ -40,10 +40,17 @@ >>>> ? * is {@code null}; see documentation of the implementing class for >>>> ? * details. >>>> ? * >>>> - *

WARNING: It is possible that methods will be added to >>>> + * @apiNote >>>> + * >>>> + * WARNING: It is possible that methods will be added to >>>> ? * this interface to accommodate new, currently unknown, language >>>> ? * structures added to future versions of the Java™ programming >>>> - * language.? Therefore, visitor classes directly implementing this >>>> + * language. >>>> + * >>>> + * Such additions have already occurred to support language features >>>> + * added after this API was introduced. >>>> + * >>>> + * Visitor classes directly implementing this >>>> ? * interface may be source incompatible with future versions of the >>>> ? * platform.? To avoid this source incompatibility, visitor >>>> ? * implementations are encouraged to instead extend the appropriate >>>> @@ -52,21 +59,15 @@ >>>> ? * parameters, return type, etc. rather than one of the abstract >>>> ? * classes. >>>> ? * >>>> - *

Note that methods to accommodate new language constructs could >>>> - * be added in a source compatible way if they were added as >>>> - * default methods.? However, default methods are only >>>> - * available on Java SE 8 and higher releases and the {@code >>>> - * javax.lang.model.*} packages bundled in Java SE 8 were required to >>>> - * also be runnable on Java SE 7.? Therefore, default methods >>>> - * were not used when extending {@code javax.lang.model.*} >>>> - * to cover Java SE 8 language features.? However, default methods >>>> - * are used in subsequent revisions of the {@code javax.lang.model.*} >>>> - * packages that are only required to run on Java SE 8 and higher >>>> - * platform versions. >>>> - * >>>> - * @apiNote >>>> + *

Methods to accommodate new language constructs are expected to >>>> + * be added as default methods to provide strong source >>>> compatibility, >>>> + * as done for {@link visitModule visitModule}. The >>>> implementations of >>>> + * the default methods will in turn call {@link visitUnknown >>>> + * visitUnknown}, behavior that will be overridden in concrete >>>> + * visitors supporting the source version with the new language >>>> + * construct. >>>> ? * >>>> - * There are several families of classes implementing this visitor >>>> + *

There are several families of classes implementing this visitor >>>> ? * interface in the {@linkplain javax.lang.model.util util >>>> ? * package}. The families follow a naming pattern along the lines of >>>> ? * {@code FooVisitor}N where N indicates the >>>> --- >>>> old/src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor6.java >>>> 2020-02-26 13:13:01.560880601 -0800 >>>> +++ >>>> new/src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor6.java >>>> 2020-02-26 13:13:01.196880601 -0800 >>>> @@ -36,7 +36,9 @@ >>>> ? * appropriate for the {@link SourceVersion#RELEASE_6 RELEASE_6} >>>> ? * source version. >>>> ? * >>>> - *

WARNING: The {@code ElementVisitor} interface >>>> + * @apiNote >>>> + * >>>> + * WARNING: The {@code ElementVisitor} interface >>>> ? * implemented by this class may have methods added to it in the >>>> ? * future to accommodate new, currently unknown, language structures >>>> ? * added to future versions of the Java™ programming language. >>>> @@ -46,12 +48,12 @@ >>>> ? * methods with names beginning with {@code "visit"}. >>>> ? * >>>> ? *

When such a new visit method is added, the default >>>> - * implementation in this class will be to call the {@link >>>> + * implementation in this class will be to directly or indirectly >>>> call the {@link >>>> ? * #visitUnknown visitUnknown} method.? A new abstract element >>>> visitor >>>> ? * class will also be introduced to correspond to the new language >>>> ? * level; this visitor will have different default behavior for the >>>> - * visit method in question.? When the new visitor is introduced, all >>>> - * or portions of this visitor may be deprecated. >>>> + * visit method in question.? When a new visitor is introduced, >>>> + * portions of this visitor class may be deprecated, including its >>>> constructors. >>>> ? * >>>> ? * @param the return type of this visitor's methods. Use {@link >>>> ? *??????????? Void} for visitors that do not need to return results. >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Fri Mar 13 19:13:52 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 13 Mar 2020 12:13:52 -0700 Subject: JDK 15 RFR of JDK-8240130: Improve and update discussion of visitor evolution warnings In-Reply-To: <322a55d0-08e9-1609-370c-07fc0b38f60f@oracle.com> References: <0a7353aa-9c06-aa47-145c-765bf2069f89@oracle.com> <12938504-53ab-57f6-7aea-86ed44a2cfbf@oracle.com> <307df662-474b-3558-1df4-1069628ddd67@oracle.com> <322a55d0-08e9-1609-370c-07fc0b38f60f@oracle.com> Message-ID: <3994368d-9380-19d6-609a-432cc51e963b@oracle.com> On 3/13/2020 11:38 AM, Jonathan Gibbons wrote: > > Generally OK, although you may have removed a bit too much text (i.e. > the @param tags) in > src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor8.java > Thanks for catching this; will fix before pushing. > I note inconsistent use of a blank line after `@apiNote`. I'm not sure > if that is intentional. > Before pushing, I'll re-flow the paragraphs and delete and a spacer line between @apiNote and the subsequent text. -Joe > -- Jon > > > On 03/13/2020 11:16 AM, Joe Darcy wrote: >> >> Hello, >> >> Following an off-list suggestion from Jon, I've re-worked the change >> to remove most of the WARNING paragraphs and replace them with @see >> links: >> >> http://cr.openjdk.java.net/~darcy/8240130.2 >> >> Each root visitor/scanner has a slightly different wording; the >> element kind visitor is not strictly correct without a specialized >> wording. Therefore, visitors other than the AbstractFooVisitor6 have >> warning paragraphs. >> >> Thanks Jon for the helpful suggestion. >> >> -Joe >> >> On 3/10/2020 10:09 PM, Joe Darcy wrote: >>> >>> Hello, >>> >>> Updated and expanded version of the webrev: >>> >>> http://cr.openjdk.java.net/~darcy/8240130.1 >>> >>> A few notes on reviewing: >>> >>> ??? * The delta for each FooVisitor$N utility visitor family should >>> be the same. I confirmed this visually by aligning up the udiffs of >>> each family and switching between tabs. >>> >>> ??? * To highlight the text differences, I did *not* reflow the >>> paragraphs in this webrev. I'll do that before a push. >>> >>> ??? * Some visitors had a tip >>> >>>> Note that annotating methods in concrete >>>> subclasses with {@link java.lang.Override @Override} will help >>>> ?ensure that methods are overridden as intended. >>> >>> ??? While this may have been useful back in JDK 6, I don't think it >>> is needed in JDK 15 and I'm proposing to remove these notes. >>> >>> ??? * The wording in TypeKindVisitor$N was updated to explicitly >>> mention the possibility of new enum values being added, aligning >>> with the wording already in use in ElementKindVisitor$N. >>> >>> Thanks, >>> >>> -Joe >>> >>> >>> On 3/5/2020 12:18 PM, Jonathan Gibbons wrote: >>>> >>>> Looks good to me. >>>> >>>> Consider using a ':' instead of ',' on this line in the first file: >>>> >>>> 66 * visitUnknown}, behavior that will be overridden in concrete >>>> -- Jon >>>> >>>> On 2/26/20 10:00 PM, Joe Darcy wrote: >>>>> Hello, >>>>> >>>>> Please review the documentation changes for >>>>> >>>>> ??? JDK-8240130: Improve and update discussion of visitor >>>>> evolution warnings >>>>> http://cr.openjdk.java.net/~darcy/8240130.0/ >>>>> >>>>> Patch below. Some discussion of and rationale for the changes, the >>>>> original javax.lang.model visitor interfaces and concrete visitor >>>>> types had various warning about the unusual compatibility policies >>>>> those types would use. Unlike other post-Java SE 6 era types, it >>>>> was anticipated methods would be added to interfaces. Prior to >>>>> default methods in JDK 8, such additions were a highly unusual >>>>> occurrence for public types in the JDK. After default methods were >>>>> used commonly in jDK 8, such additions are of less concern. The >>>>> risk of a true source compatibility is also low for a new >>>>> "visitFoo" method since it will have a parameter of type Foo, >>>>> which is new to the release, and thus not have an overloading >>>>> conflict with a method in an existing visitor outside of the JDK. >>>>> >>>>> The warnings are thus toned down and adjusted to note that the >>>>> envisioned additions have already occurred for prior language >>>>> additions. For example, the current policy is only to deprecate >>>>> the constructors of obsolete visitor classes rather than the whole >>>>> class. The "directly or indirectly call" visitUnknown is to >>>>> accurately describe, but not limit to, the current policy of the >>>>> visitFoo methods in affected concrete visitors calling the >>>>> visitFoo default method on the *interface*, which in turn calls >>>>> visitUnknown. >>>>> >>>>> The warning text is pulled into an apiNote to avoid getting >>>>> inherit-doc-ed for any subclasses. Once the shape of the changes >>>>> for the interface and visitor classes are agree to, I'll >>>>> replicated the changes for the other types. >>>>> >>>>> Thanks, >>>>> >>>>> -Joe >>>>> >>>>> --- >>>>> old/src/java.compiler/share/classes/javax/lang/model/element/ElementVisitor.java >>>>> 2020-02-26 13:13:00.848880601 -0800 >>>>> +++ >>>>> new/src/java.compiler/share/classes/javax/lang/model/element/ElementVisitor.java >>>>> 2020-02-26 13:13:00.512880601 -0800 >>>>> @@ -40,10 +40,17 @@ >>>>> ? * is {@code null}; see documentation of the implementing class for >>>>> ? * details. >>>>> ? * >>>>> - *

WARNING: It is possible that methods will be added to >>>>> + * @apiNote >>>>> + * >>>>> + * WARNING: It is possible that methods will be added to >>>>> ? * this interface to accommodate new, currently unknown, language >>>>> ? * structures added to future versions of the Java™ >>>>> programming >>>>> - * language.? Therefore, visitor classes directly implementing this >>>>> + * language. >>>>> + * >>>>> + * Such additions have already occurred to support language features >>>>> + * added after this API was introduced. >>>>> + * >>>>> + * Visitor classes directly implementing this >>>>> ? * interface may be source incompatible with future versions of the >>>>> ? * platform.? To avoid this source incompatibility, visitor >>>>> ? * implementations are encouraged to instead extend the appropriate >>>>> @@ -52,21 +59,15 @@ >>>>> ? * parameters, return type, etc. rather than one of the abstract >>>>> ? * classes. >>>>> ? * >>>>> - *

Note that methods to accommodate new language constructs could >>>>> - * be added in a source compatible way if they were >>>>> added as >>>>> - * default methods.? However, default methods are only >>>>> - * available on Java SE 8 and higher releases and the {@code >>>>> - * javax.lang.model.*} packages bundled in Java SE 8 were >>>>> required to >>>>> - * also be runnable on Java SE 7.? Therefore, default methods >>>>> - * were not used when extending {@code javax.lang.model.*} >>>>> - * to cover Java SE 8 language features.? However, default methods >>>>> - * are used in subsequent revisions of the {@code >>>>> javax.lang.model.*} >>>>> - * packages that are only required to run on Java SE 8 and higher >>>>> - * platform versions. >>>>> - * >>>>> - * @apiNote >>>>> + *

Methods to accommodate new language constructs are expected to >>>>> + * be added as default methods to provide strong source >>>>> compatibility, >>>>> + * as done for {@link visitModule visitModule}. The >>>>> implementations of >>>>> + * the default methods will in turn call {@link visitUnknown >>>>> + * visitUnknown}, behavior that will be overridden in concrete >>>>> + * visitors supporting the source version with the new language >>>>> + * construct. >>>>> ? * >>>>> - * There are several families of classes implementing this visitor >>>>> + *

There are several families of classes implementing this >>>>> visitor >>>>> ? * interface in the {@linkplain javax.lang.model.util util >>>>> ? * package}. The families follow a naming pattern along the lines of >>>>> ? * {@code FooVisitor}N where N indicates the >>>>> --- >>>>> old/src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor6.java >>>>> 2020-02-26 13:13:01.560880601 -0800 >>>>> +++ >>>>> new/src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor6.java >>>>> 2020-02-26 13:13:01.196880601 -0800 >>>>> @@ -36,7 +36,9 @@ >>>>> ? * appropriate for the {@link SourceVersion#RELEASE_6 RELEASE_6} >>>>> ? * source version. >>>>> ? * >>>>> - *

WARNING: The {@code ElementVisitor} interface >>>>> + * @apiNote >>>>> + * >>>>> + * WARNING: The {@code ElementVisitor} interface >>>>> ? * implemented by this class may have methods added to it in the >>>>> ? * future to accommodate new, currently unknown, language structures >>>>> ? * added to future versions of the Java™ programming language. >>>>> @@ -46,12 +48,12 @@ >>>>> ? * methods with names beginning with {@code "visit"}. >>>>> ? * >>>>> ? *

When such a new visit method is added, the default >>>>> - * implementation in this class will be to call the {@link >>>>> + * implementation in this class will be to directly or indirectly >>>>> call the {@link >>>>> ? * #visitUnknown visitUnknown} method.? A new abstract element >>>>> visitor >>>>> ? * class will also be introduced to correspond to the new language >>>>> ? * level; this visitor will have different default behavior for the >>>>> - * visit method in question.? When the new visitor is introduced, >>>>> all >>>>> - * or portions of this visitor may be deprecated. >>>>> + * visit method in question.? When a new visitor is introduced, >>>>> + * portions of this visitor class may be deprecated, including >>>>> its constructors. >>>>> ? * >>>>> ? * @param the return type of this visitor's methods. Use {@link >>>>> ? *??????????? Void} for visitors that do not need to return results. >>>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Fri Mar 13 19:14:52 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 13 Mar 2020 12:14:52 -0700 Subject: JDK 15 RFR of JDK-8240130: Improve and update discussion of visitor evolution warnings In-Reply-To: <3994368d-9380-19d6-609a-432cc51e963b@oracle.com> References: <0a7353aa-9c06-aa47-145c-765bf2069f89@oracle.com> <12938504-53ab-57f6-7aea-86ed44a2cfbf@oracle.com> <307df662-474b-3558-1df4-1069628ddd67@oracle.com> <322a55d0-08e9-1609-370c-07fc0b38f60f@oracle.com> <3994368d-9380-19d6-609a-432cc51e963b@oracle.com> Message-ID: <8f07a416-c0fb-973e-642e-3d35fdee9d30@oracle.com> +1 On 03/13/2020 12:13 PM, Joe Darcy wrote: > On 3/13/2020 11:38 AM, Jonathan Gibbons wrote: >> >> Generally OK, although you may have removed a bit too much text (i.e. >> the @param tags) in >> src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor8.java >> > Thanks for catching this; will fix before pushing. > > >> I note inconsistent use of a blank line after `@apiNote`. I'm not >> sure if that is intentional. >> > Before pushing, I'll re-flow the paragraphs and delete and a spacer > line between @apiNote and the subsequent text. > > -Joe > >> -- Jon >> >> >> On 03/13/2020 11:16 AM, Joe Darcy wrote: >>> >>> Hello, >>> >>> Following an off-list suggestion from Jon, I've re-worked the change >>> to remove most of the WARNING paragraphs and replace them with @see >>> links: >>> >>> http://cr.openjdk.java.net/~darcy/8240130.2 >>> >>> Each root visitor/scanner has a slightly different wording; the >>> element kind visitor is not strictly correct without a specialized >>> wording. Therefore, visitors other than the AbstractFooVisitor6 have >>> warning paragraphs. >>> >>> Thanks Jon for the helpful suggestion. >>> >>> -Joe >>> >>> On 3/10/2020 10:09 PM, Joe Darcy wrote: >>>> >>>> Hello, >>>> >>>> Updated and expanded version of the webrev: >>>> >>>> http://cr.openjdk.java.net/~darcy/8240130.1 >>>> >>>> A few notes on reviewing: >>>> >>>> ??? * The delta for each FooVisitor$N utility visitor family should >>>> be the same. I confirmed this visually by aligning up the udiffs of >>>> each family and switching between tabs. >>>> >>>> ??? * To highlight the text differences, I did *not* reflow the >>>> paragraphs in this webrev. I'll do that before a push. >>>> >>>> ??? * Some visitors had a tip >>>> >>>>> Note that annotating methods in concrete >>>>> subclasses with {@link java.lang.Override @Override} will help >>>>> ?ensure that methods are overridden as intended. >>>> >>>> ??? While this may have been useful back in JDK 6, I don't think it >>>> is needed in JDK 15 and I'm proposing to remove these notes. >>>> >>>> ??? * The wording in TypeKindVisitor$N was updated to explicitly >>>> mention the possibility of new enum values being added, aligning >>>> with the wording already in use in ElementKindVisitor$N. >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>>> >>>> On 3/5/2020 12:18 PM, Jonathan Gibbons wrote: >>>>> >>>>> Looks good to me. >>>>> >>>>> Consider using a ':' instead of ',' on this line in the first file: >>>>> >>>>> 66 * visitUnknown}, behavior that will be overridden in concrete >>>>> -- Jon >>>>> >>>>> On 2/26/20 10:00 PM, Joe Darcy wrote: >>>>>> Hello, >>>>>> >>>>>> Please review the documentation changes for >>>>>> >>>>>> ??? JDK-8240130: Improve and update discussion of visitor >>>>>> evolution warnings >>>>>> http://cr.openjdk.java.net/~darcy/8240130.0/ >>>>>> >>>>>> Patch below. Some discussion of and rationale for the changes, >>>>>> the original javax.lang.model visitor interfaces and concrete >>>>>> visitor types had various warning about the unusual compatibility >>>>>> policies those types would use. Unlike other post-Java SE 6 era >>>>>> types, it was anticipated methods would be added to interfaces. >>>>>> Prior to default methods in JDK 8, such additions were a highly >>>>>> unusual occurrence for public types in the JDK. After default >>>>>> methods were used commonly in jDK 8, such additions are of less >>>>>> concern. The risk of a true source compatibility is also low for >>>>>> a new "visitFoo" method since it will have a parameter of type >>>>>> Foo, which is new to the release, and thus not have an >>>>>> overloading conflict with a method in an existing visitor outside >>>>>> of the JDK. >>>>>> >>>>>> The warnings are thus toned down and adjusted to note that the >>>>>> envisioned additions have already occurred for prior language >>>>>> additions. For example, the current policy is only to deprecate >>>>>> the constructors of obsolete visitor classes rather than the >>>>>> whole class. The "directly or indirectly call" visitUnknown is to >>>>>> accurately describe, but not limit to, the current policy of the >>>>>> visitFoo methods in affected concrete visitors calling the >>>>>> visitFoo default method on the *interface*, which in turn calls >>>>>> visitUnknown. >>>>>> >>>>>> The warning text is pulled into an apiNote to avoid getting >>>>>> inherit-doc-ed for any subclasses. Once the shape of the changes >>>>>> for the interface and visitor classes are agree to, I'll >>>>>> replicated the changes for the other types. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Joe >>>>>> >>>>>> --- >>>>>> old/src/java.compiler/share/classes/javax/lang/model/element/ElementVisitor.java >>>>>> 2020-02-26 13:13:00.848880601 -0800 >>>>>> +++ >>>>>> new/src/java.compiler/share/classes/javax/lang/model/element/ElementVisitor.java >>>>>> 2020-02-26 13:13:00.512880601 -0800 >>>>>> @@ -40,10 +40,17 @@ >>>>>> ? * is {@code null}; see documentation of the implementing class for >>>>>> ? * details. >>>>>> ? * >>>>>> - *

WARNING: It is possible that methods will be added to >>>>>> + * @apiNote >>>>>> + * >>>>>> + * WARNING: It is possible that methods will be added to >>>>>> ? * this interface to accommodate new, currently unknown, language >>>>>> ? * structures added to future versions of the Java™ >>>>>> programming >>>>>> - * language.? Therefore, visitor classes directly implementing this >>>>>> + * language. >>>>>> + * >>>>>> + * Such additions have already occurred to support language >>>>>> features >>>>>> + * added after this API was introduced. >>>>>> + * >>>>>> + * Visitor classes directly implementing this >>>>>> ? * interface may be source incompatible with future versions of the >>>>>> ? * platform.? To avoid this source incompatibility, visitor >>>>>> ? * implementations are encouraged to instead extend the appropriate >>>>>> @@ -52,21 +59,15 @@ >>>>>> ? * parameters, return type, etc. rather than one of the abstract >>>>>> ? * classes. >>>>>> ? * >>>>>> - *

Note that methods to accommodate new language constructs >>>>>> could >>>>>> - * be added in a source compatible way if they were >>>>>> added as >>>>>> - * default methods.? However, default methods are only >>>>>> - * available on Java SE 8 and higher releases and the {@code >>>>>> - * javax.lang.model.*} packages bundled in Java SE 8 were >>>>>> required to >>>>>> - * also be runnable on Java SE 7.? Therefore, default methods >>>>>> - * were not used when extending {@code javax.lang.model.*} >>>>>> - * to cover Java SE 8 language features.? However, default methods >>>>>> - * are used in subsequent revisions of the {@code >>>>>> javax.lang.model.*} >>>>>> - * packages that are only required to run on Java SE 8 and higher >>>>>> - * platform versions. >>>>>> - * >>>>>> - * @apiNote >>>>>> + *

Methods to accommodate new language constructs are >>>>>> expected to >>>>>> + * be added as default methods to provide strong source >>>>>> compatibility, >>>>>> + * as done for {@link visitModule visitModule}. The >>>>>> implementations of >>>>>> + * the default methods will in turn call {@link visitUnknown >>>>>> + * visitUnknown}, behavior that will be overridden in concrete >>>>>> + * visitors supporting the source version with the new language >>>>>> + * construct. >>>>>> ? * >>>>>> - * There are several families of classes implementing this visitor >>>>>> + *

There are several families of classes implementing this >>>>>> visitor >>>>>> ? * interface in the {@linkplain javax.lang.model.util util >>>>>> ? * package}. The families follow a naming pattern along the >>>>>> lines of >>>>>> ? * {@code FooVisitor}N where N indicates the >>>>>> --- >>>>>> old/src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor6.java >>>>>> 2020-02-26 13:13:01.560880601 -0800 >>>>>> +++ >>>>>> new/src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor6.java >>>>>> 2020-02-26 13:13:01.196880601 -0800 >>>>>> @@ -36,7 +36,9 @@ >>>>>> ? * appropriate for the {@link SourceVersion#RELEASE_6 RELEASE_6} >>>>>> ? * source version. >>>>>> ? * >>>>>> - *

WARNING: The {@code ElementVisitor} interface >>>>>> + * @apiNote >>>>>> + * >>>>>> + * WARNING: The {@code ElementVisitor} interface >>>>>> ? * implemented by this class may have methods added to it in the >>>>>> ? * future to accommodate new, currently unknown, language >>>>>> structures >>>>>> ? * added to future versions of the Java™ programming >>>>>> language. >>>>>> @@ -46,12 +48,12 @@ >>>>>> ? * methods with names beginning with {@code "visit"}. >>>>>> ? * >>>>>> ? *

When such a new visit method is added, the default >>>>>> - * implementation in this class will be to call the {@link >>>>>> + * implementation in this class will be to directly or >>>>>> indirectly call the {@link >>>>>> ? * #visitUnknown visitUnknown} method.? A new abstract element >>>>>> visitor >>>>>> ? * class will also be introduced to correspond to the new language >>>>>> ? * level; this visitor will have different default behavior for the >>>>>> - * visit method in question.? When the new visitor is >>>>>> introduced, all >>>>>> - * or portions of this visitor may be deprecated. >>>>>> + * visit method in question.? When a new visitor is introduced, >>>>>> + * portions of this visitor class may be deprecated, including >>>>>> its constructors. >>>>>> ? * >>>>>> ? * @param the return type of this visitor's methods. Use {@link >>>>>> ? *??????????? Void} for visitors that do not need to return >>>>>> results. >>>>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Sat Mar 14 02:03:56 2020 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 13 Mar 2020 19:03:56 -0700 Subject: RFR [15] 8241014: Miscellaneous typos in documentation comments In-Reply-To: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> References: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> Message-ID: <22bda52b-9e47-914a-6e24-640f70ef3de5@oracle.com> Hi Pavel! Can this please be combined with my collection of typos? http://cr.openjdk.java.net/~igerasim/XXXXXXX-typos/00/webrev/ Just to save cycles on reviewing :) With kind regards, Ivan On 3/13/20 8:42 AM, Pavel Rappo wrote: > Hello, > > Please review the change for https://bugs.openjdk.java.net/browse/JDK-8241014: > > http://cr.openjdk.java.net/~prappo/8241014/webrev.00/ > > This is a documentation cleanup. There are no code changes involved, > and the changes in documentation are mostly trivial. > > The following packages are affected: > > java.lang, > java.nio.file, > java.nio.file.attribute, > java.security, > java.time.chrono, > java.time.temporal, > java.util, > java.util.regex, > java.util.stream, > javax.crypto, > javax.security.cert, > javax.tools > > That said, there are two changes that I'd prefer to be carefully reviewed by > the experts in the corresponding areas. > > The first one is for a suspected typo in the javax.crypto.CryptoPolicyParser > class, "AlgrithomParameterSpec". It is not unheard-of for typos to be kept and > supported for the sake of backward compatibility. Sadly, we have a number of > those in OpenJDK. Even though I performed reasonable checks, the proposed fix > should better be verified by the security folk. > > The second one is for the doc comment for the java.util.stream.Stream.collect method. > > @apiNote > The following will accumulate strings into an ArrayList: > > List asList = stringStream.collect(Collectors.toList()); > > Given that the spec for Collectors.toList() clearly says that > > ...There are no guarantees on the type, mutability, serializability, or > thread-safety of the List returned;... > > I'd assume that @apiNote should be fixed as proposed. > > -Pavel > > P.S. Apologies for spamming multiple mailing lists. > -- With kind regards, Ivan Gerasimov From weijun.wang at oracle.com Sat Mar 14 02:16:47 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 14 Mar 2020 10:16:47 +0800 Subject: RFR [15] 8241014: Miscellaneous typos in documentation comments In-Reply-To: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> References: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> Message-ID: <45501DDD-B9F4-4C1E-9666-2A1AB1BBFD75@oracle.com> > On Mar 13, 2020, at 11:42 PM, Pavel Rappo wrote: > > Hello, > > Please review the change for https://bugs.openjdk.java.net/browse/JDK-8241014: > > http://cr.openjdk.java.net/~prappo/8241014/webrev.00/ > > This is a documentation cleanup. There are no code changes involved, > and the changes in documentation are mostly trivial. > > The following packages are affected: > > java.lang, > java.nio.file, > java.nio.file.attribute, > java.security, > java.time.chrono, > java.time.temporal, > java.util, > java.util.regex, > java.util.stream, > javax.crypto, > javax.security.cert, > javax.tools > > That said, there are two changes that I'd prefer to be carefully reviewed by > the experts in the corresponding areas. > > The first one is for a suspected typo in the javax.crypto.CryptoPolicyParser > class, "AlgrithomParameterSpec". It is not unheard-of for typos to be kept and > supported for the sake of backward compatibility. Sadly, we have a number of > those in OpenJDK. Even though I performed reasonable checks, the proposed fix > should better be verified by the security folk. This is indeed a typo. Other changes (including Ivan's) also look fine to me. Thanks, Max > > The second one is for the doc comment for the java.util.stream.Stream.collect method. > > @apiNote > The following will accumulate strings into an ArrayList: > > List asList = stringStream.collect(Collectors.toList()); > > Given that the spec for Collectors.toList() clearly says that > > ...There are no guarantees on the type, mutability, serializability, or > thread-safety of the List returned;... > > I'd assume that @apiNote should be fixed as proposed. > > -Pavel > > P.S. Apologies for spamming multiple mailing lists. > From vicente.romero at oracle.com Sat Mar 14 02:55:20 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 13 Mar 2020 22:55:20 -0400 Subject: RFR: JDK-8235339: test TargetAnnoCombo.java is failing after new target RECORD_COMPONENT was added Message-ID: Hi, Please review the fix for [1] at [2]. Records added a new annotation target: RECORD_COMPONENT. This combo test is generating several combinations of tests with repeated annotations. When some combinations were adding the new target, then they were failing as the incantation to use preview features was not being used. I also changed the method that return the default set of annotation targets to don't return RECORD_COMPONENT if records are not allowed. Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8235339 [2] http://cr.openjdk.java.net/~vromero/8235339/webrev.00/ From pavel.rappo at oracle.com Sat Mar 14 16:19:45 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Sat, 14 Mar 2020 16:19:45 +0000 Subject: RFR [15] 8241014: Miscellaneous typos in documentation comments In-Reply-To: <22bda52b-9e47-914a-6e24-640f70ef3de5@oracle.com> References: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> <22bda52b-9e47-914a-6e24-640f70ef3de5@oracle.com> Message-ID: Hi Ivan, Your changes look good to me. Thanks for doing this. I will merge your changes into that patch of mine. 1. One thing that your change highlighted is that use of FQN here: public int read(java.nio.CharBuffer target) throws IOException It's been there for ages, but I believe can now safely go away after $ hg log -v -r 49262 changeset: 49262:1b3ee04e3e54 user: rriggs date: Mon Mar 19 09:58:41 2018 -0400 files: src/java.base/share/classes/java/io/Reader.java src/java.base/share/classes/java/io/Writer.java test/jdk/java/io/Reader/NullReader.java test/jdk/java/io/Writer/NullWriter.java description: 8196298: Add null Reader and Writer Reviewed-by: bpb, forax, smarks, alanb, rriggs Contributed-by: patrick at reini.net as this latter change brought import java.nio.CharBuffer; Unless people want to keep that FQN for some other reasons. For example, to emphasize that CharBuffer does not belong to java.io, or so it does not get confused with unrelated concepts like BufferedReader.defaultCharBufferSize, etc. 2. Typos aside, this MethodType.ConcurrentWeakInternSet.WeakEntry#equals has peculiar semantics! Paul Sandoz might be a good fit for reviewing changes in both java.util.stream (mine) and java.util.Arrays (yours). -Pavel > On 14 Mar 2020, at 02:03, Ivan Gerasimov wrote: > > Hi Pavel! > > Can this please be combined with my collection of typos? > > http://cr.openjdk.java.net/~igerasim/XXXXXXX-typos/00/webrev/ > > Just to save cycles on reviewing :) > > With kind regards, > > Ivan > > > On 3/13/20 8:42 AM, Pavel Rappo wrote: >> Hello, >> >> Please review the change for https://bugs.openjdk.java.net/browse/JDK-8241014: >> >> http://cr.openjdk.java.net/~prappo/8241014/webrev.00/ >> >> This is a documentation cleanup. There are no code changes involved, >> and the changes in documentation are mostly trivial. >> >> The following packages are affected: >> >> java.lang, >> java.nio.file, >> java.nio.file.attribute, >> java.security, >> java.time.chrono, >> java.time.temporal, >> java.util, >> java.util.regex, >> java.util.stream, >> javax.crypto, >> javax.security.cert, >> javax.tools >> >> That said, there are two changes that I'd prefer to be carefully reviewed by >> the experts in the corresponding areas. >> >> The first one is for a suspected typo in the javax.crypto.CryptoPolicyParser >> class, "AlgrithomParameterSpec". It is not unheard-of for typos to be kept and >> supported for the sake of backward compatibility. Sadly, we have a number of >> those in OpenJDK. Even though I performed reasonable checks, the proposed fix >> should better be verified by the security folk. >> >> The second one is for the doc comment for the java.util.stream.Stream.collect method. >> >> @apiNote >> The following will accumulate strings into an ArrayList: >> >> List asList = stringStream.collect(Collectors.toList()); >> >> Given that the spec for Collectors.toList() clearly says that >> >> ...There are no guarantees on the type, mutability, serializability, or >> thread-safety of the List returned;... >> >> I'd assume that @apiNote should be fixed as proposed. >> >> -Pavel >> >> P.S. Apologies for spamming multiple mailing lists. >> > -- > With kind regards, > Ivan Gerasimov > From joe.darcy at oracle.com Sat Mar 14 16:57:14 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Sat, 14 Mar 2020 09:57:14 -0700 Subject: RFR: JDK-8235339: test TargetAnnoCombo.java is failing after new target RECORD_COMPONENT was added In-Reply-To: References: Message-ID: Looks fine; cheers, -Joe On 3/13/2020 7:55 PM, Vicente Romero wrote: > Hi, > > Please review the fix for [1] at [2]. Records added a new annotation > target: RECORD_COMPONENT. This combo test is generating several > combinations of tests with repeated annotations. When some > combinations were adding the new target, then they were failing as the > incantation to use preview features was not being used. I also changed > the method that return the default set of annotation targets to don't > return RECORD_COMPONENT if records are not allowed. > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8235339 > [2] http://cr.openjdk.java.net/~vromero/8235339/webrev.00/ From vicente.romero at oracle.com Sat Mar 14 20:49:31 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Sat, 14 Mar 2020 16:49:31 -0400 Subject: RFR: JDK-8235339: test TargetAnnoCombo.java is failing after new target RECORD_COMPONENT was added In-Reply-To: References: Message-ID: thanks for the review, Vicente On 3/14/20 12:57 PM, Joe Darcy wrote: > Looks fine; cheers, > > -Joe > > On 3/13/2020 7:55 PM, Vicente Romero wrote: >> Hi, >> >> Please review the fix for [1] at [2]. Records added a new annotation >> target: RECORD_COMPONENT. This combo test is generating several >> combinations of tests with repeated annotations. When some >> combinations were adding the new target, then they were failing as >> the incantation to use preview features was not being used. I also >> changed the method that return the default set of annotation targets >> to don't return RECORD_COMPONENT if records are not allowed. >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8235339 >> [2] http://cr.openjdk.java.net/~vromero/8235339/webrev.00/ From jan.lahoda at oracle.com Wed Mar 18 08:55:11 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 18 Mar 2020 09:55:11 +0100 Subject: RFR: JDK-8240998: Implement javac changes for deconstruction patterns. Message-ID: <6d4820de-ff88-1bab-3fce-e9978de657f1@oracle.com> Hi, I would like to ask for a review for a patch that implements the deconstruction patterns, as described in JEP 375: https://bugs.openjdk.java.net/browse/JDK-8235186 The current specification draft is here: http://cr.openjdk.java.net/~gbierman/jep375/jep375-20200316/specs/patterns-instanceof-jls.html For this phase, the proposal is for javac to desugar the deconstruction patterns using record accessors. The CSR for this change is being written here: https://bugs.openjdk.java.net/browse/JDK-8240999 The proposed patch: http://cr.openjdk.java.net/~jlahoda/8240998/webrev.00 JBS: https://bugs.openjdk.java.net/browse/JDK-8240998 Any feedback is welcome! Thanks, Jan From forax at univ-mlv.fr Wed Mar 18 09:57:19 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 18 Mar 2020 10:57:19 +0100 (CET) Subject: RFR: JDK-8240998: Implement javac changes for deconstruction patterns. In-Reply-To: <6d4820de-ff88-1bab-3fce-e9978de657f1@oracle.com> References: <6d4820de-ff88-1bab-3fce-e9978de657f1@oracle.com> Message-ID: <1421610973.1641517.1584525439096.JavaMail.zimbra@u-pem.fr> Hi Jan, in the CSR part, you don't talk about the drawbacks of using a deconstruction pattern, the syntax of a deconstruction pattern forces you to declare the number of record components you have, so adding (by example) one record component to a record will makes the code of instanceof to not compile anymore. Let say you have record Point(int x, int y); with the current instanceof one can write if (o instanceof Point p) { System.out.println(p.x() + " " + p.y()); } with a deconstruction pattern, you will write if (o instanceof Point(int x, int y)) { System.out.println(x + " " + y); } now if you change Point to record Point(int x, int y, int z); the first code still compile but the second doesn't not anymore (but it still works at runtime in case of separate compilation). It's not a big deal, it doesn't make the deconstruction pattern useless at all but I think it's something developers should be aware of. regards, R?mi ----- Mail original ----- > De: "jan lahoda" > ?: "compiler-dev" > Cc: "amber-dev" > Envoy?: Mercredi 18 Mars 2020 09:55:11 > Objet: RFR: JDK-8240998: Implement javac changes for deconstruction patterns. > Hi, > > I would like to ask for a review for a patch that implements the > deconstruction patterns, as described in JEP 375: > https://bugs.openjdk.java.net/browse/JDK-8235186 > > The current specification draft is here: > http://cr.openjdk.java.net/~gbierman/jep375/jep375-20200316/specs/patterns-instanceof-jls.html > > For this phase, the proposal is for javac to desugar the deconstruction > patterns using record accessors. > > The CSR for this change is being written here: > https://bugs.openjdk.java.net/browse/JDK-8240999 > > The proposed patch: > http://cr.openjdk.java.net/~jlahoda/8240998/webrev.00 > > JBS: https://bugs.openjdk.java.net/browse/JDK-8240998 > > Any feedback is welcome! > > Thanks, > Jan From jan.lahoda at oracle.com Wed Mar 18 15:48:10 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 18 Mar 2020 16:48:10 +0100 Subject: RFR: JDK-8240998: Implement javac changes for deconstruction patterns. In-Reply-To: <1421610973.1641517.1584525439096.JavaMail.zimbra@u-pem.fr> References: <6d4820de-ff88-1bab-3fce-e9978de657f1@oracle.com> <1421610973.1641517.1584525439096.JavaMail.zimbra@u-pem.fr> Message-ID: Thanks Remi, I tried to update the CSR with this warning. Thanks, Jan On 18. 03. 20 10:57, Remi Forax wrote: > Hi Jan, > in the CSR part, > you don't talk about the drawbacks of using a deconstruction pattern, the syntax of a deconstruction pattern forces you to declare the number of record components you have, so adding (by example) one record component to a record will makes the code of instanceof to not compile anymore. > > Let say you have > record Point(int x, int y); > with the current instanceof one can write > if (o instanceof Point p) { > System.out.println(p.x() + " " + p.y()); > } > with a deconstruction pattern, you will write > if (o instanceof Point(int x, int y)) { > System.out.println(x + " " + y); > } > > now if you change Point to > record Point(int x, int y, int z); > the first code still compile but the second doesn't not anymore (but it still works at runtime in case of separate compilation). > > It's not a big deal, it doesn't make the deconstruction pattern useless at all but I think it's something developers should be aware of. > > regards, > R?mi > > ----- Mail original ----- >> De: "jan lahoda" >> ?: "compiler-dev" >> Cc: "amber-dev" >> Envoy?: Mercredi 18 Mars 2020 09:55:11 >> Objet: RFR: JDK-8240998: Implement javac changes for deconstruction patterns. > >> Hi, >> >> I would like to ask for a review for a patch that implements the >> deconstruction patterns, as described in JEP 375: >> https://bugs.openjdk.java.net/browse/JDK-8235186 >> >> The current specification draft is here: >> http://cr.openjdk.java.net/~gbierman/jep375/jep375-20200316/specs/patterns-instanceof-jls.html >> >> For this phase, the proposal is for javac to desugar the deconstruction >> patterns using record accessors. >> >> The CSR for this change is being written here: >> https://bugs.openjdk.java.net/browse/JDK-8240999 >> >> The proposed patch: >> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.00 >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8240998 >> >> Any feedback is welcome! >> >> Thanks, >> Jan From vicente.romero at oracle.com Wed Mar 18 16:51:01 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 18 Mar 2020 12:51:01 -0400 Subject: RFR: JDK-8240970: Some tests fail when run with JCov Message-ID: <4fc3cb71-fab1-fa31-2580-18a539caa71d@oracle.com> Please review fix for [1] at [2]. The intention of these fix is to be able to have clean jcov results when executing langtools tests. As explained in the JIRA entry, when running tests with jcov, a number of tests fail because some env variables used to run tests under jcov cause the runtime to emit non-suppressible warnings. These warnings can affect tests that check the output to be as expected. There are other issues we found like a dependency jcov has on java.logging which they will be trying to eliminate. This dependency was the case of the failure for test: tools/jdeps/modules/CheckModuleTest.java. The current solution is to ignore that dependency. We should be able to restore the test to its original form once this bug has been fixed in jcov. Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8240970 [2] http://cr.openjdk.java.net/~vromero/8240970/webrev.00/ From jonathan.gibbons at oracle.com Wed Mar 18 17:26:18 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 18 Mar 2020 10:26:18 -0700 Subject: RFR: JDK-8240970: Some tests fail when run with JCov In-Reply-To: <4fc3cb71-fab1-fa31-2580-18a539caa71d@oracle.com> References: <4fc3cb71-fab1-fa31-2580-18a539caa71d@oracle.com> Message-ID: Looks good to me. When comparing two List to be equal, I recommend using ToolBox.checkEqual, which gives more detailed info when the lists are not equal. We might also want to provide, eventually, a variant of ToolBox.grep that checked for lines not matching. -- Jon On 3/18/20 9:51 AM, Vicente Romero wrote: > Please review fix for [1] at [2]. The intention of these fix is to be > able to have clean jcov results when executing langtools tests. As > explained in the JIRA entry, when running tests with jcov, a number of > tests fail because some env variables used to run tests under jcov > cause the runtime to emit non-suppressible warnings. These warnings > can affect tests that check the output to be as expected. There are > other issues we found like a dependency jcov has on java.logging which > they will be trying to eliminate. This dependency was the case of the > failure for test: tools/jdeps/modules/CheckModuleTest.java. The > current solution is to ignore that dependency. We should be able to > restore the test to its original form once this bug has been fixed in > jcov. > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8240970 > [2] http://cr.openjdk.java.net/~vromero/8240970/webrev.00/ From vicente.romero at oracle.com Wed Mar 18 17:29:55 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 18 Mar 2020 13:29:55 -0400 Subject: RFR: JDK-8240998: Implement javac changes for deconstruction patterns. In-Reply-To: <6d4820de-ff88-1bab-3fce-e9978de657f1@oracle.com> References: <6d4820de-ff88-1bab-3fce-e9978de657f1@oracle.com> Message-ID: <60d60338-c6b1-e9ce-33f3-e047df1d3454@oracle.com> Hi Jan, Shouldn't this patch also modify some of the visitors at javax.lang.model? Thanks, Vicente On 3/18/20 4:55 AM, Jan Lahoda wrote: > Hi, > > I would like to ask for a review for a patch that implements the > deconstruction patterns, as described in JEP 375: > https://bugs.openjdk.java.net/browse/JDK-8235186 > > The current specification draft is here: > http://cr.openjdk.java.net/~gbierman/jep375/jep375-20200316/specs/patterns-instanceof-jls.html > > > For this phase, the proposal is for javac to desugar the > deconstruction patterns using record accessors. > > The CSR for this change is being written here: > https://bugs.openjdk.java.net/browse/JDK-8240999 > > The proposed patch: > http://cr.openjdk.java.net/~jlahoda/8240998/webrev.00 > > JBS: https://bugs.openjdk.java.net/browse/JDK-8240998 > > Any feedback is welcome! > > Thanks, > ??? Jan From vicente.romero at oracle.com Wed Mar 18 19:26:37 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 18 Mar 2020 15:26:37 -0400 Subject: RFR: JDK-8240658: Code completion not working for lambdas in method invocations that require type inference In-Reply-To: References: Message-ID: <7bff733d-a800-a006-731b-e34375f379e2@oracle.com> looks good, Vicente On 3/13/20 8:20 AM, Jan Lahoda wrote: > Hi, > > When a method invocation requires type inference, and the user is in > the process of typing of a (block) lambda that is a parameter to the > method invocation, javac may not, in some cases, perform the type > inference, which then may lead to non working code completion in > JShell (and possibly other tools). > > For example (in JShell): > Arrays.stream(new Integer[]{1}).forEach(v -> { System.err.println(v. > > and press - this leads to no proposals currently, as the type of > "v" is not inferred. > > The idea of the proposed patch is to improve the recovery in cases > significant for cases where the text is being typed, and allow type > inference in these cases. The type of "v" is then inferred, and the > code completion works. > > Proposed patch: > http://cr.openjdk.java.net/~jlahoda/8240658/webrev.00/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8240658 > > Thanks, > ??? Jan From vitalyd at gmail.com Wed Mar 18 23:47:55 2020 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 18 Mar 2020 19:47:55 -0400 Subject: javac 11.0.6 NullPointerException when a type param refers to missing type Message-ID: Hi all, I'd like to report a bug against javac 11.0.6 (and possibly later, but I don't readily have access to newer versions). To reproduce: Create the following 3 source files: ////// A.java public class A> { public void foo() {} } ////// B.java public class B {} ////// C.java public class C { public static void crashJavaC(A a) { a.foo(null); } } $ javac A.java B.java $ rm B.java B.class $ javac C.java An exception has occurred in the compiler (11.0.6). Please file a bug against the Java compiler via the Java bug reporting page ( http://bugreport.java.com) after checking the Bug Database ( http://bugs.java.com) for duplicates. Include your program and the following diagnostic in your report. Thank you. java.lang.NullPointerException at jdk.compiler/com.sun.tools.javac.comp.TransTypes.visitSelect(TransTypes.java:811) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:2114) at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) at jdk.compiler/com.sun.tools.javac.comp.TransTypes.translate(TransTypes.java:454) at jdk.compiler/com.sun.tools.javac.comp.TransTypes.visitApply(TransTypes.java:622) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1634) at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) at jdk.compiler/com.sun.tools.javac.comp.TransTypes.translate(TransTypes.java:454) at jdk.compiler/com.sun.tools.javac.comp.TransTypes.visitExec(TransTypes.java:599) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1452) at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:70) at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.visitBlock(TreeTranslator.java:167) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1020) at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) at jdk.compiler/com.sun.tools.javac.comp.TransTypes.translate(TransTypes.java:454) at jdk.compiler/com.sun.tools.javac.comp.TransTypes.visitMethodDef(TransTypes.java:489) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:866) at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:70) at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.visitClassDef(TreeTranslator.java:139) at jdk.compiler/com.sun.tools.javac.comp.TransTypes.translateClass(TransTypes.java:918) at jdk.compiler/com.sun.tools.javac.comp.TransTypes.visitClassDef(TransTypes.java:475) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:774) at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) at jdk.compiler/com.sun.tools.javac.comp.TransTypes.translate(TransTypes.java:454) at jdk.compiler/com.sun.tools.javac.comp.TransTypes.translateTopLevelClass(TransTypes.java:942) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1553) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1432) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973) at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:311) at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170) at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57) at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43) If B.java *is* present, we get the expected compilation error: $ javac C.java C.java:3: error: method foo in class A cannot be applied to given types; a.foo(null); ^ required: no arguments found: reason: actual and formal argument lists differ in length where T is a type-variable: T extends B declared in class A 1 error The repro is (purposely) contrived. The real case came up when build infrastructure prevented the source path of B.java from being observed when building C.java. I assume javac shouldn't crash with an NPE, and should instead provide a compilation error pointing out that B symbol is not found (or similar). Let me know if you have any questions. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Thu Mar 19 10:42:32 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 19 Mar 2020 11:42:32 +0100 Subject: RFR: JDK-8240998: Implement javac changes for deconstruction patterns. In-Reply-To: <60d60338-c6b1-e9ce-33f3-e047df1d3454@oracle.com> References: <6d4820de-ff88-1bab-3fce-e9978de657f1@oracle.com> <60d60338-c6b1-e9ce-33f3-e047df1d3454@oracle.com> Message-ID: <0f62be75-d4fe-ac80-5c99-cdb89a019e9a@oracle.com> Hi Vicente, On 18. 03. 20 18:29, Vicente Romero wrote: > Hi Jan, > > Shouldn't this patch also modify some of the visitors at javax.lang.model? With the pattern matching for instanceof in JDK14, we have added ElementKind.BINDING_VARIABLE, and the deconstruction patterns are using that as well. Otherwise, the deconstruction patterns shouldn't (I hope) affect declarations modeled by javax.lang.model? I.e. this only adds a new form of patterns, which are only specific to expressions, which are not modeled by javax.lang.model. Updates to the Trees API are part of the patch. Thanks, Jan > > Thanks, > Vicente > > On 3/18/20 4:55 AM, Jan Lahoda wrote: >> Hi, >> >> I would like to ask for a review for a patch that implements the >> deconstruction patterns, as described in JEP 375: >> https://bugs.openjdk.java.net/browse/JDK-8235186 >> >> The current specification draft is here: >> http://cr.openjdk.java.net/~gbierman/jep375/jep375-20200316/specs/patterns-instanceof-jls.html >> >> >> For this phase, the proposal is for javac to desugar the >> deconstruction patterns using record accessors. >> >> The CSR for this change is being written here: >> https://bugs.openjdk.java.net/browse/JDK-8240999 >> >> The proposed patch: >> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.00 >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8240998 >> >> Any feedback is welcome! >> >> Thanks, >> ??? Jan > From vicente.romero at oracle.com Thu Mar 19 14:25:38 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 19 Mar 2020 10:25:38 -0400 Subject: RFR: JDK-8240998: Implement javac changes for deconstruction patterns. In-Reply-To: <0f62be75-d4fe-ac80-5c99-cdb89a019e9a@oracle.com> References: <6d4820de-ff88-1bab-3fce-e9978de657f1@oracle.com> <60d60338-c6b1-e9ce-33f3-e047df1d3454@oracle.com> <0f62be75-d4fe-ac80-5c99-cdb89a019e9a@oracle.com> Message-ID: <263b03e7-0f2e-38a8-4eda-164de5fdd487@oracle.com> On 3/19/20 6:42 AM, Jan Lahoda wrote: > Hi Vicente, > > On 18. 03. 20 18:29, Vicente Romero wrote: >> Hi Jan, >> >> Shouldn't this patch also modify some of the visitors at >> javax.lang.model? > > With the pattern matching for instanceof in JDK14, we have added > ElementKind.BINDING_VARIABLE, and the deconstruction patterns are > using that as well. Otherwise, the deconstruction patterns shouldn't > (I hope) affect declarations modeled by javax.lang.model? I.e. this > only adds a new form of patterns, which are only specific to > expressions, which are not modeled by javax.lang.model. Updates to the > Trees API are part of the patch. ah ok thanks for the clarification, > > Thanks, > ??? Jan Vicente > >> >> Thanks, >> Vicente >> >> On 3/18/20 4:55 AM, Jan Lahoda wrote: >>> Hi, >>> >>> I would like to ask for a review for a patch that implements the >>> deconstruction patterns, as described in JEP 375: >>> https://bugs.openjdk.java.net/browse/JDK-8235186 >>> >>> The current specification draft is here: >>> http://cr.openjdk.java.net/~gbierman/jep375/jep375-20200316/specs/patterns-instanceof-jls.html >>> >>> >>> For this phase, the proposal is for javac to desugar the >>> deconstruction patterns using record accessors. >>> >>> The CSR for this change is being written here: >>> https://bugs.openjdk.java.net/browse/JDK-8240999 >>> >>> The proposed patch: >>> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.00 >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8240998 >>> >>> Any feedback is welcome! >>> >>> Thanks, >>> ??? Jan >> From jan.lahoda at oracle.com Thu Mar 19 17:25:27 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 19 Mar 2020 18:25:27 +0100 Subject: RFR: JDK-8240998: Implement javac changes for deconstruction patterns. In-Reply-To: <6d4820de-ff88-1bab-3fce-e9978de657f1@oracle.com> References: <6d4820de-ff88-1bab-3fce-e9978de657f1@oracle.com> Message-ID: Hi, Turned out the patch had two bugs - one related to the owners of the temporary variables created, which then broke type annotations; and another that broken de-duplication. I am deeply sorry for that. An updated webrev is here: http://cr.openjdk.java.net/~jlahoda/8240998/webrev.01/ A delta from previous round: http://cr.openjdk.java.net/~jlahoda/8240998/webrev.delta.00.01/ I am sorry for any inconvenience. Jan On 18. 03. 20 9:55, Jan Lahoda wrote: > Hi, > > I would like to ask for a review for a patch that implements the > deconstruction patterns, as described in JEP 375: > https://bugs.openjdk.java.net/browse/JDK-8235186 > > The current specification draft is here: > http://cr.openjdk.java.net/~gbierman/jep375/jep375-20200316/specs/patterns-instanceof-jls.html > > > For this phase, the proposal is for javac to desugar the deconstruction > patterns using record accessors. > > The CSR for this change is being written here: > https://bugs.openjdk.java.net/browse/JDK-8240999 > > The proposed patch: > http://cr.openjdk.java.net/~jlahoda/8240998/webrev.00 > > JBS: https://bugs.openjdk.java.net/browse/JDK-8240998 > > Any feedback is welcome! > > Thanks, > ??? Jan From paul.sandoz at oracle.com Fri Mar 20 17:16:30 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 20 Mar 2020 10:16:30 -0700 Subject: RFR [15] 8241014: Miscellaneous typos in documentation comments In-Reply-To: <22bda52b-9e47-914a-6e24-640f70ef3de5@oracle.com> References: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> <22bda52b-9e47-914a-6e24-640f70ef3de5@oracle.com> Message-ID: <2A629BB4-CE15-4172-AAF4-75A4811A3F5C@oracle.com> --- a/src/java.base/share/classes/java/lang/invoke/MethodType.java +++ b/src/java.base/share/classes/java/lang/invoke/MethodType.java @@ -1379,12 +1379,12 @@ /** * This implementation returns {@code true} if {@code obj} is another - * {@code WeakEntry} whose referent is equals to this referent, or - * if {@code obj} is equals to the referent of this. This allows + * {@code WeakEntry} whose referent equals to this referent, or + * if {@code obj} equals to the referent of this. This allows * lookups to be made without wrapping in a {@code WeakEntry}. * * @param obj the object to compare - * @return true if {@code obj} is equals to this or the referent of this + * @return true if {@code obj} equals to this or the referent of this * @see MethodType#equals(Object) * @see Object#equals(Object) Use either: whose referent is equal to this referent, or whose referent equals this referent, The former is easier just delete the ?s?. Other bits look good. Paul. > On Mar 13, 2020, at 7:03 PM, Ivan Gerasimov wrote: > > Hi Pavel! > > Can this please be combined with my collection of typos? > > http://cr.openjdk.java.net/~igerasim/XXXXXXX-typos/00/webrev/ > > Just to save cycles on reviewing :) > > With kind regards, > > Ivan > > > On 3/13/20 8:42 AM, Pavel Rappo wrote: >> Hello, >> >> Please review the change for https://bugs.openjdk.java.net/browse/JDK-8241014: >> >> http://cr.openjdk.java.net/~prappo/8241014/webrev.00/ >> >> This is a documentation cleanup. There are no code changes involved, >> and the changes in documentation are mostly trivial. >> >> The following packages are affected: >> >> java.lang, >> java.nio.file, >> java.nio.file.attribute, >> java.security, >> java.time.chrono, >> java.time.temporal, >> java.util, >> java.util.regex, >> java.util.stream, >> javax.crypto, >> javax.security.cert, >> javax.tools >> >> That said, there are two changes that I'd prefer to be carefully reviewed by >> the experts in the corresponding areas. >> >> The first one is for a suspected typo in the javax.crypto.CryptoPolicyParser >> class, "AlgrithomParameterSpec". It is not unheard-of for typos to be kept and >> supported for the sake of backward compatibility. Sadly, we have a number of >> those in OpenJDK. Even though I performed reasonable checks, the proposed fix >> should better be verified by the security folk. >> >> The second one is for the doc comment for the java.util.stream.Stream.collect method. >> >> @apiNote >> The following will accumulate strings into an ArrayList: >> >> List asList = stringStream.collect(Collectors.toList()); >> >> Given that the spec for Collectors.toList() clearly says that >> >> ...There are no guarantees on the type, mutability, serializability, or >> thread-safety of the List returned;... >> >> I'd assume that @apiNote should be fixed as proposed. >> >> -Pavel >> >> P.S. Apologies for spamming multiple mailing lists. >> > -- > With kind regards, > Ivan Gerasimov > From paul.sandoz at oracle.com Fri Mar 20 17:22:12 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 20 Mar 2020 10:22:12 -0700 Subject: RFR [15] 8241014: Miscellaneous typos in documentation comments In-Reply-To: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> References: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> Message-ID: <4278B6CA-34D5-4857-A5A7-D885C69CDB9E@oracle.com> +1 Paul. > On Mar 13, 2020, at 8:42 AM, Pavel Rappo wrote: > > Hello, > > Please review the change for https://bugs.openjdk.java.net/browse/JDK-8241014: > > http://cr.openjdk.java.net/~prappo/8241014/webrev.00/ > > This is a documentation cleanup. There are no code changes involved, > and the changes in documentation are mostly trivial. > > The following packages are affected: > > java.lang, > java.nio.file, > java.nio.file.attribute, > java.security, > java.time.chrono, > java.time.temporal, > java.util, > java.util.regex, > java.util.stream, > javax.crypto, > javax.security.cert, > javax.tools > > That said, there are two changes that I'd prefer to be carefully reviewed by > the experts in the corresponding areas. > > The first one is for a suspected typo in the javax.crypto.CryptoPolicyParser > class, "AlgrithomParameterSpec". It is not unheard-of for typos to be kept and > supported for the sake of backward compatibility. Sadly, we have a number of > those in OpenJDK. Even though I performed reasonable checks, the proposed fix > should better be verified by the security folk. > > The second one is for the doc comment for the java.util.stream.Stream.collect method. > > @apiNote > The following will accumulate strings into an ArrayList: > > List asList = stringStream.collect(Collectors.toList()); > > Given that the spec for Collectors.toList() clearly says that > > ...There are no guarantees on the type, mutability, serializability, or > thread-safety of the List returned;... > > I'd assume that @apiNote should be fixed as proposed. > > -Pavel > > P.S. Apologies for spamming multiple mailing lists. > From bsrbnd at gmail.com Fri Mar 20 18:16:19 2020 From: bsrbnd at gmail.com (B. Blaser) Date: Fri, 20 Mar 2020 19:16:19 +0100 Subject: Type inference heuristics (was: Enhancing expressions with mutability?) In-Reply-To: References: Message-ID: A common use of mutable expressions is for implementing evolutionary heuristics which typically might be helpful to solve performance issues like JDK-8152289. So, I tried to write such an algorithm using the quotation operator ` to infer the following similar example: class Point

{ Point(P label) {} } class Graph { public Graph(Point... vertices) {} } class Test { Test() { new Graph<>( new Point<>(1), ..., new Point<>(200) ); } } The attached dedicated evolutionary heuristic [3] infers all variables in no more than one second whereas javac takes currently between one and two minutes on my machine. It assumes the following initial bound set: G <: Number = P1 ... Pn Pn <: Number :> Integer = G The set of potential solutions is deduced from the initial bound set including combinations of them (intersection types): + private final Class[] classes = new Class[] { + Integer.class, Number.class, Object.class + }; + + private final Class[] interfs = new Class[] { + Serializable.class, Comparable.class, + Constable.class, ConstantDesc.class + }; The evolutionary algorithm traditionally starts with creating individuals and then iteratively chooses the best ones to perform cross-over and mutations until the prefect one is found. The interesting part is, of course, how their ADN is encoded. Each gene is dedicated to one inference variable and represents the individual ability to solve it, which can be expressed by the following formula: + adn[i] = (`able).link(`p, `type()); where `able is a function that checks all the bounds of the inference variable `p against the potential instantiation `type(). The evaluation of an individual, which is also the function to minimize, is the sum of all bad genes not able to solve their inference variable, the perfect individual having only good genes. However, this heuristic is only designed to infer this particular example. So, it might be interesting to generalize it as much as possible to solve a wider range of performance issues in this area. What do you think? Thanks, Bernard [3] heuristic.patch (attached) On Thu, 12 Mar 2020 at 18:36, B. Blaser wrote: > > To go a bit further, it'd be also possible to add another field to the > 'Term' class representing the name of any quoted identifier, which can > concretely be made in 'Lower' by adding a couple of lines like > 'makeLit(syms.stringType, ((JCIdent _or_ > JCFieldAccess)arg).name.toString())' (I can share the full diff with > the previous 'quote.patch' if requested). We can then use it like '(`d > _or_ `this.d).name.equals("d")' in our initial example. > > So, not to misunderstand me, this isn't a meta-programming facility by > itself but a fortunate consequence of the quotation operator which > might be used to considerably reduce the amount of code in certain > situations like persistence frameworks. And note also that mutable > expressions might be used to build queries using a more declarative > fashion, for example. > > Isn't that still a direction which is worth exploring? > > Thanks, > Bernard > > On Tue, 10 Mar 2020 at 22:03, B. Blaser wrote: > > > > Hi, > > > > Taking back the essential idea of the original publication on Lisp > > [1], I did the attached syntactic experiment [2] trying to bring some > > kind of mutability to expressions and thus giving more flexibility to > > the language. I hope this subject hasn't been covered too many times, > > otherwise I'd apologize for any disturbance. > > > > To build such mutable expressions, I've specified a new unary operator > > ` along with its resulting class 'java.lang.Term'. The quotation > > operator creates a 'Term' from any reference which can then be linked > > to other terms to finally be evaluated to the result of a function > > call for lambdas or the reference itself otherwise. > > > > Let's take some examples from the attached patch: > > > > + interface Get { > > + int op(); > > + } > > + > > + interface Sum { > > + int op(int i, int j); > > + } > > > > + int a = 0, b = 0; > > + Sum s = (x, y) -> x + y; > > > > + public void run() { > > + Get a = () -> this.a; > > + Get b = () -> this.b; > > + > > + Term e1 = (`s).link(`a, `b); > > + this.a = 1; this.b = 2; > > > > The above lines create a mutable expression e1 from the sum lambda s > > of the getter a and b which can then be evaluated to: > > > > (Integer)e1.value() == 3 > > > > or visualized as: > > > > e1.toString().equals("Sum( Get( ) Get( ) )") > > > > An interesting application similar to ?3.g from [1] is the computation > > of the partial derivative of a sum involving the mutation of the > > initial expression to produce a new resulting one: > > > > + // Derivative of sum e with respect to r > > + Term derivative(Term e, Term r) { > > + if (e.terms.isEmpty()) { > > + return `Integer.valueOf(e.that == r.that ? 1 : 0); > > + } > > + else if(e.that == (`s).that) { > > + return (`s).link(derivative(e.terms.get(0), r), > > derivative(e.terms.get(1), r)); > > + } > > + else throw new AssertionError(); > > + } > > > > Invoking the above method like this: > > > > + Term e2 = derivative(e1, `a); > > > > creates the resulting derivative expression e2 which can then be evaluated to: > > > > (Integer)e2.value() == 1 > > > > or visualized as: > > > > e2.toString().equals("Sum( `1 `0 )") > > > > Finally, we note that any term may be quoted to prevent its > > evaluation, for example: > > > > + Derivative d = this::derivative; > > > > + Term e3 = (`d).link(`e1, ``a); > > > > can be evaluated to: > > > > (Integer)((Term)e3.value()).value() == 1 > > > > or visualized as: > > > > e3.toString().equals("Derivative( `Sum( Get( ) Get( ) ) `Get( ) )") > > > > Of course, one of our main concern is how much do we need this and a > > reasonable answer would probably be as much as we need Lisp's > > S-expressions but with similar or maybe better performance than > > external interpreters and a more homogeneous integration to the > > language. > > > > Any feedback about this experiment would be welcome! > > > > Thanks, > > Bernard > > > > [1] http://www-formal.stanford.edu/jmc/recursive.html > > [2] quote.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: heuristic.patch Type: text/x-patch Size: 6452 bytes Desc: not available URL: From ivan.gerasimov at oracle.com Fri Mar 20 20:11:57 2020 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 20 Mar 2020 13:11:57 -0700 Subject: RFR [15] 8241014: Miscellaneous typos in documentation comments In-Reply-To: <2A629BB4-CE15-4172-AAF4-75A4811A3F5C@oracle.com> References: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> <22bda52b-9e47-914a-6e24-640f70ef3de5@oracle.com> <2A629BB4-CE15-4172-AAF4-75A4811A3F5C@oracle.com> Message-ID: Thank you Paul! grep found a few more occurrences of? 'equals to'? across java.base, so I fixed them as well. Here's the updated webrev: http://cr.openjdk.java.net/~igerasim/XXXXXXX-typos/01/webrev/ Pavel, I checked your portion of correction, everything looks good to me! One minor nit:? In src/java.base/share/classes/java/util/StringJoiner.java can you please wrap the modified line, so it won't be that long? With kind regards, Ivan On 3/20/20 10:16 AM, Paul Sandoz wrote: > --- a/src/java.base/share/classes/java/lang/invoke/MethodType.java > +++ b/src/java.base/share/classes/java/lang/invoke/MethodType.java > @@ -1379,12 +1379,12 @@ > > /** > * This implementation returns {@code true} if {@code obj} is another > - * {@code WeakEntry} whose referent is equals to this referent, or > - * if {@code obj} is equals to the referent of this. This allows > + * {@code WeakEntry} whose referent equals to this referent, or > + * if {@code obj} equals to the referent of this. This allows > * lookups to be made without wrapping in a {@code WeakEntry}. > * > * @param obj the object to compare > - * @return true if {@code obj} is equals to this or the referent of this > + * @return true if {@code obj} equals to this or the referent of this > * @see MethodType#equals(Object) > * @see Object#equals(Object) > > Use either: > > whose referent is equal to this referent, > > or > > whose referent equals this referent, > > The former is easier just delete the ?s?. > > Other bits look good. > > Paul. > >> On Mar 13, 2020, at 7:03 PM, Ivan Gerasimov wrote: >> >> Hi Pavel! >> >> Can this please be combined with my collection of typos? >> >> http://cr.openjdk.java.net/~igerasim/XXXXXXX-typos/00/webrev/ >> >> Just to save cycles on reviewing :) >> >> With kind regards, >> >> Ivan >> >> >> On 3/13/20 8:42 AM, Pavel Rappo wrote: >>> Hello, >>> >>> Please review the change for https://bugs.openjdk.java.net/browse/JDK-8241014: >>> >>> http://cr.openjdk.java.net/~prappo/8241014/webrev.00/ >>> >>> This is a documentation cleanup. There are no code changes involved, >>> and the changes in documentation are mostly trivial. >>> >>> The following packages are affected: >>> >>> java.lang, >>> java.nio.file, >>> java.nio.file.attribute, >>> java.security, >>> java.time.chrono, >>> java.time.temporal, >>> java.util, >>> java.util.regex, >>> java.util.stream, >>> javax.crypto, >>> javax.security.cert, >>> javax.tools >>> >>> That said, there are two changes that I'd prefer to be carefully reviewed by >>> the experts in the corresponding areas. >>> >>> The first one is for a suspected typo in the javax.crypto.CryptoPolicyParser >>> class, "AlgrithomParameterSpec". It is not unheard-of for typos to be kept and >>> supported for the sake of backward compatibility. Sadly, we have a number of >>> those in OpenJDK. Even though I performed reasonable checks, the proposed fix >>> should better be verified by the security folk. >>> >>> The second one is for the doc comment for the java.util.stream.Stream.collect method. >>> >>> @apiNote >>> The following will accumulate strings into an ArrayList: >>> >>> List asList = stringStream.collect(Collectors.toList()); >>> >>> Given that the spec for Collectors.toList() clearly says that >>> >>> ...There are no guarantees on the type, mutability, serializability, or >>> thread-safety of the List returned;... >>> >>> I'd assume that @apiNote should be fixed as proposed. >>> >>> -Pavel >>> >>> P.S. Apologies for spamming multiple mailing lists. >>> >> -- >> With kind regards, >> Ivan Gerasimov >> -- With kind regards, Ivan Gerasimov From pavel.rappo at oracle.com Fri Mar 20 21:00:29 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 20 Mar 2020 21:00:29 +0000 Subject: RFR [15] 8241014: Miscellaneous typos in documentation comments In-Reply-To: References: <0AA807B8-EC70-428B-A8B6-9ED6DA0B40EA@oracle.com> <22bda52b-9e47-914a-6e24-640f70ef3de5@oracle.com> <2A629BB4-CE15-4172-AAF4-75A4811A3F5C@oracle.com> Message-ID: <1EE3B1EB-15AA-4BCC-9A60-37CAC906E244@oracle.com> Thanks Ivan, I merged your changes with mine and pushed the resulting changeset. > On 20 Mar 2020, at 20:11, Ivan Gerasimov wrote: > > Thank you Paul! > > grep found a few more occurrences of 'equals to' across java.base, so I fixed them as well. > > Here's the updated webrev: > > http://cr.openjdk.java.net/~igerasim/XXXXXXX-typos/01/webrev/ > > > Pavel, I checked your portion of correction, everything looks good to me! > > One minor nit: In src/java.base/share/classes/java/util/StringJoiner.java can you please wrap the modified line, so it won't be that long? > > > With kind regards, > > Ivan > > > On 3/20/20 10:16 AM, Paul Sandoz wrote: >> --- a/src/java.base/share/classes/java/lang/invoke/MethodType.java >> +++ b/src/java.base/share/classes/java/lang/invoke/MethodType.java >> @@ -1379,12 +1379,12 @@ >> /** >> * This implementation returns {@code true} if {@code obj} is another >> - * {@code WeakEntry} whose referent is equals to this referent, or >> - * if {@code obj} is equals to the referent of this. This allows >> + * {@code WeakEntry} whose referent equals to this referent, or >> + * if {@code obj} equals to the referent of this. This allows >> * lookups to be made without wrapping in a {@code WeakEntry}. >> * >> * @param obj the object to compare >> - * @return true if {@code obj} is equals to this or the referent of this >> + * @return true if {@code obj} equals to this or the referent of this >> * @see MethodType#equals(Object) >> * @see Object#equals(Object) >> Use either: >> >> whose referent is equal to this referent, >> >> or >> >> whose referent equals this referent, >> >> The former is easier just delete the ?s?. >> >> Other bits look good. >> >> Paul. >> >>> On Mar 13, 2020, at 7:03 PM, Ivan Gerasimov wrote: >>> >>> Hi Pavel! >>> >>> Can this please be combined with my collection of typos? >>> >>> http://cr.openjdk.java.net/~igerasim/XXXXXXX-typos/00/webrev/ >>> >>> Just to save cycles on reviewing :) >>> >>> With kind regards, >>> >>> Ivan >>> >>> >>> On 3/13/20 8:42 AM, Pavel Rappo wrote: >>>> Hello, >>>> >>>> Please review the change for https://bugs.openjdk.java.net/browse/JDK-8241014: >>>> >>>> http://cr.openjdk.java.net/~prappo/8241014/webrev.00/ >>>> >>>> This is a documentation cleanup. There are no code changes involved, >>>> and the changes in documentation are mostly trivial. >>>> >>>> The following packages are affected: >>>> >>>> java.lang, >>>> java.nio.file, >>>> java.nio.file.attribute, >>>> java.security, >>>> java.time.chrono, >>>> java.time.temporal, >>>> java.util, >>>> java.util.regex, >>>> java.util.stream, >>>> javax.crypto, >>>> javax.security.cert, >>>> javax.tools >>>> >>>> That said, there are two changes that I'd prefer to be carefully reviewed by >>>> the experts in the corresponding areas. >>>> >>>> The first one is for a suspected typo in the javax.crypto.CryptoPolicyParser >>>> class, "AlgrithomParameterSpec". It is not unheard-of for typos to be kept and >>>> supported for the sake of backward compatibility. Sadly, we have a number of >>>> those in OpenJDK. Even though I performed reasonable checks, the proposed fix >>>> should better be verified by the security folk. >>>> >>>> The second one is for the doc comment for the java.util.stream.Stream.collect method. >>>> >>>> @apiNote >>>> The following will accumulate strings into an ArrayList: >>>> >>>> List asList = stringStream.collect(Collectors.toList()); >>>> >>>> Given that the spec for Collectors.toList() clearly says that >>>> >>>> ...There are no guarantees on the type, mutability, serializability, or >>>> thread-safety of the List returned;... >>>> >>>> I'd assume that @apiNote should be fixed as proposed. >>>> >>>> -Pavel >>>> >>>> P.S. Apologies for spamming multiple mailing lists. >>>> >>> -- >>> With kind regards, >>> Ivan Gerasimov >>> > -- > With kind regards, > Ivan Gerasimov > From roland.illig at gmx.de Sat Mar 21 11:12:54 2020 From: roland.illig at gmx.de (Roland Illig) Date: Sat, 21 Mar 2020 12:12:54 +0100 Subject: dict.cc: char used as array subscript Message-ID: When I compile OpenJDK 11 with GCC, I get this warning in dict.cc: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94247 Could you perhaps change k from char to any other integer type, to make this warning go away? GCC generates the same code anyway, so using int or unsigned int would be nicer to the human reader as well. Best, Roland From vicente.romero at oracle.com Sat Mar 21 21:52:43 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Sat, 21 Mar 2020 17:52:43 -0400 Subject: JDK 14 record type representation in classfile format? In-Reply-To: References: <210577329.1731587.1584813604436.JavaMail.zimbra@u-pem.fr> <795763192.1760146.1584820917588.JavaMail.zimbra@u-pem.fr> Message-ID: <085e2b81-dbab-2c82-a0d9-778938a47cc6@oracle.com> cc'ing compiler-dev OK the discussion has continued on the JBS entry see [1]. I think now that javac is generating an InnerClasses attribute just because a code that is used to generate signatures is being reused here to generate the descriptor for the bootstrap method. This seems to be the only reason why an InnerClasses attribute is generated whenever there a class refers / uses a bootstrap method. The thing is that as this code has been around since a while, I'm not sure if some other code in the VM or reflection could be depending on it. Does anybody can shed some light on this issue? Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8241398 On 3/21/20 4:19 PM, Vicente Romero wrote: > I don't think that this is a bug. Records are using indy to invoke > bootstrap methods that implement: toString, equals and hashCode. The > first parameter of every bootstrap method is: > java/lang/invoke/MethodHandles$Lookup which is an inner class and thus > requires a dedicated InnerClasses attribute. You can reproduce a very > similar pattern with any code that uses bootstrap methods like: > > class StringTest { > ??? String m(String s) { > ??????? return s + ""; > ??? } > } > > Thanks, > Vicente > > On 3/21/20 4:01 PM, Remi Forax wrote: >> ----- Mail original ----- >>> De: "Remi Forax" >>> ?: "Luke Hutchison" >>> Cc: "jdk-dev" , "amber-dev" >>> >>> Envoy?: Samedi 21 Mars 2020 19:00:04 >>> Objet: Re: JDK 14 record type representation in classfile format? >> [...] >> >>>> Also, records have an "InnerClasses" class attribute, with an inner >>>> class >>>> name of "java.lang.invoke.MethodHandles$Lookup" and an outer class >>>> name of >>>> "java.lang.invoke.MethodHandles". Normally the outer class name >>>> matches the >>>> class whose classfile the attribute is contained in. Why is this inner >>>> class attribute there, and why does the outer class name not match >>>> the name >>>> of the record? >>> This look like a bug to me. >> I've created https://bugs.openjdk.java.net/browse/JDK-8241398 to >> track that. >> >> cheers, >> R?mi > From brian.goetz at oracle.com Sun Mar 22 15:31:17 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 22 Mar 2020 11:31:17 -0400 Subject: JDK 14 record type representation in classfile format? In-Reply-To: References: <210577329.1731587.1584813604436.JavaMail.zimbra@u-pem.fr> <795763192.1760146.1584820917588.JavaMail.zimbra@u-pem.fr> <085e2b81-dbab-2c82-a0d9-778938a47cc6@oracle.com> Message-ID: This does not appear to be specific to records at all; javac seems to generate an IC attribute whenever you _use_ a nested class.? For example: import java.lang.invoke.*; public class Foo { ??? MethodHandles.Lookup lookup = null; } has the following attribute in it: InnerClasses: ? public static final #7= #6 of #20;????? // Lookup=class java/lang/invoke/MethodHandles$Lookup of class java/lang/invoke/MethodHandles While this has nothing to do with records, it may still be worth discussing whether this attribute is necessary, incorrect, or harmful.?? (Note that Lookup is a _nested_ class of MethodHandles, but not an _inner_ one, since it is static.) On 3/21/2020 7:42 PM, Luke Hutchison wrote: > In classes I have looked at in the past, if there is an InnerClasses class > attribute, then the listed inner class containment hierarchy always forms a > tree rooted at the defining class, and with the tree structure defined by > the outer_class_info and inner_class_info entries in the InnerClasses > attribute. > > In this case, the outer_class_info is for MethodHandle, and MethodHandle is > not actually an inner class of the record class, so it seems strange that > the record class would list MethodHandle$Lookup as an inner class, rather > than the MethodHandle class listing MethodHandle$Lookup as an inner class. > > (I admit I don't understand how bootstrap methods work at the deepest level > though, so maybe I'm missing something.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Sun Mar 22 15:54:23 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 22 Mar 2020 16:54:23 +0100 (CET) Subject: JDK 14 record type representation in classfile format? In-Reply-To: References: <210577329.1731587.1584813604436.JavaMail.zimbra@u-pem.fr> <795763192.1760146.1584820917588.JavaMail.zimbra@u-pem.fr> <085e2b81-dbab-2c82-a0d9-778938a47cc6@oracle.com> Message-ID: <73385428.1999698.1584892463235.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Brian Goetz" > ?: "Luke Hutchison" , "Vicente Romero" > Cc: "amber-dev" , "compiler-dev" > Envoy?: Dimanche 22 Mars 2020 16:31:17 > Objet: Re: JDK 14 record type representation in classfile format? > This does not appear to be specific to records at all; javac seems to > generate an IC attribute whenever you _use_ a nested class.? For example: > > import java.lang.invoke.*; > public class Foo { > ??? MethodHandles.Lookup lookup = null; > } > > has the following attribute in it: > > InnerClasses: > ? public static final #7= #6 of #20;????? // Lookup=class > java/lang/invoke/MethodHandles$Lookup of class > java/lang/invoke/MethodHandles not exactly, here you are declaring lookup as a field. If lookup is a local variable the attribute InnerClasses is not present. public class Foo { public static void main(String[] args) { MethodHandles.Lookup lookup = null; } } > > > While this has nothing to do with records, it may still be worth > discussing whether this attribute is necessary, incorrect, or harmful. > (Note that Lookup is a _nested_ class of MethodHandles, but not an > _inner_ one, since it is static.) > R?mi > > On 3/21/2020 7:42 PM, Luke Hutchison wrote: >> In classes I have looked at in the past, if there is an InnerClasses class >> attribute, then the listed inner class containment hierarchy always forms a >> tree rooted at the defining class, and with the tree structure defined by >> the outer_class_info and inner_class_info entries in the InnerClasses >> attribute. >> >> In this case, the outer_class_info is for MethodHandle, and MethodHandle is >> not actually an inner class of the record class, so it seems strange that >> the record class would list MethodHandle$Lookup as an inner class, rather >> than the MethodHandle class listing MethodHandle$Lookup as an inner class. >> >> (I admit I don't understand how bootstrap methods work at the deepest level > > though, so maybe I'm missing something.) From forax at univ-mlv.fr Sun Mar 22 16:06:00 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 22 Mar 2020 17:06:00 +0100 (CET) Subject: JDK 14 record type representation in classfile format? In-Reply-To: <73385428.1999698.1584892463235.JavaMail.zimbra@u-pem.fr> References: <210577329.1731587.1584813604436.JavaMail.zimbra@u-pem.fr> <795763192.1760146.1584820917588.JavaMail.zimbra@u-pem.fr> <085e2b81-dbab-2c82-a0d9-778938a47cc6@oracle.com> <73385428.1999698.1584892463235.JavaMail.zimbra@u-pem.fr> Message-ID: <387181119.2004488.1584893160412.JavaMail.zimbra@u-pem.fr> To me, it seems to be needed for the separate compilation, when javac reads the type of a class members that contains a '$', it has no idea if it's an inner class or not, the attributes InnerClasses is there to disambiguate. If i'm right, this attributes is not needed in records equals/hashCode/toString or when doing a string concat because in both cases, those operations are inside the bytecode. R?mi ----- Mail original ----- > De: "Remi Forax" > ?: "Brian Goetz" > Cc: "amber-dev" , "compiler-dev" , "Luke Hutchison" > > Envoy?: Dimanche 22 Mars 2020 16:54:23 > Objet: Re: JDK 14 record type representation in classfile format? > ----- Mail original ----- >> De: "Brian Goetz" >> ?: "Luke Hutchison" , "Vicente Romero" >> >> Cc: "amber-dev" , "compiler-dev" >> >> Envoy?: Dimanche 22 Mars 2020 16:31:17 >> Objet: Re: JDK 14 record type representation in classfile format? > >> This does not appear to be specific to records at all; javac seems to >> generate an IC attribute whenever you _use_ a nested class.? For example: >> >> import java.lang.invoke.*; >> public class Foo { >> ??? MethodHandles.Lookup lookup = null; >> } >> >> has the following attribute in it: >> >> InnerClasses: >> ? public static final #7= #6 of #20;????? // Lookup=class >> java/lang/invoke/MethodHandles$Lookup of class >> java/lang/invoke/MethodHandles > > > not exactly, here you are declaring lookup as a field. > If lookup is a local variable the attribute InnerClasses is not present. > > public class Foo { > public static void main(String[] args) { > MethodHandles.Lookup lookup = null; > } > } > >> >> >> While this has nothing to do with records, it may still be worth >> discussing whether this attribute is necessary, incorrect, or harmful. >> (Note that Lookup is a _nested_ class of MethodHandles, but not an >> _inner_ one, since it is static.) >> > > > R?mi > >> >> On 3/21/2020 7:42 PM, Luke Hutchison wrote: >>> In classes I have looked at in the past, if there is an InnerClasses class >>> attribute, then the listed inner class containment hierarchy always forms a >>> tree rooted at the defining class, and with the tree structure defined by >>> the outer_class_info and inner_class_info entries in the InnerClasses >>> attribute. >>> >>> In this case, the outer_class_info is for MethodHandle, and MethodHandle is >>> not actually an inner class of the record class, so it seems strange that >>> the record class would list MethodHandle$Lookup as an inner class, rather >>> than the MethodHandle class listing MethodHandle$Lookup as an inner class. >>> >>> (I admit I don't understand how bootstrap methods work at the deepest level > > > though, so maybe I'm missing something.) From vitalyd at gmail.com Mon Mar 23 12:35:16 2020 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 23 Mar 2020 08:35:16 -0400 Subject: javac 11.0.6 NullPointerException when a type param refers to missing type In-Reply-To: References: Message-ID: Hi guys, Wanted to bring this up in case the mail slipped through. If there's any additional info that you'd like, happy to provide it. Or if there's a more appropriate channel to report this, please let me know; I thought about going to JBS directly, but pinging this list seemed like a good start. Thanks! On Wed, Mar 18, 2020 at 7:47 PM Vitaly Davidovich wrote: > Hi all, > > I'd like to report a bug against javac 11.0.6 (and possibly later, but I > don't readily have access to newer versions). > > To reproduce: > > Create the following 3 source files: > > ////// A.java > > public class A> { > > public void foo() {} > > } > > > > ////// B.java > > public class B {} > > > > ////// C.java > > public class C { > > public static void crashJavaC(A a) { > > a.foo(null); > > } > > } > > > $ javac A.java B.java > > $ rm B.java B.class > > $ javac C.java > > An exception has occurred in the compiler (11.0.6). Please file a bug > against the Java compiler via the Java bug reporting page ( > http://bugreport.java.com) after checking the Bug Database ( > http://bugs.java.com) for duplicates. Include your program and the > following diagnostic in your report. Thank you. > > java.lang.NullPointerException > > at > jdk.compiler/com.sun.tools.javac.comp.TransTypes.visitSelect(TransTypes.java:811) > > at > jdk.compiler/com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:2114) > > at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > > at > jdk.compiler/com.sun.tools.javac.comp.TransTypes.translate(TransTypes.java:454) > > at > jdk.compiler/com.sun.tools.javac.comp.TransTypes.visitApply(TransTypes.java:622) > > at > jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1634) > > at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > > at > jdk.compiler/com.sun.tools.javac.comp.TransTypes.translate(TransTypes.java:454) > > at > jdk.compiler/com.sun.tools.javac.comp.TransTypes.visitExec(TransTypes.java:599) > > at > jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1452) > > at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > > at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:70) > > at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.visitBlock(TreeTranslator.java:167) > > at > jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1020) > > at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > > at > jdk.compiler/com.sun.tools.javac.comp.TransTypes.translate(TransTypes.java:454) > > at > jdk.compiler/com.sun.tools.javac.comp.TransTypes.visitMethodDef(TransTypes.java:489) > > at > jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:866) > > at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > > at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:70) > > at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.visitClassDef(TreeTranslator.java:139) > > at > jdk.compiler/com.sun.tools.javac.comp.TransTypes.translateClass(TransTypes.java:918) > > at > jdk.compiler/com.sun.tools.javac.comp.TransTypes.visitClassDef(TransTypes.java:475) > > at > jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:774) > > at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > > at > jdk.compiler/com.sun.tools.javac.comp.TransTypes.translate(TransTypes.java:454) > > at > jdk.compiler/com.sun.tools.javac.comp.TransTypes.translateTopLevelClass(TransTypes.java:942) > > at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1553) > > at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1432) > > at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973) > > at > jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:311) > > at > jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170) > > at > jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57) > > at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43) > > > If B.java *is* present, we get the expected compilation error: > > $ javac C.java > > C.java:3: error: method foo in class A cannot be applied to given types; > > a.foo(null); > > ^ > > required: no arguments > > found: > > reason: actual and formal argument lists differ in length > > where T is a type-variable: > > T extends B declared in class A > > 1 error > > > The repro is (purposely) contrived. The real case came up when build > infrastructure prevented the source path of B.java from being observed when > building C.java. > > > I assume javac shouldn't crash with an NPE, and should instead provide a > compilation error pointing out that B symbol is not found (or similar). > > > Let me know if you have any questions. > > > Thanks! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Mon Mar 23 12:52:04 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 23 Mar 2020 12:52:04 +0000 Subject: javac 11.0.6 NullPointerException when a type param refers to missing type In-Reply-To: References: Message-ID: <829f4728-c704-a6de-a161-a38bdc0de8bc@oracle.com> Hi Vitaly, this is indeed an issue - although I seem to be able to reproduce even with 8 (tested with both u40 and u211): An exception has occurred in the compiler (1.8.0_40-ea). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport)? after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report.? Thank you. java.lang.NullPointerException ??? at com.sun.tools.javac.comp.TransTypes.visitSelect(TransTypes.java:826) ??? at com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1897) ??? at com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) ??? at com.sun.tools.javac.comp.TransTypes.translate(TransTypes.java:490) ??? at com.sun.tools.javac.comp.TransTypes.visitApply(TransTypes.java:666) ??? at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1465) ??? at com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) ??? at com.sun.tools.javac.comp.TransTypes.translate(TransTypes.java:490) ??? at com.sun.tools.javac.comp.TransTypes.visitExec(TransTypes.java:644) ??? at com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1296) ??? at com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) ??? at com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:70) ??? at com.sun.tools.javac.tree.TreeTranslator.visitBlock(TreeTranslator.java:162) ??? at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:909) ??? at com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) ??? at com.sun.tools.javac.comp.TransTypes.translate(TransTypes.java:490) ??? at com.sun.tools.javac.comp.TransTypes.visitMethodDef(TransTypes.java:525) ??? at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:778) ??? at com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) ??? at com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:70) ??? at com.sun.tools.javac.tree.TreeTranslator.visitClassDef(TreeTranslator.java:134) ??? at com.sun.tools.javac.comp.TransTypes.translateClass(TransTypes.java:1007) ??? at com.sun.tools.javac.comp.TransTypes.visitClassDef(TransTypes.java:511) ??? at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:693) ??? at com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) ??? at com.sun.tools.javac.comp.TransTypes.translate(TransTypes.java:490) ??? at com.sun.tools.javac.comp.TransTypes.translateTopLevelClass(TransTypes.java:1035) ??? at com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1486) ??? at com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1356) ??? at com.sun.tools.javac.main.JavaCompiler.compile2(JavaCompiler.java:901) ??? at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:860) ??? at com.sun.tools.javac.main.Main.compile(Main.java:523) ??? at com.sun.tools.javac.main.Main.compile(Main.java:381) ??? at com.sun.tools.javac.main.Main.compile(Main.java:370) ??? at com.sun.tools.javac.main.Main.compile(Main.java:361) ??? at com.sun.tools.javac.Main.compile(Main.java:56) ??? at com.sun.tools.javac.Main.main(Main.java:42) I've filed a new issue - but this I've not marked it as a regression, because it doesn't seem one, unless I'm missing something. https://bugs.openjdk.java.net/browse/JDK-8241441 Thanks Maurizio On 18/03/2020 23:47, Vitaly Davidovich wrote: > Hi all, > > I'd like to report a bug against javac 11.0.6 (and possibly later, but > I don't readily have access to newer versions). > > To reproduce: > > Create the following 3 source files: > > ////// A.java > > public class A> { > > ??? public void foo() {} > > } > > ////// B.java > > public class B {} > > ////// C.java > > public class C { > > ??? public static void crashJavaC(A a) { > > ??????? a.foo(null); > > ??? } > > } > > > $ javac A.java B.java > > $ rm B.java B.class > > $ javac C.java > > An exception has occurred in the compiler (11.0.6). Please file a bug > against the Java compiler via the Java bug reporting page > (http://bugreport.java.com ) after > checking the Bug Database (http://bugs.java.com > ) for duplicates. Include your program and the > following diagnostic in your report. Thank you. > > java.lang.NullPointerException > > ??????????????? at > jdk.compiler/com.sun.tools.javac.comp.TransTypes.visitSelect(TransTypes.java:811) > > ??????????????? at > jdk.compiler/com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:2114) > > ??????????????? at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > > ??????????????? at > jdk.compiler/com.sun.tools.javac.comp.TransTypes.translate(TransTypes.java:454) > > ??????????????? at > jdk.compiler/com.sun.tools.javac.comp.TransTypes.visitApply(TransTypes.java:622) > > ??????????????? at > jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1634) > > ??????????????? at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > > ??????????????? at > jdk.compiler/com.sun.tools.javac.comp.TransTypes.translate(TransTypes.java:454) > > ??????????????? at > jdk.compiler/com.sun.tools.javac.comp.TransTypes.visitExec(TransTypes.java:599) > > ??????????????? at > jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1452) > > ??????????????? at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > > ??????????????? at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:70) > > ??????????????? at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.visitBlock(TreeTranslator.java:167) > > ??????????????? at > jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1020) > > ??????????????? at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > > ??????????????? at > jdk.compiler/com.sun.tools.javac.comp.TransTypes.translate(TransTypes.java:454) > > ??????????????? at > jdk.compiler/com.sun.tools.javac.comp.TransTypes.visitMethodDef(TransTypes.java:489) > > ??????????????? at > jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:866) > > ??????????????? at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > > ??????????????? at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:70) > > ??????????????? at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.visitClassDef(TreeTranslator.java:139) > > ??????????????? at > jdk.compiler/com.sun.tools.javac.comp.TransTypes.translateClass(TransTypes.java:918) > > ??????????????? at > jdk.compiler/com.sun.tools.javac.comp.TransTypes.visitClassDef(TransTypes.java:475) > > ??????????????? at > jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:774) > > ??????????????? at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > > ??????????????? at > jdk.compiler/com.sun.tools.javac.comp.TransTypes.translate(TransTypes.java:454) > > ??????????????? at > jdk.compiler/com.sun.tools.javac.comp.TransTypes.translateTopLevelClass(TransTypes.java:942) > > ??????????????? at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1553) > > ??????????????? at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1432) > > ??????????????? at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973) > > ??????????????? at > jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:311) > > ??????????????? at > jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170) > > ??????????????? at > jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57) > > ??????????????? at > jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43) > > > If B.java *is* present, we get the expected compilation error: > > $ javac C.java > > C.java:3: error: method foo in class A cannot be applied to given > types; > > ??????? a.foo(null); > > ???????? ^ > > ? required: no arguments > > ? found: > > ? reason: actual and formal argument lists differ in length > > ? where T is a type-variable: > > ??? T extends B declared in class A > > 1 error > > > The repro is (purposely) contrived.? The real case came up when build > infrastructure prevented the source path of B.java from being observed > when building C.java. > > > I assume javac shouldn't crash with an NPE, and should instead provide > a compilation error pointing out that B symbol is not found (or similar). > > > Let me know if you have any questions. > > > Thanks! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitalyd at gmail.com Mon Mar 23 13:04:30 2020 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 23 Mar 2020 09:04:30 -0400 Subject: javac 11.0.6 NullPointerException when a type param refers to missing type In-Reply-To: <829f4728-c704-a6de-a161-a38bdc0de8bc@oracle.com> References: <829f4728-c704-a6de-a161-a38bdc0de8bc@oracle.com> Message-ID: Hi Maurizio, Thanks for the quick reply! To be honest, I didn't even check if 8 had the same issue - we observed this on 11 so I just put the concrete version in the subject :). Thanks again! On Mon, Mar 23, 2020 at 8:52 AM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > Hi Vitaly, > this is indeed an issue - although I seem to be able to reproduce even > with 8 (tested with both u40 and u211): > > An exception has occurred in the compiler (1.8.0_40-ea). Please file a bug > at the Java Developer Connection (http://java.sun.com/webapps/bugreport) > after checking the Bug Parade for duplicates. Include your program and the > following diagnostic in your report. Thank you. > java.lang.NullPointerException > at com.sun.tools.javac.comp.TransTypes.visitSelect(TransTypes.java:826) > at > com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1897) > at > com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > at com.sun.tools.javac.comp.TransTypes.translate(TransTypes.java:490) > at com.sun.tools.javac.comp.TransTypes.visitApply(TransTypes.java:666) > at > com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1465) > at > com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > at com.sun.tools.javac.comp.TransTypes.translate(TransTypes.java:490) > at com.sun.tools.javac.comp.TransTypes.visitExec(TransTypes.java:644) > at > com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1296) > at > com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > at > com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:70) > at > com.sun.tools.javac.tree.TreeTranslator.visitBlock(TreeTranslator.java:162) > at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:909) > at > com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > at com.sun.tools.javac.comp.TransTypes.translate(TransTypes.java:490) > at > com.sun.tools.javac.comp.TransTypes.visitMethodDef(TransTypes.java:525) > at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:778) > at > com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > at > com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:70) > at > com.sun.tools.javac.tree.TreeTranslator.visitClassDef(TreeTranslator.java:134) > at > com.sun.tools.javac.comp.TransTypes.translateClass(TransTypes.java:1007) > at > com.sun.tools.javac.comp.TransTypes.visitClassDef(TransTypes.java:511) > at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:693) > at > com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > at com.sun.tools.javac.comp.TransTypes.translate(TransTypes.java:490) > at > com.sun.tools.javac.comp.TransTypes.translateTopLevelClass(TransTypes.java:1035) > at > com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1486) > at > com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1356) > at > com.sun.tools.javac.main.JavaCompiler.compile2(JavaCompiler.java:901) > at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:860) > at com.sun.tools.javac.main.Main.compile(Main.java:523) > at com.sun.tools.javac.main.Main.compile(Main.java:381) > at com.sun.tools.javac.main.Main.compile(Main.java:370) > at com.sun.tools.javac.main.Main.compile(Main.java:361) > at com.sun.tools.javac.Main.compile(Main.java:56) > at com.sun.tools.javac.Main.main(Main.java:42) > > > I've filed a new issue - but this I've not marked it as a regression, > because it doesn't seem one, unless I'm missing something. > > https://bugs.openjdk.java.net/browse/JDK-8241441 > > Thanks > Maurizio > On 18/03/2020 23:47, Vitaly Davidovich wrote: > > Hi all, > > I'd like to report a bug against javac 11.0.6 (and possibly later, but I > don't readily have access to newer versions). > > To reproduce: > > Create the following 3 source files: > > ////// A.java > > public class A> { > > public void foo() {} > > } > > > > ////// B.java > > public class B {} > > > > ////// C.java > > public class C { > > public static void crashJavaC(A a) { > > a.foo(null); > > } > > } > > > $ javac A.java B.java > > $ rm B.java B.class > > $ javac C.java > > An exception has occurred in the compiler (11.0.6). Please file a bug > against the Java compiler via the Java bug reporting page ( > http://bugreport.java.com) after checking the Bug Database ( > http://bugs.java.com) for duplicates. Include your program and the > following diagnostic in your report. Thank you. > > java.lang.NullPointerException > > at > jdk.compiler/com.sun.tools.javac.comp.TransTypes.visitSelect(TransTypes.java:811) > > at > jdk.compiler/com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:2114) > > at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > > at > jdk.compiler/com.sun.tools.javac.comp.TransTypes.translate(TransTypes.java:454) > > at > jdk.compiler/com.sun.tools.javac.comp.TransTypes.visitApply(TransTypes.java:622) > > at > jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1634) > > at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > > at > jdk.compiler/com.sun.tools.javac.comp.TransTypes.translate(TransTypes.java:454) > > at > jdk.compiler/com.sun.tools.javac.comp.TransTypes.visitExec(TransTypes.java:599) > > at > jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1452) > > at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > > at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:70) > > at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.visitBlock(TreeTranslator.java:167) > > at > jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1020) > > at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > > at > jdk.compiler/com.sun.tools.javac.comp.TransTypes.translate(TransTypes.java:454) > > at > jdk.compiler/com.sun.tools.javac.comp.TransTypes.visitMethodDef(TransTypes.java:489) > > at > jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:866) > > at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > > at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:70) > > at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.visitClassDef(TreeTranslator.java:139) > > at > jdk.compiler/com.sun.tools.javac.comp.TransTypes.translateClass(TransTypes.java:918) > > at > jdk.compiler/com.sun.tools.javac.comp.TransTypes.visitClassDef(TransTypes.java:475) > > at > jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:774) > > at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > > at > jdk.compiler/com.sun.tools.javac.comp.TransTypes.translate(TransTypes.java:454) > > at > jdk.compiler/com.sun.tools.javac.comp.TransTypes.translateTopLevelClass(TransTypes.java:942) > > at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1553) > > at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1432) > > at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973) > > at > jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:311) > > at > jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170) > > at > jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57) > > at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43) > > > If B.java *is* present, we get the expected compilation error: > > $ javac C.java > > C.java:3: error: method foo in class A cannot be applied to given types; > > a.foo(null); > > ^ > > required: no arguments > > found: > > reason: actual and formal argument lists differ in length > > where T is a type-variable: > > T extends B declared in class A > > 1 error > > > The repro is (purposely) contrived. The real case came up when build > infrastructure prevented the source path of B.java from being observed when > building C.java. > > > I assume javac shouldn't crash with an NPE, and should instead provide a > compilation error pointing out that B symbol is not found (or similar). > > > Let me know if you have any questions. > > > Thanks! > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Mon Mar 23 14:31:00 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 23 Mar 2020 14:31:00 +0000 Subject: Enhancing expressions with mutability? In-Reply-To: References: Message-ID: <9238fa7d-3035-6f10-7334-3772df712584@oracle.com> Hey Bernard, cool stuff. Your patch seems to be missing the Term class, which is kind of important to look at to see how it interoperates with javac. That said, while the ideas you explore are interesting, I do not seem them being applicable 'as is' to Java. That said, one direction which overlaps a lot to what you describe here, especially in your derivative example is support for the so called expression trees feature - C# for example has it [1]. Expression trees gives the language a new super power, in that it allows the static compiler to create a richer intermediate form for the compiled expression (e.g. other than bytecode), which is then amenable to further processing at runtime - e.g. we could take this IR and compile it down to: * regular bytecode - e.g. to generate a method handle * assembly - very useful for native interop (a la Panama) * GPU kernel - very useful for offloading computation to GPU or other resources At the same time, if the IR is expressive enough, you can do things like differentiating functions and the likes, which are use cases very important in machine learning. So, my feeling is that, at some point, we'll start seeing some more concrete experiments in that direction - stay tuned :-) Maurizio [1] - https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/expression-trees/ On 10/03/2020 21:03, B. Blaser wrote: > Hi, > > Taking back the essential idea of the original publication on Lisp > [1], I did the attached syntactic experiment [2] trying to bring some > kind of mutability to expressions and thus giving more flexibility to > the language. I hope this subject hasn't been covered too many times, > otherwise I'd apologize for any disturbance. > > To build such mutable expressions, I've specified a new unary operator > ` along with its resulting class 'java.lang.Term'. The quotation > operator creates a 'Term' from any reference which can then be linked > to other terms to finally be evaluated to the result of a function > call for lambdas or the reference itself otherwise. > > Let's take some examples from the attached patch: > > + interface Get { > + int op(); > + } > + > + interface Sum { > + int op(int i, int j); > + } > > + int a = 0, b = 0; > + Sum s = (x, y) -> x + y; > > + public void run() { > + Get a = () -> this.a; > + Get b = () -> this.b; > + > + Term e1 = (`s).link(`a, `b); > + this.a = 1; this.b = 2; > > The above lines create a mutable expression e1 from the sum lambda s > of the getter a and b which can then be evaluated to: > > (Integer)e1.value() == 3 > > or visualized as: > > e1.toString().equals("Sum( Get( ) Get( ) )") > > An interesting application similar to ?3.g from [1] is the computation > of the partial derivative of a sum involving the mutation of the > initial expression to produce a new resulting one: > > + // Derivative of sum e with respect to r > + Term derivative(Term e, Term r) { > + if (e.terms.isEmpty()) { > + return `Integer.valueOf(e.that == r.that ? 1 : 0); > + } > + else if(e.that == (`s).that) { > + return (`s).link(derivative(e.terms.get(0), r), > derivative(e.terms.get(1), r)); > + } > + else throw new AssertionError(); > + } > > Invoking the above method like this: > > + Term e2 = derivative(e1, `a); > > creates the resulting derivative expression e2 which can then be evaluated to: > > (Integer)e2.value() == 1 > > or visualized as: > > e2.toString().equals("Sum( `1 `0 )") > > Finally, we note that any term may be quoted to prevent its > evaluation, for example: > > + Derivative d = this::derivative; > > + Term e3 = (`d).link(`e1, ``a); > > can be evaluated to: > > (Integer)((Term)e3.value()).value() == 1 > > or visualized as: > > e3.toString().equals("Derivative( `Sum( Get( ) Get( ) ) `Get( ) )") > > Of course, one of our main concern is how much do we need this and a > reasonable answer would probably be as much as we need Lisp's > S-expressions but with similar or maybe better performance than > external interpreters and a more homogeneous integration to the > language. > > Any feedback about this experiment would be welcome! > > Thanks, > Bernard > > [1] http://www-formal.stanford.edu/jmc/recursive.html > [2] quote.patch From jan.lahoda at oracle.com Mon Mar 23 14:42:51 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 23 Mar 2020 15:42:51 +0100 Subject: RFR/RFC: JDK-8241356: Use a more reliable way to encode Symbol flags Message-ID: Hi, Currently, (com.sun.tools.javac.code.)Symbol/s have a long field "flags_field", which holds various one-bit information ("Flags") about the given Symbol. We currently have around 64 such Flags, which means we are out of bits in the long field, and adding new flags is not easy. We could change the "flags_field" to be a Set over enums, but this would increase the memory footprint notably, and would also slow-down access to flags. Currently, flags operations in javac are very fast and very common, so this is probably too much burden. There are also flags to which we need to access as bit masks, e.g. due to writing to classfile. My proposal here is to use an intermediate solution, until we find a better solution, or until a better solution is possible (like due to Valhalla). The idea is as follows: -the current long-based Flags are split into 4 groups: --"flat" Flags, long based, work exactly as before. --enum-based TypeSymbolFlags, MethodSymbolFlags and VarSymbolFlags, which are only applicable to TypeSymbols, MethodSymbols and VarSymbols, respectively, and are checked using methods like Symbol.isFlagSet and set/clear using methods Symbol.setFlag and Symbol.clearFlag. So these flags are mostly encapsulated, even though physically they are currently stored in the flags_field as well. There are 37 "flat" flags and 16 TypeSymbolFlags (methods and vars have less flags), 53 in total. This gives us at least 10 new flags before we might run out of long bits in flags_field again - but even if we do, there are several easy mitigation strategies we could use, like: -create a new int/long field on TypeSymbols for the TypeSymbolFlags (probably preferable) -split TypeSymbolFlags into Class/Package/MethodSymbolFlags The positives of this solution include: -safe(r) access to the flags - the access to the extra/symbol-kind-specific flags is mostly encapsulated, and hence mostly safe -improves the abstractions at least for some flags -reasonably complex patch (attempts to encapsulate all the flags were troublesome in previous experiments) -the performances appears to be acceptable. The negative that I see is that the code includes several incompatible types of flags now. These cannot be easily confused by accident (as the type system will complain), but still we need to be aware of them when writing code. Some more alternatives: -add a new field to Symbol, like long extraFlags, and continue with bit masks as we did so far using this new field. The drawback is that it is more error prone (it would be difficult to ensure only the new/extra flags would be stored and read from extraFlags). -have a new field, and "flat" and non-"flat" enum-based encapsulated Flags, but don't separate Type/Method/Var flags. Probably something to consider, even though I am a bit reluctant to add new fields without trying to avoid it . Current proposed patch: http://cr.openjdk.java.net/~jlahoda/8241356/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8241356 Any feedback is welcome! Thanks, Jan From adam.sotona at oracle.com Mon Mar 23 15:44:51 2020 From: adam.sotona at oracle.com (Adam Sotona) Date: Mon, 23 Mar 2020 16:44:51 +0100 Subject: RFR: JDK-8239544 : Javac does not respect should-stop.ifNoError policy to stop after CompileState PARSE, ENTER and PROCESS Message-ID: Hi, I would like to ask you for review of the JavaCompiler patch fixing its response to should-stop.ifNoError= option for PARSE, ENTER and PROCESS compiler states. The patch also includes new T8239544.java matrix regression test validating the compiler really stops at the requested states even under various compiler policies. The most critical part of the fix was to do not affect existing (golden-file) tests expecting exact compiler errors and also do not affect MultiTaskListener expected behavior (and related tests). JBS: https://bugs.openjdk.java.net/browse/JDK-8239544 webrev: http://cr.openjdk.java.net/~asotona/8239544/webrev.00/ Mach5 build passed Tier1, Tier2 and Tier3 tests Thank you, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.laskey at oracle.com Mon Mar 23 15:50:34 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Mon, 23 Mar 2020 12:50:34 -0300 Subject: RFR: JDK-8239544 : Javac does not respect should-stop.ifNoError policy to stop after CompileState PARSE, ENTER and PROCESS In-Reply-To: References: Message-ID: I think coding standards recommend 950 if (!CompileState.ATTR.isAfter(shouldStopPolicyIfNoError)) switch (compilePolicy) { if (!CompileState.ATTR.isAfter(shouldStopPolicyIfNoError)) { switch (compilePolicy) { ... } otherwise +1 > On Mar 23, 2020, at 12:44 PM, Adam Sotona wrote: > > Hi, > I would like to ask you for review of the JavaCompiler patch fixing its response to should-stop.ifNoError= option for PARSE, ENTER and PROCESS compiler states. > The patch also includes new T8239544.java matrix regression test validating the compiler really stops at the requested states even under various compiler policies. > The most critical part of the fix was to do not affect existing (golden-file) tests expecting exact compiler errors and also do not affect MultiTaskListener expected behavior (and related tests). > > JBS: https://bugs.openjdk.java.net/browse/JDK-8239544 > webrev: http://cr.openjdk.java.net/~asotona/8239544/webrev.00/ > > Mach5 build passed Tier1, Tier2 and Tier3 tests > > Thank you, > Adam > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Mon Mar 23 15:52:18 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 23 Mar 2020 15:52:18 +0000 Subject: RFR: JDK-8240998: Implement javac changes for deconstruction patterns. In-Reply-To: References: <6d4820de-ff88-1bab-3fce-e9978de657f1@oracle.com> Message-ID: <7b0932fb-7c0e-6291-7c7a-9942a2295d1b@oracle.com> Hi Jan, the code looks generally good. I have some high-level questions: * it would be useful to see what kind of diagnostics are generated - I see some weird ones in the golden files (e.g. "DeconstructionPatternErrors.out" refer to "compiler.misc.type.none") * this might be a spec issue - there seems to be no support for varargs extraction - e.g. if a record is varargs: record Foo(int... is) { } shouldn't I be able to do this: if (o instanceof Foo(int i1, int i2, int i3)) { ... } Some more detailed comments below: * Attr.java - verifyCastable seems very similar to Check.checkCastable, except for non-reifiable types - should we try to unify a bit? * Attr.java - not sure I get the logic by which target type is propagated or not in visitDeconstructionPattern. Seems to me that the only case where you need propagation is when you have a nested component of the kind "var x" - in which case the type is determined by the expected record component type. But this: + boolean nestedIsValidPattern = !nestedPatterns.head.hasTag(BINDINGPATTERN) || + ((JCBindingPattern) nestedPatterns.head).vartype == null; Seems to point to a slightly different direction? - e.g. target type is propagated even if the nested is a deconstruction pattern, but then I don't see any use of resultInfo inside this visitor? * parser changes - looks good :-) * TransPattern - as usual, some comments illustrating basic desugared shapes would be nice Maurizio On 19/03/2020 17:25, Jan Lahoda wrote: > Hi, > > Turned out the patch had two bugs - one related to the owners of the > temporary variables created, which then broke type annotations; and > another that broken de-duplication. I am deeply sorry for that. An > updated webrev is here: > http://cr.openjdk.java.net/~jlahoda/8240998/webrev.01/ > > A delta from previous round: > http://cr.openjdk.java.net/~jlahoda/8240998/webrev.delta.00.01/ > > I am sorry for any inconvenience. > > Jan > > On 18. 03. 20 9:55, Jan Lahoda wrote: >> Hi, >> >> I would like to ask for a review for a patch that implements the >> deconstruction patterns, as described in JEP 375: >> https://bugs.openjdk.java.net/browse/JDK-8235186 >> >> The current specification draft is here: >> http://cr.openjdk.java.net/~gbierman/jep375/jep375-20200316/specs/patterns-instanceof-jls.html >> >> >> For this phase, the proposal is for javac to desugar the >> deconstruction patterns using record accessors. >> >> The CSR for this change is being written here: >> https://bugs.openjdk.java.net/browse/JDK-8240999 >> >> The proposed patch: >> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.00 >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8240998 >> >> Any feedback is welcome! >> >> Thanks, >> ???? Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.sandoz at oracle.com Mon Mar 23 16:00:30 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 23 Mar 2020 09:00:30 -0700 Subject: Enhancing expressions with mutability? In-Reply-To: <9238fa7d-3035-6f10-7334-3772df712584@oracle.com> References: <9238fa7d-3035-6f10-7334-3772df712584@oracle.com> Message-ID: <3C71B207-24D0-429F-80A9-EB9C6E2AC381@oracle.com> Hi, Yes, interesting stuff. I agree with Maurizio here, naturally because we have talked about this area a few times. C# expression trees and LINQ is a great example. I think we can apply this more broadly to source compile time, link time and runtime, and more broadly to the source that can be ?quoted? (or target typed, rather than built programmatically). Such an IR could be an interchange format between various domains. A significant challenge is to find the right structural form to support many use cases. The machine learning area is particularly interesting to me in this respect. There appears to be an explosion in bespoke static compiler pipelines and analysis of code. Paul. > On Mar 23, 2020, at 7:31 AM, Maurizio Cimadamore wrote: > > Hey Bernard, > cool stuff. Your patch seems to be missing the Term class, which is kind of important to look at to see how it interoperates with javac. > > That said, while the ideas you explore are interesting, I do not seem them being applicable 'as is' to Java. That said, one direction which overlaps a lot to what you describe here, especially in your derivative example is support for the so called expression trees feature - C# for example has it [1]. > > Expression trees gives the language a new super power, in that it allows the static compiler to create a richer intermediate form for the compiled expression (e.g. other than bytecode), which is then amenable to further processing at runtime - e.g. we could take this IR and compile it down to: > > * regular bytecode - e.g. to generate a method handle > * assembly - very useful for native interop (a la Panama) > * GPU kernel - very useful for offloading computation to GPU or other resources > > At the same time, if the IR is expressive enough, you can do things like differentiating functions and the likes, which are use cases very important in machine learning. > > So, my feeling is that, at some point, we'll start seeing some more concrete experiments in that direction - stay tuned :-) > > Maurizio > > [1] - https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/expression-trees/ > > On 10/03/2020 21:03, B. Blaser wrote: >> Hi, >> >> Taking back the essential idea of the original publication on Lisp >> [1], I did the attached syntactic experiment [2] trying to bring some >> kind of mutability to expressions and thus giving more flexibility to >> the language. I hope this subject hasn't been covered too many times, >> otherwise I'd apologize for any disturbance. >> >> To build such mutable expressions, I've specified a new unary operator >> ` along with its resulting class 'java.lang.Term'. The quotation >> operator creates a 'Term' from any reference which can then be linked >> to other terms to finally be evaluated to the result of a function >> call for lambdas or the reference itself otherwise. >> >> Let's take some examples from the attached patch: >> >> + interface Get { >> + int op(); >> + } >> + >> + interface Sum { >> + int op(int i, int j); >> + } >> >> + int a = 0, b = 0; >> + Sum s = (x, y) -> x + y; >> >> + public void run() { >> + Get a = () -> this.a; >> + Get b = () -> this.b; >> + >> + Term e1 = (`s).link(`a, `b); >> + this.a = 1; this.b = 2; >> >> The above lines create a mutable expression e1 from the sum lambda s >> of the getter a and b which can then be evaluated to: >> >> (Integer)e1.value() == 3 >> >> or visualized as: >> >> e1.toString().equals("Sum( Get( ) Get( ) )") >> >> An interesting application similar to ?3.g from [1] is the computation >> of the partial derivative of a sum involving the mutation of the >> initial expression to produce a new resulting one: >> >> + // Derivative of sum e with respect to r >> + Term derivative(Term e, Term r) { >> + if (e.terms.isEmpty()) { >> + return `Integer.valueOf(e.that == r.that ? 1 : 0); >> + } >> + else if(e.that == (`s).that) { >> + return (`s).link(derivative(e.terms.get(0), r), >> derivative(e.terms.get(1), r)); >> + } >> + else throw new AssertionError(); >> + } >> >> Invoking the above method like this: >> >> + Term e2 = derivative(e1, `a); >> >> creates the resulting derivative expression e2 which can then be evaluated to: >> >> (Integer)e2.value() == 1 >> >> or visualized as: >> >> e2.toString().equals("Sum( `1 `0 )") >> >> Finally, we note that any term may be quoted to prevent its >> evaluation, for example: >> >> + Derivative d = this::derivative; >> >> + Term e3 = (`d).link(`e1, ``a); >> >> can be evaluated to: >> >> (Integer)((Term)e3.value()).value() == 1 >> >> or visualized as: >> >> e3.toString().equals("Derivative( `Sum( Get( ) Get( ) ) `Get( ) )") >> >> Of course, one of our main concern is how much do we need this and a >> reasonable answer would probably be as much as we need Lisp's >> S-expressions but with similar or maybe better performance than >> external interpreters and a more homogeneous integration to the >> language. >> >> Any feedback about this experiment would be welcome! >> >> Thanks, >> Bernard >> >> [1] http://www-formal.stanford.edu/jmc/recursive.html >> [2] quote.patch From bsrbnd at gmail.com Mon Mar 23 19:01:50 2020 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 23 Mar 2020 20:01:50 +0100 Subject: Enhancing expressions with mutability? In-Reply-To: <3C71B207-24D0-429F-80A9-EB9C6E2AC381@oracle.com> References: <9238fa7d-3035-6f10-7334-3772df712584@oracle.com> <3C71B207-24D0-429F-80A9-EB9C6E2AC381@oracle.com> Message-ID: Thanks for your feedback, Paul and Maurizio. On Mon, 23 Mar 2020 at 17:00, Paul Sandoz wrote: > > Hi, > > Yes, interesting stuff. > > I agree with Maurizio here, naturally because we have talked about this area a few times. > > C# expression trees and LINQ is a great example. I think we can apply this more broadly to source compile time, link time and runtime, and more broadly to the source that can be ?quoted? (or target typed, rather than built programmatically). > > Such an IR could be an interchange format between various domains. A significant challenge is to find the right structural form to support many use cases. The machine learning area is particularly interesting to me in this respect. There appears to be an explosion in bespoke static compiler pipelines and analysis of code. > I agree that finding the right design is a challenge. I chose the very flexible approach of Lisp-like S-Expressions, but C# offers interesting more restrictive expression trees too which seem to be used in dynamic queries, for example (as I suggested in [2]). But another common use would be for AI in general like evolutionary computation that I'm planning to employ experimentally to solve some tricky performance issues in javac's type inference solving system, see [3]. > Paul. > > > On Mar 23, 2020, at 7:31 AM, Maurizio Cimadamore wrote: > > > > Hey Bernard, > > cool stuff. Your patch seems to be missing the Term class, which is kind of important to look at to see how it interoperates with javac. > > I believe this is the first class of the initially attached 'quote.patch' [4] (next are javac changes along with the test), did you miss it? > > That said, while the ideas you explore are interesting, I do not seem them being applicable 'as is' to Java. That said, one direction which overlaps a lot to what you describe here, especially in your derivative example is support for the so called expression trees feature - C# for example has it [1]. > > I'm not so familiar with C# but some difference I can immediately see is that expression trees seem to use some static typing discipline which prevents them from being modified directly (new ones have to be created). My suggestion is closer to Lisp's S-Expression using a more relaxed dynamic typing discipline enabling full manipulation of existing expressions. > > Expression trees gives the language a new super power, in that it allows the static compiler to create a richer intermediate form for the compiled expression (e.g. other than bytecode), which is then amenable to further processing at runtime - e.g. we could take this IR and compile it down to: > > > > * regular bytecode - e.g. to generate a method handle > > * assembly - very useful for native interop (a la Panama) > > * GPU kernel - very useful for offloading computation to GPU or other resources > > > > At the same time, if the IR is expressive enough, you can do things like differentiating functions and the likes, which are use cases very important in machine learning. > > Yes, my prototype currently relies on reflection to evaluate expressions but the perfect solution would be to ask the JVM to compile them, of course :-) > > So, my feeling is that, at some point, we'll start seeing some more concrete experiments in that direction - stay tuned :-) > > Great, are you planning to do this as part of an existing project like Panama or are you going to create a new one? Ciao, Bernard > > Maurizio > > > > [1] - https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/expression-trees/ > > [2] http://mail.openjdk.java.net/pipermail/compiler-dev/2020-March/014340.html [3] http://mail.openjdk.java.net/pipermail/compiler-dev/2020-March/014377.html [4] https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20200310/54c5274c/quote-0001.patch From magnus.ihse.bursie at oracle.com Mon Mar 23 19:03:26 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 23 Mar 2020 20:03:26 +0100 Subject: RFR: JDK-8241463 Move build tools to respective modules Message-ID: The build tools (small java tools that are run during the build to generate source code, or data, needed in the JDK) have historically been placed in the "make" directory. This maybe made sense long time ago, but does not do so anymore. Instead, the build tools source code should move the the module that needs them. For instance, compilefontconfig should move to java.desktop, etc. There are multiple reasons for this: * Currently we build *all* build tools at once, which mean that we cannot compile java.base until e.g. the compilefontconfig tool is compiled, even though it is not needed. * If a build tool, e.g. compilefontconfig is modified, all build tools are recompiled, which triggers a rebuild of more or less the entire JDK. This makes development of the build tools unnecessary tedious. * When the build tools are modified, the group owning the corresponding module is the proper review instance, not the build team. But since they reside under "make", the review mails often include build-dev, but this is mostly noise for us. With this move, the ownership is made clear. In this patch, I have not modified how and when the build tools are compiled, but this shuffle is the prerequisite for continuing with that in a follow-up patch. I have also moved the build tools to the org.openjdk.buildtools.* package name space (inspired by Skara), instead of the strangely named build.tools.* name space. A few build tools are not moved in this patch. Two of them, charsetmapping and cldrconverter, are shared between two modules. (I think they should move to modules nevertheless, but they need some more thought to make sure I do this right.) The rest are tools that are needed for the build in general, like linking or javadoc support. I'll move this to a better location too, but in a separate patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8241463 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8241463-move-build-tools-to-modules/webrev.01 /Magnus From maurizio.cimadamore at oracle.com Mon Mar 23 19:33:38 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 23 Mar 2020 19:33:38 +0000 Subject: Enhancing expressions with mutability? In-Reply-To: References: <9238fa7d-3035-6f10-7334-3772df712584@oracle.com> <3C71B207-24D0-429F-80A9-EB9C6E2AC381@oracle.com> Message-ID: <6a4113cb-5e51-4406-cf26-d24d8474f257@oracle.com> > I'm planning to employ experimentally to solve some > tricky performance issues in javac's type inference solving system, > see [3]. With respect to implement type inference using these algorithms, I feel less sanguine. While theoretically possible, genetic algorithms usually goes through making random variations in a set of values, and iteratively keeping the values that fit best a given scoring function. Yes, we can define the scoring function to be "does the solution satisfy the bounds" - but getting there by randomly changing variable resolution until you find "one that sticks" doesn't seem amenable in the general case, although I can definitively buy that, in _that specific example_ you refer to, doing things that way is faster than doing things how javac does it (which is wildly suboptimal - hence the bug). There are also other assumptions in your prototype that are, I think, too simplistic - e.g. the fact that you can replace subtyping with subclassing (the latter is of course much faster, and has many many less degrees of freedom) - and, while a strategy like this might converge quickly to a solution, when writing a static compiler is also very important to take into account the case where no solution exists (e.g. compiler error) - do I have to wait forever until all possible permutations are ran? How will error messages be reported (or even determined)? So, while expression-tree-like approaches are very powerful and expressive, I think that a properly implemented and optimized type inference algorithm will always provide better and more predictable performances in the general case. >>> Hey Bernard, >>> cool stuff. Your patch seems to be missing the Term class, which is kind of important to look at to see how it interoperates with javac. >>> > I believe this is the first class of the initially attached > 'quote.patch' [4] (next are javac changes along with the test), did > you miss it? Whoops - yes! > Great, are you planning to do this as part of an existing project like > Panama or are you going to create a new one? At this moment we're exploring what's available out there - we have some ideas of the use cases we'd like to cover, but no specific proposal as of yet. While it's true that some of the core use cases are close to the spirit of Panama, some of the applications are also much broader - so I can see this going both ways. In any case, it's way too early to make such a call :-) Maurizio > > Ciao, > Bernard > >>> Maurizio >>> >>> [1] - https://urldefense.com/v3/__https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/expression-trees/__;!!GqivPVa7Brio!NfcoHAGJenwaQiTQ8X9WraJnbuoptP3p-CDxaw9iRIV0u9WCJI8z_RuUJLBrpHWd0BFKVWs$ >>> > [2] http://mail.openjdk.java.net/pipermail/compiler-dev/2020-March/014340.html > [3] http://mail.openjdk.java.net/pipermail/compiler-dev/2020-March/014377.html > [4] https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20200310/54c5274c/quote-0001.patch From erik.joelsson at oracle.com Mon Mar 23 19:54:44 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 23 Mar 2020 12:54:44 -0700 Subject: RFR: JDK-8241463 Move build tools to respective modules In-Reply-To: References: Message-ID: <705f74a1-8f64-166c-63d1-7174c89443cd@oracle.com> Looks good. /Erik On 2020-03-23 12:03, Magnus Ihse Bursie wrote: > The build tools (small java tools that are run during the build to > generate source code, or data, needed in the JDK) have historically > been placed in the "make" directory. This maybe made sense long time > ago, but does not do so anymore. > > Instead, the build tools source code should move the the module that > needs them. For instance, compilefontconfig should move to > java.desktop, etc. > > There are multiple reasons for this: > > * Currently we build *all* build tools at once, which mean that we > cannot compile java.base until e.g. the compilefontconfig tool is > compiled, even though it is not needed. > > * If a build tool, e.g. compilefontconfig is modified, all build tools > are recompiled, which triggers a rebuild of more or less the entire > JDK. This makes development of the build tools unnecessary tedious. > > * When the build tools are modified, the group owning the > corresponding module is the proper review instance, not the build > team. But since they reside under "make", the review mails often > include build-dev, but this is mostly noise for us. With this move, > the ownership is made clear. > > In this patch, I have not modified how and when the build tools are > compiled, but this shuffle is the prerequisite for continuing with > that in a follow-up patch. > > I have also moved the build tools to the org.openjdk.buildtools.* > package name space (inspired by Skara), instead of the strangely named > build.tools.* name space. > > A few build tools are not moved in this patch. Two of them, > charsetmapping and cldrconverter, are shared between two modules. (I > think they should move to modules nevertheless, but they need some > more thought to make sure I do this right.) The rest are tools that > are needed for the build in general, like linking or javadoc support. > I'll move this to a better location too, but in a separate patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8241463 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8241463-move-build-tools-to-modules/webrev.01 > > /Magnus > From mandy.chung at oracle.com Mon Mar 23 20:19:13 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 23 Mar 2020 13:19:13 -0700 Subject: RFR: JDK-8241463 Move build tools to respective modules In-Reply-To: References: Message-ID: <53d7119b-5e7e-22fe-97c1-0382f2d94fbc@oracle.com> Hi Magnus, Modularizing the build tools is a good move.??? This patch suggests to place the build tools under ??? src/$MODULE/share/tools/$PACKAGE/*.java I think the modular source location of the build tools needs more discussion, including jigsaw-dev for this discussion. The JDK source as specified in JEP 201 is under: ??? src/$MODULE/{share,$OS}/classes/$PACKAGE/*.java Compiling the source files from the `src` directory are the intermediate input to build the resulting image.??? Build tools are used to generate additional intermediate input (that is not part of the `src` directory) to build the image.?? So I wonder if make/$MODULE/share/tools or make/tools/$MODULE? may be better location for the build tools. Mandy On 3/23/20 12:03 PM, Magnus Ihse Bursie wrote: > The build tools (small java tools that are run during the build to > generate source code, or data, needed in the JDK) have historically > been placed in the "make" directory. This maybe made sense long time > ago, but does not do so anymore. > > Instead, the build tools source code should move the the module that > needs them. For instance, compilefontconfig should move to > java.desktop, etc. > > There are multiple reasons for this: > > * Currently we build *all* build tools at once, which mean that we > cannot compile java.base until e.g. the compilefontconfig tool is > compiled, even though it is not needed. > > * If a build tool, e.g. compilefontconfig is modified, all build tools > are recompiled, which triggers a rebuild of more or less the entire > JDK. This makes development of the build tools unnecessary tedious. > > * When the build tools are modified, the group owning the > corresponding module is the proper review instance, not the build > team. But since they reside under "make", the review mails often > include build-dev, but this is mostly noise for us. With this move, > the ownership is made clear. > > In this patch, I have not modified how and when the build tools are > compiled, but this shuffle is the prerequisite for continuing with > that in a follow-up patch. > > I have also moved the build tools to the org.openjdk.buildtools.* > package name space (inspired by Skara), instead of the strangely named > build.tools.* name space. > > A few build tools are not moved in this patch. Two of them, > charsetmapping and cldrconverter, are shared between two modules. (I > think they should move to modules nevertheless, but they need some > more thought to make sure I do this right.) The rest are tools that > are needed for the build in general, like linking or javadoc support. > I'll move this to a better location too, but in a separate patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8241463 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8241463-move-build-tools-to-modules/webrev.01 > > /Magnus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Mar 23 20:33:50 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 Mar 2020 20:33:50 +0000 Subject: RFR: JDK-8241463 Move build tools to respective modules In-Reply-To: References: Message-ID: <20158b4b-f6f1-92e1-59da-d0f6c07a85ca@oracle.com> On 23/03/2020 19:03, Magnus Ihse Bursie wrote: > The build tools (small java tools that are run during the build to > generate source code, or data, needed in the JDK) have historically > been placed in the "make" directory. This maybe made sense long time > ago, but does not do so anymore. > > Instead, the build tools source code should move the the module that > needs them. For instance, compilefontconfig should move to > java.desktop, etc. > > There are multiple reasons for this: > > * Currently we build *all* build tools at once, which mean that we > cannot compile java.base until e.g. the compilefontconfig tool is > compiled, even though it is not needed. > > * If a build tool, e.g. compilefontconfig is modified, all build tools > are recompiled, which triggers a rebuild of more or less the entire > JDK. This makes development of the build tools unnecessary tedious. > > * When the build tools are modified, the group owning the > corresponding module is the proper review instance, not the build > team. But since they reside under "make", the review mails often > include build-dev, but this is mostly noise for us. With this move, > the ownership is made clear. > > In this patch, I have not modified how and when the build tools are > compiled, but this shuffle is the prerequisite for continuing with > that in a follow-up patch. > > I have also moved the build tools to the org.openjdk.buildtools.* > package name space (inspired by Skara), instead of the strangely named > build.tools.* name space. > > A few build tools are not moved in this patch. Two of them, > charsetmapping and cldrconverter, are shared between two modules. (I > think they should move to modules nevertheless, but they need some > more thought to make sure I do this right.) The rest are tools that > are needed for the build in general, like linking or javadoc support. > I'll move this to a better location too, but in a separate patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8241463 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8241463-move-build-tools-to-modules/webrev.01 I think this will require further discussion, maybe even an update to JEP 201. I think it would be useful to see what other options were exploring, in particular options that organize the tools by module in the make tree (as it will confuse people to put them in the src tree). -Alan From naoto.sato at oracle.com Mon Mar 23 22:15:31 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 23 Mar 2020 15:15:31 -0700 Subject: RFR: JDK-8241463 Move build tools to respective modules In-Reply-To: References: Message-ID: Hi Magnus, I looked at i18n related changes: make/CopyInterimTZDB.gmk make/ToolsJdk.gmk make/gendata/Gendata-java.base.gmk make/gendata/GendataBreakIterator.gmk make/gendata/GendataTZDB.gmk make/gensrc/GensrcCharacterData.gmk make/gensrc/GensrcEmojiData.gmk They look ok to me. The *.java changes should have copyright year update. As to charsetmapping and cldrconverter, I believe they can reside in java.base, as jdk.charsets and jdk.localedata modules depend on it. Naoto On 3/23/20 12:03 PM, Magnus Ihse Bursie wrote: > The build tools (small java tools that are run during the build to > generate source code, or data, needed in the JDK) have historically been > placed in the "make" directory. This maybe made sense long time ago, but > does not do so anymore. > > Instead, the build tools source code should move the the module that > needs them. For instance, compilefontconfig should move to java.desktop, > etc. > > There are multiple reasons for this: > > * Currently we build *all* build tools at once, which mean that we > cannot compile java.base until e.g. the compilefontconfig tool is > compiled, even though it is not needed. > > * If a build tool, e.g. compilefontconfig is modified, all build tools > are recompiled, which triggers a rebuild of more or less the entire JDK. > This makes development of the build tools unnecessary tedious. > > * When the build tools are modified, the group owning the corresponding > module is the proper review instance, not the build team. But since they > reside under "make", the review mails often include build-dev, but this > is mostly noise for us. With this move, the ownership is made clear. > > In this patch, I have not modified how and when the build tools are > compiled, but this shuffle is the prerequisite for continuing with that > in a follow-up patch. > > I have also moved the build tools to the org.openjdk.buildtools.* > package name space (inspired by Skara), instead of the strangely named > build.tools.* name space. > > A few build tools are not moved in this patch. Two of them, > charsetmapping and cldrconverter, are shared between two modules. (I > think they should move to modules nevertheless, but they need some more > thought to make sure I do this right.) The rest are tools that are > needed for the build in general, like linking or javadoc support. I'll > move this to a better location too, but in a separate patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8241463 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8241463-move-build-tools-to-modules/webrev.01 > > > /Magnus > From adam.sotona at oracle.com Tue Mar 24 10:25:48 2020 From: adam.sotona at oracle.com (Adam Sotona) Date: Tue, 24 Mar 2020 11:25:48 +0100 Subject: RFR: JDK-8239544 : Javac does not respect should-stop.ifNoError policy to stop after CompileState PARSE, ENTER and PROCESS In-Reply-To: References: Message-ID: <72C60872-0764-45AC-8E86-A33F531B885E@oracle.com> I'll fix the formatting Thank you, Adam > On 23 Mar 2020, at 16:50, Jim Laskey wrote: > > I think coding standards recommend > > > 950 > if (!CompileState.ATTR.isAfter(shouldStopPolicyIfNoError)) switch (compilePolicy) { > > if (!CompileState.ATTR.isAfter(shouldStopPolicyIfNoError)) { > switch (compilePolicy) { > > ... > } > > otherwise +1 > > > > >> On Mar 23, 2020, at 12:44 PM, Adam Sotona > wrote: >> >> Hi, >> I would like to ask you for review of the JavaCompiler patch fixing its response to should-stop.ifNoError= option for PARSE, ENTER and PROCESS compiler states. >> The patch also includes new T8239544.java matrix regression test validating the compiler really stops at the requested states even under various compiler policies. >> The most critical part of the fix was to do not affect existing (golden-file) tests expecting exact compiler errors and also do not affect MultiTaskListener expected behavior (and related tests). >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8239544 >> webrev: http://cr.openjdk.java.net/~asotona/8239544/webrev.00/ >> >> Mach5 build passed Tier1, Tier2 and Tier3 tests >> >> Thank you, >> Adam >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.laskey at oracle.com Tue Mar 24 12:04:40 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 24 Mar 2020 09:04:40 -0300 Subject: RFR: JDK-8239544 : Javac does not respect should-stop.ifNoError policy to stop after CompileState PARSE, ENTER and PROCESS In-Reply-To: References: Message-ID: <5E286896-78B2-4680-B56D-6E937366A6F7@oracle.com> No problem. Just get one other reviewer. > On Mar 23, 2020, at 12:44 PM, Adam Sotona wrote: > > Hi, > I would like to ask you for review of the JavaCompiler patch fixing its response to should-stop.ifNoError= option for PARSE, ENTER and PROCESS compiler states. > The patch also includes new T8239544.java matrix regression test validating the compiler really stops at the requested states even under various compiler policies. > The most critical part of the fix was to do not affect existing (golden-file) tests expecting exact compiler errors and also do not affect MultiTaskListener expected behavior (and related tests). > > JBS: https://bugs.openjdk.java.net/browse/JDK-8239544 > webrev: http://cr.openjdk.java.net/~asotona/8239544/webrev.00/ > > Mach5 build passed Tier1, Tier2 and Tier3 tests > > Thank you, > Adam > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Tue Mar 24 12:12:45 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 24 Mar 2020 13:12:45 +0100 Subject: RFR: JDK-8241463 Move build tools to respective modules In-Reply-To: References: Message-ID: <01a1c812-1adb-a4a2-3db0-327f76c0b21c@oracle.com> On 2020-03-23 23:15, naoto.sato at oracle.com wrote: > Hi Magnus, > > I looked at i18n related changes: > > make/CopyInterimTZDB.gmk > make/ToolsJdk.gmk > make/gendata/Gendata-java.base.gmk > make/gendata/GendataBreakIterator.gmk > make/gendata/GendataTZDB.gmk > make/gensrc/GensrcCharacterData.gmk > make/gensrc/GensrcEmojiData.gmk > > They look ok to me. Thank you! > > The *.java changes should have copyright year update. Ok, I'll update them. > > As to charsetmapping and cldrconverter, I believe they can reside in > java.base, as jdk.charsets and jdk.localedata modules depend on it. Okay. It's not ideal, but I think you're right. I'll move them as well. I'll publish an updated webrev with these changes when there's agreement on where in the source code tree to move the files. /Magnus > > Naoto > > On 3/23/20 12:03 PM, Magnus Ihse Bursie wrote: >> The build tools (small java tools that are run during the build to >> generate source code, or data, needed in the JDK) have historically >> been placed in the "make" directory. This maybe made sense long time >> ago, but does not do so anymore. >> >> Instead, the build tools source code should move the the module that >> needs them. For instance, compilefontconfig should move to >> java.desktop, etc. >> >> There are multiple reasons for this: >> >> * Currently we build *all* build tools at once, which mean that we >> cannot compile java.base until e.g. the compilefontconfig tool is >> compiled, even though it is not needed. >> >> * If a build tool, e.g. compilefontconfig is modified, all build >> tools are recompiled, which triggers a rebuild of more or less the >> entire JDK. This makes development of the build tools unnecessary >> tedious. >> >> * When the build tools are modified, the group owning the >> corresponding module is the proper review instance, not the build >> team. But since they reside under "make", the review mails often >> include build-dev, but this is mostly noise for us. With this move, >> the ownership is made clear. >> >> In this patch, I have not modified how and when the build tools are >> compiled, but this shuffle is the prerequisite for continuing with >> that in a follow-up patch. >> >> I have also moved the build tools to the org.openjdk.buildtools.* >> package name space (inspired by Skara), instead of the strangely >> named build.tools.* name space. >> >> A few build tools are not moved in this patch. Two of them, >> charsetmapping and cldrconverter, are shared between two modules. (I >> think they should move to modules nevertheless, but they need some >> more thought to make sure I do this right.) The rest are tools that >> are needed for the build in general, like linking or javadoc support. >> I'll move this to a better location too, but in a separate patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8241463 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8241463-move-build-tools-to-modules/webrev.01 >> >> >> /Magnus >> From jan.lahoda at oracle.com Wed Mar 25 08:54:05 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 25 Mar 2020 09:54:05 +0100 Subject: RFR: JDK-8240998: Implement javac changes for deconstruction patterns. In-Reply-To: <7b0932fb-7c0e-6291-7c7a-9942a2295d1b@oracle.com> References: <6d4820de-ff88-1bab-3fce-e9978de657f1@oracle.com> <7b0932fb-7c0e-6291-7c7a-9942a2295d1b@oracle.com> Message-ID: <2ce9dc0e-4305-6ab1-7e4f-2407aeb79c1c@oracle.com> Hi Maurizio, Thanks for the comments! An updated version of the patch is here: http://cr.openjdk.java.net/~jlahoda/8240998/webrev.02/ diff to previous patch: http://cr.openjdk.java.net/~jlahoda/8240998/webrev.delta.01.02/ On 23. 03. 20 16:52, Maurizio Cimadamore wrote: > Hi Jan, > the code looks generally good. I have some high-level questions: > > * it would be useful to see what kind of diagnostics are generated - I > see some weird ones in the golden files (e.g. > "DeconstructionPatternErrors.out" refer to "compiler.misc.type.none") Diag samples: http://cr.openjdk.java.net/~jlahoda/8240998/diags-examples.html Output of DeconstructionPatternErrors: http://cr.openjdk.java.net/~jlahoda/8240998/DeconstructionPatternErrors.txt Regarding the compiler.misc.type.none (which maps to "") - this is in a case where there are too many nested patterns in the deconstruction pattern, and the trailing nested pattern(s) is/are "var" pattern(s). So this is some kind of indeterminable type, and "" does not seem too off. > > * this might be a spec issue - there seems to be no support for varargs > extraction - e.g. if a record is varargs: > > record Foo(int... is) { } > > shouldn't I be able to do this: > > if (o instanceof Foo(int i1, int i2, int i3)) { ... } I believe the spec does not currently allow this, although I assume there will be discussions about features like this in the future. > > > Some more detailed comments below: > > * Attr.java - verifyCastable seems very similar to Check.checkCastable, > except for non-reifiable types - should we try to unify a bit? > > * Attr.java - not sure I get the logic by which target type is > propagated or not in visitDeconstructionPattern. Seems to me that the > only case where you need propagation is when you have a nested component > of the kind "var x" - in which case the type is determined by the > expected record component type. But this: > > + boolean nestedIsValidPattern = > !nestedPatterns.head.hasTag(BINDINGPATTERN) || > + ((JCBindingPattern) nestedPatterns.head).vartype == null; > > Seems to point to a slightly different direction? - e.g. target type is > propagated even if the nested is a deconstruction pattern, but then I > don't see any use of resultInfo inside this visitor? Probably a remainder of any patterns. I've cleaned this up. > > * parser changes - looks good :-) > > * TransPattern - as usual, some comments illustrating basic desugared > shapes would be nice Done. Thanks, Jan > > Maurizio > > On 19/03/2020 17:25, Jan Lahoda wrote: >> Hi, >> >> Turned out the patch had two bugs - one related to the owners of the >> temporary variables created, which then broke type annotations; and >> another that broken de-duplication. I am deeply sorry for that. An >> updated webrev is here: >> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.01/ >> >> A delta from previous round: >> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.delta.00.01/ >> >> I am sorry for any inconvenience. >> >> Jan >> >> On 18. 03. 20 9:55, Jan Lahoda wrote: >>> Hi, >>> >>> I would like to ask for a review for a patch that implements the >>> deconstruction patterns, as described in JEP 375: >>> https://bugs.openjdk.java.net/browse/JDK-8235186 >>> >>> The current specification draft is here: >>> http://cr.openjdk.java.net/~gbierman/jep375/jep375-20200316/specs/patterns-instanceof-jls.html >>> >>> >>> For this phase, the proposal is for javac to desugar the >>> deconstruction patterns using record accessors. >>> >>> The CSR for this change is being written here: >>> https://bugs.openjdk.java.net/browse/JDK-8240999 >>> >>> The proposed patch: >>> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.00 >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8240998 >>> >>> Any feedback is welcome! >>> >>> Thanks, >>> ???? Jan From maurizio.cimadamore at oracle.com Wed Mar 25 19:25:06 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 25 Mar 2020 19:25:06 +0000 Subject: RFR: JDK-8240998: Implement javac changes for deconstruction patterns. In-Reply-To: <2ce9dc0e-4305-6ab1-7e4f-2407aeb79c1c@oracle.com> References: <6d4820de-ff88-1bab-3fce-e9978de657f1@oracle.com> <7b0932fb-7c0e-6291-7c7a-9942a2295d1b@oracle.com> <2ce9dc0e-4305-6ab1-7e4f-2407aeb79c1c@oracle.com> Message-ID: <61ba6362-d8a7-aa57-d39e-a9d10c3e31e7@oracle.com> On 25/03/2020 08:54, Jan Lahoda wrote: > Hi Maurizio, > > Thanks for the comments! > > An updated version of the patch is here: > http://cr.openjdk.java.net/~jlahoda/8240998/webrev.02/ > diff to previous patch: > http://cr.openjdk.java.net/~jlahoda/8240998/webrev.delta.01.02/ Looks good - minor nit, in the comments in TransPattern: //PATTn for record component COMPn of type Tn; + //PATTn is a type test pattern or a deconstruction pattern: + //=> + //(let Tn $c$COMPn = ((T) N$temp).COMPn(); ) + //or + //(let Tn $c$COMPn = ((T) N$temp).COMPn(); $c$COMPn != null && ) + //or + //(let Tn $c$COMPn = ((T) N$temp).COMPn(); $c$COMPn instanceof T' && ) Shouldn't we use either or in all of them, consistently? That's what the code appears to be doing. > On 23. 03. 20 16:52, Maurizio Cimadamore wrote: >> Hi Jan, >> the code looks generally good. I have some high-level questions: >> >> * it would be useful to see what kind of diagnostics are generated - >> I see some weird ones in the golden files (e.g. >> "DeconstructionPatternErrors.out" refer to "compiler.misc.type.none") > > Diag samples: > http://cr.openjdk.java.net/~jlahoda/8240998/diags-examples.html > > Output of DeconstructionPatternErrors: > http://cr.openjdk.java.net/~jlahoda/8240998/DeconstructionPatternErrors.txt > Thanks! Look good. > > Regarding the compiler.misc.type.none (which maps to "") - this > is in a case where there are too many nested patterns in the > deconstruction pattern, and the trailing nested pattern(s) is/are > "var" pattern(s). So this is some kind of indeterminable type, and > "" does not seem too off. I'd suggest to use the tree printing machinery we have for deferred type arguments in the rich diagnostic formatter - that would give you better results, I believe. Not sure if I'd prefer to break down this: "deconstruction patterns can only be applied to records, String is not a record" into: "invalid deconstruction pattern" "String is not a record" Maurizio > >> >> * this might be a spec issue - there seems to be no support for >> varargs extraction - e.g. if a record is varargs: >> >> record Foo(int... is) { } >> >> shouldn't I be able to do this: >> >> if (o instanceof Foo(int i1, int i2, int i3)) { ... } > > I believe the spec does not currently allow this, although I assume > there will be discussions about features like this in the future. Ok > >> >> >> Some more detailed comments below: >> >> * Attr.java - verifyCastable seems very similar to >> Check.checkCastable, except for non-reifiable types - should we try >> to unify a bit? >> >> * Attr.java - not sure I get the logic by which target type is >> propagated or not in visitDeconstructionPattern. Seems to me that the >> only case where you need propagation is when you have a nested >> component of the kind "var x" - in which case the type is determined >> by the expected record component type. But this: >> >> + boolean nestedIsValidPattern = >> !nestedPatterns.head.hasTag(BINDINGPATTERN) || >> + ((JCBindingPattern) nestedPatterns.head).vartype == null; >> >> Seems to point to a slightly different direction? - e.g. target type >> is propagated even if the nested is a deconstruction pattern, but >> then I don't see any use of resultInfo inside this visitor? > > Probably a remainder of any patterns. I've cleaned this up. > >> >> * parser changes - looks good :-) >> >> * TransPattern - as usual, some comments illustrating basic desugared >> shapes would be nice > > Done. > > Thanks, > ??? Jan > >> >> Maurizio >> >> On 19/03/2020 17:25, Jan Lahoda wrote: >>> Hi, >>> >>> Turned out the patch had two bugs - one related to the owners of the >>> temporary variables created, which then broke type annotations; and >>> another that broken de-duplication. I am deeply sorry for that. An >>> updated webrev is here: >>> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.01/ >>> >>> A delta from previous round: >>> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.delta.00.01/ >>> >>> I am sorry for any inconvenience. >>> >>> Jan >>> >>> On 18. 03. 20 9:55, Jan Lahoda wrote: >>>> Hi, >>>> >>>> I would like to ask for a review for a patch that implements the >>>> deconstruction patterns, as described in JEP 375: >>>> https://bugs.openjdk.java.net/browse/JDK-8235186 >>>> >>>> The current specification draft is here: >>>> http://cr.openjdk.java.net/~gbierman/jep375/jep375-20200316/specs/patterns-instanceof-jls.html >>>> >>>> >>>> For this phase, the proposal is for javac to desugar the >>>> deconstruction patterns using record accessors. >>>> >>>> The CSR for this change is being written here: >>>> https://bugs.openjdk.java.net/browse/JDK-8240999 >>>> >>>> The proposed patch: >>>> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.00 >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8240998 >>>> >>>> Any feedback is welcome! >>>> >>>> Thanks, >>>> ???? Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.sotona at oracle.com Thu Mar 26 14:45:21 2020 From: adam.sotona at oracle.com (Adam Sotona) Date: Thu, 26 Mar 2020 15:45:21 +0100 Subject: RFR: JDK-8239544 : Javac does not respect should-stop.ifNoError policy to stop after CompileState PARSE, ENTER and PROCESS In-Reply-To: <5E286896-78B2-4680-B56D-6E937366A6F7@oracle.com> References: <5E286896-78B2-4680-B56D-6E937366A6F7@oracle.com> Message-ID: Hi, I've returned back to the issue and found the patch is affecting annotation processing negatively for cases of "recoverable" errors. Here is slightly modified fix that does not cause premature stop before annotation processing in such specific situations. Also the T823954.java test had to be written a bit more complex way to correctly test annotation processing stopping. new webrev: http://cr.openjdk.java.net/~asotona/8239544/webrev.01/ Mach5 build passed Tier1, Tier2 and Tier3 tests (except for java/net/httpclient/FilePublisher/FilePublisherPermsTest.java, which seems to be unrelated). Thanks for your review, Adam > On 24 Mar 2020, at 13:04, Jim Laskey wrote: > > No problem. Just get one other reviewer. > >> On Mar 23, 2020, at 12:44 PM, Adam Sotona > wrote: >> >> Hi, >> I would like to ask you for review of the JavaCompiler patch fixing its response to should-stop.ifNoError= option for PARSE, ENTER and PROCESS compiler states. >> The patch also includes new T8239544.java matrix regression test validating the compiler really stops at the requested states even under various compiler policies. >> The most critical part of the fix was to do not affect existing (golden-file) tests expecting exact compiler errors and also do not affect MultiTaskListener expected behavior (and related tests). >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8239544 >> webrev: http://cr.openjdk.java.net/~asotona/8239544/webrev.00/ >> >> Mach5 build passed Tier1, Tier2 and Tier3 tests >> >> Thank you, >> Adam >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.laskey at oracle.com Thu Mar 26 14:55:02 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Thu, 26 Mar 2020 11:55:02 -0300 Subject: RFR: JDK-8239544 : Javac does not respect should-stop.ifNoError policy to stop after CompileState PARSE, ENTER and PROCESS In-Reply-To: References: <5E286896-78B2-4680-B56D-6E937366A6F7@oracle.com> Message-ID: <6B378786-3175-4647-919A-2B2D6348AA94@oracle.com> +1 > On Mar 26, 2020, at 11:45 AM, Adam Sotona wrote: > > Hi, > I've returned back to the issue and found the patch is affecting annotation processing negatively for cases of "recoverable" errors. > Here is slightly modified fix that does not cause premature stop before annotation processing in such specific situations. > Also the T823954.java test had to be written a bit more complex way to correctly test annotation processing stopping. > > new webrev: http://cr.openjdk.java.net/~asotona/8239544/webrev.01/ > > Mach5 build passed Tier1, Tier2 and Tier3 tests (except for java/net/httpclient/FilePublisher/FilePublisherPermsTest.java, which seems to be unrelated). > > Thanks for your review, > Adam > >> On 24 Mar 2020, at 13:04, Jim Laskey > wrote: >> >> No problem. Just get one other reviewer. >> >>> On Mar 23, 2020, at 12:44 PM, Adam Sotona > wrote: >>> >>> Hi, >>> I would like to ask you for review of the JavaCompiler patch fixing its response to should-stop.ifNoError= option for PARSE, ENTER and PROCESS compiler states. >>> The patch also includes new T8239544.java matrix regression test validating the compiler really stops at the requested states even under various compiler policies. >>> The most critical part of the fix was to do not affect existing (golden-file) tests expecting exact compiler errors and also do not affect MultiTaskListener expected behavior (and related tests). >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8239544 >>> webrev: http://cr.openjdk.java.net/~asotona/8239544/webrev.00/ >>> >>> Mach5 build passed Tier1, Tier2 and Tier3 tests >>> >>> Thank you, >>> Adam >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Fri Mar 27 10:35:43 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 27 Mar 2020 11:35:43 +0100 Subject: RFR: JDK-8240998: Implement javac changes for deconstruction patterns. In-Reply-To: <61ba6362-d8a7-aa57-d39e-a9d10c3e31e7@oracle.com> References: <6d4820de-ff88-1bab-3fce-e9978de657f1@oracle.com> <7b0932fb-7c0e-6291-7c7a-9942a2295d1b@oracle.com> <2ce9dc0e-4305-6ab1-7e4f-2407aeb79c1c@oracle.com> <61ba6362-d8a7-aa57-d39e-a9d10c3e31e7@oracle.com> Message-ID: <5eaa7292-4e49-7d04-9fbd-6ec508804f24@oracle.com> On 25. 03. 20 20:25, Maurizio Cimadamore wrote: > > On 25/03/2020 08:54, Jan Lahoda wrote: >> Hi Maurizio, >> >> Thanks for the comments! >> >> An updated version of the patch is here: >> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.02/ >> diff to previous patch: >> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.delta.01.02/ > > Looks good - minor nit, in the comments in TransPattern: > > //PATTn for record component COMPn of type Tn; > + //PATTn is a type test pattern or a deconstruction pattern: > + //=> > + //(let Tn $c$COMPn = ((T) N$temp).COMPn(); ) > + //or > + //(let Tn $c$COMPn = ((T) N$temp).COMPn(); $c$COMPn != null && > ) > + //or > + //(let Tn $c$COMPn = ((T) N$temp).COMPn(); $c$COMPn instanceof T' && > ) > > > Shouldn't we use either or in all > of them, consistently? That's what the code appears to be doing. Thanks, I've updated the comments (+one golden output). Full Webrev: https://cr.openjdk.java.net/~jlahoda/8240998/webrev.03/ Delta from previous: https://cr.openjdk.java.net/~jlahoda/8240998/webrev.delta.02.03/ Does this look better? Thanks, Jan > > >> On 23. 03. 20 16:52, Maurizio Cimadamore wrote: >>> Hi Jan, >>> the code looks generally good. I have some high-level questions: >>> >>> * it would be useful to see what kind of diagnostics are generated - >>> I see some weird ones in the golden files (e.g. >>> "DeconstructionPatternErrors.out" refer to "compiler.misc.type.none") >> >> Diag samples: >> http://cr.openjdk.java.net/~jlahoda/8240998/diags-examples.html >> >> Output of DeconstructionPatternErrors: >> http://cr.openjdk.java.net/~jlahoda/8240998/DeconstructionPatternErrors.txt >> > Thanks! Look good. >> >> Regarding the compiler.misc.type.none (which maps to "") - this >> is in a case where there are too many nested patterns in the >> deconstruction pattern, and the trailing nested pattern(s) is/are >> "var" pattern(s). So this is some kind of indeterminable type, and >> "" does not seem too off. > > I'd suggest to use the tree printing machinery we have for deferred type > arguments in the rich diagnostic formatter - that would give you better > results, I believe. > > Not sure if I'd prefer to break down this: > > "deconstruction patterns can only be applied to records, String is not a > record" > > into: > > "invalid deconstruction pattern" > > "String is not a record" > > Maurizio > >> >>> >>> * this might be a spec issue - there seems to be no support for >>> varargs extraction - e.g. if a record is varargs: >>> >>> record Foo(int... is) { } >>> >>> shouldn't I be able to do this: >>> >>> if (o instanceof Foo(int i1, int i2, int i3)) { ... } >> >> I believe the spec does not currently allow this, although I assume >> there will be discussions about features like this in the future. > Ok >> >>> >>> >>> Some more detailed comments below: >>> >>> * Attr.java - verifyCastable seems very similar to >>> Check.checkCastable, except for non-reifiable types - should we try >>> to unify a bit? >>> >>> * Attr.java - not sure I get the logic by which target type is >>> propagated or not in visitDeconstructionPattern. Seems to me that the >>> only case where you need propagation is when you have a nested >>> component of the kind "var x" - in which case the type is determined >>> by the expected record component type. But this: >>> >>> + boolean nestedIsValidPattern = >>> !nestedPatterns.head.hasTag(BINDINGPATTERN) || >>> + ((JCBindingPattern) nestedPatterns.head).vartype == null; >>> >>> Seems to point to a slightly different direction? - e.g. target type >>> is propagated even if the nested is a deconstruction pattern, but >>> then I don't see any use of resultInfo inside this visitor? >> >> Probably a remainder of any patterns. I've cleaned this up. >> >>> >>> * parser changes - looks good :-) >>> >>> * TransPattern - as usual, some comments illustrating basic desugared >>> shapes would be nice >> >> Done. >> >> Thanks, >> ??? Jan >> >>> >>> Maurizio >>> >>> On 19/03/2020 17:25, Jan Lahoda wrote: >>>> Hi, >>>> >>>> Turned out the patch had two bugs - one related to the owners of the >>>> temporary variables created, which then broke type annotations; and >>>> another that broken de-duplication. I am deeply sorry for that. An >>>> updated webrev is here: >>>> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.01/ >>>> >>>> A delta from previous round: >>>> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.delta.00.01/ >>>> >>>> I am sorry for any inconvenience. >>>> >>>> Jan >>>> >>>> On 18. 03. 20 9:55, Jan Lahoda wrote: >>>>> Hi, >>>>> >>>>> I would like to ask for a review for a patch that implements the >>>>> deconstruction patterns, as described in JEP 375: >>>>> https://bugs.openjdk.java.net/browse/JDK-8235186 >>>>> >>>>> The current specification draft is here: >>>>> http://cr.openjdk.java.net/~gbierman/jep375/jep375-20200316/specs/patterns-instanceof-jls.html >>>>> >>>>> >>>>> For this phase, the proposal is for javac to desugar the >>>>> deconstruction patterns using record accessors. >>>>> >>>>> The CSR for this change is being written here: >>>>> https://bugs.openjdk.java.net/browse/JDK-8240999 >>>>> >>>>> The proposed patch: >>>>> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.00 >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8240998 >>>>> >>>>> Any feedback is welcome! >>>>> >>>>> Thanks, >>>>> ???? Jan From forax at univ-mlv.fr Fri Mar 27 19:09:28 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 27 Mar 2020 20:09:28 +0100 (CET) Subject: JDK 14 record type representation in classfile format? In-Reply-To: References: <085e2b81-dbab-2c82-a0d9-778938a47cc6@oracle.com> <73385428.1999698.1584892463235.JavaMail.zimbra@u-pem.fr> <387181119.2004488.1584893160412.JavaMail.zimbra@u-pem.fr> Message-ID: <1713523742.1496394.1585336168925.JavaMail.zimbra@u-pem.fr> > De: "Luke Hutchison" > ?: "Remi Forax" > Cc: "Brian Goetz" , "amber-dev" > , "compiler-dev" > Envoy?: Vendredi 27 Mars 2020 19:19:09 > Objet: Re: JDK 14 record type representation in classfile format? > On Sun, Mar 22, 2020 at 10:06 AM Remi Forax < [ mailto:forax at univ-mlv.fr | > forax at univ-mlv.fr ] > wrote: >> To me, it seems to be needed for the separate compilation, >> when javac reads the type of a class members that contains a '$', it has no idea >> if it's an inner class or not, >> the attributes InnerClasses is there to disambiguate. > But the java.lang.invoke.MethodHandles$Lookup class itself contains an > InnerClasses attribute with the mapping of innerClass = > "java.lang.invoke.MethodHandles$Lookup", outerClass = > "java.lang.invoke.MethodHandles". So the JRE can resolve this by looking at the > Lookup itself, which logically should be the intent. It's not the JRE, it's the compiler. Rewording what you are saying, "the InnerClass attribute is also present at declaration site, so there is no need to have it at use site". > I don't see why this information would need to be duplicated in every class that > needs access to the Lookup class due to the use of bootstrap methods. That does > not seem right to me There is a good reason to duplicate the metadata declared at declaration site at callsite, it means that you can avoid to load the class containing the metadata. Here the compiler can find the classfile of the inner class without finding/loading the outer class. cheers, R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Sat Mar 28 00:43:41 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Sat, 28 Mar 2020 00:43:41 +0000 Subject: RFR: JDK-8240998: Implement javac changes for deconstruction patterns. In-Reply-To: <5eaa7292-4e49-7d04-9fbd-6ec508804f24@oracle.com> References: <6d4820de-ff88-1bab-3fce-e9978de657f1@oracle.com> <7b0932fb-7c0e-6291-7c7a-9942a2295d1b@oracle.com> <2ce9dc0e-4305-6ab1-7e4f-2407aeb79c1c@oracle.com> <61ba6362-d8a7-aa57-d39e-a9d10c3e31e7@oracle.com> <5eaa7292-4e49-7d04-9fbd-6ec508804f24@oracle.com> Message-ID: <9a45922e-0e00-aef9-416c-be33740a9234@oracle.com> Looks good to me Maurizio On 27/03/2020 10:35, Jan Lahoda wrote: > On 25. 03. 20 20:25, Maurizio Cimadamore wrote: >> >> On 25/03/2020 08:54, Jan Lahoda wrote: >>> Hi Maurizio, >>> >>> Thanks for the comments! >>> >>> An updated version of the patch is here: >>> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.02/ >>> diff to previous patch: >>> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.delta.01.02/ >> >> Looks good - minor nit, in the comments in TransPattern: >> >> //PATTn for record component COMPn of type Tn; >> + //PATTn is a type test pattern or a deconstruction pattern: >> + //=> >> + //(let Tn $c$COMPn = ((T) N$temp).COMPn(); ) >> + //or >> + //(let Tn $c$COMPn = ((T) N$temp).COMPn(); $c$COMPn != null && >> ) >> + //or >> + //(let Tn $c$COMPn = ((T) N$temp).COMPn(); $c$COMPn instanceof T' >> && ) >> >> >> Shouldn't we use either or in >> all of them, consistently? That's what the code appears to be doing. > > Thanks, I've updated the comments (+one golden output). > > Full Webrev: > https://cr.openjdk.java.net/~jlahoda/8240998/webrev.03/ > > Delta from previous: > https://cr.openjdk.java.net/~jlahoda/8240998/webrev.delta.02.03/ > > Does this look better? > > Thanks, > ??? Jan > >> >> >>> On 23. 03. 20 16:52, Maurizio Cimadamore wrote: >>>> Hi Jan, >>>> the code looks generally good. I have some high-level questions: >>>> >>>> * it would be useful to see what kind of diagnostics are generated >>>> - I see some weird ones in the golden files (e.g. >>>> "DeconstructionPatternErrors.out" refer to "compiler.misc.type.none") >>> >>> Diag samples: >>> http://cr.openjdk.java.net/~jlahoda/8240998/diags-examples.html >>> >>> Output of DeconstructionPatternErrors: >>> http://cr.openjdk.java.net/~jlahoda/8240998/DeconstructionPatternErrors.txt >>> >> Thanks! Look good. >>> >>> Regarding the compiler.misc.type.none (which maps to "") - >>> this is in a case where there are too many nested patterns in the >>> deconstruction pattern, and the trailing nested pattern(s) is/are >>> "var" pattern(s). So this is some kind of indeterminable type, and >>> "" does not seem too off. >> >> I'd suggest to use the tree printing machinery we have for deferred >> type arguments in the rich diagnostic formatter - that would give you >> better results, I believe. >> >> Not sure if I'd prefer to break down this: >> >> "deconstruction patterns can only be applied to records, String is >> not a record" >> >> into: >> >> "invalid deconstruction pattern" >> >> "String is not a record" >> >> Maurizio >> >>> >>>> >>>> * this might be a spec issue - there seems to be no support for >>>> varargs extraction - e.g. if a record is varargs: >>>> >>>> record Foo(int... is) { } >>>> >>>> shouldn't I be able to do this: >>>> >>>> if (o instanceof Foo(int i1, int i2, int i3)) { ... } >>> >>> I believe the spec does not currently allow this, although I assume >>> there will be discussions about features like this in the future. >> Ok >>> >>>> >>>> >>>> Some more detailed comments below: >>>> >>>> * Attr.java - verifyCastable seems very similar to >>>> Check.checkCastable, except for non-reifiable types - should we try >>>> to unify a bit? >>>> >>>> * Attr.java - not sure I get the logic by which target type is >>>> propagated or not in visitDeconstructionPattern. Seems to me that >>>> the only case where you need propagation is when you have a nested >>>> component of the kind "var x" - in which case the type is >>>> determined by the expected record component type. But this: >>>> >>>> + boolean nestedIsValidPattern = >>>> !nestedPatterns.head.hasTag(BINDINGPATTERN) || >>>> + ((JCBindingPattern) nestedPatterns.head).vartype == null; >>>> >>>> Seems to point to a slightly different direction? - e.g. target >>>> type is propagated even if the nested is a deconstruction pattern, >>>> but then I don't see any use of resultInfo inside this visitor? >>> >>> Probably a remainder of any patterns. I've cleaned this up. >>> >>>> >>>> * parser changes - looks good :-) >>>> >>>> * TransPattern - as usual, some comments illustrating basic >>>> desugared shapes would be nice >>> >>> Done. >>> >>> Thanks, >>> ??? Jan >>> >>>> >>>> Maurizio >>>> >>>> On 19/03/2020 17:25, Jan Lahoda wrote: >>>>> Hi, >>>>> >>>>> Turned out the patch had two bugs - one related to the owners of >>>>> the temporary variables created, which then broke type >>>>> annotations; and another that broken de-duplication. I am deeply >>>>> sorry for that. An updated webrev is here: >>>>> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.01/ >>>>> >>>>> A delta from previous round: >>>>> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.delta.00.01/ >>>>> >>>>> I am sorry for any inconvenience. >>>>> >>>>> Jan >>>>> >>>>> On 18. 03. 20 9:55, Jan Lahoda wrote: >>>>>> Hi, >>>>>> >>>>>> I would like to ask for a review for a patch that implements the >>>>>> deconstruction patterns, as described in JEP 375: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8235186 >>>>>> >>>>>> The current specification draft is here: >>>>>> http://cr.openjdk.java.net/~gbierman/jep375/jep375-20200316/specs/patterns-instanceof-jls.html >>>>>> >>>>>> >>>>>> For this phase, the proposal is for javac to desugar the >>>>>> deconstruction patterns using record accessors. >>>>>> >>>>>> The CSR for this change is being written here: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8240999 >>>>>> >>>>>> The proposed patch: >>>>>> http://cr.openjdk.java.net/~jlahoda/8240998/webrev.00 >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8240998 >>>>>> >>>>>> Any feedback is welcome! >>>>>> >>>>>> Thanks, >>>>>> ???? Jan From forax at univ-mlv.fr Sat Mar 28 10:24:12 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sat, 28 Mar 2020 11:24:12 +0100 (CET) Subject: JDK 14 record type representation in classfile format? In-Reply-To: References: <73385428.1999698.1584892463235.JavaMail.zimbra@u-pem.fr> <387181119.2004488.1584893160412.JavaMail.zimbra@u-pem.fr> <1713523742.1496394.1585336168925.JavaMail.zimbra@u-pem.fr> Message-ID: <298933389.1620147.1585391052737.JavaMail.zimbra@u-pem.fr> > De: "Luke Hutchison" > ?: "Remi Forax" > Cc: "Brian Goetz" , "amber-dev" > , "compiler-dev" > Envoy?: Samedi 28 Mars 2020 01:06:12 > Objet: Re: JDK 14 record type representation in classfile format? >> There is a good reason to duplicate the metadata declared at declaration site at >> callsite, it means that you can avoid to load the class containing the >> metadata. Here the compiler can find the classfile of the inner class without >> finding/loading the outer class. > But as I mentioned, this information is present as an attribute in Lookup (the > inner class), not just in MethodHandle (the outer class). Therefore you can > determine the outer class without loading the outer class. In fact it has to be > that way, because you can't load the outer class before you know what the outer > class is. > Furthermore if you don't need to load the inner class, there's no reason why you > would need to determine the outer class. So if the inner class is actually > being used, you already have the outer class information, because the inner > class has already been loaded. Nope, the trick is to neither load the outer class nor load the inner class. Let say you have a code that call a method m of a class A, with A seen as a classfile and not as a sourcefile by the compiler. class A { void m(MethodHandles.Lookup l) { ... } } ... A a = ... a.m(lookup); The signature of A::m is (Ljava/lang/invoke/MethodHandle$Lookup;)V but for javac, the variable "lookup" is typed as a MethodHandles.Lookup, so you need to have something that say that java/lang/invoke/MethodHandle$Lookup is MethodHandles.Lookup, this is exactly what you get by adding the attribute InnerClass inside the class A. As you see, you don't need to load MethodHandles or Lookup for get that piece of information. R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Sat Mar 28 23:37:24 2020 From: cushon at google.com (Liam Miller-Cushon) Date: Sat, 28 Mar 2020 16:37:24 -0700 Subject: RFR: JDK-8241798: Allow enums to have more constants Message-ID: Please consider this change to allow enums to have ~4100 constants (up from the current limit of ~2740), by moving the creation of the values array out of the clinit to a helper method. It's fair to ask whether this is worth doing. Increasing the limit by this amount doesn't really change the use-cases enums are suitable for: they still can't represent arbitrarily large collections of constants, and if you have an enum with >2740 constants you're probably going to want >4100 eventually. On the other hand, I don't see any obvious drawbacks to the change (in terms of complexity in the compiler, performance impact, or complexity of generated code). And other options for increasing the limit would require significantly more difficult and longer-term changes (e.g. tackling the method and constant pool size limits). Another question is whether this is the best code generation strategy. Currently javac saves the values array to a field and returns copies of it using clone(). The approach ecj uses skips the field, and just re-creates the array every time values() is called. For now I'm keeping the values field to minimize the performance impact of this change, but the ecj approach would avoid that field and the helper method. bug: https://bugs.openjdk.java.net/browse/JDK-8241798 webrev: http://cr.openjdk.java.net/~cushon/8241798/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Sun Mar 29 00:12:24 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 29 Mar 2020 01:12:24 +0100 (CET) Subject: RFR: JDK-8241798: Allow enums to have more constants In-Reply-To: References: Message-ID: <1231523245.1761154.1585440744725.JavaMail.zimbra@u-pem.fr> Hi Liam, Having values() initialized is the static block is a common issue once you have a code generator that spit enums. I had a similar issue and ends up not using enums but plain old classes in the generator because of that. There is another solution, you can use constantdynamic and pass the names of the constants (an array) as a bootstrap argument, you can go up to 65 635 (the limit in term of number of fields), in fact far less because the constant pool will be full before that point. public static MyEnum[] values() { ldc "values" [MyEnum [BSM=java/lang/runtime/ConstantEnumMetaFactory] ["constant1", "constant2", ...] invokevirtual clone() areturn } The major advantage of using constant dynamic is that if nobody calls the method values(), the array is never initialized. And once the VM will suport fields declared as "lazy static final", you can get ride of the static bock because the initialization of the constant fields will be done lazily too. R?mi > De: "Liam Miller-Cushon" > ?: "compiler-dev" > Envoy?: Dimanche 29 Mars 2020 00:37:24 > Objet: RFR: JDK-8241798: Allow enums to have more constants > Please consider this change to allow enums to have ~4100 constants (up from the > current limit of ~2740), by moving the creation of the values array out of the > clinit to a helper method. > It's fair to ask whether this is worth doing. Increasing the limit by this > amount doesn't really change the use-cases enums are suitable for: they still > can't represent arbitrarily large collections of constants, and if you have an > enum with >2740 constants you're probably going to want >4100 eventually. On > the other hand, I don't see any obvious drawbacks to the change (in terms of > complexity in the compiler, performance impact, or complexity of generated > code). And other options for increasing the limit would require significantly > more difficult and longer-term changes (e.g. tackling the method and constant > pool size limits). > Another question is whether this is the best code generation strategy. Currently > javac saves the values array to a field and returns copies of it using clone(). > The approach ecj uses skips the field, and just re-creates the array every time > values() is called. For now I'm keeping the values field to minimize the > performance impact of this change, but the ecj approach would avoid that field > and the helper method. > bug: [ https://bugs.openjdk.java.net/browse/JDK-8241798 | > https://bugs.openjdk.java.net/browse/JDK-8241798 ] > webrev: [ http://cr.openjdk.java.net/~cushon/8241798/webrev.00/ | > http://cr.openjdk.java.net/~cushon/8241798/webrev.00/ ] -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Mon Mar 30 11:58:41 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 30 Mar 2020 12:58:41 +0100 Subject: RFR: JDK-8241798: Allow enums to have more constants In-Reply-To: <1231523245.1761154.1585440744725.JavaMail.zimbra@u-pem.fr> References: <1231523245.1761154.1585440744725.JavaMail.zimbra@u-pem.fr> Message-ID: <8b401173-a3ce-ca4a-50e3-5bb436c773e4@oracle.com> I was thinking of something along the same lines - e.g. if constant number is a problem, then condy/ldc gives us more flexibility. Maurizio On 29/03/2020 00:12, Remi Forax wrote: > Hi Liam, > Having values() initialized is the static block is a common issue once > you have a code generator that spit enums. > I had a similar issue and ends up not using enums but plain old > classes in the generator because of that. > > There is another solution, > you can use constantdynamic and pass the names of the constants (an > array) as a bootstrap argument, > you can go up to 65 635 (the limit in term of number of fields), in > fact far less because the constant pool will be full before that point. > > public static MyEnum[] values()? { > ? ldc "values" [MyEnum [BSM=java/lang/runtime/ConstantEnumMetaFactory] > ["constant1", "constant2", ...] > ? invokevirtual clone() > ? areturn > } > > The major advantage of using constant dynamic is that if nobody calls > the method values(), the array is never initialized. > > And once the VM will suport fields declared as "lazy static final", > you can get ride of the static bock because the initialization of the > constant fields will be done lazily too. > > R?mi > > ------------------------------------------------------------------------ > > *De: *"Liam Miller-Cushon" > *?: *"compiler-dev" > *Envoy?: *Dimanche 29 Mars 2020 00:37:24 > *Objet: *RFR: JDK-8241798: Allow enums to have more constants > > Please consider this change to allow enums to have ~4100 constants > (up from the current limit of ~2740), by moving the creation of > the values array out of the clinit to a helper method. > > It's fair to ask whether this is worth doing. Increasing the limit > by this amount doesn't really change the use-cases enums are > suitable for: they still can't represent arbitrarily large > collections of constants, and if you have an enum with >2740 > constants you're probably going to want >4100 eventually. On the > other hand, I don't see?any obvious drawbacks to the change (in > terms of complexity in the compiler, performance impact, or > complexity of generated code). And other options for increasing > the limit would require significantly more difficult and > longer-term changes (e.g. tackling the method and constant pool > size limits). > > Another question is whether this is the best code generation > strategy. Currently javac saves the values array to a field and > returns copies of it using clone(). The approach ecj uses skips > the field, and just re-creates the array every time values()?is > called. For now I'm keeping the values field to minimize the > performance impact of this change,?but the ecj approach would > avoid?that field and the helper method. > > bug: https://bugs.openjdk.java.net/browse/JDK-8241798 > webrev: http://cr.openjdk.java.net/~cushon/8241798/webrev.00/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Mon Mar 30 13:32:46 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 30 Mar 2020 09:32:46 -0400 Subject: RFR: JDK-8241798: Allow enums to have more constants In-Reply-To: <1231523245.1761154.1585440744725.JavaMail.zimbra@u-pem.fr> References: <1231523245.1761154.1585440744725.JavaMail.zimbra@u-pem.fr> Message-ID: <85be8c28-1fa4-ef86-839e-8fe2fd1a8973@oracle.com> but isn't it the case that bootstrap methods can have up to 255 arguments due to the limits on method descriptors? Vicente On 3/28/20 8:12 PM, Remi Forax wrote: > Hi Liam, > Having values() initialized is the static block is a common issue once > you have a code generator that spit enums. > I had a similar issue and ends up not using enums but plain old > classes in the generator because of that. > > There is another solution, > you can use constantdynamic and pass the names of the constants (an > array) as a bootstrap argument, > you can go up to 65 635 (the limit in term of number of fields), in > fact far less because the constant pool will be full before that point. > > public static MyEnum[] values()? { > ? ldc "values" [MyEnum [BSM=java/lang/runtime/ConstantEnumMetaFactory] > ["constant1", "constant2", ...] > ? invokevirtual clone() > ? areturn > } > > The major advantage of using constant dynamic is that if nobody calls > the method values(), the array is never initialized. > > And once the VM will suport fields declared as "lazy static final", > you can get ride of the static bock because the initialization of the > constant fields will be done lazily too. > > R?mi > > ------------------------------------------------------------------------ > > *De: *"Liam Miller-Cushon" > *?: *"compiler-dev" > *Envoy?: *Dimanche 29 Mars 2020 00:37:24 > *Objet: *RFR: JDK-8241798: Allow enums to have more constants > > Please consider this change to allow enums to have ~4100 constants > (up from the current limit of ~2740), by moving the creation of > the values array out of the clinit to a helper method. > > It's fair to ask whether this is worth doing. Increasing the limit > by this amount doesn't really change the use-cases enums are > suitable for: they still can't represent arbitrarily large > collections of constants, and if you have an enum with >2740 > constants you're probably going to want >4100 eventually. On the > other hand, I don't see?any obvious drawbacks to the change (in > terms of complexity in the compiler, performance impact, or > complexity of generated code). And other options for increasing > the limit would require significantly more difficult and > longer-term changes (e.g. tackling the method and constant pool > size limits). > > Another question is whether this is the best code generation > strategy. Currently javac saves the values array to a field and > returns copies of it using clone(). The approach ecj uses skips > the field, and just re-creates the array every time values()?is > called. For now I'm keeping the values field to minimize the > performance impact of this change,?but the ecj approach would > avoid?that field and the helper method. > > bug: https://bugs.openjdk.java.net/browse/JDK-8241798 > webrev: http://cr.openjdk.java.net/~cushon/8241798/webrev.00/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Mon Mar 30 13:45:06 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 30 Mar 2020 09:45:06 -0400 Subject: RFR: JDK-8241798: Allow enums to have more constants In-Reply-To: <1231523245.1761154.1585440744725.JavaMail.zimbra@u-pem.fr> References: <1231523245.1761154.1585440744725.JavaMail.zimbra@u-pem.fr> Message-ID: Remi is of course correct that there are many creative solutions using indy/condy. I don?t want to stifle that creativity, but I also don?t want that creativity to stop Liam from making progress. Liam observed a problem, and came up with a narrowly targeted, low risk solution that doesn?t reopen questions about translation strategy and that is obviously better than what we have. Yes, we could discuss whether there?s a better big-picture strategy for dealing with the values() method, or for pushing the limit up higher. But let?s also be aware that it is too easy to get mired in blue-sky ideas and then Liam?s problem is not solved. So, +1 from me on this patch. It is simple and responsible. > On Mar 28, 2020, at 8:12 PM, Remi Forax wrote: > > Hi Liam, > Having values() initialized is the static block is a common issue once you have a code generator that spit enums. > I had a similar issue and ends up not using enums but plain old classes in the generator because of that. > > There is another solution, > you can use constantdynamic and pass the names of the constants (an array) as a bootstrap argument, > you can go up to 65 635 (the limit in term of number of fields), in fact far less because the constant pool will be full before that point. > > public static MyEnum[] values() { > ldc "values" [MyEnum [BSM=java/lang/runtime/ConstantEnumMetaFactory] ["constant1", "constant2", ...] > invokevirtual clone() > areturn > } > > The major advantage of using constant dynamic is that if nobody calls the method values(), the array is never initialized. > > And once the VM will suport fields declared as "lazy static final", you can get ride of the static bock because the initialization of the constant fields will be done lazily too. > > R?mi > > De: "Liam Miller-Cushon" > ?: "compiler-dev" > Envoy?: Dimanche 29 Mars 2020 00:37:24 > Objet: RFR: JDK-8241798: Allow enums to have more constants > Please consider this change to allow enums to have ~4100 constants (up from the current limit of ~2740), by moving the creation of the values array out of the clinit to a helper method. > > It's fair to ask whether this is worth doing. Increasing the limit by this amount doesn't really change the use-cases enums are suitable for: they still can't represent arbitrarily large collections of constants, and if you have an enum with >2740 constants you're probably going to want >4100 eventually. On the other hand, I don't see any obvious drawbacks to the change (in terms of complexity in the compiler, performance impact, or complexity of generated code). And other options for increasing the limit would require significantly more difficult and longer-term changes (e.g. tackling the method and constant pool size limits). > > Another question is whether this is the best code generation strategy. Currently javac saves the values array to a field and returns copies of it using clone(). The approach ecj uses skips the field, and just re-creates the array every time values() is called. For now I'm keeping the values field to minimize the performance impact of this change, but the ecj approach would avoid that field and the helper method. > > bug: https://bugs.openjdk.java.net/browse/JDK-8241798 > webrev: http://cr.openjdk.java.net/~cushon/8241798/webrev.00/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Mon Mar 30 14:40:20 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Mon, 30 Mar 2020 16:40:20 +0200 (CEST) Subject: RFR: JDK-8241798: Allow enums to have more constants In-Reply-To: <85be8c28-1fa4-ef86-839e-8fe2fd1a8973@oracle.com> References: <1231523245.1761154.1585440744725.JavaMail.zimbra@u-pem.fr> <85be8c28-1fa4-ef86-839e-8fe2fd1a8973@oracle.com> Message-ID: <240940716.664721.1585579220982.JavaMail.zimbra@u-pem.fr> > De: "Vicente Romero" > ?: "Remi Forax" , "Liam Miller-Cushon" > Cc: "compiler-dev" > Envoy?: Lundi 30 Mars 2020 15:32:46 > Objet: Re: RFR: JDK-8241798: Allow enums to have more constants > but isn't it the case that bootstrap methods can have up to 255 arguments due to > the limits on method descriptors? Method descriptors are strings, so the limit is 2G bytes. Originally, there was a limit on the number of arguments because the calls to the BSM had to have less than 252 arguments. The call of the bootstrap method was specified as equivalent to a call to MethodHandle.invoke(), but that restriction was lifted (see [1]) before introducing constant dynamic by specifying that the call to a BSM is equivalent to a call to invokeWithArguments (that takes an array as parameter). regards, R?mi [1] https://bugs.openjdk.java.net/browse/JDK-8185993 > Vicente > On 3/28/20 8:12 PM, Remi Forax wrote: >> Hi Liam, >> Having values() initialized is the static block is a common issue once you have >> a code generator that spit enums. >> I had a similar issue and ends up not using enums but plain old classes in the >> generator because of that. >> There is another solution, >> you can use constantdynamic and pass the names of the constants (an array) as a >> bootstrap argument, >> you can go up to 65 635 (the limit in term of number of fields), in fact far >> less because the constant pool will be full before that point. >> public static MyEnum[] values() { >> ldc "values" [MyEnum [BSM=java/lang/runtime/ConstantEnumMetaFactory] >> ["constant1", "constant2", ...] >> invokevirtual clone() >> areturn >> } >> The major advantage of using constant dynamic is that if nobody calls the method >> values(), the array is never initialized. >> And once the VM will suport fields declared as "lazy static final", you can get >> ride of the static bock because the initialization of the constant fields will >> be done lazily too. >> R?mi >>> De: "Liam Miller-Cushon" [ mailto:cushon at google.com | ] >>> ?: "compiler-dev" [ mailto:compiler-dev at openjdk.java.net | >>> ] >>> Envoy?: Dimanche 29 Mars 2020 00:37:24 >>> Objet: RFR: JDK-8241798: Allow enums to have more constants >>> Please consider this change to allow enums to have ~4100 constants (up from the >>> current limit of ~2740), by moving the creation of the values array out of the >>> clinit to a helper method. >>> It's fair to ask whether this is worth doing. Increasing the limit by this >>> amount doesn't really change the use-cases enums are suitable for: they still >>> can't represent arbitrarily large collections of constants, and if you have an >>> enum with >2740 constants you're probably going to want >4100 eventually. On >>> the other hand, I don't see any obvious drawbacks to the change (in terms of >>> complexity in the compiler, performance impact, or complexity of generated >>> code). And other options for increasing the limit would require significantly >>> more difficult and longer-term changes (e.g. tackling the method and constant >>> pool size limits). >>> Another question is whether this is the best code generation strategy. Currently >>> javac saves the values array to a field and returns copies of it using clone(). >>> The approach ecj uses skips the field, and just re-creates the array every time >>> values() is called. For now I'm keeping the values field to minimize the >>> performance impact of this change, but the ecj approach would avoid that field >>> and the helper method. >>> bug: [ https://bugs.openjdk.java.net/browse/JDK-8241798 | >>> https://bugs.openjdk.java.net/browse/JDK-8241798 ] >>> webrev: [ http://cr.openjdk.java.net/~cushon/8241798/webrev.00/ | >>> http://cr.openjdk.java.net/~cushon/8241798/webrev.00/ ] -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Mon Mar 30 17:15:33 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Mon, 30 Mar 2020 19:15:33 +0200 (CEST) Subject: RFR: JDK-8241798: Allow enums to have more constants In-Reply-To: References: <1231523245.1761154.1585440744725.JavaMail.zimbra@u-pem.fr> Message-ID: <446764264.769983.1585588533447.JavaMail.zimbra@u-pem.fr> > De: "Brian Goetz" > ?: "Remi Forax" > Cc: "Liam Miller-Cushon" , "compiler-dev" > > Envoy?: Lundi 30 Mars 2020 15:45:06 > Objet: Re: RFR: JDK-8241798: Allow enums to have more constants > Remi is of course correct that there are many creative solutions using > indy/condy. I don?t want to stifle that creativity, but I also don?t want that > creativity to stop Liam from making progress. Thinking more about that, condy is interesting because it avoid the initialization of the array until the first time you use it, something we should do in the long term but as part of an effort in the future to try to get ride of most of the existing static blocks, the problem is that we are not yet there. > Liam observed a problem, and came up with a narrowly targeted, low risk solution > that doesn?t reopen questions about translation strategy and that is obviously > better than what we have. Yes, we could discuss whether there?s a better > big-picture strategy for dealing with the values() method, or for pushing the > limit up higher. But let?s also be aware that it is too easy to get mired in > blue-sky ideas and then Liam?s problem is not solved. > So, +1 from me on this patch. It is simple and responsible. About the patch, it's ok for me if the method $values() is not declared 'final' (because it is already static). R?mi --- For the record, here is how to use constant dynamic: import static java.lang.constant.ConstantDescs.CD_Class; import static java.lang.constant.ConstantDescs.CD_MethodHandles_Lookup; import static java.lang.constant.ConstantDescs.CD_Object; import static java.lang.constant.ConstantDescs.CD_String; import static java.util.stream.IntStream.range; import static org.objectweb.asm.Opcodes.ACC_FINAL; import static org.objectweb.asm.Opcodes.ACC_PRIVATE; import static org.objectweb.asm.Opcodes.ACC_PUBLIC; import static org.objectweb.asm.Opcodes.ACC_STATIC; import static org.objectweb.asm.Opcodes.ACC_SUPER; import static org.objectweb.asm.Opcodes.ALOAD; import static org.objectweb.asm.Opcodes.ARETURN; import static org.objectweb.asm.Opcodes.BIPUSH; import static org.objectweb.asm.Opcodes.CHECKCAST; import static org.objectweb.asm.Opcodes.DUP; import static org.objectweb.asm.Opcodes.H_INVOKESTATIC; import static org.objectweb.asm.Opcodes.ICONST_0; import static org.objectweb.asm.Opcodes.ILOAD; import static org.objectweb.asm.Opcodes.INVOKESPECIAL; import static org.objectweb.asm.Opcodes.INVOKEVIRTUAL; import static org.objectweb.asm.Opcodes.NEW; import static org.objectweb.asm.Opcodes.PUTSTATIC; import static org.objectweb.asm.Opcodes.RETURN; import static org.objectweb.asm.Opcodes.SIPUSH; import static org.objectweb.asm.Opcodes.V11; import java.lang.constant.MethodTypeDesc; import java.lang.reflect.Array; import java.nio.file.Files; import java.nio.file.Path; import org.objectweb.asm.ClassWriter; import org.objectweb.asm.ConstantDynamic; import org.objectweb.asm.Handle; import org.objectweb.asm.MethodVisitor; public class GenerateMiniEnum { private static final Handle BSM = new Handle(H_INVOKESTATIC, RT.class.getName().replace('.', '/'), "getEnumConstants", MethodTypeDesc .of(CD_Object, CD_MethodHandles_Lookup, CD_String, CD_Class, CD_Object.arrayType()).descriptorString(), false); private static void generateInt(MethodVisitor mv, int value) { if (value >= -1 && value <= 5) { mv.visitInsn(ICONST_0 + value); return; } if (value >= Byte.MIN_VALUE && value <= Byte.MAX_VALUE) { mv.visitIntInsn(BIPUSH, value); return; } if (value >= Short.MIN_VALUE && value <= Short.MAX_VALUE) { mv.visitIntInsn(SIPUSH, value); return; } mv.visitLdcInsn(value); } private static byte[] generate(int enumConstantCount) { var enumNames = range(0, enumConstantCount).mapToObj(i -> "V" + i).toArray(); var writer = new ClassWriter(0); writer.visit(V11, ACC_PUBLIC | ACC_SUPER, "MyEnum", null, "java/lang/Enum", null); for(var i = 0; i ", "(Ljava/lang/String;I)V", null, null); init.visitCode(); init.visitVarInsn(ALOAD, 0); init.visitVarInsn(ALOAD, 1); init.visitVarInsn(ILOAD, 2); init.visitMethodInsn(INVOKESPECIAL, "java/lang/Enum", "", "(Ljava/lang/String;I)V", false); init.visitInsn(RETURN); init.visitMaxs(3, 3); init.visitEnd(); var values = writer.visitMethod(ACC_PUBLIC | ACC_STATIC, "values", "()[LMyEnum;", null, null); values.visitCode(); var condy = new ConstantDynamic("values", "[LMyEnum;", BSM, enumNames ); values.visitLdcInsn(condy); values.visitMethodInsn(INVOKEVIRTUAL, "java/lang/Object", "clone", "()Ljava/lang/Object;", false); values.visitTypeInsn(CHECKCAST, "[LMyEnum;"); values.visitInsn(ARETURN); values.visitMaxs(1, 0); values.visitEnd(); var clinit = writer.visitMethod(ACC_STATIC, "", "()V", null, null); clinit.visitCode(); for(var i = 0; i < enumConstantCount; i++) { clinit.visitTypeInsn(NEW, "MyEnum"); clinit.visitInsn(DUP); clinit.visitLdcInsn("V" + i); generateInt(clinit, i); clinit.visitMethodInsn(INVOKESPECIAL, "MyEnum", "", "(Ljava/lang/String;I)V", false); clinit.visitFieldInsn(PUTSTATIC, "MyEnum", "V" + i, "LMyEnum;"); } clinit.visitInsn(RETURN); clinit.visitMaxs(4, 0); clinit.visitEnd(); return writer.toByteArray(); } private static Class array(Class type) { return Array.newInstance(type, 0).getClass(); } public static void main(String[] args) throws Throwable { var path = Path.of("MyEnum.class"); var outputFolder = Path.of("minified"); Files.createDirectories(outputFolder); var byteArray = generate(4100); Files.write(outputFolder.resolve(path), byteArray); } } >> On Mar 28, 2020, at 8:12 PM, Remi Forax < [ mailto:forax at univ-mlv.fr | >> forax at univ-mlv.fr ] > wrote: >> Hi Liam, >> Having values() initialized is the static block is a common issue once you have >> a code generator that spit enums. >> I had a similar issue and ends up not using enums but plain old classes in the >> generator because of that. >> There is another solution, >> you can use constantdynamic and pass the names of the constants (an array) as a >> bootstrap argument, >> you can go up to 65 635 (the limit in term of number of fields), in fact far >> less because the constant pool will be full before that point. >> public static MyEnum[] values() { >> ldc "values" [MyEnum [BSM=java/lang/runtime/ConstantEnumMetaFactory] >> ["constant1", "constant2", ...] >> invokevirtual clone() >> areturn >> } >> The major advantage of using constant dynamic is that if nobody calls the method >> values(), the array is never initialized. >> And once the VM will suport fields declared as "lazy static final", you can get >> ride of the static bock because the initialization of the constant fields will >> be done lazily too. >> R?mi >>> De: "Liam Miller-Cushon" < [ mailto:cushon at google.com | cushon at google.com ] > >>> ?: "compiler-dev" < [ mailto:compiler-dev at openjdk.java.net | >>> compiler-dev at openjdk.java.net ] > >>> Envoy?: Dimanche 29 Mars 2020 00:37:24 >>> Objet: RFR: JDK-8241798: Allow enums to have more constants >>> Please consider this change to allow enums to have ~4100 constants (up from the >>> current limit of ~2740), by moving the creation of the values array out of the >>> clinit to a helper method. >>> It's fair to ask whether this is worth doing. Increasing the limit by this >>> amount doesn't really change the use-cases enums are suitable for: they still >>> can't represent arbitrarily large collections of constants, and if you have an >>> enum with >2740 constants you're probably going to want >4100 eventually. On >>> the other hand, I don't see any obvious drawbacks to the change (in terms of >>> complexity in the compiler, performance impact, or complexity of generated >>> code). And other options for increasing the limit would require significantly >>> more difficult and longer-term changes (e.g. tackling the method and constant >>> pool size limits). >>> Another question is whether this is the best code generation strategy. Currently >>> javac saves the values array to a field and returns copies of it using clone(). >>> The approach ecj uses skips the field, and just re-creates the array every time >>> values() is called. For now I'm keeping the values field to minimize the >>> performance impact of this change, but the ecj approach would avoid that field >>> and the helper method. >>> bug: [ https://bugs.openjdk.java.net/browse/JDK-8241798 | >>> https://bugs.openjdk.java.net/browse/JDK-8241798 ] >>> webrev: [ http://cr.openjdk.java.net/~cushon/8241798/webrev.00/ | >>> http://cr.openjdk.java.net/~cushon/8241798/webrev.00/ ] -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Mon Mar 30 18:10:32 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 30 Mar 2020 14:10:32 -0400 Subject: RFR: JDK-8241798: Allow enums to have more constants In-Reply-To: References: Message-ID: <240132e3-a88e-ef49-54e2-c9ac5309bb19@oracle.com> On the more general (and longer term) topic of "how far can we push this", here are some constraints: ?- The spec requires that migrating between a class with static fields and an enum to be binary compatible. This essentially means that every enum constant has to be a field. ?- static final fields have to be initialized from , so we can't use this "outlining" trick to break up this part of For a trivial enum ??? enum Foo { A } we get the following classfile: Constant pool: ?? #1 = Fieldref?????????? #4.#29???????? // Foo.$VALUES:[LFoo; ?? #2 = Methodref????????? #30.#31??????? // "[LFoo;".clone:()Ljava/lang/Object; ?? #3 = Class????????????? #14??????????? // "[LFoo;" ?? #4 = Class????????????? #32??????????? // Foo ?? #5 = Methodref????????? #10.#33??????? // java/lang/Enum.valueOf:(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/Enum; ?? #6 = Methodref????????? #10.#34??????? // java/lang/Enum."":(Ljava/lang/String;I)V ?? #7 = String???????????? #11??????????? // A ?? #8 = Methodref????????? #4.#34???????? // Foo."":(Ljava/lang/String;I)V ?? #9 = Fieldref?????????? #4.#35???????? // Foo.A:LFoo; ? #10 = Class????????????? #36??????????? // java/lang/Enum ? #11 = Utf8?????????????? A ? #12 = Utf8?????????????? LFoo; ? #13 = Utf8?????????????? $VALUES ? #14 = Utf8?????????????? [LFoo; ? #15 = Utf8?????????????? values ? #16 = Utf8?????????????? ()[LFoo; ? #17 = Utf8?????????????? Code ? #18 = Utf8?????????????? LineNumberTable ? #19 = Utf8?????????????? valueOf ? #20 = Utf8?????????????? (Ljava/lang/String;)LFoo; ? #21 = Utf8?????????????? ? #22 = Utf8?????????????? (Ljava/lang/String;I)V ? #23 = Utf8?????????????? Signature ? #24 = Utf8?????????????? ()V ? #25 = Utf8?????????????? ? #26 = Utf8?????????????? Ljava/lang/Enum; ? #27 = Utf8?????????????? SourceFile ? #28 = Utf8?????????????? Foo.java ? #29 = NameAndType??????? #13:#14??????? // $VALUES:[LFoo; ? #30 = Class????????????? #14??????????? // "[LFoo;" ? #31 = NameAndType??????? #37:#38??????? // clone:()Ljava/lang/Object; ? #32 = Utf8?????????????? Foo ? #33 = NameAndType??????? #19:#39??????? // valueOf:(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/Enum; ? #34 = NameAndType??????? #21:#22??????? // "":(Ljava/lang/String;I)V ? #35 = NameAndType??????? #11:#12??????? // A:LFoo; ? #36 = Utf8?????????????? java/lang/Enum ? #37 = Utf8?????????????? clone ? #38 = Utf8?????????????? ()Ljava/lang/Object; ? #39 = Utf8 (Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/Enum; public static final Foo A; ??? descriptor: LFoo; ??? flags: ACC_PUBLIC, ACC_STATIC, ACC_FINAL, ACC_ENUM At the very least, each constant requires a unique UTF8 for its name (#11 here for Foo.A.)? And that field has to be initialized, regardless of what we do with values(): ???????? 0: new?????????? #4????????????????? // class Foo ???????? 3: dup ???????? 4: ldc?????????? #7????????????????? // String A ???????? 6: iconst_0 ???????? 7: invokespecial #8????????????????? // Method "":(Ljava/lang/String;I)V ??????? 10: putstatic???? #9????????????????? // Field A:LFoo; To support the putstatic, we need a constant-specific NameAndType (#35) and Fieldref (#9).? So that's a minimum of 3 CP slots per enum constants, putting a ceiling of about 21K if we want to initialize the field via bytecode.? (We could do it reflectively which would reduce the number of CP slots but would cost way more in startup.) The other limit we are bumping into is the size limit of .? Liam's patch moves the values() array creation out of init, leaving only the constant initialization; with ~13 bytes per field, the 64K method size limit gives me about 5K enum constants. (Liam, what's the constraint that brings you down to 4100?)? We can't "outline" the initialization of the field because of the constraint that final static fields be set in . However, we can probably squeeze a little more out by another refactoring, which would be to initialize the values method _first_ and then initialize the fields from that: ?? aload_1? // push array on the stack ?? sipush #n? // push index on the stack ?? aaload // fetch element ?? putstatic Foo.A This is 8 bytes, instead of 13, which means we can get more like 8K enum constants with these constraints. On 3/28/2020 7:37 PM, Liam Miller-Cushon wrote: > Please consider this change to allow enums to have ~4100 constants (up > from the current limit of ~2740), by moving the creation of the values > array out of the clinit to a helper method. > > It's fair to ask whether this is worth doing. Increasing the limit by > this amount doesn't really change the use-cases enums are suitable > for: they still can't represent arbitrarily large collections of > constants, and if you have an enum with >2740 constants you're > probably going to want >4100 eventually. On the other hand, I don't > see?any obvious drawbacks to the change (in terms of complexity in the > compiler, performance impact, or complexity of generated code). And > other options for increasing the limit would require significantly > more difficult and longer-term changes (e.g. tackling the method and > constant pool size limits). > > Another question is whether this is the best code generation strategy. > Currently javac saves the values array to a field and returns copies > of it using clone(). The approach ecj uses skips the field, and just > re-creates the array every time values()?is called. For now I'm > keeping the values field to minimize the performance impact of this > change,?but the ecj approach would avoid?that field and the helper method. > > bug: https://bugs.openjdk.java.net/browse/JDK-8241798 > webrev: http://cr.openjdk.java.net/~cushon/8241798/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Mon Mar 30 19:34:34 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 30 Mar 2020 21:34:34 +0200 (CEST) Subject: RFR: JDK-8241798: Allow enums to have more constants In-Reply-To: <240132e3-a88e-ef49-54e2-c9ac5309bb19@oracle.com> References: <240132e3-a88e-ef49-54e2-c9ac5309bb19@oracle.com> Message-ID: <1188159132.814356.1585596874548.JavaMail.zimbra@u-pem.fr> > De: "Brian Goetz" > ?: "Liam Miller-Cushon" , "compiler-dev" > > Envoy?: Lundi 30 Mars 2020 20:10:32 > Objet: Re: RFR: JDK-8241798: Allow enums to have more constants > On the more general (and longer term) topic of "how far can we push this", here > are some constraints: > - The spec requires that migrating between a class with static fields and an > enum to be binary compatible. This essentially means that every enum constant > has to be a field. > - static final fields have to be initialized from , so we can't use this > "outlining" trick to break up this part of not if JDK-8209964 is implemented so this is only true at shorter term > For a trivial enum > enum Foo { A } > we get the following classfile: > Constant pool: > #1 = Fieldref #4.#29 // Foo.$VALUES:[LFoo; > #2 = Methodref #30.#31 // "[LFoo;".clone:()Ljava/lang/Object; > #3 = Class #14 // "[LFoo;" > #4 = Class #32 // Foo > #5 = Methodref #10.#33 // > java/lang/Enum.valueOf:(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/Enum; > #6 = Methodref #10.#34 // java/lang/Enum."":(Ljava/lang/String;I)V > #7 = String #11 // A > #8 = Methodref #4.#34 // Foo."":(Ljava/lang/String;I)V > #9 = Fieldref #4.#35 // Foo.A:LFoo; > #10 = Class #36 // java/lang/Enum > #11 = Utf8 A > #12 = Utf8 LFoo; > #13 = Utf8 $VALUES > #14 = Utf8 [LFoo; > #15 = Utf8 values > #16 = Utf8 ()[LFoo; > #17 = Utf8 Code > #18 = Utf8 LineNumberTable > #19 = Utf8 valueOf > #20 = Utf8 (Ljava/lang/String;)LFoo; > #21 = Utf8 > #22 = Utf8 (Ljava/lang/String;I)V > #23 = Utf8 Signature > #24 = Utf8 ()V > #25 = Utf8 > #26 = Utf8 Ljava/lang/Enum; > #27 = Utf8 SourceFile > #28 = Utf8 Foo.java > #29 = NameAndType #13:#14 // $VALUES:[LFoo; > #30 = Class #14 // "[LFoo;" > #31 = NameAndType #37:#38 // clone:()Ljava/lang/Object; > #32 = Utf8 Foo > #33 = NameAndType #19:#39 // > valueOf:(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/Enum; > #34 = NameAndType #21:#22 // "":(Ljava/lang/String;I)V > #35 = NameAndType #11:#12 // A:LFoo; > #36 = Utf8 java/lang/Enum > #37 = Utf8 clone > #38 = Utf8 ()Ljava/lang/Object; > #39 = Utf8 (Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/Enum; > public static final Foo A; > descriptor: LFoo; > flags: ACC_PUBLIC, ACC_STATIC, ACC_FINAL, ACC_ENUM > At the very least, each constant requires a unique UTF8 for its name (#11 here > for Foo.A.) And that field has to be initialized, regardless of what we do with > values(): > 0: new #4 // class Foo > 3: dup > 4: ldc #7 // String A > 6: iconst_0 > 7: invokespecial #8 // Method "":(Ljava/lang/String;I)V > 10: putstatic #9 // Field A:LFoo; > To support the putstatic, we need a constant-specific NameAndType (#35) and > Fieldref (#9). So that's a minimum of 3 CP slots per enum constants, putting a > ceiling of about 21K if we want to initialize the field via bytecode. (We could > do it reflectively which would reduce the number of CP slots but would cost way > more in startup.) > The other limit we are bumping into is the size limit of . Liam's patch > moves the values() array creation out of init, leaving only the constant > initialization; with ~13 bytes per field, the 64K method size limit gives me > about 5K enum constants. (Liam, what's the constraint that brings you down to > 4100?) We can't "outline" the initialization of the field because of the > constraint that final static fields be set in . > However, we can probably squeeze a little more out by another refactoring, which > would be to initialize the values method _first_ and then initialize the fields > from that: > aload_1 // push array on the stack > sipush #n // push index on the stack > aaload // fetch element > putstatic Foo.A > This is 8 bytes, instead of 13, which means we can get more like 8K enum > constants with these constraints. yes, Currently doing an abstract execution of the clinit of an enum is quite simple. I fear that the transformation you are proposing make harder for AOT to find the value of the constant without executing the clinit at compile time. So it's a more disruptive change. R?mi > On 3/28/2020 7:37 PM, Liam Miller-Cushon wrote: >> Please consider this change to allow enums to have ~4100 constants (up from the >> current limit of ~2740), by moving the creation of the values array out of the >> clinit to a helper method. >> It's fair to ask whether this is worth doing. Increasing the limit by this >> amount doesn't really change the use-cases enums are suitable for: they still >> can't represent arbitrarily large collections of constants, and if you have an >> enum with >2740 constants you're probably going to want >4100 eventually. On >> the other hand, I don't see any obvious drawbacks to the change (in terms of >> complexity in the compiler, performance impact, or complexity of generated >> code). And other options for increasing the limit would require significantly >> more difficult and longer-term changes (e.g. tackling the method and constant >> pool size limits). >> Another question is whether this is the best code generation strategy. Currently >> javac saves the values array to a field and returns copies of it using clone(). >> The approach ecj uses skips the field, and just re-creates the array every time >> values() is called. For now I'm keeping the values field to minimize the >> performance impact of this change, but the ecj approach would avoid that field >> and the helper method. >> bug: [ https://bugs.openjdk.java.net/browse/JDK-8241798 | >> https://bugs.openjdk.java.net/browse/JDK-8241798 ] >> webrev: [ http://cr.openjdk.java.net/~cushon/8241798/webrev.00/ | >> http://cr.openjdk.java.net/~cushon/8241798/webrev.00/ ] -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.r.rose at oracle.com Mon Mar 30 20:29:33 2020 From: john.r.rose at oracle.com (John Rose) Date: Mon, 30 Mar 2020 13:29:33 -0700 Subject: RFR: JDK-8241798: Allow enums to have more constants In-Reply-To: <85be8c28-1fa4-ef86-839e-8fe2fd1a8973@oracle.com> References: <1231523245.1761154.1585440744725.JavaMail.zimbra@u-pem.fr> <85be8c28-1fa4-ef86-839e-8fe2fd1a8973@oracle.com> Message-ID: On Mar 30, 2020, at 6:32 AM, Vicente Romero wrote: > > but isn't it the case that bootstrap methods can have up to 255 arguments due to the limits on method descriptors? No. Varargs works. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Tue Mar 31 06:40:51 2020 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 30 Mar 2020 23:40:51 -0700 Subject: RFR: JDK-8241798: Allow enums to have more constants In-Reply-To: <240132e3-a88e-ef49-54e2-c9ac5309bb19@oracle.com> References: <240132e3-a88e-ef49-54e2-c9ac5309bb19@oracle.com> Message-ID: To preface this, I'm also interested in the options involving condy, but even if that ends up being the preferred strategy for a future language version I think there's value in increasing the limit for existing language versions (assuming we can find a way to do that with acceptable complexity and performance). It'll take time before some of the code generators affected by the current limit can target Java 16+ features. On Mon, Mar 30, 2020 at 11:10 AM Brian Goetz wrote: > Liam, what's the constraint that brings you down to 4100? > At some point we start needing ldc_w and sipush for the names and ordinals, which makes it 16 bytes per constant. > However, we can probably squeeze a little more out by another refactoring, > which would be to initialize the values method _first_ and then initialize > the fields from that > Thanks! It looks like that gets us down to 8 bytes per constant in the clinit, or ~8200 constants total. Initializing the values() array now takes 18 bytes per constant, but that part is easy to split across multiple helper methods. I have a prototype that mostly works (*) and handles 8207 constants. I'll clean that up tomorrow, and do some benchmarking with both approaches to better understand any performance trade-offs / cliffs, and will report back. (*) the caveat is that enum constants can refer to other constants in their initializers, e.g.: enum T { ONE, TWO(ONE); final T t; T(T t) { this.t = t; } T() { this(null); } } It's possible to fix some cases by fixing up references to use the values array (e.g. `new T("TWO", 1, values[0]);`), but that doesn't work in general. I think that limits this strategy to enums that don't declare constructors with non-mandated parameters. I'd still be happy to have support for that many constants in 'simple' enums, but needing different code generation strategies for different kinds of enum does change the return-on-complexity a bit. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Tue Mar 31 15:42:55 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 31 Mar 2020 16:42:55 +0100 Subject: RFR: JDK-8241798: Allow enums to have more constants In-Reply-To: References: <240132e3-a88e-ef49-54e2-c9ac5309bb19@oracle.com> Message-ID: <1ba99b6e-3635-5962-7ab6-c1fb883df0bc@oracle.com> On 31/03/2020 07:40, Liam Miller-Cushon wrote: > I think that limits this strategy to enums that don't declare > constructors with non-mandated?parameters. I'd still be happy to have > support for that many constants in 'simple' enums, but needing > different code generation strategies for different kinds of enum does > change the return-on-complexity a bit. I agree - your first patch has a simplicity to it that is appealing. If we go down more complex paths which require different generation strategies, I'm not sure whether the trade off is justified - as that has consequence on testing and all. Maurizio From brian.goetz at oracle.com Tue Mar 31 21:27:57 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 31 Mar 2020 17:27:57 -0400 Subject: RFR: JDK-8241798: Allow enums to have more constants In-Reply-To: <1ba99b6e-3635-5962-7ab6-c1fb883df0bc@oracle.com> References: <240132e3-a88e-ef49-54e2-c9ac5309bb19@oracle.com> <1ba99b6e-3635-5962-7ab6-c1fb883df0bc@oracle.com> Message-ID: Yep, I'm with Maurizio on this one too.? Keep the "bytecode golf" idea for later :) On 3/31/2020 11:42 AM, Maurizio Cimadamore wrote: > > On 31/03/2020 07:40, Liam Miller-Cushon wrote: >> I think that limits this strategy to enums that don't declare >> constructors with non-mandated?parameters. I'd still be happy to have >> support for that many constants in 'simple' enums, but needing >> different code generation strategies for different kinds of enum does >> change the return-on-complexity a bit. > > I agree - your first patch has a simplicity to it that is appealing. > > If we go down more complex paths which require different generation > strategies, I'm not sure whether the trade off is justified - as that > has consequence on testing and all. > > Maurizio > -------------- next part -------------- An HTML attachment was scrubbed... URL: