From shafi.s.ahmad at oracle.com Mon Jun 5 05:34:47 2017 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Sun, 4 Jun 2017 22:34:47 -0700 (PDT) Subject: [8u] RFR for JDK-8180660: missing LNT entry for finally block Message-ID: Hi, Please review the backport of bug: "JDK-8180660: missing LNT entry for finally block" to jdk8u-dev Please note that this is not a clean backport due to - A) Compilation failure for file share/classes/com/sun/tools/javac/tree/TreeInfo.java. To make it compile we have made a code change in 'enum PosKind'. Thanks to Maurizio and Vicente for the help. B) Compilation failure in file test/tools/javac/T8180660/MissingLNTEntryForFinalizerTest.java due to Module related code. + void clear() { + newRound(); + Modules.instance(context).newRound(); + } I have modified the above method to + void clear() { + //do nothing + } ... and also removed all module related change. Webrev: http://cr.openjdk.java.net/~shshahma/8180660/webrev.00/ Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8180660 Original patch pushed to jdk10: http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/f52e81f886fb Test: Run jprt, all langtools jtreg test, jtreg test under jdk/test/java/util and jdk/test/java/lang and newly added test case. Regards, Shafi From maurizio.cimadamore at oracle.com Tue Jun 6 09:55:13 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 6 Jun 2017 10:55:13 +0100 Subject: [8u] RFR for JDK-8180660: missing LNT entry for finally block In-Reply-To: References: Message-ID: Looks good Maurizio On 05/06/17 06:34, Shafi Ahmad wrote: > Hi, > > Please review the backport of bug: "JDK-8180660: missing LNT entry for finally block" to jdk8u-dev > > Please note that this is not a clean backport due to - > A) Compilation failure for file share/classes/com/sun/tools/javac/tree/TreeInfo.java. > To make it compile we have made a code change in 'enum PosKind'. > Thanks to Maurizio and Vicente for the help. > B) Compilation failure in file test/tools/javac/T8180660/MissingLNTEntryForFinalizerTest.java due to Module related code. > + void clear() { > + newRound(); > + Modules.instance(context).newRound(); > + } > I have modified the above method to > + void clear() { > + //do nothing > + } > ... and also removed all module related change. > > Webrev: http://cr.openjdk.java.net/~shshahma/8180660/webrev.00/ > Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8180660 > Original patch pushed to jdk10: http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/f52e81f886fb > > Test: Run jprt, all langtools jtreg test, jtreg test under jdk/test/java/util and jdk/test/java/lang and newly added test case. > > Regards, > Shafi From shafi.s.ahmad at oracle.com Tue Jun 6 14:24:47 2017 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Tue, 6 Jun 2017 07:24:47 -0700 (PDT) Subject: [8u] RFR for JDK-8180660: missing LNT entry for finally block In-Reply-To: References: Message-ID: <13ecc63a-d352-49ce-a424-3ebf869149b6@default> Thank you Maurizio. May I get the 2nd thumps up. Regards, Shafi > -----Original Message----- > From: Maurizio Cimadamore > Sent: Tuesday, June 06, 2017 3:25 PM > To: Shafi Ahmad ; compiler- > dev at openjdk.java.net > Cc: Vicente Romero Zaldivar > Subject: Re: [8u] RFR for JDK-8180660: missing LNT entry for finally block > > Looks good > > Maurizio > > > On 05/06/17 06:34, Shafi Ahmad wrote: > > Hi, > > > > Please review the backport of bug: "JDK-8180660: missing LNT entry for > finally block" to jdk8u-dev > > > > Please note that this is not a clean backport due to - > > A) Compilation failure for file > share/classes/com/sun/tools/javac/tree/TreeInfo.java. > > To make it compile we have made a code change in 'enum PosKind'. > > Thanks to Maurizio and Vicente for the help. > > B) Compilation failure in file > test/tools/javac/T8180660/MissingLNTEntryForFinalizerTest.java due to > Module related code. > > + void clear() { > > + newRound(); > > + Modules.instance(context).newRound(); > > + } > > I have modified the above method to > > + void clear() { > > + //do nothing > > + } > > ... and also removed all module related change. > > > > Webrev: http://cr.openjdk.java.net/~shshahma/8180660/webrev.00/ > > Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8180660 > > Original patch pushed to jdk10: > http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/f52e81f886fb > > > > Test: Run jprt, all langtools jtreg test, jtreg test under jdk/test/java/util > and jdk/test/java/lang and newly added test case. > > > > Regards, > > Shafi > From vicente.romero at oracle.com Tue Jun 6 17:06:01 2017 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 6 Jun 2017 13:06:01 -0400 Subject: [8u] RFR for JDK-8180660: missing LNT entry for finally block In-Reply-To: References: Message-ID: <1410b902-151a-b309-75c4-50d230d73357@oracle.com> Looks good, Vicente On 06/05/2017 01:34 AM, Shafi Ahmad wrote: > Hi, > > Please review the backport of bug: "JDK-8180660: missing LNT entry for finally block" to jdk8u-dev > > Please note that this is not a clean backport due to - > A) Compilation failure for file share/classes/com/sun/tools/javac/tree/TreeInfo.java. > To make it compile we have made a code change in 'enum PosKind'. > Thanks to Maurizio and Vicente for the help. > B) Compilation failure in file test/tools/javac/T8180660/MissingLNTEntryForFinalizerTest.java due to Module related code. > + void clear() { > + newRound(); > + Modules.instance(context).newRound(); > + } > I have modified the above method to > + void clear() { > + //do nothing > + } > ... and also removed all module related change. > > Webrev: http://cr.openjdk.java.net/~shshahma/8180660/webrev.00/ > Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8180660 > Original patch pushed to jdk10: http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/f52e81f886fb > > Test: Run jprt, all langtools jtreg test, jtreg test under jdk/test/java/util and jdk/test/java/lang and newly added test case. > > Regards, > Shafi From shafi.s.ahmad at oracle.com Tue Jun 6 17:07:04 2017 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Tue, 6 Jun 2017 10:07:04 -0700 (PDT) Subject: [8u] RFR for JDK-8180660: missing LNT entry for finally block In-Reply-To: <1410b902-151a-b309-75c4-50d230d73357@oracle.com> References: <1410b902-151a-b309-75c4-50d230d73357@oracle.com> Message-ID: <558ff8b1-d3e8-49e7-991f-41b3d7263e1c@default> Thank you Vicente for the review. Regards, Shafi > -----Original Message----- > From: Vicente Romero > Sent: Tuesday, June 06, 2017 10:36 PM > To: Shafi Ahmad ; compiler- > dev at openjdk.java.net > Cc: Maurizio Cimadamore > Subject: Re: [8u] RFR for JDK-8180660: missing LNT entry for finally block > > Looks good, > Vicente > > On 06/05/2017 01:34 AM, Shafi Ahmad wrote: > > Hi, > > > > Please review the backport of bug: "JDK-8180660: missing LNT entry for > finally block" to jdk8u-dev > > > > Please note that this is not a clean backport due to - > > A) Compilation failure for file > share/classes/com/sun/tools/javac/tree/TreeInfo.java. > > To make it compile we have made a code change in 'enum PosKind'. > > Thanks to Maurizio and Vicente for the help. > > B) Compilation failure in file > test/tools/javac/T8180660/MissingLNTEntryForFinalizerTest.java due to > Module related code. > > + void clear() { > > + newRound(); > > + Modules.instance(context).newRound(); > > + } > > I have modified the above method to > > + void clear() { > > + //do nothing > > + } > > ... and also removed all module related change. > > > > Webrev: http://cr.openjdk.java.net/~shshahma/8180660/webrev.00/ > > Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8180660 > > Original patch pushed to jdk10: > http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/f52e81f886fb > > > > Test: Run jprt, all langtools jtreg test, jtreg test under jdk/test/java/util > and jdk/test/java/lang and newly added test case. > > > > Regards, > > Shafi > From jonathan.gibbons at oracle.com Fri Jun 9 00:25:58 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 08 Jun 2017 17:25:58 -0700 Subject: RFR: 8181825: Add tool and services information to module summary Message-ID: <5939EB16.8080700@oracle.com> Please review minor doc updates to langtools modules to add info about tools and services. In addition, a previously missing package-info is provided for com.sun.tools.javac. This is the langtools equivalent of JDK-8181639. https://bugs.openjdk.java.net/browse/JDK-8181639 http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048132.html JBS: https://bugs.openjdk.java.net/browse/JDK-8181825 Webrev: http://cr.openjdk.java.net/~jjg/8181825/webrev.00 -- Jon From mandy.chung at oracle.com Fri Jun 9 03:03:25 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 8 Jun 2017 20:03:25 -0700 Subject: RFR: 8181825: Add tool and services information to module summary In-Reply-To: <5939EB16.8080700@oracle.com> References: <5939EB16.8080700@oracle.com> Message-ID: <684551EF-0B74-42A3-91C1-A345A59BFDCC@oracle.com> > On Jun 8, 2017, at 5:25 PM, Jonathan Gibbons wrote: > > Please review minor doc updates to langtools modules to add info > about tools and services. > > In addition, a previously missing package-info is provided for > com.sun.tools.javac. > > This is the langtools equivalent of JDK-8181639. > https://bugs.openjdk.java.net/browse/JDK-8181639 > http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048132.html > > JBS: https://bugs.openjdk.java.net/browse/JDK-8181825 > Webrev: http://cr.openjdk.java.net/~jjg/8181825/webrev.00 You can consider s/just exists/only exists/ suggested by Paul in a similiar statement in the jdk module: javah just exists as a command line tool, jdeprscan just exists as a command line tool, Otherwise looks good. Mandy From robert.field at oracle.com Fri Jun 9 03:57:05 2017 From: robert.field at oracle.com (Robert Field) Date: Thu, 8 Jun 2017 20:57:05 -0700 Subject: RFR: 8181825: Add tool and services information to module summary In-Reply-To: <5939EB16.8080700@oracle.com> References: <5939EB16.8080700@oracle.com> Message-ID: <304E4F3D-4F36-4DA5-9A21-436F15DE26C4@oracle.com> In terms of the JShell module ? The changes include formatting references to the tool as: jshell tool Which is dandy. However, because of another change, what was the first reference to the tool is now the second: the existing Java? shell tool Which makes no sense for a second reference. This too should be: jshell tool What is now the first reference (on the line above) could become something like: including the Java? shell tool ? {@index jshell jshell tool} tool. Or not. A link is added for the new Tool Reference (?Tool Guides?), which great, though it should be ?Tool Reference?. There is a User Guide nearing completion, but there is no external link yet. Robert > On Jun 8, 2017, at 5:25 PM, Jonathan Gibbons wrote: > > Please review minor doc updates to langtools modules to add info > about tools and services. > > In addition, a previously missing package-info is provided for > com.sun.tools.javac. > > This is the langtools equivalent of JDK-8181639. > https://bugs.openjdk.java.net/browse/JDK-8181639 > http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048132.html > > JBS: https://bugs.openjdk.java.net/browse/JDK-8181825 > Webrev: http://cr.openjdk.java.net/~jjg/8181825/webrev.00 > > -- Jon > > > From jonathan.gibbons at oracle.com Fri Jun 9 17:09:15 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 9 Jun 2017 10:09:15 -0700 Subject: RFR: 8181825: Add tool and services information to module summary In-Reply-To: <304E4F3D-4F36-4DA5-9A21-436F15DE26C4@oracle.com> References: <5939EB16.8080700@oracle.com> <304E4F3D-4F36-4DA5-9A21-436F15DE26C4@oracle.com> Message-ID: <4f02814a-d4b3-e251-3909-fd502130110d@oracle.com> On 6/8/17 8:57 PM, Robert Field wrote: > A link is added for the new Tool Reference (?Tool Guides?), which great, though it should be ?Tool Reference?. Neither term is fully accurate, and we have been discussing better text with the Docs team.. For now, I opted for consistency with the updates in the jdk/ repo; if necessary, we can/should do a forest-wide update for all such references. From robert.field at oracle.com Fri Jun 9 17:34:51 2017 From: robert.field at oracle.com (Robert Field) Date: Fri, 9 Jun 2017 10:34:51 -0700 Subject: RFR: 8181825: Add tool and services information to module summary In-Reply-To: <4f02814a-d4b3-e251-3909-fd502130110d@oracle.com> References: <5939EB16.8080700@oracle.com> <304E4F3D-4F36-4DA5-9A21-436F15DE26C4@oracle.com> <4f02814a-d4b3-e251-3909-fd502130110d@oracle.com> Message-ID: <34D47316-BCDE-43D5-923F-18EF68467FDE@oracle.com> > On Jun 9, 2017, at 10:09 AM, Jonathan Gibbons wrote: > > > > On 6/8/17 8:57 PM, Robert Field wrote: >> A link is added for the new Tool Reference (?Tool Guides?), which great, though it should be ?Tool Reference?. > > Neither term is fully accurate, and we have been discussing better text with the Docs team.. For now, I opted for consistency with the updates in the jdk/ repo; if necessary, we can/should do a forest-wide update for all such references. > > OK. I was basing on what is currently external: https://docs.oracle.com/javase/9/tools/tools-and-command-reference.htm -Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Fri Jun 9 17:36:33 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 9 Jun 2017 10:36:33 -0700 Subject: RFR: 8181825: Add tool and services information to module summary In-Reply-To: <34D47316-BCDE-43D5-923F-18EF68467FDE@oracle.com> References: <5939EB16.8080700@oracle.com> <304E4F3D-4F36-4DA5-9A21-436F15DE26C4@oracle.com> <4f02814a-d4b3-e251-3909-fd502130110d@oracle.com> <34D47316-BCDE-43D5-923F-18EF68467FDE@oracle.com> Message-ID: On 6/9/17 10:34 AM, Robert Field wrote: > >> On Jun 9, 2017, at 10:09 AM, Jonathan Gibbons >> > wrote: >> >> >> >> On 6/8/17 8:57 PM, Robert Field wrote: >>> A link is added for the new Tool Reference (?Tool Guides?), which >>> great, though it should be ?Tool Reference?. >> >> Neither term is fully accurate, and we have been discussing better >> text with the Docs team.. For now, I opted for consistency with the >> updates in the jdk/ repo; if necessary, we can/should do a >> forest-wide update for all such references. >> >> > > OK. > > I was basing on what is currently external: > > https://docs.oracle.com/javase/9/tools/tools-and-command-reference.htm > > -Robert > Yes, noted; that may be what we have to go with. -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.kelemen85 at gmail.com Sun Jun 11 16:16:49 2017 From: attila.kelemen85 at gmail.com (Attila Kelemen) Date: Sun, 11 Jun 2017 18:16:49 +0200 Subject: Generics type inference problem? Message-ID: Hi, I'm not sure if my issue is a violation of the specs or a bug, so I'm writing here instead of a bug report. The following class does not compile (imports are omitted) in Java 9 but does in Java 8: public final class NewClass { private static List> test( Collection> factory) { return factory.stream() .map(NewClass::testMap) .collect(Collectors.toList()); } private static TestFactory testMap(Supplier factory) { return null; } private static interface TestFactory { } } The above `test` method does not compile because type inference fails to deduce the "appropriate" type for the return value of `Stream.collect`. Which is strange given that `Stream.map` should map to `Stream>`. In fact, if I rewrite the method `test` to: Stream> factoryStream = factory.stream().map(NewClass::testMap); return factoryStream.collect(Collectors.toList()); The code will compile fine. Is this behaviour in accordance with the spec or is this a bug? The exact versions I have tried this with: Java 8: java version "1.8.0_92", build 1.8.0_92-b14 Java 9: java version "9-ea", build 9-ea+170 Thanks, Attila Kelemen -------------- next part -------------- An HTML attachment was scrubbed... URL: From srikanth.adayapalam at oracle.com Mon Jun 12 11:37:00 2017 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Mon, 12 Jun 2017 17:07:00 +0530 Subject: RFR: 8144185: javac produces incorrect RuntimeInvisibleTypeAnnotations length attribute In-Reply-To: <59147A45.8070502@oracle.com> References: <590BC4DD.4050400@oracle.com> <591408D4.2060003@oracle.com> <59147A45.8070502@oracle.com> Message-ID: <593E7CDC.5040300@oracle.com> Hi Liam, OK. I have studied these differences and I am satisfied with the patch you have and the explanations you have provided. Thanks so much. Can you please generate a mercurial change set for JDK10 and mail it to me privately with this one comment incorporated so I can take it forward: - Rename test class from being T8144185.java to a more meaningful one such as say TypeAnnotationPropagationTest,java Thanks! Srikanth On Thursday 11 May 2017 08:20 PM, Srikanth wrote: > I made the assertions about the differences in the patches simply by > looking at the patches without ascertaining the behavior on tip due to > other fixes. > > I will look into this in detail to see what is the minimal set of > changes that would suffice. > > Srikanth > > On Thursday 11 May 2017 07:47 PM, Liam Miller-Cushon wrote: >> Thanks for reviewing, >> >> On Thu, May 11, 2017 at 2:46 AM, Srikanth >> > > wrote: >> >> >> I am looking into this one - turns out I had a patch for this >> that was put through internal review process and some open issues >> that needed addressing caused it to be deferred. >> >> >> If it'd be less work to continue with your patch that sounds good to >> me, thanks. As I said I ran into an ASM crash related to this, and >> thought it might be a simple fix. >> >> (1) Your proposed patch simply switches on the kind to determine >> whether annotations need to be carried over. This looks >> incorrect/insufficient. Type annotations and declarations >> annotations have different rules to be carried over. >> >> From >> http://mail.openjdk.java.net/pipermail/compiler-dev/2015-December/009865.html >> : >> >> - Declaration annotations on a lambda formal should not make >> it to the >> class file at all. >> >> >> I think that is handled in ClassWriter: >> http://hg.openjdk.java.net/jdk9/dev/langtools/file/ee84b7d44339/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java#l1183 >> >> >> - Type annotations on the type of a lambda formal should be >> carried >> over to the type >> of the formal parameter of the synthetic method that >> implements >> the lambda[*] >> >> I don't think this is handled by your patch ??? >> >> >> As far as I can tell this is handled correctly before and after the >> patch: >> >> class T { >> @Retention(RUNTIME) @Target(TYPE_USE) @interface A {} >> Function r = (@A String x) -> x; >> } >> ... >> RuntimeVisibleTypeAnnotations: >> 0: #20(): METHOD_FORMAL_PARAMETER, param_index=0 >> >> (2) From https://bugs.openjdk.java.net/browse/JDK-8144185 >> : >> >> Not only is the range incorrect, but also LVT index appears >> incorrect: >> >> I don't think this is handled by your patch ??? >> >> >> I thought it was handled by the patch and exercised by the included >> test case. What am I missing? The incorrect LVT index comes from >> associating the annotation with the capture parameter in the >> synthetic lambda method instead of with the original local variable. >> In the test, the LVT index of the variable in f() is 1, and the LVT >> index of the capture parameter in the synthetic lambda method is 0. >> >> Before the patch, I see: >> >> RuntimeVisibleTypeAnnotations: >> 0: #23(): LOCAL_VARIABLE, {start_pc=0, length=31, index=0} >> >> With the patch applied: >> >> RuntimeVisibleTypeAnnotations: >> 0: #23(): LOCAL_VARIABLE, {start_pc=3, length=8, index=1} > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Mon Jun 12 14:25:27 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 12 Jun 2017 15:25:27 +0100 Subject: Generics type inference problem? In-Reply-To: References: Message-ID: <34e60ef7-8b8c-767a-fd33-122430572012@oracle.com> Hi Attila, the change in behavior you are observing is expected and part of the fix for: https://bugs.openjdk.java.net/browse/JDK-8039214 Let me try to show you what the difference is between 8 and 9 - and let me doing so by rewriting your example to use unique type-variable names: class NewClass { private static List> test( Collection> factory) { return factory.stream() .map(NewClass::testMap) .collect(Collectors.toList()); } private static TestFactory testMap(Supplier factory) { return null; } private static interface TestFactory { } } So, the variable 'factory' has this static type: Collection> If we want to access its members (e.g. call stream() ), we need to capture the type first, and obtain: Collection<#CAP1>, where #CAP1 is a fresh type-variable such that #CAP1 <: Supplier Now, the instantiated type of 'factory.stream().map()' is something like: R map(Function) This means that when checking the method reference expression: NewClass::testMap We will be using #CAP1 as the argument type (see JLS 15.13.2). In other words, we will run a method lookup for a method name 'testMap' inside class 'NewClass' with argument types { #CAP1 }. This triggers an applicability check against the only method found (NewClass.testMap); as part of the applicability check we need to check that the actual argument type is compatible with the formal - so: #CAP1 <: Supplier To do this subtyping we need to rewrite the left hand side so that it looks like a 'Supplier' - we do so by recursing on the upper bound: Supplier <: Supplier And, to do this subtyping, we need to capture the left hand side (at least that's how javac does it) - as recursion into supertypes can sometimes require capture conversion. So: Supplier<#CAP2> <: Supplier, where #CAP2 <: T which is satisfied if: #CAP2 <= E (where '<=' means 'contained by'). Now, in JDK 8's javac, this containment relation was rewritten as follows: T <: E (that is, we recursed on the upper bound of the left hand side. This led to an inference constraint which ultimately led to E and T being solved in the same way, and the program compiled without errors. This behavior is flexible but, ultimately, unsound - JDK-8039214 fixed that, so that in 9 the type containment is rewritten as: #CAP2 <: E (no recursion on the left hand side). This then runs into trouble because when we need to solve the inference variable E, we have two incompatible constraints: E = T (from target type context of the collect() call) and E = #CAP2 (from above) hence the error. We worked on some potential mitigation for these issues, but ultimately they have been considered too risky for targeting JDK 9 - you can follow the issue here: https://bugs.openjdk.java.net/browse/JDK-8160244 Thanks! Maurizio On 11/06/17 17:16, Attila Kelemen wrote: > Hi, > > I'm not sure if my issue is a violation of the specs or a bug, so I'm > writing here instead of a bug report. The following class does not > compile (imports are omitted) in Java 9 but does in Java 8: > > public final class NewClass { > private static List> test( > Collection> factory) { > return factory.stream() > .map(NewClass::testMap) > .collect(Collectors.toList()); > } > > private static TestFactory > testMap(Supplier factory) { > return null; > } > > private static interface TestFactory { > } > } > > The above `test` method does not compile because type inference fails > to deduce the "appropriate" type for the return value of > `Stream.collect`. Which is strange given that `Stream.map` should map > to `Stream>`. In fact, if I rewrite the method `test` to: > > Stream> factoryStream = > factory.stream().map(NewClass::testMap); > return factoryStream.collect(Collectors.toList()); > > The code will compile fine. > > Is this behaviour in accordance with the spec or is this a bug? > > The exact versions I have tried this with: > > Java 8: java version "1.8.0_92", build 1.8.0_92-b14 > Java 9: java version "9-ea", build 9-ea+170 > > Thanks, > Attila Kelemen From jonathan.gibbons at oracle.com Mon Jun 12 19:01:42 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 12 Jun 2017 12:01:42 -0700 Subject: RFR: 8144185: javac produces incorrect RuntimeInvisibleTypeAnnotations length attribute In-Reply-To: <593E7CDC.5040300@oracle.com> References: <590BC4DD.4050400@oracle.com> <591408D4.2060003@oracle.com> <59147A45.8070502@oracle.com> <593E7CDC.5040300@oracle.com> Message-ID: <593EE516.3000904@oracle.com> On 06/12/2017 04:37 AM, Srikanth wrote: > > - Rename test class from being T8144185.java to a more meaningful > one such as say TypeAnnotationPropagationTest,java Yes, generally, we are trying to move away from bug-numbered tests these days. That might make it harder to write the test, but it definitely makes it easier to read the test later on, assuming the name is well chosen. -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.kelemen85 at gmail.com Mon Jun 12 19:28:00 2017 From: attila.kelemen85 at gmail.com (Attila Kelemen) Date: Mon, 12 Jun 2017 21:28:00 +0200 Subject: Generics type inference problem? In-Reply-To: <34e60ef7-8b8c-767a-fd33-122430572012@oracle.com> References: <34e60ef7-8b8c-767a-fd33-122430572012@oracle.com> Message-ID: Forgot to add the dev-list. Sorry for the duplicate message. Thank you very much for the detailed explanation. I did not expect this to be fixed for the release of Java 9 (unless it turns out to be a bug, which I was hinted against). Aside from that: How rigid the JLS is in this regard? Is it acceptable to adjust type inference - in a post release update - in a way that may make some code compile which failes to do so according to the spec (assuming the construct can be proven to be safe)? 2017-06-12 16:25 GMT+02:00 Maurizio Cimadamore < maurizio.cimadamore at oracle.com>: > Hi Attila, > the change in behavior you are observing is expected and part of the fix > for: > > https://bugs.openjdk.java.net/browse/JDK-8039214 > > Let me try to show you what the difference is between 8 and 9 - and let me > doing so by rewriting your example to use unique type-variable names: > > class NewClass { > private static List> test( > Collection> factory) { > return factory.stream() > .map(NewClass::testMap) > .collect(Collectors.toList()); > } > > private static TestFactory > testMap(Supplier factory) { > return null; > } > > private static interface TestFactory { > } > } > > So, the variable 'factory' has this static type: > > Collection> > > If we want to access its members (e.g. call stream() ), we need to capture > the type first, and obtain: > > Collection<#CAP1>, > > where #CAP1 is a fresh type-variable such that #CAP1 <: Supplier T> > > Now, the instantiated type of 'factory.stream().map()' is something like: > > R map(Function) > > This means that when checking the method reference expression: > > NewClass::testMap > > We will be using #CAP1 as the argument type (see JLS 15.13.2). In other > words, we will run a method lookup for a method name 'testMap' inside class > 'NewClass' with argument types { #CAP1 }. This triggers an applicability > check against the only method found (NewClass.testMap); as part of the > applicability check we need to check that the actual argument type is > compatible with the formal - so: > > #CAP1 <: Supplier > > To do this subtyping we need to rewrite the left hand side so that it > looks like a 'Supplier' - we do so by recursing on the upper bound: > > Supplier <: Supplier > > And, to do this subtyping, we need to capture the left hand side (at least > that's how javac does it) - as recursion into supertypes can sometimes > require capture conversion. So: > > Supplier<#CAP2> <: Supplier, where #CAP2 <: T > > which is satisfied if: > > #CAP2 <= E > > (where '<=' means 'contained by'). > > Now, in JDK 8's javac, this containment relation was rewritten as follows: > > T <: E (that is, we recursed on the upper bound of the left hand side. > > This led to an inference constraint which ultimately led to E and T being > solved in the same way, and the program compiled without errors. > > This behavior is flexible but, ultimately, unsound - JDK-8039214 fixed > that, so that in 9 the type containment is rewritten as: > > #CAP2 <: E (no recursion on the left hand side). > > This then runs into trouble because when we need to solve the inference > variable E, we have two incompatible constraints: > > E = T (from target type context of the collect() call) > > and > > E = #CAP2 (from above) > > hence the error. > > > We worked on some potential mitigation for these issues, but ultimately > they have been considered too risky for targeting JDK 9 - you can follow > the issue here: > > https://bugs.openjdk.java.net/browse/JDK-8160244 > > Thanks! > > Maurizio > > > > On 11/06/17 17:16, Attila Kelemen wrote: > >> Hi, >> >> I'm not sure if my issue is a violation of the specs or a bug, so I'm >> writing here instead of a bug report. The following class does not compile >> (imports are omitted) in Java 9 but does in Java 8: >> >> public final class NewClass { >> private static List> test( >> Collection> factory) { >> return factory.stream() >> .map(NewClass::testMap) >> .collect(Collectors.toList()); >> } >> >> private static TestFactory >> testMap(Supplier factory) { >> return null; >> } >> >> private static interface TestFactory { >> } >> } >> >> The above `test` method does not compile because type inference fails to >> deduce the "appropriate" type for the return value of `Stream.collect`. >> Which is strange given that `Stream.map` should map to >> `Stream>`. In fact, if I rewrite the method `test` to: >> >> Stream> factoryStream = >> factory.stream().map(NewClass::testMap); >> return factoryStream.collect(Collectors.toList()); >> >> The code will compile fine. >> >> Is this behaviour in accordance with the spec or is this a bug? >> >> The exact versions I have tried this with: >> >> Java 8: java version "1.8.0_92", build 1.8.0_92-b14 >> Java 9: java version "9-ea", build 9-ea+170 >> >> Thanks, >> Attila Kelemen >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Mon Jun 12 22:51:27 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 12 Jun 2017 23:51:27 +0100 Subject: Generics type inference problem? In-Reply-To: References: <34e60ef7-8b8c-767a-fd33-122430572012@oracle.com> Message-ID: On 12/06/17 20:28, Attila Kelemen wrote: > Forgot to add the dev-list. Sorry for the duplicate message. > > Thank you very much for the detailed explanation. I did not expect > this to be fixed for the release of Java 9 (unless it turns out to be > a bug, which I was hinted against). Aside from that: How rigid the JLS > is in this regard? Is it acceptable to adjust type inference - in a > post release update - in a way that may make some code compile which > failes to do so according to the spec (assuming the construct can be > proven to be safe)? The JLS is generally more rigid than the compiler in this area. While it's possible to ameliorate the situation with some fixes, our long term goal is to arrive at a place where the compiler (all of them, not just javac) and the spec agree on whether these kind of programs should compile. But this require some work on the spec side too, which we will take care of post 9. Thanks Maurizio > > 2017-06-12 16:25 GMT+02:00 Maurizio Cimadamore > >: > > Hi Attila, > the change in behavior you are observing is expected and part of > the fix for: > > https://bugs.openjdk.java.net/browse/JDK-8039214 > > > Let me try to show you what the difference is between 8 and 9 - > and let me doing so by rewriting your example to use unique > type-variable names: > > class NewClass { > private static List> > test( > Collection> factory) { > return factory.stream() > .map(NewClass::testMap) > .collect(Collectors.toList()); > } > > private static TestFactory > testMap(Supplier factory) { > return null; > } > > private static interface TestFactory { > } > } > > So, the variable 'factory' has this static type: > > Collection> > > If we want to access its members (e.g. call stream() ), we need to > capture the type first, and obtain: > > Collection<#CAP1>, > > where #CAP1 is a fresh type-variable such that #CAP1 <: Supplier extends T> > > Now, the instantiated type of 'factory.stream().map()' is > something like: > > R map(Function) > > This means that when checking the method reference expression: > > NewClass::testMap > > We will be using #CAP1 as the argument type (see JLS 15.13.2). In > other words, we will run a method lookup for a method name > 'testMap' inside class 'NewClass' with argument types { #CAP1 }. > This triggers an applicability check against the only method found > (NewClass.testMap); as part of the applicability check we need to > check that the actual argument type is compatible with the formal > - so: > > #CAP1 <: Supplier > > To do this subtyping we need to rewrite the left hand side so that > it looks like a 'Supplier' - we do so by recursing on the upper bound: > > Supplier <: Supplier > > And, to do this subtyping, we need to capture the left hand side > (at least that's how javac does it) - as recursion into supertypes > can sometimes require capture conversion. So: > > Supplier<#CAP2> <: Supplier, where #CAP2 <: T > > which is satisfied if: > > #CAP2 <= E > > (where '<=' means 'contained by'). > > Now, in JDK 8's javac, this containment relation was rewritten as > follows: > > T <: E (that is, we recursed on the upper bound of the left hand side. > > This led to an inference constraint which ultimately led to E and > T being solved in the same way, and the program compiled without > errors. > > This behavior is flexible but, ultimately, unsound - JDK-8039214 > fixed that, so that in 9 the type containment is rewritten as: > > #CAP2 <: E (no recursion on the left hand side). > > This then runs into trouble because when we need to solve the > inference variable E, we have two incompatible constraints: > > E = T (from target type context of the collect() call) > > and > > E = #CAP2 (from above) > > hence the error. > > > We worked on some potential mitigation for these issues, but > ultimately they have been considered too risky for targeting JDK 9 > - you can follow the issue here: > > https://bugs.openjdk.java.net/browse/JDK-8160244 > > > Thanks! > > Maurizio > > > > On 11/06/17 17:16, Attila Kelemen wrote: > > Hi, > > I'm not sure if my issue is a violation of the specs or a bug, > so I'm writing here instead of a bug report. The following > class does not compile (imports are omitted) in Java 9 but > does in Java 8: > > public final class NewClass { > private static > List> test( > Collection> > factory) { > return factory.stream() > .map(NewClass::testMap) > .collect(Collectors.toList()); > } > > private static TestFactory > testMap(Supplier factory) { > return null; > } > > private static interface TestFactory Throwable> { > } > } > > The above `test` method does not compile because type > inference fails to deduce the "appropriate" type for the > return value of `Stream.collect`. Which is strange given that > `Stream.map` should map to `Stream>`. In fact, > if I rewrite the method `test` to: > > Stream> factoryStream = > factory.stream().map(NewClass::testMap); > return factoryStream.collect(Collectors.toList()); > > The code will compile fine. > > Is this behaviour in accordance with the spec or is this a bug? > > The exact versions I have tried this with: > > Java 8: java version "1.8.0_92", build 1.8.0_92-b14 > Java 9: java version "9-ea", build 9-ea+170 > > Thanks, > Attila Kelemen > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Thu Jun 15 15:53:09 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 15 Jun 2017 17:53:09 +0200 Subject: RFR: 8182162: Remove -XD-Xmodule Message-ID: <5942AD65.2000206@oracle.com> Hi, The proposal here is to remove the undocumented option -XD-Xmodule. Webrev: http://cr.openjdk.java.net/~jlahoda/8182162/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8182162 Thanks, Jan From jonathan.gibbons at oracle.com Thu Jun 15 17:34:08 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 15 Jun 2017 10:34:08 -0700 Subject: RFR: 8182162: Remove -XD-Xmodule In-Reply-To: <5942AD65.2000206@oracle.com> References: <5942AD65.2000206@oracle.com> Message-ID: <5942C510.3030404@oracle.com> +1 On 06/15/2017 08:53 AM, Jan Lahoda wrote: > Hi, > > The proposal here is to remove the undocumented option -XD-Xmodule. > > Webrev: > http://cr.openjdk.java.net/~jlahoda/8182162/webrev.00/ > Bug: > https://bugs.openjdk.java.net/browse/JDK-8182162 > > Thanks, > Jan > From jonathan.gibbons at oracle.com Thu Jun 15 21:05:09 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 15 Jun 2017 14:05:09 -0700 Subject: RFR: 8181825: Add tool and services information to module summary In-Reply-To: <5939EB16.8080700@oracle.com> References: <5939EB16.8080700@oracle.com> Message-ID: <5942F685.7020007@oracle.com> Updated patch incorporating review feedback. * Mandy and Paul's suggestion to use "only" instead of "just". * Removed entities for trademark symbols, as being against current guidelines. -- Jon JBS: https://bugs.openjdk.java.net/browse/JDK-8181825 Webrev: http://cr.openjdk.java.net/~jjg/8181825/webrev.01 On 06/08/2017 05:25 PM, Jonathan Gibbons wrote: > Please review minor doc updates to langtools modules to add info > about tools and services. > > In addition, a previously missing package-info is provided for > com.sun.tools.javac. > > This is the langtools equivalent of JDK-8181639. > https://bugs.openjdk.java.net/browse/JDK-8181639 > http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048132.html > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8181825 > Webrev: http://cr.openjdk.java.net/~jjg/8181825/webrev.00 > > -- Jon > > > From mandy.chung at oracle.com Thu Jun 15 21:18:37 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 15 Jun 2017 14:18:37 -0700 Subject: RFR: 8181825: Add tool and services information to module summary In-Reply-To: <5942F685.7020007@oracle.com> References: <5939EB16.8080700@oracle.com> <5942F685.7020007@oracle.com> Message-ID: > On Jun 15, 2017, at 2:05 PM, Jonathan Gibbons wrote: > > Updated patch incorporating review feedback. > > * Mandy and Paul's suggestion to use "only" instead of "just". > * Removed entities for trademark symbols, as being against current guidelines. > > -- Jon > > JBS: https://bugs.openjdk.java.net/browse/JDK-8181825 > Webrev: http://cr.openjdk.java.net/~jjg/8181825/webrev.01 langtools/src/jdk.compiler/share/classes/module-info.java s/jar file/JAR file/ Otherwise, looks fine. Mandy From srikanth.adayapalam at oracle.com Mon Jun 19 10:13:38 2017 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Mon, 19 Jun 2017 15:43:38 +0530 Subject: RFR: 8144185: javac produces incorrect RuntimeInvisibleTypeAnnotations length attribute In-Reply-To: References: <590BC4DD.4050400@oracle.com> <591408D4.2060003@oracle.com> Message-ID: <5947A3D2.3000801@oracle.com> This got pushed here: http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/0b32afcabef4 Thanks a lot for the fix. Srikanth On Thursday 11 May 2017 07:47 PM, Liam Miller-Cushon wrote: > Thanks for reviewing, > > On Thu, May 11, 2017 at 2:46 AM, Srikanth > > wrote: > > > I am looking into this one - turns out I had a patch for this that > was put through internal review process and some open issues that > needed addressing caused it to be deferred. > > > If it'd be less work to continue with your patch that sounds good to > me, thanks. As I said I ran into an ASM crash related to this, and > thought it might be a simple fix. > > (1) Your proposed patch simply switches on the kind to determine > whether annotations need to be carried over. This looks > incorrect/insufficient. Type annotations and declarations > annotations have different rules to be carried over. > > From > http://mail.openjdk.java.net/pipermail/compiler-dev/2015-December/009865.html > : > > - Declaration annotations on a lambda formal should not make > it to the > class file at all. > > > I think that is handled in ClassWriter: > http://hg.openjdk.java.net/jdk9/dev/langtools/file/ee84b7d44339/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java#l1183 > > > - Type annotations on the type of a lambda formal should be > carried > over to the type > of the formal parameter of the synthetic method that > implements > the lambda[*] > > I don't think this is handled by your patch ??? > > > As far as I can tell this is handled correctly before and after the patch: > > class T { > @Retention(RUNTIME) @Target(TYPE_USE) @interface A {} > Function r = (@A String x) -> x; > } > ... > RuntimeVisibleTypeAnnotations: > 0: #20(): METHOD_FORMAL_PARAMETER, param_index=0 > > (2) From https://bugs.openjdk.java.net/browse/JDK-8144185 > : > > Not only is the range incorrect, but also LVT index appears incorrect: > > I don't think this is handled by your patch ??? > > > I thought it was handled by the patch and exercised by the included > test case. What am I missing? The incorrect LVT index comes from > associating the annotation with the capture parameter in the synthetic > lambda method instead of with the original local variable. In the > test, the LVT index of the variable in f() is 1, and the LVT index of > the capture parameter in the synthetic lambda method is 0. > > Before the patch, I see: > > RuntimeVisibleTypeAnnotations: > 0: #23(): LOCAL_VARIABLE, {start_pc=0, length=31, index=0} > > With the patch applied: > > RuntimeVisibleTypeAnnotations: > 0: #23(): LOCAL_VARIABLE, {start_pc=3, length=8, index=1} -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Mon Jun 26 15:36:15 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 26 Jun 2017 17:36:15 +0200 Subject: RFR: 8181897: JDK 9 change to symlink handling affects SourceFile attributes Message-ID: <595129EF.7090005@oracle.com> Hi, I'd like to propose a simple fix for: https://bugs.openjdk.java.net/browse/JDK-8181897 The proposed fix is to use the original/user path for toUri(): http://cr.openjdk.java.net/~jlahoda/8181897/webrev.00/ I believe this is conceptually consistent with the JDK 8 behavior. Jan From rengels at optionscity.com Mon Jun 26 17:56:30 2017 From: rengels at optionscity.com (Robert Engels) Date: Mon, 26 Jun 2017 12:56:30 -0500 Subject: critical native wrapper inefficiencies Message-ID: In the sharedRuntime_x86_64.cpp the generate_native_wrapper is somewhat inefficient for a very important case. (I assume this is also the case for other platforms). The 'critical native' allows for much more efficient JNI calls, but often these don't need to pass any java arrays - that is, all parameters and return values use handles (simple ints?) in the native code, or pointers to a 'direct buffer'. The generate_native_wrapper() ALWAYS adds to the code to ask the GC_Locker if a gc is needed when calling a native critical method. It should only be adding this check if the number of 'java array arguments' is greater than 0. Similarly, it should be the same after the JNI method return. This will make many JNI calls much more efficient. -- *Robert Engels* OptionsCity Software 150 S. Wacker Dr., Suite 2300 Chicago, IL 60606 O. +1 (312) 605-4500 | F. +1 (312) 635-1751 *Connect with OptionsCity at *www.optionscity.com | LinkedIn | Twitter | YouTube | Facebook -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsproch at google.com Mon Jun 26 23:38:33 2017 From: jsproch at google.com (Jim Sproch) Date: Mon, 26 Jun 2017 16:38:33 -0700 Subject: Explicitly importing code generated by APT Message-ID: Hi, I'm trying to understand the intended usage of code generation within APT. In particular, I'm wondering if it is considered a good practice to have users explicitly importing classes that are generated during the annotation processing phase of javac. Example: import com.generated.MyAutomaticallyGeneratedWidget; > @MakeMagical > public class MyWidget { > public MyAutomaticallyGeneratedWidget doSomething() { > return new MyAutomaticallyGeneratedWidget("whatever"); > } > } Where the @MakeMagical annotation will look at the classname being annotated and automatically generate a class based on the class being annotated. The problem being that the classes in com.generated.* are not available until I recompile MyWidget, so the IDE is confused and complains instead of offering autocomplete suggestions. Is this a bug in the IDE? Or is this code an antipattern? Should the generated code be imported, or should annotation processors design their API to ensure the generated code is an implementation detail of the annotation processor? Thanks, Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Mon Jun 26 23:58:43 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 26 Jun 2017 16:58:43 -0700 Subject: Explicitly importing code generated by APT In-Reply-To: References: Message-ID: <59519FB3.1030104@oracle.com> Jim, Some IDEs have explicit support for annotation processing and dealing with generated sources. Check your IDE for details. -- Jon On 06/26/2017 04:38 PM, Jim Sproch wrote: > Hi, > > I'm trying to understand the intended usage of code generation within > APT. In particular, I'm wondering if it is considered a good practice > to have users explicitly importing classes that are generated during > the annotation processing phase of javac. > > Example: > > import com.generated.MyAutomaticallyGeneratedWidget; > @MakeMagical > public class MyWidget { > public MyAutomaticallyGeneratedWidget doSomething() { > return new MyAutomaticallyGeneratedWidget("whatever"); > } > } > > > > Where the @MakeMagical annotation will look at the classname being > annotated and automatically generate a class based on the class being > annotated. > > The problem being that the classes in com.generated.* are not > available until I recompile MyWidget, so the IDE is confused and > complains instead of offering autocomplete suggestions. > > Is this a bug in the IDE? Or is this code an antipattern? Should the > generated code be imported, or should annotation processors design > their API to ensure the generated code is an implementation detail of > the annotation processor? > > Thanks, > Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From gunnar at hibernate.org Tue Jun 27 14:54:45 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 27 Jun 2017 16:54:45 +0200 Subject: Using annotation with @Target(TYPE_USE) on type declaration Message-ID: Hi, I've an annotation type whose only supported target is ElementType.TYPE_USE: @Target(ElementType.TYPE_USE) public @interface MyAnno {} To my surprise I can use this annotation on the definition of a class, whereas I'd have expected a compilation error: @MyAnno public class Foo {} I can't seem to find the JLS wording that'd suggest that TYPE_USE allows usage of the annotation on a type definition. "9.6.4.1 @Target" [1] mentions eight declaration contexts (which don't seem to apply here as per the supported element type) and 16 type contexts which are described in "4.11. Where Types Are Used" [2]. They are represented by TYPE_USE, but none of these seem to match the the declaration of type Foo. Why is it that specifying @MyAnno on the declaration of Foo does not raise a compiler error? Thanks for any pointers, --Gunnar [1] https://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.6.4.1 [2] https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.11 From alex.buckley at oracle.com Tue Jun 27 18:47:39 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 27 Jun 2017 11:47:39 -0700 Subject: Using annotation with @Target(TYPE_USE) on type declaration In-Reply-To: References: Message-ID: <5952A84B.30100@oracle.com> On 6/27/2017 7:54 AM, Gunnar Morling wrote: > I've an annotation type whose only supported target is ElementType.TYPE_USE: > > @Target(ElementType.TYPE_USE) > public @interface MyAnno {} > > To my surprise I can use this annotation on the definition of a class, > whereas I'd have expected a compilation error: > > @MyAnno > public class Foo {} > > I can't seem to find the JLS wording that'd suggest that TYPE_USE > allows usage of the annotation on a type definition. > > "9.6.4.1 @Target" [1] mentions eight declaration contexts (which don't > seem to apply here as per the supported element type) and 16 type > contexts which are described in "4.11. Where Types Are Used" [2]. They > are represented by TYPE_USE, but none of these seem to match the the > declaration of type Foo. 1. JLS 9.6.4.1 is trying to make {declaration,type} contexts in the language correspond to constants in the ElementType API. A type declaration context corresponds to TYPE, and the 16 type contexts corresponds to TYPE_USE. Notice the correspondence is one-way. 2. The API spec for ElementType is trying to make constants in the ElementType API correspond to {declaration,type} contexts in the language. The TYPE_USE constant corresponds to more contexts than the JLS said correspond to it: "The constant TYPE_USE corresponds to the type contexts in JLS 4.11, as well as to two declaration contexts: type declarations (including annotation type declarations) and type parameter declarations." [Rationale follows] 3. You're now wondering why JLS 9.6.4.1 doesn't "just" make a type declaration context correspond to both TYPE and TYPE_USE. The answer is that I wanted to keep the correspondence between contexts and constants as straightforward as possible in the JLS. This was one of many techniques for managing the complexity of the specification as it gained support for type annotations and repeating annotations in SE 8. 4. OK, so why does the JLS allow @MyAnno on the declaration of class Foo? Because JLS 9.7.4 says the following, which "implements" the ElementType API spec's belief that TYPE_USE corresponds to type declarations: "It is a compile-time error if an annotation of type T is syntactically a modifier for: ... a class, interface, or enum declaration, but T is not applicable to type declarations or type contexts" 5. The JLS9 draft available at http://cr.openjdk.java.net/~mr/jigsaw/spec/ has some words in 9.7.4 to explain this multi-role of TYPE_USE. Alex From gunnar at hibernate.org Wed Jun 28 07:26:14 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 28 Jun 2017 09:26:14 +0200 Subject: Using annotation with @Target(TYPE_USE) on type declaration In-Reply-To: <5952A84B.30100@oracle.com> References: <5952A84B.30100@oracle.com> Message-ID: Thanks, Alex! > 3. You're now wondering why JLS 9.6.4.1 doesn't "just" make a type declaration context I see. While 9.7.4 addresses the issue, it seems a bit implicit to me. A sentence in 9.6.4.1 in that spirit might be helpful, given it's probably the first place people will check when looking for details around @Target. Btw. I had looked for clarification at the JavaDoc of the enum member ElementType#TYPE_USE, but this just says "Use of a type". Perhaps it'd be a good idea to move/duplicate some of the very useful info given in the class comment of ElementType to the specific docs of the TYPE_USE member? --Gunnar 2017-06-27 20:47 GMT+02:00 Alex Buckley : > On 6/27/2017 7:54 AM, Gunnar Morling wrote: >> >> I've an annotation type whose only supported target is >> ElementType.TYPE_USE: >> >> @Target(ElementType.TYPE_USE) >> public @interface MyAnno {} >> >> To my surprise I can use this annotation on the definition of a class, >> whereas I'd have expected a compilation error: >> >> @MyAnno >> public class Foo {} >> >> I can't seem to find the JLS wording that'd suggest that TYPE_USE >> allows usage of the annotation on a type definition. >> >> "9.6.4.1 @Target" [1] mentions eight declaration contexts (which don't >> seem to apply here as per the supported element type) and 16 type >> contexts which are described in "4.11. Where Types Are Used" [2]. They >> are represented by TYPE_USE, but none of these seem to match the the >> declaration of type Foo. > > > 1. JLS 9.6.4.1 is trying to make {declaration,type} contexts in the language > correspond to constants in the ElementType API. A type declaration context > corresponds to TYPE, and the 16 type contexts corresponds to TYPE_USE. > Notice the correspondence is one-way. > > 2. The API spec for ElementType is trying to make constants in the > ElementType API correspond to {declaration,type} contexts in the language. > The TYPE_USE constant corresponds to more contexts than the JLS said > correspond to it: > > "The constant TYPE_USE corresponds to the type contexts in JLS 4.11, > as well as to two declaration contexts: type declarations > (including annotation type declarations) and > type parameter declarations." [Rationale follows] > > 3. You're now wondering why JLS 9.6.4.1 doesn't "just" make a type > declaration context correspond to both TYPE and TYPE_USE. The answer is that > I wanted to keep the correspondence between contexts and constants as > straightforward as possible in the JLS. This was one of many techniques for > managing the complexity of the specification as it gained support for type > annotations and repeating annotations in SE 8. > > 4. OK, so why does the JLS allow @MyAnno on the declaration of class Foo? > Because JLS 9.7.4 says the following, which "implements" the ElementType API > spec's belief that TYPE_USE corresponds to type declarations: > > "It is a compile-time error if an annotation of type T is > syntactically a modifier for: ... a class, interface, or enum > declaration, but T is not applicable to type declarations or > type contexts" > > 5. The JLS9 draft available at http://cr.openjdk.java.net/~mr/jigsaw/spec/ > has some words in 9.7.4 to explain this multi-role of TYPE_USE. > > Alex From gunnar at hibernate.org Wed Jun 28 08:23:42 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 28 Jun 2017 10:23:42 +0200 Subject: Evolution of annotation types - reducing set of supported targets Message-ID: Hi, I'm trying to figure whether removing an element type from an annotation's set of supported targets is considered to break binary compatibility or not. Some quick testing indicates it's non-breaking: I have an annotation which in v1 supports {TYPE,FIELD} and in v2 just {FIELD}. Linking against v2, I still can retrieve the annotation from a type definition in a binary compiled against v1. Is there some official confirmation of this? Esp. is it guaranteed that the annotation can be retrieved from the now unsupported location or could there theoretically be a runtime which performs a check of the supported targets? I was looking in JLS 13.5.7. "Evolution of Annotation Types", but couldn't find anything. Thanks, --Gunnar From alex.buckley at oracle.com Wed Jun 28 18:08:51 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 28 Jun 2017 11:08:51 -0700 Subject: Using annotation with @Target(TYPE_USE) on type declaration In-Reply-To: References: <5952A84B.30100@oracle.com> Message-ID: <5953F0B3.4090804@oracle.com> On 6/28/2017 12:26 AM, Gunnar Morling wrote: >> 3. You're now wondering why JLS 9.6.4.1 doesn't "just" make a type declaration context > > I see. While 9.7.4 addresses the issue, it seems a bit implicit to me. > A sentence in 9.6.4.1 in that spirit might be helpful, given it's > probably the first place people will check when looking for details > around @Target. OK, sure, please provide that sentence by reply. It should be a crystal clear narrative in perfect English. Alex From alex.buckley at oracle.com Wed Jun 28 18:19:42 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 28 Jun 2017 11:19:42 -0700 Subject: Evolution of annotation types - reducing set of supported targets In-Reply-To: References: Message-ID: <5953F33E.3060800@oracle.com> On 6/28/2017 1:23 AM, Gunnar Morling wrote: > I'm trying to figure whether removing an element type from an > annotation's set of supported targets is considered to break binary > compatibility or not. Binary compatibility concerns the JVM's ability to continue to link the changed class. Since linking does not care about annotations, any change to an annotation's type is binary compatible. Your issue is nothing to do with binary compatibility, but rather with the specified behavior of the Core Reflection API when an annotation's presence is out of sync with the annotation's type. I believe the Core Reflection API is designed to be extremely forgiving in these circumstances. Alex > Some quick testing indicates it's non-breaking: I have an annotation > which in v1 supports {TYPE,FIELD} and in v2 just {FIELD}. Linking > against v2, I still can retrieve the annotation from a type definition > in a binary compiled against v1. > > Is there some official confirmation of this? Esp. is it guaranteed > that the annotation can be retrieved from the now unsupported location > or could there theoretically be a runtime which performs a check of > the supported targets? I was looking in JLS 13.5.7. "Evolution of > Annotation Types", but couldn't find anything. From joe.darcy at oracle.com Wed Jun 28 21:17:52 2017 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 28 Jun 2017 14:17:52 -0700 Subject: Evolution of annotation types - reducing set of supported targets In-Reply-To: <5953F33E.3060800@oracle.com> References: <5953F33E.3060800@oracle.com> Message-ID: <59541D00.8060608@oracle.com> On 6/28/2017 11:19 AM, Alex Buckley wrote: > On 6/28/2017 1:23 AM, Gunnar Morling wrote: >> I'm trying to figure whether removing an element type from an >> annotation's set of supported targets is considered to break binary >> compatibility or not. > > Binary compatibility concerns the JVM's ability to continue to link > the changed class. Since linking does not care about annotations, any > change to an annotation's type is binary compatible. Your issue is > nothing to do with binary compatibility, but rather with the specified > behavior of the Core Reflection API when an annotation's presence is > out of sync with the annotation's type. I believe the Core Reflection > API is designed to be extremely forgiving in these circumstances. > In the terminology used by the CSR (compatibility and specification review) process, that kind of compatiblity under discussion is called behavioral compatiblty rather than binary compatibility: https://wiki.openjdk.java.net/display/csr/Kinds+of+Compatibility By design, annotations are checked more loosely than other aspects of the platform. For example, malformed annotation information in class files will only trigger exceptions to be thrown if there is an attempt to read the annotations; the annotation data is just ignored otherwise. In that spirit, the core reflection implementation generally does not do heroic efforts to check for compile-time vs runtime inconsistencies in annotation usage, such as changing the set of valid targets. -Joe From gunnar at hibernate.org Thu Jun 29 13:29:26 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 29 Jun 2017 15:29:26 +0200 Subject: Evolution of annotation types - reducing set of supported targets In-Reply-To: <59541D00.8060608@oracle.com> References: <5953F33E.3060800@oracle.com> <59541D00.8060608@oracle.com> Message-ID: Joe, Alex, thanks a lot for the clarification! 2017-06-28 23:17 GMT+02:00 Joseph D. Darcy : > > On 6/28/2017 11:19 AM, Alex Buckley wrote: >> >> On 6/28/2017 1:23 AM, Gunnar Morling wrote: >>> >>> I'm trying to figure whether removing an element type from an >>> annotation's set of supported targets is considered to break binary >>> compatibility or not. >> >> >> Binary compatibility concerns the JVM's ability to continue to link the >> changed class. Since linking does not care about annotations, any change to >> an annotation's type is binary compatible. Your issue is nothing to do with >> binary compatibility, but rather with the specified behavior of the Core >> Reflection API when an annotation's presence is out of sync with the >> annotation's type. I believe the Core Reflection API is designed to be >> extremely forgiving in these circumstances. >> > > In the terminology used by the CSR (compatibility and specification review) > process, that kind of compatiblity under discussion is called behavioral > compatiblty rather than binary compatibility: > > https://wiki.openjdk.java.net/display/csr/Kinds+of+Compatibility > > By design, annotations are checked more loosely than other aspects of the > platform. For example, malformed annotation information in class files will > only trigger exceptions to be thrown if there is an attempt to read the > annotations; the annotation data is just ignored otherwise. > > In that spirit, the core reflection implementation generally does not do > heroic efforts to check for compile-time vs runtime inconsistencies in > annotation usage, such as changing the set of valid targets. > > -Joe From batya239 at gmail.com Thu Jun 29 13:50:42 2017 From: batya239 at gmail.com (Dmitry Batkovich) Date: Thu, 29 Jun 2017 13:50:42 -0000 Subject: A question about javac API Message-ID: Hi, I want to find a way how to determine whether given TypeElement is defined in some class from classpath or in source code. Or it is not possible? I've found that com.sun.tools.javac.code.Symbol.ClassSymbol has sourcefile and classfile fields and it may helps. But unfortunately ClassSymbol is not part of officially supported API. Best regards, Dmitry Batkovich -------------- next part -------------- An HTML attachment was scrubbed... URL: