From james.laskey at oracle.com Wed Jan 2 18:02:59 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 2 Jan 2019 14:02:59 -0400 Subject: RFR - JDK-8215682 - Remove compiler support for Raw String Literals from JDK 12 Message-ID: <27F1C797-B045-443F-8E41-31F753420B53@oracle.com> Looking for reviewers to make sure this CSR passes muster. CSR: https://bugs.openjdk.java.net/browse/JDK-8215682 Thank you. Cheers, ? Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Wed Jan 2 19:46:49 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 2 Jan 2019 20:46:49 +0100 Subject: RFR - JDK-8215682 - Remove compiler support for Raw String Literals from JDK 12 In-Reply-To: <27F1C797-B045-443F-8E41-31F753420B53@oracle.com> References: <27F1C797-B045-443F-8E41-31F753420B53@oracle.com> Message-ID: <5C2D1529.4090802@oracle.com> Done. I've changed the Compatibility Kind to "source" (as I guess it better reflects the change, and the original CSR appears to have it as well) and added "Language Construct" to Interface Kind. Jan On 2.1.2019 19:02, Jim Laskey wrote: > Looking for reviewers to make sure this CSR passes muster. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8215682 > > Thank you. > > Cheers, > > ? Jim > > From merkel05 at gmail.com Fri Jan 4 12:08:20 2019 From: merkel05 at gmail.com (Sergei Ustimenko) Date: Fri, 4 Jan 2019 13:08:20 +0100 Subject: Question on JDK-8215470: Bad EnclosingMethod attribute Message-ID: Hi compiler-dev, Recently I was working on the following bug: https://bugs.openjdk.java.net/browse/JDK-8213465 It is mainly about anonymous classes that miss type variable information if declared inside lambda expression. It leads to a bug in the javac compiler https://bugs.openjdk.java.net/browse/JDK-8215470 which emits `EnclosingMethod` attribute that points to the synthetic method for anonymous classes if declared inside lambda. I was experimenting with it a bit and want to know compiler-dev's opinion on what would be the best way to fix it. So my goal in the end is to have `EnclosingMethod` for anonymous classes, as well as for class declarations inside lambda expressions, to have `EnclosingMethod` attribute pointing to the nearest lexically enclosing method (not the synthetic method!) I see a couple of options to probably achieve the goal: 1) Skip the lambdas when assigning the owner (e.g. use `owner(true)`) http://hg.openjdk.java.net/jdk/sandbox/file/6f2d65f29de3/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java#l1388 that approach requires additional changes in other compiler parts. I cannot say for sure how big the changes could be. 2) When compiler writes a classfile, identify the `EnclosingMethod` attribute that point to synthetic method and repoint it to a lexically enclosing method. Does anybody have any suggestions? Should I at all try either of options above? Is there any better way to do it? Please let me know. Thanks, Sergei -------------- next part -------------- An HTML attachment was scrubbed... URL: From gunnar at hibernate.org Sat Jan 5 22:04:33 2019 From: gunnar at hibernate.org (Gunnar Morling) Date: Sat, 5 Jan 2019 23:04:33 +0100 Subject: Notification upon completion of compilation Message-ID: Hi, I'm exploring the (unsupported) plug-in API of javac. Java 9 added a task event kind TaskEvent.Kind.COMPILATION which allows a listener to react to the completion of the compilation. Is there a way to achieve the same under Java 8? JDK-8033414 [1], which introduced the new event kind states "there is no easy way to be notified when the compilation is complete". What way would that be, from looking into the code I couldn't see any approach, be it easy or more complex. Thanks, --Gunnar [1] https://bugs.openjdk.java.net/browse/JDK-8033414 From gunnar at hibernate.org Sun Jan 6 08:51:34 2019 From: gunnar at hibernate.org (Gunnar Morling) Date: Sun, 6 Jan 2019 09:51:34 +0100 Subject: Notification upon completion of compilation In-Reply-To: References: Message-ID: So I've found one solution that seems good enough for my purposes: I'm counting the PARSE finished events. That way I know when I've received the last ANALYZE finished event, at which point I can take my required action (generating a resource file in this case). Thanks again, --Gunnar Am Sa., 5. Jan. 2019 um 23:04 Uhr schrieb Gunnar Morling : > > Hi, > > I'm exploring the (unsupported) plug-in API of javac. Java 9 added a > task event kind TaskEvent.Kind.COMPILATION which allows a listener to > react to the completion of the compilation. > > Is there a way to achieve the same under Java 8? JDK-8033414 [1], > which introduced the new event kind states "there is no easy way to be > notified when the compilation is complete". What way would that be, > from looking into the code I couldn't see any approach, be it easy or > more complex. > > Thanks, > > --Gunnar > > [1] https://bugs.openjdk.java.net/browse/JDK-8033414 From jonathan.gibbons at oracle.com Sun Jan 6 16:34:24 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sun, 6 Jan 2019 08:34:24 -0800 Subject: Notification upon completion of compilation In-Reply-To: References: Message-ID: <638afe9d-e595-6e9d-1e98-39bc52b73911@oracle.com> FWIW, the com.sun.source.* API is a supported API, albeit a JDK API and not a Java SE API. Tracking started/ended events seems like a reasonable way to infer when compilation is complete, but note that after parsing all the files on the command line at the beginning of the compilation, javac may read additional files later on, while analyzing files that have been read. These additional files are those that javac needs to implicitly compile in order to complete the compilation of the files given on the command line. -- Jon On 1/6/19 12:51 AM, Gunnar Morling wrote: > So I've found one solution that seems good enough for my purposes: I'm > counting the PARSE finished events. That way I know when I've received > the last ANALYZE finished event, at which point I can take my required > action (generating a resource file in this case). > > Thanks again, > > --Gunnar > > Am Sa., 5. Jan. 2019 um 23:04 Uhr schrieb Gunnar Morling : >> Hi, >> >> I'm exploring the (unsupported) plug-in API of javac. Java 9 added a >> task event kind TaskEvent.Kind.COMPILATION which allows a listener to >> react to the completion of the compilation. >> >> Is there a way to achieve the same under Java 8? JDK-8033414 [1], >> which introduced the new event kind states "there is no easy way to be >> notified when the compilation is complete". What way would that be, >> from looking into the code I couldn't see any approach, be it easy or >> more complex. >> >> Thanks, >> >> --Gunnar >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8033414 From jan.lahoda at oracle.com Mon Jan 7 12:48:07 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 7 Jan 2019 13:48:07 +0100 Subject: RFR(13): JDK-8216263: Add historical data for JDK 12 Message-ID: <5C334A87.5080207@oracle.com> Hi, To make --release 12 work, we need to add historical data for JDK 12. The current historical data is based on: $ javac -fullversion javac full version "12-ea+26" We may need to update the data once JDK 12 is out to cover any changes to the APIs that might happen. The patch also adds a simple (shell) script to generate the data, so all that was needed to generate the data was: $ cd make/data/symbols $ sh generate-data JBS: https://bugs.openjdk.java.net/browse/JDK-8216263 Webrev: http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/ How does this look? Thanks, Jan From eolivelli at gmail.com Mon Jan 7 13:28:17 2019 From: eolivelli at gmail.com (Enrico Olivelli) Date: Mon, 7 Jan 2019 14:28:17 +0100 Subject: spotBugs and JDK-8194978: Javac produces dead code for try-with-resource In-Reply-To: <5BE60326.4090202@oracle.com> References: <25e5d853-e4d4-41aa-8221-00462389fc67@oracle.com> <5BE60326.4090202@oracle.com> Message-ID: Two questions/ideas: 1) Wouldn't it be possible for javac to annotate such code blocks and write into the class file that that code is "synthetic" ? I really don't know where to store such flags, but maybe someone could elaborate more this idea 2) Why isn't javac adding the "$closeResource" method ? Enrico Il giorno ven 9 nov 2018 alle ore 23:01 Alex Buckley ha scritto: > > On 11/9/2018 12:31 PM, Vicente Romero wrote: > > My evaluation on this issue is that javac is generating code > > according to the spec, see JLS11 14.20.3.1 [1]. There is an explicit > > check for null on the resource before invoking the close() method. > > This is the null check javac is generating. > > I confirm that the explicit null check on the resource variable is > required, per the translation in > https://docs.oracle.com/javase/specs/jls/se11/html/jls-14.html#jls-14.20.3.1-140 > -- it has been specified that way since JLS7. > > > Fix for JDK-8194978 went a bit further trying to eliminate dead code > > for some cases for which javac could statically determine that the > > resource would be different from null. In particular if the resource > > was initialized with a new class expression. > > I confirm it's acceptable to not perform the null check in generated > code if you can prove the resource variable is non-null. Frankly, > though, there is so much that can occur in a "new class expression" -- > `new Outer(a(b(c)))<>.new Inner(d(e(f)))` -- that I would be > wary of trying to prove anything. > > > It could be argued that we could try to analyze the body and if we > > find out that a NPE must be thrown in the body of the try, then the > > null check on the resource would be deemed unnecessary. But then we > > can get to an implementation that will be out of sync with the spec > > plus it probably won't cover all cases. > > Right, let's not be too clever. > > Alex > > > Thanks, > > Vicente > > > > [1] > > https://docs.oracle.com/javase/specs/jls/se11/html/jls-14.html#jls-14.20.3.1 > > > > On 11/9/18 10:22 AM, Ismael Juma wrote: > >> Any comments on this? Many people are disabling spotBugs when > >> compiling with Java 11 due to this issue: > >> > >> https://github.com/spotbugs/spotbugs/issues/756 > >> > >> Ismael > >> > >> On Thu, Sep 13, 2018 at 10:05 PM Ismael Juma >> > wrote: > >> > >> Hi all, > >> > >> JDK-8194978 introduced some changes to the bytecode generated by > >> javac for the try with resource construct. In the following code, > >> it seems to generate a null check on a reference after invoking a > >> method on it: > >> > >> public static void readFileAsString(String path) throws > >> IOException { > >> try (FileChannel fc = FileChannel.open(Paths.get(path))) { > >> fc.size(); > >> } > >> > >> } > >> > >> In line 16 to 22 of the bytecode, it looks like we check for null > >> after calling a method on the fc reference: > >> > >> 16: aload_1 > >> 17: invokevirtual #6 // Method > >> java/nio/channels/FileChannel.size:()J > >> 20: pop2 > >> 21: aload_1 > >> 22: ifnull 52 > >> 25: aload_1 > >> 26: invokevirtual #7 // Method > >> java/nio/channels/FileChannel.close:()V > >> > >> Is this intentional? I ask because this pattern triggers a > >> spotBugs warning since it often implies a bug in user's code: > >> > >> RCN | Nullcheck of fc at line 10 of value previously dereferenced > >> in TryTest.readFileAsString(String, Charset) > >> > >> Note that this works fine in Java versions older than Java 11. > >> Since this spotBugs warning is generally useful, it would be handy > >> if javac did not trigger it. Alternatively, if there's a good way > >> to detect the code that was generated by javac, spotBugs could be > >> updated to ignore it. For reference, this was discussed in the > >> spotBugs issue tracker: > >> > >> https://github.com/spotbugs/spotbugs/issues/756 > >> > >> And method bytecode in full: > >> > >> public static void readFileAsString(java.lang.String) throws > >> java.io.IOException; > >> Code: > >> 0: aload_0 > >> 1: iconst_0 > >> 2: anewarray #2 // class java/lang/String > >> 5: invokestatic #3 // Method > >> java/nio/file/Paths.get:(Ljava/lang/String;[Ljava/lang/String;)Ljava/nio/file/Path; > >> 8: iconst_0 > >> 9: anewarray #4 // class > >> java/nio/file/OpenOption > >> 12: invokestatic #5 // Method > >> java/nio/channels/FileChannel.open:(Ljava/nio/file/Path;[Ljava/nio/file/OpenOption;)Ljava/nio/channels/FileChannel; > >> 15: astore_1 > >> 16: aload_1 > >> 17: invokevirtual #6 // Method > >> java/nio/channels/FileChannel.size:()J > >> 20: pop2 > >> 21: aload_1 > >> 22: ifnull 52 > >> 25: aload_1 > >> 26: invokevirtual #7 // Method > >> java/nio/channels/FileChannel.close:()V > >> 29: goto 52 > >> 32: astore_2 > >> 33: aload_1 > >> 34: ifnull 50 > >> 37: aload_1 > >> 38: invokevirtual #7 // Method > >> java/nio/channels/FileChannel.close:()V > >> 41: goto 50 > >> 44: astore_3 > >> 45: aload_2 > >> 46: aload_3 > >> 47: invokevirtual #9 // Method > >> java/lang/Throwable.addSuppressed:(Ljava/lang/Throwable;)V > >> 50: aload_2 > >> 51: athrow > >> 52: return > >> Exception table: > >> from to target type > >> 16 21 32 Class java/lang/Throwable > >> 37 41 44 Class java/lang/Throwable > >> > >> Thanks, > >> Ismael > >> > > From alex.buckley at oracle.com Mon Jan 7 20:09:59 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 07 Jan 2019 12:09:59 -0800 Subject: RFR - JDK-8215682 - Remove compiler support for Raw String Literals from JDK 12 In-Reply-To: <27F1C797-B045-443F-8E41-31F753420B53@oracle.com> References: <27F1C797-B045-443F-8E41-31F753420B53@oracle.com> Message-ID: <5C33B217.60907@oracle.com> I tightened up the text a bit, and added myself as a reviewer. On 1/2/2019 10:02 AM, Jim Laskey wrote: > Looking for reviewers to make sure this CSR passes muster. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8215682 > > Thank you. > > Cheers, > > ? Jim From james.laskey at oracle.com Mon Jan 7 20:34:08 2019 From: james.laskey at oracle.com (James Laskey) Date: Mon, 7 Jan 2019 16:34:08 -0400 Subject: RFR - JDK-8215682 - Remove compiler support for Raw String Literals from JDK 12 In-Reply-To: <5C33B217.60907@oracle.com> References: <27F1C797-B045-443F-8E41-31F753420B53@oracle.com> <5C33B217.60907@oracle.com> Message-ID: <6CDD2070-167F-4630-8533-C1FA5A92F26E@oracle.com> Thank you. Sent from my iPhone > On Jan 7, 2019, at 4:09 PM, Alex Buckley wrote: > > I tightened up the text a bit, and added myself as a reviewer. > >> On 1/2/2019 10:02 AM, Jim Laskey wrote: >> Looking for reviewers to make sure this CSR passes muster. >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8215682 >> >> Thank you. >> >> Cheers, >> >> ? Jim From joe.darcy at oracle.com Mon Jan 7 22:51:12 2019 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 07 Jan 2019 14:51:12 -0800 Subject: RFR(13): JDK-8216263: Add historical data for JDK 12 In-Reply-To: <5C334A87.5080207@oracle.com> References: <5C334A87.5080207@oracle.com> Message-ID: <5C33D7E0.2020609@oracle.com> Hi Jan, On 1/7/2019 4:48 AM, Jan Lahoda wrote: > Hi, > > To make --release 12 work, we need to add historical data for JDK 12. > The current historical data is based on: > $ javac -fullversion > javac full version "12-ea+26" > > We may need to update the data once JDK 12 is out to cover any changes > to the APIs that might happen. > > The patch also adds a simple (shell) script to generate the data, so > all that was needed to generate the data was: > $ cd make/data/symbols > $ sh generate-data > > JBS: https://bugs.openjdk.java.net/browse/JDK-8216263 > Webrev: http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/ > > How does this look? If the overhead is small enough and we don't mind a few updates to the JDK N+1 data, than perhaps the generation of this information could be included as part of the start of JDK N+1 activities. I suggest a more extensive description of how to make/data/symbols/generate-data. For example, this builds the data for the current release independent of whether or not the current release has already had its data generated, correct? Concretely, if JDK N+1 has already forked, what is the proper way to get data for JDK N? Likewise, how should a re-build of the data for JDK N be done? Thanks, -Joe From joe.darcy at oracle.com Tue Jan 8 06:43:13 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 7 Jan 2019 22:43:13 -0800 Subject: JDK 13 RFR of 8216335: Minor cleanups to javax.annotation.processing and javax.lang.model javadoc Message-ID: <1d4a87a8-7664-9062-7662-6e5e773f7982@oracle.com> Hello, A pass over the javax.annotation.processing and javax.lang.model specs revealed various areas for improvement. Please review the fixes to address those issues in the webrev and the corresponding patch below: ??? http://cr.openjdk.java.net/~darcy/8216335.0/ Thanks, -Joe --- old/src/java.compiler/share/classes/javax/annotation/processing/AbstractProcessor.java 2019-01-07 22:32:32.960000000 -0800 +++ new/src/java.compiler/share/classes/javax/annotation/processing/AbstractProcessor.java 2019-01-07 22:32:32.756000000 -0800 @@ -92,10 +92,10 @@ * same set of strings as the annotation. If the class is not so * annotated, an empty set is returned. * - * If the {@link ProcessingEnvironment#getSourceVersion source + * If the {@linkplain ProcessingEnvironment#getSourceVersion source * version} does not support modules, in other words if it is less * than or equal to {@link SourceVersion#RELEASE_8 RELEASE_8}, - * then any leading {@link Processor#getSupportedAnnotationTypes + * then any leading {@linkplain Processor#getSupportedAnnotationTypes * module prefixes} are stripped from the names. * * @return the names of the annotation types supported by this --- old/src/java.compiler/share/classes/javax/annotation/processing/Filer.java 2019-01-07 22:32:33.376000000 -0800 +++ new/src/java.compiler/share/classes/javax/annotation/processing/Filer.java 2019-01-07 22:32:33.180000000 -0800 @@ -60,7 +60,7 @@ * by {@code '/'}; {@code '.'} and {@code '..'} are invalid path * segments. A valid relative name must match the * "path-rootless" rule of RFC 3986, section + * href="http://www.ietf.org/html/rfc3986.txt">RFC 3986, section * 3.3. * *

