From s.2016.kay at gmail.com Mon Jul 2 05:02:41 2018 From: s.2016.kay at gmail.com (Ess Kay) Date: Mon, 2 Jul 2018 15:02:41 +1000 Subject: Generation of NestHost and NestMembers attributes using javac? Message-ID: Should I be able to produce NestHost and NestMembers attributes using the current Javac 19 (2018/6/22)? If so then is there any source code available that will result in these attributes being generated? If not then when is Java 11 expected to be feature complete? From Michael.Rasmussen at roguewave.com Mon Jul 2 08:15:48 2018 From: Michael.Rasmussen at roguewave.com (Michael Rasmussen) Date: Mon, 2 Jul 2018 08:15:48 +0000 Subject: Generation of NestHost and NestMembers attributes using javac? In-Reply-To: References: Message-ID: The JEP 181 implementation was merged in on June 23rd [1], so probably no. /Michael [1] http://hg.openjdk.java.net/jdk/jdk/rev/2f2af62dfac7 ________________________________ From: compiler-dev on behalf of Ess Kay Sent: 02 July 2018 08:02:41 To: compiler-dev Subject: Generation of NestHost and NestMembers attributes using javac? Should I be able to produce NestHost and NestMembers attributes using the current Javac 19 (2018/6/22)? If so then is there any source code available that will result in these attributes being generated? If not then when is Java 11 expected to be feature complete? -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Mon Jul 2 10:31:22 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 2 Jul 2018 11:31:22 +0100 Subject: Generation of NestHost and NestMembers attributes using javac? In-Reply-To: References: Message-ID: <66e05de2-4d36-40f7-e61c-b24b91b29b3a@oracle.com> Hi, JEP 181 was integrated On Sat 23rd of June: http://hg.openjdk.java.net/jdk/jdk/rev/2f2af62dfac7 I can see the support enabled in my latest JDK 11 build, but we'll have to wait for next available promotion, as b19 doesn't have it. Maurizio On 02/07/18 06:02, Ess Kay wrote: > Should I be able to produce NestHost and NestMembers attributes using > the current Javac 19 (2018/6/22)? If so then is there any source code > available that will result in these attributes being generated? If > not then when is Java 11 expected to be feature complete? From peter.levart at gmail.com Mon Jul 2 14:36:58 2018 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 2 Jul 2018 16:36:58 +0200 Subject: JDK 12 RFR of JDK-8206085 : Refactor langtools/tools/javac/versions/Versions.java In-Reply-To: <7c73f7f9-ab06-f734-633a-35173a2d45a9@oracle.com> References: <50063ce4-ce4c-5666-d1db-a78e5697b0c5@oracle.com> <4564190b-ee82-b4dd-03a5-df690e69a253@oracle.com> <7c73f7f9-ab06-f734-633a-35173a2d45a9@oracle.com> Message-ID: <90aa4ad4-af3e-1c47-8b77-5c4e79c7fe60@gmail.com> Hi Joe, A suggestion for more compact code: the (ever growing) switch statement in enum SourceTarget.checksrc could be replaced with a field of type BiConsumer, initialized in constructor. For each enum constant you then just pass a method reference to the chosen target method. The checksrc in SourceTarget could be an instance method. Peter On 06/29/2018 09:41 PM, joe darcy wrote: > Dis-charged revision along with JDK 11 specific source example now up at > > ??? http://cr.openjdk.java.net/~darcy/8206085.1/ > > Thanks, > > -Joe > > > On 6/29/2018 9:55 AM, Jonathan Gibbons wrote: >> There's more static in this file than on my high-school Van de Graaf >> generator! >> >> Can we follow the convention of creating an instance in main, and >> then using instance methods. >> >> The naming of some methods is also novel, with respect to >> case-conventions. >> >> -- Jon >> >> >> On 6/28/18 8:15 PM, joe darcy wrote: >>> Hello, >>> >>> Fresh off of updating >>> >>> ??? langtools/tools/javac/versions/Versions.java >>> >>> for the JDK 11 -> 12 transition, I'd like to refactor the test to >>> reduce the maintenance needed when adding new versions (as in new >>> releases) or removing versions (as is planned for later in JDK 12): >>> >>> ??? http://cr.openjdk.java.net/~darcy/8206085.0/ >>> >>> Thanks, >>> >>> -Joe >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Mon Jul 2 23:38:27 2018 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 2 Jul 2018 16:38:27 -0700 Subject: JDK 12 RFR of JDK-8206085 : Refactor langtools/tools/javac/versions/Versions.java In-Reply-To: <90aa4ad4-af3e-1c47-8b77-5c4e79c7fe60@gmail.com> References: <50063ce4-ce4c-5666-d1db-a78e5697b0c5@oracle.com> <4564190b-ee82-b4dd-03a5-df690e69a253@oracle.com> <7c73f7f9-ab06-f734-633a-35173a2d45a9@oracle.com> <90aa4ad4-af3e-1c47-8b77-5c4e79c7fe60@gmail.com> Message-ID: <7d15d77c-95d8-7e9a-891f-05b3c4547760@oracle.com> Hi Peter, On 7/2/2018 7:36 AM, Peter Levart wrote: > Hi Joe, > > A suggestion for more compact code: the (ever growing) switch > statement in enum SourceTarget.checksrc could be replaced with a field > of type BiConsumer, initialized in constructor. > For each enum constant you then just pass a method reference to the > chosen target method. The checksrc in SourceTarget could be an > instance method. I had an intermediate version along those lines before sending the first one out for review. In the intermediate version, I stored in the method reference in a field and the enum client code used an accessor method for it code. The downside was a bit unpleasent to use since the vararg-ness isn't captured in the generic type. But if checksrc was a varags instance on the enum, then it could benefit from the varargs conversion. Let's see ... yes, the resulting test looks better and should be easier to maintain: ??? http://cr.openjdk.java.net/~darcy/8206085.2/ Thank you for the suggestion. In any case, the span of versions should reduced soon by the removal of -source/-target/--release 6 in JDK 12 [1], which is one reason I'm working on refactoring these tests now :-) Cheers, -Joe [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-May/001210.html > > Peter > > On 06/29/2018 09:41 PM, joe darcy wrote: >> Dis-charged revision along with JDK 11 specific source example now up at >> >> http://cr.openjdk.java.net/~darcy/8206085.1/ >> >> Thanks, >> >> -Joe >> >> >> On 6/29/2018 9:55 AM, Jonathan Gibbons wrote: >>> There's more static in this file than on my high-school Van de Graaf >>> generator! >>> >>> Can we follow the convention of creating an instance in main, and >>> then using instance methods. >>> >>> The naming of some methods is also novel, with respect to >>> case-conventions. >>> >>> -- Jon >>> >>> >>> On 6/28/18 8:15 PM, joe darcy wrote: >>>> Hello, >>>> >>>> Fresh off of updating >>>> >>>> ??? langtools/tools/javac/versions/Versions.java >>>> >>>> for the JDK 11 -> 12 transition, I'd like to refactor the test to >>>> reduce the maintenance needed when adding new versions (as in new >>>> releases) or removing versions (as is planned for later in JDK 12): >>>> >>>> http://cr.openjdk.java.net/~darcy/8206085.0/ >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Tue Jul 3 00:43:09 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 2 Jul 2018 17:43:09 -0700 Subject: RFR: JDK-8198945: Invalid RuntimeVisibleTypeAnnotations for annotation on anonymous class type parameter In-Reply-To: <5B36C325.7080605@oracle.com> References: <5B36C325.7080605@oracle.com> Message-ID: Hi Alex, Thanks for digging up those threads, I hadn't seen the earlier discussions. I do not have a strong opinion about the decision to emit annotations on anonymous class supertypes as both CLASS_EXTENDS and NEW, vs. just CLASS_EXTENDS. Unless others on this thread are interested in revisiting it, I'm now leaning towards keeping the current approach. Here's the updated webrev to do that: http://cr.openjdk.java.net/~cushon/8198945/webrev.01/index.html The patch to Annotate is still necessary to prevent annotations like @TB from being attached to the enclosing method (rather than the code attribute). The revised patch to TypeAnnotations keeps the copyNewClassAnnotationsToOwner helper that propagates annotations on anonymous classes to the 'new' expression, but fixes it to preserve the relative position information of annotations that are not on the top-level type. Here's a demo. Note that the 'NEW' annotations are identical for both the anonymous and named new expressions: ``` import java.lang.annotation.*; class Test { @Target(ElementType.TYPE_USE) @interface TA {} @Target(ElementType.TYPE_USE) @interface TB {} interface I {} static class J {} void f() { new @TA I<@TB Object>() {}; new @TA J<@TB Object>(); } } ``` $ javap -v -p Test void f(); ... RuntimeInvisibleTypeAnnotations: 0: #22(): NEW, offset=9 Test$TA 1: #23(): NEW, offset=9, location=[TYPE_ARGUMENT(0)] Test$TB 2: #23(): NEW, offset=0, location=[TYPE_ARGUMENT(0)] Test$TB 3: #22(): NEW, offset=0 Test$TA $ javap -v -p 'Test$1' ... RuntimeInvisibleTypeAnnotations: 0: #21(): CLASS_EXTENDS, type_index=0, location=[TYPE_ARGUMENT(0)] Test$TB 1: #24(): CLASS_EXTENDS, type_index=0 Test$TA On Fri, Jun 29, 2018 at 4:39 PM Alex Buckley wrote: > On 6/29/2018 3:55 PM, Liam Miller-Cushon wrote: > > The handling of @TB in particular is clearly incorrect: > > > > * @TB appears with a `NEW` type path that leads to the top-level type of > > the 'new' expression, even though @TB appeared on a type argument of > > that type and not at the top level. > > > > * @TB also appears on 'f' with a `CLASS_EXTENDS` path and no bytecode > > offset, which does not provide enough information to associate it with > > the annotated location. > > I agree with both points. It is egregious that the method_info structure > for `f` (as opposed to the Code attribute therein) as a > Runtime*TypeAnnotations attribute. > > > The handling of @TA is also questionable. It makes some sense to use the > > same type path for an annotation on the type of an anonymous class > > declaration as the type of a regular 'new' expression. However that > > results in the same use of @TA appearing twice in bytecode, and > > conflates the type of the anonymous class with its supertype. > > > > I think it is more correct to only emit @TA as a `CLASS_EXTENDS` > > annotation on Test$1, and not include a copy of it at the enclosing > method. > > I did some digging and found three threads from 2013: > > 1. "Annotations on anonymous classes" > > http://mail.openjdk.java.net/pipermail/type-annotations-spec-experts/2013-February/000063.html > > 2. "Desugaring of anonymous classes" > > http://mail.openjdk.java.net/pipermail/type-annotations-spec-experts/2013-April/000092.html > > 3. "Desugaring of anonymous classes" (followup) > > http://mail.openjdk.java.net/pipermail/type-annotations-spec-experts/2013-August/000127.html > > It seems like I changed my mind on the matter of recording @TA: > > - In February I agreed with your view, Liam, that @TA should appear only > as a CLASS_EXTENDS path in the implicit class declaration (Test$1), and > not as a NEW path in the code of `f`. > > - But in April, I said that @TA should be recorded as both paths. Per > the followup mail in August, this was driven by a longstanding policy > that "In the classfile, the type annotations are copied to the class > declaration and to its instantiation (new expression)." > > In June 2018, I do not mind whether @TA appears as CLASS_EXTENDS only, > or as CLASS_EXTENDS + NEW. If you and Werner have agreed on > CLASS_EXTENDS only, and if your fix (which is mostly deletion) makes the > recording of both @TA and @TB more reliable, then I defer to your decision. > > Alex > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wdietl at gmail.com Tue Jul 3 02:14:44 2018 From: wdietl at gmail.com (Werner Dietl) Date: Mon, 2 Jul 2018 22:14:44 -0400 Subject: RFR: JDK-8198945: Invalid RuntimeVisibleTypeAnnotations for annotation on anonymous class type parameter In-Reply-To: References: <5B36C325.7080605@oracle.com> Message-ID: Hi Liam, Alex, all, it would be nice if there were a correspondence between the type of the object that is created and the NEW type annotations that we generate. For method f() from the latest example, we generate bytecode: Code: stack=3, locals=1, args_size=1 0: new #2 // class Test$1 ... 9: new #4 // class Test$J Class Test$1 has no type arguments, so I would find having NEW type annotations on a type argument confusing. In contrast, class Test$J takes type arguments, so having a NEW type annotation on that type argument is sensible. So I would be for either no NEW type annotations for anonymous class instantiations, or duplicating only the top-level type annotations. For method f() this would generate three type annotations: RuntimeInvisibleTypeAnnotations: 0: #22(): NEW, offset=9 Test$TA 1: #23(): NEW, offset=9, location=[TYPE_ARGUMENT(0)] Test$TB 2: #22(): NEW, offset=0 Test$TA Duplicating only the top-level type annotations would be my slight preference over no NEW annotations at all. This is what I had suggested in the 2/12/2013 message quoted in http://mail.openjdk.java.net/pipermail/type-annotations-spec-experts/2013-February/000063.html and still seems sensible to me. Best, cu, WMD. On Mon, Jul 2, 2018 at 8:43 PM Liam Miller-Cushon wrote: > > Hi Alex, > > Thanks for digging up those threads, I hadn't seen the earlier discussions. > > I do not have a strong opinion about the decision to emit annotations on anonymous class supertypes as both CLASS_EXTENDS and NEW, vs. just CLASS_EXTENDS. Unless others on this thread are interested in revisiting it, I'm now leaning towards keeping the current approach. > > Here's the updated webrev to do that: http://cr.openjdk.java.net/~cushon/8198945/webrev.01/index.html > > The patch to Annotate is still necessary to prevent annotations like @TB from being attached to the enclosing method (rather than the code attribute). The revised patch to TypeAnnotations keeps the copyNewClassAnnotationsToOwner helper that propagates annotations on anonymous classes to the 'new' expression, but fixes it to preserve the relative position information of annotations that are not on the top-level type. > > Here's a demo. Note that the 'NEW' annotations are identical for both the anonymous and named new expressions: > > ``` > import java.lang.annotation.*; > > class Test { > @Target(ElementType.TYPE_USE) @interface TA {} > @Target(ElementType.TYPE_USE) @interface TB {} > > interface I {} > static class J {} > > void f() { > new @TA I<@TB Object>() {}; > new @TA J<@TB Object>(); > } > } > ``` > > $ javap -v -p Test > void f(); > ... > RuntimeInvisibleTypeAnnotations: > 0: #22(): NEW, offset=9 > Test$TA > 1: #23(): NEW, offset=9, location=[TYPE_ARGUMENT(0)] > Test$TB > 2: #23(): NEW, offset=0, location=[TYPE_ARGUMENT(0)] > Test$TB > 3: #22(): NEW, offset=0 > Test$TA > > $ javap -v -p 'Test$1' > ... > RuntimeInvisibleTypeAnnotations: > 0: #21(): CLASS_EXTENDS, type_index=0, location=[TYPE_ARGUMENT(0)] > Test$TB > 1: #24(): CLASS_EXTENDS, type_index=0 > Test$TA > > > On Fri, Jun 29, 2018 at 4:39 PM Alex Buckley wrote: >> >> On 6/29/2018 3:55 PM, Liam Miller-Cushon wrote: >> > The handling of @TB in particular is clearly incorrect: >> > >> > * @TB appears with a `NEW` type path that leads to the top-level type of >> > the 'new' expression, even though @TB appeared on a type argument of >> > that type and not at the top level. >> > >> > * @TB also appears on 'f' with a `CLASS_EXTENDS` path and no bytecode >> > offset, which does not provide enough information to associate it with >> > the annotated location. >> >> I agree with both points. It is egregious that the method_info structure >> for `f` (as opposed to the Code attribute therein) as a >> Runtime*TypeAnnotations attribute. >> >> > The handling of @TA is also questionable. It makes some sense to use the >> > same type path for an annotation on the type of an anonymous class >> > declaration as the type of a regular 'new' expression. However that >> > results in the same use of @TA appearing twice in bytecode, and >> > conflates the type of the anonymous class with its supertype. >> > >> > I think it is more correct to only emit @TA as a `CLASS_EXTENDS` >> > annotation on Test$1, and not include a copy of it at the enclosing method. >> >> I did some digging and found three threads from 2013: >> >> 1. "Annotations on anonymous classes" >> http://mail.openjdk.java.net/pipermail/type-annotations-spec-experts/2013-February/000063.html >> >> 2. "Desugaring of anonymous classes" >> http://mail.openjdk.java.net/pipermail/type-annotations-spec-experts/2013-April/000092.html >> >> 3. "Desugaring of anonymous classes" (followup) >> http://mail.openjdk.java.net/pipermail/type-annotations-spec-experts/2013-August/000127.html >> >> It seems like I changed my mind on the matter of recording @TA: >> >> - In February I agreed with your view, Liam, that @TA should appear only >> as a CLASS_EXTENDS path in the implicit class declaration (Test$1), and >> not as a NEW path in the code of `f`. >> >> - But in April, I said that @TA should be recorded as both paths. Per >> the followup mail in August, this was driven by a longstanding policy >> that "In the classfile, the type annotations are copied to the class >> declaration and to its instantiation (new expression)." >> >> In June 2018, I do not mind whether @TA appears as CLASS_EXTENDS only, >> or as CLASS_EXTENDS + NEW. If you and Werner have agreed on >> CLASS_EXTENDS only, and if your fix (which is mostly deletion) makes the >> recording of both @TA and @TB more reliable, then I defer to your decision. >> >> Alex -- http://www.google.com/profiles/wdietl From cushon at google.com Tue Jul 3 02:34:03 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 2 Jul 2018 19:34:03 -0700 Subject: RFR: JDK-8198945: Invalid RuntimeVisibleTypeAnnotations for annotation on anonymous class type parameter In-Reply-To: References: <5B36C325.7080605@oracle.com> Message-ID: On Mon, Jul 2, 2018 at 7:14 PM Werner Dietl wrote: > Class Test$1 has no type arguments, so I would find having NEW type > annotations on a type argument confusing. > Ah, right. Thanks for the catch. > So I would be for either no NEW type annotations for anonymous class > instantiations, or duplicating only the top-level type annotations. > For method f() this would generate three type annotations: > > RuntimeInvisibleTypeAnnotations: > 0: #22(): NEW, offset=9 > Test$TA > 1: #23(): NEW, offset=9, location=[TYPE_ARGUMENT(0)] > Test$TB > 2: #22(): NEW, offset=0 > Test$TA > > Duplicating only the top-level type annotations would be my slight > preference over no NEW annotations at all. I revised the fix to only duplicate top-level annotations: http://cr.openjdk.java.net/~cushon/8198945/webrev.02 -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.2016.kay at gmail.com Tue Jul 3 02:50:14 2018 From: s.2016.kay at gmail.com (Ess Kay) Date: Tue, 3 Jul 2018 12:50:14 +1000 Subject: Generation of NestHost and NestMembers attributes using javac? In-Reply-To: <66e05de2-4d36-40f7-e61c-b24b91b29b3a@oracle.com> References: <66e05de2-4d36-40f7-e61c-b24b91b29b3a@oracle.com> Message-ID: Hi Maurizio, > JEP 181 was integrated On Sat 23rd of June Thank you. I see build 20 (2018/6/29) is now available. I should have been patient for one more day ;). As far as I can determine, a nest member class is always an inner class of its nest host class. That is, if there is a NestHost or NestMember attribute in a class then there will always also be an InnerClasses attribute. Is that indeed the case? If not then do you have sample Java source that would result in a NestHost or NestMember attribute being generated by javac without an InnerClasses attribute? Best regards, S From s.2016.kay at gmail.com Tue Jul 3 03:55:08 2018 From: s.2016.kay at gmail.com (Ess Kay) Date: Tue, 3 Jul 2018 13:55:08 +1000 Subject: JEP 309 (Dynamic Class-File Constants) integration? Message-ID: Has JEP 309 been integrated into build 20 (2018/6/29)? If not then any idea when JEP 309 will appear in the JDK 11 build? From forax at univ-mlv.fr Tue Jul 3 06:35:28 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 3 Jul 2018 08:35:28 +0200 (CEST) Subject: Generation of NestHost and NestMembers attributes using javac? In-Reply-To: References: <66e05de2-4d36-40f7-e61c-b24b91b29b3a@oracle.com> Message-ID: <733499181.389685.1530599728947.JavaMail.zimbra@u-pem.fr> Hi Ess, the specification of NestHost/NestMember attributes is independent of the InnerClass attribute. The former specifies that there is a private access among the members of the nest the later indicates that the classes comes from the same source files. For javac currently, a nest member is an inner class of the nest host, so the attributes or more or less aligned, but for other languages than Java this may not be the case and in the future, for Java this may not be the case too. Another example, a JavaEE (like) container may generate proxy classes that are nest members of the proxied class without the proxy being an inner class of the proxied class. cheers, R?mi ----- Mail original ----- > De: "Ess Kay" > ?: "Maurizio Cimadamore" > Cc: "compiler-dev" > Envoy?: Mardi 3 Juillet 2018 04:50:14 > Objet: Re: Generation of NestHost and NestMembers attributes using javac? > Hi Maurizio, > >> JEP 181 was integrated On Sat 23rd of June > Thank you. I see build 20 (2018/6/29) is now available. I should have > been patient for one more day ;). > > As far as I can determine, a nest member class is always an inner > class of its nest host class. That is, if there is a NestHost or > NestMember attribute in a class then there will always also be an > InnerClasses attribute. Is that indeed the case? If not then do you > have sample Java source that would result in a NestHost or NestMember > attribute being generated by javac without an InnerClasses attribute? > > Best regards, > S From maurizio.cimadamore at oracle.com Tue Jul 3 09:51:56 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 3 Jul 2018 10:51:56 +0100 Subject: JDK 12 RFR of JDK-8206085 : Refactor langtools/tools/javac/versions/Versions.java In-Reply-To: <7d15d77c-95d8-7e9a-891f-05b3c4547760@oracle.com> References: <50063ce4-ce4c-5666-d1db-a78e5697b0c5@oracle.com> <4564190b-ee82-b4dd-03a5-df690e69a253@oracle.com> <7c73f7f9-ab06-f734-633a-35173a2d45a9@oracle.com> <90aa4ad4-af3e-1c47-8b77-5c4e79c7fe60@gmail.com> <7d15d77c-95d8-7e9a-891f-05b3c4547760@oracle.com> Message-ID: Looks good. I believe the test could be further automatized, by adding more logic to the enum. E.g. each constant could define in a string a snippet of code that is unique to that version (and maybe the BASE version would have an empty snippet). That way the sources could be generated programatically - no need to repeat various headers etc. Also, I believe once you go down this path, it could be even possible to have a single checksrc method which takes a couple of version constants, generate the sources for them using the templating strategy described above. E.g. it would be great if all the 'mutable' parts would be contained to the enum declaration - adding enum constants is rather easy, especially when the structure is clearly self-explanatory (as in this case). Maurizio On 03/07/18 00:38, joe darcy wrote: > > Hi Peter, > > > On 7/2/2018 7:36 AM, Peter Levart wrote: >> Hi Joe, >> >> A suggestion for more compact code: the (ever growing) switch >> statement in enum SourceTarget.checksrc could be replaced with a >> field of type BiConsumer, initialized in >> constructor. For each enum constant you then just pass a method >> reference to the chosen target method. The checksrc in SourceTarget >> could be an instance method. > > I had an intermediate version along those lines before sending the > first one out for review. In the intermediate version, I stored in the > method reference in a field and the enum client code used an accessor > method for it code. The downside was a bit unpleasent to use since the > vararg-ness isn't captured in the generic type. But if checksrc was a > varags instance on the enum, then it could benefit from the varargs > conversion. Let's see ... yes, the resulting test looks better and > should be easier to maintain: > > http://cr.openjdk.java.net/~darcy/8206085.2/ > > Thank you for the suggestion. > > In any case, the span of versions should reduced soon by the removal > of -source/-target/--release 6 in JDK 12 [1], which is one reason I'm > working on refactoring these tests now :-) > > Cheers, > > -Joe > > [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-May/001210.html > >> >> Peter >> >> On 06/29/2018 09:41 PM, joe darcy wrote: >>> Dis-charged revision along with JDK 11 specific source example now >>> up at >>> >>> http://cr.openjdk.java.net/~darcy/8206085.1/ >>> >>> Thanks, >>> >>> -Joe >>> >>> >>> On 6/29/2018 9:55 AM, Jonathan Gibbons wrote: >>>> There's more static in this file than on my high-school Van de >>>> Graaf generator! >>>> >>>> Can we follow the convention of creating an instance in main, and >>>> then using instance methods. >>>> >>>> The naming of some methods is also novel, with respect to >>>> case-conventions. >>>> >>>> -- Jon >>>> >>>> >>>> On 6/28/18 8:15 PM, joe darcy wrote: >>>>> Hello, >>>>> >>>>> Fresh off of updating >>>>> >>>>> ??? langtools/tools/javac/versions/Versions.java >>>>> >>>>> for the JDK 11 -> 12 transition, I'd like to refactor the test to >>>>> reduce the maintenance needed when adding new versions (as in new >>>>> releases) or removing versions (as is planned for later in JDK 12): >>>>> >>>>> http://cr.openjdk.java.net/~darcy/8206085.0/ >>>>> >>>>> Thanks, >>>>> >>>>> -Joe >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Tue Jul 3 09:56:34 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 3 Jul 2018 10:56:34 +0100 Subject: Generation of NestHost and NestMembers attributes using javac? In-Reply-To: <733499181.389685.1530599728947.JavaMail.zimbra@u-pem.fr> References: <66e05de2-4d36-40f7-e61c-b24b91b29b3a@oracle.com> <733499181.389685.1530599728947.JavaMail.zimbra@u-pem.fr> Message-ID: What Remi says :-) Think of InnerClasses as one of those attributes used to store extra source information which is then later used either by javac (when reading from classfiles) or by reflection. The VM doesn't really care about InnerClasses much, as it doesn't about the Signature attribute. Using a new attribute avoids the confusion and, as Remi said, opens the machinery up to cases where classes might not come from the same source. Another example where this might come in handy is valhalla generic specialization, where you want e.g. List and List be part of the same logical 'nest', although they might correspond to different dynamically generated bits which are not in an inner/nested relationship. Cheers Maurizio On 03/07/18 07:35, Remi Forax wrote: > Hi Ess, > the specification of NestHost/NestMember attributes is independent of the InnerClass attribute. > The former specifies that there is a private access among the members of the nest the later indicates that the classes comes from the same source files. > > For javac currently, a nest member is an inner class of the nest host, so the attributes or more or less aligned, but for other languages than Java this may not be the case and in the future, for Java this may not be the case too. Another example, a JavaEE (like) container may generate proxy classes that are nest members of the proxied class without the proxy being an inner class of the proxied class. > > cheers, > R?mi > > ----- Mail original ----- >> De: "Ess Kay" >> ?: "Maurizio Cimadamore" >> Cc: "compiler-dev" >> Envoy?: Mardi 3 Juillet 2018 04:50:14 >> Objet: Re: Generation of NestHost and NestMembers attributes using javac? >> Hi Maurizio, >> >>> JEP 181 was integrated On Sat 23rd of June >> Thank you. I see build 20 (2018/6/29) is now available. I should have >> been patient for one more day ;). >> >> As far as I can determine, a nest member class is always an inner >> class of its nest host class. That is, if there is a NestHost or >> NestMember attribute in a class then there will always also be an >> InnerClasses attribute. Is that indeed the case? If not then do you >> have sample Java source that would result in a NestHost or NestMember >> attribute being generated by javac without an InnerClasses attribute? >> >> Best regards, >> S From wdietl at gmail.com Tue Jul 3 18:31:31 2018 From: wdietl at gmail.com (Werner Dietl) Date: Tue, 3 Jul 2018 14:31:31 -0400 Subject: RFR: JDK-8198945: Invalid RuntimeVisibleTypeAnnotations for annotation on anonymous class type parameter In-Reply-To: References: <5B36C325.7080605@oracle.com> Message-ID: Thanks for the quick fix! The `old.position.location.isEmpty()` doesn't quite do what we would consider a "top-level" annotation. Consider: ``` import java.lang.annotation.ElementType; import java.lang.annotation.Retention; import java.lang.annotation.RetentionPolicy; import java.lang.annotation.Target; @Retention(RetentionPolicy.RUNTIME) @Target({ElementType.TYPE_USE, ElementType.TYPE_PARAMETER}) @interface Foo { int value(); } class OBox {} class JDK8198945 { class IBox {} public void f() { new @Foo(1) OBox<@Foo(2) Object>() { }; new @Foo(3) IBox<@Foo(4) String>() { }; } } ``` 8198945/webrev.02 only creates the NEW annotation for @Foo(1), but not for @Foo(3), because the latter has an INNER_TYPE location. Maybe the right check is that old.position.location doesn't contain any TYPE_ARGUMENT ? Minor: in src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java I would remove the now out-of-date TODO comment: @@ -1332,7 +1334,6 @@ copyNewClassAnnotationsToOwner(tree); // classdecl.sym.type now contains an annotated type, which // is not what we want there. - // TODO: should we put this type somewhere in the superclass/interface? classdecl.sym.type = before; } Best, cu, WMD. On Mon, Jul 2, 2018 at 10:34 PM Liam Miller-Cushon wrote: > > On Mon, Jul 2, 2018 at 7:14 PM Werner Dietl wrote: >> >> Class Test$1 has no type arguments, so I would find having NEW type >> annotations on a type argument confusing. > > > Ah, right. Thanks for the catch. > >> >> So I would be for either no NEW type annotations for anonymous class >> instantiations, or duplicating only the top-level type annotations. >> For method f() this would generate three type annotations: >> >> RuntimeInvisibleTypeAnnotations: >> 0: #22(): NEW, offset=9 >> Test$TA >> 1: #23(): NEW, offset=9, location=[TYPE_ARGUMENT(0)] >> Test$TB >> 2: #22(): NEW, offset=0 >> Test$TA >> >> Duplicating only the top-level type annotations would be my slight >> preference over no NEW annotations at all. > > > I revised the fix to only duplicate top-level annotations: > http://cr.openjdk.java.net/~cushon/8198945/webrev.02 -- http://www.google.com/profiles/wdietl From alex.buckley at oracle.com Tue Jul 3 18:37:11 2018 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 03 Jul 2018 11:37:11 -0700 Subject: RFR: JDK-8198945: Invalid RuntimeVisibleTypeAnnotations for annotation on anonymous class type parameter In-Reply-To: References: <5B36C325.7080605@oracle.com> Message-ID: <5B3BC257.10101@oracle.com> On 7/2/2018 7:34 PM, Liam Miller-Cushon wrote: > On Mon, Jul 2, 2018 at 7:14 PM Werner Dietl > wrote: > > Class Test$1 has no type arguments, so I would find having NEW type > annotations on a type argument confusing. > > Ah, right. Thanks for the catch. > > So I would be for either no NEW type annotations for anonymous class > instantiations, or duplicating only the top-level type annotations. > For method f() this would generate three type annotations: > > RuntimeInvisibleTypeAnnotations: > 0: #22(): NEW, offset=9 > Test$TA > 1: #23(): NEW, offset=9, location=[TYPE_ARGUMENT(0)] > Test$TB > 2: #22(): NEW, offset=0 > Test$TA > > Duplicating only the top-level type annotations would be my slight > preference over no NEW annotations at all. > > > I revised the fix to only duplicate top-level annotations: > http://cr.openjdk.java.net/~cushon/8198945/webrev.02 > I am OK with this. To be clear, given this code in a method of class Test: new @TA I<@TB Object>() {}; new @TA J<@TB Object>(); we're going to generate annotations as if the code was: new @TA Test$1(); new @TA J<@TB Object>(); class Test$1 implements @TA I<@TB Object> {} (The type_annotation structure for the first @TA has a NEW target_type, while the type_annotation structure for the second @TA has a CLASS_EXTENDS target_type. Since the structures are not identical, it's misleading to say that anything is "duplicated".) Alex From cushon at google.com Tue Jul 3 22:17:02 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 3 Jul 2018 15:17:02 -0700 Subject: RFR: JDK-8198945: Invalid RuntimeVisibleTypeAnnotations for annotation on anonymous class type parameter In-Reply-To: References: <5B36C325.7080605@oracle.com> Message-ID: On Tue, Jul 3, 2018 at 11:31 AM Werner Dietl wrote: > 8198945/webrev.02 only creates the NEW annotation for @Foo(1), but not > for @Foo(3), because the latter has an INNER_TYPE location. > Maybe the right check is that old.position.location doesn't contain > any TYPE_ARGUMENT ? > Good point. Do we also need to add an INNER_TYPE location to the NEW annotation, since the synthetic anonymous class declaration is itself an inner class? e.g. given: class Other {} class Outer { class Inner { public void f() { new @A Other() {}; } } } Do we need an [INNER_TYPE, INNER_TYPE] location to indicate that the NEW annotation is on the type Outer$Inner$1, not Outer or Outer$Inner? This would involve creating INNER_TYPE entries corresponding to any enclosing classes of the synthetic anonymous class declaration, and ignoring INNER_TYPE entries on the supertype when propagating the annotation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Tue Jul 3 23:03:51 2018 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 3 Jul 2018 16:03:51 -0700 Subject: JDK 12 RFR of JDK-8206085 : Refactor langtools/tools/javac/versions/Versions.java In-Reply-To: References: <50063ce4-ce4c-5666-d1db-a78e5697b0c5@oracle.com> <4564190b-ee82-b4dd-03a5-df690e69a253@oracle.com> <7c73f7f9-ab06-f734-633a-35173a2d45a9@oracle.com> <90aa4ad4-af3e-1c47-8b77-5c4e79c7fe60@gmail.com> <7d15d77c-95d8-7e9a-891f-05b3c4547760@oracle.com> Message-ID: Hi Maurizio, On 7/3/2018 2:51 AM, Maurizio Cimadamore wrote: > > Looks good. > > I believe the test could be further automatized, by adding more logic > to the enum. E.g. each constant could define in a string a snippet of > code that is unique to that version (and maybe the BASE version would > have an empty snippet). That way the sources could be generated > programatically - no need to repeat various headers etc. Also, I > believe once you go down this path, it could be even possible to have > a single checksrc method which takes a couple of version constants, > generate the sources for them using the templating strategy described > above. > > E.g. it would be great if all the 'mutable' parts would be contained > to the enum declaration - adding enum constants is rather easy, > especially when the structure is clearly self-explanatory (as in this > case). > > Thanks for the review. Further refactoring for another day; this test has some a long way from its earlier days as a shell script! Cheers, -Joe From jonathan.gibbons at oracle.com Tue Jul 3 23:11:41 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 3 Jul 2018 16:11:41 -0700 Subject: JDK 12 RFR of JDK-8206114: Refactor langtools/tools/javac/classfiles/ClassVersionChecker.java In-Reply-To: <6ad3c11c-a581-720c-ee38-21a6a8ec4386@oracle.com> References: <6ad3c11c-a581-720c-ee38-21a6a8ec4386@oracle.com> Message-ID: <03b3f449-6123-a242-daa9-7a4b02c4798f@oracle.com> +1 There are opportunities for additional cleanup, maybe later, like whitespace fixes and using nio Files.writeFile etc. Also, the "-g" option for javac looks gratuitous. -- Jon On 6/30/18 9:45 AM, joe darcy wrote: > Hello, > > Another day, another version-related test refactoring: > > ??? JDK-8206114: Refactor > langtools/tools/javac/classfiles/ClassVersionChecker.java > ??? http://cr.openjdk.java.net/~darcy/8206114.0/ > > I've verified the ease of maintenance of the test by removing the > TWELVE enum value and running the test against JDK 11. > > This is overlap in the test coverage of this test and other other test > out for review, but I haven't not tried to precisely determine or > eliminate that overlap. > > Thanks, > > -Joe > From jonathan.gibbons at oracle.com Tue Jul 3 23:16:48 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 3 Jul 2018 16:16:48 -0700 Subject: JDK 12 RFR of JDK-8206085 : Refactor langtools/tools/javac/versions/Versions.java In-Reply-To: References: <50063ce4-ce4c-5666-d1db-a78e5697b0c5@oracle.com> <4564190b-ee82-b4dd-03a5-df690e69a253@oracle.com> <7c73f7f9-ab06-f734-633a-35173a2d45a9@oracle.com> <90aa4ad4-af3e-1c47-8b77-5c4e79c7fe60@gmail.com> <7d15d77c-95d8-7e9a-891f-05b3c4547760@oracle.com> Message-ID: On 7/3/18 4:03 PM, joe darcy wrote: > Hi Maurizio, > > > On 7/3/2018 2:51 AM, Maurizio Cimadamore wrote: >> >> Looks good. >> >> I believe the test could be further automatized, by adding more logic >> to the enum. E.g. each constant could define in a string a snippet of >> code that is unique to that version (and maybe the BASE version would >> have an empty snippet). That way the sources could be generated >> programatically - no need to repeat various headers etc. Also, I >> believe once you go down this path, it could be even possible to have >> a single checksrc method which takes a couple of version constants, >> generate the sources for them using the templating strategy described >> above. >> >> E.g. it would be great if all the 'mutable' parts would be contained >> to the enum declaration - adding enum constants is rather easy, >> especially when the structure is clearly self-explanatory (as in this >> case). >> >> > > Thanks for the review. > > Further refactoring for another day; this test has some a long way > from its earlier days as a shell script! http://hg.openjdk.java.net/jdk6/jdk6/langtools/file/fde47df50cab/test/tools/javac/versions/check.sh :-) > > Cheers, > > -Joe From cushon at google.com Thu Jul 5 17:03:30 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Thu, 5 Jul 2018 10:03:30 -0700 Subject: RFR: 8204630: generating an anonymous class with Filer#createClassFile causes an NPE in JavacProcessingEnvironment In-Reply-To: References: <5B1FD510.1090808@oracle.com> Message-ID: Ping. Should I defer this to 12? On Thu, Jun 28, 2018 at 5:19 PM Liam Miller-Cushon wrote: > Hi, > > Is there any more feedback on this? > > The bug is currently targeted for JDK 11, but I can defer it if there are > any concerns. > > Thanks, > Liam > > On Tue, Jun 12, 2018 at 7:50 PM Liam Miller-Cushon > wrote: > >> Hi Jan, >> >> Thanks for the review, and the explanation! >> >> On Tue, Jun 12, 2018 at 7:13 AM Jan Lahoda wrote: >> >>> So the change in JavacProcessingEnvironment could be, I think, rewritten >>> as: >>> if (cs.owner.kind == PCK) { >>> cs.owner.members().enterIfAbsent(cs); >>> } >>> >> >> Done. >> >> The change in ClassReader seems unnecessary, or am I mistaken? >>> >> >> Nope, I think you're right. >> >> Updated webrev: >> http://cr.openjdk.java.net/~cushon/8204630/webrev.01/ >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Thu Jul 5 17:45:25 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 5 Jul 2018 10:45:25 -0700 Subject: RFR: 8204630: generating an anonymous class with Filer#createClassFile causes an NPE in JavacProcessingEnvironment In-Reply-To: References: <5B1FD510.1090808@oracle.com> Message-ID: It's a crash. Once it is approved, you can push to the jdk/jdk11 repo. -- Jon On 7/5/18 10:03 AM, Liam Miller-Cushon wrote: > Ping. Should I defer this to 12? > > On Thu, Jun 28, 2018 at 5:19 PM Liam Miller-Cushon > wrote: > > Hi, > > Is there any more feedback on this? > > The bug is currently targeted for JDK 11, but I can defer it if > there are any concerns. > > Thanks, > Liam > > On Tue, Jun 12, 2018 at 7:50 PM Liam Miller-Cushon > > wrote: > > Hi Jan, > > Thanks for the review, and the explanation! > > On Tue, Jun 12, 2018 at 7:13 AM Jan Lahoda > > wrote: > > So the change in JavacProcessingEnvironment could be, I > think, rewritten as: > if (cs.owner.kind == PCK) { > ? ? ?cs.owner.members().enterIfAbsent(cs); > } > > > Done. > > The change in ClassReader seems unnecessary, or am I mistaken? > > > Nope, I think you're right. > > Updated webrev: > http://cr.openjdk.java.net/~cushon/8204630/webrev.01/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Thu Jul 5 18:51:59 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 05 Jul 2018 20:51:59 +0200 Subject: RFR: 8204630: generating an anonymous class with Filer#createClassFile causes an NPE in JavacProcessingEnvironment In-Reply-To: References: <5B1FD510.1090808@oracle.com> Message-ID: <8ABE0F48-9C71-4B4A-B37E-32F15DEFF2AD@oracle.com> Seems fine to me. Jan 5. ?ervence 2018 19:03:30 SEL?, Liam Miller-Cushon napsal: >Ping. Should I defer this to 12? > >On Thu, Jun 28, 2018 at 5:19 PM Liam Miller-Cushon >wrote: > >> Hi, >> >> Is there any more feedback on this? >> >> The bug is currently targeted for JDK 11, but I can defer it if there >are >> any concerns. >> >> Thanks, >> Liam >> >> On Tue, Jun 12, 2018 at 7:50 PM Liam Miller-Cushon > >> wrote: >> >>> Hi Jan, >>> >>> Thanks for the review, and the explanation! >>> >>> On Tue, Jun 12, 2018 at 7:13 AM Jan Lahoda >wrote: >>> >>>> So the change in JavacProcessingEnvironment could be, I think, >rewritten >>>> as: >>>> if (cs.owner.kind == PCK) { >>>> cs.owner.members().enterIfAbsent(cs); >>>> } >>>> >>> >>> Done. >>> >>> The change in ClassReader seems unnecessary, or am I mistaken? >>>> >>> >>> Nope, I think you're right. >>> >>> Updated webrev: >>> http://cr.openjdk.java.net/~cushon/8204630/webrev.01/ >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Fri Jul 6 02:19:16 2018 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 5 Jul 2018 19:19:16 -0700 Subject: JDK 12 RFR of JDK-8206439: Remove javac -source/-target 6 from langtools regression tests Message-ID: Hello, Laying some groundwork for the future removal of javac's -source/-target 6 later in JDK 12, please review this initial pass to remove most usages of -source/-target 6/1.6 from the lantools regression tests: ??? http://cr.openjdk.java.net/~darcy/8206439.0/ A number of 6-specific foo.out files are removed. Various other *.out files are adjusted to accommodate removal of a @compile line containing -source or -target 6. Thanks, -Joe From joe.darcy at oracle.com Fri Jul 6 03:05:46 2018 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 5 Jul 2018 20:05:46 -0700 Subject: RFR(s): JDK-8205455: jdeprscan issues annotation processor warning regarding RELEASE_10 In-Reply-To: <47364090-cd43-8f63-57b4-475fde77ffef@oracle.com> References: <24e14c63-4b8f-2ce1-d4b9-c24be769e833@oracle.com> <1309b09f-bbbc-867d-7220-25fbf02ba1ea@oracle.com> <47364090-cd43-8f63-57b4-475fde77ffef@oracle.com> Message-ID: <86f6f2c6-c941-bcc0-5aae-817838c780e4@oracle.com> Belatedly catching up on review email, although the fix has already been reviewed and pushed, I wanted to make a counterpoint for future consideration. While it is more future proof to have an annotation processor return SourceVersion.latest(), doing that can mask actual updates that need to be made to support the a newer source level. If a new kind of element were added, it is likely a processor would need to be updated to maintain its semantics over the expanded set of elements now possible. Cheers, -Joe On 6/25/2018 5:04 PM, Stuart Marks wrote: > > Hi Jon, > > Good point. It seems fairly unlikely for jdeprscan to be outright > broken by a model change, given that jdeprscan uses annotation > processing for class scanning, not source code analysis. > > I've posted an updated webrev here: > > http://cr.openjdk.java.net/~smarks/reviews/8205455/webrev.1/ > > (previous patch posted as webrev.0 for completeness) > > s'marks > > > On 6/25/18 3:35 PM, Jonathan Gibbons wrote: >> >> Stuart, >> >> This would be more future-proof if you did not use these lines: >> >> >> - at SupportedSourceVersion(RELEASE_10) >> + at SupportedSourceVersion(RELEASE_11) >> >> but instead provided an override definition like this, taken from >> test/langtools/tools/javac/lib/JavacTestingAbstractProcessor: >> >> /** >> * Return the latest source version. Unless this method is >> * overridden, an {@code IllegalStateException} will be thrown if a >> * subclass has a {@code SupportedSourceVersion} annotation. >> */ >> @Override >> public SourceVersion getSupportedSourceVersion() { >> SupportedSourceVersion ssv = >> this.getClass().getAnnotation(SupportedSourceVersion.class); >> if (ssv != null) >> throw new IllegalStateException("SupportedSourceVersion annotation >> not supported here."); >> >> return SourceVersion.latest(); >> } >> >> or, more simply >> >> @Override >> public SourceVersion getSupportedSourceVersion() { >> return SourceVersion.latest(); >> } >> On 6/25/18 3:28 PM, Stuart Marks wrote: >>> Hi all, >>> >>> Please review this small changeset that updates one of jdeprscan's >>> annotation processors to RELEASE_11 in order to prevent warning >>> messages from being issued. This changeset also includes some >>> additional output lines so that the output of jdeprscan's >>> TestRelease.java test is more readable. >>> >>> Patch appended below. >>> >>> Bug: >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Fri Jul 6 14:22:23 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 6 Jul 2018 15:22:23 +0100 Subject: JDK 12 RFR of JDK-8206439: Remove javac -source/-target 6 from langtools regression tests In-Reply-To: References: Message-ID: <02fa4be6-ab0a-31ba-5056-4c970490f48c@oracle.com> Looks good - I found this new line I'm dubious about + * @compile/ref=gold_unsp_warn.out -XDrawDiagnostics -processor TestSourceVersionWarnings -proc:only -ASourceVersion=RELEASE_6 -source 6 -Xlint:-options -Aunsupported HelloWorld.java (this is in test/langtools/tools/javac/processing/warnings/TestSourceVersionWarnings.java) Are you sure that the -source 6 is deliberate here? Maurizio On 06/07/18 03:19, joe darcy wrote: > Hello, > > Laying some groundwork for the future removal of javac's > -source/-target 6 later in JDK 12, please review this initial pass to > remove most usages of -source/-target 6/1.6 from the lantools > regression tests: > > ??? http://cr.openjdk.java.net/~darcy/8206439.0/ > > A number of 6-specific foo.out files are removed. Various other *.out > files are adjusted to accommodate removal of a @compile line > containing -source or -target 6. > > Thanks, > > -Joe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Fri Jul 6 16:56:11 2018 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 6 Jul 2018 09:56:11 -0700 Subject: JDK 12 RFR of JDK-8206439: Remove javac -source/-target 6 from langtools regression tests In-Reply-To: <02fa4be6-ab0a-31ba-5056-4c970490f48c@oracle.com> References: <02fa4be6-ab0a-31ba-5056-4c970490f48c@oracle.com> Message-ID: <6583a123-be30-2e93-91eb-3c11bc47f57a@oracle.com> Hi Maurizio, On 7/6/2018 7:22 AM, Maurizio Cimadamore wrote: > > Looks good - I found this new line I'm dubious about > > + * @compile/ref=gold_unsp_warn.out -XDrawDiagnostics -processor > TestSourceVersionWarnings -proc:only -ASourceVersion=RELEASE_6 -source > 6 -Xlint:-options -Aunsupported HelloWorld.java > > (this is in > test/langtools/tools/javac/processing/warnings/TestSourceVersionWarnings.java) > > Are you sure that the -source 6 is deliberate here? Good catch; I'll change that line to use RELEASE_8 and -source 8 before pushing. Thanks, -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Fri Jul 6 23:59:46 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Fri, 6 Jul 2018 16:59:46 -0700 Subject: RFR: 8204630: generating an anonymous class with Filer#createClassFile causes an NPE in JavacProcessingEnvironment In-Reply-To: <8ABE0F48-9C71-4B4A-B37E-32F15DEFF2AD@oracle.com> References: <5B1FD510.1090808@oracle.com> <8ABE0F48-9C71-4B4A-B37E-32F15DEFF2AD@oracle.com> Message-ID: Thanks for the review! I pushed to jdk/jdk11: http://hg.openjdk.java.net/jdk/jdk11/rev/f8ebefc29b79 On Thu, Jul 5, 2018 at 11:52 AM Jan Lahoda wrote: > Seems fine to me. > > Jan > > > 5. ?ervence 2018 19:03:30 SEL?, Liam Miller-Cushon > napsal: >> >> Ping. Should I defer this to 12? >> >> On Thu, Jun 28, 2018 at 5:19 PM Liam Miller-Cushon >> wrote: >> >>> Hi, >>> >>> Is there any more feedback on this? >>> >>> The bug is currently targeted for JDK 11, but I can defer it if there >>> are any concerns. >>> >>> Thanks, >>> Liam >>> >>> On Tue, Jun 12, 2018 at 7:50 PM Liam Miller-Cushon >>> wrote: >>> >>>> Hi Jan, >>>> >>>> Thanks for the review, and the explanation! >>>> >>>> On Tue, Jun 12, 2018 at 7:13 AM Jan Lahoda >>>> wrote: >>>> >>>>> So the change in JavacProcessingEnvironment could be, I think, >>>>> rewritten as: >>>>> if (cs.owner.kind == PCK) { >>>>> cs.owner.members().enterIfAbsent(cs); >>>>> } >>>>> >>>> >>>> Done. >>>> >>>> The change in ClassReader seems unnecessary, or am I mistaken? >>>>> >>>> >>>> Nope, I think you're right. >>>> >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~cushon/8204630/webrev.01/ >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From wdietl at gmail.com Sat Jul 7 02:24:17 2018 From: wdietl at gmail.com (Werner Dietl) Date: Fri, 6 Jul 2018 22:24:17 -0400 Subject: RFR: JDK-8198945: Invalid RuntimeVisibleTypeAnnotations for annotation on anonymous class type parameter In-Reply-To: References: <5B36C325.7080605@oracle.com> Message-ID: I agree that we should handle a NEW annotation on the anonymous class creation like a NEW annotation on a method-local class instantiation. In your example, the result should be equivalent to: class Other {} class Outer { class Inner { public void f() { class Local extends @A Other {}; new @A Local(); } } } That is, I would expect: Outer$Inner.class for method f(): RuntimeInvisibleTypeAnnotations: 0: #19(): NEW, offset=0, location=[INNER_TYPE, INNER_TYPE] A Outer\$Inner\$1Local.class for the class: RuntimeInvisibleTypeAnnotations: 0: #17(): CLASS_EXTENDS, type_index=65535 A As Alex points out, we shouldn't think of it as duplicating the @A annotation in these two locations, but instead determine the correct location for each individual use - as in the desugaring. I therefore don't agree with the "ignoring" part in your last sentence ("This would involve creating INNER_TYPE entries corresponding to any enclosing classes of the synthetic anonymous class declaration, and ignoring INNER_TYPE entries on the supertype when propagating the annotation.") Take this slight re-shuffling of the example: class Outer { class Other {} class Inner { public void f() { class Local extends @A Other {}; new @A Local(); } } } I would now expect: Outer$Inner.class for method f(): RuntimeInvisibleTypeAnnotations: 0: #19(): NEW, offset=0, location=[INNER_TYPE, INNER_TYPE] A Outer\$Inner\$1Local.class for the class: RuntimeInvisibleTypeAnnotations: 0: #18(): CLASS_EXTENDS, type_index=65535, location=[INNER_TYPE] A The annotation location for the NEW would stay unchanged, but the CLASS_EXTENDS now has an INNER_TYPE. As an example where both NEW and CLASS_EXTENDS have the same number of INNER_TYPEs: class Outer { public void f() { class Local extends @A Other {}; new @A Local(); } class Other {} } In the following I would expect that the NEW has fewer INNER_TYPE than the CLASS_EXTENDS: class Outer { public void f(Inner i) { i.new @A Other() {}; } class Inner { class Other {} } } but I didn't get the desugaring to work. (Is there a way to write the desugaring?) So instead of duplicating and filtering out some locations, we should properly determine the locations for these two usages. Does this sound good to you? Best, cu, WMD. On Tue, Jul 3, 2018 at 6:17 PM Liam Miller-Cushon wrote: > > On Tue, Jul 3, 2018 at 11:31 AM Werner Dietl wrote: >> >> 8198945/webrev.02 only creates the NEW annotation for @Foo(1), but not >> for @Foo(3), because the latter has an INNER_TYPE location. >> Maybe the right check is that old.position.location doesn't contain >> any TYPE_ARGUMENT ? > > > Good point. Do we also need to add an INNER_TYPE location to the NEW annotation, since the synthetic anonymous class declaration is itself an inner class? e.g. given: > > class Other {} > class Outer { > class Inner { > public void f() { > new @A Other() {}; > } > } > } > > Do we need an [INNER_TYPE, INNER_TYPE] location to indicate that the NEW annotation is on the type Outer$Inner$1, not Outer or Outer$Inner? > > This would involve creating INNER_TYPE entries corresponding to any enclosing classes of the synthetic anonymous class declaration, and ignoring INNER_TYPE entries on the supertype when propagating the annotation. -- http://www.google.com/profiles/wdietl From s.2016.kay at gmail.com Sun Jul 8 05:41:27 2018 From: s.2016.kay at gmail.com (Ess Kay) Date: Sun, 8 Jul 2018 15:41:27 +1000 Subject: JEP 309 (Dynamic Class-File Constants) integration into build 21? Message-ID: Has JEP 309 been integrated into build 21 (2018/7/5)? I am unable to get javac to generate a CONSTANT_Dynamic entry. If JEP 309 has not yet been integrated any idea when it will appear in the JDK 11 build? Need to be able to generate our own more complicate test cases prior to general availability. From forax at univ-mlv.fr Sun Jul 8 11:11:33 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 8 Jul 2018 13:11:33 +0200 (CEST) Subject: JEP 309 (Dynamic Class-File Constants) integration into build 21? In-Reply-To: References: Message-ID: <411606600.1997599.1531048293023.JavaMail.zimbra@u-pem.fr> Hi Ess, ----- Mail original ----- > De: "Ess Kay" > ?: "compiler-dev" > Envoy?: Dimanche 8 Juillet 2018 07:41:27 > Objet: JEP 309 (Dynamic Class-File Constants) integration into build 21? > Has JEP 309 been integrated into build 21 (2018/7/5)? I am unable to > get javac to generate a CONSTANT_Dynamic entry. the VM recognizes CONSTANT_Dynamic but there is no feature of Java the language that uses CONSTANT_Dynamic yet, it's like when Java 7 VM has the support of invokedynamic but Java using it only in 8 for creating lambdas. There are several features that may use CONSTANT_Dynamic, the JEP 303, constant lambdas creation, switch (expression switch or plain old switch on String and Enums), but none of them are currently integrated with the JDK. > > If JEP 309 has not yet been integrated any idea when it will appear in > the JDK 11 build? Need to be able to generate our own more complicate > test cases prior to general availability. You can test using ASM [1] (6.2 and up) or if you are adventurous you can use cplisp [2] which is a lisp that can compile its expression into CONSTANT_Dynamics. R?mi [1] https://asm.ow2.io/ [2] https://github.com/forax/cplisp From joe.darcy at oracle.com Sun Jul 8 17:01:22 2018 From: joe.darcy at oracle.com (joe darcy) Date: Sun, 8 Jul 2018 10:01:22 -0700 Subject: JDK 12 RFR of JDK-802856: Remove javac support for 6/1.6 source and target values Message-ID: Hello, Please review the initial implementation of ??? JDK-802856: Remove javac support for 6/1.6 source and target values ??? http://cr.openjdk.java.net/~darcy/8028563.4/ and the accompanying CSR: ??? https://bugs.openjdk.java.net/browse/JDK-8206877 I suspect at least one adjustment of the changeset will be needed, as discussed below. All the langtools tests pass with these changes. A few comments about the current state of the patch: Updating the various components of the compiler was in part revisiting and then retiring some of the detailed engineering done for Project Coin, such as giving distinct error messages about a try statement lacking other pieces dependent on whether or not try-with-resources is supported under the source version in effect. The refactoring in Source.java to use the Feature enum was easy to work with. Excising the now conceptually dead code and checks was straightforward. The enum constant for DIAMOND was *not* removed, although it is also semantically unconditionally true now just like the other introduced-in-7 features, because messages about diamond from checkSourceLevel called in the parser are used in the testing? of diagnostics generated for the preview feature functionality. I didn't dig down to try to determine the full set of interactions here. There is also support for the diamond finder elsewhere in the compiler. I think it would be acceptable to leave DIAMOND available as a enum constant if there are other uses for it. While an earlier changeset cleared out uses of -source 6 and -target 6 (JDK-8206439), various other tests needed updating since -source 7 is now obsolete. This was often handled by adding "-lint:-options" to the compile invocation. I'll file a follow-up issue to add "-lint:-options" to a handful of uses of -source 8 to avoid similar edits being needed in the future. For expediency, I ignored the warning in make/data/symbols/symbols that "THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT." and edited the file to remove support for --release 6. This aspect of the change should be redone properly, but I thought it would be quicker to ask about this point during the code review than investigate how this aspect of the build works. Once the proper way is determined, I'll send a note to build-dev for a review of that aspect of the change. Thanks, -Joe From scolebourne at joda.org Sun Jul 8 17:18:17 2018 From: scolebourne at joda.org (Stephen Colebourne) Date: Sun, 8 Jul 2018 18:18:17 +0100 Subject: JDK 12 RFR of JDK-802856: Remove javac support for 6/1.6 source and target values In-Reply-To: References: Message-ID: While sad to see Java 6 go, I think JDK 12 is the right time, so +1 for the basic idea of the change here. thanks Stephen On 8 July 2018 at 18:01, joe darcy wrote: > Hello, > > Please review the initial implementation of > > JDK-802856: Remove javac support for 6/1.6 source and target values > http://cr.openjdk.java.net/~darcy/8028563.4/ > > and the accompanying CSR: > > https://bugs.openjdk.java.net/browse/JDK-8206877 > > I suspect at least one adjustment of the changeset will be needed, as > discussed below. > > All the langtools tests pass with these changes. > > A few comments about the current state of the patch: > > Updating the various components of the compiler was in part revisiting and > then retiring some of the detailed engineering done for Project Coin, such > as giving distinct error messages about a try statement lacking other pieces > dependent on whether or not try-with-resources is supported under the source > version in effect. > > The refactoring in Source.java to use the Feature enum was easy to work > with. Excising the now conceptually dead code and checks was > straightforward. The enum constant for DIAMOND was *not* removed, although > it is also semantically unconditionally true now just like the other > introduced-in-7 features, because messages about diamond from > checkSourceLevel called in the parser are used in the testing of > diagnostics generated for the preview feature functionality. I didn't dig > down to try to determine the full set of interactions here. There is also > support for the diamond finder elsewhere in the compiler. I think it would > be acceptable to leave DIAMOND available as a enum constant if there are > other uses for it. > > While an earlier changeset cleared out uses of -source 6 and -target 6 > (JDK-8206439), various other tests needed updating since -source 7 is now > obsolete. This was often handled by adding "-lint:-options" to the compile > invocation. I'll file a follow-up issue to add "-lint:-options" to a handful > of uses of -source 8 to avoid similar edits being needed in the future. > > For expediency, I ignored the warning in make/data/symbols/symbols that > "THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT." and edited the file to > remove support for --release 6. This aspect of the change should be redone > properly, but I thought it would be quicker to ask about this point during > the code review than investigate how this aspect of the build works. Once > the proper way is determined, I'll send a note to build-dev for a review of > that aspect of the change. > > Thanks, > > -Joe > > From forax at univ-mlv.fr Sun Jul 8 18:42:34 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 8 Jul 2018 20:42:34 +0200 (CEST) Subject: JDK 12 RFR of JDK-802856: Remove javac support for 6/1.6 source and target values In-Reply-To: References: Message-ID: <866700033.2038665.1531075354978.JavaMail.zimbra@u-pem.fr> Hi Stephen, ----- Mail original ----- > De: "Stephen Colebourne" > ?: "compiler-dev" > Envoy?: Dimanche 8 Juillet 2018 19:18:17 > Objet: Re: JDK 12 RFR of JDK-802856: Remove javac support for 6/1.6 source and target values > While sad to see Java 6 go, I think JDK 12 is the right time, so +1 > for the basic idea of the change here. > thanks i know that you know but Java 6 is not dead yet, Azul Zulu [1] still offer free download of the OpenJDK 6, and i'm sure other companies still offer paying support for 6, what is removed is the support of the target 6 in JDK 12 compiler. > Stephen R?mi [1] https://www.azul.com/downloads/zulu/zulu-linux/ > > On 8 July 2018 at 18:01, joe darcy wrote: >> Hello, >> >> Please review the initial implementation of >> >> JDK-802856: Remove javac support for 6/1.6 source and target values >> http://cr.openjdk.java.net/~darcy/8028563.4/ >> >> and the accompanying CSR: >> >> https://bugs.openjdk.java.net/browse/JDK-8206877 >> >> I suspect at least one adjustment of the changeset will be needed, as >> discussed below. >> >> All the langtools tests pass with these changes. >> >> A few comments about the current state of the patch: >> >> Updating the various components of the compiler was in part revisiting and >> then retiring some of the detailed engineering done for Project Coin, such >> as giving distinct error messages about a try statement lacking other pieces >> dependent on whether or not try-with-resources is supported under the source >> version in effect. >> >> The refactoring in Source.java to use the Feature enum was easy to work >> with. Excising the now conceptually dead code and checks was >> straightforward. The enum constant for DIAMOND was *not* removed, although >> it is also semantically unconditionally true now just like the other >> introduced-in-7 features, because messages about diamond from >> checkSourceLevel called in the parser are used in the testing of >> diagnostics generated for the preview feature functionality. I didn't dig >> down to try to determine the full set of interactions here. There is also >> support for the diamond finder elsewhere in the compiler. I think it would >> be acceptable to leave DIAMOND available as a enum constant if there are >> other uses for it. >> >> While an earlier changeset cleared out uses of -source 6 and -target 6 >> (JDK-8206439), various other tests needed updating since -source 7 is now >> obsolete. This was often handled by adding "-lint:-options" to the compile >> invocation. I'll file a follow-up issue to add "-lint:-options" to a handful >> of uses of -source 8 to avoid similar edits being needed in the future. >> >> For expediency, I ignored the warning in make/data/symbols/symbols that >> "THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT." and edited the file to >> remove support for --release 6. This aspect of the change should be redone >> properly, but I thought it would be quicker to ask about this point during >> the code review than investigate how this aspect of the build works. Once >> the proper way is determined, I'll send a note to build-dev for a review of >> that aspect of the change. >> >> Thanks, >> >> -Joe >> From joe.darcy at oracle.com Sun Jul 8 20:32:05 2018 From: joe.darcy at oracle.com (joe darcy) Date: Sun, 8 Jul 2018 13:32:05 -0700 Subject: JDK 12 RFR of JDK-8173606: Deprecate constructors of 7-era visitors Message-ID: <80cb5d6f-5428-7667-8b24-5138cd4ea2d3@oracle.com> Hello, Please review the changeset ??? JDK-8173606: Deprecate constructors of 7-era visitors ??? http://cr.openjdk.java.net/~darcy/8173606.0/ and corresponding CSR ??? ??? https://bugs.openjdk.java.net/browse/JDK-8206878 The changeset follows the pattern previously established for deprecating the JDK 6-era visitors in the same release as -source/-target 6 was made obsolete. Thanks, -Joe From cushon at google.com Mon Jul 9 19:23:16 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 9 Jul 2018 12:23:16 -0700 Subject: Problems building with --release=8 In-Reply-To: References: <5c0ad745-def9-6617-96a3-ce9bc20fe349@oracle.com> Message-ID: On Fri, Jun 22, 2018 at 9:02 AM Liam Miller-Cushon wrote: > On Wed, Jan 17, 2018 at 9:43 AM Jonathan Gibbons < > jonathan.gibbons at oracle.com> wrote: > >> That being said, there has been discussion recently about providing >> access to some of the API that precedes jdk.unsupported, as a special >> case. >> > > What was the outcome of the discussion you mentioned? Is there still > interest in making it possible to access those APIs when using --release < > 9? > I filed a bug to track this: https://bugs.openjdk.java.net/browse/JDK-8206937 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Tue Jul 10 20:54:59 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 10 Jul 2018 13:54:59 -0700 Subject: [12] (S) RFR 8206122 : Use Queue in place of ArrayList when need to remove first element Message-ID: Hello! It is a tiny optimization. There are a couple of places where ArrayList is used as FIFO: elements are appended to the end, and removed from the head. ArrayDeque would be more efficient to use. Would you please help review? BUG: https://bugs.openjdk.java.net/browse/JDK-8206122 Webrev: http://cr.openjdk.java.net/~igerasim/8206122/00/webrev/ Thanks in advance! -- With kind regards, Ivan Gerasimov From martinrb at google.com Tue Jul 10 21:32:37 2018 From: martinrb at google.com (Martin Buchholz) Date: Tue, 10 Jul 2018 14:32:37 -0700 Subject: [12] (S) RFR 8206122 : Use Queue in place of ArrayList when need to remove first element In-Reply-To: References: Message-ID: I'm happy to see ArrayDeque replacing uses of ArrayList. private final Map, Deque> options2Contexts = new HashMap<>(); Looks like these Deques are used only via the Queue interface. I would either switch to Queue or to ArrayDeque (which might help the VM optimize). On Tue, Jul 10, 2018 at 1:54 PM, Ivan Gerasimov wrote: > Hello! > > It is a tiny optimization. > > There are a couple of places where ArrayList is used as FIFO: elements are > appended to the end, and removed from the head. > > ArrayDeque would be more efficient to use. > > Would you please help review? > > BUG: https://bugs.openjdk.java.net/browse/JDK-8206122 > > Webrev: http://cr.openjdk.java.net/~igerasim/8206122/00/webrev/ > > Thanks in advance! > > -- > With kind regards, > Ivan Gerasimov > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Tue Jul 10 23:38:12 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 10 Jul 2018 16:38:12 -0700 Subject: [12] (S) RFR 8206122 : Use Queue in place of ArrayList when need to remove first element In-Reply-To: References: Message-ID: <0616146a-bdf3-4f2f-b4c9-537e07107927@oracle.com> Thank you Martin! On 7/10/18 2:32 PM, Martin Buchholz wrote: > I'm happy to see ArrayDeque replacing uses of ArrayList. > > private final Map, Deque> > options2Contexts = new HashMap<>(); > Looks like these Deques are used only via the Queue interface. I would > either switch to Queue or to ArrayDeque (which might help the VM > optimize). Right. I can't remember why I used Deque in one place and Queue in the other. Please find the updated webrev here: http://cr.openjdk.java.net/~igerasim/8206122/01/webrev/ With kind regards, Ivan > > On Tue, Jul 10, 2018 at 1:54 PM, Ivan Gerasimov > > wrote: > > Hello! > > It is a tiny optimization. > > There are a couple of places where ArrayList is used as FIFO: > elements are appended to the end, and removed from the head. > > ArrayDeque would be more efficient to use. > > Would you please help review? > > BUG: https://bugs.openjdk.java.net/browse/JDK-8206122 > > > Webrev: http://cr.openjdk.java.net/~igerasim/8206122/00/webrev/ > > > Thanks in advance! > > -- > With kind regards, > Ivan Gerasimov > > -- With kind regards, Ivan Gerasimov -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Tue Jul 10 23:43:58 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 10 Jul 2018 16:43:58 -0700 Subject: [12] (S) RFR 8206122 : Use Queue in place of ArrayList when need to remove first element In-Reply-To: <0616146a-bdf3-4f2f-b4c9-537e07107927@oracle.com> References: <0616146a-bdf3-4f2f-b4c9-537e07107927@oracle.com> Message-ID: In both files, the imports are messed up. At a minimum, the new imports should be grouped with existing imports from the same package. -- Jon On 7/10/18 4:38 PM, Ivan Gerasimov wrote: > > Thank you Martin! > > > On 7/10/18 2:32 PM, Martin Buchholz wrote: >> I'm happy to see ArrayDeque replacing uses of ArrayList. >> >> private final Map, Deque> >> options2Contexts = new HashMap<>(); >> Looks like these Deques are used only via the Queue interface. I >> would either switch to Queue or to ArrayDeque (which might help the >> VM optimize). > > Right. > I can't remember why I used Deque in one place and Queue in the other. > > Please find the updated webrev here: > http://cr.openjdk.java.net/~igerasim/8206122/01/webrev/ > > With kind regards, > Ivan > >> >> On Tue, Jul 10, 2018 at 1:54 PM, Ivan Gerasimov >> > wrote: >> >> Hello! >> >> It is a tiny optimization. >> >> There are a couple of places where ArrayList is used as FIFO: >> elements are appended to the end, and removed from the head. >> >> ArrayDeque would be more efficient to use. >> >> Would you please help review? >> >> BUG: https://bugs.openjdk.java.net/browse/JDK-8206122 >> >> >> Webrev: http://cr.openjdk.java.net/~igerasim/8206122/00/webrev/ >> >> >> Thanks in advance! >> >> -- >> With kind regards, >> Ivan Gerasimov >> >> > > -- > With kind regards, > Ivan Gerasimov -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Tue Jul 10 23:46:53 2018 From: martinrb at google.com (Martin Buchholz) Date: Tue, 10 Jul 2018 16:46:53 -0700 Subject: [12] (S) RFR 8206122 : Use Queue in place of ArrayList when need to remove first element In-Reply-To: <0616146a-bdf3-4f2f-b4c9-537e07107927@oracle.com> References: <0616146a-bdf3-4f2f-b4c9-537e07107927@oracle.com> Message-ID: Looks good to me, but I'm not a compiler engineer. On Tue, Jul 10, 2018 at 4:38 PM, Ivan Gerasimov wrote: > Thank you Martin! > > On 7/10/18 2:32 PM, Martin Buchholz wrote: > > I'm happy to see ArrayDeque replacing uses of ArrayList. > > private final Map, Deque> options2Contexts = new HashMap<>(); > > Looks like these Deques are used only via the Queue interface. I would > either switch to Queue or to ArrayDeque (which might help the VM optimize). > > > Right. > I can't remember why I used Deque in one place and Queue in the other. > > Please find the updated webrev here: > http://cr.openjdk.java.net/~igerasim/8206122/01/webrev/ > > With kind regards, > Ivan > > > On Tue, Jul 10, 2018 at 1:54 PM, Ivan Gerasimov > wrote: > >> Hello! >> >> It is a tiny optimization. >> >> There are a couple of places where ArrayList is used as FIFO: elements >> are appended to the end, and removed from the head. >> >> ArrayDeque would be more efficient to use. >> >> Would you please help review? >> >> BUG: https://bugs.openjdk.java.net/browse/JDK-8206122 >> >> Webrev: http://cr.openjdk.java.net/~igerasim/8206122/00/webrev/ >> >> Thanks in advance! >> >> -- >> With kind regards, >> Ivan Gerasimov >> >> > > -- > With kind regards, > Ivan Gerasimov > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Wed Jul 11 00:44:39 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 10 Jul 2018 17:44:39 -0700 Subject: RFR: JDK-8198945: Invalid RuntimeVisibleTypeAnnotations for annotation on anonymous class type parameter In-Reply-To: References: <5B36C325.7080605@oracle.com> Message-ID: On Fri, Jul 6, 2018 at 7:24 PM Werner Dietl wrote: > Does this sound good to you? > Yes, I agree with your summary. Thanks for the corrections and clarifications. In particular I agree that speaking of 'duplicating' annotations is incorrect, 'propagating' seems to be a better word. Parts of the annotation structures are copied when propagating annotations from the anonymous class supertype to the new expression (e.g. the element value pair structure), but not the target_type or type_path. I updated the fix to only propagate annotations from the top-level supertype. For example, given `new @A Outer. @B Inner<@C Object>() {}` we propagate only `@B`. When the annotations are propagated an appropriate location is generated with one or more INNER_TYPE entries to place the annotation on the anonymous' class synthetic declaration type. Here's the latest webrev: http://cr.openjdk.java.net/~cushon/8198945/webrev.03/ While continuing to investigate this I think I discovered a couple of related bugs: * https://bugs.openjdk.java.net/browse/JDK-8207017 * https://bugs.openjdk.java.net/browse/JDK-8207018 I can continue to iterate on the fix to try to fix those issues as well, but they might be distinct enough to be worth dealing with separately. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Wed Jul 11 00:49:16 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 10 Jul 2018 17:49:16 -0700 Subject: [12] (S) RFR 8206122 : Use Queue in place of ArrayList when need to remove first element In-Reply-To: References: <0616146a-bdf3-4f2f-b4c9-537e07107927@oracle.com> Message-ID: <5d63c456-3807-3829-cf09-02da3ac8262f@oracle.com> Thank you Jon! On 7/10/18 4:43 PM, Jonathan Gibbons wrote: > > In both files, the imports are messed up. > Okay, I can fix it while we're here. Please find the webrev updated in-place: http://cr.openjdk.java.net/~igerasim/8206122/01/webrev/ With kind regards, Ivan > At a minimum, the new imports should be grouped with existing imports > from the same package. > > -- Jon > > > On 7/10/18 4:38 PM, Ivan Gerasimov wrote: >> >> Thank you Martin! >> >> >> On 7/10/18 2:32 PM, Martin Buchholz wrote: >>> I'm happy to see ArrayDeque replacing uses of ArrayList. >>> >>> private final Map, Deque> >>> options2Contexts = new HashMap<>(); >>> Looks like these Deques are used only via the Queue interface. I >>> would either switch to Queue or to ArrayDeque (which might help the >>> VM optimize). >> >> Right. >> I can't remember why I used Deque in one place and Queue in the other. >> >> Please find the updated webrev here: >> http://cr.openjdk.java.net/~igerasim/8206122/01/webrev/ >> >> With kind regards, >> Ivan >> >>> >>> On Tue, Jul 10, 2018 at 1:54 PM, Ivan Gerasimov >>> > wrote: >>> >>> Hello! >>> >>> It is a tiny optimization. >>> >>> There are a couple of places where ArrayList is used as FIFO: >>> elements are appended to the end, and removed from the head. >>> >>> ArrayDeque would be more efficient to use. >>> >>> Would you please help review? >>> >>> BUG: https://bugs.openjdk.java.net/browse/JDK-8206122 >>> >>> >>> Webrev: http://cr.openjdk.java.net/~igerasim/8206122/00/webrev/ >>> >>> >>> Thanks in advance! >>> >>> -- >>> With kind regards, >>> Ivan Gerasimov >>> >>> >> >> -- >> With kind regards, >> Ivan Gerasimov > -- With kind regards, Ivan Gerasimov -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Wed Jul 11 13:21:23 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 11 Jul 2018 09:21:23 -0400 Subject: [12] (S) RFR 8206122 : Use Queue in place of ArrayList when need to remove first element In-Reply-To: <5d63c456-3807-3829-cf09-02da3ac8262f@oracle.com> References: <0616146a-bdf3-4f2f-b4c9-537e07107927@oracle.com> <5d63c456-3807-3829-cf09-02da3ac8262f@oracle.com> Message-ID: <51e95cd8-8481-c707-872b-75d8f7dc10b7@oracle.com> looks good, Vicente On 07/10/2018 08:49 PM, Ivan Gerasimov wrote: > > Thank you Jon! > > > On 7/10/18 4:43 PM, Jonathan Gibbons wrote: >> >> In both files, the imports are messed up. >> > Okay, I can fix it while we're here. > > Please find the webrev updated in-place: > http://cr.openjdk.java.net/~igerasim/8206122/01/webrev/ > > With kind regards, > Ivan > >> At a minimum, the new imports should be grouped with existing imports >> from the same package. >> >> -- Jon >> >> >> On 7/10/18 4:38 PM, Ivan Gerasimov wrote: >>> >>> Thank you Martin! >>> >>> >>> On 7/10/18 2:32 PM, Martin Buchholz wrote: >>>> I'm happy to see ArrayDeque replacing uses of ArrayList. >>>> >>>> private final Map, Deque> >>>> options2Contexts = new HashMap<>(); >>>> Looks like these Deques are used only via the Queue interface. I >>>> would either switch to Queue or to ArrayDeque (which might help the >>>> VM optimize). >>> >>> Right. >>> I can't remember why I used Deque in one place and Queue in the other. >>> >>> Please find the updated webrev here: >>> http://cr.openjdk.java.net/~igerasim/8206122/01/webrev/ >>> >>> With kind regards, >>> Ivan >>> >>>> >>>> On Tue, Jul 10, 2018 at 1:54 PM, Ivan Gerasimov >>>> > wrote: >>>> >>>> Hello! >>>> >>>> It is a tiny optimization. >>>> >>>> There are a couple of places where ArrayList is used as FIFO: >>>> elements are appended to the end, and removed from the head. >>>> >>>> ArrayDeque would be more efficient to use. >>>> >>>> Would you please help review? >>>> >>>> BUG: https://bugs.openjdk.java.net/browse/JDK-8206122 >>>> >>>> >>>> Webrev: http://cr.openjdk.java.net/~igerasim/8206122/00/webrev/ >>>> >>>> >>>> Thanks in advance! >>>> >>>> -- >>>> With kind regards, >>>> Ivan Gerasimov >>>> >>>> >>> >>> -- >>> With kind regards, >>> Ivan Gerasimov >> > > -- > With kind regards, > Ivan Gerasimov -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Wed Jul 11 14:09:56 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 11 Jul 2018 10:09:56 -0400 Subject: JDK 12 RFR of JDK-8173606: Deprecate constructors of 7-era visitors In-Reply-To: <80cb5d6f-5428-7667-8b24-5138cd4ea2d3@oracle.com> References: <80cb5d6f-5428-7667-8b24-5138cd4ea2d3@oracle.com> Message-ID: <3c77ef86-0788-9572-88bd-465f2bb66b62@oracle.com> both looks good, Vicente On 07/08/2018 04:32 PM, joe darcy wrote: > Hello, > > Please review the changeset > > ??? JDK-8173606: Deprecate constructors of 7-era visitors > ??? http://cr.openjdk.java.net/~darcy/8173606.0/ > > and corresponding CSR > > ??? ??? https://bugs.openjdk.java.net/browse/JDK-8206878 > > The changeset follows the pattern previously established for > deprecating the JDK 6-era visitors in the same release as > -source/-target 6 was made obsolete. > > Thanks, > > -Joe > From joe.darcy at oracle.com Wed Jul 11 18:18:23 2018 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 11 Jul 2018 11:18:23 -0700 Subject: JDK 12 RFR of JDK-8207055 : Make javac -help output for -source and -target more informative Message-ID: Hello, Please review the changes to implement ??? JDK-8207055 : Make javac -help output for -source and -target more informative ??? http://cr.openjdk.java.net/~darcy/8207055.1/ Basically the -help output for -source and -target is augmented to include a concatenation of the supported values for those options. It would be possible to write the concatenation in a more stream-y manner, but I think the loops are sufficient. Thanks, -Joe From jonathan.gibbons at oracle.com Wed Jul 11 21:18:35 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 11 Jul 2018 14:18:35 -0700 Subject: JDK 12 RFR of JDK-8207055 : Make javac -help output for -source and -target more informative In-Reply-To: References: Message-ID: <5B46742B.2070202@oracle.com> On 07/11/2018 11:18 AM, joe darcy wrote: > Hello, > > Please review the changes to implement > > JDK-8207055 : Make javac -help output for -source and -target more > informative > http://cr.openjdk.java.net/~darcy/8207055.1/ > > Basically the -help output for -source and -target is augmented to > include a concatenation of the supported values for those options. It > would be possible to write the concatenation in a more stream-y > manner, but I think the loops are sufficient. > > Thanks, > > -Joe > Joe, OK, but ... While not without precedent[1], the use of the string ", " to create a string for a list is not correct in all locales. Perhaps separately, we should create and use a utility method to convert a list to a string. -- Jon 1: src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacElements.java: .collect(Collectors.joining(", ")); src/jdk.compiler/share/classes/com/sun/tools/javac/code/Scope.java: if (e != s.elems) result.append(", "); src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java: if (!first) s.append(", "); src/jdk.compiler/share/classes/com/sun/tools/javac/code/Attribute.java: if (!first) buf.append(", "); src/jdk.compiler/share/classes/com/sun/tools/javac/code/Attribute.java: buf.append(", "); src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java: printExprs(trees, ", "); src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java: print(", "); src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java: print(", " + vdef.name); src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java: delim = ", "; src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java: .collect(Collectors.joining(", ")); src/jdk.compiler/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java: sep = ", "; src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/JNIWriter.java~: out.print(", "); src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/JNIWriter.java: out.print(", "); src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java: collect(Collectors.joining(", "))); src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java: writer.print(", "); src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java: writer.println(", "); src/jdk.compiler/share/classes/jdk/internal/shellsupport/doc/JavadocHelper.java: sep = ", "; From joe.darcy at oracle.com Wed Jul 11 22:30:03 2018 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 11 Jul 2018 15:30:03 -0700 Subject: JDK 12 RFR of JDK-8207055 : Make javac -help output for -source and -target more informative In-Reply-To: <5B46742B.2070202@oracle.com> References: <5B46742B.2070202@oracle.com> Message-ID: Hi Jon, On 7/11/2018 2:18 PM, Jonathan Gibbons wrote: > > > On 07/11/2018 11:18 AM, joe darcy wrote: >> Hello, >> >> Please review the changes to implement >> >> ??? JDK-8207055 : Make javac -help output for -source and -target >> more informative >> ??? http://cr.openjdk.java.net/~darcy/8207055.1/ >> >> Basically the -help output for -source and -target is augmented to >> include a concatenation of the supported values for those options. It >> would be possible to write the concatenation in a more stream-y >> manner, but I think the loops are sufficient. >> >> Thanks, >> >> -Joe >> > > Joe, > > OK, but ... > > While not without precedent[1], the use of the string ", " to create a > string for a list is not correct in all locales. > > Perhaps separately, we should create and use a utility method to > convert a list to a string. > > - Thanks for the review; adding a localized list-ifier javac utility method sounds like a good refactoring. Cheers, -Joe From wdietl at gmail.com Thu Jul 12 02:28:37 2018 From: wdietl at gmail.com (Werner Dietl) Date: Wed, 11 Jul 2018 22:28:37 -0400 Subject: RFR: JDK-8198945: Invalid RuntimeVisibleTypeAnnotations for annotation on anonymous class type parameter In-Reply-To: References: <5B36C325.7080605@oracle.com> Message-ID: The webrev looks good to me (note that I'm not a reviewer). Maybe `copyNewClassAnnotationsToOwner` should now be renamed to `propagateNewClassAnnotationsToOwner` or something else that's more descriptive. I like the test set. Maybe instead of having so many static methods I would instantiate AnonymousClassTest in main. JDK-8207018 seems very related to the current issue, so it would seem worth-while to fix it at the same time. I added a comment there. On the other hand JDK-8207017 seems sufficiently different to require a separate fix. Best, cu, WMD. On Tue, Jul 10, 2018 at 8:44 PM Liam Miller-Cushon wrote: > > On Fri, Jul 6, 2018 at 7:24 PM Werner Dietl wrote: >> >> Does this sound good to you? > > > Yes, I agree with your summary. Thanks for the corrections and clarifications. > > In particular I agree that speaking of 'duplicating' annotations is incorrect, 'propagating' seems to be a better word. Parts of the annotation structures are copied when propagating annotations from the anonymous class supertype to the new expression (e.g. the element value pair structure), but not the target_type or type_path. > > I updated the fix to only propagate annotations from the top-level supertype. For example, given `new @A Outer. @B Inner<@C Object>() {}` we propagate only `@B`. When the annotations are propagated an appropriate location is generated with one or more INNER_TYPE entries to place the annotation on the anonymous' class synthetic declaration type. > > Here's the latest webrev: http://cr.openjdk.java.net/~cushon/8198945/webrev.03/ > > While continuing to investigate this I think I discovered a couple of related bugs: > * https://bugs.openjdk.java.net/browse/JDK-8207017 > * https://bugs.openjdk.java.net/browse/JDK-8207018 > > I can continue to iterate on the fix to try to fix those issues as well, but they might be distinct enough to be worth dealing with separately. -- http://www.google.com/profiles/wdietl From jan.lahoda at oracle.com Thu Jul 12 14:04:15 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 12 Jul 2018 16:04:15 +0200 Subject: RFR(11): JDK-8207032: Compilation succeeds without checking readability when --add-exports used Message-ID: <5B475FDF.6000509@oracle.com> Hi, Currently, when --add-exports is used, javac will inject the exported packages into the target module's visible packages even if the target module is not reading the source module. So that even if the target module does not read the source module, it can use the packages exported using --add-exports, which is not intended. The fix is to check readability before adding the packages into the list of visible packages. Bug: https://bugs.openjdk.java.net/browse/JDK-8207032 Webrev: http://cr.openjdk.java.net/~jlahoda/8207032/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8207175 Thanks, Jan From vicente.romero at oracle.com Thu Jul 12 14:53:56 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 12 Jul 2018 10:53:56 -0400 Subject: RFR(11): JDK-8207032: Compilation succeeds without checking readability when --add-exports used In-Reply-To: <5B475FDF.6000509@oracle.com> References: <5B475FDF.6000509@oracle.com> Message-ID: both looks good, I made some minimal format changes to the CSR, Vicente On 07/12/2018 10:04 AM, Jan Lahoda wrote: > Hi, > > Currently, when --add-exports is used, javac will inject the exported > packages into the target module's visible packages even if the target > module is not reading the source module. So that even if the target > module does not read the source module, it can use the packages > exported using --add-exports, which is not intended. The fix is to > check readability before adding the packages into the list of visible > packages. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8207032 > Webrev: http://cr.openjdk.java.net/~jlahoda/8207032/webrev.00/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8207175 > > Thanks, > ??? Jan From alex.buckley at oracle.com Thu Jul 12 18:24:01 2018 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 12 Jul 2018 11:24:01 -0700 Subject: RFR(11): JDK-8207032: Compilation succeeds without checking readability when --add-exports used In-Reply-To: References: <5B475FDF.6000509@oracle.com> Message-ID: <5B479CC1.6010502@oracle.com> I also thought the CSR was good. I modified the clause about passing `--add-reads mb=ma`, because adding `requires ma;` to mb is also a valid choice. The release note talks of "source module" and "target module". While it's possible to figure out which is which, it's rather tricky for a compiler release note to use "source module" to mean something other than "the source code of a module, not its class files". I have taken the liberty of changing "source module" to "exporting module" in the release note. (No need to mention a `requires` directive in this short, command-line release note.) Alex On 7/12/2018 7:53 AM, Vicente Romero wrote: > both looks good, I made some minimal format changes to the CSR, > > Vicente > > On 07/12/2018 10:04 AM, Jan Lahoda wrote: >> Hi, >> >> Currently, when --add-exports is used, javac will inject the exported >> packages into the target module's visible packages even if the target >> module is not reading the source module. So that even if the target >> module does not read the source module, it can use the packages >> exported using --add-exports, which is not intended. The fix is to >> check readability before adding the packages into the list of visible >> packages. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8207032 >> Webrev: http://cr.openjdk.java.net/~jlahoda/8207032/webrev.00/ >> CSR: https://bugs.openjdk.java.net/browse/JDK-8207175 >> >> Thanks, >> Jan > From jonathan.gibbons at oracle.com Thu Jul 12 22:31:59 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 12 Jul 2018 15:31:59 -0700 Subject: RFR(11): JDK-8207032: Compilation succeeds without checking readability when --add-exports used In-Reply-To: <5B475FDF.6000509@oracle.com> References: <5B475FDF.6000509@oracle.com> Message-ID: <5B47D6DF.80708@oracle.com> +1 -- Jon On 07/12/2018 07:04 AM, Jan Lahoda wrote: > Hi, > > Currently, when --add-exports is used, javac will inject the exported > packages into the target module's visible packages even if the target > module is not reading the source module. So that even if the target > module does not read the source module, it can use the packages > exported using --add-exports, which is not intended. The fix is to > check readability before adding the packages into the list of visible > packages. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8207032 > Webrev: http://cr.openjdk.java.net/~jlahoda/8207032/webrev.00/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8207175 > > Thanks, > Jan From jan.lahoda at oracle.com Fri Jul 13 08:15:04 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 13 Jul 2018 10:15:04 +0200 Subject: RFR(11): JDK-8189747: JDK9 javax.lang.model.util.Elements#getTypeElement regressed 1000x in performance. Message-ID: <5B485F88.1000201@oracle.com> Hi, Since the addition of modules, the Elements.getTypeElement(CharSequence) and Elements.getPackageElement(CharSequence) methods need to look into all modules when looking for Type/Package Elements. This may make these methods significantly slower than before. Sadly, I am sure if it is possible to make the methods as fast as before, while still looking into all modules. A possible solution for cases where the API clients look repeatedly for the same type/package may be to introduce a cache for the results. That is the proposed patch here. An alternative for the clients is to use the variants of the methods that accept ModuleElement as the base for the search. Bug: https://bugs.openjdk.java.net/browse/JDK-8189747 Webrev: http://cr.openjdk.java.net/~jlahoda/8189747/webrev.00/ Thanks, Jan From jan.lahoda at oracle.com Fri Jul 13 15:09:47 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 13 Jul 2018 17:09:47 +0200 Subject: RFR(11): JDK-8207032: Compilation succeeds without checking readability when --add-exports used In-Reply-To: <5B479CC1.6010502@oracle.com> References: <5B475FDF.6000509@oracle.com> <5B479CC1.6010502@oracle.com> Message-ID: <5B48C0BB.5020506@oracle.com> Thanks to all for improving the CSR and the release note! Jan On 12.7.2018 20:24, Alex Buckley wrote: > I also thought the CSR was good. I modified the clause about passing > `--add-reads mb=ma`, because adding `requires ma;` to mb is also a valid > choice. > > The release note talks of "source module" and "target module". While > it's possible to figure out which is which, it's rather tricky for a > compiler release note to use "source module" to mean something other > than "the source code of a module, not its class files". I have taken > the liberty of changing "source module" to "exporting module" in the > release note. (No need to mention a `requires` directive in this short, > command-line release note.) > > Alex > > On 7/12/2018 7:53 AM, Vicente Romero wrote: >> both looks good, I made some minimal format changes to the CSR, >> >> Vicente >> >> On 07/12/2018 10:04 AM, Jan Lahoda wrote: >>> Hi, >>> >>> Currently, when --add-exports is used, javac will inject the exported >>> packages into the target module's visible packages even if the target >>> module is not reading the source module. So that even if the target >>> module does not read the source module, it can use the packages >>> exported using --add-exports, which is not intended. The fix is to >>> check readability before adding the packages into the list of visible >>> packages. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8207032 >>> Webrev: http://cr.openjdk.java.net/~jlahoda/8207032/webrev.00/ >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8207175 >>> >>> Thanks, >>> Jan >> From joe.darcy at oracle.com Fri Jul 13 16:35:39 2018 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 13 Jul 2018 09:35:39 -0700 Subject: RFR(11): JDK-8189747: JDK9 javax.lang.model.util.Elements#getTypeElement regressed 1000x in performance. In-Reply-To: <5B485F88.1000201@oracle.com> References: <5B485F88.1000201@oracle.com> Message-ID: <83d62022-6ee0-b49a-7401-37c9c442a75f@oracle.com> Hi Jan, Looks fine; thanks, -Joe On 7/13/2018 1:15 AM, Jan Lahoda wrote: > Hi, > > Since the addition of modules, the > Elements.getTypeElement(CharSequence) and > Elements.getPackageElement(CharSequence) methods need to look into all > modules when looking for Type/Package Elements. This may make these > methods significantly slower than before. > > Sadly, I am sure if it is possible to make the methods as fast as > before, while still looking into all modules. A possible solution for > cases where the API clients look repeatedly for the same type/package > may be to introduce a cache for the results. That is the proposed > patch here. An alternative for the clients is to use the variants of > the methods that accept ModuleElement as the base for the search. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8189747 > Webrev: http://cr.openjdk.java.net/~jlahoda/8189747/webrev.00/ > > Thanks, > ??? Jan From joe.darcy at oracle.com Fri Jul 13 16:43:17 2018 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 13 Jul 2018 09:43:17 -0700 Subject: JDK 12 RFR of JDK-8207247: Reduce incidence of compiler.warn.source.no.bootclasspath in javac tests Message-ID: <8346bf38-b19e-2f18-b613-59398950b6b8@oracle.com> Hello, Please review the changes to address ??? JDK-8207247: Reduce incidence of compiler.warn.source.no.bootclasspath in javac tests ??? http://cr.openjdk.java.net/~darcy/8207248.0/ While working on the changes to prepare for removal of -source/-target/--release 6, some of the test edits that were need were to suppress extraneous warnings about -source/-target 7 being obsolete. To avoid a similar round of extraneous changes when -source/-targer 7 is removed and 8 becomes obsolete, this patch includes -Xlint:-options to remove the options-related warnings. The set of removed warnings includes the identified bootclasspath warning and will also cover future "-source/-target 8 is obsolete" warnings. Thanks, -Joe From jan.lahoda at oracle.com Fri Jul 13 16:43:50 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 13 Jul 2018 18:43:50 +0200 Subject: RFR(12): JDK-8207229: Trees.getScope crashes for broken lambda; JDK-8207230: Trees.getScope runs Analyzers Message-ID: <5B48D6C6.9090805@oracle.com> Hi, The proposed patch attempts to fix two problems with Trees.getScope: -a NPE when a lambda is categorized as an implicit lambda, but has a parameter with type (in erroneous source); when Attr.fallbackDescriptorType constructs the fallback descriptor, it uses the (unattributed) type of the parameter, which then leads to the NPE. The proposal is to check if the type of the parameter is present, and use syms.errType if not present. -Analyzers appear to run while the Scope is being computed by Trees.getScope. This does not seem necessary (as the attribution typically runs on a copy of the AST, not on the real AST). Bugs: https://bugs.openjdk.java.net/browse/JDK-8207229 https://bugs.openjdk.java.net/browse/JDK-8207230 Webrev: http://cr.openjdk.java.net/~jlahoda/8207229/webrev.00/ Does this look reasonable? Thanks, Jan From jonathan.gibbons at oracle.com Fri Jul 13 19:06:00 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 13 Jul 2018 12:06:00 -0700 Subject: javac --release 11 not support by jdk 12 In-Reply-To: <1603767512.929008.1531506708261.JavaMail.zimbra@u-pem.fr> References: <1603767512.929008.1531506708261.JavaMail.zimbra@u-pem.fr> Message-ID: <5B48F818.8080602@oracle.com> Remi, This should go to compiler-dev. It requires an update to make the historical data available for an earlier release. -- Jon On 07/13/2018 11:31 AM, Remi Forax wrote: > There is a weird bug with javac of jdk 12. > > /usr/jdk/jdk-12/bin/javac --release 11 > error: release version 11 not supported > Usage: javac > use --help for a list of possible options > > while javac --release 10 or javac --release 12 works ? > > R?mi > From vicente.romero at oracle.com Fri Jul 13 19:47:31 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 13 Jul 2018 15:47:31 -0400 Subject: RFR(12): JDK-8207229: Trees.getScope crashes for broken lambda; JDK-8207230: Trees.getScope runs Analyzers In-Reply-To: <5B48D6C6.9090805@oracle.com> References: <5B48D6C6.9090805@oracle.com> Message-ID: <7100885e-ebef-98bd-5e0c-469bc864ba1c@oracle.com> looks good, Vicente On 07/13/2018 12:43 PM, Jan Lahoda wrote: > Hi, > > The proposed patch attempts to fix two problems with Trees.getScope: > -a NPE when a lambda is categorized as an implicit lambda, but has a > parameter with type (in erroneous source); when > Attr.fallbackDescriptorType constructs the fallback descriptor, it > uses the (unattributed) type of the parameter, which then leads to the > NPE. The proposal is to check if the type of the parameter is present, > and use syms.errType if not present. > -Analyzers appear to run while the Scope is being computed by > Trees.getScope. This does not seem necessary (as the attribution > typically runs on a copy of the AST, not on the real AST). > > Bugs: > https://bugs.openjdk.java.net/browse/JDK-8207229 > https://bugs.openjdk.java.net/browse/JDK-8207230 > > Webrev: > http://cr.openjdk.java.net/~jlahoda/8207229/webrev.00/ > > Does this look reasonable? > > Thanks, > ??? Jan > From vicente.romero at oracle.com Tue Jul 17 01:23:27 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 16 Jul 2018 21:23:27 -0400 Subject: JDK 12 RFR of JDK-8207247: Reduce incidence of compiler.warn.source.no.bootclasspath in javac tests In-Reply-To: <8346bf38-b19e-2f18-b613-59398950b6b8@oracle.com> References: <8346bf38-b19e-2f18-b613-59398950b6b8@oracle.com> Message-ID: looks good, Vicente On 07/13/2018 12:43 PM, joe darcy wrote: > Hello, > > Please review the changes to address > > ??? JDK-8207247: Reduce incidence of > compiler.warn.source.no.bootclasspath in javac tests > ??? http://cr.openjdk.java.net/~darcy/8207248.0/ > > While working on the changes to prepare for removal of > -source/-target/--release 6, some of the test edits that were need > were to suppress extraneous warnings about -source/-target 7 being > obsolete. To avoid a similar round of extraneous changes when > -source/-targer 7 is removed and 8 becomes obsolete, this patch > includes -Xlint:-options to remove the options-related warnings. The > set of removed warnings includes the identified bootclasspath warning > and will also cover future "-source/-target 8 is obsolete" warnings. > > Thanks, > > -Joe > From jan.lahoda at oracle.com Tue Jul 17 18:00:42 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 17 Jul 2018 20:00:42 +0200 Subject: RFR: JDK-8192963/JDK-8206986 JEP 325: Switch Expressions (Preview) Message-ID: <5B4E2ECA.5070805@oracle.com> Hi, As JEP 325 is in the proposed to target state, I thought it might be a good idea to start a review process for the code. The code here strives to implement the current specification for the Switch Expressions: http://cr.openjdk.java.net/~gbierman/switch-expressions.html The current webrev is here: http://cr.openjdk.java.net/~jlahoda/8192963/webrev.00/ (includes a list of new errors.) JBS: https://bugs.openjdk.java.net/browse/JDK-8192963 https://bugs.openjdk.java.net/browse/JDK-8206986 CSRs: https://bugs.openjdk.java.net/browse/JDK-8207241 https://bugs.openjdk.java.net/browse/JDK-8207406 Any feedback is welcome! Thanks, Jan From vicente.romero at oracle.com Wed Jul 18 17:59:43 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 18 Jul 2018 13:59:43 -0400 Subject: RFR: JDK-8192963/JDK-8206986 JEP 325: Switch Expressions (Preview) In-Reply-To: <5B4E2ECA.5070805@oracle.com> References: <5B4E2ECA.5070805@oracle.com> Message-ID: <6b2f5de2-2373-63da-9032-16f2db67ebf9@oracle.com> pretty nice work, some notes below: - SwitchExpressionTree.java is a new file so the copyright should say 2018 only plus you should remove some @author comments, probably taken from SwitchTree. - Attr, it is a bit weird seeing, the method below receiving a tree instead of an expression, consider renaming it to attribTree ??????? public Type attribExpr(JCTree tree, Env env, ResultInfo resultInfo) - also in Attr, isn't: @Override public void visitMethodDef(JCMethodDecl tree) {} at the TreeScanner anonymous class created at visitSwitchExpression redundant? - at Lower, minor, inside method: convertCase, is it necessary to always create a block inside visitBreak? overall great job! Vicente On 07/17/2018 02:00 PM, Jan Lahoda wrote: > Hi, > > As JEP 325 is in the proposed to target state, I thought it might be a > good idea to start a review process for the code. > > The code here strives to implement the current specification for the > Switch Expressions: > http://cr.openjdk.java.net/~gbierman/switch-expressions.html > > The current webrev is here: > http://cr.openjdk.java.net/~jlahoda/8192963/webrev.00/ > > (includes a list of new errors.) > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8192963 > https://bugs.openjdk.java.net/browse/JDK-8206986 > > CSRs: > https://bugs.openjdk.java.net/browse/JDK-8207241 > https://bugs.openjdk.java.net/browse/JDK-8207406 > > Any feedback is welcome! > > Thanks, > ??? Jan From wdietl at gmail.com Wed Jul 18 23:49:55 2018 From: wdietl at gmail.com (Werner Dietl) Date: Wed, 18 Jul 2018 19:49:55 -0400 Subject: Type annotations on inner type that is an array components Message-ID: Take this example: import java.lang.annotation.ElementType; import java.lang.annotation.Retention; import java.lang.annotation.RetentionPolicy; import java.lang.annotation.Target; @Retention(RetentionPolicy.RUNTIME) @Target({ElementType.TYPE_USE, ElementType.TYPE_PARAMETER}) @interface TA { int value(); } class ArrayOfInner { class Inner {} @TA(1) ArrayOfInner. @TA(2) Inner oi; @TA(3) ArrayOfInner. @TA(4) Inner [] oia; @TA(5) Inner i; @TA(6) Inner [] ia; } Compile with javac 8 and according to javap -v field ia has the annotation: ArrayOfInner$Inner[] ia; descriptor: [LArrayOfInner$Inner; flags: (0x0000) RuntimeVisibleTypeAnnotations: 0: #10(#11=I#21): FIELD, location=[ARRAY, INNER_TYPE] TA( value=6 ) Compile with javac 9, 10, or a recent 11 build and ia has the annotation: ArrayOfInner$Inner[] ia; descriptor: [LArrayOfInner$Inner; flags: (0x0000) RuntimeVisibleTypeAnnotations: 0: #10(#11=I#21): FIELD, location=[ARRAY] TA( value=6 ) Note the missing INNER_TYPE location. The annotations for fields oi, oia, and i are generated consistently for all versions and are just included to illustrate all the relevant annotation positions. I would like to argue that the Java 8 behavior was correct. I didn't find an existing issue that either motivated this change or that would report this mismatch. Thoughts? cu, WMD. -- http://www.google.com/profiles/wdietl From joe.darcy at oracle.com Thu Jul 19 16:32:07 2018 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 19 Jul 2018 09:32:07 -0700 Subject: FYI, JSR 269 MR for Java SE 11 started Message-ID: Hello, FYI, a maintenance review for the few changes in the JSR 269 API in Java SE 11 has started: https://jcp.org/aboutJava/communityprocess/maintenance/jsr269/index5.html Cheers, -Joe From vicente.romero at oracle.com Thu Jul 19 16:35:50 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 19 Jul 2018 12:35:50 -0400 Subject: RFR: JDK-8205493: OptionSmokeTest.java uses hard-coded release values Message-ID: <927c945c-cf6f-1b7b-d678-4b2a3e80d8dc@oracle.com> Hi all, Please review the patch to fix [1] at [2]. The fix is basically removing the use of hard-coded source/release values from the test making it easier to maintain in the future, Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8205493 [2] http://cr.openjdk.java.net/~vromero/8205493/webrev.00/jdk.dev.patch From bsrbnd at gmail.com Thu Jul 19 16:49:46 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Thu, 19 Jul 2018 18:49:46 +0200 Subject: RFR: JDK-8192963/JDK-8206986 JEP 325: Switch Expressions (Preview) In-Reply-To: <5B4E2ECA.5070805@oracle.com> References: <5B4E2ECA.5070805@oracle.com> Message-ID: Hi Jan, On 17 July 2018 at 20:00, Jan Lahoda wrote: > Hi, > > As JEP 325 is in the proposed to target state, I thought it might be a good > idea to start a review process for the code. > > The code here strives to implement the current specification for the Switch > Expressions: > http://cr.openjdk.java.net/~gbierman/switch-expressions.html > > The current webrev is here: > http://cr.openjdk.java.net/~jlahoda/8192963/webrev.00/ Going back to thread [1], I'd like to suggest some cosmetic changes to 'LetExpr': * 'LetExpr.defs' could be renamed to 'LetExpr.stmts' * 'LetExpr' could be renamed to 'BlockExpr' * 'Pretty' could print '(exec ... eval ...)' instead of '(let ... in ...)' I also note that [2] could be finally addressed but probably separately. Cheers, Bernard [1] http://mail.openjdk.java.net/pipermail/compiler-dev/2017-May/010954.html [2] https://bugs.openjdk.java.net/browse/JDK-8183548 > (includes a list of new errors.) > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8192963 > https://bugs.openjdk.java.net/browse/JDK-8206986 > > CSRs: > https://bugs.openjdk.java.net/browse/JDK-8207241 > https://bugs.openjdk.java.net/browse/JDK-8207406 > > Any feedback is welcome! > > Thanks, > Jan From vicente.romero at oracle.com Thu Jul 19 17:27:41 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 19 Jul 2018 13:27:41 -0400 Subject: RFR: JDK-8206874: Evaluate LoadClassFromJava6CreatedJarTest.java after dropping -source 6 Message-ID: <0b44d97a-cd83-cf37-c88e-34605b847e96@oracle.com> Hi all, Please review the patch to fix [1] at [2]. The fix is basically removing the test as it is not useful anymore, Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8206874 [2] http://cr.openjdk.java.net/~vromero/8206874/webrev.00/jdk.dev.patch From alex.buckley at oracle.com Thu Jul 19 19:23:12 2018 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 19 Jul 2018 12:23:12 -0700 Subject: Type annotations on inner type that is an array components In-Reply-To: References: Message-ID: <5B50E520.90504@oracle.com> Hi Werner, On 7/18/2018 4:49 PM, Werner Dietl wrote: > class ArrayOfInner { > class Inner {} > > @TA(1) ArrayOfInner. @TA(2) Inner oi; > @TA(3) ArrayOfInner. @TA(4) Inner [] oia; > @TA(5) Inner i; > @TA(6) Inner [] ia; > } > > > Compile with javac 8 and according to javap -v field ia has the annotation: > > ArrayOfInner$Inner[] ia; > descriptor: [LArrayOfInner$Inner; > flags: (0x0000) > RuntimeVisibleTypeAnnotations: > 0: #10(#11=I#21): FIELD, location=[ARRAY, INNER_TYPE] > > Compile with javac 9, 10, or a recent 11 build and ia has the annotation: > > ArrayOfInner$Inner[] ia; > descriptor: [LArrayOfInner$Inner; > flags: (0x0000) > RuntimeVisibleTypeAnnotations: > 0: #10(#11=I#21): FIELD, location=[ARRAY] > > Note the missing INNER_TYPE location. > > I would like to argue that the Java 8 behavior was correct. Sounds right. Given source code that denotes the array type "Inner[]", the question is whether the component type of that array type is a nested type (ArrayOfInner.Inner) or not (just Inner). Logically, yes, it's a nested type, so the target_path item deserves an INNER_TYPE entry. This feels like the kind of detail we've been round and round on in the past. That said, I don't see any mails that would have led to javac changing how it emits target_path between 8 and 9. The closest suspect is a compiler-dev thread from Jan/Feb 2016 -- "Bug in encoding type annotations for supertype_targets" -- which spoke about the target_path being omitted entirely for an annotated nested type. (JDK-8148504 was filed against 8, but it's still open, so it can't have caused any collateral damage for a field type's annotation.) Alex From jan.lahoda at oracle.com Thu Jul 19 19:39:05 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 19 Jul 2018 21:39:05 +0200 Subject: RFR: JDK-8192963/JDK-8206986 JEP 325: Switch Expressions (Preview) In-Reply-To: <6b2f5de2-2373-63da-9032-16f2db67ebf9@oracle.com> References: <5B4E2ECA.5070805@oracle.com> <6b2f5de2-2373-63da-9032-16f2db67ebf9@oracle.com> Message-ID: <5B50E8D9.7070005@oracle.com> Hi Vicente, Thanks for the comments. An updated webrev is here: http://cr.openjdk.java.net/~jlahoda/8192963/webrev.01/ Comments inline. On 18.7.2018 19:59, Vicente Romero wrote: > pretty nice work, some notes below: > > - SwitchExpressionTree.java is a new file so the copyright should say > 2018 only plus you should remove some @author comments, probably taken > from SwitchTree. Done. > - Attr, it is a bit weird seeing, the method below receiving a tree > instead of an expression, consider renaming it to attribTree > public Type attribExpr(JCTree tree, Env env, > ResultInfo resultInfo) Turned out this new overload is not needed anymore, I've remove it. > - also in Attr, isn't: @Override public void visitMethodDef(JCMethodDecl > tree) {} at the TreeScanner anonymous class created at > visitSwitchExpression redundant? Yes, that's not really necessary, removed. > - at Lower, minor, inside method: convertCase, is it necessary to always > create a block inside visitBreak? Here, a single statement (value break) is replaced with two statements (an assignment and a break). If the original value break would be inside a block, then we could replace it with the statements inside the enclosing block. But we would still need to replace the value break with a block sometimes (if the value break would not be enclosed by a block), and using the block always shouldn't hurt much, so I opted for the current simpler state. Jan > > overall great job! > Vicente > > On 07/17/2018 02:00 PM, Jan Lahoda wrote: >> Hi, >> >> As JEP 325 is in the proposed to target state, I thought it might be a >> good idea to start a review process for the code. >> >> The code here strives to implement the current specification for the >> Switch Expressions: >> http://cr.openjdk.java.net/~gbierman/switch-expressions.html >> >> The current webrev is here: >> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.00/ >> >> (includes a list of new errors.) >> >> JBS: >> https://bugs.openjdk.java.net/browse/JDK-8192963 >> https://bugs.openjdk.java.net/browse/JDK-8206986 >> >> CSRs: >> https://bugs.openjdk.java.net/browse/JDK-8207241 >> https://bugs.openjdk.java.net/browse/JDK-8207406 >> >> Any feedback is welcome! >> >> Thanks, >> Jan > From jan.lahoda at oracle.com Thu Jul 19 19:41:05 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 19 Jul 2018 21:41:05 +0200 Subject: RFR: JDK-8192963/JDK-8206986 JEP 325: Switch Expressions (Preview) In-Reply-To: References: <5B4E2ECA.5070805@oracle.com> Message-ID: <5B50E951.6000807@oracle.com> Hi Bernard, On 19.7.2018 18:49, B. Blaser wrote: > Hi Jan, > > On 17 July 2018 at 20:00, Jan Lahoda wrote: >> Hi, >> >> As JEP 325 is in the proposed to target state, I thought it might be a good >> idea to start a review process for the code. >> >> The code here strives to implement the current specification for the Switch >> Expressions: >> http://cr.openjdk.java.net/~gbierman/switch-expressions.html >> >> The current webrev is here: >> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.00/ > > Going back to thread [1], I'd like to suggest some cosmetic changes to > 'LetExpr': > * 'LetExpr.defs' could be renamed to 'LetExpr.stmts' > * 'LetExpr' could be renamed to 'BlockExpr' > * 'Pretty' could print '(exec ... eval ...)' instead of '(let ... in ...)' Good points. On the other hand, I am not sure if it is good to complicate this patch (esp. with a rename to BlockExpr). Maybe we could work on the LetExpr improvements and then rebase the switch expressions patch on that? Thanks, Jan > > I also note that [2] could be finally addressed but probably separately. > > Cheers, > Bernard > > [1] http://mail.openjdk.java.net/pipermail/compiler-dev/2017-May/010954.html > [2] https://bugs.openjdk.java.net/browse/JDK-8183548 > > >> (includes a list of new errors.) >> >> JBS: >> https://bugs.openjdk.java.net/browse/JDK-8192963 >> https://bugs.openjdk.java.net/browse/JDK-8206986 >> >> CSRs: >> https://bugs.openjdk.java.net/browse/JDK-8207241 >> https://bugs.openjdk.java.net/browse/JDK-8207406 >> >> Any feedback is welcome! >> >> Thanks, >> Jan From vicente.romero at oracle.com Thu Jul 19 20:04:07 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 19 Jul 2018 16:04:07 -0400 Subject: RFR: JDK-8192963/JDK-8206986 JEP 325: Switch Expressions (Preview) In-Reply-To: <5B50E8D9.7070005@oracle.com> References: <5B4E2ECA.5070805@oracle.com> <6b2f5de2-2373-63da-9032-16f2db67ebf9@oracle.com> <5B50E8D9.7070005@oracle.com> Message-ID: <9cf5c481-b878-725e-0a73-6d57b27af86e@oracle.com> I don't have any further comments. It would be interesting to do a code coverage test, Thanks, Vicente On 07/19/2018 03:39 PM, Jan Lahoda wrote: > Hi Vicente, > > Thanks for the comments. An updated webrev is here: > http://cr.openjdk.java.net/~jlahoda/8192963/webrev.01/ > > Comments inline. > > On 18.7.2018 19:59, Vicente Romero wrote: >> pretty nice work, some notes below: >> >> - SwitchExpressionTree.java is a new file so the copyright should say >> 2018 only plus you should remove some @author comments, probably taken >> from SwitchTree. > > Done. > >> - Attr, it is a bit weird seeing, the method below receiving a tree >> instead of an expression, consider renaming it to attribTree >> ???????? public Type attribExpr(JCTree tree, Env env, >> ResultInfo resultInfo) > > Turned out this new overload is not needed anymore, I've remove it. > >> - also in Attr, isn't: @Override public void visitMethodDef(JCMethodDecl >> tree) {} at the TreeScanner anonymous class created at >> visitSwitchExpression redundant? > > Yes, that's not really necessary, removed. > >> - at Lower, minor, inside method: convertCase, is it necessary to always >> create a block inside visitBreak? > > Here, a single statement (value break) is replaced with two statements > (an assignment and a break). If the original value break would be > inside a block, then we could replace it with the statements inside > the enclosing block. But we would still need to replace the value > break with a block sometimes (if the value break would not be enclosed > by a block), and using the block always shouldn't hurt much, so I > opted for the current simpler state. > > Jan > >> >> overall great job! >> Vicente >> >> On 07/17/2018 02:00 PM, Jan Lahoda wrote: >>> Hi, >>> >>> As JEP 325 is in the proposed to target state, I thought it might be a >>> good idea to start a review process for the code. >>> >>> The code here strives to implement the current specification for the >>> Switch Expressions: >>> http://cr.openjdk.java.net/~gbierman/switch-expressions.html >>> >>> The current webrev is here: >>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.00/ >>> >>> (includes a list of new errors.) >>> >>> JBS: >>> https://bugs.openjdk.java.net/browse/JDK-8192963 >>> https://bugs.openjdk.java.net/browse/JDK-8206986 >>> >>> CSRs: >>> https://bugs.openjdk.java.net/browse/JDK-8207241 >>> https://bugs.openjdk.java.net/browse/JDK-8207406 >>> >>> Any feedback is welcome! >>> >>> Thanks, >>> ??? Jan >> From joe.darcy at oracle.com Thu Jul 19 21:42:06 2018 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 19 Jul 2018 14:42:06 -0700 Subject: RFR: JDK-8206874: Evaluate LoadClassFromJava6CreatedJarTest.java after dropping -source 6 In-Reply-To: <0b44d97a-cd83-cf37-c88e-34605b847e96@oracle.com> References: <0b44d97a-cd83-cf37-c88e-34605b847e96@oracle.com> Message-ID: <3becf89d-e14f-41fb-7639-2c7a6db8d29a@oracle.com> Hi Vicente, The current patch looks fine. It would arguably be more robust if min, max, and premax were computed more directly based on information from Source. For example, run a loop over the supported source values such as ??????????? for(Source source :? Source.values()) { ??????????????? if (source.isSupported()) ??????????????????? supportedSources.add(source.name); ??????????? } and then populate min, max, and premax accordingly. Thanks, -Joe On 7/19/2018 10:27 AM, Vicente Romero wrote: > Hi all, > > Please review the patch to fix [1] at [2]. The fix is basically > removing the test as it is not useful anymore, > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8206874 > [2] http://cr.openjdk.java.net/~vromero/8206874/webrev.00/jdk.dev.patch From joe.darcy at oracle.com Fri Jul 20 00:03:31 2018 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 19 Jul 2018 17:03:31 -0700 Subject: JDK 12 RFR of JDK-8193462: Fix Filer handling of package-info initial elements Message-ID: <039391da-5c27-2cd8-18c8-f1340f65b791@oracle.com> Hello, Swapping in some work from late 2017 (http://mail.openjdk.java.net/pipermail/compiler-dev/2017-December/011434.html), please review a fix to address: ??? JDK-8193462: Fix Filer handling of package-info initial elements ??? http://cr.openjdk.java.net/~darcy/8193462.1/ This version of the fix incorporates Liam's suggestion to set the source file of the package in Enter. All langtools regression tests pass with the current version of the fix. Thanks, -Joe From alex.buckley at oracle.com Fri Jul 20 01:40:06 2018 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 19 Jul 2018 18:40:06 -0700 Subject: Type annotations on inner type that is an array components In-Reply-To: References: <5B50E520.90504@oracle.com> Message-ID: <5B513D76.3010303@oracle.com> Hi Mike, javac's generation of target_path items for annotated nested types is clearly sub-par, and fixing this particular issue may tickle (or even create) related issues. I'd therefore lean towards this issue being a P3 rather than a P4, although javac developers would govern. The rampdown schedule is at http://openjdk.java.net/projects/jdk/11/. I doubt that this P3 can be reported, fixed, tested, and reviewed by the start of RDP2, which is when a P3 (or P4) would expect to be dropped or deferred. Do you have a fix ready to go? (Please note that LTS is a non-factor in JEP 3, which describes the release process and is linked from the URL above.) Alex On 7/19/2018 5:03 PM, Michael Ernst wrote: > Alex, > > Thanks for the confirmation. I appreciate it. > > We suspect that this was introduced in a refactoring and not noticed due > to a lack of tests. I would think that this particular scenario is > relatively rare (a public interface that mentions an array of inner > types), but it is a serious issue for some of our users. > > I'm not sure what phase of rampdown JDK 11 is in. What are the chances > that this could be fixed before the next LTS release is made? > > Thanks, > > Mike > > On Thu, Jul 19, 2018, 12:23 PM Alex Buckley > wrote: > > Hi Werner, > > On 7/18/2018 4:49 PM, Werner Dietl wrote: > > class ArrayOfInner { > > class Inner {} > > > > @TA(1) ArrayOfInner. @TA(2) Inner oi; > > @TA(3) ArrayOfInner. @TA(4) Inner [] oia; > > @TA(5) Inner i; > > @TA(6) Inner [] ia; > > } > > > > > > Compile with javac 8 and according to javap -v field ia has the > annotation: > > > > ArrayOfInner$Inner[] ia; > > descriptor: [LArrayOfInner$Inner; > > flags: (0x0000) > > RuntimeVisibleTypeAnnotations: > > 0: #10(#11=I#21): FIELD, location=[ARRAY, INNER_TYPE] > > > > Compile with javac 9, 10, or a recent 11 build and ia has the > annotation: > > > > ArrayOfInner$Inner[] ia; > > descriptor: [LArrayOfInner$Inner; > > flags: (0x0000) > > RuntimeVisibleTypeAnnotations: > > 0: #10(#11=I#21): FIELD, location=[ARRAY] > > > > Note the missing INNER_TYPE location. > > > > I would like to argue that the Java 8 behavior was correct. > > Sounds right. Given source code that denotes the array type "Inner[]", > the question is whether the component type of that array type is a > nested type (ArrayOfInner.Inner) or not (just Inner). Logically, yes, > it's a nested type, so the target_path item deserves an INNER_TYPE > entry. > > This feels like the kind of detail we've been round and round on in the > past. That said, I don't see any mails that would have led to javac > changing how it emits target_path between 8 and 9. The closest suspect > is a compiler-dev thread from Jan/Feb 2016 -- "Bug in encoding type > annotations for supertype_targets" -- which spoke about the target_path > being omitted entirely for an annotated nested type. (JDK-8148504 was > filed against 8, but it's still open, so it can't have caused any > collateral damage for a field type's annotation.) > > Alex > From joe.darcy at oracle.com Fri Jul 20 05:03:50 2018 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 19 Jul 2018 22:03:50 -0700 Subject: JDK 12 RFR of JDK-8193214: Incorrect annotations.without.processors warnings with JDK 9 Message-ID: Hello, Please review the changes to address ??? JDK-8193214: Incorrect annotations.without.processors warnings with JDK 9 ??? http://cr.openjdk.java.net/~darcy/8193214.0/ At some point during JDK 6 or earlier JDK 7, the platform annotations were filtered out of the annotations.without.processors warning issued under the -Xlint:processing flag. This change adds several platform annotations, those now in the java.base module, to the list of annotation that should be filtered away as being out-of-scope for annotation processors to process since they are implicitly handled by javac. In addition, the module-enabled releases the string-based check adds "java.base/" as a prefix. Thanks, -Joe From bsrbnd at gmail.com Fri Jul 20 14:05:39 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Fri, 20 Jul 2018 16:05:39 +0200 Subject: RFR: JDK-8192963/JDK-8206986 JEP 325: Switch Expressions (Preview) In-Reply-To: <5B50E951.6000807@oracle.com> References: <5B4E2ECA.5070805@oracle.com> <5B50E951.6000807@oracle.com> Message-ID: On 19 July 2018 at 21:41, Jan Lahoda wrote: > Hi Bernard, > > On 19.7.2018 18:49, B. Blaser wrote: >> >> Hi Jan, >> >> On 17 July 2018 at 20:00, Jan Lahoda wrote: >>> >>> Hi, >>> >>> As JEP 325 is in the proposed to target state, I thought it might be a >>> good >>> idea to start a review process for the code. >>> >>> The code here strives to implement the current specification for the >>> Switch >>> Expressions: >>> http://cr.openjdk.java.net/~gbierman/switch-expressions.html >>> >>> The current webrev is here: >>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.00/ >> >> >> Going back to thread [1], I'd like to suggest some cosmetic changes to >> 'LetExpr': >> * 'LetExpr.defs' could be renamed to 'LetExpr.stmts' >> * 'LetExpr' could be renamed to 'BlockExpr' >> * 'Pretty' could print '(exec ... eval ...)' instead of '(let ... in ...)' > > > Good points. On the other hand, I am not sure if it is good to complicate > this patch (esp. with a rename to BlockExpr). Maybe we could work on the > LetExpr improvements and then rebase the switch expressions patch on that? I guess you're right. We can to that before or after the integration of switch expressions not to complicate this patch. I can take a look at this soon (probably after the integration) unless you want to? Thanks, Bernard > Thanks, > Jan > > >> >> I also note that [2] could be finally addressed but probably separately. >> >> Cheers, >> Bernard >> >> [1] >> http://mail.openjdk.java.net/pipermail/compiler-dev/2017-May/010954.html >> [2] https://bugs.openjdk.java.net/browse/JDK-8183548 >> >> >>> (includes a list of new errors.) >>> >>> JBS: >>> https://bugs.openjdk.java.net/browse/JDK-8192963 >>> https://bugs.openjdk.java.net/browse/JDK-8206986 >>> >>> CSRs: >>> https://bugs.openjdk.java.net/browse/JDK-8207241 >>> https://bugs.openjdk.java.net/browse/JDK-8207406 >>> >>> Any feedback is welcome! >>> >>> Thanks, >>> Jan From vicente.romero at oracle.com Fri Jul 20 15:14:20 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 20 Jul 2018 11:14:20 -0400 Subject: RFR: 8205493: OptionSmokeTest.java uses hard-coded release values In-Reply-To: <3becf89d-e14f-41fb-7639-2c7a6db8d29a@oracle.com> References: <0b44d97a-cd83-cf37-c88e-34605b847e96@oracle.com> <3becf89d-e14f-41fb-7639-2c7a6db8d29a@oracle.com> Message-ID: Hi Joe, Thanks for your comments. I have modified the test [3] and now I'm only using min and max supported source version which can be read directly from Source thus simplifying the code. What do you think? Vicente [3] http://cr.openjdk.java.net/~vromero/8205493/webrev.01/jdk.dev.patch On 07/19/2018 05:42 PM, joe darcy wrote: > Hi Vicente, > > The current patch looks fine. It would arguably be more robust if min, > max, and premax were computed more directly based on information from > Source. For example, run a loop over the supported source values such as > > ??????????? for(Source source :? Source.values()) { > ??????????????? if (source.isSupported()) > ??????????????????? supportedSources.add(source.name); > ??????????? } > > and then populate min, max, and premax accordingly. > > Thanks, > > -Joe > > > On 7/19/2018 10:27 AM, Vicente Romero wrote: >> Hi all, >> >> Please review the patch to fix [1] at [2]. The fix is basically >> removing the test as it is not useful anymore, >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8206874 >> [2] http://cr.openjdk.java.net/~vromero/8206874/webrev.00/jdk.dev.patch > From vicente.romero at oracle.com Fri Jul 20 16:00:40 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 20 Jul 2018 12:00:40 -0400 Subject: JDK 12 RFR of JDK-8193462: Fix Filer handling of package-info initial elements In-Reply-To: <039391da-5c27-2cd8-18c8-f1340f65b791@oracle.com> References: <039391da-5c27-2cd8-18c8-f1340f65b791@oracle.com> Message-ID: looks good to me, Vicente On 07/19/2018 08:03 PM, joe darcy wrote: > Hello, > > Swapping in some work from late 2017 > (http://mail.openjdk.java.net/pipermail/compiler-dev/2017-December/011434.html), > please review a fix to address: > > ??? JDK-8193462: Fix Filer handling of package-info initial elements > ??? http://cr.openjdk.java.net/~darcy/8193462.1/ > > This version of the fix incorporates Liam's suggestion to set the > source file of the package in Enter. > > All langtools regression tests pass with the current version of the fix. > > Thanks, > > -Joe > From vicente.romero at oracle.com Fri Jul 20 16:10:38 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 20 Jul 2018 12:10:38 -0400 Subject: JDK 12 RFR of JDK-8193214: Incorrect annotations.without.processors warnings with JDK 9 In-Reply-To: References: Message-ID: <6adb717c-8dad-94a8-4bfb-ac05c6c8863d@oracle.com> looks good, Vicente On 07/20/2018 01:03 AM, joe darcy wrote: > Hello, > > Please review the changes to address > > ??? JDK-8193214: Incorrect annotations.without.processors warnings > with JDK 9 > ??? http://cr.openjdk.java.net/~darcy/8193214.0/ > > At some point during JDK 6 or earlier JDK 7, the platform annotations > were filtered out of the annotations.without.processors warning issued > under the -Xlint:processing flag. This change adds several platform > annotations, those now in the java.base module, to the list of > annotation that should be filtered away as being out-of-scope for > annotation processors to process since they are implicitly handled by > javac. > > In addition, the module-enabled releases the string-based check adds > "java.base/" as a prefix. > > Thanks, > > -Joe > From joe.darcy at oracle.com Fri Jul 20 20:10:49 2018 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Fri, 20 Jul 2018 13:10:49 -0700 Subject: RFR: 8205493: OptionSmokeTest.java uses hard-coded release values In-Reply-To: References: <0b44d97a-cd83-cf37-c88e-34605b847e96@oracle.com> <3becf89d-e14f-41fb-7639-2c7a6db8d29a@oracle.com> Message-ID: <5B5241C9.4080703@oracle.com> Hi Vicente, Looks good; thanks, -Joe On 7/20/2018 8:14 AM, Vicente Romero wrote: > Hi Joe, > > Thanks for your comments. I have modified the test [3] and now I'm > only using min and max supported source version which can be read > directly from Source thus simplifying the code. What do you think? > > Vicente > > [3] http://cr.openjdk.java.net/~vromero/8205493/webrev.01/jdk.dev.patch > > > On 07/19/2018 05:42 PM, joe darcy wrote: >> Hi Vicente, >> >> The current patch looks fine. It would arguably be more robust if >> min, max, and premax were computed more directly based on information >> from Source. For example, run a loop over the supported source values >> such as >> >> for(Source source : Source.values()) { >> if (source.isSupported()) >> supportedSources.add(source.name); >> } >> >> and then populate min, max, and premax accordingly. >> >> Thanks, >> >> -Joe >> >> >> On 7/19/2018 10:27 AM, Vicente Romero wrote: >>> Hi all, >>> >>> Please review the patch to fix [1] at [2]. The fix is basically >>> removing the test as it is not useful anymore, >>> >>> Thanks, >>> Vicente >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8206874 >>> [2] http://cr.openjdk.java.net/~vromero/8206874/webrev.00/jdk.dev.patch >> > From vicente.romero at oracle.com Fri Jul 20 20:27:40 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 20 Jul 2018 16:27:40 -0400 Subject: RFR JDK-8206142: type inference: javac is incorrectly applying capture conversion during incorporation Message-ID: <4ac51895-1d0b-9e1a-c0b2-b5d9a368041b@oracle.com> Hi all, Please review the patch to fix [1] at [2]. The fix is putting javac in sync with the spec by not applying capture conversion during incorporation. Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8206142 [2] http://cr.openjdk.java.net/~vromero/8206142/webrev.00/jdk.dev.patch From bsrbnd at gmail.com Sat Jul 21 13:49:53 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Sat, 21 Jul 2018 15:49:53 +0200 Subject: RFR JDK-8206142: type inference: javac is incorrectly applying capture conversion during incorporation In-Reply-To: <4ac51895-1d0b-9e1a-c0b2-b5d9a368041b@oracle.com> References: <4ac51895-1d0b-9e1a-c0b2-b5d9a368041b@oracle.com> Message-ID: Hi Vicente, On 20 July 2018 at 22:27, Vicente Romero wrote: > Hi all, > > Please review the patch to fix [1] at [2]. The fix is putting javac in sync > with the spec by not applying capture conversion during incorporation. > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8206142 > [2] http://cr.openjdk.java.net/~vromero/8206142/webrev.00/jdk.dev.patch It's hard to measure the potential side-effects of this fix, but it seems good to me even if you'll probably need another review. Maybe, I'd rewrite it as next to avoid creating a new method? Thanks, Bernard diff -r b0fcf59be391 src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java Fri Jul 20 14:48:41 2018 -0700 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java Sat Jul 21 14:33:05 2018 +0200 @@ -1003,24 +1003,24 @@ * Is t an unchecked subtype of s? */ public boolean isSubtypeUnchecked(Type t, Type s, Warner warn) { - boolean result = isSubtypeUncheckedInternal(t, s, true, warn); + boolean result = isSubtypeUnchecked(t, s, true, warn); if (result) { checkUnsafeVarargsConversion(t, s, warn); } return result; } //where - private boolean isSubtypeUncheckedInternal(Type t, Type s, boolean capture, Warner warn) { + public boolean isSubtypeUnchecked(Type t, Type s, boolean capture, Warner warn) { if (t.hasTag(ARRAY) && s.hasTag(ARRAY)) { if (((ArrayType)t).elemtype.isPrimitive()) { return isSameType(elemtype(t), elemtype(s)); } else { - return isSubtypeUncheckedInternal(elemtype(t), elemtype(s), false, warn); + return isSubtypeUnchecked(elemtype(t), elemtype(s), false, warn); } } else if (isSubtype(t, s, capture)) { return true; } else if (t.hasTag(TYPEVAR)) { - return isSubtypeUncheckedInternal(t.getUpperBound(), s, false, warn); + return isSubtypeUnchecked(t.getUpperBound(), s, false, warn); } else if (!s.isRaw()) { Type t2 = asSuper(t, s.tsym); if (t2 != null && t2.isRaw()) { diff -r b0fcf59be391 src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java Fri Jul 20 14:48:41 2018 -0700 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java Sat Jul 21 14:33:05 2018 +0200 @@ -1180,7 +1180,7 @@ IS_SUBTYPE() { @Override boolean apply(Type op1, Type op2, Warner warn, Types types) { - return types.isSubtypeUnchecked(op1, op2, warn); + return types.isSubtypeUnchecked(op1, op2, false, warn); } }, IS_SAME_TYPE() { From bsrbnd at gmail.com Sat Jul 21 14:13:02 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Sat, 21 Jul 2018 16:13:02 +0200 Subject: RFR JDK-8206142: type inference: javac is incorrectly applying capture conversion during incorporation In-Reply-To: References: <4ac51895-1d0b-9e1a-c0b2-b5d9a368041b@oracle.com> Message-ID: On 21 July 2018 at 15:49, B. Blaser wrote: > Hi Vicente, > > On 20 July 2018 at 22:27, Vicente Romero wrote: >> Hi all, >> >> Please review the patch to fix [1] at [2]. The fix is putting javac in sync >> with the spec by not applying capture conversion during incorporation. >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8206142 >> [2] http://cr.openjdk.java.net/~vromero/8206142/webrev.00/jdk.dev.patch > > It's hard to measure the potential side-effects of this fix, but it > seems good to me even if you'll probably need another review. > Maybe, I'd rewrite it as next to avoid creating a new method? My suggestion would miss 'checkUnsafeVarargsConversion()', so your patch is better ;-) Bernard > Thanks, > Bernard From jan.lahoda at oracle.com Mon Jul 23 11:44:30 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 23 Jul 2018 13:44:30 +0200 Subject: RFF (12): JDK-8207954: Data for --release 11 Message-ID: <5B55BF9E.1090901@oracle.com> Hi, To support --release 11 in JDK 12, historical data for JDK 11 need to be added. As new attributes (NestHost and NestMembers) have been added to the classfile, there also needs to be some tweaking of the tool that creates the historical descriptions and the ct.sym sigfiles. The proposed patch has two parts: -code changes, which include: --update to the build scripts and the tool, so that the tool can read both the open and extra/closed description of the ct.sym content, and merge those (there should not be any extra/closed for JDK 11, AFAIK, so this is to avoid having to update the closed part). --improving the description on how to add historical data for new releases, using the new source launcher --adding support for the new NestHost/NestMembers attributes --adding a new test which strives to fail when a new attribute is added and CreateSymbols is not updated http://cr.openjdk.java.net/~jlahoda/8207954/webrev.code.00/ -addition of the historical data: http://cr.openjdk.java.net/~jlahoda/8207954/webrev.data.00/ (these may need to be re-generated when the final JDK 11 is released in case there are any changes, but that should be very simple) JBS: https://bugs.openjdk.java.net/browse/JDK-8207954 Any feedback is welcome, Jan From vicente.romero at oracle.com Mon Jul 23 13:22:18 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 23 Jul 2018 09:22:18 -0400 Subject: RFR JDK-8206142: type inference: javac is incorrectly applying capture conversion during incorporation In-Reply-To: References: <4ac51895-1d0b-9e1a-c0b2-b5d9a368041b@oracle.com> Message-ID: <9bd84725-d989-8514-db6b-fd844c85ca11@oracle.com> On 07/21/2018 09:49 AM, B. Blaser wrote: > Hi Vicente, > > On 20 July 2018 at 22:27, Vicente Romero wrote: >> Hi all, >> >> Please review the patch to fix [1] at [2]. The fix is putting javac in sync >> with the spec by not applying capture conversion during incorporation. >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8206142 >> [2] http://cr.openjdk.java.net/~vromero/8206142/webrev.00/jdk.dev.patch > It's hard to measure the potential side-effects of this fix, yes, I'm also worried about the possible side effects. I agree that more discussion will be needed, > but it > seems good to me even if you'll probably need another review. > Maybe, I'd rewrite it as next to avoid creating a new method? > > Thanks, > Bernard Thanks, Vicente > > > diff -r b0fcf59be391 > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java > Fri Jul 20 14:48:41 2018 -0700 > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java > Sat Jul 21 14:33:05 2018 +0200 > @@ -1003,24 +1003,24 @@ > * Is t an unchecked subtype of s? > */ > public boolean isSubtypeUnchecked(Type t, Type s, Warner warn) { > - boolean result = isSubtypeUncheckedInternal(t, s, true, warn); > + boolean result = isSubtypeUnchecked(t, s, true, warn); > if (result) { > checkUnsafeVarargsConversion(t, s, warn); > } > return result; > } > //where > - private boolean isSubtypeUncheckedInternal(Type t, Type s, > boolean capture, Warner warn) { > + public boolean isSubtypeUnchecked(Type t, Type s, boolean > capture, Warner warn) { > if (t.hasTag(ARRAY) && s.hasTag(ARRAY)) { > if (((ArrayType)t).elemtype.isPrimitive()) { > return isSameType(elemtype(t), elemtype(s)); > } else { > - return isSubtypeUncheckedInternal(elemtype(t), > elemtype(s), false, warn); > + return isSubtypeUnchecked(elemtype(t), > elemtype(s), false, warn); > } > } else if (isSubtype(t, s, capture)) { > return true; > } else if (t.hasTag(TYPEVAR)) { > - return isSubtypeUncheckedInternal(t.getUpperBound(), > s, false, warn); > + return isSubtypeUnchecked(t.getUpperBound(), s, false, warn); > } else if (!s.isRaw()) { > Type t2 = asSuper(t, s.tsym); > if (t2 != null && t2.isRaw()) { > diff -r b0fcf59be391 > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java > Fri Jul 20 14:48:41 2018 -0700 > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java > Sat Jul 21 14:33:05 2018 +0200 > @@ -1180,7 +1180,7 @@ > IS_SUBTYPE() { > @Override > boolean apply(Type op1, Type op2, Warner warn, Types types) { > - return types.isSubtypeUnchecked(op1, op2, warn); > + return types.isSubtypeUnchecked(op1, op2, false, warn); > } > }, > IS_SAME_TYPE() { From mernst at cs.washington.edu Fri Jul 20 00:03:28 2018 From: mernst at cs.washington.edu (Michael Ernst) Date: Thu, 19 Jul 2018 17:03:28 -0700 Subject: Type annotations on inner type that is an array components In-Reply-To: <5B50E520.90504@oracle.com> References: <5B50E520.90504@oracle.com> Message-ID: Alex, Thanks for the confirmation. I appreciate it. We suspect that this was introduced in a refactoring and not noticed due to a lack of tests. I would think that this particular scenario is relatively rare (a public interface that mentions an array of inner types), but it is a serious issue for some of our users. I'm not sure what phase of rampdown JDK 11 is in. What are the chances that this could be fixed before the next LTS release is made? Thanks, Mike On Thu, Jul 19, 2018, 12:23 PM Alex Buckley wrote: > Hi Werner, > > On 7/18/2018 4:49 PM, Werner Dietl wrote: > > class ArrayOfInner { > > class Inner {} > > > > @TA(1) ArrayOfInner. @TA(2) Inner oi; > > @TA(3) ArrayOfInner. @TA(4) Inner [] oia; > > @TA(5) Inner i; > > @TA(6) Inner [] ia; > > } > > > > > > Compile with javac 8 and according to javap -v field ia has the > annotation: > > > > ArrayOfInner$Inner[] ia; > > descriptor: [LArrayOfInner$Inner; > > flags: (0x0000) > > RuntimeVisibleTypeAnnotations: > > 0: #10(#11=I#21): FIELD, location=[ARRAY, INNER_TYPE] > > > > Compile with javac 9, 10, or a recent 11 build and ia has the annotation: > > > > ArrayOfInner$Inner[] ia; > > descriptor: [LArrayOfInner$Inner; > > flags: (0x0000) > > RuntimeVisibleTypeAnnotations: > > 0: #10(#11=I#21): FIELD, location=[ARRAY] > > > > Note the missing INNER_TYPE location. > > > > I would like to argue that the Java 8 behavior was correct. > > Sounds right. Given source code that denotes the array type "Inner[]", > the question is whether the component type of that array type is a > nested type (ArrayOfInner.Inner) or not (just Inner). Logically, yes, > it's a nested type, so the target_path item deserves an INNER_TYPE entry. > > This feels like the kind of detail we've been round and round on in the > past. That said, I don't see any mails that would have led to javac > changing how it emits target_path between 8 and 9. The closest suspect > is a compiler-dev thread from Jan/Feb 2016 -- "Bug in encoding type > annotations for supertype_targets" -- which spoke about the target_path > being omitted entirely for an annotated nested type. (JDK-8148504 was > filed against 8, but it's still open, so it can't have caused any > collateral damage for a field type's annotation.) > > Alex > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.buck at oracle.com Sun Jul 22 02:26:09 2018 From: david.buck at oracle.com (David Buck) Date: Sun, 22 Jul 2018 11:26:09 +0900 Subject: Short Question - About javac.c where is it? In-Reply-To: References: Message-ID: Hi Max! The compiler that compiles Java source code into Java bytecode is written entirely in Java itself. The only C code involved is the launcher executable, "javac" which (as explained by Erik) is simply a very small piece of JNI code that starts the JVM and points it to the main class. Everything else is pure Java. If you are really interesting in learning how the Java compiler works, I would recommend running it in a debugger. You can write a small stub that calls it via JavaCompiler [0] and then you don't need to worry about the native code used to invoke javac from the command line. If you are new to compilers in general, I would recommend reading "The Tiger Book" [1]. (Much of the book's content, especially many of the later chapters, would not directly apply to javac, but it is still a great book if you are looking for a place to start.) There are also a ton of great resources linked from the compiler team's OpenJDK project page [2]. Cheers, -Buck [0] https://docs.oracle.com/javase/8/docs/api/javax/tools/JavaCompiler.html [1] https://www.cs.princeton.edu/~appel/modern/java/ [2] http://openjdk.java.net/groups/compiler/ On 2018/07/21 9:56, mr rupplin wrote: > Hello. > > I look and find that we start here: > > http://hg.openjdk.java.net/jdk/jdk/file/b0fcf59be391/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Main.java > > public Result compile(String[] argv, Context context) > > and this leads to: > > http://hg.openjdk.java.net/jdk/jdk/file/b0fcf59be391/src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java > > comp.compile(args.getFileObjects(), args.getClassNames(), null, List.nil()); > > > Which leads to genCode: > > http://hg.openjdk.java.net/jdk/jdk/file/b0fcf59be391/src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java > > JavaFileObject genCode(Env env, JCClassDecl cdef) throws IOException > > Which calls: > > > return writer.writeClass(cdef.sym); > > And so I think if I've understood you (without a debugger running on this end) the JavaCompiler (in Java) will do a C compile on various C source code documents and share libraries and this will make the native binary "javac". Is that correct? > > The file "javac" is a native binary that is produced with a JavaCompiler called from the "bash configure && make all" command? > > Thanks! > > ?? MR/ > ________________________________ > From: Erik Joelsson > Sent: Friday, July 20, 2018 6:56 PM > To: mr rupplin; build-dev at openjdk.java.net > Subject: Re: Short Question - About javac.c where is it? > > Hello Max, > > Javac, like most of the command line tools in the JDK is written in > Java, so to look at the actual program, I would recommend starting here > (assuming current mainline at http://hg.openjdk.java.net/jdk/jdk): > > src/jdk.compiler/share/classes/com/sun/tools/javac/Main.java > > Most of the executables in the JDK are built from the same launcher src > file with some different -D macro flags set to control which java class > gets invoked by that launcher. The source for the launchers is located here: > > src/java.base/share/native/launcher/main.c > > Does that answer your question? > > /Erik > > > On 2018-07-20 15:31, mr rupplin wrote: >> In building the OpenJDK where may we find the source code file(s) for the javac output? >> >> In libjli we find the java.c but locate javac.c returns no results. How curious. >> >> Would you be a friend and help us out. We love reading. >> >> Thanks, >> >> Max >> >> /sr software developer > From erik.joelsson at oracle.com Mon Jul 23 16:56:47 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 23 Jul 2018 09:56:47 -0700 Subject: RFF (12): JDK-8207954: Data for --release 11 In-Reply-To: <5B55BF9E.1090901@oracle.com> References: <5B55BF9E.1090901@oracle.com> Message-ID: <8bad4563-4c8d-7246-1976-4b80a6b59ce9@oracle.com> Hello Jan, The assignment of a non existent directory looks suspect. You should be able assign to an empty value using ?=. On the other hand, what it looks like you want to achieve is having both the open and closed value on the command line. Then I would just change the ?= to +=. /Erik On 2018-07-23 04:44, Jan Lahoda wrote: > Hi, > > To support --release 11 in JDK 12, historical data for JDK 11 need to > be added. As new attributes (NestHost and NestMembers) have been added > to the classfile, there also needs to be some tweaking of the tool > that creates the historical descriptions and the ct.sym sigfiles. > > The proposed patch has two parts: > -code changes, which include: > --update to the build scripts and the tool, so that the tool can read > both the open and extra/closed description of the ct.sym content, and > merge those (there should not be any extra/closed for JDK 11, AFAIK, > so this is to avoid having to update the closed part). > --improving the description on how to add historical data for new > releases, using the new source launcher > --adding support for the new NestHost/NestMembers attributes > --adding a new test which strives to fail when a new attribute is > added and CreateSymbols is not updated > http://cr.openjdk.java.net/~jlahoda/8207954/webrev.code.00/ > > -addition of the historical data: > http://cr.openjdk.java.net/~jlahoda/8207954/webrev.data.00/ > (these may need to be re-generated when the final JDK 11 is released > in case there are any changes, but that should be very simple) > > JBS: https://bugs.openjdk.java.net/browse/JDK-8207954 > > Any feedback is welcome, > ???? Jan From joe.darcy at oracle.com Tue Jul 24 06:50:09 2018 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 23 Jul 2018 23:50:09 -0700 Subject: JDK 12 RFR of JDK-8190886: package-info handling in RoundEnvironment.getElementsAnnotatedWith Message-ID: <6a8cf499-d9d7-c6b8-91fc-6a9f749b0334@oracle.com> Hello, Please review the changes to address ??? JDK-8190886: package-info handling in RoundEnvironment.getElementsAnnotatedWith ??? http://cr.openjdk.java.net/~darcy/8190886.1/ Contrary to the spec, the RoundEnvironment.getElementsAnnotatedWith implementation was traversing into packages (and modules). Given the phase of JDK 11 and at least the potential for behavioral compatibility impact, I'm proposing to fix this in 12 rather than 11. I'll file a CSR for the behavioral change in due course. The implementation change is small, just adding overrides of visitor methods which skip scanning packages and modules. To allow use of AnnotatedElementInfo in compilation units in a named package, the AnnotatedElementInfo type has to itself be in a named package rather than an unnamed one; therefore, a number of supporting changes are needed to other test files in the directory to support that type rename. The tests have not been updated to verify the behavior on modules, but that could be done too. I've verified the updated test fails with a promoted build of JDK 12 but passes with a build with these javac modifications. All other langtools tests pass on a modified build too. I'll perform a copyright pass before pushing once the rest of the contents are reviewed. Thanks, -Joe From vicente.romero at oracle.com Tue Jul 24 17:00:40 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 24 Jul 2018 13:00:40 -0400 Subject: JDK 12 RFR of JDK-8190886: package-info handling in RoundEnvironment.getElementsAnnotatedWith In-Reply-To: <6a8cf499-d9d7-c6b8-91fc-6a9f749b0334@oracle.com> References: <6a8cf499-d9d7-c6b8-91fc-6a9f749b0334@oracle.com> Message-ID: <63ff7a7f-a19e-7f10-b4d0-ccc6596b21eb@oracle.com> looks good, just minimal copyright for test: test/langtools/tools/javac/processing/environment/round/pkg/package-info.java should be 2018 Vicente On 07/24/2018 02:50 AM, joe darcy wrote: > Hello, > > Please review the changes to address > > ??? JDK-8190886: package-info handling in > RoundEnvironment.getElementsAnnotatedWith > ??? http://cr.openjdk.java.net/~darcy/8190886.1/ > > Contrary to the spec, the RoundEnvironment.getElementsAnnotatedWith > implementation was traversing into packages (and modules). Given the > phase of JDK 11 and at least the potential for behavioral > compatibility impact, I'm proposing to fix this in 12 rather than 11. > I'll file a CSR for the behavioral change in due course. > > The implementation change is small, just adding overrides of visitor > methods which skip scanning packages and modules. To allow use of > AnnotatedElementInfo in compilation units in a named package, the > AnnotatedElementInfo type has to itself be in a named package rather > than an unnamed one; therefore, a number of supporting changes are > needed to other test files in the directory to support that type rename. > > The tests have not been updated to verify the behavior on modules, but > that could be done too. > > I've verified the updated test fails with a promoted build of JDK 12 > but passes with a build with these javac modifications. All other > langtools tests pass on a modified build too. > > I'll perform a copyright pass before pushing once the rest of the > contents are reviewed. > > Thanks, > > -Joe > From nezihyigitbasi at gmail.com Wed Jul 25 05:23:57 2018 From: nezihyigitbasi at gmail.com (nezih yigitbasi) Date: Tue, 24 Jul 2018 22:23:57 -0700 Subject: about Enum.values() memory allocation Message-ID: Hi, I recently noticed in our app that Enum.values() allocates a significant amount of memory when called in a tight loop as it clones the constant values array (which is probably for immutability, and I can understand that). I found that the same issue has been discussed back in 2012: http://mail.openjdk.java.net/pipermail/compiler-dev/2012-March/004210.html Are there any plans to address this issue going forward? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Wed Jul 25 06:32:10 2018 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 24 Jul 2018 23:32:10 -0700 Subject: JDK 12 RFR of JDK-8190886: package-info handling in RoundEnvironment.getElementsAnnotatedWith In-Reply-To: <63ff7a7f-a19e-7f10-b4d0-ccc6596b21eb@oracle.com> References: <6a8cf499-d9d7-c6b8-91fc-6a9f749b0334@oracle.com> <63ff7a7f-a19e-7f10-b4d0-ccc6596b21eb@oracle.com> Message-ID: Hello, I had hoped that writing a few more test to cover the modules cases would be a simple exercise, but that is not how things worked out! The resulting set of changes is now: ??? http://cr.openjdk.java.net/~darcy/8190886.6/ Major differences between the prior version sent for review are in the files src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java test/langtools/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java The earlier iteration of the fix was adequate for package-info files; however, there are several complications related to modules the previous fix did not account for. The getElementsAnnotatedWith methods with a java.lang.Class parameter need some way to bridge between the core reflection world and the compile-time reflection world of javax.lang.model. The way to do this is to construct a TypeElement for an annotation type corresponding to the Class object for the annotation type argument by mapping from the name of the annotation type to a type element via Elements.getTypeElement(name). A wrinkle is that the behavior of Elements.getTypeElement(name) was redefined in JDK 9 to account for modules since a name can correspond to multiple types post-modules. The revised fix first tries Elements.getTypeElement(name) and if that fails, including failing due to multiple results being found, it fails over to the two-argument version of Elements.getTypeElement which has a module parameter. The module parameter is set to a module whose name matches the name of the module of the Class, if such a Class is in a named module. On the testing sides, as discussed in JEP 200 when the compiler is running in single-module mode (which includes when compiling a module-info file), all the files being compiled are assumed to be in that module even if they would not be in the module by virtue of their file system locations. This necessitates some of the testing conditions being conditionally excluded. I'll leave any extension of this test to multi-module compilation mode for future work. Thanks, -Joe On 7/24/2018 10:00 AM, Vicente Romero wrote: > looks good, just minimal copyright for test: > > test/langtools/tools/javac/processing/environment/round/pkg/package-info.java > > > should be 2018 > > Vicente > > On 07/24/2018 02:50 AM, joe darcy wrote: >> Hello, >> >> Please review the changes to address >> >> ??? JDK-8190886: package-info handling in >> RoundEnvironment.getElementsAnnotatedWith >> ??? http://cr.openjdk.java.net/~darcy/8190886.1/ >> >> Contrary to the spec, the RoundEnvironment.getElementsAnnotatedWith >> implementation was traversing into packages (and modules). Given the >> phase of JDK 11 and at least the potential for behavioral >> compatibility impact, I'm proposing to fix this in 12 rather than 11. >> I'll file a CSR for the behavioral change in due course. >> >> The implementation change is small, just adding overrides of visitor >> methods which skip scanning packages and modules. To allow use of >> AnnotatedElementInfo in compilation units in a named package, the >> AnnotatedElementInfo type has to itself be in a named package rather >> than an unnamed one; therefore, a number of supporting changes are >> needed to other test files in the directory to support that type rename. >> >> The tests have not been updated to verify the behavior on modules, >> but that could be done too. >> >> I've verified the updated test fails with a promoted build of JDK 12 >> but passes with a build with these javac modifications. All other >> langtools tests pass on a modified build too. >> >> I'll perform a copyright pass before pushing once the rest of the >> contents are reviewed. >> >> Thanks, >> >> -Joe >> > From Michael.Rasmussen at roguewave.com Wed Jul 25 09:22:25 2018 From: Michael.Rasmussen at roguewave.com (Michael Rasmussen) Date: Wed, 25 Jul 2018 09:22:25 +0000 Subject: about Enum.values() memory allocation In-Reply-To: References: Message-ID: With condy being added in Java 11, this could potentially be a use-case for that ? for (EnumType e: const(EnumType.values())) { ... } Or perhaps it's time to add a List valuesList(); to enum types, that returns an immutable List of the values? /Michael ________________________________ From: compiler-dev on behalf of nezih yigitbasi Sent: 25 July 2018 08:23:57 To: compiler-dev at openjdk.java.net Subject: about Enum.values() memory allocation Hi, I recently noticed in our app that Enum.values() allocates a significant amount of memory when called in a tight loop as it clones the constant values array (which is probably for immutability, and I can understand that). I found that the same issue has been discussed back in 2012: http://mail.openjdk.java.net/pipermail/compiler-dev/2012-March/004210.html Are there any plans to address this issue going forward? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronshapiro at google.com Wed Jul 25 11:17:30 2018 From: ronshapiro at google.com (Ron Shapiro) Date: Wed, 25 Jul 2018 07:17:30 -0400 Subject: about Enum.values() memory allocation In-Reply-To: References: Message-ID: It's a bit of indirection, but can for (YourEnum e : EnumSet.allOf(YourEnum.class)) {} do the trick? It will still allocate, but likely only one instance instead of a full array. On Wed, Jul 25, 2018, 5:23 AM Michael Rasmussen < Michael.Rasmussen at roguewave.com> wrote: > With condy being added in Java 11, this could potentially be a use-case > for that ? > > > for (EnumType e: const(EnumType.values())) { ... } > > > Or perhaps it's time to add a List valuesList(); to enum types, that > returns an immutable List of the values? > > > /Michael > ------------------------------ > *From:* compiler-dev on behalf of > nezih yigitbasi > *Sent:* 25 July 2018 08:23:57 > *To:* compiler-dev at openjdk.java.net > *Subject:* about Enum.values() memory allocation > > Hi, > I recently noticed in our app that Enum.values() allocates a significant > amount of memory when called in a tight loop as it clones the constant > values array (which is probably for immutability, and I can understand > that). I found that the same issue has been discussed back in 2012: > http://mail.openjdk.java.net/pipermail/compiler-dev/2012-March/004210.html > > Are there any plans to address this issue going forward? > > Thanks! > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Wed Jul 25 12:00:03 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 25 Jul 2018 14:00:03 +0200 Subject: Type annotations on inner type that is an array components In-Reply-To: <5B513D76.3010303@oracle.com> References: <5B50E520.90504@oracle.com> <5B513D76.3010303@oracle.com> Message-ID: Hi, On 20 July 2018 at 03:40, Alex Buckley wrote: > Hi Mike, > > javac's generation of target_path items for annotated nested types is > clearly sub-par, and fixing this particular issue may tickle (or even > create) related issues. I'd therefore lean towards this issue being a P3 > rather than a P4, although javac developers would govern. > > The rampdown schedule is at http://openjdk.java.net/projects/jdk/11/. I > doubt that this P3 can be reported, fixed, tested, and reviewed by the start > of RDP2, which is when a P3 (or P4) would expect to be dropped or deferred. > Do you have a fix ready to go? Currently, inner types within arrays don't seem to be addressed for type annotations in declaration positions ('@TA(6)' for example, but not '@TA(4)'). Does anyone already try to fix this? If not, the following patch strives to fill this gap, tier1 is OK. Is there any open issue about that? Being not an expert in this area of the compiler, any comment or subsequent explanation would be welcome. Thanks, Bernard > (Please note that LTS is a non-factor in JEP 3, which describes the release > process and is linked from the URL above.) > > Alex diff -r b0fcf59be391 src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java Fri Jul 20 14:48:41 2018 -0700 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java Wed Jul 25 12:32:00 2018 +0200 @@ -423,9 +423,6 @@ return type; } - if (type.hasTag(TypeTag.ARRAY)) - return rewriteArrayType((ArrayType)type, annotations, pos); - if (type.hasTag(TypeTag.TYPEVAR)) { return type.annotatedType(onlyTypeAnnotations); } else if (type.getKind() == TypeKind.UNION) { @@ -443,6 +440,14 @@ Element enclEl = type.asElement(); JCTree enclTr = typetree; + if (type.hasTag(TypeTag.ARRAY) && enclTr.getKind() != JCTree.Kind.ANNOTATED_TYPE) { + while (enclTy.hasTag(TypeTag.ARRAY)) { + enclTy = ((ArrayType)enclTy).elemtype; + } + enclEl = enclTy.asElement(); + enclTr = ((JCArrayTypeTree)typetree).elemtype; + } + while (enclEl != null && enclEl.getKind() != ElementKind.PACKAGE && enclTy != null && @@ -523,9 +528,13 @@ p.location = p.location.appendList(depth.toList()); } - Type ret = typeWithAnnotations(type, enclTy, annotations); - typetree.type = ret; - return ret; + if (type.hasTag(TypeTag.ARRAY)) + return rewriteArrayType((ArrayType)type, annotations, pos, depth.toList()); + else { + Type ret = typeWithAnnotations(type, enclTy, annotations); + typetree.type = ret; + return ret; + } } } @@ -536,7 +545,7 @@ * * SIDE EFFECT: Update position for the annotations to be {@code pos}. */ - private Type rewriteArrayType(ArrayType type, List annotations, TypeAnnotationPosition pos) { + private Type rewriteArrayType(ArrayType type, List annotations, TypeAnnotationPosition pos, List depth) { ArrayType tomodify = new ArrayType(type); ArrayType res = tomodify; @@ -581,7 +590,7 @@ for (TypeCompound tc : annotations) { if (tc.position == null) tc.position = pos; - tc.position.location = loc; + tc.position.location = depth.prependList(loc); } return res; From jan.lahoda at oracle.com Wed Jul 25 13:17:27 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 25 Jul 2018 15:17:27 +0200 Subject: JDK 12 RFR of JDK-8190886: package-info handling in RoundEnvironment.getElementsAnnotatedWith In-Reply-To: References: <6a8cf499-d9d7-c6b8-91fc-6a9f749b0334@oracle.com> <63ff7a7f-a19e-7f10-b4d0-ccc6596b21eb@oracle.com> Message-ID: <5B587867.3090400@oracle.com> Looks good to me. Jan On 25.7.2018 08:32, joe darcy wrote: > Hello, > > I had hoped that writing a few more test to cover the modules cases > would be a simple exercise, but that is not how things worked out! > > The resulting set of changes is now: > > http://cr.openjdk.java.net/~darcy/8190886.6/ > > Major differences between the prior version sent for review are in the > files > > src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java > > test/langtools/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java > > > The earlier iteration of the fix was adequate for package-info files; > however, there are several complications related to modules the previous > fix did not account for. > > The getElementsAnnotatedWith methods with a java.lang.Class parameter > need some way to bridge between the core reflection world and the > compile-time reflection world of javax.lang.model. The way to do this is > to construct a TypeElement for an annotation type corresponding to the > Class object for the annotation type argument by mapping from the name > of the annotation type to a type element via > Elements.getTypeElement(name). A wrinkle is that the behavior of > Elements.getTypeElement(name) was redefined in JDK 9 to account for > modules since a name can correspond to multiple types post-modules. The > revised fix first tries Elements.getTypeElement(name) and if that fails, > including failing due to multiple results being found, it fails over to > the two-argument version of Elements.getTypeElement which has a module > parameter. The module parameter is set to a module whose name matches > the name of the module of the Class, if such a Class is in a named module. > > On the testing sides, as discussed in JEP 200 when the compiler is > running in single-module mode (which includes when compiling a > module-info file), all the files being compiled are assumed to be in > that module even if they would not be in the module by virtue of their > file system locations. This necessitates some of the testing conditions > being conditionally excluded. > > I'll leave any extension of this test to multi-module compilation mode > for future work. > > Thanks, > > -Joe > > > On 7/24/2018 10:00 AM, Vicente Romero wrote: >> looks good, just minimal copyright for test: >> >> test/langtools/tools/javac/processing/environment/round/pkg/package-info.java >> >> >> should be 2018 >> >> Vicente >> >> On 07/24/2018 02:50 AM, joe darcy wrote: >>> Hello, >>> >>> Please review the changes to address >>> >>> JDK-8190886: package-info handling in >>> RoundEnvironment.getElementsAnnotatedWith >>> http://cr.openjdk.java.net/~darcy/8190886.1/ >>> >>> Contrary to the spec, the RoundEnvironment.getElementsAnnotatedWith >>> implementation was traversing into packages (and modules). Given the >>> phase of JDK 11 and at least the potential for behavioral >>> compatibility impact, I'm proposing to fix this in 12 rather than 11. >>> I'll file a CSR for the behavioral change in due course. >>> >>> The implementation change is small, just adding overrides of visitor >>> methods which skip scanning packages and modules. To allow use of >>> AnnotatedElementInfo in compilation units in a named package, the >>> AnnotatedElementInfo type has to itself be in a named package rather >>> than an unnamed one; therefore, a number of supporting changes are >>> needed to other test files in the directory to support that type rename. >>> >>> The tests have not been updated to verify the behavior on modules, >>> but that could be done too. >>> >>> I've verified the updated test fails with a promoted build of JDK 12 >>> but passes with a build with these javac modifications. All other >>> langtools tests pass on a modified build too. >>> >>> I'll perform a copyright pass before pushing once the rest of the >>> contents are reviewed. >>> >>> Thanks, >>> >>> -Joe >>> >> > From vicente.romero at oracle.com Wed Jul 25 14:51:08 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 25 Jul 2018 10:51:08 -0400 Subject: JDK 12 RFR of JDK-8190886: package-info handling in RoundEnvironment.getElementsAnnotatedWith In-Reply-To: References: <6a8cf499-d9d7-c6b8-91fc-6a9f749b0334@oracle.com> <63ff7a7f-a19e-7f10-b4d0-ccc6596b21eb@oracle.com> Message-ID: <19deb59e-8303-abff-df51-21de8776f95f@oracle.com> looks good, Vicente On 07/25/2018 02:32 AM, joe darcy wrote: > Hello, > > I had hoped that writing a few more test to cover the modules cases > would be a simple exercise, but that is not how things worked out! > > The resulting set of changes is now: > > ??? http://cr.openjdk.java.net/~darcy/8190886.6/ > > Major differences between the prior version sent for review are in the > files > > src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java > > test/langtools/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java > > > The earlier iteration of the fix was adequate for package-info files; > however, there are several complications related to modules the > previous fix did not account for. > > The getElementsAnnotatedWith methods with a java.lang.Class parameter > need some way to bridge between the core reflection world and the > compile-time reflection world of javax.lang.model. The way to do this > is to construct a TypeElement for an annotation type corresponding to > the Class object for the annotation type argument by mapping from the > name of the annotation type to a type element via > Elements.getTypeElement(name). A wrinkle is that the behavior of > Elements.getTypeElement(name) was redefined in JDK 9 to account for > modules since a name can correspond to multiple types post-modules. > The revised fix first tries Elements.getTypeElement(name) and if that > fails, including failing due to multiple results being found, it fails > over to the two-argument version of Elements.getTypeElement which has > a module parameter. The module parameter is set to a module whose name > matches the name of the module of the Class, if such a Class is in a > named module. > > On the testing sides, as discussed in JEP 200 when the compiler is > running in single-module mode (which includes when compiling a > module-info file), all the files being compiled are assumed to be in > that module even if they would not be in the module by virtue of their > file system locations. This necessitates some of the testing > conditions being conditionally excluded. > > I'll leave any extension of this test to multi-module compilation mode > for future work. > > Thanks, > > -Joe > > > On 7/24/2018 10:00 AM, Vicente Romero wrote: >> looks good, just minimal copyright for test: >> >> test/langtools/tools/javac/processing/environment/round/pkg/package-info.java >> >> >> should be 2018 >> >> Vicente >> >> On 07/24/2018 02:50 AM, joe darcy wrote: >>> Hello, >>> >>> Please review the changes to address >>> >>> ??? JDK-8190886: package-info handling in >>> RoundEnvironment.getElementsAnnotatedWith >>> ??? http://cr.openjdk.java.net/~darcy/8190886.1/ >>> >>> Contrary to the spec, the RoundEnvironment.getElementsAnnotatedWith >>> implementation was traversing into packages (and modules). Given the >>> phase of JDK 11 and at least the potential for behavioral >>> compatibility impact, I'm proposing to fix this in 12 rather than >>> 11. I'll file a CSR for the behavioral change in due course. >>> >>> The implementation change is small, just adding overrides of visitor >>> methods which skip scanning packages and modules. To allow use of >>> AnnotatedElementInfo in compilation units in a named package, the >>> AnnotatedElementInfo type has to itself be in a named package rather >>> than an unnamed one; therefore, a number of supporting changes are >>> needed to other test files in the directory to support that type >>> rename. >>> >>> The tests have not been updated to verify the behavior on modules, >>> but that could be done too. >>> >>> I've verified the updated test fails with a promoted build of JDK 12 >>> but passes with a build with these javac modifications. All other >>> langtools tests pass on a modified build too. >>> >>> I'll perform a copyright pass before pushing once the rest of the >>> contents are reviewed. >>> >>> Thanks, >>> >>> -Joe >>> >> > From jan.lahoda at oracle.com Wed Jul 25 15:15:55 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 25 Jul 2018 17:15:55 +0200 Subject: RFF (12): JDK-8207954: Data for --release 11 In-Reply-To: <8bad4563-4c8d-7246-1976-4b80a6b59ce9@oracle.com> References: <5B55BF9E.1090901@oracle.com> <8bad4563-4c8d-7246-1976-4b80a6b59ce9@oracle.com> Message-ID: <5B58942B.5090308@oracle.com> Thanks Erik. I've updated the code patch here: http://cr.openjdk.java.net/~jlahoda/8207954/webrev.code.01/ (the data patch remains the same) Does this look better? Thanks, Jan On 23.7.2018 18:56, Erik Joelsson wrote: > Hello Jan, > > The assignment of a non existent directory looks suspect. You should be > able assign to an empty value using ?=. On the other hand, what it looks > like you want to achieve is having both the open and closed value on the > command line. Then I would just change the ?= to +=. > > /Erik > > > On 2018-07-23 04:44, Jan Lahoda wrote: >> Hi, >> >> To support --release 11 in JDK 12, historical data for JDK 11 need to >> be added. As new attributes (NestHost and NestMembers) have been added >> to the classfile, there also needs to be some tweaking of the tool >> that creates the historical descriptions and the ct.sym sigfiles. >> >> The proposed patch has two parts: >> -code changes, which include: >> --update to the build scripts and the tool, so that the tool can read >> both the open and extra/closed description of the ct.sym content, and >> merge those (there should not be any extra/closed for JDK 11, AFAIK, >> so this is to avoid having to update the closed part). >> --improving the description on how to add historical data for new >> releases, using the new source launcher >> --adding support for the new NestHost/NestMembers attributes >> --adding a new test which strives to fail when a new attribute is >> added and CreateSymbols is not updated >> http://cr.openjdk.java.net/~jlahoda/8207954/webrev.code.00/ >> >> -addition of the historical data: >> http://cr.openjdk.java.net/~jlahoda/8207954/webrev.data.00/ >> (these may need to be re-generated when the final JDK 11 is released >> in case there are any changes, but that should be very simple) >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8207954 >> >> Any feedback is welcome, >> Jan > From erik.joelsson at oracle.com Wed Jul 25 15:46:16 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 25 Jul 2018 08:46:16 -0700 Subject: RFF (12): JDK-8207954: Data for --release 11 In-Reply-To: <5B58942B.5090308@oracle.com> References: <5B55BF9E.1090901@oracle.com> <8bad4563-4c8d-7246-1976-4b80a6b59ce9@oracle.com> <5B58942B.5090308@oracle.com> Message-ID: <423a82e2-f8b3-cb12-6c63-adcdd97472c5@oracle.com> Yes, build changes look good. /Erik On 2018-07-25 08:15, Jan Lahoda wrote: > Thanks Erik. I've updated the code patch here: > http://cr.openjdk.java.net/~jlahoda/8207954/webrev.code.01/ > > (the data patch remains the same) > > Does this look better? > > Thanks, > ??? Jan > > On 23.7.2018 18:56, Erik Joelsson wrote: >> Hello Jan, >> >> The assignment of a non existent directory looks suspect. You should be >> able assign to an empty value using ?=. On the other hand, what it looks >> like you want to achieve is having both the open and closed value on the >> command line. Then I would just change the ?= to +=. >> >> /Erik >> >> >> On 2018-07-23 04:44, Jan Lahoda wrote: >>> Hi, >>> >>> To support --release 11 in JDK 12, historical data for JDK 11 need to >>> be added. As new attributes (NestHost and NestMembers) have been added >>> to the classfile, there also needs to be some tweaking of the tool >>> that creates the historical descriptions and the ct.sym sigfiles. >>> >>> The proposed patch has two parts: >>> -code changes, which include: >>> --update to the build scripts and the tool, so that the tool can read >>> both the open and extra/closed description of the ct.sym content, and >>> merge those (there should not be any extra/closed for JDK 11, AFAIK, >>> so this is to avoid having to update the closed part). >>> --improving the description on how to add historical data for new >>> releases, using the new source launcher >>> --adding support for the new NestHost/NestMembers attributes >>> --adding a new test which strives to fail when a new attribute is >>> added and CreateSymbols is not updated >>> http://cr.openjdk.java.net/~jlahoda/8207954/webrev.code.00/ >>> >>> -addition of the historical data: >>> http://cr.openjdk.java.net/~jlahoda/8207954/webrev.data.00/ >>> (these may need to be re-generated when the final JDK 11 is released >>> in case there are any changes, but that should be very simple) >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8207954 >>> >>> Any feedback is welcome, >>> ???? Jan >> From nezihyigitbasi at gmail.com Wed Jul 25 16:30:28 2018 From: nezihyigitbasi at gmail.com (nezih yigitbasi) Date: Wed, 25 Jul 2018 09:30:28 -0700 Subject: about Enum.values() memory allocation In-Reply-To: References: Message-ID: Thanks Ron. Yes, working around this is pretty easy. But, it is a common pattern to foreach over Enum.values(), so it would be nice if the runtime/compiler handles that in a more efficient way. Nezih Ron Shapiro , 25 Tem 2018 ?ar, 04:18 tarihinde ?unu yazd?: > It's a bit of indirection, but can for (YourEnum e : > EnumSet.allOf(YourEnum.class)) {} do the trick? It will still allocate, but > likely only one instance instead of a full array. > > On Wed, Jul 25, 2018, 5:23 AM Michael Rasmussen < > Michael.Rasmussen at roguewave.com> wrote: > >> With condy being added in Java 11, this could potentially be a use-case >> for that ? >> >> >> for (EnumType e: const(EnumType.values())) { ... } >> >> >> Or perhaps it's time to add a List valuesList(); to enum types, that >> returns an immutable List of the values? >> >> >> /Michael >> ------------------------------ >> *From:* compiler-dev on behalf >> of nezih yigitbasi >> *Sent:* 25 July 2018 08:23:57 >> *To:* compiler-dev at openjdk.java.net >> *Subject:* about Enum.values() memory allocation >> >> Hi, >> I recently noticed in our app that Enum.values() allocates a significant >> amount of memory when called in a tight loop as it clones the constant >> values array (which is probably for immutability, and I can understand >> that). I found that the same issue has been discussed back in 2012: >> http://mail.openjdk.java.net/pipermail/compiler-dev/2012-March/004210.html >> >> Are there any plans to address this issue going forward? >> >> Thanks! >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronshapiro at google.com Wed Jul 25 16:32:34 2018 From: ronshapiro at google.com (Ron Shapiro) Date: Wed, 25 Jul 2018 12:32:34 -0400 Subject: about Enum.values() memory allocation In-Reply-To: References: Message-ID: +appreduce-team maybe this is something good that AppReduce can do? On Wed, Jul 25, 2018 at 12:30 PM nezih yigitbasi wrote: > Thanks Ron. Yes, working around this is pretty easy. But, it is a common > pattern to foreach over Enum.values(), so it would be nice if the > runtime/compiler handles that in a more efficient way. > > Nezih > > Ron Shapiro , 25 Tem 2018 ?ar, 04:18 tarihinde > ?unu yazd?: > >> It's a bit of indirection, but can for (YourEnum e : >> EnumSet.allOf(YourEnum.class)) {} do the trick? It will still allocate, but >> likely only one instance instead of a full array. >> >> On Wed, Jul 25, 2018, 5:23 AM Michael Rasmussen < >> Michael.Rasmussen at roguewave.com> wrote: >> >>> With condy being added in Java 11, this could potentially be a use-case >>> for that ? >>> >>> >>> for (EnumType e: const(EnumType.values())) { ... } >>> >>> >>> Or perhaps it's time to add a List valuesList(); to enum types, that >>> returns an immutable List of the values? >>> >>> >>> /Michael >>> ------------------------------ >>> *From:* compiler-dev on behalf >>> of nezih yigitbasi >>> *Sent:* 25 July 2018 08:23:57 >>> *To:* compiler-dev at openjdk.java.net >>> *Subject:* about Enum.values() memory allocation >>> >>> Hi, >>> I recently noticed in our app that Enum.values() allocates a significant >>> amount of memory when called in a tight loop as it clones the constant >>> values array (which is probably for immutability, and I can understand >>> that). I found that the same issue has been discussed back in 2012: >>> http://mail.openjdk.java.net/pipermail/compiler-dev/2012-March/004210.html >>> >>> Are there any plans to address this issue going forward? >>> >>> Thanks! >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Wed Jul 25 17:36:12 2018 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 25 Jul 2018 10:36:12 -0700 Subject: JDK 12 RFR of JDK-8208200: Add missing periods to sentences in RoundEnvironment specs Message-ID: <91bf8fad-6c6a-0e78-b403-6ff2dcdc178b@oracle.com> Hello, Please review the patch below to fix ??? JDK-8208200: Add missing periods to sentences in RoundEnvironment specs Thanks, -Joe diff -r f4f5f961a81f src/java.compiler/share/classes/javax/annotation/processing/RoundEnvironment.java --- a/src/java.compiler/share/classes/javax/annotation/processing/RoundEnvironment.java Wed Jul 25 12:32:06 2018 -0400 +++ b/src/java.compiler/share/classes/javax/annotation/processing/RoundEnvironment.java Wed Jul 25 10:29:40 2018 -0700 @@ -1,5 +1,5 @@ ?/* - * Copyright (c) 2005, 2017, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2005, 2018, 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 @@ -86,7 +86,7 @@ ????? * created. ????? * Likewise, elements of a module are not considered included ????? * simply because a {@code module-info} file for that module was -???? * created +???? * created. ????? * ????? * @param a? annotation type being requested ????? * @return the elements annotated with the given annotation type, @@ -141,7 +141,7 @@ ????? * created. ????? * Likewise, elements of a module are not considered included ????? * simply because a {@code module-info} file for that module was -???? * created +???? * created. ????? * ????? * @param a? annotation type being requested ????? * @return the elements annotated with the given annotation type, From jparachoniak at google.com Wed Jul 25 17:45:34 2018 From: jparachoniak at google.com (Jason Parachoniak) Date: Wed, 25 Jul 2018 10:45:34 -0700 Subject: about Enum.values() memory allocation In-Reply-To: References: Message-ID: Hi Ron, Thanks for the heads up our team (michaelquigley@ speficially) is hoping to expand enum unboxing to the collection types (and similar) this quarter. We are finishing up the work on adding all of the information about signatures to our type system to make this reasonable. Making the iterator work seems reasonable. (I think we would translate that into a for (int e = 1; e < maxOrdinal+1; e++) { // 0 is for null :) // Loop code. } You should be able to follow the bug for more details. On Wed, Jul 25, 2018 at 9:32 AM Ron Shapiro wrote: > +appreduce-team maybe this is something good > that AppReduce can do? > > On Wed, Jul 25, 2018 at 12:30 PM nezih yigitbasi > wrote: > >> Thanks Ron. Yes, working around this is pretty easy. But, it is a common >> pattern to foreach over Enum.values(), so it would be nice if the >> runtime/compiler handles that in a more efficient way. >> >> Nezih >> >> Ron Shapiro , 25 Tem 2018 ?ar, 04:18 tarihinde >> ?unu yazd?: >> >>> It's a bit of indirection, but can for (YourEnum e : >>> EnumSet.allOf(YourEnum.class)) {} do the trick? It will still allocate, but >>> likely only one instance instead of a full array. >>> >>> On Wed, Jul 25, 2018, 5:23 AM Michael Rasmussen < >>> Michael.Rasmussen at roguewave.com> wrote: >>> >>>> With condy being added in Java 11, this could potentially be a use-case >>>> for that ? >>>> >>>> >>>> for (EnumType e: const(EnumType.values())) { ... } >>>> >>>> >>>> Or perhaps it's time to add a List valuesList(); to enum types, that >>>> returns an immutable List of the values? >>>> >>>> >>>> /Michael >>>> ------------------------------ >>>> *From:* compiler-dev on behalf >>>> of nezih yigitbasi >>>> *Sent:* 25 July 2018 08:23:57 >>>> *To:* compiler-dev at openjdk.java.net >>>> *Subject:* about Enum.values() memory allocation >>>> >>>> Hi, >>>> I recently noticed in our app that Enum.values() allocates a >>>> significant amount of memory when called in a tight loop as it clones the >>>> constant values array (which is probably for immutability, and I can >>>> understand that). I found that the same issue has been discussed back in >>>> 2012: >>>> http://mail.openjdk.java.net/pipermail/compiler-dev/2012-March/004210.html >>>> >>>> Are there any plans to address this issue going forward? >>>> >>>> Thanks! >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4855 bytes Desc: S/MIME Cryptographic Signature URL: From bsrbnd at gmail.com Wed Jul 25 18:04:29 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 25 Jul 2018 20:04:29 +0200 Subject: Type annotations on inner type that is an array components In-Reply-To: <5B50E520.90504@oracle.com> References: <5B50E520.90504@oracle.com> Message-ID: Hi, On 19 July 2018 at 21:23, Alex Buckley wrote: > Hi Werner, > > On 7/18/2018 4:49 PM, Werner Dietl wrote: >> >> class ArrayOfInner { >> class Inner {} >> >> @TA(1) ArrayOfInner. @TA(2) Inner oi; >> @TA(3) ArrayOfInner. @TA(4) Inner [] oia; >> @TA(5) Inner i; >> @TA(6) Inner [] ia; >> } >> >> >> Compile with javac 8 and according to javap -v field ia has the >> annotation: >> >> ArrayOfInner$Inner[] ia; >> descriptor: [LArrayOfInner$Inner; >> flags: (0x0000) >> RuntimeVisibleTypeAnnotations: >> 0: #10(#11=I#21): FIELD, location=[ARRAY, INNER_TYPE] >> >> Compile with javac 9, 10, or a recent 11 build and ia has the annotation: >> >> ArrayOfInner$Inner[] ia; >> descriptor: [LArrayOfInner$Inner; >> flags: (0x0000) >> RuntimeVisibleTypeAnnotations: >> 0: #10(#11=I#21): FIELD, location=[ARRAY] >> >> Note the missing INNER_TYPE location. >> >> I would like to argue that the Java 8 behavior was correct. > > > Sounds right. Given source code that denotes the array type "Inner[]", the > question is whether the component type of that array type is a nested type > (ArrayOfInner.Inner) or not (just Inner). Logically, yes, it's a nested > type, so the target_path item deserves an INNER_TYPE entry. > > This feels like the kind of detail we've been round and round on in the > past. That said, I don't see any mails that would have led to javac changing > how it emits target_path between 8 and 9. The closest suspect is a > compiler-dev thread from Jan/Feb 2016 -- "Bug in encoding type annotations > for supertype_targets" -- which spoke about the target_path being omitted > entirely for an annotated nested type. (JDK-8148504 was filed against 8, but > it's still open, so it can't have caused any collateral damage for a field > type's annotation.) > > Alex Doing some archaeology in 'TypeAnnotations.java' I found a suspect change-set for JDK-8031744: https://bugs.openjdk.java.net/browse/JDK-8031744 The array logic has been bundled in 'rewriteArrayType()' but the following line seems to have disappeared: http://hg.openjdk.java.net/jdk9/dev/langtools/rev/62e285806e83#l6.440 This change-set might be the culprit but I haven't verified. Bernard From joe.darcy at oracle.com Wed Jul 25 19:46:03 2018 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 25 Jul 2018 12:46:03 -0700 Subject: JDK 12 RFR of JDK-8208201: Update SourceVersion.RELEASE_11 docs to mention var for lambda param Message-ID: <0edef22e-2f64-7383-1a17-e258da2e4824@oracle.com> Hello, Please review the simple fix for ??? JDK-8208201: Update SourceVersion.RELEASE_11 docs to mention var for lambda param ??? http://cr.openjdk.java.net/~darcy/8208201.0/ Patch below. Thanks, -Joe --- old/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java 2018-07-25 12:44:12.211000999 -0700 +++ new/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java 2018-07-25 12:44:12.067000999 -0700 @@ -57,7 +57,8 @@ ????? * 1.8: lambda expressions and default methods ????? *?? 9: modules, small cleanups to 1.7 and 1.8 changes ????? *? 10: local-variable type inference (var) -???? *? 11: to be determined changes +???? *? 11: local-variable syntax for lambda parameters +???? *? 12: TBD ????? */ ???? /** @@ -169,6 +170,9 @@ ????? * The version recognized by the Java Platform, Standard Edition ????? * 11. ????? * +???? * Additions in this release include local-variable syntax for +???? * lambda parameters. +???? * ????? * @since 11 ????? */ ????? RELEASE_11, From brian.goetz at oracle.com Wed Jul 25 19:48:03 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 25 Jul 2018 15:48:03 -0400 Subject: about Enum.values() memory allocation In-Reply-To: References: Message-ID: This is essentially an API design bug; because values() returns an array, and arrays are mutable, it must copy the array every time.? Otherwise some miscreant could change the contents of this array, and other consumers of `values()` would see wrong data. There are a number of ways this could be improved, each with their pros and cons: ?- Add a new method, valuesAsList(), which would return an immutable list which could be cached and shared.? (Arguably this is what Enum::values should have done in the first place.)? Easy to add, but puts the burden on users to change their code. ?- Wait for the JVM to support frozen arrays, and then have values() return a frozen array.? This would allow sharing.? It is a behavior-incompatible change, but one we could probably justify. ?- Have the compiler recognize that the array returned from values() is confined to a scope from which it does not escape and is not mutated, and if so, perform some sort of transformation (such as the one suggested in the mail you link to.) ?- Similar to the previous, but using JIT optimizations. I'm not too hot on either the static or dynamic compiler transformation routes; I think the return-on-complexity is not that good.? The new method is the easiest, but it might look silly if the frozen arrays solution comes around soon. On 7/25/2018 1:23 AM, nezih yigitbasi wrote: > Hi, > I recently noticed in our app that Enum.values() allocates a > significant amount of memory when called in a tight loop as it clones > the constant values array (which is probably for immutability, and I > can understand that). I found that the same issue has been discussed > back in 2012: > http://mail.openjdk.java.net/pipermail/compiler-dev/2012-March/004210.html > > > Are there any plans to address this issue going forward? > > Thanks! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed Jul 25 19:51:51 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 25 Jul 2018 12:51:51 -0700 Subject: JDK 12 RFR of JDK-8208201: Update SourceVersion.RELEASE_11 docs to mention var for lambda param In-Reply-To: <0edef22e-2f64-7383-1a17-e258da2e4824@oracle.com> References: <0edef22e-2f64-7383-1a17-e258da2e4824@oracle.com> Message-ID: <5B58D4D7.8080004@oracle.com> +1 On 07/25/2018 12:46 PM, joe darcy wrote: > Hello, > > Please review the simple fix for > > JDK-8208201: Update SourceVersion.RELEASE_11 docs to mention var > for lambda param > http://cr.openjdk.java.net/~darcy/8208201.0/ > > Patch below. > > Thanks, > > -Joe > > --- > old/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java 2018-07-25 > 12:44:12.211000999 -0700 > +++ > new/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java 2018-07-25 > 12:44:12.067000999 -0700 > @@ -57,7 +57,8 @@ > * 1.8: lambda expressions and default methods > * 9: modules, small cleanups to 1.7 and 1.8 changes > * 10: local-variable type inference (var) > - * 11: to be determined changes > + * 11: local-variable syntax for lambda parameters > + * 12: TBD > */ > > /** > @@ -169,6 +170,9 @@ > * The version recognized by the Java Platform, Standard Edition > * 11. > * > + * Additions in this release include local-variable syntax for > + * lambda parameters. > + * > * @since 11 > */ > RELEASE_11, > From jonathan.gibbons at oracle.com Wed Jul 25 22:00:26 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 25 Jul 2018 15:00:26 -0700 Subject: RFR: 8208227: tools/jdeps/DotFileTest.java fails on Win-X64 Message-ID: <5B58F2FA.9040703@oracle.com> Please review a simple fix for a P2 (tier1) langtools test failure. It's Yet Another Example of using Files.delete on Windows and expecting it to work. The fix is to replace the usage with more robust library code, such as that provided in the ToolBox test-utility class. Webrev: http://cr.openjdk.java.net/~jjg/8208227/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8208227 The diff is small enough to also include inline: --- old/test/langtools/tools/jdeps/DotFileTest.java 2018-07-25 14:51:38.032332248 -0700 +++ new/test/langtools/tools/jdeps/DotFileTest.java 2018-07-25 14:51:37.644315078 -0700 @@ -27,7 +27,8 @@ * @summary Basic tests for jdeps -dotoutput option * @modules java.management * jdk.jdeps/com.sun.tools.jdeps - * @build Test p.Foo p.Bar + * @library /tools/lib + * @build toolbox.ToolBox Test p.Foo p.Bar * @run main DotFileTest */ @@ -43,6 +44,8 @@ import java.util.regex.*; import java.util.stream.Collectors; +import toolbox.ToolBox; + public class DotFileTest { public static void main(String... args) throws Exception { int errors = 0; @@ -51,9 +54,11 @@ throw new Exception(errors + " errors found"); } + final ToolBox toolBox; final Path dir; final Path dotoutput; DotFileTest() { + this.toolBox = new ToolBox(); this.dir = Paths.get(System.getProperty("test.classes", ".")); this.dotoutput = dir.resolve("dots"); } @@ -169,12 +174,10 @@ Map jdeps(List args, Path dotfile) throws IOException { if (Files.exists(dotoutput)) { - try (DirectoryStream stream = Files.newDirectoryStream(dotoutput)) { - for (Path p : stream) { - Files.delete(p); - } - } - Files.delete(dotoutput); + // delete contents of directory, then directory, + // waiting for confirmation on Windows + toolBox.cleanDirectory(dotoutput); + toolBox.deleteFiles(dotoutput); } // invoke jdeps StringWriter sw = new StringWriter(); From joe.darcy at oracle.com Wed Jul 25 23:54:02 2018 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 25 Jul 2018 16:54:02 -0700 Subject: RFR: 8208227: tools/jdeps/DotFileTest.java fails on Win-X64 In-Reply-To: <5B58F2FA.9040703@oracle.com> References: <5B58F2FA.9040703@oracle.com> Message-ID: Look fine Jon; cheers, -Joe On 7/25/2018 3:00 PM, Jonathan Gibbons wrote: > Please review a simple fix for a P2 (tier1) langtools test failure. > > It's Yet Another Example of using Files.delete on Windows and > expecting it to work. > The fix is to replace the usage with more robust library code, such as > that provided > in the ToolBox test-utility class. > > Webrev: http://cr.openjdk.java.net/~jjg/8208227/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8208227 > > The diff is small enough to also include inline: > > --- old/test/langtools/tools/jdeps/DotFileTest.java??? 2018-07-25 > 14:51:38.032332248 -0700 > +++ new/test/langtools/tools/jdeps/DotFileTest.java??? 2018-07-25 > 14:51:37.644315078 -0700 > @@ -27,7 +27,8 @@ > ? * @summary Basic tests for jdeps -dotoutput option > ? * @modules java.management > ? *????????? jdk.jdeps/com.sun.tools.jdeps > - * @build Test p.Foo p.Bar > + * @library /tools/lib > + * @build toolbox.ToolBox Test p.Foo p.Bar > ? * @run main DotFileTest > ? */ > > @@ -43,6 +44,8 @@ > ?import java.util.regex.*; > ?import java.util.stream.Collectors; > > +import toolbox.ToolBox; > + > ?public class DotFileTest { > ???? public static void main(String... args) throws Exception { > ???????? int errors = 0; > @@ -51,9 +54,11 @@ > ???????????? throw new Exception(errors + " errors found"); > ???? } > > +??? final ToolBox toolBox; > ???? final Path dir; > ???? final Path dotoutput; > ???? DotFileTest() { > +??????? this.toolBox = new ToolBox(); > ???????? this.dir = Paths.get(System.getProperty("test.classes", ".")); > ???????? this.dotoutput = dir.resolve("dots"); > ???? } > @@ -169,12 +174,10 @@ > > ???? Map jdeps(List args, Path dotfile) throws > IOException { > ???????? if (Files.exists(dotoutput)) { > -??????????? try (DirectoryStream stream = > Files.newDirectoryStream(dotoutput)) { > -??????????????? for (Path p : stream) { > -??????????????????? Files.delete(p); > -??????????????? } > -??????????? } > -??????????? Files.delete(dotoutput); > +??????????? // delete contents of directory, then directory, > +??????????? // waiting for confirmation on Windows > +??????????? toolBox.cleanDirectory(dotoutput); > +??????????? toolBox.deleteFiles(dotoutput); > ???????? } > ???????? // invoke jdeps > ???????? StringWriter sw = new StringWriter(); > > From jonathan.gibbons at oracle.com Wed Jul 25 23:55:22 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 25 Jul 2018 16:55:22 -0700 Subject: RFR: 8208227: tools/jdeps/DotFileTest.java fails on Win-X64 In-Reply-To: References: <5B58F2FA.9040703@oracle.com> Message-ID: <42bfcf09-34b9-fc9a-34bd-2156546fc0fe@oracle.com> Thanks On 7/25/18 4:54 PM, joe darcy wrote: > Look fine Jon; cheers, > > -Joe > > > On 7/25/2018 3:00 PM, Jonathan Gibbons wrote: >> Please review a simple fix for a P2 (tier1) langtools test failure. >> >> It's Yet Another Example of using Files.delete on Windows and >> expecting it to work. >> The fix is to replace the usage with more robust library code, such >> as that provided >> in the ToolBox test-utility class. >> >> Webrev: http://cr.openjdk.java.net/~jjg/8208227/webrev.00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8208227 >> >> The diff is small enough to also include inline: >> >> --- old/test/langtools/tools/jdeps/DotFileTest.java 2018-07-25 >> 14:51:38.032332248 -0700 >> +++ new/test/langtools/tools/jdeps/DotFileTest.java 2018-07-25 >> 14:51:37.644315078 -0700 >> @@ -27,7 +27,8 @@ >> ? * @summary Basic tests for jdeps -dotoutput option >> ? * @modules java.management >> ? *????????? jdk.jdeps/com.sun.tools.jdeps >> - * @build Test p.Foo p.Bar >> + * @library /tools/lib >> + * @build toolbox.ToolBox Test p.Foo p.Bar >> ? * @run main DotFileTest >> ? */ >> >> @@ -43,6 +44,8 @@ >> ?import java.util.regex.*; >> ?import java.util.stream.Collectors; >> >> +import toolbox.ToolBox; >> + >> ?public class DotFileTest { >> ???? public static void main(String... args) throws Exception { >> ???????? int errors = 0; >> @@ -51,9 +54,11 @@ >> ???????????? throw new Exception(errors + " errors found"); >> ???? } >> >> +??? final ToolBox toolBox; >> ???? final Path dir; >> ???? final Path dotoutput; >> ???? DotFileTest() { >> +??????? this.toolBox = new ToolBox(); >> ???????? this.dir = Paths.get(System.getProperty("test.classes", ".")); >> ???????? this.dotoutput = dir.resolve("dots"); >> ???? } >> @@ -169,12 +174,10 @@ >> >> ???? Map jdeps(List args, Path dotfile) throws >> IOException { >> ???????? if (Files.exists(dotoutput)) { >> -??????????? try (DirectoryStream stream = >> Files.newDirectoryStream(dotoutput)) { >> -??????????????? for (Path p : stream) { >> -??????????????????? Files.delete(p); >> -??????????????? } >> -??????????? } >> -??????????? Files.delete(dotoutput); >> +??????????? // delete contents of directory, then directory, >> +??????????? // waiting for confirmation on Windows >> +??????????? toolBox.cleanDirectory(dotoutput); >> +??????????? toolBox.deleteFiles(dotoutput); >> ???????? } >> ???????? // invoke jdeps >> ???????? StringWriter sw = new StringWriter(); >> >> > From jonathan.gibbons at oracle.com Thu Jul 26 00:15:20 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 25 Jul 2018 17:15:20 -0700 Subject: JDK 12 RFR of JDK-8208200: Add missing periods to sentences in RoundEnvironment specs In-Reply-To: <91bf8fad-6c6a-0e78-b403-6ff2dcdc178b@oracle.com> References: <91bf8fad-6c6a-0e78-b403-6ff2dcdc178b@oracle.com> Message-ID: <5B591298.6030900@oracle.com> +1 On 07/25/2018 10:36 AM, joe darcy wrote: > Hello, > > Please review the patch below to fix > > JDK-8208200: Add missing periods to sentences in RoundEnvironment > specs > > Thanks, > > -Joe > > diff -r f4f5f961a81f > src/java.compiler/share/classes/javax/annotation/processing/RoundEnvironment.java > --- > a/src/java.compiler/share/classes/javax/annotation/processing/RoundEnvironment.java > Wed Jul 25 12:32:06 2018 -0400 > +++ > b/src/java.compiler/share/classes/javax/annotation/processing/RoundEnvironment.java > Wed Jul 25 10:29:40 2018 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2005, 2017, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2005, 2018, 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 > @@ -86,7 +86,7 @@ > * created. > * Likewise, elements of a module are not considered included > * simply because a {@code module-info} file for that module was > - * created > + * created. > * > * @param a annotation type being requested > * @return the elements annotated with the given annotation type, > @@ -141,7 +141,7 @@ > * created. > * Likewise, elements of a module are not considered included > * simply because a {@code module-info} file for that module was > - * created > + * created. > * > * @param a annotation type being requested > * @return the elements annotated with the given annotation type, > From cushon at google.com Thu Jul 26 16:04:47 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Thu, 26 Jul 2018 09:04:47 -0700 Subject: RFR: JDK-8198945: Invalid RuntimeVisibleTypeAnnotations for annotation on anonymous class type parameter In-Reply-To: References: <5B36C325.7080605@oracle.com> Message-ID: On Wed, Jul 11, 2018 at 7:28 PM Werner Dietl wrote: > Maybe `copyNewClassAnnotationsToOwner` should now be renamed to > `propagateNewClassAnnotationsToOwner` > Thanks, done. JDK-8207018 seems very related to the current issue, so it would seem > worth-while to fix it at the same time. I added a comment there. > I investigated JDK-8207018. The parser currently attaches annotations on anonymous class declarations to the modifiers tree of the JCNewClass, and relies on the type annotation handling to disambiguate declaration and type annotations and move the type annotations to the super-type: http://hg.openjdk.java.net/jdk/jdk/file/220c9188db4f/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java#l2165 . The disambiguation is incorrectly moving the annotations to the inner-most type of the super-type, instead of the 'left-most' type that appeared in source. I think this logic may have been left over from an earlier iteration of type annotation implementation, since declaration annotations on anonymous class declarations are illegal, so it's safe to remove that parser logic and attach any annotations to the super-type. With that simplification the compiler still (correctly) rejects any declaration annotations that appear on anonymous class declarations. The disambiguation currently performed in TypeAnnotations becomes unnecessary, and JDK-8207018 is fixed. Here's the updated webrev: http://cr.openjdk.java.net/~cushon/8198945/webrev.04/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Thu Jul 26 17:57:29 2018 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 26 Jul 2018 10:57:29 -0700 Subject: RFR: 8208227: tools/jdeps/DotFileTest.java fails on Win-X64 In-Reply-To: <5B58F2FA.9040703@oracle.com> References: <5B58F2FA.9040703@oracle.com> Message-ID: <447fa74e-b139-10ef-eac4-17366bdffb73@oracle.com> Thanks for fixing this Jon. Looks good. Mandy On 7/25/18 3:00 PM, Jonathan Gibbons wrote: > Please review a simple fix for a P2 (tier1) langtools test failure. > > It's Yet Another Example of using Files.delete on Windows and expecting > it to work. > The fix is to replace the usage with more robust library code, such as > that provided > in the ToolBox test-utility class. > > Webrev: http://cr.openjdk.java.net/~jjg/8208227/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8208227 > > The diff is small enough to also include inline: > > --- old/test/langtools/tools/jdeps/DotFileTest.java??? 2018-07-25 > 14:51:38.032332248 -0700 > +++ new/test/langtools/tools/jdeps/DotFileTest.java??? 2018-07-25 > 14:51:37.644315078 -0700 > @@ -27,7 +27,8 @@ > ? * @summary Basic tests for jdeps -dotoutput option > ? * @modules java.management > ? *????????? jdk.jdeps/com.sun.tools.jdeps > - * @build Test p.Foo p.Bar > + * @library /tools/lib > + * @build toolbox.ToolBox Test p.Foo p.Bar > ? * @run main DotFileTest > ? */ > > @@ -43,6 +44,8 @@ > ?import java.util.regex.*; > ?import java.util.stream.Collectors; > > +import toolbox.ToolBox; > + > ?public class DotFileTest { > ???? public static void main(String... args) throws Exception { > ???????? int errors = 0; > @@ -51,9 +54,11 @@ > ???????????? throw new Exception(errors + " errors found"); > ???? } > > +??? final ToolBox toolBox; > ???? final Path dir; > ???? final Path dotoutput; > ???? DotFileTest() { > +??????? this.toolBox = new ToolBox(); > ???????? this.dir = Paths.get(System.getProperty("test.classes", ".")); > ???????? this.dotoutput = dir.resolve("dots"); > ???? } > @@ -169,12 +174,10 @@ > > ???? Map jdeps(List args, Path dotfile) throws > IOException { > ???????? if (Files.exists(dotoutput)) { > -??????????? try (DirectoryStream stream = > Files.newDirectoryStream(dotoutput)) { > -??????????????? for (Path p : stream) { > -??????????????????? Files.delete(p); > -??????????????? } > -??????????? } > -??????????? Files.delete(dotoutput); > +??????????? // delete contents of directory, then directory, > +??????????? // waiting for confirmation on Windows > +??????????? toolBox.cleanDirectory(dotoutput); > +??????????? toolBox.deleteFiles(dotoutput); > ???????? } > ???????? // invoke jdeps > ???????? StringWriter sw = new StringWriter(); > > From wdietl at gmail.com Fri Jul 27 20:25:35 2018 From: wdietl at gmail.com (Werner Dietl) Date: Fri, 27 Jul 2018 16:25:35 -0400 Subject: RFR: JDK-8198945: Invalid RuntimeVisibleTypeAnnotations for annotation on anonymous class type parameter In-Reply-To: References: <5B36C325.7080605@oracle.com> Message-ID: Hi Liam, thanks, this looks very nice! Removing all this incorrect code is great. The examples I tried worked correctly. Best, cu, WMD. On Thu, Jul 26, 2018 at 12:05 PM Liam Miller-Cushon wrote: > > On Wed, Jul 11, 2018 at 7:28 PM Werner Dietl wrote: >> >> Maybe `copyNewClassAnnotationsToOwner` should now be renamed to >> `propagateNewClassAnnotationsToOwner` > > > Thanks, done. > >> JDK-8207018 seems very related to the current issue, so it would seem >> worth-while to fix it at the same time. I added a comment there. > > > I investigated JDK-8207018. > > The parser currently attaches annotations on anonymous class declarations to the modifiers tree of the JCNewClass, and relies on the type annotation handling to disambiguate declaration and type annotations and move the type annotations to the super-type: http://hg.openjdk.java.net/jdk/jdk/file/220c9188db4f/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java#l2165. The disambiguation is incorrectly moving the annotations to the inner-most type of the super-type, instead of the 'left-most' type that appeared in source. > > I think this logic may have been left over from an earlier iteration of type annotation implementation, since declaration annotations on anonymous class declarations are illegal, so it's safe to remove that parser logic and attach any annotations to the super-type. With that simplification the compiler still (correctly) rejects any declaration annotations that appear on anonymous class declarations. The disambiguation currently performed in TypeAnnotations becomes unnecessary, and JDK-8207018 is fixed. > > Here's the updated webrev: http://cr.openjdk.java.net/~cushon/8198945/webrev.04/ -- http://www.google.com/profiles/wdietl From jonathan.gibbons at oracle.com Fri Jul 27 23:12:34 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 27 Jul 2018 16:12:34 -0700 Subject: RFR: JDK-8192963/JDK-8206986 JEP 325: Switch Expressions (Preview) In-Reply-To: <5B4E2ECA.5070805@oracle.com> References: <5B4E2ECA.5070805@oracle.com> Message-ID: <5B5BA6E2.9000208@oracle.com> CaseTree.java:52: spelling, "lables" CaseTree.java:84: "return" should be "returns". Lots of @Deprecated annotations without corresponding @deprecated javadoc tag. Should the @apiNote really be @deprecated. I also think that using @Deprecated like this is "a bit smelly", and had a discussion with Stuart "Dr Deprecator" regarding my concerns. If nothing else, assuming the feature is a success, we are setting up a precedent of marking an API as deprecated-for-removal, and then in the next release, simply removing the annotation. Attr.java:1482: ugly use of @SuppressWarnings. I understand why it is there, but it exemplifies why @Deprecated on the declaration is a bad idea. It'll be too easy to not remove these annotations in JDK 13. Attr:1825: why XXX LambdaToMethod: unnecessary new import, CaseKind Flow: unnecessary new import, CaseKind JavacParser: order of imports messages: generally, I think the text of the messages could be improved (related but not new) we should somehow identify language keywords from English text (i.e. words like `break, `case`, `continue`, `return`) 204: saying the name is both a valid label and a valid expression hints at the cause but not the error (i.e. the name is ambiguous) JCTree: inconsistent layout of annotations; inconsistent use of @Deprecated and @Deprecated(forRemoval=true) (tests) Not reviewed in detail yet. New test descriptions should use "/*" for jtreg comment block; not "/**". These are not javadoc documentation comments. New test descriptions should have @summary Presumably, we will have to change the -old.out files if the preview feature becomes standard in JDK 13. Overall, The logic is nice, but the use of @Deprecated(forRemoval=true) and resulting @SuppressWarnings really suck. I don't think the current practice is serving us well. -- Jon On 07/17/2018 11:00 AM, Jan Lahoda wrote: > Hi, > > As JEP 325 is in the proposed to target state, I thought it might be a > good idea to start a review process for the code. > > The code here strives to implement the current specification for the > Switch Expressions: > http://cr.openjdk.java.net/~gbierman/switch-expressions.html > > The current webrev is here: > http://cr.openjdk.java.net/~jlahoda/8192963/webrev.00/ > > (includes a list of new errors.) > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8192963 > https://bugs.openjdk.java.net/browse/JDK-8206986 > > CSRs: > https://bugs.openjdk.java.net/browse/JDK-8207241 > https://bugs.openjdk.java.net/browse/JDK-8207406 > > Any feedback is welcome! > > Thanks, > Jan From alex.buckley at oracle.com Fri Jul 27 23:34:30 2018 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 27 Jul 2018 16:34:30 -0700 Subject: RFR: JDK-8192963/JDK-8206986 JEP 325: Switch Expressions (Preview) In-Reply-To: <5B5BA6E2.9000208@oracle.com> References: <5B4E2ECA.5070805@oracle.com> <5B5BA6E2.9000208@oracle.com> Message-ID: <5B5BAC06.4000203@oracle.com> On 7/27/2018 4:12 PM, Jonathan Gibbons wrote: > Lots of @Deprecated annotations without corresponding @deprecated > javadoc tag. Should the @apiNote really be @deprecated. I also think > that using @Deprecated like this is "a bit smelly", and had a > discussion with Stuart "Dr Deprecator" regarding my concerns. If > nothing else, assuming the feature is a success, we are setting up a > precedent of marking an API as deprecated-for-removal, and then in > the next release, simply removing the annotation. JEP 12 is prepared to do exactly that for a Java SE API introduced in close connection with a preview feature -- see http://openjdk.java.net/jeps/12#Relationship-to-Java-SE-APIs. However, com.sun.source.tree is a JDK-supported API, not a Java SE API, so JEP 12 is silent on whether new methods in BreakTree.java and CaseTree.java should be flagged as if on the same level as a java.* API in the "Reflective" bucket. You could argue that a client of com.sun.source.tree is informed enough that they don't hand-holding about preview features. Alex From jonathan.gibbons at oracle.com Sat Jul 28 00:10:33 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 27 Jul 2018 17:10:33 -0700 Subject: RFR: JDK-8192963/JDK-8206986 JEP 325: Switch Expressions (Preview) In-Reply-To: <5B5BAC06.4000203@oracle.com> References: <5B4E2ECA.5070805@oracle.com> <5B5BA6E2.9000208@oracle.com> <5B5BAC06.4000203@oracle.com> Message-ID: <5B5BB479.6000902@oracle.com> On 07/27/2018 04:34 PM, Alex Buckley wrote: > On 7/27/2018 4:12 PM, Jonathan Gibbons wrote: >> Lots of @Deprecated annotations without corresponding @deprecated >> javadoc tag. Should the @apiNote really be @deprecated. I also think >> that using @Deprecated like this is "a bit smelly", and had a >> discussion with Stuart "Dr Deprecator" regarding my concerns. If >> nothing else, assuming the feature is a success, we are setting up a >> precedent of marking an API as deprecated-for-removal, and then in >> the next release, simply removing the annotation. > > JEP 12 is prepared to do exactly that for a Java SE API introduced in > close connection with a preview feature -- see > http://openjdk.java.net/jeps/12#Relationship-to-Java-SE-APIs. > > However, com.sun.source.tree is a JDK-supported API, not a Java SE > API, so JEP 12 is silent on whether new methods in BreakTree.java and > CaseTree.java should be flagged as if on the same level as a java.* > API in the "Reflective" bucket. You could argue that a client of > com.sun.source.tree is informed enough that they don't hand-holding > about preview features. > > Alex The anti-pattern this is setting up is at the use-site of the "preview" API. Either you have to do @SuppressWarnings("removal") at a high level, and risk suppressing more warnings than you intended, or you do it at a fine grain level, which clutters the code. Either way, you set up the risk of forgetting to remove the annotations should the feature transition from "preview" to "standard". If we stay with the prescribed practice, the review comment about not having @deprecated text still stands. From JEP 12: > When a Java compiler gives a removal warning > > for a use of a terminally deprecated API connected with a preview > feature, it is recommended that the text of the warning be customized > to indicate the connection. (This is a quality of implementation > issue; the generation of a warning is mandated, as is the ability to > suppress it in source code, but the precise text is not.) The problem with this suggestion is that there is no easy way to mechanically determine the reason for the deprecation, except an ugly heuristic that says, "if it's deprecated for removal since the current release, it's probably related to a preview feature". Uugh. It would be *slightly* better if the @apiNote was converted to @deprecated, because then we could make a general improvement to show the @deprecated text when any API that has been deprecated for removal is used. -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From wdietl at gmail.com Sun Jul 29 23:26:40 2018 From: wdietl at gmail.com (Werner Dietl) Date: Sun, 29 Jul 2018 19:26:40 -0400 Subject: Type annotations on inner type that is an array components In-Reply-To: References: <5B50E520.90504@oracle.com> Message-ID: Hi Bernard, thanks for looking into this bug! I created a bug: https://bugs.openjdk.java.net/browse/JDK-8208470 Please let me know if I missed some information. I was a bit worried about the different changes in your first patch. Based on the missing method invocation you uncovered in your second email, I made the patch below. (It includes a few whitespace and style cleanups, and removes a dead method.) Overall, `rewriteArrayType` is much easier to read after the change, I hope. How do I run tier1 tests? I looked a bit in the compiler team documentation, but didn't find current instructions. Please let me know if I should send the patch in a different format or if you have any comments! Thanks, cu, WMD. diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java @@ -50,7 +50,6 @@ import com.sun.tools.javac.code.Symbol.VarSymbol; import com.sun.tools.javac.code.Symbol.MethodSymbol; import com.sun.tools.javac.code.Type.ModuleType; -import com.sun.tools.javac.code.TypeMetadata.Entry.Kind; import com.sun.tools.javac.comp.Annotate; import com.sun.tools.javac.comp.Attr; import com.sun.tools.javac.comp.AttrContext; @@ -423,8 +422,9 @@ return type; } - if (type.hasTag(TypeTag.ARRAY)) - return rewriteArrayType((ArrayType)type, annotations, pos); + if (type.hasTag(TypeTag.ARRAY)) { + return rewriteArrayType(typetree, (ArrayType)type, annotations, pos); + } if (type.hasTag(TypeTag.TYPEVAR)) { return type.annotatedType(onlyTypeAnnotations); @@ -536,15 +536,17 @@ * * SIDE EFFECT: Update position for the annotations to be {@code pos}. */ - private Type rewriteArrayType(ArrayType type, List annotations, TypeAnnotationPosition pos) { + private Type rewriteArrayType(JCTree typetree, ArrayType type, + List annotations, TypeAnnotationPosition pos) { ArrayType tomodify = new ArrayType(type); - ArrayType res = tomodify; + final ArrayType res = tomodify; List loc = List.nil(); // peel one and update loc Type tmpType = type.elemtype; loc = loc.prepend(TypePathEntry.ARRAY); + JCTree tmpTypeTree = ((JCArrayTypeTree) typetree).elemtype; while (tmpType.hasTag(TypeTag.ARRAY)) { ArrayType arr = (ArrayType)tmpType; @@ -556,33 +558,17 @@ tmpType = arr.elemtype; loc = loc.prepend(TypePathEntry.ARRAY); + tmpTypeTree = ((JCArrayTypeTree) tmpTypeTree).elemtype; } + // Update positions + // All annotations share the same position; modify the first one. + TypeCompound tc = annotations.get(0); + tc.position = pos; + tc.position.location = loc; + // Fix innermost element type - Type elemType; - if (tmpType.getMetadata() != null) { - List tcs; - if (tmpType.getAnnotationMirrors().isEmpty()) { - tcs = annotations; - } else { - // Special case, lets prepend - tcs = annotations.appendList(tmpType.getAnnotationMirrors()); - } - elemType = tmpType.cloneWithMetadata(tmpType - .getMetadata() - .without(Kind.ANNOTATIONS) - .combine(new TypeMetadata.Annotations(tcs))); - } else { - elemType = tmpType.cloneWithMetadata(new TypeMetadata(new TypeMetadata.Annotations(annotations))); - } - tomodify.elemtype = elemType; - - // Update positions - for (TypeCompound tc : annotations) { - if (tc.position == null) - tc.position = pos; - tc.position.location = loc; - } + tomodify.elemtype = typeWithAnnotations(tmpTypeTree, tmpType, annotations, annotations, pos); return res; } @@ -707,9 +693,7 @@ List path, JCLambda currentLambda, int outer_type_index, - ListBuffer location) - { - + ListBuffer location) { // Note that p.offset is set in // com.sun.tools.javac.jvm.Gen.setTypeAnnotationPositions(int) @@ -1399,37 +1383,25 @@ scan(tree.elems); } - - private void findTypeCompoundPosition(JCTree tree, JCTree frame, List annotations) { + private void findPosition(JCTree tree, JCTree frame, List annotations) { if (!annotations.isEmpty()) { final TypeAnnotationPosition p = - resolveFrame(tree, frame, frames, currentLambda, 0, new ListBuffer<>()); - for (TypeCompound tc : annotations) - tc.position = p; - } - } - - private void findPosition(JCTree tree, JCTree frame, List annotations) { - if (!annotations.isEmpty()) - { - final TypeAnnotationPosition p = resolveFrame(tree, frame, frames, currentLambda, 0, new ListBuffer<>()); setTypeAnnotationPos(annotations, p); } } - private void setTypeAnnotationPos(List annotations, TypeAnnotationPosition position) - { + private void setTypeAnnotationPos(List annotations, TypeAnnotationPosition position) { // attribute might be null during DeferredAttr; // we will be back later. for (JCAnnotation anno : annotations) { - if (anno.attribute != null) + if (anno.attribute != null) { ((Attribute.TypeCompound) anno.attribute).position = position; + } } } - @Override public String toString() { return super.toString() + ": sigOnly: " + sigOnly; On Wed, Jul 25, 2018 at 2:04 PM B. Blaser wrote: > > Hi, > > On 19 July 2018 at 21:23, Alex Buckley wrote: > > Hi Werner, > > > > On 7/18/2018 4:49 PM, Werner Dietl wrote: > >> > >> class ArrayOfInner { > >> class Inner {} > >> > >> @TA(1) ArrayOfInner. @TA(2) Inner oi; > >> @TA(3) ArrayOfInner. @TA(4) Inner [] oia; > >> @TA(5) Inner i; > >> @TA(6) Inner [] ia; > >> } > >> > >> > >> Compile with javac 8 and according to javap -v field ia has the > >> annotation: > >> > >> ArrayOfInner$Inner[] ia; > >> descriptor: [LArrayOfInner$Inner; > >> flags: (0x0000) > >> RuntimeVisibleTypeAnnotations: > >> 0: #10(#11=I#21): FIELD, location=[ARRAY, INNER_TYPE] > >> > >> Compile with javac 9, 10, or a recent 11 build and ia has the annotation: > >> > >> ArrayOfInner$Inner[] ia; > >> descriptor: [LArrayOfInner$Inner; > >> flags: (0x0000) > >> RuntimeVisibleTypeAnnotations: > >> 0: #10(#11=I#21): FIELD, location=[ARRAY] > >> > >> Note the missing INNER_TYPE location. > >> > >> I would like to argue that the Java 8 behavior was correct. > > > > > > Sounds right. Given source code that denotes the array type "Inner[]", the > > question is whether the component type of that array type is a nested type > > (ArrayOfInner.Inner) or not (just Inner). Logically, yes, it's a nested > > type, so the target_path item deserves an INNER_TYPE entry. > > > > This feels like the kind of detail we've been round and round on in the > > past. That said, I don't see any mails that would have led to javac changing > > how it emits target_path between 8 and 9. The closest suspect is a > > compiler-dev thread from Jan/Feb 2016 -- "Bug in encoding type annotations > > for supertype_targets" -- which spoke about the target_path being omitted > > entirely for an annotated nested type. (JDK-8148504 was filed against 8, but > > it's still open, so it can't have caused any collateral damage for a field > > type's annotation.) > > > > Alex > > Doing some archaeology in 'TypeAnnotations.java' I found a suspect > change-set for JDK-8031744: > > https://bugs.openjdk.java.net/browse/JDK-8031744 > > The array logic has been bundled in 'rewriteArrayType()' but the > following line seems to have disappeared: > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/62e285806e83#l6.440 > > This change-set might be the culprit but I haven't verified. > > Bernard -- http://www.google.com/profiles/wdietl From wdietl at gmail.com Mon Jul 30 03:31:31 2018 From: wdietl at gmail.com (Werner Dietl) Date: Sun, 29 Jul 2018 23:31:31 -0400 Subject: Type annotations on inner type that is an array components In-Reply-To: References: <5B50E520.90504@oracle.com> Message-ID: Thanks to Liam for pointing out how to run the tests and, of course, I had missed a case: annotations on the array dimensions. I re-added the arrayTypeTree helper method that was removed in http://hg.openjdk.java.net/jdk9/dev/langtools/rev/62e285806e83 and tier1 tests are now clean, except for some failures that already existed for me. Updated patch below. Best, cu, WMD. diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java @@ -50,7 +50,6 @@ import com.sun.tools.javac.code.Symbol.VarSymbol; import com.sun.tools.javac.code.Symbol.MethodSymbol; import com.sun.tools.javac.code.Type.ModuleType; -import com.sun.tools.javac.code.TypeMetadata.Entry.Kind; import com.sun.tools.javac.comp.Annotate; import com.sun.tools.javac.comp.Attr; import com.sun.tools.javac.comp.AttrContext; @@ -423,8 +422,9 @@ return type; } - if (type.hasTag(TypeTag.ARRAY)) - return rewriteArrayType((ArrayType)type, annotations, pos); + if (type.hasTag(TypeTag.ARRAY)) { + return rewriteArrayType(typetree, (ArrayType)type, annotations, pos); + } if (type.hasTag(TypeTag.TYPEVAR)) { return type.annotatedType(onlyTypeAnnotations); @@ -536,15 +536,17 @@ * * SIDE EFFECT: Update position for the annotations to be {@code pos}. */ - private Type rewriteArrayType(ArrayType type, List annotations, TypeAnnotationPosition pos) { + private Type rewriteArrayType(JCTree typetree, ArrayType type, + List annotations, TypeAnnotationPosition pos) { ArrayType tomodify = new ArrayType(type); - ArrayType res = tomodify; + final ArrayType res = tomodify; List loc = List.nil(); // peel one and update loc Type tmpType = type.elemtype; loc = loc.prepend(TypePathEntry.ARRAY); + JCTree tmpTypeTree = arrayTypeTree(typetree).elemtype; while (tmpType.hasTag(TypeTag.ARRAY)) { ArrayType arr = (ArrayType)tmpType; @@ -556,37 +558,32 @@ tmpType = arr.elemtype; loc = loc.prepend(TypePathEntry.ARRAY); + tmpTypeTree = arrayTypeTree(tmpTypeTree).elemtype; } + // Update positions + // All annotations share the same position; modify the first one. + TypeCompound tc = annotations.get(0); + tc.position = pos; + tc.position.location = loc; + // Fix innermost element type - Type elemType; - if (tmpType.getMetadata() != null) { - List tcs; - if (tmpType.getAnnotationMirrors().isEmpty()) { - tcs = annotations; - } else { - // Special case, lets prepend - tcs = annotations.appendList(tmpType.getAnnotationMirrors()); - } - elemType = tmpType.cloneWithMetadata(tmpType - .getMetadata() - .without(Kind.ANNOTATIONS) - .combine(new TypeMetadata.Annotations(tcs))); - } else { - elemType = tmpType.cloneWithMetadata(new TypeMetadata(new TypeMetadata.Annotations(annotations))); - } - tomodify.elemtype = elemType; - - // Update positions - for (TypeCompound tc : annotations) { - if (tc.position == null) - tc.position = pos; - tc.position.location = loc; - } + tomodify.elemtype = typeWithAnnotations(tmpTypeTree, tmpType, annotations, annotations, pos); return res; } + private JCArrayTypeTree arrayTypeTree(JCTree typetree) { + if (typetree.getKind() == JCTree.Kind.ARRAY_TYPE) { + return (JCArrayTypeTree) typetree; + } else if (typetree.getKind() == JCTree.Kind.ANNOTATED_TYPE) { + return (JCArrayTypeTree) ((JCAnnotatedType) typetree).underlyingType; + } else { + Assert.error("Could not determine array type from type tree: " + typetree); + return null; + } + } + /** Return a copy of the first type that only differs by * inserting the annotations to the left-most/inner-most type * or the type given by stopAt. @@ -707,9 +704,7 @@ List path, JCLambda currentLambda, int outer_type_index, - ListBuffer location) - { - + ListBuffer location) { // Note that p.offset is set in // com.sun.tools.javac.jvm.Gen.setTypeAnnotationPositions(int) @@ -1399,37 +1394,25 @@ scan(tree.elems); } - - private void findTypeCompoundPosition(JCTree tree, JCTree frame, List annotations) { + private void findPosition(JCTree tree, JCTree frame, List annotations) { if (!annotations.isEmpty()) { final TypeAnnotationPosition p = - resolveFrame(tree, frame, frames, currentLambda, 0, new ListBuffer<>()); - for (TypeCompound tc : annotations) - tc.position = p; - } - } - - private void findPosition(JCTree tree, JCTree frame, List annotations) { - if (!annotations.isEmpty()) - { - final TypeAnnotationPosition p = resolveFrame(tree, frame, frames, currentLambda, 0, new ListBuffer<>()); setTypeAnnotationPos(annotations, p); } } - private void setTypeAnnotationPos(List annotations, TypeAnnotationPosition position) - { + private void setTypeAnnotationPos(List annotations, TypeAnnotationPosition position) { // attribute might be null during DeferredAttr; // we will be back later. for (JCAnnotation anno : annotations) { - if (anno.attribute != null) + if (anno.attribute != null) { ((Attribute.TypeCompound) anno.attribute).position = position; + } } } - @Override public String toString() { return super.toString() + ": sigOnly: " + sigOnly; On Sun, Jul 29, 2018 at 7:26 PM Werner Dietl wrote: > > Hi Bernard, > > thanks for looking into this bug! > > I created a bug: > https://bugs.openjdk.java.net/browse/JDK-8208470 > Please let me know if I missed some information. > > I was a bit worried about the different changes in your first patch. > Based on the missing method invocation you uncovered in your second > email, I made the patch below. > (It includes a few whitespace and style cleanups, and removes a dead method.) > Overall, `rewriteArrayType` is much easier to read after the change, I hope. > > How do I run tier1 tests? I looked a bit in the compiler team > documentation, but didn't find current instructions. > > Please let me know if I should send the patch in a different format or > if you have any comments! > > Thanks, > cu, WMD. > > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java > @@ -50,7 +50,6 @@ > import com.sun.tools.javac.code.Symbol.VarSymbol; > import com.sun.tools.javac.code.Symbol.MethodSymbol; > import com.sun.tools.javac.code.Type.ModuleType; > -import com.sun.tools.javac.code.TypeMetadata.Entry.Kind; > import com.sun.tools.javac.comp.Annotate; > import com.sun.tools.javac.comp.Attr; > import com.sun.tools.javac.comp.AttrContext; > @@ -423,8 +422,9 @@ > return type; > } > > - if (type.hasTag(TypeTag.ARRAY)) > - return rewriteArrayType((ArrayType)type, annotations, pos); > + if (type.hasTag(TypeTag.ARRAY)) { > + return rewriteArrayType(typetree, (ArrayType)type, > annotations, pos); > + } > > if (type.hasTag(TypeTag.TYPEVAR)) { > return type.annotatedType(onlyTypeAnnotations); > @@ -536,15 +536,17 @@ > * > * SIDE EFFECT: Update position for the annotations to be {@code pos}. > */ > - private Type rewriteArrayType(ArrayType type, > List annotations, TypeAnnotationPosition pos) { > + private Type rewriteArrayType(JCTree typetree, ArrayType type, > + List annotations, TypeAnnotationPosition pos) { > ArrayType tomodify = new ArrayType(type); > - ArrayType res = tomodify; > + final ArrayType res = tomodify; > > List loc = List.nil(); > > // peel one and update loc > Type tmpType = type.elemtype; > loc = loc.prepend(TypePathEntry.ARRAY); > + JCTree tmpTypeTree = ((JCArrayTypeTree) typetree).elemtype; > > while (tmpType.hasTag(TypeTag.ARRAY)) { > ArrayType arr = (ArrayType)tmpType; > @@ -556,33 +558,17 @@ > > tmpType = arr.elemtype; > loc = loc.prepend(TypePathEntry.ARRAY); > + tmpTypeTree = ((JCArrayTypeTree) tmpTypeTree).elemtype; > } > > + // Update positions > + // All annotations share the same position; modify the first one. > + TypeCompound tc = annotations.get(0); > + tc.position = pos; > + tc.position.location = loc; > + > // Fix innermost element type > - Type elemType; > - if (tmpType.getMetadata() != null) { > - List tcs; > - if (tmpType.getAnnotationMirrors().isEmpty()) { > - tcs = annotations; > - } else { > - // Special case, lets prepend > - tcs = > annotations.appendList(tmpType.getAnnotationMirrors()); > - } > - elemType = tmpType.cloneWithMetadata(tmpType > - .getMetadata() > - .without(Kind.ANNOTATIONS) > - .combine(new TypeMetadata.Annotations(tcs))); > - } else { > - elemType = tmpType.cloneWithMetadata(new > TypeMetadata(new TypeMetadata.Annotations(annotations))); > - } > - tomodify.elemtype = elemType; > - > - // Update positions > - for (TypeCompound tc : annotations) { > - if (tc.position == null) > - tc.position = pos; > - tc.position.location = loc; > - } > + tomodify.elemtype = typeWithAnnotations(tmpTypeTree, > tmpType, annotations, annotations, pos); > > return res; > } > @@ -707,9 +693,7 @@ > List path, > JCLambda currentLambda, > int outer_type_index, > - ListBuffer location) > - { > - > + ListBuffer location) { > // Note that p.offset is set in > // com.sun.tools.javac.jvm.Gen.setTypeAnnotationPositions(int) > > @@ -1399,37 +1383,25 @@ > scan(tree.elems); > } > > - > - private void findTypeCompoundPosition(JCTree tree, JCTree > frame, List annotations) { > + private void findPosition(JCTree tree, JCTree frame, > List annotations) { > if (!annotations.isEmpty()) { > final TypeAnnotationPosition p = > - resolveFrame(tree, frame, frames, > currentLambda, 0, new ListBuffer<>()); > - for (TypeCompound tc : annotations) > - tc.position = p; > - } > - } > - > - private void findPosition(JCTree tree, JCTree frame, > List annotations) { > - if (!annotations.isEmpty()) > - { > - final TypeAnnotationPosition p = > resolveFrame(tree, frame, frames, currentLambda, > 0, new ListBuffer<>()); > > setTypeAnnotationPos(annotations, p); > } > } > > - private void setTypeAnnotationPos(List > annotations, TypeAnnotationPosition position) > - { > + private void setTypeAnnotationPos(List > annotations, TypeAnnotationPosition position) { > // attribute might be null during DeferredAttr; > // we will be back later. > for (JCAnnotation anno : annotations) { > - if (anno.attribute != null) > + if (anno.attribute != null) { > ((Attribute.TypeCompound) > anno.attribute).position = position; > + } > } > } > > - > @Override > public String toString() { > return super.toString() + ": sigOnly: " + sigOnly; > On Wed, Jul 25, 2018 at 2:04 PM B. Blaser wrote: > > > > Hi, > > > > On 19 July 2018 at 21:23, Alex Buckley wrote: > > > Hi Werner, > > > > > > On 7/18/2018 4:49 PM, Werner Dietl wrote: > > >> > > >> class ArrayOfInner { > > >> class Inner {} > > >> > > >> @TA(1) ArrayOfInner. @TA(2) Inner oi; > > >> @TA(3) ArrayOfInner. @TA(4) Inner [] oia; > > >> @TA(5) Inner i; > > >> @TA(6) Inner [] ia; > > >> } > > >> > > >> > > >> Compile with javac 8 and according to javap -v field ia has the > > >> annotation: > > >> > > >> ArrayOfInner$Inner[] ia; > > >> descriptor: [LArrayOfInner$Inner; > > >> flags: (0x0000) > > >> RuntimeVisibleTypeAnnotations: > > >> 0: #10(#11=I#21): FIELD, location=[ARRAY, INNER_TYPE] > > >> > > >> Compile with javac 9, 10, or a recent 11 build and ia has the annotation: > > >> > > >> ArrayOfInner$Inner[] ia; > > >> descriptor: [LArrayOfInner$Inner; > > >> flags: (0x0000) > > >> RuntimeVisibleTypeAnnotations: > > >> 0: #10(#11=I#21): FIELD, location=[ARRAY] > > >> > > >> Note the missing INNER_TYPE location. > > >> > > >> I would like to argue that the Java 8 behavior was correct. > > > > > > > > > Sounds right. Given source code that denotes the array type "Inner[]", the > > > question is whether the component type of that array type is a nested type > > > (ArrayOfInner.Inner) or not (just Inner). Logically, yes, it's a nested > > > type, so the target_path item deserves an INNER_TYPE entry. > > > > > > This feels like the kind of detail we've been round and round on in the > > > past. That said, I don't see any mails that would have led to javac changing > > > how it emits target_path between 8 and 9. The closest suspect is a > > > compiler-dev thread from Jan/Feb 2016 -- "Bug in encoding type annotations > > > for supertype_targets" -- which spoke about the target_path being omitted > > > entirely for an annotated nested type. (JDK-8148504 was filed against 8, but > > > it's still open, so it can't have caused any collateral damage for a field > > > type's annotation.) > > > > > > Alex > > > > Doing some archaeology in 'TypeAnnotations.java' I found a suspect > > change-set for JDK-8031744: > > > > https://bugs.openjdk.java.net/browse/JDK-8031744 > > > > The array logic has been bundled in 'rewriteArrayType()' but the > > following line seems to have disappeared: > > > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/62e285806e83#l6.440 > > > > This change-set might be the culprit but I haven't verified. > > > > Bernard > > > > -- > http://www.google.com/profiles/wdietl -- http://www.google.com/profiles/wdietl From bsrbnd at gmail.com Mon Jul 30 10:50:09 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 30 Jul 2018 12:50:09 +0200 Subject: Type annotations on inner type that is an array components In-Reply-To: References: <5B50E520.90504@oracle.com> Message-ID: Hi Werner, On 30 July 2018 at 05:31, Werner Dietl wrote: > Thanks to Liam for pointing out how to run the tests and, of course, I > had missed a case: annotations on the array dimensions. > I re-added the arrayTypeTree helper method that was removed in > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/62e285806e83 > and tier1 tests are now clean, except for some failures that already > existed for me. > Updated patch below. I discovered the suspicious change-set after having submitted the first patch as initial direction to search, but I was also septic that it might be the final solution... I'll take a look at your suggestion and give you my feedback soon. Maybe examining existing tests ([1],[2],...) and adding missing cases would be interesting too? Thanks! Bernard [1] http://hg.openjdk.java.net/jdk/jdk/file/b7a307084247/test/langtools/tools/javac/annotations/typeAnnotations/referenceinfos [2] http://hg.openjdk.java.net/jdk/jdk/file/b7a307084247/test/langtools/tools/javac/annotations/typeAnnotations/referenceinfos/Fields.java > Best, > cu, WMD. > > > > -- > http://www.google.com/profiles/wdietl From jan.lahoda at oracle.com Mon Jul 30 12:32:22 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 30 Jul 2018 14:32:22 +0200 Subject: RFR: JDK-8192963/JDK-8206986 JEP 325: Switch Expressions (Preview) In-Reply-To: <5B5BAC06.4000203@oracle.com> References: <5B4E2ECA.5070805@oracle.com> <5B5BA6E2.9000208@oracle.com> <5B5BAC06.4000203@oracle.com> Message-ID: <5B5F0556.4010208@oracle.com> On 28.7.2018 01:34, Alex Buckley wrote: > On 7/27/2018 4:12 PM, Jonathan Gibbons wrote: >> Lots of @Deprecated annotations without corresponding @deprecated >> javadoc tag. Should the @apiNote really be @deprecated. I also think >> that using @Deprecated like this is "a bit smelly", and had a >> discussion with Stuart "Dr Deprecator" regarding my concerns. If >> nothing else, assuming the feature is a success, we are setting up a >> precedent of marking an API as deprecated-for-removal, and then in >> the next release, simply removing the annotation. > > JEP 12 is prepared to do exactly that for a Java SE API introduced in > close connection with a preview feature -- see > http://openjdk.java.net/jeps/12#Relationship-to-Java-SE-APIs. > > However, com.sun.source.tree is a JDK-supported API, not a Java SE API, > so JEP 12 is silent on whether new methods in BreakTree.java and > CaseTree.java should be flagged as if on the same level as a java.* API > in the "Reflective" bucket. You could argue that a client of > com.sun.source.tree is informed enough that they don't hand-holding > about preview features. One of my goals here was to keep the approach consistent and predictable between the API kinds. Even though JEP 12 does not speak about the com.sun.source APIs, using the same set of rules for both com.sun.source and javax.lang.model seems sensible to me. Jan > > Alex From maurizio.cimadamore at oracle.com Mon Jul 30 14:25:35 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 30 Jul 2018 15:25:35 +0100 Subject: RFR JDK-8206142: type inference: javac is incorrectly applying capture conversion during incorporation In-Reply-To: <9bd84725-d989-8514-db6b-fd844c85ca11@oracle.com> References: <4ac51895-1d0b-9e1a-c0b2-b5d9a368041b@oracle.com> <9bd84725-d989-8514-db6b-fd844c85ca11@oracle.com> Message-ID: <7a455c5f-6bb2-b3fd-584c-a827543a7d3f@oracle.com> Hi Vicente, while I agree that the program in JDK-8206142 exposes an issues with a spurious capture being performed by javac, and, while I agree that, in that case, we can do without the capyure (both the source and the target of the test are some B<...>), in the more general case where source and target are at different heights, you need to recurse to supertype and, hence, you need capture. So, I'm afraid that with this we will potentially introduce compatibility issues, w/o fully resolving the underlying issue, which is described by this spec issue which Dan filed while ago: https://bugs.openjdk.java.net/browse/JDK-8016196 Maybe we should wait on this one? Maurizio On 23/07/18 14:22, Vicente Romero wrote: > > > On 07/21/2018 09:49 AM, B. Blaser wrote: >> Hi Vicente, >> >> On 20 July 2018 at 22:27, Vicente Romero >> wrote: >>> Hi all, >>> >>> Please review the patch to fix [1] at [2]. The fix is putting javac >>> in sync >>> with the spec by not applying capture conversion during incorporation. >>> >>> Thanks, >>> Vicente >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8206142 >>> [2] http://cr.openjdk.java.net/~vromero/8206142/webrev.00/jdk.dev.patch >> It's hard to measure the potential side-effects of this fix, > > yes, I'm also worried about the possible side effects. I agree that > more discussion will be needed, > >> ? but it >> seems good to me even if you'll probably need another review. >> Maybe, I'd rewrite it as next to avoid creating a new method? >> >> Thanks, >> Bernard > > Thanks, > Vicente > >> >> >> diff -r b0fcf59be391 >> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java >> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java >> ??????? Fri Jul 20 14:48:41 2018 -0700 >> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java >> ??????? Sat Jul 21 14:33:05 2018 +0200 >> @@ -1003,24 +1003,24 @@ >> ?????? * Is t an unchecked subtype of s? >> ?????? */ >> ????? public boolean isSubtypeUnchecked(Type t, Type s, Warner warn) { >> -??????? boolean result = isSubtypeUncheckedInternal(t, s, true, warn); >> +??????? boolean result = isSubtypeUnchecked(t, s, true, warn); >> ????????? if (result) { >> ????????????? checkUnsafeVarargsConversion(t, s, warn); >> ????????? } >> ????????? return result; >> ????? } >> ????? //where >> -??????? private boolean isSubtypeUncheckedInternal(Type t, Type s, >> boolean capture, Warner warn) { >> +??????? public boolean isSubtypeUnchecked(Type t, Type s, boolean >> capture, Warner warn) { >> ????????????? if (t.hasTag(ARRAY) && s.hasTag(ARRAY)) { >> ????????????????? if (((ArrayType)t).elemtype.isPrimitive()) { >> ????????????????????? return isSameType(elemtype(t), elemtype(s)); >> ????????????????? } else { >> -??????????????????? return isSubtypeUncheckedInternal(elemtype(t), >> elemtype(s), false, warn); >> +??????????????????? return isSubtypeUnchecked(elemtype(t), >> elemtype(s), false, warn); >> ????????????????? } >> ????????????? } else if (isSubtype(t, s, capture)) { >> ????????????????? return true; >> ????????????? } else if (t.hasTag(TYPEVAR)) { >> -??????????????? return isSubtypeUncheckedInternal(t.getUpperBound(), >> s, false, warn); >> +??????????????? return isSubtypeUnchecked(t.getUpperBound(), s, >> false, warn); >> ????????????? } else if (!s.isRaw()) { >> ????????????????? Type t2 = asSuper(t, s.tsym); >> ????????????????? if (t2 != null && t2.isRaw()) { >> diff -r b0fcf59be391 >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java >> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java >> ??????? Fri Jul 20 14:48:41 2018 -0700 >> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java >> ??????? Sat Jul 21 14:33:05 2018 +0200 >> @@ -1180,7 +1180,7 @@ >> ????????? IS_SUBTYPE() { >> ????????????? @Override >> ????????????? boolean apply(Type op1, Type op2, Warner warn, Types >> types) { >> -??????????????? return types.isSubtypeUnchecked(op1, op2, warn); >> +??????????????? return types.isSubtypeUnchecked(op1, op2, false, warn); >> ????????????? } >> ????????? }, >> ????????? IS_SAME_TYPE() { > From bsrbnd at gmail.com Mon Jul 30 16:23:49 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 30 Jul 2018 18:23:49 +0200 Subject: Type annotations on inner type that is an array components In-Reply-To: References: <5B50E520.90504@oracle.com> Message-ID: On 30 July 2018 at 12:50, B. Blaser wrote: > Hi Werner, > > On 30 July 2018 at 05:31, Werner Dietl wrote: >> Thanks to Liam for pointing out how to run the tests and, of course, I >> had missed a case: annotations on the array dimensions. >> I re-added the arrayTypeTree helper method that was removed in >> http://hg.openjdk.java.net/jdk9/dev/langtools/rev/62e285806e83 >> and tier1 tests are now clean, except for some failures that already >> existed for me. >> Updated patch below. > > I discovered the suspicious change-set after having submitted the > first patch as initial direction to search, but I was also septic that > it might be the final solution... > I'll take a look at your suggestion and give you my feedback soon. > > Maybe examining existing tests ([1],[2],...) and adding missing cases > would be interesting too? I've attached your latest patch updated as follows: * removed the unnecessary loop on array elements (replaced by recursion on 'typeWithAnnotations()') * added the 'onlyTypeAnnotations' parameter to 'rewriteArrayType()' * dropped cosmetic changes (indentation & dead code removal) which can be later reinstated * added some test cases Tier1 is OK (without any failure) but note the different output for 'T6747671.java' which probably means that the fix has side-effects. What do you think? Bernard > Thanks! > Bernard > > [1] http://hg.openjdk.java.net/jdk/jdk/file/b7a307084247/test/langtools/tools/javac/annotations/typeAnnotations/referenceinfos > [2] http://hg.openjdk.java.net/jdk/jdk/file/b7a307084247/test/langtools/tools/javac/annotations/typeAnnotations/referenceinfos/Fields.java > >> Best, >> cu, WMD. >> >> >> >> -- >> http://www.google.com/profiles/wdietl -------------- next part -------------- A non-text attachment was scrubbed... Name: jdk8208470b.patch Type: text/x-patch Size: 7047 bytes Desc: not available URL: From maurizio.cimadamore at oracle.com Mon Jul 30 17:50:52 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 30 Jul 2018 18:50:52 +0100 Subject: RFR 8208524: IntelliJ support broken since 2018.2 Message-ID: <6612fe8f-5dea-1f0f-df6f-f76572c0535b@oracle.com> Hi, support for IntelliJ projects (both langtools specific and JDK-wide) is broken by a fix in the latest IntelliJ 2018.2, which prevents parsing of ant files inside the .idea configuration folder. The solution is to copy the ant file into some sub-folder of the build folder (I've called it .idea-support for now), which fixes the issue. I have more changes in the pipeline to improve the IntelliJ support, including one which fixes the -o flag (e.g. JDK-8180794) - that's to say that I know that this patch adds more assumptions on the location of the build folder, but we have plans to remove such assumptions in due course. In the short term, priority is to keep support working. Webrev: http://cr.openjdk.java.net/~mcimadamore/8208524/ Cheers Maurizio From vicente.romero at oracle.com Mon Jul 30 18:00:07 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 30 Jul 2018 11:00:07 -0700 Subject: RFR JDK-8206142: type inference: javac is incorrectly applying capture conversion during incorporation In-Reply-To: <7a455c5f-6bb2-b3fd-584c-a827543a7d3f@oracle.com> References: <4ac51895-1d0b-9e1a-c0b2-b5d9a368041b@oracle.com> <9bd84725-d989-8514-db6b-fd844c85ca11@oracle.com> <7a455c5f-6bb2-b3fd-584c-a827543a7d3f@oracle.com> Message-ID: <33e3c937-38b1-f935-7819-86b12aca848a@oracle.com> On 07/30/2018 07:25 AM, Maurizio Cimadamore wrote: > Hi Vicente, > while I agree that the program in JDK-8206142 exposes an issues with a > spurious capture being performed by javac, and, while I agree that, in > that case, we can do without the capyure (both the source and the > target of the test are some B<...>), in the more general case where > source and target are at different heights, you need to recurse to > supertype and, hence, you need capture. > > So, I'm afraid that with this we will potentially introduce > compatibility issues, w/o fully resolving the underlying issue, which > is described by this spec issue which Dan filed while ago: > > https://bugs.openjdk.java.net/browse/JDK-8016196 > > Maybe we should wait on this one? not sure here, it could be a good idea to wait but usually these spec issues take some time to be sorted out, so we could pause now and push this fix later if more users complain about this issue. > > Maurizio Vicente > > > > On 23/07/18 14:22, Vicente Romero wrote: >> >> >> On 07/21/2018 09:49 AM, B. Blaser wrote: >>> Hi Vicente, >>> >>> On 20 July 2018 at 22:27, Vicente Romero >>> wrote: >>>> Hi all, >>>> >>>> Please review the patch to fix [1] at [2]. The fix is putting javac >>>> in sync >>>> with the spec by not applying capture conversion during incorporation. >>>> >>>> Thanks, >>>> Vicente >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8206142 >>>> [2] >>>> http://cr.openjdk.java.net/~vromero/8206142/webrev.00/jdk.dev.patch >>> It's hard to measure the potential side-effects of this fix, >> >> yes, I'm also worried about the possible side effects. I agree that >> more discussion will be needed, >> >>> ? but it >>> seems good to me even if you'll probably need another review. >>> Maybe, I'd rewrite it as next to avoid creating a new method? >>> >>> Thanks, >>> Bernard >> >> Thanks, >> Vicente >> >>> >>> >>> diff -r b0fcf59be391 >>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java >>> --- >>> a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java >>> ??????? Fri Jul 20 14:48:41 2018 -0700 >>> +++ >>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java >>> ??????? Sat Jul 21 14:33:05 2018 +0200 >>> @@ -1003,24 +1003,24 @@ >>> ?????? * Is t an unchecked subtype of s? >>> ?????? */ >>> ????? public boolean isSubtypeUnchecked(Type t, Type s, Warner warn) { >>> -??????? boolean result = isSubtypeUncheckedInternal(t, s, true, warn); >>> +??????? boolean result = isSubtypeUnchecked(t, s, true, warn); >>> ????????? if (result) { >>> ????????????? checkUnsafeVarargsConversion(t, s, warn); >>> ????????? } >>> ????????? return result; >>> ????? } >>> ????? //where >>> -??????? private boolean isSubtypeUncheckedInternal(Type t, Type s, >>> boolean capture, Warner warn) { >>> +??????? public boolean isSubtypeUnchecked(Type t, Type s, boolean >>> capture, Warner warn) { >>> ????????????? if (t.hasTag(ARRAY) && s.hasTag(ARRAY)) { >>> ????????????????? if (((ArrayType)t).elemtype.isPrimitive()) { >>> ????????????????????? return isSameType(elemtype(t), elemtype(s)); >>> ????????????????? } else { >>> -??????????????????? return isSubtypeUncheckedInternal(elemtype(t), >>> elemtype(s), false, warn); >>> +??????????????????? return isSubtypeUnchecked(elemtype(t), >>> elemtype(s), false, warn); >>> ????????????????? } >>> ????????????? } else if (isSubtype(t, s, capture)) { >>> ????????????????? return true; >>> ????????????? } else if (t.hasTag(TYPEVAR)) { >>> -??????????????? return isSubtypeUncheckedInternal(t.getUpperBound(), >>> s, false, warn); >>> +??????????????? return isSubtypeUnchecked(t.getUpperBound(), s, >>> false, warn); >>> ????????????? } else if (!s.isRaw()) { >>> ????????????????? Type t2 = asSuper(t, s.tsym); >>> ????????????????? if (t2 != null && t2.isRaw()) { >>> diff -r b0fcf59be391 >>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java >>> --- >>> a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java >>> ??????? Fri Jul 20 14:48:41 2018 -0700 >>> +++ >>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java >>> ??????? Sat Jul 21 14:33:05 2018 +0200 >>> @@ -1180,7 +1180,7 @@ >>> ????????? IS_SUBTYPE() { >>> ????????????? @Override >>> ????????????? boolean apply(Type op1, Type op2, Warner warn, Types >>> types) { >>> -??????????????? return types.isSubtypeUnchecked(op1, op2, warn); >>> +??????????????? return types.isSubtypeUnchecked(op1, op2, false, >>> warn); >>> ????????????? } >>> ????????? }, >>> ????????? IS_SAME_TYPE() { >> > From wdietl at gmail.com Mon Jul 30 18:19:23 2018 From: wdietl at gmail.com (Werner Dietl) Date: Mon, 30 Jul 2018 14:19:23 -0400 Subject: Type annotations on inner type that is an array components In-Reply-To: References: <5B50E520.90504@oracle.com> Message-ID: In this part: // Update first position for (TypeCompound tc : annotations) { if (tc.position == null) tc.position = pos; tc.position.location = tc.position.location.prepend(TypePathEntry.ARRAY); I think you can simplify to: TypeCompound tc = annotations.get(0); tc.position = pos; tc.position.location = tc.position.location.prepend(TypePathEntry.ARRAY); You know that annotations is non-empty, so there is always at least the first element that you need to update. I'm not sure why the null check was there. Even if the position is already non-null, don't we want to set it to the position we determined? Should we change `arrayTypeTree` to `arrayTypeTreeElement` or some such and put the `.elemtype` access in the helper method? The change to T6747671.out seems ok to me - the error message now contains the annotation on the type use. Thanks for adding the test cases! Best, cu, WMD. On Mon, Jul 30, 2018 at 12:23 PM B. Blaser wrote: > > On 30 July 2018 at 12:50, B. Blaser wrote: > > Hi Werner, > > > > On 30 July 2018 at 05:31, Werner Dietl wrote: > >> Thanks to Liam for pointing out how to run the tests and, of course, I > >> had missed a case: annotations on the array dimensions. > >> I re-added the arrayTypeTree helper method that was removed in > >> http://hg.openjdk.java.net/jdk9/dev/langtools/rev/62e285806e83 > >> and tier1 tests are now clean, except for some failures that already > >> existed for me. > >> Updated patch below. > > > > I discovered the suspicious change-set after having submitted the > > first patch as initial direction to search, but I was also septic that > > it might be the final solution... > > I'll take a look at your suggestion and give you my feedback soon. > > > > Maybe examining existing tests ([1],[2],...) and adding missing cases > > would be interesting too? > > I've attached your latest patch updated as follows: > * removed the unnecessary loop on array elements (replaced by > recursion on 'typeWithAnnotations()') > * added the 'onlyTypeAnnotations' parameter to 'rewriteArrayType()' > * dropped cosmetic changes (indentation & dead code removal) which can > be later reinstated > * added some test cases > > Tier1 is OK (without any failure) but note the different output for > 'T6747671.java' which probably means that the fix has side-effects. > > What do you think? > > Bernard > > > > Thanks! > > Bernard > > > > [1] http://hg.openjdk.java.net/jdk/jdk/file/b7a307084247/test/langtools/tools/javac/annotations/typeAnnotations/referenceinfos > > [2] http://hg.openjdk.java.net/jdk/jdk/file/b7a307084247/test/langtools/tools/javac/annotations/typeAnnotations/referenceinfos/Fields.java > > > >> Best, > >> cu, WMD. > >> > >> > >> > >> -- > >> http://www.google.com/profiles/wdietl -- http://www.google.com/profiles/wdietl From maurizio.cimadamore at oracle.com Mon Jul 30 20:20:18 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 30 Jul 2018 21:20:18 +0100 Subject: RFR JDK-8206142: type inference: javac is incorrectly applying capture conversion during incorporation In-Reply-To: <33e3c937-38b1-f935-7819-86b12aca848a@oracle.com> References: <4ac51895-1d0b-9e1a-c0b2-b5d9a368041b@oracle.com> <9bd84725-d989-8514-db6b-fd844c85ca11@oracle.com> <7a455c5f-6bb2-b3fd-584c-a827543a7d3f@oracle.com> <33e3c937-38b1-f935-7819-86b12aca848a@oracle.com> Message-ID: <4f300578-3313-3742-d607-7d7f060ee66d@oracle.com> On 30/07/18 19:00, Vicente Romero wrote: > > > On 07/30/2018 07:25 AM, Maurizio Cimadamore wrote: >> Hi Vicente, >> while I agree that the program in JDK-8206142 exposes an issues with >> a spurious capture being performed by javac, and, while I agree that, >> in that case, we can do without the capyure (both the source and the >> target of the test are some B<...>), in the more general case where >> source and target are at different heights, you need to recurse to >> supertype and, hence, you need capture. >> >> So, I'm afraid that with this we will potentially introduce >> compatibility issues, w/o fully resolving the underlying issue, which >> is described by this spec issue which Dan filed while ago: >> >> https://bugs.openjdk.java.net/browse/JDK-8016196 >> >> Maybe we should wait on this one? > > not sure here, it could be a good idea to wait but usually these spec > issues take some time to be sorted out, so we could pause now and push > this fix later if more users complain about this issue. Right. But the point I was trying to make is that, if you never capture (as in this patch), when you have a subtyping test like this: A <: B where A <: B> you end up with the following, non-sensical subtyping assertion: B <: B So, javac always applies capture conversion (even at risk of incompatibilities like the one in this issue) in order to remain on a safe path, from a type-wellformedness perspective. Maurizio > >> >> Maurizio > > Vicente > >> >> >> >> On 23/07/18 14:22, Vicente Romero wrote: >>> >>> >>> On 07/21/2018 09:49 AM, B. Blaser wrote: >>>> Hi Vicente, >>>> >>>> On 20 July 2018 at 22:27, Vicente Romero >>>> wrote: >>>>> Hi all, >>>>> >>>>> Please review the patch to fix [1] at [2]. The fix is putting >>>>> javac in sync >>>>> with the spec by not applying capture conversion during >>>>> incorporation. >>>>> >>>>> Thanks, >>>>> Vicente >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8206142 >>>>> [2] >>>>> http://cr.openjdk.java.net/~vromero/8206142/webrev.00/jdk.dev.patch >>>> It's hard to measure the potential side-effects of this fix, >>> >>> yes, I'm also worried about the possible side effects. I agree that >>> more discussion will be needed, >>> >>>> ? but it >>>> seems good to me even if you'll probably need another review. >>>> Maybe, I'd rewrite it as next to avoid creating a new method? >>>> >>>> Thanks, >>>> Bernard >>> >>> Thanks, >>> Vicente >>> >>>> >>>> >>>> diff -r b0fcf59be391 >>>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java >>>> --- >>>> a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java >>>> ??????? Fri Jul 20 14:48:41 2018 -0700 >>>> +++ >>>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java >>>> ??????? Sat Jul 21 14:33:05 2018 +0200 >>>> @@ -1003,24 +1003,24 @@ >>>> ?????? * Is t an unchecked subtype of s? >>>> ?????? */ >>>> ????? public boolean isSubtypeUnchecked(Type t, Type s, Warner warn) { >>>> -??????? boolean result = isSubtypeUncheckedInternal(t, s, true, >>>> warn); >>>> +??????? boolean result = isSubtypeUnchecked(t, s, true, warn); >>>> ????????? if (result) { >>>> ????????????? checkUnsafeVarargsConversion(t, s, warn); >>>> ????????? } >>>> ????????? return result; >>>> ????? } >>>> ????? //where >>>> -??????? private boolean isSubtypeUncheckedInternal(Type t, Type s, >>>> boolean capture, Warner warn) { >>>> +??????? public boolean isSubtypeUnchecked(Type t, Type s, boolean >>>> capture, Warner warn) { >>>> ????????????? if (t.hasTag(ARRAY) && s.hasTag(ARRAY)) { >>>> ????????????????? if (((ArrayType)t).elemtype.isPrimitive()) { >>>> ????????????????????? return isSameType(elemtype(t), elemtype(s)); >>>> ????????????????? } else { >>>> -??????????????????? return isSubtypeUncheckedInternal(elemtype(t), >>>> elemtype(s), false, warn); >>>> +??????????????????? return isSubtypeUnchecked(elemtype(t), >>>> elemtype(s), false, warn); >>>> ????????????????? } >>>> ????????????? } else if (isSubtype(t, s, capture)) { >>>> ????????????????? return true; >>>> ????????????? } else if (t.hasTag(TYPEVAR)) { >>>> -??????????????? return isSubtypeUncheckedInternal(t.getUpperBound(), >>>> s, false, warn); >>>> +??????????????? return isSubtypeUnchecked(t.getUpperBound(), s, >>>> false, warn); >>>> ????????????? } else if (!s.isRaw()) { >>>> ????????????????? Type t2 = asSuper(t, s.tsym); >>>> ????????????????? if (t2 != null && t2.isRaw()) { >>>> diff -r b0fcf59be391 >>>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java >>>> --- >>>> a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java >>>> ??????? Fri Jul 20 14:48:41 2018 -0700 >>>> +++ >>>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java >>>> ??????? Sat Jul 21 14:33:05 2018 +0200 >>>> @@ -1180,7 +1180,7 @@ >>>> ????????? IS_SUBTYPE() { >>>> ????????????? @Override >>>> ????????????? boolean apply(Type op1, Type op2, Warner warn, Types >>>> types) { >>>> -??????????????? return types.isSubtypeUnchecked(op1, op2, warn); >>>> +??????????????? return types.isSubtypeUnchecked(op1, op2, false, >>>> warn); >>>> ????????????? } >>>> ????????? }, >>>> ????????? IS_SAME_TYPE() { >>> >> > From bsrbnd at gmail.com Mon Jul 30 21:59:33 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 30 Jul 2018 23:59:33 +0200 Subject: Type annotations on inner type that is an array components In-Reply-To: References: <5B50E520.90504@oracle.com> Message-ID: On 30 July 2018 at 20:19, Werner Dietl wrote: > In this part: > > // Update first position > for (TypeCompound tc : annotations) { > if (tc.position == null) > tc.position = pos; > tc.position.location = > tc.position.location.prepend(TypePathEntry.ARRAY); > > I think you can simplify to: > > TypeCompound tc = annotations.get(0); > tc.position = pos; > tc.position.location = tc.position.location.prepend(TypePathEntry.ARRAY); > > You know that annotations is non-empty, so there is always at least > the first element that you need to update. > I'm not sure why the null check was there. Even if the position is > already non-null, don't we want to set it to the position we > determined? I wasn't sure of this, that's why I conservatively kept this check. But I agree that 'tc = annotations.get(0)' would be possible too. > Should we change `arrayTypeTree` to `arrayTypeTreeElement` or some > such and put the `.elemtype` access in the helper method? Why not but does this really improve readability? > The change to T6747671.out seems ok to me - the error message now > contains the annotation on the type use. I've attached a variant of the fix without any side-effect (the new elements discussed above are not yet included but I reinstated the dead code removal). Any comment about this variant (and 'T6747671' expected output) is welcome. > Thanks for adding the test cases! Thank you too, Bernard > Best, > cu, WMD. > > > > > > -- > http://www.google.com/profiles/wdietl -------------- next part -------------- A non-text attachment was scrubbed... Name: jdk8208470c.patch Type: text/x-patch Size: 8984 bytes Desc: not available URL: From vicente.romero at oracle.com Mon Jul 30 22:36:28 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 30 Jul 2018 15:36:28 -0700 Subject: RFR JDK-8206142: type inference: javac is incorrectly applying capture conversion during incorporation In-Reply-To: <4f300578-3313-3742-d607-7d7f060ee66d@oracle.com> References: <4ac51895-1d0b-9e1a-c0b2-b5d9a368041b@oracle.com> <9bd84725-d989-8514-db6b-fd844c85ca11@oracle.com> <7a455c5f-6bb2-b3fd-584c-a827543a7d3f@oracle.com> <33e3c937-38b1-f935-7819-86b12aca848a@oracle.com> <4f300578-3313-3742-d607-7d7f060ee66d@oracle.com> Message-ID: <7e571758-a181-a3c0-358a-aaae74ef5f8a@oracle.com> On 07/30/2018 01:20 PM, Maurizio Cimadamore wrote: > > > On 30/07/18 19:00, Vicente Romero wrote: >> >> >> On 07/30/2018 07:25 AM, Maurizio Cimadamore wrote: >>> Hi Vicente, >>> while I agree that the program in JDK-8206142 exposes an issues with >>> a spurious capture being performed by javac, and, while I agree >>> that, in that case, we can do without the capyure (both the source >>> and the target of the test are some B<...>), in the more general >>> case where source and target are at different heights, you need to >>> recurse to supertype and, hence, you need capture. >>> >>> So, I'm afraid that with this we will potentially introduce >>> compatibility issues, w/o fully resolving the underlying issue, >>> which is described by this spec issue which Dan filed while ago: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8016196 >>> >>> Maybe we should wait on this one? >> >> not sure here, it could be a good idea to wait but usually these spec >> issues take some time to be sorted out, so we could pause now and >> push this fix later if more users complain about this issue. > Right. But the point I was trying to make is that, if you never > capture (as in this patch), when you have a subtyping test like this: > > A <: B > > where > > A <: B> > > you end up with the following, non-sensical subtyping assertion: > > B <: B > > So, javac always applies capture conversion (even at risk of > incompatibilities like the one in this issue) in order to remain on a > safe path, from a type-wellformedness perspective. got it, then I guess we have no option but waiting for the spec issue to be fixed > > Maurizio Vicente >> >>> >>> Maurizio >> >> Vicente >> >>> >>> >>> >>> On 23/07/18 14:22, Vicente Romero wrote: >>>> >>>> >>>> On 07/21/2018 09:49 AM, B. Blaser wrote: >>>>> Hi Vicente, >>>>> >>>>> On 20 July 2018 at 22:27, Vicente Romero >>>>> wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review the patch to fix [1] at [2]. The fix is putting >>>>>> javac in sync >>>>>> with the spec by not applying capture conversion during >>>>>> incorporation. >>>>>> >>>>>> Thanks, >>>>>> Vicente >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8206142 >>>>>> [2] >>>>>> http://cr.openjdk.java.net/~vromero/8206142/webrev.00/jdk.dev.patch >>>>> It's hard to measure the potential side-effects of this fix, >>>> >>>> yes, I'm also worried about the possible side effects. I agree that >>>> more discussion will be needed, >>>> >>>>> ? but it >>>>> seems good to me even if you'll probably need another review. >>>>> Maybe, I'd rewrite it as next to avoid creating a new method? >>>>> >>>>> Thanks, >>>>> Bernard >>>> >>>> Thanks, >>>> Vicente >>>> >>>>> >>>>> >>>>> diff -r b0fcf59be391 >>>>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java >>>>> --- >>>>> a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java >>>>> ??????? Fri Jul 20 14:48:41 2018 -0700 >>>>> +++ >>>>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java >>>>> ??????? Sat Jul 21 14:33:05 2018 +0200 >>>>> @@ -1003,24 +1003,24 @@ >>>>> ?????? * Is t an unchecked subtype of s? >>>>> ?????? */ >>>>> ????? public boolean isSubtypeUnchecked(Type t, Type s, Warner >>>>> warn) { >>>>> -??????? boolean result = isSubtypeUncheckedInternal(t, s, true, >>>>> warn); >>>>> +??????? boolean result = isSubtypeUnchecked(t, s, true, warn); >>>>> ????????? if (result) { >>>>> ????????????? checkUnsafeVarargsConversion(t, s, warn); >>>>> ????????? } >>>>> ????????? return result; >>>>> ????? } >>>>> ????? //where >>>>> -??????? private boolean isSubtypeUncheckedInternal(Type t, Type s, >>>>> boolean capture, Warner warn) { >>>>> +??????? public boolean isSubtypeUnchecked(Type t, Type s, boolean >>>>> capture, Warner warn) { >>>>> ????????????? if (t.hasTag(ARRAY) && s.hasTag(ARRAY)) { >>>>> ????????????????? if (((ArrayType)t).elemtype.isPrimitive()) { >>>>> ????????????????????? return isSameType(elemtype(t), elemtype(s)); >>>>> ????????????????? } else { >>>>> -??????????????????? return isSubtypeUncheckedInternal(elemtype(t), >>>>> elemtype(s), false, warn); >>>>> +??????????????????? return isSubtypeUnchecked(elemtype(t), >>>>> elemtype(s), false, warn); >>>>> ????????????????? } >>>>> ????????????? } else if (isSubtype(t, s, capture)) { >>>>> ????????????????? return true; >>>>> ????????????? } else if (t.hasTag(TYPEVAR)) { >>>>> -??????????????? return isSubtypeUncheckedInternal(t.getUpperBound(), >>>>> s, false, warn); >>>>> +??????????????? return isSubtypeUnchecked(t.getUpperBound(), s, >>>>> false, warn); >>>>> ????????????? } else if (!s.isRaw()) { >>>>> ????????????????? Type t2 = asSuper(t, s.tsym); >>>>> ????????????????? if (t2 != null && t2.isRaw()) { >>>>> diff -r b0fcf59be391 >>>>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java >>>>> --- >>>>> a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java >>>>> ??????? Fri Jul 20 14:48:41 2018 -0700 >>>>> +++ >>>>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java >>>>> ??????? Sat Jul 21 14:33:05 2018 +0200 >>>>> @@ -1180,7 +1180,7 @@ >>>>> ????????? IS_SUBTYPE() { >>>>> ????????????? @Override >>>>> ????????????? boolean apply(Type op1, Type op2, Warner warn, Types >>>>> types) { >>>>> -??????????????? return types.isSubtypeUnchecked(op1, op2, warn); >>>>> +??????????????? return types.isSubtypeUnchecked(op1, op2, false, >>>>> warn); >>>>> ????????????? } >>>>> ????????? }, >>>>> ????????? IS_SAME_TYPE() { >>>> >>> >> > From bsrbnd at gmail.com Tue Jul 31 11:20:27 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Tue, 31 Jul 2018 13:20:27 +0200 Subject: Type annotations on inner type that is an array components In-Reply-To: References: <5B50E520.90504@oracle.com> Message-ID: I attached one more iteration (d) of the fix without any side-effect which is closer to 'jdk8208470b.patch' based on your second fix + the latest points we discussed. The issue is that resetting or not the type of the tree in 'typeWithAnnotations()' has some side-effects which is revealed by 'T6747671.out' but I'm not sure what's really expected? So, both (b) and (d) variants seem good to me. Variant (c) is more conservative but I'm not sure this is really necessary (the logic I kept was added as part of the jdk9 change-set). Any feedback is welcome, Bernard On 30 July 2018 at 23:59, B. Blaser wrote: > On 30 July 2018 at 20:19, Werner Dietl wrote: >> In this part: >> >> // Update first position >> for (TypeCompound tc : annotations) { >> if (tc.position == null) >> tc.position = pos; >> tc.position.location = >> tc.position.location.prepend(TypePathEntry.ARRAY); >> >> I think you can simplify to: >> >> TypeCompound tc = annotations.get(0); >> tc.position = pos; >> tc.position.location = tc.position.location.prepend(TypePathEntry.ARRAY); >> >> You know that annotations is non-empty, so there is always at least >> the first element that you need to update. >> I'm not sure why the null check was there. Even if the position is >> already non-null, don't we want to set it to the position we >> determined? > > I wasn't sure of this, that's why I conservatively kept this check. > But I agree that 'tc = annotations.get(0)' would be possible too. > >> Should we change `arrayTypeTree` to `arrayTypeTreeElement` or some >> such and put the `.elemtype` access in the helper method? > > Why not but does this really improve readability? > >> The change to T6747671.out seems ok to me - the error message now >> contains the annotation on the type use. > > I've attached a variant of the fix without any side-effect (the new > elements discussed above are not yet included but I reinstated the > dead code removal). > Any comment about this variant (and 'T6747671' expected output) is welcome. > >> Thanks for adding the test cases! > > Thank you too, > Bernard > >> Best, >> cu, WMD. >> >> >> >> >> >> -- >> http://www.google.com/profiles/wdietl -------------- next part -------------- A non-text attachment was scrubbed... Name: jdk8208470d.patch Type: text/x-patch Size: 8685 bytes Desc: not available URL: From thomas.stuefe at gmail.com Tue Jul 31 13:36:48 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 31 Jul 2018 15:36:48 +0200 Subject: RFR 8208524: IntelliJ support broken since 2018.2 In-Reply-To: <6612fe8f-5dea-1f0f-df6f-f76572c0535b@oracle.com> References: <6612fe8f-5dea-1f0f-df6f-f76572c0535b@oracle.com> Message-ID: Hi Maurizio, thank you for fixing this. I tested it and it works. I did not dive deeply into the issue, but your changes look like they do what you claim they do. Thanks, Thomas On Mon, Jul 30, 2018 at 7:50 PM, Maurizio Cimadamore wrote: > Hi, > support for IntelliJ projects (both langtools specific and JDK-wide) is > broken by a fix in the latest IntelliJ 2018.2, which prevents parsing of ant > files inside the .idea configuration folder. > > The solution is to copy the ant file into some sub-folder of the build > folder (I've called it .idea-support for now), which fixes the issue. > > I have more changes in the pipeline to improve the IntelliJ support, > including one which fixes the -o flag (e.g. JDK-8180794) - that's to say > that I know that this patch adds more assumptions on the location of the > build folder, but we have plans to remove such assumptions in due course. In > the short term, priority is to keep support working. > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/8208524/ > > Cheers > Maurizio > From maurizio.cimadamore at oracle.com Tue Jul 31 15:08:45 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 31 Jul 2018 16:08:45 +0100 Subject: RFR 8208524: IntelliJ support broken since 2018.2 In-Reply-To: References: <6612fe8f-5dea-1f0f-df6f-f76572c0535b@oracle.com> Message-ID: <572571e6-f150-9c24-7397-ce04f4d30314@oracle.com> Thanks for testing and reviewing Thomas! P.S. I'll be pushing shortly another RFR in code tools for the jtreg plugin source code, which is also broken by the latest IJ update. Cheers Maurizio On 31/07/18 14:36, Thomas St?fe wrote: > Hi Maurizio, > > thank you for fixing this. I tested it and it works. I did not dive > deeply into the issue, but your changes look like they do what you > claim they do. > > Thanks, Thomas > > On Mon, Jul 30, 2018 at 7:50 PM, Maurizio Cimadamore > wrote: >> Hi, >> support for IntelliJ projects (both langtools specific and JDK-wide) is >> broken by a fix in the latest IntelliJ 2018.2, which prevents parsing of ant >> files inside the .idea configuration folder. >> >> The solution is to copy the ant file into some sub-folder of the build >> folder (I've called it .idea-support for now), which fixes the issue. >> >> I have more changes in the pipeline to improve the IntelliJ support, >> including one which fixes the -o flag (e.g. JDK-8180794) - that's to say >> that I know that this patch adds more assumptions on the location of the >> build folder, but we have plans to remove such assumptions in due course. In >> the short term, priority is to keep support working. >> >> Webrev: >> >> http://cr.openjdk.java.net/~mcimadamore/8208524/ >> >> Cheers >> Maurizio >>