The file creation methods take a variable number of arguments to --- old/src/java.compiler/share/classes/javax/annotation/processing/Processor.java 2019-01-07 22:32:33.940000000 -0800 +++ new/src/java.compiler/share/classes/javax/annotation/processing/Processor.java 2019-01-07 22:32:33.748000000 -0800 @@ -59,7 +59,7 @@ * constructor of the processor class. * *

  • Next, the tool calls the {@link #init init} method with - * an appropriate {@code ProcessingEnvironment}. + * an appropriate {@link ProcessingEnvironment}. * *
  • Afterwards, the tool calls {@link #getSupportedAnnotationTypes * getSupportedAnnotationTypes}, {@link #getSupportedOptions --- old/src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java 2019-01-07 22:32:34.520000000 -0800 +++ new/src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java 2019-01-07 22:32:34.328000000 -0800 @@ -317,7 +317,7 @@ /** * Returns the specific modules to which the package is being exported, - * or null, if the package is exported to all modules which + * or {@code null}, if the package is exported to all modules which * have readability to this module. * @return the specific modules to which the package is being exported */ @@ -339,7 +339,7 @@ /** * Returns the specific modules to which the package is being open - * or null, if the package is open all modules which + * or {@code null}, if the package is open all modules which * have readability to this module. * @return the specific modules to which the package is being opened */ --- old/src/java.compiler/share/classes/javax/lang/model/util/Elements.java 2019-01-07 22:32:34.928000000 -0800 +++ new/src/java.compiler/share/classes/javax/lang/model/util/Elements.java 2019-01-07 22:32:34.732000000 -0800 @@ -511,6 +511,7 @@ * @param hidden the second element * @return {@code true} if and only if the first element hides * the second + * @jls 8.4.8 Inheritance, Overriding, and Hiding */ boolean hides(Element hider, Element hidden); -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Tue Jan 8 07:26:39 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 7 Jan 2019 23:26:39 -0800 Subject: JDK 12 RFR of JDK-8216322 : Missing since information in deprecation of constructor visitors Message-ID: Hello, When the JDK 7-era constructors were deprecated earlier in JDK 12 (JDK-8173606), the "since" deprecation information should have been included. Please review the changes to add the since information after the fact along with its CSR: ??? http://cr.openjdk.java.net/~darcy/8216322.0/ ??? http://bugs.openjdk.java.net/browse/JDK-8216351 Patch below. Files updating using sed. Thanks, -Joe --- old/src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor7.java 2019-01-07 23:13:31.340000000 -0800 +++ new/src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor7.java 2019-01-07 23:13:31.140000000 -0800 @@ -68,7 +68,7 @@ ????? * @deprecated Release 7 is obsolete; update to a visitor for a newer ????? * release level. ????? */ -??? @Deprecated +??? @Deprecated(since="12") ???? protected AbstractAnnotationValueVisitor7() { ???????? super(); // Superclass constructor deprecated too ???? } --- old/src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor7.java 2019-01-07 23:13:31.780000000 -0800 +++ new/src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor7.java 2019-01-07 23:13:31.584000000 -0800 @@ -71,7 +71,7 @@ ????? * @deprecated Release 7 is obsolete; update to a visitor for a newer ????? * release level. ????? */ -??? @Deprecated +??? @Deprecated(since="12") ???? protected AbstractElementVisitor7(){ ???????? super(); // Superclass constructor deprecated too ???? } --- old/src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor7.java 2019-01-07 23:13:32.196000000 -0800 +++ new/src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor7.java 2019-01-07 23:13:32.000000000 -0800 @@ -71,7 +71,7 @@ ????? * @deprecated Release 7 is obsolete; update to a visitor for a newer ????? * release level. ????? */ -??? @Deprecated +??? @Deprecated(since="12") ???? protected AbstractTypeVisitor7() { ???????? super();? // Superclass constructor deprecated too ???? } --- old/src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor7.java 2019-01-07 23:13:32.620000000 -0800 +++ new/src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor7.java 2019-01-07 23:13:32.428000000 -0800 @@ -85,7 +85,7 @@ ????? * @deprecated Release 7 is obsolete; update to a visitor for a newer ????? * release level. ????? */ -??? @Deprecated +??? @Deprecated(since="12") ???? protected ElementKindVisitor7() { ???????? super(null); // Superclass constructor deprecated too ???? } @@ -99,7 +99,7 @@ ????? * @deprecated Release 7 is obsolete; update to a visitor for a newer ????? * release level. ????? */ -??? @Deprecated +??? @Deprecated(since="12") ???? protected ElementKindVisitor7(R defaultValue) { ???????? super(defaultValue); // Superclass constructor deprecated too ???? } --- old/src/java.compiler/share/classes/javax/lang/model/util/ElementScanner7.java 2019-01-07 23:13:33.028000000 -0800 +++ new/src/java.compiler/share/classes/javax/lang/model/util/ElementScanner7.java 2019-01-07 23:13:32.836000000 -0800 @@ -98,7 +98,7 @@ ????? * @deprecated Release 7 is obsolete; update to a visitor for a newer ????? * release level. ????? */ -??? @Deprecated +??? @Deprecated(since="12") ???? protected ElementScanner7(){ ???????? super(null); // Superclass constructor deprecated too ???? } @@ -112,7 +112,7 @@ ????? * @deprecated Release 7 is obsolete; update to a visitor for a newer ????? * release level. ????? */ -??? @Deprecated +??? @Deprecated(since="12") ???? protected ElementScanner7(R defaultValue){ ???????? super(defaultValue); // Superclass constructor deprecated too ???? } --- old/src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor7.java 2019-01-07 23:13:33.432000000 -0800 +++ new/src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor7.java 2019-01-07 23:13:33.240000000 -0800 @@ -75,7 +75,7 @@ ????? * @deprecated Release 7 is obsolete; update to a visitor for a newer ????? * release level. ????? */ -??? @Deprecated +??? @Deprecated(since="12") ???? protected SimpleAnnotationValueVisitor7() { ???????? super(null); // Superclass constructor deprecated too ???? } @@ -89,7 +89,7 @@ ????? * @deprecated Release 7 is obsolete; update to a visitor for a newer ????? * release level. ????? */ -??? @Deprecated +??? @Deprecated(since="12") ???? protected SimpleAnnotationValueVisitor7(R defaultValue) { ???????? super(defaultValue); // Superclass constructor deprecated too ???? } --- old/src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor7.java 2019-01-07 23:13:33.840000000 -0800 +++ new/src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor7.java 2019-01-07 23:13:33.644000000 -0800 @@ -81,7 +81,7 @@ ????? * @deprecated Release 7 is obsolete; update to a visitor for a newer ????? * release level. ????? */ -??? @Deprecated +??? @Deprecated(since="12") ???? protected SimpleElementVisitor7(){ ???????? super(null); // Superclass constructor deprecated too ???? } @@ -95,7 +95,7 @@ ????? * @deprecated Release 7 is obsolete; update to a visitor for a newer ????? * release level. ????? */ -??? @Deprecated +??? @Deprecated(since="12") ???? protected SimpleElementVisitor7(R defaultValue){ ???????? super(defaultValue); // Superclass constructor deprecated too ???? } --- old/src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor7.java 2019-01-07 23:13:34.252000000 -0800 +++ new/src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor7.java 2019-01-07 23:13:34.060000000 -0800 @@ -81,7 +81,7 @@ ????? * @deprecated Release 7 is obsolete; update to a visitor for a newer ????? * release level. ????? */ -??? @Deprecated +??? @Deprecated(since="12") ???? protected SimpleTypeVisitor7(){ ???????? super(null); // Superclass constructor deprecated too ???? } @@ -95,7 +95,7 @@ ????? * @deprecated Release 7 is obsolete; update to a visitor for a newer ????? * release level. ????? */ -??? @Deprecated +??? @Deprecated(since="12") ???? protected SimpleTypeVisitor7(R defaultValue){ ???????? super(defaultValue); // Superclass constructor deprecated too ???? } --- old/src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor7.java 2019-01-07 23:13:34.668000000 -0800 +++ new/src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor7.java 2019-01-07 23:13:34.476000000 -0800 @@ -82,7 +82,7 @@ ????? * @deprecated Release 7 is obsolete; update to a visitor for a newer ????? * release level. ????? */ -??? @Deprecated +??? @Deprecated(since="12") ???? protected TypeKindVisitor7() { ???????? super(null); // Superclass constructor deprecated too ???? } @@ -96,7 +96,7 @@ ????? * @deprecated Release 7 is obsolete; update to a visitor for a newer ????? * release level. ????? */ -??? @Deprecated +??? @Deprecated(since="12") ???? protected TypeKindVisitor7(R defaultValue) { ???????? super(defaultValue); // Superclass constructor deprecated too ???? } From jan.lahoda at oracle.com Tue Jan 8 10:13:11 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 8 Jan 2019 11:13:11 +0100 Subject: RFR(13): JDK-8216263: Add historical data for JDK 12 In-Reply-To: <5C33D7E0.2020609@oracle.com> References: <5C334A87.5080207@oracle.com> <5C33D7E0.2020609@oracle.com> Message-ID: <5C3477B7.8060307@oracle.com> Hi Joe, Thanks for the comments, some responses inline. Updated webrev: http://cr.openjdk.java.net/~jlahoda/8216263/webrev.01/ On 7.1.2019 23:51, Joseph D. Darcy wrote: > Hi Jan, > > On 1/7/2019 4:48 AM, Jan Lahoda wrote: >> Hi, >> >> To make --release 12 work, we need to add historical data for JDK 12. >> The current historical data is based on: >> $ javac -fullversion >> javac full version "12-ea+26" >> >> We may need to update the data once JDK 12 is out to cover any changes >> to the APIs that might happen. >> >> The patch also adds a simple (shell) script to generate the data, so >> all that was needed to generate the data was: >> $ cd make/data/symbols >> $ sh generate-data >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8216263 >> Webrev: http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/ >> >> How does this look? > > If the overhead is small enough and we don't mind a few updates to the > JDK N+1 data, than perhaps the generation of this information could be > included as part of the start of JDK N+1 activities. That would be perfect! > > I suggest a more extensive description of how to > make/data/symbols/generate-data. For example, this builds the data for > the current release independent of whether or not the current release > has already had its data generated, correct? Yes. > > Concretely, if JDK N+1 has already forked, what is the proper way to get > data for JDK N? Likewise, how should a re-build of the data for JDK N be > done? What exactly should be there? To the existing description: # to generate (add) data for JDK N, do: # cd make/data/symbols # sh generate-data I've added (in .01): # to regenerate the data for JDK N, run the above commands again What more should be there? Thanks, Jan > > Thanks, > > -Joe > From vicente.romero at oracle.com Tue Jan 8 19:11:35 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 8 Jan 2019 14:11:35 -0500 Subject: JDK 13 RFR of 8216335: Minor cleanups to javax.annotation.processing and javax.lang.model javadoc In-Reply-To: <1d4a87a8-7664-9062-7662-6e5e773f7982@oracle.com> References: <1d4a87a8-7664-9062-7662-6e5e773f7982@oracle.com> Message-ID: looks good, Vicente On 1/8/19 1:43 AM, Joe Darcy wrote: > > Hello, > > A pass over the javax.annotation.processing and javax.lang.model specs > revealed various areas for improvement. > > Please review the fixes to address those issues in the webrev and the > corresponding patch below: > > http://cr.openjdk.java.net/~darcy/8216335.0/ > > Thanks, > > -Joe > > --- old/src/java.compiler/share/classes/javax/annotation/processing/AbstractProcessor.java 2019-01-07 22:32:32.960000000 -0800 > +++ new/src/java.compiler/share/classes/javax/annotation/processing/AbstractProcessor.java 2019-01-07 22:32:32.756000000 -0800 > @@ -92,10 +92,10 @@ > * same set of strings as the annotation. If the class is not so > * annotated, an empty set is returned. > * > - * If the {@link ProcessingEnvironment#getSourceVersion source > + * If the {@linkplain ProcessingEnvironment#getSourceVersion source > * version} does not support modules, in other words if it is less > * than or equal to {@link SourceVersion#RELEASE_8 RELEASE_8}, > - * then any leading {@link Processor#getSupportedAnnotationTypes > + * then any leading {@linkplain Processor#getSupportedAnnotationTypes > * module prefixes} are stripped from the names. > * > * @return the names of the annotation types supported by this > --- old/src/java.compiler/share/classes/javax/annotation/processing/Filer.java 2019-01-07 22:32:33.376000000 -0800 > +++ new/src/java.compiler/share/classes/javax/annotation/processing/Filer.java 2019-01-07 22:32:33.180000000 -0800 > @@ -60,7 +60,7 @@ > * by {@code '/'}; {@code '.'} and {@code '..'} are invalid path > * segments. A valid relative name must match the > * "path-rootless" rule of - * href="http://www.ietf.org/rfc/rfc3986.txt">RFC 3986, section > + * href="http://www.ietf.org/html/rfc3986.txt">RFC 3986, section > * 3.3. > * > *

    The file creation methods take a variable number of arguments to > --- old/src/java.compiler/share/classes/javax/annotation/processing/Processor.java 2019-01-07 22:32:33.940000000 -0800 > +++ new/src/java.compiler/share/classes/javax/annotation/processing/Processor.java 2019-01-07 22:32:33.748000000 -0800 > @@ -59,7 +59,7 @@ > * constructor of the processor class. > * > *

  • Next, the tool calls the {@link #init init} method with > - * an appropriate {@code ProcessingEnvironment}. > + * an appropriate {@link ProcessingEnvironment}. > * > *
  • Afterwards, the tool calls {@link #getSupportedAnnotationTypes > * getSupportedAnnotationTypes}, {@link #getSupportedOptions > --- old/src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java 2019-01-07 22:32:34.520000000 -0800 > +++ new/src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java 2019-01-07 22:32:34.328000000 -0800 > @@ -317,7 +317,7 @@ > > /** > * Returns the specific modules to which the package is being exported, > - * or null, if the package is exported to all modules which > + * or {@code null}, if the package is exported to all modules which > * have readability to this module. > * @return the specific modules to which the package is being exported > */ > @@ -339,7 +339,7 @@ > > /** > * Returns the specific modules to which the package is being open > - * or null, if the package is open all modules which > + * or {@code null}, if the package is open all modules which > * have readability to this module. > * @return the specific modules to which the package is being opened > */ > --- old/src/java.compiler/share/classes/javax/lang/model/util/Elements.java 2019-01-07 22:32:34.928000000 -0800 > +++ new/src/java.compiler/share/classes/javax/lang/model/util/Elements.java 2019-01-07 22:32:34.732000000 -0800 > @@ -511,6 +511,7 @@ > * @param hidden the second element > * @return {@code true} if and only if the first element hides > * the second > + * @jls 8.4.8 Inheritance, Overriding, and Hiding > */ > boolean hides(Element hider, Element hidden); > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Tue Jan 8 19:13:57 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 8 Jan 2019 14:13:57 -0500 Subject: JDK 12 RFR of JDK-8216322 : Missing since information in deprecation of constructor visitors In-Reply-To: References: Message-ID: <8bac6ee3-bea7-57be-3e3b-6c45bc6e7c07@oracle.com> looks good, Vicente On 1/8/19 2:26 AM, Joe Darcy wrote: > Hello, > > When the JDK 7-era constructors were deprecated earlier in JDK 12 > (JDK-8173606), the "since" deprecation information should have been > included. Please review the changes to add the since information after > the fact along with its CSR: > > ??? http://cr.openjdk.java.net/~darcy/8216322.0/ > ??? http://bugs.openjdk.java.net/browse/JDK-8216351 > > Patch below. > > Files updating using sed. > > Thanks, > > -Joe > > --- > old/src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor7.java > 2019-01-07 23:13:31.340000000 -0800 > +++ > new/src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor7.java > 2019-01-07 23:13:31.140000000 -0800 > @@ -68,7 +68,7 @@ > ????? * @deprecated Release 7 is obsolete; update to a visitor for a > newer > ????? * release level. > ????? */ > -??? @Deprecated > +??? @Deprecated(since="12") > ???? protected AbstractAnnotationValueVisitor7() { > ???????? super(); // Superclass constructor deprecated too > ???? } > --- > old/src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor7.java > 2019-01-07 23:13:31.780000000 -0800 > +++ > new/src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor7.java > 2019-01-07 23:13:31.584000000 -0800 > @@ -71,7 +71,7 @@ > ????? * @deprecated Release 7 is obsolete; update to a visitor for a > newer > ????? * release level. > ????? */ > -??? @Deprecated > +??? @Deprecated(since="12") > ???? protected AbstractElementVisitor7(){ > ???????? super(); // Superclass constructor deprecated too > ???? } > --- > old/src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor7.java > 2019-01-07 23:13:32.196000000 -0800 > +++ > new/src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor7.java > 2019-01-07 23:13:32.000000000 -0800 > @@ -71,7 +71,7 @@ > ????? * @deprecated Release 7 is obsolete; update to a visitor for a > newer > ????? * release level. > ????? */ > -??? @Deprecated > +??? @Deprecated(since="12") > ???? protected AbstractTypeVisitor7() { > ???????? super();? // Superclass constructor deprecated too > ???? } > --- > old/src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor7.java > 2019-01-07 23:13:32.620000000 -0800 > +++ > new/src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor7.java > 2019-01-07 23:13:32.428000000 -0800 > @@ -85,7 +85,7 @@ > ????? * @deprecated Release 7 is obsolete; update to a visitor for a > newer > ????? * release level. > ????? */ > -??? @Deprecated > +??? @Deprecated(since="12") > ???? protected ElementKindVisitor7() { > ???????? super(null); // Superclass constructor deprecated too > ???? } > @@ -99,7 +99,7 @@ > ????? * @deprecated Release 7 is obsolete; update to a visitor for a > newer > ????? * release level. > ????? */ > -??? @Deprecated > +??? @Deprecated(since="12") > ???? protected ElementKindVisitor7(R defaultValue) { > ???????? super(defaultValue); // Superclass constructor deprecated too > ???? } > --- > old/src/java.compiler/share/classes/javax/lang/model/util/ElementScanner7.java > 2019-01-07 23:13:33.028000000 -0800 > +++ > new/src/java.compiler/share/classes/javax/lang/model/util/ElementScanner7.java > 2019-01-07 23:13:32.836000000 -0800 > @@ -98,7 +98,7 @@ > ????? * @deprecated Release 7 is obsolete; update to a visitor for a > newer > ????? * release level. > ????? */ > -??? @Deprecated > +??? @Deprecated(since="12") > ???? protected ElementScanner7(){ > ???????? super(null); // Superclass constructor deprecated too > ???? } > @@ -112,7 +112,7 @@ > ????? * @deprecated Release 7 is obsolete; update to a visitor for a > newer > ????? * release level. > ????? */ > -??? @Deprecated > +??? @Deprecated(since="12") > ???? protected ElementScanner7(R defaultValue){ > ???????? super(defaultValue); // Superclass constructor deprecated too > ???? } > --- > old/src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor7.java > 2019-01-07 23:13:33.432000000 -0800 > +++ > new/src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor7.java > 2019-01-07 23:13:33.240000000 -0800 > @@ -75,7 +75,7 @@ > ????? * @deprecated Release 7 is obsolete; update to a visitor for a > newer > ????? * release level. > ????? */ > -??? @Deprecated > +??? @Deprecated(since="12") > ???? protected SimpleAnnotationValueVisitor7() { > ???????? super(null); // Superclass constructor deprecated too > ???? } > @@ -89,7 +89,7 @@ > ????? * @deprecated Release 7 is obsolete; update to a visitor for a > newer > ????? * release level. > ????? */ > -??? @Deprecated > +??? @Deprecated(since="12") > ???? protected SimpleAnnotationValueVisitor7(R defaultValue) { > ???????? super(defaultValue); // Superclass constructor deprecated too > ???? } > --- > old/src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor7.java > 2019-01-07 23:13:33.840000000 -0800 > +++ > new/src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor7.java > 2019-01-07 23:13:33.644000000 -0800 > @@ -81,7 +81,7 @@ > ????? * @deprecated Release 7 is obsolete; update to a visitor for a > newer > ????? * release level. > ????? */ > -??? @Deprecated > +??? @Deprecated(since="12") > ???? protected SimpleElementVisitor7(){ > ???????? super(null); // Superclass constructor deprecated too > ???? } > @@ -95,7 +95,7 @@ > ????? * @deprecated Release 7 is obsolete; update to a visitor for a > newer > ????? * release level. > ????? */ > -??? @Deprecated > +??? @Deprecated(since="12") > ???? protected SimpleElementVisitor7(R defaultValue){ > ???????? super(defaultValue); // Superclass constructor deprecated too > ???? } > --- > old/src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor7.java > 2019-01-07 23:13:34.252000000 -0800 > +++ > new/src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor7.java > 2019-01-07 23:13:34.060000000 -0800 > @@ -81,7 +81,7 @@ > ????? * @deprecated Release 7 is obsolete; update to a visitor for a > newer > ????? * release level. > ????? */ > -??? @Deprecated > +??? @Deprecated(since="12") > ???? protected SimpleTypeVisitor7(){ > ???????? super(null); // Superclass constructor deprecated too > ???? } > @@ -95,7 +95,7 @@ > ????? * @deprecated Release 7 is obsolete; update to a visitor for a > newer > ????? * release level. > ????? */ > -??? @Deprecated > +??? @Deprecated(since="12") > ???? protected SimpleTypeVisitor7(R defaultValue){ > ???????? super(defaultValue); // Superclass constructor deprecated too > ???? } > --- > old/src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor7.java > 2019-01-07 23:13:34.668000000 -0800 > +++ > new/src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor7.java > 2019-01-07 23:13:34.476000000 -0800 > @@ -82,7 +82,7 @@ > ????? * @deprecated Release 7 is obsolete; update to a visitor for a > newer > ????? * release level. > ????? */ > -??? @Deprecated > +??? @Deprecated(since="12") > ???? protected TypeKindVisitor7() { > ???????? super(null); // Superclass constructor deprecated too > ???? } > @@ -96,7 +96,7 @@ > ????? * @deprecated Release 7 is obsolete; update to a visitor for a > newer > ????? * release level. > ????? */ > -??? @Deprecated > +??? @Deprecated(since="12") > ???? protected TypeKindVisitor7(R defaultValue) { > ???????? super(defaultValue); // Superclass constructor deprecated too > ???? } > From cushon at google.com Wed Jan 9 01:44:54 2019 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 8 Jan 2019 17:44:54 -0800 Subject: RFR: 8216403: Allocate fewer EnumSets in JavacFileManager#list Message-ID: Hi, Please consider this trivial performance improvement, which moves a couple of allocations out of JavacFileManager#list. bug: https://bugs.openjdk.java.net/browse/JDK-8216403 webrev: http://cr.openjdk.java.net/~cushon/8216403/webrev.00/ Thanks, Liam -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattiask at spotify.com Wed Jan 9 08:40:09 2019 From: mattiask at spotify.com (Mattias Nordin Kettil) Date: Wed, 9 Jan 2019 09:40:09 +0100 Subject: Backporting JDK-8210483 to Java 11 Message-ID: Hello! I have searched the bug pages and mailing list archives for this, but I can't find any information about a potential backport of the JDK-8210483 fix to Java 11. Will it be included in Java 11, and if so, is it possible to say when? Best regards, Mattias Nordin Kettil -------------- next part -------------- An HTML attachment was scrubbed... URL: From claes.redestad at oracle.com Wed Jan 9 09:48:12 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 9 Jan 2019 10:48:12 +0100 Subject: RFR: 8216403: Allocate fewer EnumSets in JavacFileManager#list In-Reply-To: References: Message-ID: Hi, not really a langtools reviewer, but I generally avoid using raw static EnumSets due their mutable nature (not saying there's a bug here - just that we should consider all possible futures and treat them kindly). Set.of() / Set.of(FOLLOW_LINKS) is a compact, performant and safer alternative. Thanks! /Claes On 2019-01-09 02:44, Liam Miller-Cushon wrote: > Hi, > > Please consider this trivial performance improvement, which moves a > couple of allocations out of JavacFileManager#list. > > bug: https://bugs.openjdk.java.net/browse/JDK-8216403 > webrev: http://cr.openjdk.java.net/~cushon/8216403/webrev.00/ > > Thanks, > Liam From forax at univ-mlv.fr Wed Jan 9 10:38:51 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 9 Jan 2019 11:38:51 +0100 (CET) Subject: RFR: 8216403: Allocate fewer EnumSets in JavacFileManager#list In-Reply-To: References: Message-ID: <1545406327.649889.1547030331191.JavaMail.zimbra@u-pem.fr> List.of() (with no argument) doesn't need to be stored in a static final given it's already a value stored in a static final and i'm not sure that in this case List.of(oneSingleValue) will be allocated due to escape analysis. R?mi ----- Mail original ----- > De: "Claes Redestad" > ?: "Liam Miller-Cushon" , "compiler-dev" , "Ron Shapiro" > > Envoy?: Mercredi 9 Janvier 2019 10:48:12 > Objet: Re: RFR: 8216403: Allocate fewer EnumSets in JavacFileManager#list > Hi, > > not really a langtools reviewer, but I generally avoid using raw > static EnumSets due their mutable nature (not saying there's a bug > here - just that we should consider all possible futures and treat them > kindly). > > Set.of() / Set.of(FOLLOW_LINKS) is a compact, performant and safer > alternative. > > Thanks! > > /Claes > > On 2019-01-09 02:44, Liam Miller-Cushon wrote: >> Hi, >> >> Please consider this trivial performance improvement, which moves a >> couple of allocations out of JavacFileManager#list. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8216403 >> webrev: http://cr.openjdk.java.net/~cushon/8216403/webrev.00/ >> >> Thanks, > > Liam From claes.redestad at oracle.com Wed Jan 9 11:54:27 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 9 Jan 2019 12:54:27 +0100 Subject: RFR: 8216403: Allocate fewer EnumSets in JavacFileManager#list In-Reply-To: <1545406327.649889.1547030331191.JavaMail.zimbra@u-pem.fr> References: <1545406327.649889.1547030331191.JavaMail.zimbra@u-pem.fr> Message-ID: <2b23c51d-c688-5dd7-6ef7-ac6469acce42@oracle.com> On 2019-01-09 11:38, Remi Forax wrote: > List.of() (with no argument) doesn't need to be stored in a static final given it's already a value stored in a static final True, but a static final likely doesn't hurt, either, especially not during startup/warmup. > and i'm not sure that in this case List.of(oneSingleValue) will be allocated due to escape analysis. That's assuming it's hot enough to reach C2 *and* get sufficiently inlined for EA to kick in. I don't doubt the speed-up as seen in the bug report is real. :-) /Claes > > R?mi > > ----- Mail original ----- >> De: "Claes Redestad" >> ?: "Liam Miller-Cushon" , "compiler-dev" , "Ron Shapiro" >> >> Envoy?: Mercredi 9 Janvier 2019 10:48:12 >> Objet: Re: RFR: 8216403: Allocate fewer EnumSets in JavacFileManager#list > >> Hi, >> >> not really a langtools reviewer, but I generally avoid using raw >> static EnumSets due their mutable nature (not saying there's a bug >> here - just that we should consider all possible futures and treat them >> kindly). >> >> Set.of() / Set.of(FOLLOW_LINKS) is a compact, performant and safer >> alternative. >> >> Thanks! >> >> /Claes >> >> On 2019-01-09 02:44, Liam Miller-Cushon wrote: >>> Hi, >>> >>> Please consider this trivial performance improvement, which moves a >>> couple of allocations out of JavacFileManager#list. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8216403 >>> webrev: http://cr.openjdk.java.net/~cushon/8216403/webrev.00/ >>> >>> Thanks, >>> Liam From james.laskey at oracle.com Wed Jan 9 13:09:57 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 9 Jan 2019 09:09:57 -0400 Subject: RFR - JDK-8215681 Remove compiler support for Raw String Literals from JDK 12 In-Reply-To: <1768A8D0-A8DE-477D-910A-1902E5D92F97@oracle.com> References: <1768A8D0-A8DE-477D-910A-1902E5D92F97@oracle.com> Message-ID: <159F1366-BF51-4E69-A629-70176C5CD178@oracle.com> Could I get one or two more reviewers please? Thank you ? Jim > On Dec 20, 2018, at 9:20 AM, Jim Laskey wrote: > > With the withdrawal of JEP 326: Raw String Literals (Preview) from JDK 12, code introduced into javac to support the specification must be removed. > > webrev: http://cr.openjdk.java.net/~jlaskey/8215681/webrev/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8215681 > > Thank you. > > Cheers, > > ? Jim > > CSR: https://bugs.openjdk.java.net/browse/JDK-8215682 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Wed Jan 9 13:17:29 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 9 Jan 2019 14:17:29 +0100 Subject: RFR - JDK-8215681 Remove compiler support for Raw String Literals from JDK 12 In-Reply-To: <159F1366-BF51-4E69-A629-70176C5CD178@oracle.com> References: <1768A8D0-A8DE-477D-910A-1902E5D92F97@oracle.com> <159F1366-BF51-4E69-A629-70176C5CD178@oracle.com> Message-ID: <5C35F469.6050002@oracle.com> Looks OK to me, for the record. Jan On 9.1.2019 14:09, Jim Laskey wrote: > Could I get one or two more reviewers please? > > Thank you > > ? Jim > > >> On Dec 20, 2018, at 9:20 AM, Jim Laskey > > wrote: >> >> With the withdrawal of JEP 326: Raw String Literals (Preview) from JDK >> 12, code introduced into javac to support the specification must be >> removed. >> >> webrev: http://cr.openjdk.java.net/~jlaskey/8215681/webrev/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8215681 >> >> Thank you. >> >> Cheers, >> >> ? Jim >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8215682 >> >> > From vicente.romero at oracle.com Wed Jan 9 13:21:41 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 9 Jan 2019 08:21:41 -0500 Subject: RFR: 8216403: Allocate fewer EnumSets in JavacFileManager#list In-Reply-To: References: Message-ID: <34e181dd-adf0-4dd8-5874-e9333f98512b@oracle.com> looks good, Vicente On 1/8/19 8:44 PM, Liam Miller-Cushon wrote: > Hi, > > Please consider this trivial performance improvement, which moves a > couple of allocations out of JavacFileManager#list. > > bug: https://bugs.openjdk.java.net/browse/JDK-8216403 > webrev: http://cr.openjdk.java.net/~cushon/8216403/webrev.00/ > > Thanks, > Liam From sundararajan.athijegannathan at oracle.com Wed Jan 9 13:39:21 2019 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 09 Jan 2019 19:09:21 +0530 Subject: RFR - JDK-8215681 Remove compiler support for Raw String Literals from JDK 12 In-Reply-To: <159F1366-BF51-4E69-A629-70176C5CD178@oracle.com> References: <1768A8D0-A8DE-477D-910A-1902E5D92F97@oracle.com> <159F1366-BF51-4E69-A629-70176C5CD178@oracle.com> Message-ID: <5C35F989.70800@oracle.com> Looks good -Sundar On 09/01/19, 6:39 PM, Jim Laskey wrote: > Could I get one or two more reviewers please? > > Thank you > > ? Jim > > >> On Dec 20, 2018, at 9:20 AM, Jim Laskey > > wrote: >> >> With the withdrawal of JEP 326: Raw String Literals (Preview) from >> JDK 12, code introduced into javac to support the specification must >> be removed. >> >> webrev: http://cr.openjdk.java.net/~jlaskey/8215681/webrev/index.html >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8215681 >> >> Thank you. >> >> Cheers, >> >> ? Jim >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8215682 >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Wed Jan 9 13:29:14 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 9 Jan 2019 08:29:14 -0500 Subject: Backporting JDK-8210483 to Java 11 In-Reply-To: References: Message-ID: Hi, I don't think there is any plan to backport it to 11, Thanks, Vicente On 1/9/19 3:40 AM, Mattias Nordin Kettil wrote: > Hello! > > I have searched the bug pages and mailing list archives for this, but > I can't find any information about a potential backport of > the?JDK-8210483 fix to Java 11. Will it be included in Java 11, and if > so, is it possible to say when? > > Best regards, > Mattias Nordin Kettil From joe.darcy at oracle.com Wed Jan 9 16:45:50 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 9 Jan 2019 08:45:50 -0800 Subject: JDK 13 RFR of 8216404: Elements.getPackageOf should handle modules Message-ID: Hello, Please review the changes and CSR for ??? 8216404: Elements.getPackageOf should handle modules ??? http://cr.openjdk.java.net/~darcy/8216404.0/ ??? https://bugs.openjdk.java.net/browse/JDK-8216429 In summary, the method Elements.getPackageOf was not updated to specify how modules should be handled. The javac implementation currently throws an NPE in that case. The fix is to add a check for that situation in the javac implementation of the Elements interface. This could also be added at the Symbol level, but adding it to Elements seemed a more direct approach. Thanks, -Joe From cushon at google.com Wed Jan 9 16:50:00 2019 From: cushon at google.com (Liam Miller-Cushon) Date: Wed, 9 Jan 2019 08:50:00 -0800 Subject: RFR: 8216403: Allocate fewer EnumSets in JavacFileManager#list In-Reply-To: References: Message-ID: On Wed, Jan 9, 2019 at 1:42 AM Claes Redestad wrote: > not really a langtools reviewer, but I generally avoid using raw > static EnumSets due their mutable nature (not saying there's a bug > here - just that we should consider all possible futures and treat them > kindly). > > Set.of() / Set.of(FOLLOW_LINKS) is a compact, performant and safer > alternative. > Done, thanks: http://cr.openjdk.java.net/~cushon/8216403/webrev.01/ (I also gave 'sourceOrClass' the same treatment.) I used EnumSet initially because it usually performs better than general-purpose sets, but I suppose it doesn't have much of an advantage over Set.of for a one-element set. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronshapiro at google.com Wed Jan 9 16:57:06 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Wed, 9 Jan 2019 11:57:06 -0500 Subject: RFR: 8216403: Allocate fewer EnumSets in JavacFileManager#list In-Reply-To: References: Message-ID: Should SOURCE_OR_CLASS be static also? On Wed, Jan 9, 2019 at 11:50 AM Liam Miller-Cushon wrote: > On Wed, Jan 9, 2019 at 1:42 AM Claes Redestad > wrote: > >> not really a langtools reviewer, but I generally avoid using raw >> static EnumSets due their mutable nature (not saying there's a bug >> here - just that we should consider all possible futures and treat them >> kindly). >> >> Set.of() / Set.of(FOLLOW_LINKS) is a compact, performant and safer >> alternative. >> > > Done, thanks: http://cr.openjdk.java.net/~cushon/8216403/webrev.01/ (I > also gave 'sourceOrClass' the same treatment.) > > I used EnumSet initially because it usually performs better than > general-purpose sets, but I suppose it doesn't have much of an advantage > over Set.of for a one-element set. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From claes.redestad at oracle.com Wed Jan 9 17:04:50 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 9 Jan 2019 18:04:50 +0100 Subject: RFR: 8216403: Allocate fewer EnumSets in JavacFileManager#list In-Reply-To: References: Message-ID: On 2019-01-09 17:50, Liam Miller-Cushon wrote: > On Wed, Jan 9, 2019 at 1:42 AM Claes Redestad > wrote: > > not really a langtools reviewer, but I generally avoid using raw > static EnumSets due their mutable nature (not saying there's a bug > here - just that we should consider all possible futures and treat them > kindly). > > Set.of() / Set.of(FOLLOW_LINKS) is a compact, performant and safer > alternative. > > > Done, thanks: http://cr.openjdk.java.net/~cushon/8216403/webrev.01/?(I > also gave 'sourceOrClass' the same treatment.) Looks good! > I used EnumSet initially because it usually performs better than > general-purpose sets, but I suppose it doesn't have much of an advantage > over Set.of for a one-element set. Right, EnumSet is hard to beat in the general case, but the Set/List.of implementations with 0-2 elements should behave similarly on artificial microbenchmarks. As an added bonus their immutability (and @Stable:ness) means they will be amenable to constant folding by the JIT. Thanks! /Claes From cushon at google.com Wed Jan 9 17:17:25 2019 From: cushon at google.com (Liam Miller-Cushon) Date: Wed, 9 Jan 2019 09:17:25 -0800 Subject: RFR: 8216403: Allocate fewer EnumSets in JavacFileManager#list In-Reply-To: References: Message-ID: On Wed, Jan 9, 2019 at 8:57 AM Ron Shapiro wrote: > Should SOURCE_OR_CLASS be static also? > I think so, thanks. http://cr.openjdk.java.net/~cushon/8216403/webrev.02 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Thu Jan 10 04:44:15 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 9 Jan 2019 23:44:15 -0500 Subject: RFR: 8216403: Allocate fewer EnumSets in JavacFileManager#list In-Reply-To: References: Message-ID: looks good, Vicente On 1/9/19 12:17 PM, Liam Miller-Cushon wrote: > On Wed, Jan 9, 2019 at 8:57 AM Ron Shapiro > wrote: > > Should?SOURCE_OR_CLASS be static also? > > > I think so, thanks. > > http://cr.openjdk.java.net/~cushon/8216403/webrev.02 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Thu Jan 10 15:19:41 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 10 Jan 2019 16:19:41 +0100 Subject: JDK 13 RFR of 8216335: Minor cleanups to javax.annotation.processing and javax.lang.model javadoc In-Reply-To: <1d4a87a8-7664-9062-7662-6e5e773f7982@oracle.com> References: <1d4a87a8-7664-9062-7662-6e5e773f7982@oracle.com> Message-ID: <5C37628D.2040107@oracle.com> Looks OK to me except for: > - * href="http://www.ietf.org/rfc/rfc3986.txt">RFC 3986, section > + * href="http://www.ietf.org/html/rfc3986.txt">RFC 3986, section The new link does not seem to work for me. Jan On 8.1.2019 07:43, Joe Darcy wrote: > Hello, > > A pass over the javax.annotation.processing and javax.lang.model specs > revealed various areas for improvement. > > Please review the fixes to address those issues in the webrev and the > corresponding patch below: > > http://cr.openjdk.java.net/~darcy/8216335.0/ > > Thanks, > > -Joe > > --- old/src/java.compiler/share/classes/javax/annotation/processing/AbstractProcessor.java 2019-01-07 22:32:32.960000000 -0800 > +++ new/src/java.compiler/share/classes/javax/annotation/processing/AbstractProcessor.java 2019-01-07 22:32:32.756000000 -0800 > @@ -92,10 +92,10 @@ > * same set of strings as the annotation. If the class is not so > * annotated, an empty set is returned. > * > - * If the {@link ProcessingEnvironment#getSourceVersion source > + * If the {@linkplain ProcessingEnvironment#getSourceVersion source > * version} does not support modules, in other words if it is less > * than or equal to {@link SourceVersion#RELEASE_8 RELEASE_8}, > - * then any leading {@link Processor#getSupportedAnnotationTypes > + * then any leading {@linkplain Processor#getSupportedAnnotationTypes > * module prefixes} are stripped from the names. > * > * @return the names of the annotation types supported by this > --- old/src/java.compiler/share/classes/javax/annotation/processing/Filer.java 2019-01-07 22:32:33.376000000 -0800 > +++ new/src/java.compiler/share/classes/javax/annotation/processing/Filer.java 2019-01-07 22:32:33.180000000 -0800 > @@ -60,7 +60,7 @@ > * by {@code '/'}; {@code '.'} and {@code '..'} are invalid path > * segments. A valid relative name must match the > * "path-rootless" rule of - * href="http://www.ietf.org/rfc/rfc3986.txt">RFC 3986, section > + * href="http://www.ietf.org/html/rfc3986.txt">RFC 3986, section > * 3.3. > * > *

    The file creation methods take a variable number of arguments to > --- old/src/java.compiler/share/classes/javax/annotation/processing/Processor.java 2019-01-07 22:32:33.940000000 -0800 > +++ new/src/java.compiler/share/classes/javax/annotation/processing/Processor.java 2019-01-07 22:32:33.748000000 -0800 > @@ -59,7 +59,7 @@ > * constructor of the processor class. > * > *

  • Next, the tool calls the {@link #init init} method with > - * an appropriate {@code ProcessingEnvironment}. > + * an appropriate {@link ProcessingEnvironment}. > * > *
  • Afterwards, the tool calls {@link #getSupportedAnnotationTypes > * getSupportedAnnotationTypes}, {@link #getSupportedOptions > --- old/src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java 2019-01-07 22:32:34.520000000 -0800 > +++ new/src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java 2019-01-07 22:32:34.328000000 -0800 > @@ -317,7 +317,7 @@ > > /** > * Returns the specific modules to which the package is being exported, > - * or null, if the package is exported to all modules which > + * or {@code null}, if the package is exported to all modules which > * have readability to this module. > * @return the specific modules to which the package is being exported > */ > @@ -339,7 +339,7 @@ > > /** > * Returns the specific modules to which the package is being open > - * or null, if the package is open all modules which > + * or {@code null}, if the package is open all modules which > * have readability to this module. > * @return the specific modules to which the package is being opened > */ > --- old/src/java.compiler/share/classes/javax/lang/model/util/Elements.java 2019-01-07 22:32:34.928000000 -0800 > +++ new/src/java.compiler/share/classes/javax/lang/model/util/Elements.java 2019-01-07 22:32:34.732000000 -0800 > @@ -511,6 +511,7 @@ > * @param hidden the second element > * @return {@code true} if and only if the first element hides > * the second > + * @jls 8.4.8 Inheritance, Overriding, and Hiding > */ > boolean hides(Element hider, Element hidden); > > From jan.lahoda at oracle.com Thu Jan 10 15:25:13 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 10 Jan 2019 16:25:13 +0100 Subject: JDK 13 RFR of 8216404: Elements.getPackageOf should handle modules In-Reply-To: References: Message-ID: <5C3763D9.2040603@oracle.com> Looks good to me. Jan On 9.1.2019 17:45, Joe Darcy wrote: > Hello, > > Please review the changes and CSR for > > 8216404: Elements.getPackageOf should handle modules > http://cr.openjdk.java.net/~darcy/8216404.0/ > https://bugs.openjdk.java.net/browse/JDK-8216429 > > In summary, the method Elements.getPackageOf was not updated to specify > how modules should be handled. The javac implementation currently throws > an NPE in that case. > > The fix is to add a check for that situation in the javac implementation > of the Elements interface. This could also be added at the Symbol level, > but adding it to Elements seemed a more direct approach. > > Thanks, > > -Joe > From eolivelli at gmail.com Thu Jan 10 19:13:02 2019 From: eolivelli at gmail.com (Enrico Olivelli) Date: Thu, 10 Jan 2019 20:13:02 +0100 Subject: spotBugs and JDK-8194978: Javac produces dead code for try-with-resource In-Reply-To: References: <25e5d853-e4d4-41aa-8221-00462389fc67@oracle.com> <5BE60326.4090202@oracle.com> Message-ID: Kindly pinging on this.. Cheers Enrico Il lun 7 gen 2019, 14:28 Enrico Olivelli ha scritto: > Two questions/ideas: > 1) Wouldn't it be possible for javac to annotate such code blocks and > write into the class file that that code is "synthetic" ? I really > don't know where to store such flags, but maybe someone could > elaborate more this idea > 2) Why isn't javac adding the "$closeResource" method ? > > Enrico > > Il giorno ven 9 nov 2018 alle ore 23:01 Alex Buckley > ha scritto: > > > > On 11/9/2018 12:31 PM, Vicente Romero wrote: > > > My evaluation on this issue is that javac is generating code > > > according to the spec, see JLS11 14.20.3.1 [1]. There is an explicit > > > check for null on the resource before invoking the close() method. > > > This is the null check javac is generating. > > > > I confirm that the explicit null check on the resource variable is > > required, per the translation in > > > https://docs.oracle.com/javase/specs/jls/se11/html/jls-14.html#jls-14.20.3.1-140 > > -- it has been specified that way since JLS7. > > > > > Fix for JDK-8194978 went a bit further trying to eliminate dead code > > > for some cases for which javac could statically determine that the > > > resource would be different from null. In particular if the resource > > > was initialized with a new class expression. > > > > I confirm it's acceptable to not perform the null check in generated > > code if you can prove the resource variable is non-null. Frankly, > > though, there is so much that can occur in a "new class expression" -- > > `new Outer(a(b(c)))<>.new Inner(d(e(f)))` -- that I would be > > wary of trying to prove anything. > > > > > It could be argued that we could try to analyze the body and if we > > > find out that a NPE must be thrown in the body of the try, then the > > > null check on the resource would be deemed unnecessary. But then we > > > can get to an implementation that will be out of sync with the spec > > > plus it probably won't cover all cases. > > > > Right, let's not be too clever. > > > > Alex > > > > > Thanks, > > > Vicente > > > > > > [1] > > > > https://docs.oracle.com/javase/specs/jls/se11/html/jls-14.html#jls-14.20.3.1 > > > > > > On 11/9/18 10:22 AM, Ismael Juma wrote: > > >> Any comments on this? Many people are disabling spotBugs when > > >> compiling with Java 11 due to this issue: > > >> > > >> https://github.com/spotbugs/spotbugs/issues/756 > > >> > > >> Ismael > > >> > > >> On Thu, Sep 13, 2018 at 10:05 PM Ismael Juma > >> > wrote: > > >> > > >> Hi all, > > >> > > >> JDK-8194978 introduced some changes to the bytecode generated by > > >> javac for the try with resource construct. In the following code, > > >> it seems to generate a null check on a reference after invoking a > > >> method on it: > > >> > > >> public static void readFileAsString(String path) throws > > >> IOException { > > >> try (FileChannel fc = FileChannel.open(Paths.get(path))) { > > >> fc.size(); > > >> } > > >> > > >> } > > >> > > >> In line 16 to 22 of the bytecode, it looks like we check for null > > >> after calling a method on the fc reference: > > >> > > >> 16: aload_1 > > >> 17: invokevirtual #6 // Method > > >> java/nio/channels/FileChannel.size:()J > > >> 20: pop2 > > >> 21: aload_1 > > >> 22: ifnull 52 > > >> 25: aload_1 > > >> 26: invokevirtual #7 // Method > > >> java/nio/channels/FileChannel.close:()V > > >> > > >> Is this intentional? I ask because this pattern triggers a > > >> spotBugs warning since it often implies a bug in user's code: > > >> > > >> RCN | Nullcheck of fc at line 10 of value previously dereferenced > > >> in TryTest.readFileAsString(String, Charset) > > >> > > >> Note that this works fine in Java versions older than Java 11. > > >> Since this spotBugs warning is generally useful, it would be handy > > >> if javac did not trigger it. Alternatively, if there's a good way > > >> to detect the code that was generated by javac, spotBugs could be > > >> updated to ignore it. For reference, this was discussed in the > > >> spotBugs issue tracker: > > >> > > >> https://github.com/spotbugs/spotbugs/issues/756 > > >> > > >> And method bytecode in full: > > >> > > >> public static void readFileAsString(java.lang.String) throws > > >> java.io.IOException; > > >> Code: > > >> 0: aload_0 > > >> 1: iconst_0 > > >> 2: anewarray #2 // class > java/lang/String > > >> 5: invokestatic #3 // Method > > >> > java/nio/file/Paths.get:(Ljava/lang/String;[Ljava/lang/String;)Ljava/nio/file/Path; > > >> 8: iconst_0 > > >> 9: anewarray #4 // class > > >> java/nio/file/OpenOption > > >> 12: invokestatic #5 // Method > > >> > java/nio/channels/FileChannel.open:(Ljava/nio/file/Path;[Ljava/nio/file/OpenOption;)Ljava/nio/channels/FileChannel; > > >> 15: astore_1 > > >> 16: aload_1 > > >> 17: invokevirtual #6 // Method > > >> java/nio/channels/FileChannel.size:()J > > >> 20: pop2 > > >> 21: aload_1 > > >> 22: ifnull 52 > > >> 25: aload_1 > > >> 26: invokevirtual #7 // Method > > >> java/nio/channels/FileChannel.close:()V > > >> 29: goto 52 > > >> 32: astore_2 > > >> 33: aload_1 > > >> 34: ifnull 50 > > >> 37: aload_1 > > >> 38: invokevirtual #7 // Method > > >> java/nio/channels/FileChannel.close:()V > > >> 41: goto 50 > > >> 44: astore_3 > > >> 45: aload_2 > > >> 46: aload_3 > > >> 47: invokevirtual #9 // Method > > >> java/lang/Throwable.addSuppressed:(Ljava/lang/Throwable;)V > > >> 50: aload_2 > > >> 51: athrow > > >> 52: return > > >> Exception table: > > >> from to target type > > >> 16 21 32 Class java/lang/Throwable > > >> 37 41 44 Class java/lang/Throwable > > >> > > >> Thanks, > > >> Ismael > > >> > > > > -- -- Enrico Olivelli -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Thu Jan 10 22:51:07 2019 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 10 Jan 2019 14:51:07 -0800 Subject: JDK 13 RFR of JDK-8208371: Provided supported mechanims to create a ModuleElement for an unnamed module Message-ID: <5C37CC5B.608@oracle.com> Hello, Please review the change and CSR to implement JDK-8208371: Provided supported mechanims to create a ModuleElement for an unnamed module webrev: http://cr.openjdk.java.net/~darcy/8208371.0/ CSR: https://bugs.openjdk.java.net/browse/JDK-8216527 Patch below. Thanks, -Joe --- old/src/java.compiler/share/classes/javax/lang/model/util/Elements.java 2019-01-10 14:40:14.594256000 -0800 +++ new/src/java.compiler/share/classes/javax/lang/model/util/Elements.java 2019-01-10 14:40:14.342130000 -0800 @@ -189,7 +189,7 @@ /** * Returns a module element given its fully qualified name. * - * If the named module cannot be found, {@code null} is + * If the requested module cannot be found, {@code null} is * returned. One situation where a module cannot be found is if * the environment does not include modules, such as an annotation * processing environment configured for a {@linkplain @@ -199,7 +199,7 @@ * @implSpec The default implementation of this method returns * {@code null}. * - * @param name the name + * @param name the name, or an empty string for an unnamed module * @return the named module element, or {@code null} if it cannot be found * @see #getAllModuleElements * @since 9 --- old/test/langtools/tools/javac/processing/model/element/TestModuleElementNames.java 2019-01-10 14:40:15.174546001 -0800 +++ new/test/langtools/tools/javac/processing/model/element/TestModuleElementNames.java 2019-01-10 14:40:14.918418000 -0800 @@ -23,7 +23,7 @@ /* * @test - * @bug 8163989 + * @bug 8163989 8208371 * @summary Test basic workings of naming methods on ModuleElement * @library /tools/javac/lib * @modules java.compiler From joe.darcy at oracle.com Fri Jan 11 00:02:40 2019 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 10 Jan 2019 16:02:40 -0800 Subject: JDK 13 RFR of 8216335: Minor cleanups to javax.annotation.processing and javax.lang.model javadoc In-Reply-To: <5C37628D.2040107@oracle.com> References: <1d4a87a8-7664-9062-7662-6e5e773f7982@oracle.com> <5C37628D.2040107@oracle.com> Message-ID: <5C37DD20.1070806@oracle.com> Hi Jan, Thanks for checking; that URL doesn't seem to work now for me either. I'll file a follow-up issue to change it to https://www.rfc-editor.org/info/rfc3986 which will hopefully be stable going forward. Cheers, -Joe On 1/10/2019 7:19 AM, Jan Lahoda wrote: > Looks OK to me except for: > > - * href="http://www.ietf.org/rfc/rfc3986.txt">RFC 3986, section > > + * href="http://www.ietf.org/html/rfc3986.txt">RFC 3986, section > > The new link does not seem to work for me. > > Jan > > On 8.1.2019 07:43, Joe Darcy wrote: >> Hello, >> >> A pass over the javax.annotation.processing and javax.lang.model specs >> revealed various areas for improvement. >> >> Please review the fixes to address those issues in the webrev and the >> corresponding patch below: >> >> http://cr.openjdk.java.net/~darcy/8216335.0/ >> >> Thanks, >> >> -Joe >> >> --- >> old/src/java.compiler/share/classes/javax/annotation/processing/AbstractProcessor.java >> 2019-01-07 22:32:32.960000000 -0800 >> +++ >> new/src/java.compiler/share/classes/javax/annotation/processing/AbstractProcessor.java >> 2019-01-07 22:32:32.756000000 -0800 >> @@ -92,10 +92,10 @@ >> * same set of strings as the annotation. If the class is not so >> * annotated, an empty set is returned. >> * >> - * If the {@link ProcessingEnvironment#getSourceVersion source >> + * If the {@linkplain ProcessingEnvironment#getSourceVersion source >> * version} does not support modules, in other words if it is less >> * than or equal to {@link SourceVersion#RELEASE_8 RELEASE_8}, >> - * then any leading {@link Processor#getSupportedAnnotationTypes >> + * then any leading {@linkplain >> Processor#getSupportedAnnotationTypes >> * module prefixes} are stripped from the names. >> * >> * @return the names of the annotation types supported by this >> --- >> old/src/java.compiler/share/classes/javax/annotation/processing/Filer.java >> 2019-01-07 22:32:33.376000000 -0800 >> +++ >> new/src/java.compiler/share/classes/javax/annotation/processing/Filer.java >> 2019-01-07 22:32:33.180000000 -0800 >> @@ -60,7 +60,7 @@ >> * by {@code '/'}; {@code '.'} and {@code '..'} are invalid path >> * segments. A valid relative name must match the >> * "path-rootless" rule of > - * href="http://www.ietf.org/rfc/rfc3986.txt">RFC 3986, section >> + * href="http://www.ietf.org/html/rfc3986.txt">RFC 3986, section >> * 3.3. >> * >> *

    The file creation methods take a variable number of arguments to >> --- >> old/src/java.compiler/share/classes/javax/annotation/processing/Processor.java >> 2019-01-07 22:32:33.940000000 -0800 >> +++ >> new/src/java.compiler/share/classes/javax/annotation/processing/Processor.java >> 2019-01-07 22:32:33.748000000 -0800 >> @@ -59,7 +59,7 @@ >> * constructor of the processor class. >> * >> *

  • Next, the tool calls the {@link #init init} method with >> - * an appropriate {@code ProcessingEnvironment}. >> + * an appropriate {@link ProcessingEnvironment}. >> * >> *
  • Afterwards, the tool calls {@link #getSupportedAnnotationTypes >> * getSupportedAnnotationTypes}, {@link #getSupportedOptions >> --- >> old/src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java >> 2019-01-07 22:32:34.520000000 -0800 >> +++ >> new/src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java >> 2019-01-07 22:32:34.328000000 -0800 >> @@ -317,7 +317,7 @@ >> >> /** >> * Returns the specific modules to which the package is >> being exported, >> - * or null, if the package is exported to all modules which >> + * or {@code null}, if the package is exported to all >> modules which >> * have readability to this module. >> * @return the specific modules to which the package is >> being exported >> */ >> @@ -339,7 +339,7 @@ >> >> /** >> * Returns the specific modules to which the package is >> being open >> - * or null, if the package is open all modules which >> + * or {@code null}, if the package is open all modules which >> * have readability to this module. >> * @return the specific modules to which the package is >> being opened >> */ >> --- >> old/src/java.compiler/share/classes/javax/lang/model/util/Elements.java >> 2019-01-07 22:32:34.928000000 -0800 >> +++ >> new/src/java.compiler/share/classes/javax/lang/model/util/Elements.java >> 2019-01-07 22:32:34.732000000 -0800 >> @@ -511,6 +511,7 @@ >> * @param hidden the second element >> * @return {@code true} if and only if the first element hides >> * the second >> + * @jls 8.4.8 Inheritance, Overriding, and Hiding >> */ >> boolean hides(Element hider, Element hidden); >> >> From jonathan.gibbons at oracle.com Fri Jan 11 00:24:23 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 10 Jan 2019 16:24:23 -0800 Subject: JDK 13 RFR of 8216335: Minor cleanups to javax.annotation.processing and javax.lang.model javadoc In-Reply-To: <5C37DD20.1070806@oracle.com> References: <1d4a87a8-7664-9062-7662-6e5e773f7982@oracle.com> <5C37628D.2040107@oracle.com> <5C37DD20.1070806@oracle.com> Message-ID: <97f68381-cfeb-4bea-f73e-a8d9582176b8@oracle.com> What was wrong with href="http://www.ietf.org/rfc/rfc3986.txt">RFC 3986 ? Note there are lots of references to ietf.org rfc docs in our API docs; it would be nice if they were consistent. See the list reported by doccheck, about half-way down this page: http://cr.openjdk.java.net/~jjg/doccheck/11/jdk-all/report.html -- Jon On 01/10/2019 04:02 PM, Joseph D. Darcy wrote: > Hi Jan, > > Thanks for checking; that URL doesn't seem to work now for me either. > > I'll file a follow-up issue to change it to > > ??? https://www.rfc-editor.org/info/rfc3986 > > which will hopefully be stable going forward. > > Cheers, > > -Joe > > On 1/10/2019 7:19 AM, Jan Lahoda wrote: >> Looks OK to me except for: >> > - * href="http://www.ietf.org/rfc/rfc3986.txt">RFC 3986, section >> > + * href="http://www.ietf.org/html/rfc3986.txt">RFC 3986, section >> >> The new link does not seem to work for me. >> >> Jan >> >> On 8.1.2019 07:43, Joe Darcy wrote: >>> Hello, >>> >>> A pass over the javax.annotation.processing and javax.lang.model specs >>> revealed various areas for improvement. >>> >>> Please review the fixes to address those issues in the webrev and the >>> corresponding patch below: >>> >>> http://cr.openjdk.java.net/~darcy/8216335.0/ >>> >>> Thanks, >>> >>> -Joe >>> >>> --- >>> old/src/java.compiler/share/classes/javax/annotation/processing/AbstractProcessor.java >>> 2019-01-07 22:32:32.960000000 -0800 >>> +++ >>> new/src/java.compiler/share/classes/javax/annotation/processing/AbstractProcessor.java >>> 2019-01-07 22:32:32.756000000 -0800 >>> @@ -92,10 +92,10 @@ >>> ?????? * same set of strings as the annotation.? If the class is not so >>> ?????? * annotated, an empty set is returned. >>> ?????? * >>> -???? * If the {@link ProcessingEnvironment#getSourceVersion source >>> +???? * If the {@linkplain ProcessingEnvironment#getSourceVersion >>> source >>> ?????? * version} does not support modules, in other words if it is >>> less >>> ?????? * than or equal to {@link SourceVersion#RELEASE_8 RELEASE_8}, >>> -???? * then any leading {@link Processor#getSupportedAnnotationTypes >>> +???? * then any leading {@linkplain >>> Processor#getSupportedAnnotationTypes >>> ?????? * module prefixes} are stripped from the names. >>> ?????? * >>> ?????? * @return the names of the annotation types supported by this >>> --- >>> old/src/java.compiler/share/classes/javax/annotation/processing/Filer.java >>> 2019-01-07 22:32:33.376000000 -0800 >>> +++ >>> new/src/java.compiler/share/classes/javax/annotation/processing/Filer.java >>> 2019-01-07 22:32:33.180000000 -0800 >>> @@ -60,7 +60,7 @@ >>> ?? * by {@code '/'}; {@code '.'} and {@code '..'} are invalid path >>> ?? * segments.? A valid relative name must match the >>> ?? * "path-rootless" rule of >> - * href="http://www.ietf.org/rfc/rfc3986.txt">RFC 3986, section >>> + * href="http://www.ietf.org/html/rfc3986.txt">RFC 3986, section >>> ?? * 3.3. >>> ?? * >>> ?? *

    The file creation methods take a variable number of >>> arguments to >>> --- >>> old/src/java.compiler/share/classes/javax/annotation/processing/Processor.java >>> 2019-01-07 22:32:33.940000000 -0800 >>> +++ >>> new/src/java.compiler/share/classes/javax/annotation/processing/Processor.java >>> 2019-01-07 22:32:33.748000000 -0800 >>> @@ -59,7 +59,7 @@ >>> ?? * constructor of the processor class. >>> ?? * >>> ?? *

  • Next, the tool calls the {@link #init init} method with >>> - * an appropriate {@code ProcessingEnvironment}. >>> + * an appropriate {@link ProcessingEnvironment}. >>> ?? * >>> ?? *
  • Afterwards, the tool calls {@link #getSupportedAnnotationTypes >>> ?? * getSupportedAnnotationTypes}, {@link #getSupportedOptions >>> --- >>> old/src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java >>> 2019-01-07 22:32:34.520000000 -0800 >>> +++ >>> new/src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java >>> 2019-01-07 22:32:34.328000000 -0800 >>> @@ -317,7 +317,7 @@ >>> >>> ????????? /** >>> ?????????? * Returns the specific modules to which the package is >>> being exported, >>> -???????? * or null, if the package is exported to all modules which >>> +???????? * or {@code null}, if the package is exported to all >>> modules which >>> ?????????? * have readability to this module. >>> ?????????? * @return the specific modules to which the package is >>> being exported >>> ?????????? */ >>> @@ -339,7 +339,7 @@ >>> >>> ????????? /** >>> ?????????? * Returns the specific modules to which the package is >>> being open >>> -???????? * or null, if the package is open all modules which >>> +???????? * or {@code null}, if the package is open all modules which >>> ?????????? * have readability to this module. >>> ?????????? * @return the specific modules to which the package is >>> being opened >>> ?????????? */ >>> --- >>> old/src/java.compiler/share/classes/javax/lang/model/util/Elements.java >>> 2019-01-07 22:32:34.928000000 -0800 >>> +++ >>> new/src/java.compiler/share/classes/javax/lang/model/util/Elements.java >>> 2019-01-07 22:32:34.732000000 -0800 >>> @@ -511,6 +511,7 @@ >>> ?????? * @param hidden? the second element >>> ?????? * @return {@code true} if and only if the first element hides >>> ?????? *????????? the second >>> +???? * @jls 8.4.8 Inheritance, Overriding, and Hiding >>> ?????? */ >>> ????? boolean hides(Element hider, Element hidden); >>> >>> > From vicente.romero at oracle.com Fri Jan 11 16:47:26 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 11 Jan 2019 11:47:26 -0500 Subject: RFR: JDK-8215482: check for cycles in type variables can provoke NPE Message-ID: <74c7978f-034b-2d2c-0e6d-adad2a14a496@oracle.com> Please review the fix for [1] at [2]. The NPE showed up in code like: class Outer { ??? class Inner {} } here attribution of type variable `A` during type enter phase will trigger attribution of class `Inner` while type variable `B` hasn't been attributed yet and thus its bound is still set to null. A similar problem arose a while ago see [3]. The issue provoking the current bug is that checks for cycles in type variables are done as soon as the type variable is attributed but in cases like the one above we can't do that until the type variable for the outer class has been attributed too. My first try was to create a fixup table that maps the outer type to the list of type variables defined by it or its members that happen to be types too, and once the compiler finish entering the outer class it would be safe to check for cycles in all the concerning type variables. I had a mild success here as there were some trivial cases that were working before that started failing. I realized that it was because the annotation processing phase was setting all the types to null, no bueno. So I decided to clone the type variables to be stored in the fixup table and do the cycle check on the clones which is what the current patch is doing. Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8215482 [2] http://cr.openjdk.java.net/~vromero/8215482/ [3] https://bugs.openjdk.java.net/browse/JDK-6660289 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Fri Jan 11 16:53:55 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 11 Jan 2019 08:53:55 -0800 Subject: JDK 13 RFR of JDK-8208371: Provided supported mechanims to create a ModuleElement for an unnamed module In-Reply-To: <5C37CC5B.608@oracle.com> References: <5C37CC5B.608@oracle.com> Message-ID: <7fb40126-9c35-ff84-ef0c-e01f4d9a153f@oracle.com> +1 On 1/10/19 2:51 PM, Joseph D. Darcy wrote: > Hello, > > Please review the change and CSR to implement > > ??? JDK-8208371: Provided supported mechanims to create a > ModuleElement for an unnamed module > ??? webrev:? http://cr.openjdk.java.net/~darcy/8208371.0/ > ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8216527 > > Patch below. > > Thanks, > > -Joe > > --- > old/src/java.compiler/share/classes/javax/lang/model/util/Elements.java > 2019-01-10 14:40:14.594256000 -0800 > +++ > new/src/java.compiler/share/classes/javax/lang/model/util/Elements.java > 2019-01-10 14:40:14.342130000 -0800 > @@ -189,7 +189,7 @@ > ???? /** > ????? * Returns a module element given its fully qualified name. > ????? * > -???? * If the named module cannot be found, {@code null} is > +???? * If the requested module cannot be found, {@code null} is > ????? * returned. One situation where a module cannot be found is if > ????? * the environment does not include modules, such as an annotation > ????? * processing environment configured for a {@linkplain > @@ -199,7 +199,7 @@ > ????? * @implSpec The default implementation of this method returns > ????? * {@code null}. > ????? * > -???? * @param name? the name > +???? * @param name? the name, or an empty string for an unnamed module > ????? * @return the named module element, or {@code null} if it cannot > be found > ????? * @see #getAllModuleElements > ????? * @since 9 > --- > old/test/langtools/tools/javac/processing/model/element/TestModuleElementNames.java > 2019-01-10 14:40:15.174546001 -0800 > +++ > new/test/langtools/tools/javac/processing/model/element/TestModuleElementNames.java > 2019-01-10 14:40:14.918418000 -0800 > @@ -23,7 +23,7 @@ > > ?/* > ? * @test > - * @bug 8163989 > + * @bug 8163989 8208371 > ? * @summary Test basic workings of naming methods on ModuleElement > ? * @library /tools/javac/lib > ? * @modules java.compiler > From maurizio.cimadamore at oracle.com Fri Jan 11 17:21:44 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 11 Jan 2019 17:21:44 +0000 Subject: RFR: JDK-8215482: check for cycles in type variables can provoke NPE In-Reply-To: <74c7978f-034b-2d2c-0e6d-adad2a14a496@oracle.com> References: <74c7978f-034b-2d2c-0e6d-adad2a14a496@oracle.com> Message-ID: <64c32752-879a-98b0-faab-724c2a330b1e@oracle.com> It seems that another thing that your path is doing is storing all the type vars to check keyed by outermost class, so that only when you have finished entering the outermost symbol you actually start checking all pending typevars for cycles. I guess this delay is necessary otherwise you would hit a problem anyway when checking Bc for cyclicity? Have you consider moving the attribution and cyclicity check in different type enter phases? For instance, leave attribution in HeaderPhase, but move the cycle check in MembersPhase ? Maurizio On 11/01/2019 16:47, Vicente Romero wrote: > Please review the fix for [1] at [2]. The NPE showed up in code like: > > class Outer { > ??? class Inner {} > } > > here attribution of type variable `A` during type enter phase will > trigger attribution of class `Inner` while type variable `B` hasn't > been attributed yet and thus its bound is still set to null. A similar > problem arose a while ago see [3]. The issue provoking the current bug > is that checks for cycles in type variables are done as soon as the > type variable is attributed but in cases like the one above we can't > do that until the type variable for the outer class has been > attributed too. > > My first try was to create a fixup table that maps the outer type to > the list of type variables defined by it or its members that happen to > be types too, and once the compiler finish entering the outer class it > would be safe to check for cycles in all the concerning type > variables. I had a mild success here as there were some trivial cases > that were working before that started failing. I realized that it was > because the annotation processing phase was setting all the types to > null, no bueno. So I decided to clone the type variables to be stored > in the fixup table and do the cycle check on the clones which is what > the current patch is doing. > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8215482 > [2] http://cr.openjdk.java.net/~vromero/8215482/ > [3] https://bugs.openjdk.java.net/browse/JDK-6660289 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Fri Jan 11 17:29:55 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 11 Jan 2019 12:29:55 -0500 Subject: RFR: JDK-8215482: check for cycles in type variables can provoke NPE In-Reply-To: <64c32752-879a-98b0-faab-724c2a330b1e@oracle.com> References: <74c7978f-034b-2d2c-0e6d-adad2a14a496@oracle.com> <64c32752-879a-98b0-faab-724c2a330b1e@oracle.com> Message-ID: On 1/11/19 12:21 PM, Maurizio Cimadamore wrote: > > It seems that another thing that your path is doing is storing all the > type vars to check keyed by outermost class, so that only when you > have finished entering the outermost symbol you actually start > checking all pending typevars for cycles. I guess this delay is > necessary otherwise you would hit a problem anyway when checking Bc > for cyclicity? > correct > Have you consider moving the attribution and cyclicity check in > different type enter phases? For instance, leave attribution in > HeaderPhase, but move the cycle check in MembersPhase ? > I didn't try, but why would this be preferable? also as annotation processing can nuke the type we would have to make sure that the types are there before doing the cycle check which is something we can guarantee now by keeping the check for cycles in the Header phase > Maurizio > Vicente > On 11/01/2019 16:47, Vicente Romero wrote: >> Please review the fix for [1] at [2]. The NPE showed up in code like: >> >> class Outer { >> ??? class Inner {} >> } >> >> here attribution of type variable `A` during type enter phase will >> trigger attribution of class `Inner` while type variable `B` hasn't >> been attributed yet and thus its bound is still set to null. A >> similar problem arose a while ago see [3]. The issue provoking the >> current bug is that checks for cycles in type variables are done as >> soon as the type variable is attributed but in cases like the one >> above we can't do that until the type variable for the outer class >> has been attributed too. >> >> My first try was to create a fixup table that maps the outer type to >> the list of type variables defined by it or its members that happen >> to be types too, and once the compiler finish entering the outer >> class it would be safe to check for cycles in all the concerning type >> variables. I had a mild success here as there were some trivial cases >> that were working before that started failing. I realized that it was >> because the annotation processing phase was setting all the types to >> null, no bueno. So I decided to clone the type variables to be stored >> in the fixup table and do the cycle check on the clones which is what >> the current patch is doing. >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8215482 >> [2] http://cr.openjdk.java.net/~vromero/8215482/ >> [3] https://bugs.openjdk.java.net/browse/JDK-6660289 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Fri Jan 11 18:05:22 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 11 Jan 2019 13:05:22 -0500 Subject: RFR: JDK-8215482: check for cycles in type variables can provoke NPE In-Reply-To: References: <74c7978f-034b-2d2c-0e6d-adad2a14a496@oracle.com> <64c32752-879a-98b0-faab-724c2a330b1e@oracle.com> Message-ID: <7056c755-9242-d5e7-c926-705610074f09@oracle.com> I have realized that cloning the type variable is not necessary as the Pair element in the table will keep a reference to the type variable Vicente On 1/11/19 12:29 PM, Vicente Romero wrote: > > > On 1/11/19 12:21 PM, Maurizio Cimadamore wrote: >> >> It seems that another thing that your path is doing is storing all >> the type vars to check keyed by outermost class, so that only when >> you have finished entering the outermost symbol you actually start >> checking all pending typevars for cycles. I guess this delay is >> necessary otherwise you would hit a problem anyway when checking Bc >> for cyclicity? >> > > correct > >> Have you consider moving the attribution and cyclicity check in >> different type enter phases? For instance, leave attribution in >> HeaderPhase, but move the cycle check in MembersPhase ? >> > > I didn't try, but why would this be preferable? also as annotation > processing can nuke the type we would have to make sure that the types > are there before doing the cycle check which is something we can > guarantee now by keeping the check for cycles in the Header phase > >> Maurizio >> > > Vicente > >> On 11/01/2019 16:47, Vicente Romero wrote: >>> Please review the fix for [1] at [2]. The NPE showed up in code like: >>> >>> class Outer { >>> ??? class Inner {} >>> } >>> >>> here attribution of type variable `A` during type enter phase will >>> trigger attribution of class `Inner` while type variable `B` hasn't >>> been attributed yet and thus its bound is still set to null. A >>> similar problem arose a while ago see [3]. The issue provoking the >>> current bug is that checks for cycles in type variables are done as >>> soon as the type variable is attributed but in cases like the one >>> above we can't do that until the type variable for the outer class >>> has been attributed too. >>> >>> My first try was to create a fixup table that maps the outer type to >>> the list of type variables defined by it or its members that happen >>> to be types too, and once the compiler finish entering the outer >>> class it would be safe to check for cycles in all the concerning >>> type variables. I had a mild success here as there were some trivial >>> cases that were working before that started failing. I realized that >>> it was because the annotation processing phase was setting all the >>> types to null, no bueno. So I decided to clone the type variables to >>> be stored in the fixup table and do the cycle check on the clones >>> which is what the current patch is doing. >>> >>> Thanks, >>> Vicente >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8215482 >>> [2] http://cr.openjdk.java.net/~vromero/8215482/ >>> [3] https://bugs.openjdk.java.net/browse/JDK-6660289 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Fri Jan 11 19:13:17 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 11 Jan 2019 19:13:17 +0000 Subject: RFR: JDK-8215482: check for cycles in type variables can provoke NPE In-Reply-To: <7056c755-9242-d5e7-c926-705610074f09@oracle.com> References: <74c7978f-034b-2d2c-0e6d-adad2a14a496@oracle.com> <64c32752-879a-98b0-faab-724c2a330b1e@oracle.com> <7056c755-9242-d5e7-c926-705610074f09@oracle.com> Message-ID: <7ffb81ca-a20c-7d28-1364-397c5b30a87d@oracle.com> As per my suggestion to split into multiple stages, it was mostly a suggestion to take full advantage of the tiered architecture of TypeEnter. You are basically caching some types in a 'todo later' list, and then you are coming back at them - avoiding these kind of queuing is what the (relatively) new TypeEnter code is for. If the cyclic check is moved to a later phase, then I think you just need to fetch the type variables from the symbol/type/tree and check them; the types will be already set, no need to stash them into a map. At least in theory :-) Maurizio On 11/01/2019 18:05, Vicente Romero wrote: > I have realized that cloning the type variable is not necessary as the > Pair element in the table will keep a > reference to the type variable > > Vicente > > > On 1/11/19 12:29 PM, Vicente Romero wrote: >> >> >> On 1/11/19 12:21 PM, Maurizio Cimadamore wrote: >>> >>> It seems that another thing that your path is doing is storing all >>> the type vars to check keyed by outermost class, so that only when >>> you have finished entering the outermost symbol you actually start >>> checking all pending typevars for cycles. I guess this delay is >>> necessary otherwise you would hit a problem anyway when checking Bc >>> for cyclicity? >>> >> >> correct >> >>> Have you consider moving the attribution and cyclicity check in >>> different type enter phases? For instance, leave attribution in >>> HeaderPhase, but move the cycle check in MembersPhase ? >>> >> >> I didn't try, but why would this be preferable? also as annotation >> processing can nuke the type we would have to make sure that the >> types are there before doing the cycle check which is something we >> can guarantee now by keeping the check for cycles in the Header phase >> >>> Maurizio >>> >> >> Vicente >> >>> On 11/01/2019 16:47, Vicente Romero wrote: >>>> Please review the fix for [1] at [2]. The NPE showed up in code like: >>>> >>>> class Outer { >>>> ??? class Inner {} >>>> } >>>> >>>> here attribution of type variable `A` during type enter phase will >>>> trigger attribution of class `Inner` while type variable `B` hasn't >>>> been attributed yet and thus its bound is still set to null. A >>>> similar problem arose a while ago see [3]. The issue provoking the >>>> current bug is that checks for cycles in type variables are done as >>>> soon as the type variable is attributed but in cases like the one >>>> above we can't do that until the type variable for the outer class >>>> has been attributed too. >>>> >>>> My first try was to create a fixup table that maps the outer type >>>> to the list of type variables defined by it or its members that >>>> happen to be types too, and once the compiler finish entering the >>>> outer class it would be safe to check for cycles in all the >>>> concerning type variables. I had a mild success here as there were >>>> some trivial cases that were working before that started failing. I >>>> realized that it was because the annotation processing phase was >>>> setting all the types to null, no bueno. So I decided to clone the >>>> type variables to be stored in the fixup table and do the cycle >>>> check on the clones which is what the current patch is doing. >>>> >>>> Thanks, >>>> Vicente >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8215482 >>>> [2] http://cr.openjdk.java.net/~vromero/8215482/ >>>> [3] https://bugs.openjdk.java.net/browse/JDK-6660289 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Fri Jan 11 19:18:30 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 11 Jan 2019 11:18:30 -0800 Subject: RFR: JDK12 doc-only JDK-8210561: Command-line help wrong for javac --module Message-ID: <28f310bb-e81e-e46d-7439-9b1790f9d2f4@oracle.com> Please review a small doc-only fix in a resource file for the javac command-line help for --module. Patch is inline, here: $ hg diff diff -r fbc921683f02 src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties Fri Jan 11 13:34:57 2019 +0100 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties Fri Jan 11 11:16:54 2019 -0800 @@ -44,7 +44,7 @@ ?javac.opt.sourcepath=\ ???? Specify where to find input source files ?javac.opt.m=\ -??? Compile only the specified module, check timestamps +??? Compile only the specified module(s), check timestamps ?javac.opt.modulesourcepath=\ ???? Specify where to find input source files for multiple modules ?javac.opt.bootclasspath=\ @@ -108,7 +108,7 @@ ?javac.opt.arg.mspath=\ ???? ?javac.opt.arg.m=\ -??? +??? (,)* ?javac.opt.arg.jdk=\ ???? |none ?javac.opt.arg.dirs=\ -- Jon JBS: https://bugs.openjdk.java.net/browse/JDK-8210561 CSR:https://bugs.openjdk.java.net/browse/JDK-8216402 From joe.darcy at oracle.com Fri Jan 11 19:23:52 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 11 Jan 2019 11:23:52 -0800 Subject: RFR: JDK12 doc-only JDK-8210561: Command-line help wrong for javac --module In-Reply-To: <28f310bb-e81e-e46d-7439-9b1790f9d2f4@oracle.com> References: <28f310bb-e81e-e46d-7439-9b1790f9d2f4@oracle.com> Message-ID: <4ff2b290-fe73-24b1-6c14-013796c190d3@oracle.com> +1 -Joe On 1/11/2019 11:18 AM, Jonathan Gibbons wrote: > Please review a small doc-only fix in a resource file for the javac > command-line help for --module. > > Patch is inline, here: > > > $ hg diff > diff -r fbc921683f02 > src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties > --- > a/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties > Fri Jan 11 13:34:57 2019 +0100 > +++ > b/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties > Fri Jan 11 11:16:54 2019 -0800 > @@ -44,7 +44,7 @@ > ?javac.opt.sourcepath=\ > ???? Specify where to find input source files > ?javac.opt.m=\ > -??? Compile only the specified module, check timestamps > +??? Compile only the specified module(s), check timestamps > ?javac.opt.modulesourcepath=\ > ???? Specify where to find input source files for multiple modules > ?javac.opt.bootclasspath=\ > @@ -108,7 +108,7 @@ > ?javac.opt.arg.mspath=\ > ???? > ?javac.opt.arg.m=\ > -??? > +??? (,)* > ?javac.opt.arg.jdk=\ > ???? |none > ?javac.opt.arg.dirs=\ > > > -- Jon > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8210561 > CSR:https://bugs.openjdk.java.net/browse/JDK-8216402 > From vicente.romero at oracle.com Fri Jan 11 22:11:15 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 11 Jan 2019 17:11:15 -0500 Subject: RFR: JDK-8215482: check for cycles in type variables can provoke NPE In-Reply-To: <7ffb81ca-a20c-7d28-1364-397c5b30a87d@oracle.com> References: <74c7978f-034b-2d2c-0e6d-adad2a14a496@oracle.com> <64c32752-879a-98b0-faab-724c2a330b1e@oracle.com> <7056c755-9242-d5e7-c926-705610074f09@oracle.com> <7ffb81ca-a20c-7d28-1364-397c5b30a87d@oracle.com> Message-ID: <6c01f830-dfa9-50e3-0df4-17c744a53a63@oracle.com> On 1/11/19 2:13 PM, Maurizio Cimadamore wrote: > > As per my suggestion to split into multiple stages, it was mostly a > suggestion to take full advantage of the tiered architecture of > TypeEnter. You are basically caching some types in a 'todo later' > list, and then you are coming back at them - avoiding these kind of > queuing is what the (relatively) new TypeEnter code is for. > > If the cyclic check is moved to a later phase, then I think you just > need to fetch the type variables from the symbol/type/tree and check > them; the types will be already set, no need to stash them into a map. > At least in theory :-) > right thanks for the suggestion, that's a better option, please see: http://cr.openjdk.java.net/~vromero/8215482/webrev.01/ Vicente > > Maurizio > > On 11/01/2019 18:05, Vicente Romero wrote: >> I have realized that cloning the type variable is not necessary as >> the Pair element in the table will keep a >> reference to the type variable >> >> Vicente >> >> >> On 1/11/19 12:29 PM, Vicente Romero wrote: >>> >>> >>> On 1/11/19 12:21 PM, Maurizio Cimadamore wrote: >>>> >>>> It seems that another thing that your path is doing is storing all >>>> the type vars to check keyed by outermost class, so that only when >>>> you have finished entering the outermost symbol you actually start >>>> checking all pending typevars for cycles. I guess this delay is >>>> necessary otherwise you would hit a problem anyway when checking Bc >>>> for cyclicity? >>>> >>> >>> correct >>> >>>> Have you consider moving the attribution and cyclicity check in >>>> different type enter phases? For instance, leave attribution in >>>> HeaderPhase, but move the cycle check in MembersPhase ? >>>> >>> >>> I didn't try, but why would this be preferable? also as annotation >>> processing can nuke the type we would have to make sure that the >>> types are there before doing the cycle check which is something we >>> can guarantee now by keeping the check for cycles in the Header phase >>> >>>> Maurizio >>>> >>> >>> Vicente >>> >>>> On 11/01/2019 16:47, Vicente Romero wrote: >>>>> Please review the fix for [1] at [2]. The NPE showed up in code like: >>>>> >>>>> class Outer { >>>>> ??? class Inner {} >>>>> } >>>>> >>>>> here attribution of type variable `A` during type enter phase will >>>>> trigger attribution of class `Inner` while type variable `B` >>>>> hasn't been attributed yet and thus its bound is still set to >>>>> null. A similar problem arose a while ago see [3]. The issue >>>>> provoking the current bug is that checks for cycles in type >>>>> variables are done as soon as the type variable is attributed but >>>>> in cases like the one above we can't do that until the type >>>>> variable for the outer class has been attributed too. >>>>> >>>>> My first try was to create a fixup table that maps the outer type >>>>> to the list of type variables defined by it or its members that >>>>> happen to be types too, and once the compiler finish entering the >>>>> outer class it would be safe to check for cycles in all the >>>>> concerning type variables. I had a mild success here as there were >>>>> some trivial cases that were working before that started failing. >>>>> I realized that it was because the annotation processing phase was >>>>> setting all the types to null, no bueno. So I decided to clone the >>>>> type variables to be stored in the fixup table and do the cycle >>>>> check on the clones which is what the current patch is doing. >>>>> >>>>> Thanks, >>>>> Vicente >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8215482 >>>>> [2] http://cr.openjdk.java.net/~vromero/8215482/ >>>>> [3] https://bugs.openjdk.java.net/browse/JDK-6660289 >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Mon Jan 14 10:56:45 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 14 Jan 2019 10:56:45 +0000 Subject: RFR: JDK-8215482: check for cycles in type variables can provoke NPE In-Reply-To: <6c01f830-dfa9-50e3-0df4-17c744a53a63@oracle.com> References: <74c7978f-034b-2d2c-0e6d-adad2a14a496@oracle.com> <64c32752-879a-98b0-faab-724c2a330b1e@oracle.com> <7056c755-9242-d5e7-c926-705610074f09@oracle.com> <7ffb81ca-a20c-7d28-1364-397c5b30a87d@oracle.com> <6c01f830-dfa9-50e3-0df4-17c744a53a63@oracle.com> Message-ID: Looks good! Maurizio On 11/01/2019 22:11, Vicente Romero wrote: > > > On 1/11/19 2:13 PM, Maurizio Cimadamore wrote: >> >> As per my suggestion to split into multiple stages, it was mostly a >> suggestion to take full advantage of the tiered architecture of >> TypeEnter. You are basically caching some types in a 'todo later' >> list, and then you are coming back at them - avoiding these kind of >> queuing is what the (relatively) new TypeEnter code is for. >> >> If the cyclic check is moved to a later phase, then I think you just >> need to fetch the type variables from the symbol/type/tree and check >> them; the types will be already set, no need to stash them into a >> map. At least in theory :-) >> > > right thanks for the suggestion, that's a better option, please see: > > http://cr.openjdk.java.net/~vromero/8215482/webrev.01/ > > Vicente >> >> Maurizio >> >> On 11/01/2019 18:05, Vicente Romero wrote: >>> I have realized that cloning the type variable is not necessary as >>> the Pair element in the table will keep a >>> reference to the type variable >>> >>> Vicente >>> >>> >>> On 1/11/19 12:29 PM, Vicente Romero wrote: >>>> >>>> >>>> On 1/11/19 12:21 PM, Maurizio Cimadamore wrote: >>>>> >>>>> It seems that another thing that your path is doing is storing all >>>>> the type vars to check keyed by outermost class, so that only when >>>>> you have finished entering the outermost symbol you actually start >>>>> checking all pending typevars for cycles. I guess this delay is >>>>> necessary otherwise you would hit a problem anyway when checking >>>>> Bc for cyclicity? >>>>> >>>> >>>> correct >>>> >>>>> Have you consider moving the attribution and cyclicity check in >>>>> different type enter phases? For instance, leave attribution in >>>>> HeaderPhase, but move the cycle check in MembersPhase ? >>>>> >>>> >>>> I didn't try, but why would this be preferable? also as annotation >>>> processing can nuke the type we would have to make sure that the >>>> types are there before doing the cycle check which is something we >>>> can guarantee now by keeping the check for cycles in the Header phase >>>> >>>>> Maurizio >>>>> >>>> >>>> Vicente >>>> >>>>> On 11/01/2019 16:47, Vicente Romero wrote: >>>>>> Please review the fix for [1] at [2]. The NPE showed up in code like: >>>>>> >>>>>> class Outer { >>>>>> ??? class Inner {} >>>>>> } >>>>>> >>>>>> here attribution of type variable `A` during type enter phase >>>>>> will trigger attribution of class `Inner` while type variable `B` >>>>>> hasn't been attributed yet and thus its bound is still set to >>>>>> null. A similar problem arose a while ago see [3]. The issue >>>>>> provoking the current bug is that checks for cycles in type >>>>>> variables are done as soon as the type variable is attributed but >>>>>> in cases like the one above we can't do that until the type >>>>>> variable for the outer class has been attributed too. >>>>>> >>>>>> My first try was to create a fixup table that maps the outer type >>>>>> to the list of type variables defined by it or its members that >>>>>> happen to be types too, and once the compiler finish entering the >>>>>> outer class it would be safe to check for cycles in all the >>>>>> concerning type variables. I had a mild success here as there >>>>>> were some trivial cases that were working before that started >>>>>> failing. I realized that it was because the annotation processing >>>>>> phase was setting all the types to null, no bueno. So I decided >>>>>> to clone the type variables to be stored in the fixup table and >>>>>> do the cycle check on the clones which is what the current patch >>>>>> is doing. >>>>>> >>>>>> Thanks, >>>>>> Vicente >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8215482 >>>>>> [2] http://cr.openjdk.java.net/~vromero/8215482/ >>>>>> [3] https://bugs.openjdk.java.net/browse/JDK-6660289 >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Mon Jan 14 13:29:44 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 14 Jan 2019 08:29:44 -0500 Subject: RFR: JDK-8215482: check for cycles in type variables can provoke NPE In-Reply-To: References: <74c7978f-034b-2d2c-0e6d-adad2a14a496@oracle.com> <64c32752-879a-98b0-faab-724c2a330b1e@oracle.com> <7056c755-9242-d5e7-c926-705610074f09@oracle.com> <7ffb81ca-a20c-7d28-1364-397c5b30a87d@oracle.com> <6c01f830-dfa9-50e3-0df4-17c744a53a63@oracle.com> Message-ID: thanks! Vicente On 1/14/19 5:56 AM, Maurizio Cimadamore wrote: > > Looks good! > > Maurizio > > On 11/01/2019 22:11, Vicente Romero wrote: >> >> >> On 1/11/19 2:13 PM, Maurizio Cimadamore wrote: >>> >>> As per my suggestion to split into multiple stages, it was mostly a >>> suggestion to take full advantage of the tiered architecture of >>> TypeEnter. You are basically caching some types in a 'todo later' >>> list, and then you are coming back at them - avoiding these kind of >>> queuing is what the (relatively) new TypeEnter code is for. >>> >>> If the cyclic check is moved to a later phase, then I think you just >>> need to fetch the type variables from the symbol/type/tree and check >>> them; the types will be already set, no need to stash them into a >>> map. At least in theory :-) >>> >> >> right thanks for the suggestion, that's a better option, please see: >> >> http://cr.openjdk.java.net/~vromero/8215482/webrev.01/ >> >> Vicente >>> >>> Maurizio >>> >>> On 11/01/2019 18:05, Vicente Romero wrote: >>>> I have realized that cloning the type variable is not necessary as >>>> the Pair element in the table will keep a >>>> reference to the type variable >>>> >>>> Vicente >>>> >>>> >>>> On 1/11/19 12:29 PM, Vicente Romero wrote: >>>>> >>>>> >>>>> On 1/11/19 12:21 PM, Maurizio Cimadamore wrote: >>>>>> >>>>>> It seems that another thing that your path is doing is storing >>>>>> all the type vars to check keyed by outermost class, so that only >>>>>> when you have finished entering the outermost symbol you actually >>>>>> start checking all pending typevars for cycles. I guess this >>>>>> delay is necessary otherwise you would hit a problem anyway when >>>>>> checking Bc for cyclicity? >>>>>> >>>>> >>>>> correct >>>>> >>>>>> Have you consider moving the attribution and cyclicity check in >>>>>> different type enter phases? For instance, leave attribution in >>>>>> HeaderPhase, but move the cycle check in MembersPhase ? >>>>>> >>>>> >>>>> I didn't try, but why would this be preferable? also as annotation >>>>> processing can nuke the type we would have to make sure that the >>>>> types are there before doing the cycle check which is something we >>>>> can guarantee now by keeping the check for cycles in the Header phase >>>>> >>>>>> Maurizio >>>>>> >>>>> >>>>> Vicente >>>>> >>>>>> On 11/01/2019 16:47, Vicente Romero wrote: >>>>>>> Please review the fix for [1] at [2]. The NPE showed up in code >>>>>>> like: >>>>>>> >>>>>>> class Outer { >>>>>>> ??? class Inner {} >>>>>>> } >>>>>>> >>>>>>> here attribution of type variable `A` during type enter phase >>>>>>> will trigger attribution of class `Inner` while type variable >>>>>>> `B` hasn't been attributed yet and thus its bound is still set >>>>>>> to null. A similar problem arose a while ago see [3]. The issue >>>>>>> provoking the current bug is that checks for cycles in type >>>>>>> variables are done as soon as the type variable is attributed >>>>>>> but in cases like the one above we can't do that until the type >>>>>>> variable for the outer class has been attributed too. >>>>>>> >>>>>>> My first try was to create a fixup table that maps the outer >>>>>>> type to the list of type variables defined by it or its members >>>>>>> that happen to be types too, and once the compiler finish >>>>>>> entering the outer class it would be safe to check for cycles in >>>>>>> all the concerning type variables. I had a mild success here as >>>>>>> there were some trivial cases that were working before that >>>>>>> started failing. I realized that it was because the annotation >>>>>>> processing phase was setting all the types to null, no bueno. So >>>>>>> I decided to clone the type variables to be stored in the fixup >>>>>>> table and do the cycle check on the clones which is what the >>>>>>> current patch is doing. >>>>>>> >>>>>>> Thanks, >>>>>>> Vicente >>>>>>> >>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8215482 >>>>>>> [2] http://cr.openjdk.java.net/~vromero/8215482/ >>>>>>> [3] https://bugs.openjdk.java.net/browse/JDK-6660289 >>>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Mon Jan 14 18:50:50 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 14 Jan 2019 13:50:50 -0500 Subject: RFR: JDK-8216529: in case of a crash, javac should print out the parameters passed to it Message-ID: <1d6aab93-bf0b-6fce-8819-a699d22a26ae@oracle.com> Please review the fix for enhancement [1] at [2]. The idea of this enhancement is to print out to a file the arguments passed to javac is there is a fatal error or if a hidden option is passed to the compiler. This could be very helpful to reproduce some bugs reported by users. Thanks, Vicente PS, thanks to Jon for offline feedback an suggestions [1] https://bugs.openjdk.java.net/browse/JDK-8216529 [2] http://cr.openjdk.java.net/~vromero/8216529/webrev.00/ From cushon at google.com Mon Jan 14 19:22:48 2019 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 14 Jan 2019 11:22:48 -0800 Subject: RFR: JDK-8216529: in case of a crash, javac should print out the parameters passed to it In-Reply-To: <1d6aab93-bf0b-6fce-8819-a699d22a26ae@oracle.com> References: <1d6aab93-bf0b-6fce-8819-a699d22a26ae@oracle.com> Message-ID: Hi Vicente, This looks useful. Did you consider printing the args to stderr instead of writing them to a file, maybe as part of msg.bug? If I'm reading the patch correctly it currently uses a file `javac..args` in the directory javac is running from, which users won't necessarily know about to include in crash reports, and which won't succeed if javac doesn't have permissions to create files in the working directory. On Mon, Jan 14, 2019 at 10:51 AM Vicente Romero wrote: > Please review the fix for enhancement [1] at [2]. The idea of this > enhancement is to print out to a file the arguments passed to javac is > there is a fatal error or if a hidden option is passed to the compiler. > This could be very helpful to reproduce some bugs reported by users. > > Thanks, > Vicente > > PS, thanks to Jon for offline feedback an suggestions > > [1] https://bugs.openjdk.java.net/browse/JDK-8216529 > [2] http://cr.openjdk.java.net/~vromero/8216529/webrev.00/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Mon Jan 14 19:38:05 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 14 Jan 2019 11:38:05 -0800 Subject: RFR: JDK-8216529: in case of a crash, javac should print out the parameters passed to it In-Reply-To: References: <1d6aab93-bf0b-6fce-8819-a699d22a26ae@oracle.com> Message-ID: The intent is the crash report should contain the path of the file, and the file should be in "@-file" format, to make it easier to rerun the compilation using the file with `javac @javac..args`.?? If an error occurs when writing to the file, the info could be written to the console, but note that there could be a huge amount of output, depending how many files are specified on the command-line. -- Jon On 1/14/19 11:22 AM, Liam Miller-Cushon wrote: > Hi Vicente, > > This looks useful. > > Did you consider printing the args to stderr instead of writing them > to a file, maybe as part of msg.bug? If I'm reading the patch > correctly it currently uses a file `javac..args` in the > directory javac is running from, which users won't necessarily know > about to include in crash reports, and which won't succeed if javac > doesn't have permissions to create files in the working directory. > > On Mon, Jan 14, 2019 at 10:51 AM Vicente Romero > > wrote: > > Please review the fix for enhancement [1] at [2]. The idea of this > enhancement is to print out to a file the arguments passed to > javac is > there is a fatal error or if a hidden option is passed to the > compiler. > This could be very helpful to reproduce some bugs reported by users. > > Thanks, > Vicente > > PS, thanks to Jon for offline feedback an suggestions > > [1] https://bugs.openjdk.java.net/browse/JDK-8216529 > [2] http://cr.openjdk.java.net/~vromero/8216529/webrev.00/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Mon Jan 14 20:03:44 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 14 Jan 2019 15:03:44 -0500 Subject: RFR: JDK-8216529: in case of a crash, javac should print out the parameters passed to it In-Reply-To: References: <1d6aab93-bf0b-6fce-8819-a699d22a26ae@oracle.com> Message-ID: <0b4d139c-7b74-7158-8be1-feb3f27dade7@oracle.com> Hi Liam, On 1/14/19 2:38 PM, Jonathan Gibbons wrote: > > The intent is the crash report should contain the path of the file, > and the file should be in "@-file" format, to make it easier to rerun > the compilation using the file with `javac @javac..args`.?? If > an error occurs when writing to the file, the info could be written to > the console, but note that there could be a huge amount of output, > depending how many files are specified on the command-line. > right, what Jon says. I decided not to write to the console because if the output is huge, most of it will be lost as it will be trimmed thus reducing the usefulness of it. > -- Jon > Vicente > On 1/14/19 11:22 AM, Liam Miller-Cushon wrote: >> Hi Vicente, >> >> This looks useful. >> >> Did you consider printing the args to stderr instead of writing them >> to a file, maybe as part of msg.bug? If I'm reading the patch >> correctly it currently uses a file `javac..args` in the >> directory javac is running from, which users won't necessarily know >> about to include in crash reports, and which won't succeed if javac >> doesn't have permissions to create files in the working directory. >> >> On Mon, Jan 14, 2019 at 10:51 AM Vicente Romero >> > wrote: >> >> Please review the fix for enhancement [1] at [2]. The idea of this >> enhancement is to print out to a file the arguments passed to >> javac is >> there is a fatal error or if a hidden option is passed to the >> compiler. >> This could be very helpful to reproduce some bugs reported by users. >> >> Thanks, >> Vicente >> >> PS, thanks to Jon for offline feedback an suggestions >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8216529 >> [2] http://cr.openjdk.java.net/~vromero/8216529/webrev.00/ >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Mon Jan 14 21:20:27 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 14 Jan 2019 13:20:27 -0800 Subject: RFR: JDK-8216529: in case of a crash, javac should print out the parameters passed to it In-Reply-To: <0b4d139c-7b74-7158-8be1-feb3f27dade7@oracle.com> References: <1d6aab93-bf0b-6fce-8819-a699d22a26ae@oracle.com> <0b4d139c-7b74-7158-8be1-feb3f27dade7@oracle.com> Message-ID: <716f0216-8f78-b539-dfa9-4fffea69ff97@oracle.com> Do you mean the trimming done by jtreg??? That will obviously only happen if the crash happens in the context of a test. As a general solution, if you can't write the file, you could write the non-file options, and the first N files, to the console, for some suitable N. That being said, if you're just printing argv, you don't easily have the analysis of file vs non-file options, so it may just come down to print the first N args, for a different, bigger N. -- Jon On 01/14/2019 12:03 PM, Vicente Romero wrote: > Hi Liam, > > On 1/14/19 2:38 PM, Jonathan Gibbons wrote: >> >> The intent is the crash report should contain the path of the file, >> and the file should be in "@-file" format, to make it easier to rerun >> the compilation using the file with `javac @javac..args`.?? If >> an error occurs when writing to the file, the info could be written >> to the console, but note that there could be a huge amount of output, >> depending how many files are specified on the command-line. >> > > right, what Jon says. I decided not to write to the console because if > the output is huge, most of it will be lost as it will be trimmed thus > reducing the usefulness of it. > >> -- Jon >> > > Vicente > >> On 1/14/19 11:22 AM, Liam Miller-Cushon wrote: >>> Hi Vicente, >>> >>> This looks useful. >>> >>> Did you consider printing the args to stderr instead of writing them >>> to a file, maybe as part of msg.bug? If I'm reading the patch >>> correctly it currently uses a file `javac..args` in the >>> directory javac is running from, which users won't necessarily know >>> about to include in crash reports, and which won't succeed if javac >>> doesn't have permissions to create files in the working directory. >>> >>> On Mon, Jan 14, 2019 at 10:51 AM Vicente Romero >>> > wrote: >>> >>> Please review the fix for enhancement [1] at [2]. The idea of this >>> enhancement is to print out to a file the arguments passed to >>> javac is >>> there is a fatal error or if a hidden option is passed to the >>> compiler. >>> This could be very helpful to reproduce some bugs reported by users. >>> >>> Thanks, >>> Vicente >>> >>> PS, thanks to Jon for offline feedback an suggestions >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8216529 >>> [2] http://cr.openjdk.java.net/~vromero/8216529/webrev.00/ >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Mon Jan 14 22:59:37 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 14 Jan 2019 17:59:37 -0500 Subject: RFR: JDK-8216529: in case of a crash, javac should print out the parameters passed to it In-Reply-To: <716f0216-8f78-b539-dfa9-4fffea69ff97@oracle.com> References: <1d6aab93-bf0b-6fce-8819-a699d22a26ae@oracle.com> <0b4d139c-7b74-7158-8be1-feb3f27dade7@oracle.com> <716f0216-8f78-b539-dfa9-4fffea69ff97@oracle.com> Message-ID: On 1/14/19 4:20 PM, Jonathan Gibbons wrote: > Do you mean the trimming done by jtreg??? That will obviously only > happen if the crash happens in the context of a test. no I saw that issue for bugs breaking the JDK build and I saw that the output was incomplete > > As a general solution, if you can't write the file, you could write > the non-file options, and the first N files, to the console, for some > suitable N. That being said, if you're just printing argv, you don't > easily have the analysis of file vs non-file options, so it may just > come down to print the first N args, for a different, bigger N. I tend to believe that the general case in which this will be most useful will be cases with a large number of parameters, so I tend to think that it should be better to generate no output rather than generate an incomplete output. But I could be convinced otherwise :) > > -- Jon Vicente > > > > On 01/14/2019 12:03 PM, Vicente Romero wrote: >> Hi Liam, >> >> On 1/14/19 2:38 PM, Jonathan Gibbons wrote: >>> >>> The intent is the crash report should contain the path of the file, >>> and the file should be in "@-file" format, to make it easier to >>> rerun the compilation using the file with `javac >>> @javac..args`.?? If an error occurs when writing to the file, >>> the info could be written to the console, but note that there could >>> be a huge amount of output, depending how many files are specified >>> on the command-line. >>> >> >> right, what Jon says. I decided not to write to the console because >> if the output is huge, most of it will be lost as it will be trimmed >> thus reducing the usefulness of it. >> >>> -- Jon >>> >> >> Vicente >> >>> On 1/14/19 11:22 AM, Liam Miller-Cushon wrote: >>>> Hi Vicente, >>>> >>>> This looks useful. >>>> >>>> Did you consider printing the args to stderr instead of writing >>>> them to a file, maybe as part of msg.bug? If I'm reading the patch >>>> correctly it currently uses a file `javac..args` in the >>>> directory javac is running from, which users won't necessarily know >>>> about to include in crash reports, and which won't succeed if javac >>>> doesn't have permissions to create files in the working directory. >>>> >>>> On Mon, Jan 14, 2019 at 10:51 AM Vicente Romero >>>> > wrote: >>>> >>>> Please review the fix for enhancement [1] at [2]. The idea of this >>>> enhancement is to print out to a file the arguments passed to >>>> javac is >>>> there is a fatal error or if a hidden option is passed to the >>>> compiler. >>>> This could be very helpful to reproduce some bugs reported by >>>> users. >>>> >>>> Thanks, >>>> Vicente >>>> >>>> PS, thanks to Jon for offline feedback an suggestions >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8216529 >>>> [2] http://cr.openjdk.java.net/~vromero/8216529/webrev.00/ >>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Mon Jan 14 23:51:01 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 14 Jan 2019 18:51:01 -0500 Subject: RFR: JDK-8216529: in case of a crash, javac should print out the parameters passed to it In-Reply-To: References: <1d6aab93-bf0b-6fce-8819-a699d22a26ae@oracle.com> <0b4d139c-7b74-7158-8be1-feb3f27dade7@oracle.com> <716f0216-8f78-b539-dfa9-4fffea69ff97@oracle.com> Message-ID: <1aa1aa36-fb5f-0313-019a-87cc17ad662c@oracle.com> I have updated the webrev [1], the difference is that now in case of error, a message is printed to warn the user, Thanks, Vicente [1] http://cr.openjdk.java.net/~vromero/8216529/webrev.01/ On 1/14/19 5:59 PM, Vicente Romero wrote: > > > On 1/14/19 4:20 PM, Jonathan Gibbons wrote: >> Do you mean the trimming done by jtreg??? That will obviously only >> happen if the crash happens in the context of a test. > > no I saw that issue for bugs breaking the JDK build and I saw that the > output was incomplete > >> >> As a general solution, if you can't write the file, you could write >> the non-file options, and the first N files, to the console, for some >> suitable N. That being said, if you're just printing argv, you don't >> easily have the analysis of file vs non-file options, so it may just >> come down to print the first N args, for a different, bigger N. > > I tend to believe that the general case in which this will be most > useful will be cases with a large number of parameters, so I tend to > think that it should be better to generate no output rather than > generate an incomplete output. But I could be convinced otherwise :) > >> >> -- Jon > > Vicente > >> >> >> >> On 01/14/2019 12:03 PM, Vicente Romero wrote: >>> Hi Liam, >>> >>> On 1/14/19 2:38 PM, Jonathan Gibbons wrote: >>>> >>>> The intent is the crash report should contain the path of the file, >>>> and the file should be in "@-file" format, to make it easier to >>>> rerun the compilation using the file with `javac >>>> @javac..args`.?? If an error occurs when writing to the file, >>>> the info could be written to the console, but note that there could >>>> be a huge amount of output, depending how many files are specified >>>> on the command-line. >>>> >>> >>> right, what Jon says. I decided not to write to the console because >>> if the output is huge, most of it will be lost as it will be trimmed >>> thus reducing the usefulness of it. >>> >>>> -- Jon >>>> >>> >>> Vicente >>> >>>> On 1/14/19 11:22 AM, Liam Miller-Cushon wrote: >>>>> Hi Vicente, >>>>> >>>>> This looks useful. >>>>> >>>>> Did you consider printing the args to stderr instead of writing >>>>> them to a file, maybe as part of msg.bug? If I'm reading the patch >>>>> correctly it currently uses a file `javac..args` in the >>>>> directory javac is running from, which users won't necessarily >>>>> know about to include in crash reports, and which won't succeed if >>>>> javac doesn't have permissions to create files in the working >>>>> directory. >>>>> >>>>> On Mon, Jan 14, 2019 at 10:51 AM Vicente Romero >>>>> > wrote: >>>>> >>>>> Please review the fix for enhancement [1] at [2]. The idea of >>>>> this >>>>> enhancement is to print out to a file the arguments passed to >>>>> javac is >>>>> there is a fatal error or if a hidden option is passed to the >>>>> compiler. >>>>> This could be very helpful to reproduce some bugs reported by >>>>> users. >>>>> >>>>> Thanks, >>>>> Vicente >>>>> >>>>> PS, thanks to Jon for offline feedback an suggestions >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8216529 >>>>> [2] http://cr.openjdk.java.net/~vromero/8216529/webrev.00/ >>>>> >>>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Tue Jan 15 00:05:53 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 14 Jan 2019 16:05:53 -0800 Subject: RFR: JDK-8216529: in case of a crash, javac should print out the parameters passed to it In-Reply-To: References: <1d6aab93-bf0b-6fce-8819-a699d22a26ae@oracle.com> <0b4d139c-7b74-7158-8be1-feb3f27dade7@oracle.com> <716f0216-8f78-b539-dfa9-4fffea69ff97@oracle.com> Message-ID: On 01/14/2019 02:59 PM, Vicente Romero wrote: > > > On 1/14/19 4:20 PM, Jonathan Gibbons wrote: >> Do you mean the trimming done by jtreg??? That will obviously only >> happen if the crash happens in the context of a test. > > no I saw that issue for bugs breaking the JDK build and I saw that the > output was incomplete It's still the case that what you describe is our internal infrastructure trimming the output, and most users will not suffer the same restrictions. > >> >> As a general solution, if you can't write the file, you could write >> the non-file options, and the first N files, to the console, for some >> suitable N. That being said, if you're just printing argv, you don't >> easily have the analysis of file vs non-file options, so it may just >> come down to print the first N args, for a different, bigger N. > > I tend to believe that the general case in which this will be most > useful will be cases with a large number of parameters, so I tend to > think that it should be better to generate no output rather than > generate an incomplete output. But I could be convinced otherwise :) Maybe. "No output" means no way of guessing what the input was; "Some output" means you might at least show enough to show all the options, even if you don't show all the files.? But either way, if you fail to write the output, you should report that to the console, so that folk who are expecting to see the output and not surprised when it is not generated. > >> >> -- Jon > > Vicente > >> >> >> >> On 01/14/2019 12:03 PM, Vicente Romero wrote: >>> Hi Liam, >>> >>> On 1/14/19 2:38 PM, Jonathan Gibbons wrote: >>>> >>>> The intent is the crash report should contain the path of the file, >>>> and the file should be in "@-file" format, to make it easier to >>>> rerun the compilation using the file with `javac >>>> @javac..args`.?? If an error occurs when writing to the file, >>>> the info could be written to the console, but note that there could >>>> be a huge amount of output, depending how many files are specified >>>> on the command-line. >>>> >>> >>> right, what Jon says. I decided not to write to the console because >>> if the output is huge, most of it will be lost as it will be trimmed >>> thus reducing the usefulness of it. >>> >>>> -- Jon >>>> >>> >>> Vicente >>> >>>> On 1/14/19 11:22 AM, Liam Miller-Cushon wrote: >>>>> Hi Vicente, >>>>> >>>>> This looks useful. >>>>> >>>>> Did you consider printing the args to stderr instead of writing >>>>> them to a file, maybe as part of msg.bug? If I'm reading the patch >>>>> correctly it currently uses a file `javac..args` in the >>>>> directory javac is running from, which users won't necessarily >>>>> know about to include in crash reports, and which won't succeed if >>>>> javac doesn't have permissions to create files in the working >>>>> directory. >>>>> >>>>> On Mon, Jan 14, 2019 at 10:51 AM Vicente Romero >>>>> > wrote: >>>>> >>>>> Please review the fix for enhancement [1] at [2]. The idea of >>>>> this >>>>> enhancement is to print out to a file the arguments passed to >>>>> javac is >>>>> there is a fatal error or if a hidden option is passed to the >>>>> compiler. >>>>> This could be very helpful to reproduce some bugs reported by >>>>> users. >>>>> >>>>> Thanks, >>>>> Vicente >>>>> >>>>> PS, thanks to Jon for offline feedback an suggestions >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8216529 >>>>> [2] http://cr.openjdk.java.net/~vromero/8216529/webrev.00/ >>>>> >>>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Tue Jan 15 00:38:00 2019 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 14 Jan 2019 16:38:00 -0800 Subject: RFR: JDK-8216529: in case of a crash, javac should print out the parameters passed to it In-Reply-To: References: <1d6aab93-bf0b-6fce-8819-a699d22a26ae@oracle.com> <0b4d139c-7b74-7158-8be1-feb3f27dade7@oracle.com> <716f0216-8f78-b539-dfa9-4fffea69ff97@oracle.com> Message-ID: My concern was mostly that users might forget to include the separate file in their report, and by the time it's triaged it's probably too late to get that information. Making it easy to copy-paste the arguments as part of the crash message could help, but I understand the concern about console spam. If you were to print a subset, the non-file options are probably the most interesting (especially non-standard options, as in e.g. JDK-8059453). But having the full list of arguments is even better. Maybe add a reminder to the diagnostic text to include the params file when reporting a bug (possibly in the "Include your program and the following diagnostic" part of msg.bug)? On Mon, Jan 14, 2019 at 4:05 PM Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > > > On 01/14/2019 02:59 PM, Vicente Romero wrote: > > > > On 1/14/19 4:20 PM, Jonathan Gibbons wrote: > > Do you mean the trimming done by jtreg? That will obviously only happen > if the crash happens in the context of a test. > > > no I saw that issue for bugs breaking the JDK build and I saw that the > output was incomplete > > > It's still the case that what you describe is our internal infrastructure > trimming the output, and most users will not suffer the same restrictions. > > > > As a general solution, if you can't write the file, you could write the > non-file options, and the first N files, to the console, for some suitable > N. That being said, if you're just printing argv, you don't easily have the > analysis of file vs non-file options, so it may just come down to print the > first N args, for a different, bigger N. > > > I tend to believe that the general case in which this will be most useful > will be cases with a large number of parameters, so I tend to think that it > should be better to generate no output rather than generate an incomplete > output. But I could be convinced otherwise :) > > > Maybe. "No output" means no way of guessing what the input was; "Some > output" means you might at least show enough to show all the options, even > if you don't show all the files. But either way, if you fail to write the > output, you should report that to the console, so that folk who are > expecting to see the output and not surprised when it is not generated. > > > > -- Jon > > > Vicente > > > > > On 01/14/2019 12:03 PM, Vicente Romero wrote: > > Hi Liam, > > On 1/14/19 2:38 PM, Jonathan Gibbons wrote: > > The intent is the crash report should contain the path of the file, and > the file should be in "@-file" format, to make it easier to rerun the > compilation using the file with `javac @javac..args`. If an error > occurs when writing to the file, the info could be written to the console, > but note that there could be a huge amount of output, depending how many > files are specified on the command-line. > > > right, what Jon says. I decided not to write to the console because if the > output is huge, most of it will be lost as it will be trimmed thus reducing > the usefulness of it. > > -- Jon > > > Vicente > > On 1/14/19 11:22 AM, Liam Miller-Cushon wrote: > > Hi Vicente, > > This looks useful. > > Did you consider printing the args to stderr instead of writing them to a > file, maybe as part of msg.bug? If I'm reading the patch correctly it > currently uses a file `javac..args` in the directory javac is running > from, which users won't necessarily know about to include in crash reports, > and which won't succeed if javac doesn't have permissions to create files > in the working directory. > > On Mon, Jan 14, 2019 at 10:51 AM Vicente Romero > wrote: > >> Please review the fix for enhancement [1] at [2]. The idea of this >> enhancement is to print out to a file the arguments passed to javac is >> there is a fatal error or if a hidden option is passed to the compiler. >> This could be very helpful to reproduce some bugs reported by users. >> >> Thanks, >> Vicente >> >> PS, thanks to Jon for offline feedback an suggestions >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8216529 >> [2] http://cr.openjdk.java.net/~vromero/8216529/webrev.00/ >> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Tue Jan 15 13:47:51 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 15 Jan 2019 08:47:51 -0500 Subject: RFR: JDK-8216529: in case of a crash, javac should print out the parameters passed to it In-Reply-To: References: <1d6aab93-bf0b-6fce-8819-a699d22a26ae@oracle.com> <0b4d139c-7b74-7158-8be1-feb3f27dade7@oracle.com> <716f0216-8f78-b539-dfa9-4fffea69ff97@oracle.com> Message-ID: <0b5b9b2d-697e-5230-14e2-65b8ec191892@oracle.com> On 1/14/19 7:38 PM, Liam Miller-Cushon wrote: > My concern was mostly that users might forget to include the separate > file in their report, and by the time it's triaged it's probably too > late to get that information. there is an early triage that could ask users for the file / parameters plus the release file which could also be helpful to reproduce the issue > > Making it easy to copy-paste the arguments as part of the crash > message could help, but I understand the concern about console spam. > If you were to print a subset, the non-file options are probably the > most interesting (especially non-standard options, as in e.g. > JDK-8059453). > > But having the full list of arguments is even better. Maybe add a > reminder to the diagnostic text to include the params file when > reporting a bug (possibly in the "Include your program and the > following diagnostic" part of msg.bug)? I have modified the msg.bug to mention javac parameters too, see [1], this version also prints the parameters to the output in case of error [1] http://cr.openjdk.java.net/~vromero/8216529/webrev.02/ Thanks, Vicente > > On Mon, Jan 14, 2019 at 4:05 PM Jonathan Gibbons > > wrote: > > > > On 01/14/2019 02:59 PM, Vicente Romero wrote: >> >> >> On 1/14/19 4:20 PM, Jonathan Gibbons wrote: >>> Do you mean the trimming done by jtreg??? That will obviously >>> only happen if the crash happens in the context of a test. >> >> no I saw that issue for bugs breaking the JDK build and I saw >> that the output was incomplete > > It's still the case that what you describe is our internal > infrastructure trimming the output, and most users will not suffer > the same restrictions. > >> >>> >>> As a general solution, if you can't write the file, you could >>> write the non-file options, and the first N files, to the >>> console, for some suitable N. That being said, if you're just >>> printing argv, you don't easily have the analysis of file vs >>> non-file options, so it may just come down to print the first N >>> args, for a different, bigger N. >> >> I tend to believe that the general case in which this will be >> most useful will be cases with a large number of parameters, so I >> tend to think that it should be better to generate no output >> rather than generate an incomplete output. But I could be >> convinced otherwise :) > > Maybe. "No output" means no way of guessing what the input was;? > "Some output" means you might at least show enough to show all the > options, even if you don't show all the files. But either way, if > you fail to write the output, you should report that to the > console, so that folk who are expecting to see the output and not > surprised when it is not generated. > >> >>> >>> -- Jon >> >> Vicente >> >>> >>> >>> >>> On 01/14/2019 12:03 PM, Vicente Romero wrote: >>>> Hi Liam, >>>> >>>> On 1/14/19 2:38 PM, Jonathan Gibbons wrote: >>>>> >>>>> The intent is the crash report should contain the path of the >>>>> file, and the file should be in "@-file" format, to make it >>>>> easier to rerun the compilation using the file with `javac >>>>> @javac..args`.?? If an error occurs when writing to the >>>>> file, the info could be written to the console, but note that >>>>> there could be a huge amount of output, depending how many >>>>> files are specified on the command-line. >>>>> >>>> >>>> right, what Jon says. I decided not to write to the console >>>> because if the output is huge, most of it will be lost as it >>>> will be trimmed thus reducing the usefulness of it. >>>> >>>>> -- Jon >>>>> >>>> >>>> Vicente >>>> >>>>> On 1/14/19 11:22 AM, Liam Miller-Cushon wrote: >>>>>> Hi Vicente, >>>>>> >>>>>> This looks useful. >>>>>> >>>>>> Did you consider printing the args to stderr instead of >>>>>> writing them to a file, maybe as part of msg.bug? If I'm >>>>>> reading the patch correctly it currently uses a file >>>>>> `javac..args` in the directory javac is running from, >>>>>> which users won't necessarily know about to include in crash >>>>>> reports, and which won't succeed if javac doesn't have >>>>>> permissions to create files in the working directory. >>>>>> >>>>>> On Mon, Jan 14, 2019 at 10:51 AM Vicente Romero >>>>>> >>>>> > wrote: >>>>>> >>>>>> Please review the fix for enhancement [1] at [2]. The >>>>>> idea of this >>>>>> enhancement is to print out to a file the arguments >>>>>> passed to javac is >>>>>> there is a fatal error or if a hidden option is passed to >>>>>> the compiler. >>>>>> This could be very helpful to reproduce some bugs >>>>>> reported by users. >>>>>> >>>>>> Thanks, >>>>>> Vicente >>>>>> >>>>>> PS, thanks to Jon for offline feedback an suggestions >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8216529 >>>>>> [2] >>>>>> http://cr.openjdk.java.net/~vromero/8216529/webrev.00/ >>>>>> >>>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Tue Jan 15 18:10:21 2019 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 15 Jan 2019 10:10:21 -0800 Subject: JDK 12 RFR: 8217102: getAnnotatedOwnerType does not handle static nested classes correctly Message-ID: Hi, Please review this backport of JDK-8198526 to JDK 12. webrev: http://cr.openjdk.java.net/~cushon/8217102/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8217102 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Tue Jan 15 18:38:50 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 15 Jan 2019 13:38:50 -0500 Subject: JDK 12 RFR: 8217102: getAnnotatedOwnerType does not handle static nested classes correctly In-Reply-To: References: Message-ID: <2e2b427b-bc89-28b9-ad12-b439ec0a4e74@oracle.com> looks good, Vicente On 1/15/19 1:10 PM, Liam Miller-Cushon wrote: > Hi, > > Please review this backport of?JDK-8198526 to JDK 12. > > webrev: http://cr.openjdk.java.net/~cushon/8217102/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8217102 From vicente.romero at oracle.com Tue Jan 15 19:07:53 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 15 Jan 2019 14:07:53 -0500 Subject: RFR: JDK-8216529: in case of a crash, javac should print out the parameters passed to it In-Reply-To: <0b5b9b2d-697e-5230-14e2-65b8ec191892@oracle.com> References: <1d6aab93-bf0b-6fce-8819-a699d22a26ae@oracle.com> <0b4d139c-7b74-7158-8be1-feb3f27dade7@oracle.com> <716f0216-8f78-b539-dfa9-4fffea69ff97@oracle.com> <0b5b9b2d-697e-5230-14e2-65b8ec191892@oracle.com> Message-ID: Hi Liam, What do you think about the last version? I propose to start with this approach and modify it going forward as we get more feedback from users Thanks, Vicente On 1/15/19 8:47 AM, Vicente Romero wrote: > > > On 1/14/19 7:38 PM, Liam Miller-Cushon wrote: >> My concern was mostly that users might forget to include the separate >> file in their report, and by the time it's triaged it's probably too >> late to get that information. > > there is an early triage that could ask users for the file / > parameters plus the release file which could also be helpful to > reproduce the issue > >> >> Making it easy to copy-paste the arguments as part of the crash >> message could help, but I understand the concern about console spam. >> If you were to print a subset, the non-file options are probably the >> most interesting (especially non-standard options, as in e.g. >> JDK-8059453). >> >> But having the full list of arguments is even better. Maybe add a >> reminder to the diagnostic text to include the params file when >> reporting a bug (possibly in the "Include your program and the >> following diagnostic" part of msg.bug)? > > I have modified the msg.bug to mention javac parameters too, see [1], > this version also prints the parameters to the output in case of error > > [1] http://cr.openjdk.java.net/~vromero/8216529/webrev.02/ > > Thanks, > Vicente > >> >> On Mon, Jan 14, 2019 at 4:05 PM Jonathan Gibbons >> > wrote: >> >> >> >> On 01/14/2019 02:59 PM, Vicente Romero wrote: >>> >>> >>> On 1/14/19 4:20 PM, Jonathan Gibbons wrote: >>>> Do you mean the trimming done by jtreg??? That will obviously >>>> only happen if the crash happens in the context of a test. >>> >>> no I saw that issue for bugs breaking the JDK build and I saw >>> that the output was incomplete >> >> It's still the case that what you describe is our internal >> infrastructure trimming the output, and most users will not >> suffer the same restrictions. >> >>> >>>> >>>> As a general solution, if you can't write the file, you could >>>> write the non-file options, and the first N files, to the >>>> console, for some suitable N. That being said, if you're just >>>> printing argv, you don't easily have the analysis of file vs >>>> non-file options, so it may just come down to print the first N >>>> args, for a different, bigger N. >>> >>> I tend to believe that the general case in which this will be >>> most useful will be cases with a large number of parameters, so >>> I tend to think that it should be better to generate no output >>> rather than generate an incomplete output. But I could be >>> convinced otherwise :) >> >> Maybe. "No output" means no way of guessing what the input was;? >> "Some output" means you might at least show enough to show all >> the options, even if you don't show all the files.? But either >> way, if you fail to write the output, you should report that to >> the console, so that folk who are expecting to see the output and >> not surprised when it is not generated. >> >>> >>>> >>>> -- Jon >>> >>> Vicente >>> >>>> >>>> >>>> >>>> On 01/14/2019 12:03 PM, Vicente Romero wrote: >>>>> Hi Liam, >>>>> >>>>> On 1/14/19 2:38 PM, Jonathan Gibbons wrote: >>>>>> >>>>>> The intent is the crash report should contain the path of the >>>>>> file, and the file should be in "@-file" format, to make it >>>>>> easier to rerun the compilation using the file with `javac >>>>>> @javac..args`.?? If an error occurs when writing to the >>>>>> file, the info could be written to the console, but note that >>>>>> there could be a huge amount of output, depending how many >>>>>> files are specified on the command-line. >>>>>> >>>>> >>>>> right, what Jon says. I decided not to write to the console >>>>> because if the output is huge, most of it will be lost as it >>>>> will be trimmed thus reducing the usefulness of it. >>>>> >>>>>> -- Jon >>>>>> >>>>> >>>>> Vicente >>>>> >>>>>> On 1/14/19 11:22 AM, Liam Miller-Cushon wrote: >>>>>>> Hi Vicente, >>>>>>> >>>>>>> This looks useful. >>>>>>> >>>>>>> Did you consider printing the args to stderr instead of >>>>>>> writing them to a file, maybe as part of msg.bug? If I'm >>>>>>> reading the patch correctly it currently uses a file >>>>>>> `javac..args` in the directory javac is running from, >>>>>>> which users won't necessarily know about to include in crash >>>>>>> reports, and which won't succeed if javac doesn't have >>>>>>> permissions to create files in the working directory. >>>>>>> >>>>>>> On Mon, Jan 14, 2019 at 10:51 AM Vicente Romero >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> Please review the fix for enhancement [1] at [2]. The >>>>>>> idea of this >>>>>>> enhancement is to print out to a file the arguments >>>>>>> passed to javac is >>>>>>> there is a fatal error or if a hidden option is passed >>>>>>> to the compiler. >>>>>>> This could be very helpful to reproduce some bugs >>>>>>> reported by users. >>>>>>> >>>>>>> Thanks, >>>>>>> Vicente >>>>>>> >>>>>>> PS, thanks to Jon for offline feedback an suggestions >>>>>>> >>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8216529 >>>>>>> [2] >>>>>>> http://cr.openjdk.java.net/~vromero/8216529/webrev.00/ >>>>>>> >>>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeynoronha at gmail.com Tue Jan 15 19:25:53 2019 From: jeynoronha at gmail.com (Jeyvison Nascimento) Date: Tue, 15 Jan 2019 16:25:53 -0300 Subject: Null safe navigation Message-ID: Hi folks :) Sorry if this is the wrong list to ask about it but I'd like to discuss a feature that could turn into a JEP later, that is null Safe navigation. It's something like Groovy and kotlin offers with the operator "?" to avoid NullPointerExceptions. If this is not the best place, could you tell me to what list should I send a message, please? Thanks and sorry for bothering you all. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Tue Jan 15 21:29:09 2019 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 15 Jan 2019 13:29:09 -0800 Subject: JDK 12 RFR: 8217102: getAnnotatedOwnerType does not handle static nested classes correctly In-Reply-To: <2e2b427b-bc89-28b9-ad12-b439ec0a4e74@oracle.com> References: <2e2b427b-bc89-28b9-ad12-b439ec0a4e74@oracle.com> Message-ID: Thanks for the review! On Tue, Jan 15, 2019 at 10:38 AM Vicente Romero wrote: > looks good, > Vicente > > On 1/15/19 1:10 PM, Liam Miller-Cushon wrote: > > Hi, > > > > Please review this backport of JDK-8198526 to JDK 12. > > > > webrev: http://cr.openjdk.java.net/~cushon/8217102/webrev.00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8217102 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Tue Jan 15 23:19:36 2019 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 15 Jan 2019 15:19:36 -0800 Subject: RFR: JDK-8216529: in case of a crash, javac should print out the parameters passed to it In-Reply-To: References: <1d6aab93-bf0b-6fce-8819-a699d22a26ae@oracle.com> <0b4d139c-7b74-7158-8be1-feb3f27dade7@oracle.com> <716f0216-8f78-b539-dfa9-4fffea69ff97@oracle.com> <0b5b9b2d-697e-5230-14e2-65b8ec191892@oracle.com> Message-ID: On Tue, Jan 15, 2019 at 11:08 AM Vicente Romero wrote: > What do you think about the last version? I propose to start with this > approach and modify it going forward as we get more feedback from users > Looks good to me, thanks for the discussion. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Tue Jan 15 23:37:23 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 15 Jan 2019 18:37:23 -0500 Subject: RFR: JDK-8216529: in case of a crash, javac should print out the parameters passed to it In-Reply-To: References: <1d6aab93-bf0b-6fce-8819-a699d22a26ae@oracle.com> <0b4d139c-7b74-7158-8be1-feb3f27dade7@oracle.com> <716f0216-8f78-b539-dfa9-4fffea69ff97@oracle.com> <0b5b9b2d-697e-5230-14e2-65b8ec191892@oracle.com> Message-ID: thanks, Vicente On 1/15/19 6:19 PM, Liam Miller-Cushon wrote: > On Tue, Jan 15, 2019 at 11:08 AM Vicente Romero > > wrote: > > What do you think about the last version? I propose to start with > this approach and modify it going forward as we get more feedback > from users > > > Looks good to me, thanks for the discussion. -------------- next part -------------- An HTML attachment was scrubbed... URL: From amaembo at gmail.com Wed Jan 16 01:03:28 2019 From: amaembo at gmail.com (Tagir Valeev) Date: Wed, 16 Jan 2019 08:03:28 +0700 Subject: Null safe navigation In-Reply-To: References: Message-ID: Hello! I think, amber-spec-comments is a better place to discuss new language features. I don't think that Kotlin has a ? operator. There's ?: operator and ?. operator. Also I think, their semantics differs from those in Groovy. With best regards, Tagir Valeev. ??, 16 ???. 2019 ?., 2:27 Jeyvison Nascimento jeynoronha at gmail.com: > Hi folks :) > > Sorry if this is the wrong list to ask about it but I'd like to discuss a > feature that could turn into a JEP later, that is null Safe navigation. > It's something like Groovy and kotlin offers with the operator "?" to avoid > NullPointerExceptions. > > If this is not the best place, could you tell me to what list should I > send a message, please? > > Thanks and sorry for bothering you all. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeynoronha at gmail.com Wed Jan 16 12:29:35 2019 From: jeynoronha at gmail.com (Jeyvison Nascimento) Date: Wed, 16 Jan 2019 09:29:35 -0300 Subject: Null safe navigation In-Reply-To: References: Message-ID: Tanks Tagir :) Em ter, 15 de jan de 2019 ?s 22:03, Tagir Valeev escreveu: > Hello! > > I think, amber-spec-comments is a better place to discuss new language > features. > > I don't think that Kotlin has a ? operator. There's ?: operator and ?. > operator. Also I think, their semantics differs from those in Groovy. > > With best regards, > Tagir Valeev. > > ??, 16 ???. 2019 ?., 2:27 Jeyvison Nascimento jeynoronha at gmail.com: > >> Hi folks :) >> >> Sorry if this is the wrong list to ask about it but I'd like to discuss a >> feature that could turn into a JEP later, that is null Safe navigation. >> It's something like Groovy and kotlin offers with the operator "?" to avoid >> NullPointerExceptions. >> >> If this is not the best place, could you tell me to what list should I >> send a message, please? >> >> Thanks and sorry for bothering you all. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Wed Jan 16 14:47:09 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 16 Jan 2019 15:47:09 +0100 Subject: RFR 8214345: Infinite recursion with checking of class bound Message-ID: Hi, Please review the following fix for [1] which simply checks only valid class bounds per JLS 8.1.4/5: http://cr.openjdk.java.net/~bsrbnd/jdk8214345/webrev.00/ Thanks (tier1 is OK), Bernard [1] https://bugs.openjdk.java.net/browse/JDK-8214345 From joe.darcy at oracle.com Wed Jan 16 18:45:20 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 16 Jan 2019 10:45:20 -0800 Subject: FYI, JSR 269 maintenance review underway for Java SE 12 Message-ID: <941a5ac3-bada-c1a1-9023-c7f0c0eae388@oracle.com> Hello, As usual the JSR 269 API covering javax.lang.model.* and javax.annotation.processing is under JCP maintenance review for the current Java SE release, now Java SE 12: ??? https://jcp.org/en/jsr/detail?id=269 The summary and bug list from the MR materials: > The proposed changes to JSR 269 include: > > * Customary changes to support a new platform version, additional > enum constant in SourceVersion, etc. > * Deprecation of constructors of 7-era visitors (follows deprecation > of 6-era visitors under bug JDK-8172686 in JDK 9 and maintenance > review 2) > * Miscellaneous cleanups > > Bug system: https://bugs.openjdk.java.net > > JDK-8193292: Add SourceVersion.RELEASE_12 > JDK-8208201: Update SourceVersion.RELEASE_11 docs to mention var for > lambda param > JDK-8213256: Clarify runtime vs compile time annotations for > RoundEnvironment.getElementsAnnotatedWith(Class) > JDK-8208200: Add missing periods to sentences in RoundEnvironment specs > JDK-8173606: Deprecate constructors of 7-era visitors > JDK-8216322: Missing since information in deprecation of constructor > visitors Cheers, -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Wed Jan 16 19:55:01 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 16 Jan 2019 14:55:01 -0500 Subject: RFR JDK-8215470: Bad EnclosingMethod attribute on classes declared in lambdas Message-ID: <8e0778f7-1827-6864-a7c1-2d03f80f6095@oracle.com> Please review fix for [1] at [2]. The fix is about pointing the enclosing method attribute of inner classes inside a lambda; to the original method in which the inner class was declared. Currently javac is pointing it to the synthetic method that contains the lambda implementation. Please review the CSR too, Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8215470 [2] http://cr.openjdk.java.net/~vromero/8215470/webrev.00/ [3] https://bugs.openjdk.java.net/browse/JDK-8217272 From maurizio.cimadamore at oracle.com Wed Jan 16 21:05:55 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 16 Jan 2019 21:05:55 +0000 Subject: RFR JDK-8215470: Bad EnclosingMethod attribute on classes declared in lambdas In-Reply-To: <8e0778f7-1827-6864-a7c1-2d03f80f6095@oracle.com> References: <8e0778f7-1827-6864-a7c1-2d03f80f6095@oracle.com> Message-ID: The patch looks good - but I have some questions; sometime ago some logic was added to LambdaToMethod to handle type variables - see LambdaSymbolKind.TypeVar and related code. I have the vague feeling that this code was added precisely for this reason: to fixup issues related to missing type-variable in the enclosing method. If now you point to the correct method (as per source code), wouldn't this code be redundant? Doing some analysis on the code (hg annotate) I was able to get to this bug: https://bugs.openjdk.java.net/browse/JDK-8005653 Looking at the synopsis, I see an inner class with an enclosing method - and a dandling type variable reference... I think this is overlapping with the issue you are trying to fix. Also, I think it would be nice to have a test which uses reflection to poke at the type variables, and checks that the runtime values of the type-variables in the local class are indeed the same as the ones in the enclosing method. Maurizio On 16/01/2019 19:55, Vicente Romero wrote: > Please review fix for [1] at [2]. The fix is about pointing the > enclosing method attribute of inner classes inside a lambda; to the > original method in which the inner class was declared. Currently javac > is pointing it to the synthetic method that contains the lambda > implementation. Please review the CSR too, > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8215470 > [2] http://cr.openjdk.java.net/~vromero/8215470/webrev.00/ > [3] https://bugs.openjdk.java.net/browse/JDK-8217272 From joe.darcy at oracle.com Thu Jan 17 01:13:12 2019 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 16 Jan 2019 17:13:12 -0800 Subject: RFR(13): JDK-8216263: Add historical data for JDK 12 In-Reply-To: <5C3477B7.8060307@oracle.com> References: <5C334A87.5080207@oracle.com> <5C33D7E0.2020609@oracle.com> <5C3477B7.8060307@oracle.com> Message-ID: <5C3FD6A8.1080803@oracle.com> Hi Jan, On 1/8/2019 2:13 AM, Jan Lahoda wrote: > Hi Joe, > > Thanks for the comments, some responses inline. Updated webrev: > http://cr.openjdk.java.net/~jlahoda/8216263/webrev.01/ > > On 7.1.2019 23:51, Joseph D. Darcy wrote: >> Hi Jan, >> >> On 1/7/2019 4:48 AM, Jan Lahoda wrote: >>> Hi, >>> >>> To make --release 12 work, we need to add historical data for JDK 12. >>> The current historical data is based on: >>> $ javac -fullversion >>> javac full version "12-ea+26" >>> >>> We may need to update the data once JDK 12 is out to cover any changes >>> to the APIs that might happen. >>> >>> The patch also adds a simple (shell) script to generate the data, so >>> all that was needed to generate the data was: >>> $ cd make/data/symbols >>> $ sh generate-data >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8216263 >>> Webrev: http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/ >>> >>> How does this look? >> >> If the overhead is small enough and we don't mind a few updates to the >> JDK N+1 data, than perhaps the generation of this information could be >> included as part of the start of JDK N+1 activities. > > That would be perfect! > >> >> I suggest a more extensive description of how to >> make/data/symbols/generate-data. For example, this builds the data for >> the current release independent of whether or not the current release >> has already had its data generated, correct? > > Yes. > >> >> Concretely, if JDK N+1 has already forked, what is the proper way to get >> data for JDK N? Likewise, how should a re-build of the data for JDK N be >> done? > > What exactly should be there? To the existing description: > # to generate (add) data for JDK N, do: > # cd make/data/symbols > # sh generate-data > > I've added (in .01): > # to regenerate the data for JDK N, run the above commands again > > What more should be there? > I'd appreciate somewhere to have a textual discussion of how make/data/symbols/symbols should be updated, the A = 10, B = 11, etc. convention, what else need to be done to generate the contents of this changeset. The is the contents of the build directory? In general, a description of how the data of JDK N should be added to JDK (N+1). Thanks, -Joe From vicente.romero at oracle.com Thu Jan 17 02:15:57 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 16 Jan 2019 21:15:57 -0500 Subject: RFR JDK-8215470: Bad EnclosingMethod attribute on classes declared in lambdas In-Reply-To: References: <8e0778f7-1827-6864-a7c1-2d03f80f6095@oracle.com> Message-ID: <2b004f09-501f-03b4-c4dd-b6e8e5d14aac@oracle.com> Hi Maurizio, Thanks for your comments. What about [1]? Vicente [1] http://cr.openjdk.java.net/~vromero/8215470/webrev.01/jdk.dev.patch On 1/16/19 4:05 PM, Maurizio Cimadamore wrote: > The patch looks good - but I have some questions; sometime ago some > logic was added to LambdaToMethod to handle type variables - see > LambdaSymbolKind.TypeVar and related code. > > I have the vague feeling that this code was added precisely for this > reason: to fixup issues related to missing type-variable in the > enclosing method. If now you point to the correct method (as per > source code), wouldn't this code be redundant? Doing some analysis on > the code (hg annotate) I was able to get to this bug: > > https://bugs.openjdk.java.net/browse/JDK-8005653 > > Looking at the synopsis, I see an inner class with an enclosing method > - and a dandling type variable reference... I think this is > overlapping with the issue you are trying to fix. > > Also, I think it would be nice to have a test which uses reflection to > poke at the type variables, and checks that the runtime values of the > type-variables in the local class are indeed the same as the ones in > the enclosing method. > > Maurizio > > On 16/01/2019 19:55, Vicente Romero wrote: >> Please review fix for [1] at [2]. The fix is about pointing the >> enclosing method attribute of inner classes inside a lambda; to the >> original method in which the inner class was declared. Currently >> javac is pointing it to the synthetic method that contains the lambda >> implementation. Please review the CSR too, >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8215470 >> [2] http://cr.openjdk.java.net/~vromero/8215470/webrev.00/ >> [3] https://bugs.openjdk.java.net/browse/JDK-8217272 From jan.lahoda at oracle.com Thu Jan 17 16:51:21 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 17 Jan 2019 17:51:21 +0100 Subject: RFR(13): JDK-8216263: Add historical data for JDK 12 In-Reply-To: <5C3FD6A8.1080803@oracle.com> References: <5C334A87.5080207@oracle.com> <5C33D7E0.2020609@oracle.com> <5C3477B7.8060307@oracle.com> <5C3FD6A8.1080803@oracle.com> Message-ID: <5C40B289.7070408@oracle.com> Hi Joe, On 17.1.2019 02:13, Joseph D. Darcy wrote: > Hi Jan, > > On 1/8/2019 2:13 AM, Jan Lahoda wrote: >> Hi Joe, >> >> Thanks for the comments, some responses inline. Updated webrev: >> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.01/ >> >> On 7.1.2019 23:51, Joseph D. Darcy wrote: >>> Hi Jan, >>> >>> On 1/7/2019 4:48 AM, Jan Lahoda wrote: >>>> Hi, >>>> >>>> To make --release 12 work, we need to add historical data for JDK 12. >>>> The current historical data is based on: >>>> $ javac -fullversion >>>> javac full version "12-ea+26" >>>> >>>> We may need to update the data once JDK 12 is out to cover any changes >>>> to the APIs that might happen. >>>> >>>> The patch also adds a simple (shell) script to generate the data, so >>>> all that was needed to generate the data was: >>>> $ cd make/data/symbols >>>> $ sh generate-data >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8216263 >>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/ >>>> >>>> How does this look? >>> >>> If the overhead is small enough and we don't mind a few updates to the >>> JDK N+1 data, than perhaps the generation of this information could be >>> included as part of the start of JDK N+1 activities. >> >> That would be perfect! >> >>> >>> I suggest a more extensive description of how to >>> make/data/symbols/generate-data. For example, this builds the data for >>> the current release independent of whether or not the current release >>> has already had its data generated, correct? >> >> Yes. >> >>> >>> Concretely, if JDK N+1 has already forked, what is the proper way to get >>> data for JDK N? Likewise, how should a re-build of the data for JDK N be >>> done? >> >> What exactly should be there? To the existing description: >> # to generate (add) data for JDK N, do: >> # cd make/data/symbols >> # sh generate-data >> >> I've added (in .01): >> # to regenerate the data for JDK N, run the above commands again >> >> What more should be there? >> > > I'd appreciate somewhere to have a textual discussion of how > make/data/symbols/symbols should be updated, the A = 10, B = 11, etc. > convention, what else need to be done to generate the contents of this > changeset. > > The is the contents of the build directory? > > In general, a description of how the data of JDK N should be added to > JDK (N+1). I've added more textual description to the script, an updated webrev is here: http://cr.openjdk.java.net/~jlahoda/8216263/webrev.02/ Jan > > Thanks, > > -Joe > > From jonathan.gibbons at oracle.com Thu Jan 17 16:58:18 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 17 Jan 2019 08:58:18 -0800 Subject: RFR(13): JDK-8216263: Add historical data for JDK 12 In-Reply-To: <5C40B289.7070408@oracle.com> References: <5C334A87.5080207@oracle.com> <5C33D7E0.2020609@oracle.com> <5C3477B7.8060307@oracle.com> <5C3FD6A8.1080803@oracle.com> <5C40B289.7070408@oracle.com> Message-ID: <967fdd5a-9810-4790-a164-2e39394fed66@oracle.com> Re: 36 # The checkout must not have any local changes that could interfere with the new data. In particular, 37 # there must be absolutely no changed, new or removed files under the ${JDK_CHECKOUT}/make/data/symbols 38 # directory. That seems like a simple check that could be incorporated into the script itself. But, it also seems reasonable to separate enhancements like that from the specific issue here, to add historical data for 12. -- Jon On 1/17/19 8:51 AM, Jan Lahoda wrote: > Hi Joe, > > On 17.1.2019 02:13, Joseph D. Darcy wrote: >> Hi Jan, >> >> On 1/8/2019 2:13 AM, Jan Lahoda wrote: >>> Hi Joe, >>> >>> Thanks for the comments, some responses inline. Updated webrev: >>> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.01/ >>> >>> On 7.1.2019 23:51, Joseph D. Darcy wrote: >>>> Hi Jan, >>>> >>>> On 1/7/2019 4:48 AM, Jan Lahoda wrote: >>>>> Hi, >>>>> >>>>> To make --release 12 work, we need to add historical data for JDK 12. >>>>> The current historical data is based on: >>>>> $ javac? -fullversion >>>>> javac full version "12-ea+26" >>>>> >>>>> We may need to update the data once JDK 12 is out to cover any >>>>> changes >>>>> to the APIs that might happen. >>>>> >>>>> The patch also adds a simple (shell) script to generate the data, so >>>>> all that was needed to generate the data was: >>>>> $ cd make/data/symbols >>>>> $ sh generate-data >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8216263 >>>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/ >>>>> >>>>> How does this look? >>>> >>>> If the overhead is small enough and we don't mind a few updates to the >>>> JDK N+1 data, than perhaps the generation of this information could be >>>> included as part of the start of JDK N+1 activities. >>> >>> That would be perfect! >>> >>>> >>>> I suggest a more extensive description of how to >>>> make/data/symbols/generate-data. For example, this builds the data for >>>> the current release independent of whether or not the current release >>>> has already had its data generated, correct? >>> >>> Yes. >>> >>>> >>>> Concretely, if JDK N+1 has already forked, what is the proper way >>>> to get >>>> data for JDK N? Likewise, how should a re-build of the data for JDK >>>> N be >>>> done? >>> >>> What exactly should be there? To the existing description: >>> # to generate (add) data for JDK N, do: >>> # cd make/data/symbols >>> # sh generate-data >>> >>> I've added (in .01): >>> # to regenerate the data for JDK N, run the above commands again >>> >>> What more should be there? >>> >> >> I'd appreciate somewhere to have a textual discussion of how >> make/data/symbols/symbols should be updated, the A = 10, B = 11, etc. >> convention, what else need to be done to generate the contents of this >> changeset. >> >> The is the contents of the build directory? >> >> In general, a description of how the data of JDK N should be added to >> JDK (N+1). > > I've added more textual description to the script, an updated webrev > is here: > http://cr.openjdk.java.net/~jlahoda/8216263/webrev.02/ > > Jan > >> >> Thanks, >> >> -Joe >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Thu Jan 17 17:19:29 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 17 Jan 2019 12:19:29 -0500 Subject: RFR 8214345: Infinite recursion with checking of class bound In-Reply-To: References: Message-ID: looks good, Thanks, Vicente On 1/16/19 9:47 AM, B. Blaser wrote: > Hi, > > Please review the following fix for [1] which simply checks only valid > class bounds per JLS 8.1.4/5: > > http://cr.openjdk.java.net/~bsrbnd/jdk8214345/webrev.00/ > > Thanks (tier1 is OK), > Bernard > > [1] https://bugs.openjdk.java.net/browse/JDK-8214345 From maurizio.cimadamore at oracle.com Thu Jan 17 18:31:43 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 17 Jan 2019 18:31:43 +0000 Subject: RFR JDK-8215470: Bad EnclosingMethod attribute on classes declared in lambdas In-Reply-To: <2b004f09-501f-03b4-c4dd-b6e8e5d14aac@oracle.com> References: <8e0778f7-1827-6864-a7c1-2d03f80f6095@oracle.com> <2b004f09-501f-03b4-c4dd-b6e8e5d14aac@oracle.com> Message-ID: Looks good - all tests clear despite the removals? Maurizio On 17/01/2019 02:15, Vicente Romero wrote: > Hi Maurizio, > > Thanks for your comments. What about [1]? > > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8215470/webrev.01/jdk.dev.patch > > On 1/16/19 4:05 PM, Maurizio Cimadamore wrote: >> The patch looks good - but I have some questions; sometime ago some >> logic was added to LambdaToMethod to handle type variables - see >> LambdaSymbolKind.TypeVar and related code. >> >> I have the vague feeling that this code was added precisely for this >> reason: to fixup issues related to missing type-variable in the >> enclosing method. If now you point to the correct method (as per >> source code), wouldn't this code be redundant? Doing some analysis on >> the code (hg annotate) I was able to get to this bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8005653 >> >> Looking at the synopsis, I see an inner class with an enclosing >> method - and a dandling type variable reference... I think this is >> overlapping with the issue you are trying to fix. >> >> Also, I think it would be nice to have a test which uses reflection >> to poke at the type variables, and checks that the runtime values of >> the type-variables in the local class are indeed the same as the ones >> in the enclosing method. >> >> Maurizio >> >> On 16/01/2019 19:55, Vicente Romero wrote: >>> Please review fix for [1] at [2]. The fix is about pointing the >>> enclosing method attribute of inner classes inside a lambda; to the >>> original method in which the inner class was declared. Currently >>> javac is pointing it to the synthetic method that contains the >>> lambda implementation. Please review the CSR too, >>> >>> Thanks, >>> Vicente >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8215470 >>> [2] http://cr.openjdk.java.net/~vromero/8215470/webrev.00/ >>> [3] https://bugs.openjdk.java.net/browse/JDK-8217272 > From jan.lahoda at oracle.com Thu Jan 17 18:51:42 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 17 Jan 2019 19:51:42 +0100 Subject: RFR: JDK-8217335: Add a script to generate --release data Message-ID: <5C40CEBE.9090300@oracle.com> Hi, As suggested here: https://mail.openjdk.java.net/pipermail/compiler-dev/2019-January/012876.html This is a separate patch that adds a script to generate --release N data. Webrev: http://cr.openjdk.java.net/~jlahoda/8217335/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8217335 Jan From vicente.romero at oracle.com Thu Jan 17 18:50:17 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 17 Jan 2019 13:50:17 -0500 Subject: RFR JDK-8215470: Bad EnclosingMethod attribute on classes declared in lambdas In-Reply-To: References: <8e0778f7-1827-6864-a7c1-2d03f80f6095@oracle.com> <2b004f09-501f-03b4-c4dd-b6e8e5d14aac@oracle.com> Message-ID: On 1/17/19 1:31 PM, Maurizio Cimadamore wrote: > Looks good - all tests clear despite the removals? yes on my local, anyway I will do a test on all platforms before pushing > > Maurizio Thanks, Vicente > > On 17/01/2019 02:15, Vicente Romero wrote: >> Hi Maurizio, >> >> Thanks for your comments. What about [1]? >> >> Vicente >> >> [1] http://cr.openjdk.java.net/~vromero/8215470/webrev.01/jdk.dev.patch >> >> On 1/16/19 4:05 PM, Maurizio Cimadamore wrote: >>> The patch looks good - but I have some questions; sometime ago some >>> logic was added to LambdaToMethod to handle type variables - see >>> LambdaSymbolKind.TypeVar and related code. >>> >>> I have the vague feeling that this code was added precisely for this >>> reason: to fixup issues related to missing type-variable in the >>> enclosing method. If now you point to the correct method (as per >>> source code), wouldn't this code be redundant? Doing some analysis >>> on the code (hg annotate) I was able to get to this bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8005653 >>> >>> Looking at the synopsis, I see an inner class with an enclosing >>> method - and a dandling type variable reference... I think this is >>> overlapping with the issue you are trying to fix. >>> >>> Also, I think it would be nice to have a test which uses reflection >>> to poke at the type variables, and checks that the runtime values of >>> the type-variables in the local class are indeed the same as the >>> ones in the enclosing method. >>> >>> Maurizio >>> >>> On 16/01/2019 19:55, Vicente Romero wrote: >>>> Please review fix for [1] at [2]. The fix is about pointing the >>>> enclosing method attribute of inner classes inside a lambda; to the >>>> original method in which the inner class was declared. Currently >>>> javac is pointing it to the synthetic method that contains the >>>> lambda implementation. Please review the CSR too, >>>> >>>> Thanks, >>>> Vicente >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8215470 >>>> [2] http://cr.openjdk.java.net/~vromero/8215470/webrev.00/ >>>> [3] https://bugs.openjdk.java.net/browse/JDK-8217272 >> From jan.lahoda at oracle.com Thu Jan 17 18:53:23 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 17 Jan 2019 19:53:23 +0100 Subject: RFR(13): JDK-8216263: Add historical data for JDK 12 In-Reply-To: <967fdd5a-9810-4790-a164-2e39394fed66@oracle.com> References: <5C334A87.5080207@oracle.com> <5C33D7E0.2020609@oracle.com> <5C3477B7.8060307@oracle.com> <5C3FD6A8.1080803@oracle.com> <5C40B289.7070408@oracle.com> <967fdd5a-9810-4790-a164-2e39394fed66@oracle.com> Message-ID: <5C40CF23.4050608@oracle.com> On 17.1.2019 17:58, Jonathan Gibbons wrote: > Re: > > 36 # The checkout must not have any local changes that could interfere with the new data. In particular, > 37 # there must be absolutely no changed, new or removed files under the ${JDK_CHECKOUT}/make/data/symbols > 38 # directory. > > That seems like a simple check that could be incorporated into the > script itself. > > But, it also seems reasonable to separate enhancements like that from > the specific issue here, to add historical data for 12. Ok. Sent as: https://mail.openjdk.java.net/pipermail/compiler-dev/2019-January/012879.html And limited this patch to the historical data only: http://cr.openjdk.java.net/~jlahoda/8216263/webrev.03/ Thanks, Jan > > -- Jon > > On 1/17/19 8:51 AM, Jan Lahoda wrote: >> Hi Joe, >> >> On 17.1.2019 02:13, Joseph D. Darcy wrote: >>> Hi Jan, >>> >>> On 1/8/2019 2:13 AM, Jan Lahoda wrote: >>>> Hi Joe, >>>> >>>> Thanks for the comments, some responses inline. Updated webrev: >>>> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.01/ >>>> >>>> On 7.1.2019 23:51, Joseph D. Darcy wrote: >>>>> Hi Jan, >>>>> >>>>> On 1/7/2019 4:48 AM, Jan Lahoda wrote: >>>>>> Hi, >>>>>> >>>>>> To make --release 12 work, we need to add historical data for JDK 12. >>>>>> The current historical data is based on: >>>>>> $ javac -fullversion >>>>>> javac full version "12-ea+26" >>>>>> >>>>>> We may need to update the data once JDK 12 is out to cover any >>>>>> changes >>>>>> to the APIs that might happen. >>>>>> >>>>>> The patch also adds a simple (shell) script to generate the data, so >>>>>> all that was needed to generate the data was: >>>>>> $ cd make/data/symbols >>>>>> $ sh generate-data >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8216263 >>>>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/ >>>>>> >>>>>> How does this look? >>>>> >>>>> If the overhead is small enough and we don't mind a few updates to the >>>>> JDK N+1 data, than perhaps the generation of this information could be >>>>> included as part of the start of JDK N+1 activities. >>>> >>>> That would be perfect! >>>> >>>>> >>>>> I suggest a more extensive description of how to >>>>> make/data/symbols/generate-data. For example, this builds the data for >>>>> the current release independent of whether or not the current release >>>>> has already had its data generated, correct? >>>> >>>> Yes. >>>> >>>>> >>>>> Concretely, if JDK N+1 has already forked, what is the proper way >>>>> to get >>>>> data for JDK N? Likewise, how should a re-build of the data for JDK >>>>> N be >>>>> done? >>>> >>>> What exactly should be there? To the existing description: >>>> # to generate (add) data for JDK N, do: >>>> # cd make/data/symbols >>>> # sh generate-data >>>> >>>> I've added (in .01): >>>> # to regenerate the data for JDK N, run the above commands again >>>> >>>> What more should be there? >>>> >>> >>> I'd appreciate somewhere to have a textual discussion of how >>> make/data/symbols/symbols should be updated, the A = 10, B = 11, etc. >>> convention, what else need to be done to generate the contents of this >>> changeset. >>> >>> The is the contents of the build directory? >>> >>> In general, a description of how the data of JDK N should be added to >>> JDK (N+1). >> >> I've added more textual description to the script, an updated webrev >> is here: >> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.02/ >> >> Jan >> >>> >>> Thanks, >>> >>> -Joe >>> >>> From bsrbnd at gmail.com Thu Jan 17 19:59:15 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Thu, 17 Jan 2019 20:59:15 +0100 Subject: RFR 8214345: Infinite recursion with checking of class bound In-Reply-To: References: Message-ID: Thanks Vicente, I'll push it soon! Cheers, Bernard On Thu, 17 Jan 2019 at 18:19, Vicente Romero wrote: > > looks good, > > Thanks, > Vicente > > On 1/16/19 9:47 AM, B. Blaser wrote: > > Hi, > > > > Please review the following fix for [1] which simply checks only valid > > class bounds per JLS 8.1.4/5: > > > > http://cr.openjdk.java.net/~bsrbnd/jdk8214345/webrev.00/ > > > > Thanks (tier1 is OK), > > Bernard > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8214345 > From joe.darcy at oracle.com Thu Jan 17 20:48:19 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 17 Jan 2019 12:48:19 -0800 Subject: RFR: JDK-8217335: Add a script to generate --release data In-Reply-To: <5C40CEBE.9090300@oracle.com> References: <5C40CEBE.9090300@oracle.com> Message-ID: <04242993-2a85-86ea-3fbd-fd0b82ae627a@oracle.com> Hi Jan, A few minor suggested wording changes: "Open JDK N" -> "OpenJDK N" "include the Mercurial changeset" -> "include the SCM state" Otherwise, looks good. Thanks for adding these docs. Cheers, -Joe On 1/17/2019 10:51 AM, Jan Lahoda wrote: > Hi, > > As suggested here: > https://mail.openjdk.java.net/pipermail/compiler-dev/2019-January/012876.html > > > This is a separate patch that adds a script to generate --release N data. > > Webrev: http://cr.openjdk.java.net/~jlahoda/8217335/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8217335 > > Jan From magnus.ihse.bursie at oracle.com Fri Jan 18 12:59:28 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 18 Jan 2019 13:59:28 +0100 Subject: RFR: JDK-8217335: Add a script to generate --release data In-Reply-To: <5C40CEBE.9090300@oracle.com> References: <5C40CEBE.9090300@oracle.com> Message-ID: On 2019-01-17 19:51, Jan Lahoda wrote: > Hi, > > As suggested here: > https://mail.openjdk.java.net/pipermail/compiler-dev/2019-January/012876.html > > > This is a separate patch that adds a script to generate --release N data. > > Webrev: http://cr.openjdk.java.net/~jlahoda/8217335/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8217335 > > Jan Hi Jan, I would recommend that you place the generate-data script in make/scripts; it's the default location for scripts -- make/data is reserved for, eh, data. :) But a bit more descriptive name would be suitable when moving it away from make/data/symbols -- perhaps generate-symbol-data? Also, the update to the README file does not seem correct. I assume you want to point to the new generate-data script, but the path is wrong (even for the location in your current patch). Finally, we in the build team always appreciates if you cc build-dev for changes in the make directory, even if it's not strictly part of the build system. /Magnus -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Fri Jan 18 13:32:00 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 18 Jan 2019 08:32:00 -0500 Subject: RFR JDK-8215470: Bad EnclosingMethod attribute on classes declared in lambdas In-Reply-To: References: <8e0778f7-1827-6864-a7c1-2d03f80f6095@oracle.com> <2b004f09-501f-03b4-c4dd-b6e8e5d14aac@oracle.com> Message-ID: Hi, I also need a review on the CSR: https://bugs.openjdk.java.net/browse/JDK-8217272 Thanks, Vicente On 1/17/19 1:50 PM, Vicente Romero wrote: > > > On 1/17/19 1:31 PM, Maurizio Cimadamore wrote: >> Looks good - all tests clear despite the removals? > > yes on my local, anyway I will do a test on all platforms before pushing >> >> Maurizio > Thanks, > Vicente >> >> On 17/01/2019 02:15, Vicente Romero wrote: >>> Hi Maurizio, >>> >>> Thanks for your comments. What about [1]? >>> >>> Vicente >>> >>> [1] http://cr.openjdk.java.net/~vromero/8215470/webrev.01/jdk.dev.patch >>> >>> On 1/16/19 4:05 PM, Maurizio Cimadamore wrote: >>>> The patch looks good - but I have some questions; sometime ago some >>>> logic was added to LambdaToMethod to handle type variables - see >>>> LambdaSymbolKind.TypeVar and related code. >>>> >>>> I have the vague feeling that this code was added precisely for >>>> this reason: to fixup issues related to missing type-variable in >>>> the enclosing method. If now you point to the correct method (as >>>> per source code), wouldn't this code be redundant? Doing some >>>> analysis on the code (hg annotate) I was able to get to this bug: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8005653 >>>> >>>> Looking at the synopsis, I see an inner class with an enclosing >>>> method - and a dandling type variable reference... I think this is >>>> overlapping with the issue you are trying to fix. >>>> >>>> Also, I think it would be nice to have a test which uses reflection >>>> to poke at the type variables, and checks that the runtime values >>>> of the type-variables in the local class are indeed the same as the >>>> ones in the enclosing method. >>>> >>>> Maurizio >>>> >>>> On 16/01/2019 19:55, Vicente Romero wrote: >>>>> Please review fix for [1] at [2]. The fix is about pointing the >>>>> enclosing method attribute of inner classes inside a lambda; to >>>>> the original method in which the inner class was declared. >>>>> Currently javac is pointing it to the synthetic method that >>>>> contains the lambda implementation. Please review the CSR too, >>>>> >>>>> Thanks, >>>>> Vicente >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8215470 >>>>> [2] http://cr.openjdk.java.net/~vromero/8215470/webrev.00/ >>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8217272 >>> > From maurizio.cimadamore at oracle.com Fri Jan 18 14:43:46 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 18 Jan 2019 14:43:46 +0000 Subject: RFR JDK-8215470: Bad EnclosingMethod attribute on classes declared in lambdas In-Reply-To: References: <8e0778f7-1827-6864-a7c1-2d03f80f6095@oracle.com> <2b004f09-501f-03b4-c4dd-b6e8e5d14aac@oracle.com> Message-ID: <3d436055-8528-9e2a-53e1-5338577801be@oracle.com> Hi, i think when you say "javac is not in sync with the spec" that's a bit harsh. There are two possible enclosing methods - the synthetic lambda and the 'real' one. There's nothing in the spec suggesting that the enclosingMethod attribute should point one way or another. Also not 100% on 'minimal' as compatibility risk - while it's true that there's no official commitment one way or another, this change will result in behavioral changes with core reflection. Also, I don't think I can think of another case where EnclosingMethod is set to something so that a real classfile method is 'skipped' over. Maurizio On 18/01/2019 13:32, Vicente Romero wrote: > Hi, > > I also need a review on the CSR: > https://bugs.openjdk.java.net/browse/JDK-8217272 > > Thanks, > Vicente > > On 1/17/19 1:50 PM, Vicente Romero wrote: >> >> >> On 1/17/19 1:31 PM, Maurizio Cimadamore wrote: >>> Looks good - all tests clear despite the removals? >> >> yes on my local, anyway I will do a test on all platforms before pushing >>> >>> Maurizio >> Thanks, >> Vicente >>> >>> On 17/01/2019 02:15, Vicente Romero wrote: >>>> Hi Maurizio, >>>> >>>> Thanks for your comments. What about [1]? >>>> >>>> Vicente >>>> >>>> [1] >>>> http://cr.openjdk.java.net/~vromero/8215470/webrev.01/jdk.dev.patch >>>> >>>> On 1/16/19 4:05 PM, Maurizio Cimadamore wrote: >>>>> The patch looks good - but I have some questions; sometime ago >>>>> some logic was added to LambdaToMethod to handle type variables - >>>>> see LambdaSymbolKind.TypeVar and related code. >>>>> >>>>> I have the vague feeling that this code was added precisely for >>>>> this reason: to fixup issues related to missing type-variable in >>>>> the enclosing method. If now you point to the correct method (as >>>>> per source code), wouldn't this code be redundant? Doing some >>>>> analysis on the code (hg annotate) I was able to get to this bug: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8005653 >>>>> >>>>> Looking at the synopsis, I see an inner class with an enclosing >>>>> method - and a dandling type variable reference... I think this is >>>>> overlapping with the issue you are trying to fix. >>>>> >>>>> Also, I think it would be nice to have a test which uses >>>>> reflection to poke at the type variables, and checks that the >>>>> runtime values of the type-variables in the local class are indeed >>>>> the same as the ones in the enclosing method. >>>>> >>>>> Maurizio >>>>> >>>>> On 16/01/2019 19:55, Vicente Romero wrote: >>>>>> Please review fix for [1] at [2]. The fix is about pointing the >>>>>> enclosing method attribute of inner classes inside a lambda; to >>>>>> the original method in which the inner class was declared. >>>>>> Currently javac is pointing it to the synthetic method that >>>>>> contains the lambda implementation. Please review the CSR too, >>>>>> >>>>>> Thanks, >>>>>> Vicente >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8215470 >>>>>> [2] http://cr.openjdk.java.net/~vromero/8215470/webrev.00/ >>>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8217272 >>>> >> > From vicente.romero at oracle.com Fri Jan 18 14:56:34 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 18 Jan 2019 09:56:34 -0500 Subject: RFR JDK-8215470: Bad EnclosingMethod attribute on classes declared in lambdas In-Reply-To: <3d436055-8528-9e2a-53e1-5338577801be@oracle.com> References: <8e0778f7-1827-6864-a7c1-2d03f80f6095@oracle.com> <2b004f09-501f-03b4-c4dd-b6e8e5d14aac@oracle.com> <3d436055-8528-9e2a-53e1-5338577801be@oracle.com> Message-ID: <524adc16-ce94-c73e-a4e4-f24f634645bc@oracle.com> Hi Maurizio, Thanks for your comments, what about now? Vicente On 1/18/19 9:43 AM, Maurizio Cimadamore wrote: > Hi, > i think when you say "javac is not in sync with the spec" that's a bit > harsh. There are two possible enclosing methods - the synthetic lambda > and the 'real' one. There's nothing in the spec suggesting that the > enclosingMethod attribute should point one way or another. > > Also not 100% on 'minimal' as compatibility risk - while it's true > that there's no official commitment one way or another, this change > will result in behavioral changes with core reflection. Also, I don't > think I can think of another case where EnclosingMethod is set to > something so that a real classfile method is 'skipped' over. > > Maurizio > > On 18/01/2019 13:32, Vicente Romero wrote: >> Hi, >> >> I also need a review on the CSR: >> https://bugs.openjdk.java.net/browse/JDK-8217272 >> >> Thanks, >> Vicente >> >> On 1/17/19 1:50 PM, Vicente Romero wrote: >>> >>> >>> On 1/17/19 1:31 PM, Maurizio Cimadamore wrote: >>>> Looks good - all tests clear despite the removals? >>> >>> yes on my local, anyway I will do a test on all platforms before >>> pushing >>>> >>>> Maurizio >>> Thanks, >>> Vicente >>>> >>>> On 17/01/2019 02:15, Vicente Romero wrote: >>>>> Hi Maurizio, >>>>> >>>>> Thanks for your comments. What about [1]? >>>>> >>>>> Vicente >>>>> >>>>> [1] >>>>> http://cr.openjdk.java.net/~vromero/8215470/webrev.01/jdk.dev.patch >>>>> >>>>> On 1/16/19 4:05 PM, Maurizio Cimadamore wrote: >>>>>> The patch looks good - but I have some questions; sometime ago >>>>>> some logic was added to LambdaToMethod to handle type variables - >>>>>> see LambdaSymbolKind.TypeVar and related code. >>>>>> >>>>>> I have the vague feeling that this code was added precisely for >>>>>> this reason: to fixup issues related to missing type-variable in >>>>>> the enclosing method. If now you point to the correct method (as >>>>>> per source code), wouldn't this code be redundant? Doing some >>>>>> analysis on the code (hg annotate) I was able to get to this bug: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8005653 >>>>>> >>>>>> Looking at the synopsis, I see an inner class with an enclosing >>>>>> method - and a dandling type variable reference... I think this >>>>>> is overlapping with the issue you are trying to fix. >>>>>> >>>>>> Also, I think it would be nice to have a test which uses >>>>>> reflection to poke at the type variables, and checks that the >>>>>> runtime values of the type-variables in the local class are >>>>>> indeed the same as the ones in the enclosing method. >>>>>> >>>>>> Maurizio >>>>>> >>>>>> On 16/01/2019 19:55, Vicente Romero wrote: >>>>>>> Please review fix for [1] at [2]. The fix is about pointing the >>>>>>> enclosing method attribute of inner classes inside a lambda; to >>>>>>> the original method in which the inner class was declared. >>>>>>> Currently javac is pointing it to the synthetic method that >>>>>>> contains the lambda implementation. Please review the CSR too, >>>>>>> >>>>>>> Thanks, >>>>>>> Vicente >>>>>>> >>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8215470 >>>>>>> [2] http://cr.openjdk.java.net/~vromero/8215470/webrev.00/ >>>>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8217272 >>>>> >>> >> From maurizio.cimadamore at oracle.com Fri Jan 18 14:58:28 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 18 Jan 2019 14:58:28 +0000 Subject: RFR JDK-8215470: Bad EnclosingMethod attribute on classes declared in lambdas In-Reply-To: <524adc16-ce94-c73e-a4e4-f24f634645bc@oracle.com> References: <8e0778f7-1827-6864-a7c1-2d03f80f6095@oracle.com> <2b004f09-501f-03b4-c4dd-b6e8e5d14aac@oracle.com> <3d436055-8528-9e2a-53e1-5338577801be@oracle.com> <524adc16-ce94-c73e-a4e4-f24f634645bc@oracle.com> Message-ID: Looks good Maurizio On 18/01/2019 14:56, Vicente Romero wrote: > Hi Maurizio, > > Thanks for your comments, what about now? > > Vicente > > On 1/18/19 9:43 AM, Maurizio Cimadamore wrote: >> Hi, >> i think when you say "javac is not in sync with the spec" that's a >> bit harsh. There are two possible enclosing methods - the synthetic >> lambda and the 'real' one. There's nothing in the spec suggesting >> that the enclosingMethod attribute should point one way or another. >> >> Also not 100% on 'minimal' as compatibility risk - while it's true >> that there's no official commitment one way or another, this change >> will result in behavioral changes with core reflection. Also, I don't >> think I can think of another case where EnclosingMethod is set to >> something so that a real classfile method is 'skipped' over. >> >> Maurizio >> >> On 18/01/2019 13:32, Vicente Romero wrote: >>> Hi, >>> >>> I also need a review on the CSR: >>> https://bugs.openjdk.java.net/browse/JDK-8217272 >>> >>> Thanks, >>> Vicente >>> >>> On 1/17/19 1:50 PM, Vicente Romero wrote: >>>> >>>> >>>> On 1/17/19 1:31 PM, Maurizio Cimadamore wrote: >>>>> Looks good - all tests clear despite the removals? >>>> >>>> yes on my local, anyway I will do a test on all platforms before >>>> pushing >>>>> >>>>> Maurizio >>>> Thanks, >>>> Vicente >>>>> >>>>> On 17/01/2019 02:15, Vicente Romero wrote: >>>>>> Hi Maurizio, >>>>>> >>>>>> Thanks for your comments. What about [1]? >>>>>> >>>>>> Vicente >>>>>> >>>>>> [1] >>>>>> http://cr.openjdk.java.net/~vromero/8215470/webrev.01/jdk.dev.patch >>>>>> >>>>>> On 1/16/19 4:05 PM, Maurizio Cimadamore wrote: >>>>>>> The patch looks good - but I have some questions; sometime ago >>>>>>> some logic was added to LambdaToMethod to handle type variables >>>>>>> - see LambdaSymbolKind.TypeVar and related code. >>>>>>> >>>>>>> I have the vague feeling that this code was added precisely for >>>>>>> this reason: to fixup issues related to missing type-variable in >>>>>>> the enclosing method. If now you point to the correct method (as >>>>>>> per source code), wouldn't this code be redundant? Doing some >>>>>>> analysis on the code (hg annotate) I was able to get to this bug: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8005653 >>>>>>> >>>>>>> Looking at the synopsis, I see an inner class with an enclosing >>>>>>> method - and a dandling type variable reference... I think this >>>>>>> is overlapping with the issue you are trying to fix. >>>>>>> >>>>>>> Also, I think it would be nice to have a test which uses >>>>>>> reflection to poke at the type variables, and checks that the >>>>>>> runtime values of the type-variables in the local class are >>>>>>> indeed the same as the ones in the enclosing method. >>>>>>> >>>>>>> Maurizio >>>>>>> >>>>>>> On 16/01/2019 19:55, Vicente Romero wrote: >>>>>>>> Please review fix for [1] at [2]. The fix is about pointing the >>>>>>>> enclosing method attribute of inner classes inside a lambda; to >>>>>>>> the original method in which the inner class was declared. >>>>>>>> Currently javac is pointing it to the synthetic method that >>>>>>>> contains the lambda implementation. Please review the CSR too, >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vicente >>>>>>>> >>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8215470 >>>>>>>> [2] http://cr.openjdk.java.net/~vromero/8215470/webrev.00/ >>>>>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8217272 >>>>>> >>>> >>> > From vicente.romero at oracle.com Fri Jan 18 15:48:40 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 18 Jan 2019 10:48:40 -0500 Subject: RFR JDK-8215470: Bad EnclosingMethod attribute on classes declared in lambdas In-Reply-To: References: <8e0778f7-1827-6864-a7c1-2d03f80f6095@oracle.com> <2b004f09-501f-03b4-c4dd-b6e8e5d14aac@oracle.com> <3d436055-8528-9e2a-53e1-5338577801be@oracle.com> <524adc16-ce94-c73e-a4e4-f24f634645bc@oracle.com> Message-ID: thanks Vicente On 1/18/19 9:58 AM, Maurizio Cimadamore wrote: > Looks good > > Maurizio > > On 18/01/2019 14:56, Vicente Romero wrote: >> Hi Maurizio, >> >> Thanks for your comments, what about now? >> >> Vicente >> >> On 1/18/19 9:43 AM, Maurizio Cimadamore wrote: >>> Hi, >>> i think when you say "javac is not in sync with the spec" that's a >>> bit harsh. There are two possible enclosing methods - the synthetic >>> lambda and the 'real' one. There's nothing in the spec suggesting >>> that the enclosingMethod attribute should point one way or another. >>> >>> Also not 100% on 'minimal' as compatibility risk - while it's true >>> that there's no official commitment one way or another, this change >>> will result in behavioral changes with core reflection. Also, I >>> don't think I can think of another case where EnclosingMethod is set >>> to something so that a real classfile method is 'skipped' over. >>> >>> Maurizio >>> >>> On 18/01/2019 13:32, Vicente Romero wrote: >>>> Hi, >>>> >>>> I also need a review on the CSR: >>>> https://bugs.openjdk.java.net/browse/JDK-8217272 >>>> >>>> Thanks, >>>> Vicente >>>> >>>> On 1/17/19 1:50 PM, Vicente Romero wrote: >>>>> >>>>> >>>>> On 1/17/19 1:31 PM, Maurizio Cimadamore wrote: >>>>>> Looks good - all tests clear despite the removals? >>>>> >>>>> yes on my local, anyway I will do a test on all platforms before >>>>> pushing >>>>>> >>>>>> Maurizio >>>>> Thanks, >>>>> Vicente >>>>>> >>>>>> On 17/01/2019 02:15, Vicente Romero wrote: >>>>>>> Hi Maurizio, >>>>>>> >>>>>>> Thanks for your comments. What about [1]? >>>>>>> >>>>>>> Vicente >>>>>>> >>>>>>> [1] >>>>>>> http://cr.openjdk.java.net/~vromero/8215470/webrev.01/jdk.dev.patch >>>>>>> >>>>>>> On 1/16/19 4:05 PM, Maurizio Cimadamore wrote: >>>>>>>> The patch looks good - but I have some questions; sometime ago >>>>>>>> some logic was added to LambdaToMethod to handle type variables >>>>>>>> - see LambdaSymbolKind.TypeVar and related code. >>>>>>>> >>>>>>>> I have the vague feeling that this code was added precisely for >>>>>>>> this reason: to fixup issues related to missing type-variable >>>>>>>> in the enclosing method. If now you point to the correct method >>>>>>>> (as per source code), wouldn't this code be redundant? Doing >>>>>>>> some analysis on the code (hg annotate) I was able to get to >>>>>>>> this bug: >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8005653 >>>>>>>> >>>>>>>> Looking at the synopsis, I see an inner class with an enclosing >>>>>>>> method - and a dandling type variable reference... I think this >>>>>>>> is overlapping with the issue you are trying to fix. >>>>>>>> >>>>>>>> Also, I think it would be nice to have a test which uses >>>>>>>> reflection to poke at the type variables, and checks that the >>>>>>>> runtime values of the type-variables in the local class are >>>>>>>> indeed the same as the ones in the enclosing method. >>>>>>>> >>>>>>>> Maurizio >>>>>>>> >>>>>>>> On 16/01/2019 19:55, Vicente Romero wrote: >>>>>>>>> Please review fix for [1] at [2]. The fix is about pointing >>>>>>>>> the enclosing method attribute of inner classes inside a >>>>>>>>> lambda; to the original method in which the inner class was >>>>>>>>> declared. Currently javac is pointing it to the synthetic >>>>>>>>> method that contains the lambda implementation. Please review >>>>>>>>> the CSR too, >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vicente >>>>>>>>> >>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8215470 >>>>>>>>> [2] http://cr.openjdk.java.net/~vromero/8215470/webrev.00/ >>>>>>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8217272 >>>>>>> >>>>> >>>> >> From jan.lahoda at oracle.com Fri Jan 18 17:05:59 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 18 Jan 2019 18:05:59 +0100 Subject: RFR: JDK-8217335: Add a script to generate --release data In-Reply-To: References: <5C40CEBE.9090300@oracle.com> Message-ID: <5C420777.6080007@oracle.com> Hi Magnus, Thanks for the comments, an updated webrev: http://cr.openjdk.java.net/~jlahoda/8217335/webrev.01/ (Includes changes suggested by Joe was well). Jan On 18.1.2019 13:59, Magnus Ihse Bursie wrote: > On 2019-01-17 19:51, Jan Lahoda wrote: >> Hi, >> >> As suggested here: >> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-January/012876.html >> >> >> This is a separate patch that adds a script to generate --release N data. >> >> Webrev: http://cr.openjdk.java.net/~jlahoda/8217335/webrev.00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8217335 >> >> Jan > Hi Jan, > > I would recommend that you place the generate-data script in > make/scripts; it's the default location for scripts -- make/data is > reserved for, eh, data. :) But a bit more descriptive name would be > suitable when moving it away from make/data/symbols -- perhaps > generate-symbol-data? > > Also, the update to the README file does not seem correct. I assume you > want to point to the new generate-data script, but the path is wrong > (even for the location in your current patch). > > Finally, we in the build team always appreciates if you cc build-dev for > changes in the make directory, even if it's not strictly part of the > build system. > > /Magnus From jan.lahoda at oracle.com Fri Jan 18 17:06:44 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 18 Jan 2019 18:06:44 +0100 Subject: RFR(13): JDK-8216263: Add historical data for JDK 12 In-Reply-To: <5C40CF23.4050608@oracle.com> References: <5C334A87.5080207@oracle.com> <5C33D7E0.2020609@oracle.com> <5C3477B7.8060307@oracle.com> <5C3FD6A8.1080803@oracle.com> <5C40B289.7070408@oracle.com> <967fdd5a-9810-4790-a164-2e39394fed66@oracle.com> <5C40CF23.4050608@oracle.com> Message-ID: <5C4207A4.1040203@oracle.com> Adding build-dev. Jan On 17.1.2019 19:53, Jan Lahoda wrote: > On 17.1.2019 17:58, Jonathan Gibbons wrote: >> Re: >> >> 36 # The checkout must not have any local changes that could >> interfere with the new data. In particular, >> 37 # there must be absolutely no changed, new or removed files >> under the ${JDK_CHECKOUT}/make/data/symbols >> 38 # directory. >> >> That seems like a simple check that could be incorporated into the >> script itself. >> >> But, it also seems reasonable to separate enhancements like that from >> the specific issue here, to add historical data for 12. > > Ok. Sent as: > https://mail.openjdk.java.net/pipermail/compiler-dev/2019-January/012879.html > > > And limited this patch to the historical data only: > http://cr.openjdk.java.net/~jlahoda/8216263/webrev.03/ > > Thanks, > Jan > >> >> -- Jon >> >> On 1/17/19 8:51 AM, Jan Lahoda wrote: >>> Hi Joe, >>> >>> On 17.1.2019 02:13, Joseph D. Darcy wrote: >>>> Hi Jan, >>>> >>>> On 1/8/2019 2:13 AM, Jan Lahoda wrote: >>>>> Hi Joe, >>>>> >>>>> Thanks for the comments, some responses inline. Updated webrev: >>>>> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.01/ >>>>> >>>>> On 7.1.2019 23:51, Joseph D. Darcy wrote: >>>>>> Hi Jan, >>>>>> >>>>>> On 1/7/2019 4:48 AM, Jan Lahoda wrote: >>>>>>> Hi, >>>>>>> >>>>>>> To make --release 12 work, we need to add historical data for JDK >>>>>>> 12. >>>>>>> The current historical data is based on: >>>>>>> $ javac -fullversion >>>>>>> javac full version "12-ea+26" >>>>>>> >>>>>>> We may need to update the data once JDK 12 is out to cover any >>>>>>> changes >>>>>>> to the APIs that might happen. >>>>>>> >>>>>>> The patch also adds a simple (shell) script to generate the data, so >>>>>>> all that was needed to generate the data was: >>>>>>> $ cd make/data/symbols >>>>>>> $ sh generate-data >>>>>>> >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8216263 >>>>>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/ >>>>>>> >>>>>>> How does this look? >>>>>> >>>>>> If the overhead is small enough and we don't mind a few updates to >>>>>> the >>>>>> JDK N+1 data, than perhaps the generation of this information >>>>>> could be >>>>>> included as part of the start of JDK N+1 activities. >>>>> >>>>> That would be perfect! >>>>> >>>>>> >>>>>> I suggest a more extensive description of how to >>>>>> make/data/symbols/generate-data. For example, this builds the data >>>>>> for >>>>>> the current release independent of whether or not the current release >>>>>> has already had its data generated, correct? >>>>> >>>>> Yes. >>>>> >>>>>> >>>>>> Concretely, if JDK N+1 has already forked, what is the proper way >>>>>> to get >>>>>> data for JDK N? Likewise, how should a re-build of the data for JDK >>>>>> N be >>>>>> done? >>>>> >>>>> What exactly should be there? To the existing description: >>>>> # to generate (add) data for JDK N, do: >>>>> # cd make/data/symbols >>>>> # sh generate-data >>>>> >>>>> I've added (in .01): >>>>> # to regenerate the data for JDK N, run the above commands again >>>>> >>>>> What more should be there? >>>>> >>>> >>>> I'd appreciate somewhere to have a textual discussion of how >>>> make/data/symbols/symbols should be updated, the A = 10, B = 11, etc. >>>> convention, what else need to be done to generate the contents of this >>>> changeset. >>>> >>>> The is the contents of the build directory? >>>> >>>> In general, a description of how the data of JDK N should be added to >>>> JDK (N+1). >>> >>> I've added more textual description to the script, an updated webrev >>> is here: >>> http://cr.openjdk.java.net/~jlahoda/8216263/webrev.02/ >>> >>> Jan >>> >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>>> From jonathan.gibbons at oracle.com Fri Jan 18 19:53:43 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 18 Jan 2019 11:53:43 -0800 Subject: RFR: [XS] JDK-8217395: Update langtools shell tests to use ${EXE_SUFFIX} Message-ID: <743a3fd0-9019-662b-a3a7-5b6e1fe2ee78@oracle.com> Please review this small change to have langtools shell tests support the use of ${EXE_SUFFIX} to allow the optional use of .exe as a suffix in the path for Windows binaries in shell scripts. langtools has only a few shell tests remaining, all in a single directory, and all using a single shared setup script. The change is small enough to be given inline, below.? The change is benign if EXE_SUFFIX is not set; it is assumed that the variable will be set if needed when the test run. -- Jon JBS: https://bugs.openjdk.java.net/browse/JDK-8217395 $ hg diff diff -r a99bd2570660 test/langtools/tools/javac/Paths/Util.sh --- a/test/langtools/tools/javac/Paths/Util.sh? Fri Jan 18 11:26:30 2019 -0800 +++ b/test/langtools/tools/javac/Paths/Util.sh? Fri Jan 18 11:39:31 2019 -0800 @@ -24,10 +24,10 @@ ?# Utilities for shell tests ?: ${TESTSRC=.} ${TESTCLASSES=.} -? java="${TESTJAVA+${TESTJAVA}/bin/}java" - javac="${TESTJAVA+${TESTJAVA}/bin/}javac" -?? jar="${TESTJAVA+${TESTJAVA}/bin/}jar" -jimage="${TESTJAVA+${TESTJAVA}/bin/}jimage" +? java="${TESTJAVA+${TESTJAVA}/bin/}java${EXE_SUFFIX}" + javac="${TESTJAVA+${TESTJAVA}/bin/}javac${EXE_SUFFIX}" +?? jar="${TESTJAVA+${TESTJAVA}/bin/}jar${EXE_SUFFIX}" +jimage="${TESTJAVA+${TESTJAVA}/bin/}jimage${EXE_SUFFIX}" ?case `uname -s` in ?? Windows*|CYGWIN*) From joe.darcy at oracle.com Fri Jan 18 20:05:52 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 18 Jan 2019 12:05:52 -0800 Subject: RFR: [XS] JDK-8217395: Update langtools shell tests to use ${EXE_SUFFIX} In-Reply-To: <743a3fd0-9019-662b-a3a7-5b6e1fe2ee78@oracle.com> References: <743a3fd0-9019-662b-a3a7-5b6e1fe2ee78@oracle.com> Message-ID: Looks fine; cheers, -Joe On 1/18/2019 11:53 AM, Jonathan Gibbons wrote: > Please review this small change to have langtools shell tests support > the use of ${EXE_SUFFIX} to allow the optional use of .exe as a suffix > in the path for Windows binaries in shell scripts. > > langtools has only a few shell tests remaining, all in a single > directory, and all using a single shared setup script. > > The change is small enough to be given inline, below.? The change is > benign if EXE_SUFFIX is not set; it is assumed that the variable will > be set if needed when the test run. > > -- Jon > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8217395 > > > $ hg diff > diff -r a99bd2570660 test/langtools/tools/javac/Paths/Util.sh > --- a/test/langtools/tools/javac/Paths/Util.sh? Fri Jan 18 11:26:30 > 2019 -0800 > +++ b/test/langtools/tools/javac/Paths/Util.sh? Fri Jan 18 11:39:31 > 2019 -0800 > @@ -24,10 +24,10 @@ > ?# Utilities for shell tests > > ?: ${TESTSRC=.} ${TESTCLASSES=.} > -? java="${TESTJAVA+${TESTJAVA}/bin/}java" > - javac="${TESTJAVA+${TESTJAVA}/bin/}javac" > -?? jar="${TESTJAVA+${TESTJAVA}/bin/}jar" > -jimage="${TESTJAVA+${TESTJAVA}/bin/}jimage" > +? java="${TESTJAVA+${TESTJAVA}/bin/}java${EXE_SUFFIX}" > + javac="${TESTJAVA+${TESTJAVA}/bin/}javac${EXE_SUFFIX}" > +?? jar="${TESTJAVA+${TESTJAVA}/bin/}jar${EXE_SUFFIX}" > +jimage="${TESTJAVA+${TESTJAVA}/bin/}jimage${EXE_SUFFIX}" > > ?case `uname -s` in > ?? Windows*|CYGWIN*) > From magnus.ihse.bursie at oracle.com Mon Jan 21 10:14:23 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 21 Jan 2019 11:14:23 +0100 Subject: RFR: JDK-8217335: Add a script to generate --release data In-Reply-To: <5C420777.6080007@oracle.com> References: <5C40CEBE.9090300@oracle.com> <5C420777.6080007@oracle.com> Message-ID: <55467651-7090-0c6b-fbf3-7bbde0119b65@oracle.com> On 2019-01-18 18:05, Jan Lahoda wrote: > Hi Magnus, > > Thanks for the comments, an updated webrev: > http://cr.openjdk.java.net/~jlahoda/8217335/webrev.01/ > > (Includes changes suggested by Joe was well). Looks good to me! /Magnus > > Jan > > On 18.1.2019 13:59, Magnus Ihse Bursie wrote: >> On 2019-01-17 19:51, Jan Lahoda wrote: >>> Hi, >>> >>> As suggested here: >>> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-January/012876.html >>> >>> >>> >>> This is a separate patch that adds a script to generate --release N >>> data. >>> >>> Webrev: http://cr.openjdk.java.net/~jlahoda/8217335/webrev.00/ >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8217335 >>> >>> Jan >> Hi Jan, >> >> I would recommend that you place the generate-data script in >> make/scripts; it's the default location for scripts -- make/data is >> reserved for, eh, data. :) But a bit more descriptive name would be >> suitable when moving it away from make/data/symbols -- perhaps >> generate-symbol-data? >> >> Also, the update to the README file does not seem correct. I assume you >> want to point to the new generate-data script, but the path is wrong >> (even for the location in your current patch). >> >> Finally, we in the build team always appreciates if you cc build-dev for >> changes in the make directory, even if it's not strictly part of the >> build system. >> >> /Magnus -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Mon Jan 21 12:32:37 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 21 Jan 2019 13:32:37 +0100 Subject: RFR(13): JDK-8217047: Provide a way to inject missing parameter names Message-ID: <5C45BBE5.6030007@oracle.com> Hi, When a type is load from a classfile, and some or all of its methods have neither the MethodParameters or LocalVariableTable attributes, then the parameters of the methods have an artificial synthesized name, which is visible through VariableElement.getSimpleName(). The proposal here is to allow to plug in an external provider that could provide more user-friendly names lazily/on demand. These could originate e.g. in adjacent sources. JBS: https://bugs.openjdk.java.net/browse/JDK-8217437 Webrev: http://cr.openjdk.java.net/~jlahoda/8217047/webrev.01/ Specdiff: http://cr.openjdk.java.net/~jlahoda/8217047/specdiff.01/overview-summary.html CSR: https://bugs.openjdk.java.net/browse/JDK-8217437 What do you think? Thanks, Jan From jan.lahoda at oracle.com Tue Jan 22 13:43:18 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 22 Jan 2019 14:43:18 +0100 Subject: RFR: JDK-8217381: Inconvenient errors reported when annotation processor generates source file and errors in the same round Message-ID: <5C471DF6.9030707@oracle.com> Hi, When an annotation processor generates a source and an error in the same round, javac (may) print errors saying it cannot find the types from the generated source. The proposal here is to improve the errors by deferring recoverable error until the newly generated source is analyzed. JBS: https://bugs.openjdk.java.net/browse/JDK-8217381 Webrev: http://cr.openjdk.java.net/~jlahoda/8217381/webrev.00/ How does this look? Thanks, Jan From antoniocortes at google.com Wed Jan 23 20:54:49 2019 From: antoniocortes at google.com (Antonio Cortes Perez) Date: Wed, 23 Jan 2019 12:54:49 -0800 Subject: JCFunctionalExpression targets Message-ID: While visiting a CompilationUnitTree, I need to access the target(s) of a LambdaExpressionTree and a MemberReferenceTree. Right now, I am downcasting them to the underlying (non-public) JCFunctionalExpression and directly accessing the member variable ?targets?. Is there a simple public API to obtain the same data? Something like Trees.getX Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Thu Jan 24 13:52:00 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Thu, 24 Jan 2019 14:52:00 +0100 Subject: RFR: JDK-8193367: Annotated type variable bounds crash javac In-Reply-To: References: <9417eb26-0b85-41c5-102d-241df719076f@oracle.com> Message-ID: On Mon, 18 Jun 2018 at 22:09, Maurizio Cimadamore wrote: > > Also, note that there's another related method: getUpperBound. This is > *almost* like getBound() but it does few extra checks on top. > > While, I'm confident that this patch is not risky, I'm a bit worried > that exposing yet another accessor will create confusion to clients - > should they use Type::getUpperBound, Types::upperBound, or the new > Type::bound/getBound? > > I wonder if we need some consolidation here before moving forward with > the fix Done some weeks ago: http://cr.openjdk.java.net/~bsrbnd/jdk8193367/webrev.00/ Tier1 was OK at that time, thoughts? Thanks! Ciao, Bernard From maurizio.cimadamore at oracle.com Thu Jan 24 14:29:59 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 24 Jan 2019 14:29:59 +0000 Subject: RFR: JDK-8193367: Annotated type variable bounds crash javac In-Reply-To: References: <9417eb26-0b85-41c5-102d-241df719076f@oracle.com> Message-ID: <8a1a38f4-3562-4550-5b6d-8fed618b7373@oracle.com> I'm a bit confused (but it could also be because I'm misremembering) - wasn't the whole point of the exercise to have cloned type variables to piggy back on the clonee's getUpperBound? In the patch I see this: @Override 1640 public TypeVar cloneWithMetadata(TypeMetadata md) { 1641 return new TypeVar(tsym, getUpperBound(), lower, md) { 1642 @Override 1643 public Type baseType() { return TypeVar.this.baseType(); } 1644 }; 1645 } Which doesn't seem better than the current code - e.g. the upper bound is fetched when the cloned var is created, so, if the bound is updated after the fact, such changes will not be reflected in the clones var? Maurizio On 24/01/2019 13:52, B. Blaser wrote: > On Mon, 18 Jun 2018 at 22:09, Maurizio Cimadamore > wrote: >> Also, note that there's another related method: getUpperBound. This is >> *almost* like getBound() but it does few extra checks on top. >> >> While, I'm confident that this patch is not risky, I'm a bit worried >> that exposing yet another accessor will create confusion to clients - >> should they use Type::getUpperBound, Types::upperBound, or the new >> Type::bound/getBound? >> >> I wonder if we need some consolidation here before moving forward with >> the fix > Done some weeks ago: > > http://cr.openjdk.java.net/~bsrbnd/jdk8193367/webrev.00/ > > Tier1 was OK at that time, thoughts? > Thanks! > > Ciao, > Bernard -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Thu Jan 24 15:49:36 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Thu, 24 Jan 2019 16:49:36 +0100 Subject: RFR: JDK-8193367: Annotated type variable bounds crash javac In-Reply-To: <8a1a38f4-3562-4550-5b6d-8fed618b7373@oracle.com> References: <9417eb26-0b85-41c5-102d-241df719076f@oracle.com> <8a1a38f4-3562-4550-5b6d-8fed618b7373@oracle.com> Message-ID: On Thu, 24 Jan 2019 at 15:30, Maurizio Cimadamore wrote: > > I'm a bit confused (but it could also be because I'm misremembering) - wasn't the whole point of the exercise to have cloned type variables to piggy back on the clonee's getUpperBound? > > In the patch I see this: > > @Override > 1640 public TypeVar cloneWithMetadata(TypeMetadata md) { > 1641 return new TypeVar(tsym, getUpperBound(), lower, md) { > 1642 @Override > 1643 public Type baseType() { return TypeVar.this.baseType(); } > 1644 }; > 1645 } > > > Which doesn't seem better than the current code - e.g. the upper bound is fetched when the cloned var is created, so, if the bound is updated after the fact, such changes will not be reflected in the clones var? The current getUpperBound() sets the clone's bound to the clonee's bound (tsym.type.getUpperBound()) at every invocation while still unset (null or tag=NONE): http://hg.openjdk.java.net/jdk/jdk/file/525f212f1bda/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java#l1659 which is exactly what we need in our issue (see Types::getBounds). Overriding the accessor in cloneWithMetadata() is then no more necessary. This fixes the issue and tests are clean. Do we agree? Bernard From maurizio.cimadamore at oracle.com Thu Jan 24 15:56:23 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 24 Jan 2019 15:56:23 +0000 Subject: RFR: JDK-8193367: Annotated type variable bounds crash javac In-Reply-To: References: <9417eb26-0b85-41c5-102d-241df719076f@oracle.com> <8a1a38f4-3562-4550-5b6d-8fed618b7373@oracle.com> Message-ID: <76e27e4a-c895-b653-7ea1-ad37f2aee464@oracle.com> On 24/01/2019 15:49, B. Blaser wrote: > On Thu, 24 Jan 2019 at 15:30, Maurizio Cimadamore > wrote: >> I'm a bit confused (but it could also be because I'm misremembering) - wasn't the whole point of the exercise to have cloned type variables to piggy back on the clonee's getUpperBound? >> >> In the patch I see this: >> >> @Override >> 1640 public TypeVar cloneWithMetadata(TypeMetadata md) { >> 1641 return new TypeVar(tsym, getUpperBound(), lower, md) { >> 1642 @Override >> 1643 public Type baseType() { return TypeVar.this.baseType(); } >> 1644 }; >> 1645 } >> >> >> Which doesn't seem better than the current code - e.g. the upper bound is fetched when the cloned var is created, so, if the bound is updated after the fact, such changes will not be reflected in the clones var? > The current getUpperBound() sets the clone's bound to the clonee's > bound (tsym.type.getUpperBound()) at every invocation while still > unset (null or tag=NONE): > > http://hg.openjdk.java.net/jdk/jdk/file/525f212f1bda/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java#l1659 > > which is exactly what we need in our issue (see Types::getBounds). > Overriding the accessor in cloneWithMetadata() is then no more > necessary. > > This fixes the issue and tests are clean. Urgh - I forgot that getUpperBound was side-effecting things. That said, this side-effect thing really does come from the very first type annotation push back in 2013! Back then the compiler was using a different architecture for supporting type annotations (there was an explicit AnnotatedType) - so I believe this could be a leftover of that era. Now that you have properly encapsulated access to the bound, I bet that this hack can go away, and you should be able to mimic current behavior by overriding the 'getUpperBound' in the cloned type variable. Maurizio > > Do we agree? > > Bernard From bsrbnd at gmail.com Thu Jan 24 17:48:25 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Thu, 24 Jan 2019 18:48:25 +0100 Subject: RFR: JDK-8193367: Annotated type variable bounds crash javac In-Reply-To: <76e27e4a-c895-b653-7ea1-ad37f2aee464@oracle.com> References: <9417eb26-0b85-41c5-102d-241df719076f@oracle.com> <8a1a38f4-3562-4550-5b6d-8fed618b7373@oracle.com> <76e27e4a-c895-b653-7ea1-ad37f2aee464@oracle.com> Message-ID: On Thu, 24 Jan 2019 at 16:56, Maurizio Cimadamore wrote: > > Urgh - I forgot that getUpperBound was side-effecting things. > > That said, this side-effect thing really does come from the very first > type annotation push back in 2013! Back then the compiler was using a > different architecture for supporting type annotations (there was an > explicit AnnotatedType) - so I believe this could be a leftover of that era. > > Now that you have properly encapsulated access to the bound, I bet that > this hack can go away, and you should be able to mimic current behavior > by overriding the 'getUpperBound' in the cloned type variable. Yes, as here under (only Type.java, the other files are identical to webrev.00). Issue and tests are OK, seems good? Bernard diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java @@ -896,7 +896,7 @@ if (moreInfo && bound != null && !isPrintingBound) try { isPrintingBound = true; - s.append("{:").append(bound.bound).append(":}"); + s.append("{:").append(bound.getUpperBound()).append(":}"); } finally { isPrintingBound = false; } @@ -1607,7 +1607,7 @@ * itself. Furthermore, the erasure_field of the class * points to the first class or interface bound. */ - public Type bound = null; + private Type _bound = null; /** The lower bound of this type variable. * TypeVars don't normally have a lower bound, so it is normally set @@ -1620,7 +1620,7 @@ super(null, TypeMetadata.EMPTY); Assert.checkNonNull(lower); tsym = new TypeVariableSymbol(0, name, this, owner); - this.bound = null; + this.setUpperBound(null); this.lower = lower; } @@ -1632,15 +1632,20 @@ TypeMetadata metadata) { super(tsym, metadata); Assert.checkNonNull(lower); - this.bound = bound; + this.setUpperBound(bound); this.lower = lower; } @Override public TypeVar cloneWithMetadata(TypeMetadata md) { - return new TypeVar(tsym, bound, lower, md) { + return new TypeVar(tsym, getUpperBound(), lower, md) { @Override public Type baseType() { return TypeVar.this.baseType(); } + + @Override @DefinedBy(Api.LANGUAGE_MODEL) + public Type getUpperBound() { return TypeVar.this.getUpperBound(); } + + public void setUpperBound(Type bound) { TypeVar.this.setUpperBound(bound); } }; } @@ -1655,12 +1660,9 @@ } @Override @DefinedBy(Api.LANGUAGE_MODEL) - public Type getUpperBound() { - if ((bound == null || bound.hasTag(NONE)) && this != tsym.type) { - bound = tsym.type.getUpperBound(); - } - return bound; - } + public Type getUpperBound() { return _bound; } + + public void setUpperBound(Type bound) { this._bound = bound; } int rank_field = -1; @@ -1709,7 +1711,7 @@ WildcardType wildcard) { super(name, owner, lower); this.lower = Assert.checkNonNull(lower); - this.bound = upper; + this.setUpperBound(upper); this.wildcard = wildcard; } @@ -1725,9 +1727,14 @@ @Override public CapturedType cloneWithMetadata(TypeMetadata md) { - return new CapturedType(tsym, bound, bound, lower, wildcard, md) { + return new CapturedType(tsym, getUpperBound(), getUpperBound(), lower, wildcard, md) { @Override public Type baseType() { return CapturedType.this.baseType(); } + + @Override @DefinedBy(Api.LANGUAGE_MODEL) + public Type getUpperBound() { return CapturedType.this.getUpperBound(); } + + public void setUpperBound(Type bound) { CapturedType.this.setUpperBound(bound); } }; } @@ -1832,7 +1839,7 @@ public void complete() { for (List l = tvars; l.nonEmpty(); l = l.tail) { - ((TypeVar)l.head).bound.complete(); + ((TypeVar)l.head).getUpperBound().complete(); } qtype.complete(); } From maurizio.cimadamore at oracle.com Thu Jan 24 18:20:57 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 24 Jan 2019 18:20:57 +0000 Subject: RFR: JDK-8193367: Annotated type variable bounds crash javac In-Reply-To: References: <9417eb26-0b85-41c5-102d-241df719076f@oracle.com> <8a1a38f4-3562-4550-5b6d-8fed618b7373@oracle.com> <76e27e4a-c895-b653-7ea1-ad37f2aee464@oracle.com> Message-ID: On 24/01/2019 17:48, B. Blaser wrote: > On Thu, 24 Jan 2019 at 16:56, Maurizio Cimadamore > wrote: >> Urgh - I forgot that getUpperBound was side-effecting things. >> >> That said, this side-effect thing really does come from the very first >> type annotation push back in 2013! Back then the compiler was using a >> different architecture for supporting type annotations (there was an >> explicit AnnotatedType) - so I believe this could be a leftover of that era. >> >> Now that you have properly encapsulated access to the bound, I bet that >> this hack can go away, and you should be able to mimic current behavior >> by overriding the 'getUpperBound' in the cloned type variable. > Yes, as here under (only Type.java, the other files are identical to webrev.00). > Issue and tests are OK, seems good? > Bernard Yep - this seems like a good cleanup! Maurizio > > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java > @@ -896,7 +896,7 @@ > if (moreInfo && bound != null && !isPrintingBound) > try { > isPrintingBound = true; > - s.append("{:").append(bound.bound).append(":}"); > + s.append("{:").append(bound.getUpperBound()).append(":}"); > } finally { > isPrintingBound = false; > } > @@ -1607,7 +1607,7 @@ > * itself. Furthermore, the erasure_field of the class > * points to the first class or interface bound. > */ > - public Type bound = null; > + private Type _bound = null; > > /** The lower bound of this type variable. > * TypeVars don't normally have a lower bound, so it is normally set > @@ -1620,7 +1620,7 @@ > super(null, TypeMetadata.EMPTY); > Assert.checkNonNull(lower); > tsym = new TypeVariableSymbol(0, name, this, owner); > - this.bound = null; > + this.setUpperBound(null); > this.lower = lower; > } > > @@ -1632,15 +1632,20 @@ > TypeMetadata metadata) { > super(tsym, metadata); > Assert.checkNonNull(lower); > - this.bound = bound; > + this.setUpperBound(bound); > this.lower = lower; > } > > @Override > public TypeVar cloneWithMetadata(TypeMetadata md) { > - return new TypeVar(tsym, bound, lower, md) { > + return new TypeVar(tsym, getUpperBound(), lower, md) { > @Override > public Type baseType() { return TypeVar.this.baseType(); } > + > + @Override @DefinedBy(Api.LANGUAGE_MODEL) > + public Type getUpperBound() { return > TypeVar.this.getUpperBound(); } > + > + public void setUpperBound(Type bound) { > TypeVar.this.setUpperBound(bound); } > }; > } > > @@ -1655,12 +1660,9 @@ > } > > @Override @DefinedBy(Api.LANGUAGE_MODEL) > - public Type getUpperBound() { > - if ((bound == null || bound.hasTag(NONE)) && this != tsym.type) { > - bound = tsym.type.getUpperBound(); > - } > - return bound; > - } > + public Type getUpperBound() { return _bound; } > + > + public void setUpperBound(Type bound) { this._bound = bound; } > > int rank_field = -1; > > @@ -1709,7 +1711,7 @@ > WildcardType wildcard) { > super(name, owner, lower); > this.lower = Assert.checkNonNull(lower); > - this.bound = upper; > + this.setUpperBound(upper); > this.wildcard = wildcard; > } > > @@ -1725,9 +1727,14 @@ > > @Override > public CapturedType cloneWithMetadata(TypeMetadata md) { > - return new CapturedType(tsym, bound, bound, lower, wildcard, md) { > + return new CapturedType(tsym, getUpperBound(), > getUpperBound(), lower, wildcard, md) { > @Override > public Type baseType() { return CapturedType.this.baseType(); } > + > + @Override @DefinedBy(Api.LANGUAGE_MODEL) > + public Type getUpperBound() { return > CapturedType.this.getUpperBound(); } > + > + public void setUpperBound(Type bound) { > CapturedType.this.setUpperBound(bound); } > }; > } > > @@ -1832,7 +1839,7 @@ > > public void complete() { > for (List l = tvars; l.nonEmpty(); l = l.tail) { > - ((TypeVar)l.head).bound.complete(); > + ((TypeVar)l.head).getUpperBound().complete(); > } > qtype.complete(); > } From vicente.romero at oracle.com Thu Jan 24 18:29:13 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 24 Jan 2019 13:29:13 -0500 Subject: RFR: JDK-8193367: Annotated type variable bounds crash javac In-Reply-To: References: <9417eb26-0b85-41c5-102d-241df719076f@oracle.com> <8a1a38f4-3562-4550-5b6d-8fed618b7373@oracle.com> <76e27e4a-c895-b653-7ea1-ad37f2aee464@oracle.com> Message-ID: <877ddd7f-9bbb-abb3-8e1e-30d70715b3d6@oracle.com> last diff looks good to me too, Vicente On 1/24/19 12:48 PM, B. Blaser wrote: > On Thu, 24 Jan 2019 at 16:56, Maurizio Cimadamore > wrote: >> Urgh - I forgot that getUpperBound was side-effecting things. >> >> That said, this side-effect thing really does come from the very first >> type annotation push back in 2013! Back then the compiler was using a >> different architecture for supporting type annotations (there was an >> explicit AnnotatedType) - so I believe this could be a leftover of that era. >> >> Now that you have properly encapsulated access to the bound, I bet that >> this hack can go away, and you should be able to mimic current behavior >> by overriding the 'getUpperBound' in the cloned type variable. > Yes, as here under (only Type.java, the other files are identical to webrev.00). > Issue and tests are OK, seems good? > Bernard > > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java > @@ -896,7 +896,7 @@ > if (moreInfo && bound != null && !isPrintingBound) > try { > isPrintingBound = true; > - s.append("{:").append(bound.bound).append(":}"); > + s.append("{:").append(bound.getUpperBound()).append(":}"); > } finally { > isPrintingBound = false; > } > @@ -1607,7 +1607,7 @@ > * itself. Furthermore, the erasure_field of the class > * points to the first class or interface bound. > */ > - public Type bound = null; > + private Type _bound = null; > > /** The lower bound of this type variable. > * TypeVars don't normally have a lower bound, so it is normally set > @@ -1620,7 +1620,7 @@ > super(null, TypeMetadata.EMPTY); > Assert.checkNonNull(lower); > tsym = new TypeVariableSymbol(0, name, this, owner); > - this.bound = null; > + this.setUpperBound(null); > this.lower = lower; > } > > @@ -1632,15 +1632,20 @@ > TypeMetadata metadata) { > super(tsym, metadata); > Assert.checkNonNull(lower); > - this.bound = bound; > + this.setUpperBound(bound); > this.lower = lower; > } > > @Override > public TypeVar cloneWithMetadata(TypeMetadata md) { > - return new TypeVar(tsym, bound, lower, md) { > + return new TypeVar(tsym, getUpperBound(), lower, md) { > @Override > public Type baseType() { return TypeVar.this.baseType(); } > + > + @Override @DefinedBy(Api.LANGUAGE_MODEL) > + public Type getUpperBound() { return > TypeVar.this.getUpperBound(); } > + > + public void setUpperBound(Type bound) { > TypeVar.this.setUpperBound(bound); } > }; > } > > @@ -1655,12 +1660,9 @@ > } > > @Override @DefinedBy(Api.LANGUAGE_MODEL) > - public Type getUpperBound() { > - if ((bound == null || bound.hasTag(NONE)) && this != tsym.type) { > - bound = tsym.type.getUpperBound(); > - } > - return bound; > - } > + public Type getUpperBound() { return _bound; } > + > + public void setUpperBound(Type bound) { this._bound = bound; } > > int rank_field = -1; > > @@ -1709,7 +1711,7 @@ > WildcardType wildcard) { > super(name, owner, lower); > this.lower = Assert.checkNonNull(lower); > - this.bound = upper; > + this.setUpperBound(upper); > this.wildcard = wildcard; > } > > @@ -1725,9 +1727,14 @@ > > @Override > public CapturedType cloneWithMetadata(TypeMetadata md) { > - return new CapturedType(tsym, bound, bound, lower, wildcard, md) { > + return new CapturedType(tsym, getUpperBound(), > getUpperBound(), lower, wildcard, md) { > @Override > public Type baseType() { return CapturedType.this.baseType(); } > + > + @Override @DefinedBy(Api.LANGUAGE_MODEL) > + public Type getUpperBound() { return > CapturedType.this.getUpperBound(); } > + > + public void setUpperBound(Type bound) { > CapturedType.this.setUpperBound(bound); } > }; > } > > @@ -1832,7 +1839,7 @@ > > public void complete() { > for (List l = tvars; l.nonEmpty(); l = l.tail) { > - ((TypeVar)l.head).bound.complete(); > + ((TypeVar)l.head).getUpperBound().complete(); > } > qtype.complete(); > } From eolivelli at gmail.com Fri Jan 25 20:44:11 2019 From: eolivelli at gmail.com (Enrico Olivelli) Date: Fri, 25 Jan 2019 21:44:11 +0100 Subject: spotBugs and JDK-8194978: Javac produces dead code for try-with-resource In-Reply-To: References: <25e5d853-e4d4-41aa-8221-00462389fc67@oracle.com> <5BE60326.4090202@oracle.com> Message-ID: Up Regards Enrico Il 10 gen 2019 8:13 PM, "Enrico Olivelli" ha scritto: > Kindly pinging on this.. > > Cheers > Enrico > > Il lun 7 gen 2019, 14:28 Enrico Olivelli ha scritto: > >> Two questions/ideas: >> 1) Wouldn't it be possible for javac to annotate such code blocks and >> write into the class file that that code is "synthetic" ? I really >> don't know where to store such flags, but maybe someone could >> elaborate more this idea >> 2) Why isn't javac adding the "$closeResource" method ? >> >> Enrico >> >> Il giorno ven 9 nov 2018 alle ore 23:01 Alex Buckley >> ha scritto: >> > >> > On 11/9/2018 12:31 PM, Vicente Romero wrote: >> > > My evaluation on this issue is that javac is generating code >> > > according to the spec, see JLS11 14.20.3.1 [1]. There is an explicit >> > > check for null on the resource before invoking the close() method. >> > > This is the null check javac is generating. >> > >> > I confirm that the explicit null check on the resource variable is >> > required, per the translation in >> > https://docs.oracle.com/javase/specs/jls/se11/html/ >> jls-14.html#jls-14.20.3.1-140 >> > -- it has been specified that way since JLS7. >> > >> > > Fix for JDK-8194978 went a bit further trying to eliminate dead code >> > > for some cases for which javac could statically determine that the >> > > resource would be different from null. In particular if the resource >> > > was initialized with a new class expression. >> > >> > I confirm it's acceptable to not perform the null check in generated >> > code if you can prove the resource variable is non-null. Frankly, >> > though, there is so much that can occur in a "new class expression" -- >> > `new Outer(a(b(c)))<>.new Inner(d(e(f)))` -- that I would be >> > wary of trying to prove anything. >> > >> > > It could be argued that we could try to analyze the body and if we >> > > find out that a NPE must be thrown in the body of the try, then the >> > > null check on the resource would be deemed unnecessary. But then we >> > > can get to an implementation that will be out of sync with the spec >> > > plus it probably won't cover all cases. >> > >> > Right, let's not be too clever. >> > >> > Alex >> > >> > > Thanks, >> > > Vicente >> > > >> > > [1] >> > > https://docs.oracle.com/javase/specs/jls/se11/html/ >> jls-14.html#jls-14.20.3.1 >> > > >> > > On 11/9/18 10:22 AM, Ismael Juma wrote: >> > >> Any comments on this? Many people are disabling spotBugs when >> > >> compiling with Java 11 due to this issue: >> > >> >> > >> https://github.com/spotbugs/spotbugs/issues/756 >> > >> >> > >> Ismael >> > >> >> > >> On Thu, Sep 13, 2018 at 10:05 PM Ismael Juma > > >> > wrote: >> > >> >> > >> Hi all, >> > >> >> > >> JDK-8194978 introduced some changes to the bytecode generated by >> > >> javac for the try with resource construct. In the following code, >> > >> it seems to generate a null check on a reference after invoking a >> > >> method on it: >> > >> >> > >> public static void readFileAsString(String path) throws >> > >> IOException { >> > >> try (FileChannel fc = FileChannel.open(Paths.get(path))) >> { >> > >> fc.size(); >> > >> } >> > >> >> > >> } >> > >> >> > >> In line 16 to 22 of the bytecode, it looks like we check for null >> > >> after calling a method on the fc reference: >> > >> >> > >> 16: aload_1 >> > >> 17: invokevirtual #6 // Method >> > >> java/nio/channels/FileChannel.size:()J >> > >> 20: pop2 >> > >> 21: aload_1 >> > >> 22: ifnull 52 >> > >> 25: aload_1 >> > >> 26: invokevirtual #7 // Method >> > >> java/nio/channels/FileChannel.close:()V >> > >> >> > >> Is this intentional? I ask because this pattern triggers a >> > >> spotBugs warning since it often implies a bug in user's code: >> > >> >> > >> RCN | Nullcheck of fc at line 10 of value previously dereferenced >> > >> in TryTest.readFileAsString(String, Charset) >> > >> >> > >> Note that this works fine in Java versions older than Java 11. >> > >> Since this spotBugs warning is generally useful, it would be >> handy >> > >> if javac did not trigger it. Alternatively, if there's a good way >> > >> to detect the code that was generated by javac, spotBugs could be >> > >> updated to ignore it. For reference, this was discussed in the >> > >> spotBugs issue tracker: >> > >> >> > >> https://github.com/spotbugs/spotbugs/issues/756 >> > >> >> > >> And method bytecode in full: >> > >> >> > >> public static void readFileAsString(java.lang.String) throws >> > >> java.io.IOException; >> > >> Code: >> > >> 0: aload_0 >> > >> 1: iconst_0 >> > >> 2: anewarray #2 // class >> java/lang/String >> > >> 5: invokestatic #3 // Method >> > >> java/nio/file/Paths.get:(Ljava/lang/String;[Ljava/lang/ >> String;)Ljava/nio/file/Path; >> > >> 8: iconst_0 >> > >> 9: anewarray #4 // class >> > >> java/nio/file/OpenOption >> > >> 12: invokestatic #5 // Method >> > >> java/nio/channels/FileChannel.open:(Ljava/nio/ >> file/Path;[Ljava/nio/file/OpenOption;)Ljava/nio/channels/FileChannel; >> > >> 15: astore_1 >> > >> 16: aload_1 >> > >> 17: invokevirtual #6 // Method >> > >> java/nio/channels/FileChannel.size:()J >> > >> 20: pop2 >> > >> 21: aload_1 >> > >> 22: ifnull 52 >> > >> 25: aload_1 >> > >> 26: invokevirtual #7 // Method >> > >> java/nio/channels/FileChannel.close:()V >> > >> 29: goto 52 >> > >> 32: astore_2 >> > >> 33: aload_1 >> > >> 34: ifnull 50 >> > >> 37: aload_1 >> > >> 38: invokevirtual #7 // Method >> > >> java/nio/channels/FileChannel.close:()V >> > >> 41: goto 50 >> > >> 44: astore_3 >> > >> 45: aload_2 >> > >> 46: aload_3 >> > >> 47: invokevirtual #9 // Method >> > >> java/lang/Throwable.addSuppressed:(Ljava/lang/Throwable;)V >> > >> 50: aload_2 >> > >> 51: athrow >> > >> 52: return >> > >> Exception table: >> > >> from to target type >> > >> 16 21 32 Class java/lang/Throwable >> > >> 37 41 44 Class java/lang/Throwable >> > >> >> > >> Thanks, >> > >> Ismael >> > >> >> > > >> > -- > > > -- Enrico Olivelli > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Sat Jan 26 15:34:53 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Sat, 26 Jan 2019 16:34:53 +0100 Subject: RFR: JDK-8193367: Annotated type variable bounds crash javac In-Reply-To: <877ddd7f-9bbb-abb3-8e1e-30d70715b3d6@oracle.com> References: <9417eb26-0b85-41c5-102d-241df719076f@oracle.com> <8a1a38f4-3562-4550-5b6d-8fed618b7373@oracle.com> <76e27e4a-c895-b653-7ea1-ad37f2aee464@oracle.com> <877ddd7f-9bbb-abb3-8e1e-30d70715b3d6@oracle.com> Message-ID: On Thu, 24 Jan 2019 at 19:29, Vicente Romero wrote: > > last diff looks good to me too, > > Vicente Thanks for both reviews, pushed as: http://hg.openjdk.java.net/jdk/jdk/rev/a772e65727c5 I note something strange with JBS: https://bugs.openjdk.java.net/browse/JDK-8193367 I wasn't able to remove 'tbd_minor' (because it was archived) when setting the fix version to 13 and it was reset to 'tbd_minor' when pushing :-( Any idea? Thanks, Bernard From tiago.nogueira at visionspace.com Mon Jan 28 10:00:12 2019 From: tiago.nogueira at visionspace.com (Tiago Nogueira) Date: Mon, 28 Jan 2019 11:00:12 +0100 Subject: Revive support for SPARC V8 Message-ID: Hello, I'm new to the mailing list, and i just hope this is the right place to bring this up. Support for SPARC V8 was removed in 2013 (see https://bugs.openjdk.java.net/browse/JDK-8017756). The argument at the time was that SPARC V8 hardware was not used any more (see https://bugs.openjdk.java.net/browse/JDK-8008407). Well, it turns out that the the space industry has finally caught up, and the new generation of radiation hardened SoCs, at least in Europe, will be based on SPARC V8 (see https://www.gaisler.com/doc/gr740/GR740-OVERVIEW.pdf ). What would be the effort to revive support for SPARC V8? I think this would be a great opportunity to get Java running on rad-hard hardware in low Earth orbit and beyond... Thanks Tiago -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Mon Jan 28 11:02:24 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 28 Jan 2019 06:02:24 -0500 Subject: RFR: JDK-8193367: Annotated type variable bounds crash javac In-Reply-To: References: <9417eb26-0b85-41c5-102d-241df719076f@oracle.com> <8a1a38f4-3562-4550-5b6d-8fed618b7373@oracle.com> <76e27e4a-c895-b653-7ea1-ad37f2aee464@oracle.com> <877ddd7f-9bbb-abb3-8e1e-30d70715b3d6@oracle.com> Message-ID: <94a16fad-f431-70fa-550e-5872b3994c09@oracle.com> On 1/26/19 10:34 AM, B. Blaser wrote: > On Thu, 24 Jan 2019 at 19:29, Vicente Romero wrote: >> last diff looks good to me too, >> >> Vicente > Thanks for both reviews, pushed as: > http://hg.openjdk.java.net/jdk/jdk/rev/a772e65727c5 > > I note something strange with JBS: > https://bugs.openjdk.java.net/browse/JDK-8193367 > > I wasn't able to remove 'tbd_minor' (because it was archived) when > setting the fix version to 13 and it was reset to 'tbd_minor' when > pushing :-( > > Any idea? not sure what happened, anyway I manually added 13 as fix version, although tbd_minor is still being listed > > Thanks, > Bernard Vicente From vicente.romero at oracle.com Mon Jan 28 11:33:43 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 28 Jan 2019 06:33:43 -0500 Subject: spotBugs and JDK-8194978: Javac produces dead code for try-with-resource In-Reply-To: References: <25e5d853-e4d4-41aa-8221-00462389fc67@oracle.com> <5BE60326.4090202@oracle.com> Message-ID: <24d27cba-1272-3423-75ef-77b48a89e548@oracle.com> Hi, On 1/25/19 3:44 PM, Enrico Olivelli wrote: > Up > > Regards > Enrico > > Il 10 gen 2019 8:13 PM, "Enrico Olivelli" > ha scritto: > > Kindly pinging on this.. > > Cheers > Enrico > > Il lun 7 gen 2019, 14:28 Enrico Olivelli > ha scritto: > > Two questions/ideas: > 1) Wouldn't it be possible for javac to annotate such code > blocks and > write into the class file that that code is "synthetic" ? I really > don't know where to store such flags, but maybe someone could > elaborate more this idea > I don't think that this is a good idea. There is no perfect fix in this area as we have discussed. Adding annotations to blocks doesn't seems like the right direction here > 2) Why isn't javac adding? the "$closeResource" method ? > that method is not being generated anymore in recent versions of javac > > Enrico > Vicente > > Il giorno ven 9 nov 2018 alle ore 23:01 Alex Buckley > > ha > scritto: > > > > On 11/9/2018 12:31 PM, Vicente Romero wrote: > > > My evaluation on this issue is that javac is generating code > > > according to the spec, see JLS11 14.20.3.1 [1]. There is > an explicit > > > check for null on the resource before invoking the close() > method. > > > This is the null check javac is generating. > > > > I confirm that the explicit null check on the resource > variable is > > required, per the translation in > > > https://docs.oracle.com/javase/specs/jls/se11/html/jls-14.html#jls-14.20.3.1-140 > > > -- it has been specified that way since JLS7. > > > > > Fix for JDK-8194978 went a bit further trying to eliminate > dead code > > > for some cases for which javac could statically determine > that the > > > resource would be different from null. In particular if > the resource > > > was initialized with a new class expression. > > > > I confirm it's acceptable to not perform the null check in > generated > > code if you can prove the resource variable is non-null. > Frankly, > > though, there is so much that can occur in a "new class > expression" -- > > `new Outer(a(b(c)))<>.new Inner(d(e(f)))` -- that I > would be > > wary of trying to prove anything. > > > > > It could be argued that we could try to analyze the body > and if we > > > find out that a NPE must be thrown in the body of the try, > then the > > > null check on the resource would be deemed unnecessary. > But then we > > > can get to an implementation that will be out of sync with > the spec > > > plus it probably won't cover all cases. > > > > Right, let's not be too clever. > > > > Alex > > > > > Thanks, > > > Vicente > > > > > > [1] > > > > https://docs.oracle.com/javase/specs/jls/se11/html/jls-14.html#jls-14.20.3.1 > > > > > > > On 11/9/18 10:22 AM, Ismael Juma wrote: > > >> Any comments on this? Many people are disabling spotBugs when > > >> compiling with Java 11 due to this issue: > > >> > > >> https://github.com/spotbugs/spotbugs/issues/756 > > > >> > > >> Ismael > > >> > > >> On Thu, Sep 13, 2018 at 10:05 PM Ismael Juma > > > >> >> wrote: > > >> > > >>? ? ?Hi all, > > >> > > >>? ? ?JDK-8194978 introduced some changes to the bytecode > generated by > > >>? ? ?javac for the try with resource construct. In the > following code, > > >>? ? ?it seems to generate a null check on a reference > after invoking a > > >>? ? ?method on it: > > >> > > >>? ? ? ? ?public static void readFileAsString(String path) > throws > > >>? ? ?IOException { > > >>? ? ? ? ? ? ?try (FileChannel fc = > FileChannel.open(Paths.get(path))) { > > >>? ? ? ? ? ? ? ? ?fc.size(); > > >>? ? ? ? ? ? ?} > > >> > > >>? ? ? ? ?} > > >> > > >>? ? ?In line 16 to 22 of the bytecode, it looks like we > check for null > > >>? ? ?after calling a method on the fc reference: > > >> > > >>? ? ? ? ? ?16: aload_1 > > >>? ? ? ? ? ?17: invokevirtual #6 ? ? ? ? // Method > > >>? ? ?java/nio/channels/FileChannel.size:()J > > >>? ? ? ? ? ?20: pop2 > > >>? ? ? ? ? ?21: aload_1 > > >>? ? ? ? ? ?22: ifnull? ? ? ? 52 > > >>? ? ? ? ? ?25: aload_1 > > >>? ? ? ? ? ?26: invokevirtual #7 ? ? ? ? // Method > > >>? ? ?java/nio/channels/FileChannel.close:()V > > >> > > >>? ? ?Is this intentional? I ask because this pattern > triggers a > > >>? ? ?spotBugs warning since it often implies a bug in > user's code: > > >> > > >>? ? ?RCN | Nullcheck of fc at line 10 of value previously > dereferenced > > >>? ? ?in TryTest.readFileAsString(String, Charset) > > >> > > >>? ? ?Note that this works fine in Java versions older than > Java 11. > > >>? ? ?Since this spotBugs warning is generally useful, it > would be handy > > >>? ? ?if javac did not trigger it. Alternatively, if > there's a good way > > >>? ? ?to detect the code that was generated by javac, > spotBugs could be > > >>? ? ?updated to ignore it. For reference, this was > discussed in the > > >>? ? ?spotBugs issue tracker: > > >> > > >> https://github.com/spotbugs/spotbugs/issues/756 > > > >> > > >>? ? ?And method bytecode in full: > > >> > > >>? ? ? ?public static void > readFileAsString(java.lang.String) throws > > >>? ? ?java.io.IOException; > > >>? ? ? ? ?Code: > > >>? ? ? ? ? ? 0: aload_0 > > >>? ? ? ? ? ? 1: iconst_0 > > >>? ? ? ? ? ? 2: anewarray? ? ?#2 ? ? ? ? // class > java/lang/String > > >>? ? ? ? ? ? 5: invokestatic? #3 ? ? ? ? // Method > > >>? ? > ?java/nio/file/Paths.get:(Ljava/lang/String;[Ljava/lang/String;)Ljava/nio/file/Path; > > >>? ? ? ? ? ? 8: iconst_0 > > >>? ? ? ? ? ? 9: anewarray? ? ?#4 ? ? ? ? // class > > >>? ? ?java/nio/file/OpenOption > > >>? ? ? ? ? ?12: invokestatic? #5 ? ? ? ? // Method > > >>? ? > ?java/nio/channels/FileChannel.open:(Ljava/nio/file/Path;[Ljava/nio/file/OpenOption;)Ljava/nio/channels/FileChannel; > > >>? ? ? ? ? ?15: astore_1 > > >>? ? ? ? ? ?16: aload_1 > > >>? ? ? ? ? ?17: invokevirtual #6 ? ? ? ? // Method > > >>? ? ?java/nio/channels/FileChannel.size:()J > > >>? ? ? ? ? ?20: pop2 > > >>? ? ? ? ? ?21: aload_1 > > >>? ? ? ? ? ?22: ifnull? ? ? ? 52 > > >>? ? ? ? ? ?25: aload_1 > > >>? ? ? ? ? ?26: invokevirtual #7 ? ? ? ? // Method > > >>? ? ?java/nio/channels/FileChannel.close:()V > > >>? ? ? ? ? ?29: goto? ? ? ? ? 52 > > >>? ? ? ? ? ?32: astore_2 > > >>? ? ? ? ? ?33: aload_1 > > >>? ? ? ? ? ?34: ifnull? ? ? ? 50 > > >>? ? ? ? ? ?37: aload_1 > > >>? ? ? ? ? ?38: invokevirtual #7 ? ? ? ? // Method > > >>? ? ?java/nio/channels/FileChannel.close:()V > > >>? ? ? ? ? ?41: goto? ? ? ? ? 50 > > >>? ? ? ? ? ?44: astore_3 > > >>? ? ? ? ? ?45: aload_2 > > >>? ? ? ? ? ?46: aload_3 > > >>? ? ? ? ? ?47: invokevirtual #9 ? ? ? ? // Method > > >>? ? > ?java/lang/Throwable.addSuppressed:(Ljava/lang/Throwable;)V > > >>? ? ? ? ? ?50: aload_2 > > >>? ? ? ? ? ?51: athrow > > >>? ? ? ? ? ?52: return > > >>? ? ? ? ?Exception table: > > >>? ? ? ? ? ? from? ? to? target type > > >>? ? ? ? ? ? ? ?16? ? 21? ? 32? ?Class java/lang/Throwable > > >>? ? ? ? ? ? ? ?37? ? 41? ? 44? ?Class java/lang/Throwable > > >> > > >>? ? ?Thanks, > > >>? ? ?Ismael > > >> > > > > > -- > > > -- Enrico Olivelli > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eolivelli at gmail.com Mon Jan 28 11:37:11 2019 From: eolivelli at gmail.com (Enrico Olivelli) Date: Mon, 28 Jan 2019 12:37:11 +0100 Subject: spotBugs and JDK-8194978: Javac produces dead code for try-with-resource In-Reply-To: <24d27cba-1272-3423-75ef-77b48a89e548@oracle.com> References: <25e5d853-e4d4-41aa-8221-00462389fc67@oracle.com> <5BE60326.4090202@oracle.com> <24d27cba-1272-3423-75ef-77b48a89e548@oracle.com> Message-ID: Vicente I see your concerns, I just wanted to try to suggest an alternative. I guess it will be up to spotbugs team to solve the issue somehow Thank you very much Enrico Il giorno lun 28 gen 2019 alle ore 12:33 Vicente Romero ha scritto: > > Hi, > > On 1/25/19 3:44 PM, Enrico Olivelli wrote: > > Up > > Regards > Enrico > > Il 10 gen 2019 8:13 PM, "Enrico Olivelli" ha scritto: >> >> Kindly pinging on this.. >> >> Cheers >> Enrico >> >> Il lun 7 gen 2019, 14:28 Enrico Olivelli ha scritto: >>> >>> Two questions/ideas: >>> 1) Wouldn't it be possible for javac to annotate such code blocks and >>> write into the class file that that code is "synthetic" ? I really >>> don't know where to store such flags, but maybe someone could >>> elaborate more this idea > > > I don't think that this is a good idea. There is no perfect fix in this area as we have discussed. Adding annotations to blocks doesn't seems like the right direction here > >>> 2) Why isn't javac adding the "$closeResource" method ? > > > that method is not being generated anymore in recent versions of javac > >>> >>> Enrico > > > Vicente > >>> >>> Il giorno ven 9 nov 2018 alle ore 23:01 Alex Buckley >>> ha scritto: >>> > >>> > On 11/9/2018 12:31 PM, Vicente Romero wrote: >>> > > My evaluation on this issue is that javac is generating code >>> > > according to the spec, see JLS11 14.20.3.1 [1]. There is an explicit >>> > > check for null on the resource before invoking the close() method. >>> > > This is the null check javac is generating. >>> > >>> > I confirm that the explicit null check on the resource variable is >>> > required, per the translation in >>> > https://docs.oracle.com/javase/specs/jls/se11/html/jls-14.html#jls-14.20.3.1-140 >>> > -- it has been specified that way since JLS7. >>> > >>> > > Fix for JDK-8194978 went a bit further trying to eliminate dead code >>> > > for some cases for which javac could statically determine that the >>> > > resource would be different from null. In particular if the resource >>> > > was initialized with a new class expression. >>> > >>> > I confirm it's acceptable to not perform the null check in generated >>> > code if you can prove the resource variable is non-null. Frankly, >>> > though, there is so much that can occur in a "new class expression" -- >>> > `new Outer(a(b(c)))<>.new Inner(d(e(f)))` -- that I would be >>> > wary of trying to prove anything. >>> > >>> > > It could be argued that we could try to analyze the body and if we >>> > > find out that a NPE must be thrown in the body of the try, then the >>> > > null check on the resource would be deemed unnecessary. But then we >>> > > can get to an implementation that will be out of sync with the spec >>> > > plus it probably won't cover all cases. >>> > >>> > Right, let's not be too clever. >>> > >>> > Alex >>> > >>> > > Thanks, >>> > > Vicente >>> > > >>> > > [1] >>> > > https://docs.oracle.com/javase/specs/jls/se11/html/jls-14.html#jls-14.20.3.1 >>> > > >>> > > On 11/9/18 10:22 AM, Ismael Juma wrote: >>> > >> Any comments on this? Many people are disabling spotBugs when >>> > >> compiling with Java 11 due to this issue: >>> > >> >>> > >> https://github.com/spotbugs/spotbugs/issues/756 >>> > >> >>> > >> Ismael >>> > >> >>> > >> On Thu, Sep 13, 2018 at 10:05 PM Ismael Juma >> > >> > wrote: >>> > >> >>> > >> Hi all, >>> > >> >>> > >> JDK-8194978 introduced some changes to the bytecode generated by >>> > >> javac for the try with resource construct. In the following code, >>> > >> it seems to generate a null check on a reference after invoking a >>> > >> method on it: >>> > >> >>> > >> public static void readFileAsString(String path) throws >>> > >> IOException { >>> > >> try (FileChannel fc = FileChannel.open(Paths.get(path))) { >>> > >> fc.size(); >>> > >> } >>> > >> >>> > >> } >>> > >> >>> > >> In line 16 to 22 of the bytecode, it looks like we check for null >>> > >> after calling a method on the fc reference: >>> > >> >>> > >> 16: aload_1 >>> > >> 17: invokevirtual #6 // Method >>> > >> java/nio/channels/FileChannel.size:()J >>> > >> 20: pop2 >>> > >> 21: aload_1 >>> > >> 22: ifnull 52 >>> > >> 25: aload_1 >>> > >> 26: invokevirtual #7 // Method >>> > >> java/nio/channels/FileChannel.close:()V >>> > >> >>> > >> Is this intentional? I ask because this pattern triggers a >>> > >> spotBugs warning since it often implies a bug in user's code: >>> > >> >>> > >> RCN | Nullcheck of fc at line 10 of value previously dereferenced >>> > >> in TryTest.readFileAsString(String, Charset) >>> > >> >>> > >> Note that this works fine in Java versions older than Java 11. >>> > >> Since this spotBugs warning is generally useful, it would be handy >>> > >> if javac did not trigger it. Alternatively, if there's a good way >>> > >> to detect the code that was generated by javac, spotBugs could be >>> > >> updated to ignore it. For reference, this was discussed in the >>> > >> spotBugs issue tracker: >>> > >> >>> > >> https://github.com/spotbugs/spotbugs/issues/756 >>> > >> >>> > >> And method bytecode in full: >>> > >> >>> > >> public static void readFileAsString(java.lang.String) throws >>> > >> java.io.IOException; >>> > >> Code: >>> > >> 0: aload_0 >>> > >> 1: iconst_0 >>> > >> 2: anewarray #2 // class java/lang/String >>> > >> 5: invokestatic #3 // Method >>> > >> java/nio/file/Paths.get:(Ljava/lang/String;[Ljava/lang/String;)Ljava/nio/file/Path; >>> > >> 8: iconst_0 >>> > >> 9: anewarray #4 // class >>> > >> java/nio/file/OpenOption >>> > >> 12: invokestatic #5 // Method >>> > >> java/nio/channels/FileChannel.open:(Ljava/nio/file/Path;[Ljava/nio/file/OpenOption;)Ljava/nio/channels/FileChannel; >>> > >> 15: astore_1 >>> > >> 16: aload_1 >>> > >> 17: invokevirtual #6 // Method >>> > >> java/nio/channels/FileChannel.size:()J >>> > >> 20: pop2 >>> > >> 21: aload_1 >>> > >> 22: ifnull 52 >>> > >> 25: aload_1 >>> > >> 26: invokevirtual #7 // Method >>> > >> java/nio/channels/FileChannel.close:()V >>> > >> 29: goto 52 >>> > >> 32: astore_2 >>> > >> 33: aload_1 >>> > >> 34: ifnull 50 >>> > >> 37: aload_1 >>> > >> 38: invokevirtual #7 // Method >>> > >> java/nio/channels/FileChannel.close:()V >>> > >> 41: goto 50 >>> > >> 44: astore_3 >>> > >> 45: aload_2 >>> > >> 46: aload_3 >>> > >> 47: invokevirtual #9 // Method >>> > >> java/lang/Throwable.addSuppressed:(Ljava/lang/Throwable;)V >>> > >> 50: aload_2 >>> > >> 51: athrow >>> > >> 52: return >>> > >> Exception table: >>> > >> from to target type >>> > >> 16 21 32 Class java/lang/Throwable >>> > >> 37 41 44 Class java/lang/Throwable >>> > >> >>> > >> Thanks, >>> > >> Ismael >>> > >> >>> > > >> >> -- >> >> >> -- Enrico Olivelli > > From jan.lahoda at oracle.com Mon Jan 28 13:40:23 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 28 Jan 2019 14:40:23 +0100 Subject: spotBugs and JDK-8194978: Javac produces dead code for try-with-resource In-Reply-To: References: <25e5d853-e4d4-41aa-8221-00462389fc67@oracle.com> <5BE60326.4090202@oracle.com> Message-ID: <5C4F0647.2010809@oracle.com> Hi Enrico, One thing I'd like to point out is that I don't think that JDK-8194978 added any new checks. There have been improvements to the try-with-resources desugaring over the past years, usually with the goal of making the bytecode shorter. So, for example, having: try (InputStream in = new FileInputStream(...)) { ... } AFAIK, originally, before "close()" was called on "in" there was a check if "in" is non-null, which happened every time. In case the resources is initialized with the new class instance expression, this check was removed, but in all other cases it was still there, as far as I known. (And I suspect Find/SpotBugs have heuristics to detect this pattern and ignore it.) The $closeResource method was also introduced to make the bytecode smaller, but was only used when there were enough try-with-resources constructs in the given file, as the method itself also had an space overhead. So some classfiles had the try-with-resources code without $closeResource. With JDK-8194978, the code generated for try-with-resources has been improved once again, to eliminate some of the branches in the "finally" block that cannot be used at the given places where finally is inlined. This made the $closeResource method unnecessary, so it is not produced anymore. Basically, here we are talking about eliding the null check on the resource if the resource must be non-null because a NullPointerException would already appear before reaching the point where the check is done. I don't think there are current plans to do that, sorry. If SpotBugs can detect the new pattern and ignore it (as I suspect it is doing with the older patterns), that would be helpful. Jan On 25.1.2019 21:44, Enrico Olivelli wrote: > Up > > Regards > Enrico > > Il 10 gen 2019 8:13 PM, "Enrico Olivelli" > ha scritto: > > Kindly pinging on this.. > > Cheers > Enrico > > Il lun 7 gen 2019, 14:28 Enrico Olivelli > ha scritto: > > Two questions/ideas: > 1) Wouldn't it be possible for javac to annotate such code > blocks and > write into the class file that that code is "synthetic" ? I really > don't know where to store such flags, but maybe someone could > elaborate more this idea > 2) Why isn't javac adding the "$closeResource" method ? > > Enrico > > Il giorno ven 9 nov 2018 alle ore 23:01 Alex Buckley > > ha > scritto: > > > > On 11/9/2018 12:31 PM, Vicente Romero wrote: > > > My evaluation on this issue is that javac is generating code > > > according to the spec, see JLS11 14.20.3.1 [1]. There is an > explicit > > > check for null on the resource before invoking the close() > method. > > > This is the null check javac is generating. > > > > I confirm that the explicit null check on the resource > variable is > > required, per the translation in > > > https://docs.oracle.com/javase/specs/jls/se11/html/jls-14.html#jls-14.20.3.1-140 > > > -- it has been specified that way since JLS7. > > > > > Fix for JDK-8194978 went a bit further trying to eliminate > dead code > > > for some cases for which javac could statically determine > that the > > > resource would be different from null. In particular if the > resource > > > was initialized with a new class expression. > > > > I confirm it's acceptable to not perform the null check in > generated > > code if you can prove the resource variable is non-null. Frankly, > > though, there is so much that can occur in a "new class > expression" -- > > `new Outer(a(b(c)))<>.new Inner(d(e(f)))` -- that I > would be > > wary of trying to prove anything. > > > > > It could be argued that we could try to analyze the body > and if we > > > find out that a NPE must be thrown in the body of the try, > then the > > > null check on the resource would be deemed unnecessary. But > then we > > > can get to an implementation that will be out of sync with > the spec > > > plus it probably won't cover all cases. > > > > Right, let's not be too clever. > > > > Alex > > > > > Thanks, > > > Vicente > > > > > > [1] > > > > https://docs.oracle.com/javase/specs/jls/se11/html/jls-14.html#jls-14.20.3.1 > > > > > > > On 11/9/18 10:22 AM, Ismael Juma wrote: > > >> Any comments on this? Many people are disabling spotBugs when > > >> compiling with Java 11 due to this issue: > > >> > > >> https://github.com/spotbugs/spotbugs/issues/756 > > > >> > > >> Ismael > > >> > > >> On Thu, Sep 13, 2018 at 10:05 PM Ismael Juma > > > >> >> wrote: > > >> > > >> Hi all, > > >> > > >> JDK-8194978 introduced some changes to the bytecode > generated by > > >> javac for the try with resource construct. In the > following code, > > >> it seems to generate a null check on a reference after > invoking a > > >> method on it: > > >> > > >> public static void readFileAsString(String path) > throws > > >> IOException { > > >> try (FileChannel fc = > FileChannel.open(Paths.get(path))) { > > >> fc.size(); > > >> } > > >> > > >> } > > >> > > >> In line 16 to 22 of the bytecode, it looks like we > check for null > > >> after calling a method on the fc reference: > > >> > > >> 16: aload_1 > > >> 17: invokevirtual #6 // Method > > >> java/nio/channels/FileChannel.size:()J > > >> 20: pop2 > > >> 21: aload_1 > > >> 22: ifnull 52 > > >> 25: aload_1 > > >> 26: invokevirtual #7 // Method > > >> java/nio/channels/FileChannel.close:()V > > >> > > >> Is this intentional? I ask because this pattern triggers a > > >> spotBugs warning since it often implies a bug in > user's code: > > >> > > >> RCN | Nullcheck of fc at line 10 of value previously > dereferenced > > >> in TryTest.readFileAsString(String, Charset) > > >> > > >> Note that this works fine in Java versions older than > Java 11. > > >> Since this spotBugs warning is generally useful, it > would be handy > > >> if javac did not trigger it. Alternatively, if there's > a good way > > >> to detect the code that was generated by javac, > spotBugs could be > > >> updated to ignore it. For reference, this was > discussed in the > > >> spotBugs issue tracker: > > >> > > >> https://github.com/spotbugs/spotbugs/issues/756 > > > >> > > >> And method bytecode in full: > > >> > > >> public static void > readFileAsString(java.lang.String) throws > > >> java.io.IOException; > > >> Code: > > >> 0: aload_0 > > >> 1: iconst_0 > > >> 2: anewarray #2 // class > java/lang/String > > >> 5: invokestatic #3 // Method > > >> > java/nio/file/Paths.get:(Ljava/lang/String;[Ljava/lang/String;)Ljava/nio/file/Path; > > >> 8: iconst_0 > > >> 9: anewarray #4 // class > > >> java/nio/file/OpenOption > > >> 12: invokestatic #5 // Method > > >> > java/nio/channels/FileChannel.open:(Ljava/nio/file/Path;[Ljava/nio/file/OpenOption;)Ljava/nio/channels/FileChannel; > > >> 15: astore_1 > > >> 16: aload_1 > > >> 17: invokevirtual #6 // Method > > >> java/nio/channels/FileChannel.size:()J > > >> 20: pop2 > > >> 21: aload_1 > > >> 22: ifnull 52 > > >> 25: aload_1 > > >> 26: invokevirtual #7 // Method > > >> java/nio/channels/FileChannel.close:()V > > >> 29: goto 52 > > >> 32: astore_2 > > >> 33: aload_1 > > >> 34: ifnull 50 > > >> 37: aload_1 > > >> 38: invokevirtual #7 // Method > > >> java/nio/channels/FileChannel.close:()V > > >> 41: goto 50 > > >> 44: astore_3 > > >> 45: aload_2 > > >> 46: aload_3 > > >> 47: invokevirtual #9 // Method > > >> java/lang/Throwable.addSuppressed:(Ljava/lang/Throwable;)V > > >> 50: aload_2 > > >> 51: athrow > > >> 52: return > > >> Exception table: > > >> from to target type > > >> 16 21 32 Class java/lang/Throwable > > >> 37 41 44 Class java/lang/Throwable > > >> > > >> Thanks, > > >> Ismael > > >> > > > > > -- > > > -- Enrico Olivelli > From martijnverburg at gmail.com Mon Jan 28 23:23:30 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 28 Jan 2019 23:23:30 +0000 Subject: Revive support for SPARC V8 In-Reply-To: References: Message-ID: Hi Tiago, Please see https://openjdk.java.net/contribute/ - I think the reality is that a significant organization would need to commit real engineering time to support this platform for the long haul. If your organisation is able to do so then you may wish to start the work and then propose a porting project or a JEP as appropriate. Cheers, Martijn On Mon, 28 Jan 2019 at 10:00, Tiago Nogueira wrote: > Hello, > > I'm new to the mailing list, and i just hope this is the right place to > bring this up. > > Support for SPARC V8 was removed in 2013 (see > https://bugs.openjdk.java.net/browse/JDK-8017756). The argument at the > time was that SPARC V8 hardware was not used any more (see > https://bugs.openjdk.java.net/browse/JDK-8008407). > > Well, it turns out that the the space industry has finally caught up, and > the new generation of radiation hardened SoCs, at least in Europe, will be > based on SPARC V8 (see > https://www.gaisler.com/doc/gr740/GR740-OVERVIEW.pdf). > > What would be the effort to revive support for SPARC V8? I think this > would be a great opportunity to get Java running on rad-hard hardware in > low Earth orbit and beyond... > > Thanks > Tiago > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From GROEGES at uk.ibm.com Tue Jan 29 11:18:15 2019 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Tue, 29 Jan 2019 11:18:15 +0000 Subject: [NEW_BUG] javac fails and exits with no error if a bad annotation processor is on the classpath Message-ID: Hi all, I have identified a potential issue where javac fails and exits with no error if a bad annotation processor is on the classpath. Background: an Annotation Processor class can be packaged in a jar file and is identified by a special text file inside the jar named: META-INF/services/javax.annotation.processing.Processor. This text file has only one line, specifying the class name of the annotation process class to run. When javac runs, it checks all jars on the classpath and if it finds the special text file in any jar file, then it attempts to run the class listed there. The issue here is that when the annotation processor class can't be executed, javac catches the exception and exits without reporting on the reason for the exit. Examples of reasons why the annotation processor can't be executed include: the annotation processor class is compiled for a higher version of Java than the javac is running, giving UnsupportedClassVersionError. the annotation processor class file is corrupt so can't be loaded. In either of the above cases javac will swallow the error and exit without telling the user why it failed to compile the java source code as expected. Testcase put HelloWorld.java in current directory, edit and run: javac -cp .:/bad.annotation.processor.jar HelloWorld.java Instead of producing HelloWorld.class as expected, javac exits silently. Here, bad.annotation.processor.jar is a file that I created to contain: META-INF/services/javax.annotation.processing.Processor <<-- text file to list bad class bad/notaclass.class <<-- dummy file, can't be loaded as a java class Does anyone know whether this is a bug and that this should throw an error in these cases? If so, I will raise a bug for this. I have looked at the code and seen where javac Aborts the processing, and if I make the following changes the javac detects the issue and reports an error before Aborting. diff -r 5178e4b58b17 src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java Mon Jan 28 09:56:00 2019 +0100 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java Tue Jan 29 11:14:57 2019 +0000 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2005, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -436,6 +436,12 @@ } catch(ServiceConfigurationError sce) { log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage())); throw new Abort(sce); + } catch (UnsupportedClassVersionError ucve) { + log.error(Errors.ProcCantLoadClass(ucve.getLocalizedMessage())); + throw new Abort(ucve); + } catch (ClassFormatError cfe) { + log.error(Errors.ProcCantLoadClass(cfe.getLocalizedMessage())); + throw new Abort(cfe); } catch (Throwable t) { throw new Abort(t); } and to add a new message there is this change diff -r 5178e4b58b17 src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties Mon Jan 28 09:56:00 2019 +0100 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties Tue Jan 29 11:16:03 2019 +0000 @@ -1,5 +1,5 @@ # -# Copyright (c) 1999, 2018, Oracle and/or its affiliates. All rights reserved. +# Copyright (c) 1999, 2019, Oracle and/or its affiliates. All rights reserved. # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. # # This code is free software; you can redistribute it and/or modify it @@ -1051,6 +1051,10 @@ compiler.err.proc.cant.find.class=\ Could not find class file for ''{0}''. +# 0: string +compiler.err.proc.cant.load.class=\ + Could not load processor class file due to ''{0}''. + # Print a client-generated error message; assumed to be localized, no translation required # 0: string compiler.err.proc.messager=\ If this is deemed a bug and the change seems OK, please could someone sponsor this for me and I will create a proper webrev for the change for a full review. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From gunnar at hibernate.org Tue Jan 29 22:35:53 2019 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 29 Jan 2019 23:35:53 +0100 Subject: Passing options to compiler plug-in Message-ID: Hi, I'm working on a javac plug-in (i.e. implementing com.sun.source.util.Plugin) and would like to pass some options to it. I'm currently using annotation processor options (-A...), as that was the only way I could find to pass options unknown to javac. This creates a warning though "The following options were not recognized by any processor: ...". It's no big problem, but I'm curious whether there's a better way. The plug-in in question btw. is a tool for validating an application's (module-internal) architecture by comparing package relationships against a given model definition [1]. Thanks, --Gunnar [1] https://github.com/moditect/deptective From jonathan.gibbons at oracle.com Tue Jan 29 23:03:40 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 29 Jan 2019 15:03:40 -0800 Subject: Passing options to compiler plug-in In-Reply-To: References: Message-ID: From the javac help for extended options, "javac -X" ? -Xplugin:"name args" ??????? Name and optional arguments for a plug-in to be run -- Jon On 01/29/2019 02:35 PM, Gunnar Morling wrote: > Hi, > > I'm working on a javac plug-in (i.e. implementing > com.sun.source.util.Plugin) and would like to pass some options to it. > > I'm currently using annotation processor options (-A...), as that was > the only way I could find to pass options unknown to javac. This > creates a warning though "The following options were not recognized by > any processor: ...". It's no big problem, but I'm curious whether > there's a better way. > > The plug-in in question btw. is a tool for validating an application's > (module-internal) architecture by comparing package relationships > against a given model definition [1]. > > Thanks, > > --Gunnar > > [1] https://github.com/moditect/deptective From joe.darcy at oracle.com Wed Jan 30 00:25:45 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 29 Jan 2019 16:25:45 -0800 Subject: RFR: JDK-8193367: Annotated type variable bounds crash javac In-Reply-To: <94a16fad-f431-70fa-550e-5872b3994c09@oracle.com> References: <9417eb26-0b85-41c5-102d-241df719076f@oracle.com> <8a1a38f4-3562-4550-5b6d-8fed618b7373@oracle.com> <76e27e4a-c895-b653-7ea1-ad37f2aee464@oracle.com> <877ddd7f-9bbb-abb3-8e1e-30d70715b3d6@oracle.com> <94a16fad-f431-70fa-550e-5872b3994c09@oracle.com> Message-ID: <1f861082-4cc2-91f2-7b84-8bc6a53943af@oracle.com> Hello, I'll look into the bug database issues regarding tbd_minor. I believe it is an unintended consequence of the revised policy to use "tbd" instead of "tbd_major" and "tbd_minor" (http://openjdk.java.net/jeps/3). Cheers, -Joe On 1/28/2019 3:02 AM, Vicente Romero wrote: > > > On 1/26/19 10:34 AM, B. Blaser wrote: >> On Thu, 24 Jan 2019 at 19:29, Vicente Romero >> wrote: >>> last diff looks good to me too, >>> >>> Vicente >> Thanks for both reviews, pushed as: >> http://hg.openjdk.java.net/jdk/jdk/rev/a772e65727c5 >> >> I note something strange with JBS: >> https://bugs.openjdk.java.net/browse/JDK-8193367 >> >> I wasn't able to remove 'tbd_minor' (because it was archived) when >> setting the fix version to 13 and it was reset to 'tbd_minor' when >> pushing :-( >> >> Any idea? > > not sure what happened, anyway I manually added 13 as fix version, > although tbd_minor is still being listed >> >> Thanks, >> Bernard > Vicente From joe.darcy at oracle.com Wed Jan 30 01:07:59 2019 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 29 Jan 2019 17:07:59 -0800 Subject: RFR(13): JDK-8217047: Provide a way to inject missing parameter names In-Reply-To: <5C45BBE5.6030007@oracle.com> References: <5C45BBE5.6030007@oracle.com> Message-ID: <5C50F8EF.3030101@oracle.com> Hi Jan, I think this is a reasonable capability to provide in the platform, especially if a "do what I'm most likely to want" provider is included. Cheers, -Joe On 1/21/2019 4:32 AM, Jan Lahoda wrote: > Hi, > > When a type is load from a classfile, and some or all of its methods > have neither the MethodParameters or LocalVariableTable attributes, > then the parameters of the methods have an artificial synthesized > name, which is visible through VariableElement.getSimpleName(). > > The proposal here is to allow to plug in an external provider that > could provide more user-friendly names lazily/on demand. These could > originate e.g. in adjacent sources. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8217437 > Webrev: http://cr.openjdk.java.net/~jlahoda/8217047/webrev.01/ > Specdiff: > http://cr.openjdk.java.net/~jlahoda/8217047/specdiff.01/overview-summary.html > > CSR: https://bugs.openjdk.java.net/browse/JDK-8217437 > > What do you think? > > Thanks, > Jan From bsrbnd at gmail.com Wed Jan 30 12:51:03 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 30 Jan 2019 13:51:03 +0100 Subject: RFR: JDK-8193367: Annotated type variable bounds crash javac In-Reply-To: <1f861082-4cc2-91f2-7b84-8bc6a53943af@oracle.com> References: <9417eb26-0b85-41c5-102d-241df719076f@oracle.com> <8a1a38f4-3562-4550-5b6d-8fed618b7373@oracle.com> <76e27e4a-c895-b653-7ea1-ad37f2aee464@oracle.com> <877ddd7f-9bbb-abb3-8e1e-30d70715b3d6@oracle.com> <94a16fad-f431-70fa-550e-5872b3994c09@oracle.com> <1f861082-4cc2-91f2-7b84-8bc6a53943af@oracle.com> Message-ID: Hi Joe, On Wed, 30 Jan 2019 at 01:25, Joe Darcy wrote: > > Hello, > > I'll look into the bug database issues regarding tbd_minor. I believe it > is an unintended consequence of the revised policy to use "tbd" instead > of "tbd_major" and "tbd_minor" (http://openjdk.java.net/jeps/3). > > Cheers, > > -Joe Thanks for looking at this. It seems 'HG Updates' removed again the fix version '13' yesterday that Vicente manually added two days ago. Cheers, Bernard From amaembo at gmail.com Thu Jan 31 11:33:51 2019 From: amaembo at gmail.com (Tagir Valeev) Date: Thu, 31 Jan 2019 18:33:51 +0700 Subject: Qualified class name inside qualified instance creation expression Message-ID: Hello! Consider the following code: class Test { class Inner {} void test() { new Test.Inner(); // compiles successfully this.new Test.Inner(); // error } } javac reports: Test.java:6: error: '(' expected this.new Test.Inner(); ^ 1 error I read JLS 15.9 [1]: ClassInstanceCreationExpression: UnqualifiedClassInstanceCreationExpression ExpressionName . UnqualifiedClassInstanceCreationExpression Primary . UnqualifiedClassInstanceCreationExpression UnqualifiedClassInstanceCreationExpression: new [TypeArguments] ClassOrInterfaceTypeToInstantiate ( [ArgumentList] ) [ClassBody] ClassOrInterfaceTypeToInstantiate: {Annotation} Identifier {. {Annotation} Identifier} [TypeArgumentsOrDiamond] Thus this.new Test.Inner() could be parsed as Primary . UnqualifiedClassInstanceCreationExpression where ClassOrInterfaceTypeToInstantiate could be parsed as Identifier . Identifier, so there should not be parse error. Next, spec (15.9.1) says different thing for qualified and unqualified instance creation expressions: If the class instance creation expression is unqualified: The ClassOrInterfaceTypeToInstantiate must denote a class that is accessible, non-abstract, and not an enum type. Otherwise, a compile-time error occurs. If the class instance creation expression is qualified: The ClassOrInterfaceTypeToInstantiate must unambiguously denote an inner class that is accessible, non-abstract, not an enum type, and a member of the compile-time type of the Primary expression or the ExpressionName. To me it's not quite evident why Test.Inner denotes a class for unqualified expression, but does not denote the same class for qualified expression. I'm not sure that the word "unambiguously" changes the picture: there's only one class named Inner, so I don't see any ambuguity. Is this javac problem, or probably I'm missing something? Should such code be allowed or not? If not, probably this should be explicitly specified, that qualified class name is not allowed for qualified instance creation expression? What do you think? Thank you in advance, Tagir Valeev. [1] https://docs.oracle.com/javase/specs/jls/se11/html/jls-15.html#jls-15.9 From jonathan.gibbons at oracle.com Thu Jan 31 16:23:19 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 31 Jan 2019 08:23:19 -0800 Subject: [NEW_BUG] javac fails and exits with no error if a bad annotation processor is on the classpath In-Reply-To: References: Message-ID: Steve, Your fix is generally good: Abort should only be used after a suitable message has been reported. There's a `catch (Throwable t)` in the same set of catch blocks that you did not update. Rather than add yet another message for that case, it might be better to throw FatalError, to provoke the standard "javac crash" output for the unknown exception. You should provide a test case ... i.e. as a jtreg test. -- Jon On 1/29/19 3:18 AM, Steve Groeger wrote: > Hi all, > > I have identified a potential issue where javac fails and exits with > no error if a bad annotation processor is on the classpath. > > Background: an Annotation Processor class can be packaged in a jar > file and is identified by a special text file inside the jar named: > META-INF/services/javax.annotation.processing.Processor. This text > file has only one line, specifying the class name of the annotation > process class to run. When javac runs, it checks all jars on the > classpath and if it finds the special text file in any jar file, then > it attempts to run the class listed there. > > The issue here is that when the annotation processor class can't be > executed, javac catches the exception and exits without reporting on > the reason for the exit. Examples of reasons why the annotation > processor can't be executed include: > > * the annotation processor class is compiled for a higher version of > Java than the javac is running, giving UnsupportedClassVersionError. > * the annotation processor class file is corrupt so can't be loaded. > > > In either of the above cases javac will swallow the error and exit > without telling the user why it failed to compile the java source code > as expected. > > Testcase > ? ?put HelloWorld.java in current directory, edit and run: > ?javac -cp .:/bad.annotation.processor.jar HelloWorld.java > > Instead of producing HelloWorld.class as expected, javac exits silently. > > Here, bad.annotation.processor.jar is a file that I created to contain: > META-INF/services/javax.annotation.processing.Processor <<-- text file > to list bad class > ? ? ?bad/notaclass.class <<-- dummy file, can't be loaded as a java class > > Does anyone know whether this is a bug and that this should throw an > error in these cases? > If so, I will raise a bug for this. > > I have looked at the code and seen where javac Aborts the processing, > and if I make the following changes the javac detects the issue and > reports an error before Aborting. > > diff -r 5178e4b58b17 > src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java > --- > a/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java > ? ? ?Mon Jan 28 09:56:00 2019 +0100 > +++ > b/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java > ? ? ?Tue Jan 29 11:14:57 2019 +0000 > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2005, 2018, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights > reserved. > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ? * > ? * This code is free software; you can redistribute it and/or modify it > @@ -436,6 +436,12 @@ > ?} catch(ServiceConfigurationError sce) { > ?log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage())); > ? ? ?throw new Abort(sce); > + ?} catch (UnsupportedClassVersionError ucve) { > + ?log.error(Errors.ProcCantLoadClass(ucve.getLocalizedMessage())); > + ? ? ?throw new Abort(ucve); > + ?} catch (ClassFormatError cfe) { > + ?log.error(Errors.ProcCantLoadClass(cfe.getLocalizedMessage())); > + ? ? ?throw new Abort(cfe); > ?} catch (Throwable t) { > ? ? ?throw new Abort(t); > ?} > > and to add a new message there is this change > > diff -r 5178e4b58b17 > src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties > --- > a/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties > ? ? ?Mon Jan 28 09:56:00 2019 +0100 > +++ > b/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties > ? ? ?Tue Jan 29 11:16:03 2019 +0000 > @@ -1,5 +1,5 @@ > ?# > -# Copyright (c) 1999, 2018, Oracle and/or its affiliates. All rights > reserved. > +# Copyright (c) 1999, 2019, Oracle and/or its affiliates. All rights > reserved. > ?# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ?# > ?# This code is free software; you can redistribute it and/or modify it > @@ -1051,6 +1051,10 @@ > ?compiler.err.proc.cant.find.class=\ > ? ? ?Could not find class file for ''{0}''. > > +# 0: string > +compiler.err.proc.cant.load.class=\ > + ? ?Could not load processor class file due to ''{0}''. > + > ?# Print a client-generated error message; assumed to be localized, no > translation required > ?# 0: string > ?compiler.err.proc.messager=\ > > > If this is deemed a bug and the change seems OK, please could someone > sponsor this for me and I will create a proper webrev for the change > for a full review. > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From GROEGES at uk.ibm.com Thu Jan 31 16:49:02 2019 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Thu, 31 Jan 2019 16:49:02 +0000 Subject: [NEW_BUG] javac fails and exits with no error if a bad annotation processor is on the classpath In-Reply-To: References: Message-ID: Hi Jonathan, Thanks for responding. I have created a couple of webrevs for jdk8u [1] and jdk [2] which also include some JTReg tests. I would be grateful if you, or someone else could review these just to ensure I am doing the right thing. I will update the code with the additional 'throw FatalError' that you mentioned and will then create some new webrevs If you are able to sponsor these changes for me I would be very grateful. PS. As you saw I have created a JBS issue for this here [3] [1] http://cr.openjdk.java.net/~sgroeger/8218152/jdk8u/webrev.00/ [2] http://cr.openjdk.java.net/~sgroeger/8218152/jdk/webrev.00/ [3https://bugs.openjdk.java.net/browse/JDK-8218152 Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: Jonathan Gibbons To: Steve Groeger , compiler-dev at openjdk.java.net Date: 31/01/2019 16:33 Subject: Re: [NEW_BUG] javac fails and exits with no error if a bad annotation processor is on the classpath Steve, Your fix is generally good: Abort should only be used after a suitable message has been reported. There's a `catch (Throwable t)` in the same set of catch blocks that you did not update. Rather than add yet another message for that case, it might be better to throw FatalError, to provoke the standard "javac crash" output for the unknown exception. You should provide a test case ... i.e. as a jtreg test. -- Jon On 1/29/19 3:18 AM, Steve Groeger wrote: Hi all, I have identified a potential issue where javac fails and exits with no error if a bad annotation processor is on the classpath. Background: an Annotation Processor class can be packaged in a jar file and is identified by a special text file inside the jar named: META-INF/services/javax.annotation.processing.Processor. This text file has only one line, specifying the class name of the annotation process class to run. When javac runs, it checks all jars on the classpath and if it finds the special text file in any jar file, then it attempts to run the class listed there. The issue here is that when the annotation processor class can't be executed, javac catches the exception and exits without reporting on the reason for the exit. Examples of reasons why the annotation processor can't be executed include: the annotation processor class is compiled for a higher version of Java than the javac is running, giving UnsupportedClassVersionError. the annotation processor class file is corrupt so can't be loaded. In either of the above cases javac will swallow the error and exit without telling the user why it failed to compile the java source code as expected. Testcase put HelloWorld.java in current directory, edit and run: javac -cp .:/bad.annotation.processor.jar HelloWorld.java Instead of producing HelloWorld.class as expected, javac exits silently. Here, bad.annotation.processor.jar is a file that I created to contain: META-INF/services/javax.annotation.processing.Processor <<-- text file to list bad class bad/notaclass.class <<-- dummy file, can't be loaded as a java class Does anyone know whether this is a bug and that this should throw an error in these cases? If so, I will raise a bug for this. I have looked at the code and seen where javac Aborts the processing, and if I make the following changes the javac detects the issue and reports an error before Aborting. diff -r 5178e4b58b17 src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java Mon Jan 28 09:56:00 2019 +0100 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java Tue Jan 29 11:14:57 2019 +0000 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2005, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -436,6 +436,12 @@ } catch(ServiceConfigurationError sce) { log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage())); throw new Abort(sce); + } catch (UnsupportedClassVersionError ucve) { + log.error(Errors.ProcCantLoadClass(ucve.getLocalizedMessage())); + throw new Abort(ucve); + } catch (ClassFormatError cfe) { + log.error(Errors.ProcCantLoadClass(cfe.getLocalizedMessage())); + throw new Abort(cfe); } catch (Throwable t) { throw new Abort(t); } and to add a new message there is this change diff -r 5178e4b58b17 src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties Mon Jan 28 09:56:00 2019 +0100 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties Tue Jan 29 11:16:03 2019 +0000 @@ -1,5 +1,5 @@ # -# Copyright (c) 1999, 2018, Oracle and/or its affiliates. All rights reserved. +# Copyright (c) 1999, 2019, Oracle and/or its affiliates. All rights reserved. # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. # # This code is free software; you can redistribute it and/or modify it @@ -1051,6 +1051,10 @@ compiler.err.proc.cant.find.class=\ Could not find class file for ''{0}''. +# 0: string +compiler.err.proc.cant.load.class=\ + Could not load processor class file due to ''{0}''. + # Print a client-generated error message; assumed to be localized, no translation required # 0: string compiler.err.proc.messager=\ If this is deemed a bug and the change seems OK, please could someone sponsor this for me and I will create a proper webrev for the change for a full review. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Thu Jan 31 16:56:08 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 31 Jan 2019 08:56:08 -0800 Subject: [NEW_BUG] javac fails and exits with no error if a bad annotation processor is on the classpath In-Reply-To: References: Message-ID: Steve, When you post the new webrevs, can I suggest that you change the Subject line of this thread to something like RFR: 8218152 [javac] fails and exits with no error if a bad annotation processor provided That will help get attention from reviewers, and help any subsequent bug-archaeology. I can sponsor the changes for you once they have been reviewed. -- Jon On 1/31/19 8:49 AM, Steve Groeger wrote: > Hi Jonathan, > > Thanks for responding. > > I have created a couple of webrevs for jdk8u [1] and jdk [2] which > also include some JTReg tests. > I would be grateful if you, or someone else could review these just to > ensure I am doing the right thing. > I will update the code with the additional 'throw FatalError' that you > mentioned and will then create some new webrevs > > If you are able to sponsor these changes for me I would be very grateful. > > PS. As you saw I have created a JBS issue for this here [3] > > [1] http://cr.openjdk.java.net/~sgroeger/8218152/jdk8u/webrev.00/ > [2] http://cr.openjdk.java.net/~sgroeger/8218152/jdk/webrev.00/ > [3https://bugs.openjdk.java.net/browse/JDK-8218152 > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > > > > From: Jonathan Gibbons > To: Steve Groeger , compiler-dev at openjdk.java.net > Date: 31/01/2019 16:33 > Subject: Re: [NEW_BUG] javac fails and exits with no error if a bad > annotation processor is on the classpath > ------------------------------------------------------------------------ > > > > Steve, > > Your fix is generally good: Abort should only be used after a suitable > message has been reported. > > There's a `catch (Throwable t)` in the same set of catch blocks that > you did not update. Rather than add yet another message for that case, > it might be better to throw FatalError, to provoke the standard "javac > crash" output for the unknown exception. > > You should provide a test case ... i.e. as a jtreg test. > > -- Jon > > On 1/29/19 3:18 AM, Steve Groeger wrote: > Hi all, > > I have identified a potential issue where javac fails and exits with > no error if a bad annotation processor is on the classpath. > > Background: an Annotation Processor class can be packaged in a jar > file and is identified by a special text file inside the jar named: > META-INF/services/javax.annotation.processing.Processor. This text > file has only one line, specifying the class name of the annotation > process class to run. When javac runs, it checks all jars on the > classpath and if it finds the special text file in any jar file, then > it attempts to run the class listed there. > > The issue here is that when the annotation processor class can't be > executed, javac catches the exception and exits without reporting on > the reason for the exit. Examples of reasons why the annotation > processor can't be executed include: > > * the annotation processor class is compiled for a higher version of > Java than the javac is running, giving UnsupportedClassVersionError. > * the annotation processor class file is corrupt so can't be loaded. > > > In either of the above cases javac will swallow the error and exit > without telling the user why it failed to compile the java source code > as expected. > > Testcase > ? ?put HelloWorld.java in current directory, edit and run: > ? ? ? ? ?javac -cp .:/bad.annotation.processor.jar > HelloWorld.java > > Instead of producing HelloWorld.class as expected, javac exits silently. > > Here, bad.annotation.processor.jar is a file that I created to contain: > ? ? ? META-INF/services/javax.annotation.processing.Processor <<-- > text file to list bad class > ? ? ?bad/notaclass.class <<-- dummy file, can't be loaded as a java class > > Does anyone know whether this is a bug and that this should throw an > error in these cases? > If so, I will raise a bug for this. > > I have looked at the code and seen where javac Aborts the processing, > and if I make the following changes the javac detects the issue and > reports an error before Aborting. > > diff -r 5178e4b58b17 > src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java > --- > a/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java > ? ?Mon Jan 28 09:56:00 2019 +0100 > +++ > b/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java > ? ?Tue Jan 29 11:14:57 2019 +0000 > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2005, 2018, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights > reserved. > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ? * > ? * This code is free software; you can redistribute it and/or modify it > @@ -436,6 +436,12 @@ > ? ? ? ? ? ? ?} catch(ServiceConfigurationError sce) { > ?log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage())); > ? ? ? ? ? ? ? ? ?throw new Abort(sce); > + ? ? ? ? ? ?} catch (UnsupportedClassVersionError ucve) { > + ?log.error(Errors.ProcCantLoadClass(ucve.getLocalizedMessage())); > + ? ? ? ? ? ? ? ?throw new Abort(ucve); > + ? ? ? ? ? ?} catch (ClassFormatError cfe) { > + ?log.error(Errors.ProcCantLoadClass(cfe.getLocalizedMessage())); > + ? ? ? ? ? ? ? ?throw new Abort(cfe); > ? ? ? ? ? ? ?} catch (Throwable t) { > ? ? ? ? ? ? ? ? ?throw new Abort(t); > ? ? ? ? ? ? ?} > > and to add a new message there is this change > > diff -r 5178e4b58b17 > src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties > --- > a/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties > ? ?Mon Jan 28 09:56:00 2019 +0100 > +++ > b/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties > ? ?Tue Jan 29 11:16:03 2019 +0000 > @@ -1,5 +1,5 @@ > ?# > -# Copyright (c) 1999, 2018, Oracle and/or its affiliates. All rights > reserved. > +# Copyright (c) 1999, 2019, Oracle and/or its affiliates. All rights > reserved. > ?# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ?# > ?# This code is free software; you can redistribute it and/or modify it > @@ -1051,6 +1051,10 @@ > ?compiler.err.proc.cant.find.class=\ > ? ? ?Could not find class file for ''{0}''. > > +# 0: string > +compiler.err.proc.cant.load.class=\ > + ? ?Could not load processor class file due to ''{0}''. > + > ?# Print a client-generated error message; assumed to be localized, no > translation required > ?# 0: string > ?compiler.err.proc.messager=\ > > > If this is deemed a bug and the change seems OK, please could someone > sponsor this for me and I will create a proper webrev for the change > for a full review. > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: _groeges at uk.ibm.com_ > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Thu Jan 31 22:02:18 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 31 Jan 2019 14:02:18 -0800 Subject: Qualified class name inside qualified instance creation expression In-Reply-To: References: Message-ID: <5C53706A.8090203@oracle.com> On 1/31/2019 3:33 AM, Tagir Valeev wrote: > Consider the following code: > > class Test { > class Inner {} > > void test() { > new Test.Inner(); // compiles successfully > this.new Test.Inner(); // error > } > } Both the unqualified class instance creation expression and the qualified class instance creation expression should compile. Each has `this` as the immediately enclosing instance. > javac reports: > Test.java:6: error: '(' expected > this.new Test.Inner(); > ^ > 1 error > > I read JLS 15.9 [1]: > ClassInstanceCreationExpression: > UnqualifiedClassInstanceCreationExpression > ExpressionName . UnqualifiedClassInstanceCreationExpression > Primary . UnqualifiedClassInstanceCreationExpression > UnqualifiedClassInstanceCreationExpression: > new [TypeArguments] ClassOrInterfaceTypeToInstantiate ( > [ArgumentList] ) [ClassBody] > ClassOrInterfaceTypeToInstantiate: > {Annotation} Identifier {. {Annotation} Identifier} [TypeArgumentsOrDiamond] > > Thus this.new Test.Inner() could be parsed as Primary . > UnqualifiedClassInstanceCreationExpression where > ClassOrInterfaceTypeToInstantiate could be parsed as Identifier . > Identifier, so there should not be parse error. Correct. There has been shimmer in this part of the language. In Java SE 7, `this.new Test.Inner()` was illegal; only `this.new SIMPLENAME()` was allowed. (See https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.9) In Java SE 8, the grammar of `ClassInstanceCreationExpression` was modified to support type annotations, and `this.new QUALIFIEDNAME()` was allowed. In principle, there is no reason to disallow a qualified name in a qualified CICE. The phrase `new Test.Inner()` is meaningful as an unqualified CICE, and enriching the phrase to be a qualified CICE, with an explicit immediately enclosing instance, doesn't make it unmeaningful. I suspect javac is still expecting (modulo type arguments) a simple name after `new`. The 15.9.1 rules about the class denoted by `ClassOrInterfaceTypeToInstantiate` have not changed substantively since Java SE 7 (though they have been refactored numerous times in relation to diamond). They have always mandated "a class" (in an unqualified CICE) versus "an inner class" (in a qualified CICE). Alex > Next, spec (15.9.1) says different thing for qualified and unqualified > instance creation expressions: > > If the class instance creation expression is unqualified: > The ClassOrInterfaceTypeToInstantiate must denote a class that is > accessible, non-abstract, and not an enum type. Otherwise, a > compile-time error occurs. > > If the class instance creation expression is qualified: > The ClassOrInterfaceTypeToInstantiate must unambiguously denote an > inner class that is accessible, non-abstract, not an enum type, and a > member of the compile-time type of the Primary expression or the > ExpressionName. > > To me it's not quite evident why Test.Inner denotes a class for > unqualified expression, but does not denote the same class for > qualified expression. I'm not sure that the word "unambiguously" > changes the picture: there's only one class named Inner, so I don't > see any ambuguity. > > Is this javac problem, or probably I'm missing something? Should such > code be allowed or not? If not, probably this should be explicitly > specified, that qualified class name is not allowed for qualified > instance creation expression? What do you think? > > Thank you in advance, > Tagir Valeev. > > [1] https://docs.oracle.com/javase/specs/jls/se11/html/jls-15.html#jls-15.9