From joe.darcy at oracle.com Tue May 3 00:57:32 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 02 May 2016 17:57:32 -0700 Subject: JDK 9 RFR of JDK-8155516: Suppress warnings from uses of deprecated Class.newInstance langtools In-Reply-To: <5721527B.5060509@oracle.com> References: <57212EDF.6060602@oracle.com> <57214976.1000704@oracle.com> <5721527B.5060509@oracle.com> Message-ID: <5727F77C.10305@oracle.com> Hi Jon, I filed the follow-up issue JDK-8155880: Fix langtools usage of the deprecated Class.newInstance method Cheers, -Joe On 4/27/2016 4:59 PM, Jonathan Gibbons wrote: > Joe, > > I guess this is OK for now, but as a general policy for langtools, I > hope we are not going to see @SuppressWarnings proliferating > throughout the code. If a method has been deprecated, it is > presumably for a good reason ( Optional.get ) and there > should in general be a replacement, and we should endeavor to improve > the quality of the code base by using the recommended replacements, > rather than perpetuating the sins of our predecessors. > > As for @SuppressWarnings, the review yesterday had a credible use of > the annotation insofar as the replacement method was not available in > JDK 8, which (for the duration of JDK 9 development) is our bootstrap > compiler. > > For all of Stuart's protestations that these are not breaking changes, > we are sure doing a lot of high priority reacting to non-breaking > changes! > > -- Jon > > On 04/27/2016 04:21 PM, Jonathan Gibbons wrote: >> What is the recommended approach for avoiding the issue, as compared >> to sweeping it under the carpet? >> >> -- Jon >> >> >> On 04/27/2016 02:27 PM, Joseph D. Darcy wrote: >>> Hello, >>> >>> As part of the effort to address >>> >>> JDK-6850612: Deprecate Class.newInstance since it violates the >>> checked exception language contract >>> >>> the uses of Class.newInstance in the langtools repo have to be >>> address in some way, either by suppressing the resulting warning or >>> by refactoring the code to use other recommended idioms. >>> >>> Please review the fix for >>> >>> JDK-8155516: Suppress warnings from uses of deprecated >>> Class.newInstance langtools >>> http://cr.openjdk.java.net/~darcy/8155516.0/ >>> >>> which takes the suppression approach. >>> >>> Patch below. >>> >>> Thanks, >>> >>> -Joe >>> >>> --- >>> old/src/java.compiler/share/classes/javax/tools/ToolProvider.java >>> 2016-04-27 14:16:21.269126143 -0700 >>> +++ >>> new/src/java.compiler/share/classes/javax/tools/ToolProvider.java >>> 2016-04-27 14:16:21.177126140 -0700 >>> @@ -123,7 +123,9 @@ >>> private static T getSystemTool(Class clazz, String >>> moduleName, String className) { >>> if (useLegacy) { >>> try { >>> - return Class.forName(className, true, >>> ClassLoader.getSystemClassLoader()).asSubclass(clazz).newInstance(); >>> + @SuppressWarnings("deprecation") >>> + T result = Class.forName(className, true, >>> ClassLoader.getSystemClassLoader()).asSubclass(clazz).newInstance(); >>> + return result; >>> } catch (ReflectiveOperationException e) { >>> throw new Error(e); >>> } >>> --- >>> old/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java >>> 2016-04-27 14:16:21.573126153 -0700 >>> +++ >>> new/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java >>> 2016-04-27 14:16:21.489126150 -0700 >>> @@ -282,6 +282,7 @@ >>> >>> if (options.isSet(XPRINT)) { >>> try { >>> + @SuppressWarnings("deprecation") >>> Processor processor = >>> PrintingProcessor.class.newInstance(); >>> processorIterator = List.of(processor).iterator(); >>> } catch (Throwable t) { >>> @@ -549,8 +550,9 @@ >>> try { >>> Class processorClass = >>> processorCL.loadClass(processorName); >>> ensureReadable(processorClass); >>> - processor = >>> - (Processor) >>> (processorClass.newInstance()); >>> + @SuppressWarnings("deprecation") >>> + Object tmp = processorClass.newInstance(); >>> + processor = (Processor) tmp; >>> } catch (ClassNotFoundException cnfe) { >>> log.error("proc.processor.not.found", processorName); >>> return false; >>> --- >>> old/src/jdk.compiler/share/classes/com/sun/tools/sjavac/options/Option.java >>> 2016-04-27 14:16:21.881126163 -0700 >>> +++ >>> new/src/jdk.compiler/share/classes/com/sun/tools/sjavac/options/Option.java >>> 2016-04-27 14:16:21.797126161 -0700 >>> @@ -151,6 +151,7 @@ >>> // Construct transformer >>> try { >>> Class trCls = Class.forName(classname); >>> + @SuppressWarnings("deprecation") >>> Transformer transformer = (Transformer) >>> trCls.newInstance(); >>> transformer.setExtra(extra); >>> helper.addTransformer(suffix, transformer); >>> --- >>> old/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java >>> 2016-04-27 14:16:22.181126173 -0700 >>> +++ >>> new/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java >>> 2016-04-27 14:16:22.097126171 -0700 >>> @@ -247,6 +247,7 @@ >>> tagClassLoader = fileManager.getClassLoader(TAGLET_PATH); >>> Class customTagClass = >>> tagClassLoader.loadClass(classname); >>> ensureReadable(customTagClass); >>> + @SuppressWarnings("deprecation") >>> Object instance = customTagClass.newInstance(); >>> Taglet newLegacy = new >>> UserTaglet((jdk.javadoc.doclet.taglet.Taglet)instance); >>> String tname = newLegacy.getName(); >>> --- >>> old/src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java >>> 2016-04-27 14:16:22.481126183 -0700 >>> +++ >>> new/src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java >>> 2016-04-27 14:16:22.393126180 -0700 >>> @@ -252,7 +252,9 @@ >>> initMessager(); >>> messager.setLocale(locale); >>> try { >>> - doclet = (Doclet) docletClass.newInstance(); >>> + @SuppressWarnings("deprecation") >>> + Object o = docletClass.newInstance(); >>> + doclet = (Doclet) o; >>> } catch (InstantiationException | >>> IllegalAccessException exc) { >>> exc.printStackTrace(); >>> if (!apiMode) { >>> >> > From jonathan.gibbons at oracle.com Tue May 3 01:06:04 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 02 May 2016 18:06:04 -0700 Subject: JDK 9 RFR of JDK-8155516: Suppress warnings from uses of deprecated Class.newInstance langtools In-Reply-To: <5727F77C.10305@oracle.com> References: <57212EDF.6060602@oracle.com> <57214976.1000704@oracle.com> <5721527B.5060509@oracle.com> <5727F77C.10305@oracle.com> Message-ID: <5727F97C.6030106@oracle.com> Thanks for the update. -- Jon On 05/02/2016 05:57 PM, Joseph D. Darcy wrote: > Hi Jon, > > I filed the follow-up issue > > JDK-8155880: Fix langtools usage of the deprecated > Class.newInstance method > > Cheers, > > -Joe > > On 4/27/2016 4:59 PM, Jonathan Gibbons wrote: >> Joe, >> >> I guess this is OK for now, but as a general policy for langtools, I >> hope we are not going to see @SuppressWarnings proliferating >> throughout the code. If a method has been deprecated, it is >> presumably for a good reason ( Optional.get ) and >> there should in general be a replacement, and we should endeavor to >> improve the quality of the code base by using the recommended >> replacements, rather than perpetuating the sins of our predecessors. >> >> As for @SuppressWarnings, the review yesterday had a credible use of >> the annotation insofar as the replacement method was not available in >> JDK 8, which (for the duration of JDK 9 development) is our bootstrap >> compiler. >> >> For all of Stuart's protestations that these are not breaking >> changes, we are sure doing a lot of high priority reacting to >> non-breaking changes! >> >> -- Jon >> >> On 04/27/2016 04:21 PM, Jonathan Gibbons wrote: >>> What is the recommended approach for avoiding the issue, as compared >>> to sweeping it under the carpet? >>> >>> -- Jon >>> >>> >>> On 04/27/2016 02:27 PM, Joseph D. Darcy wrote: >>>> Hello, >>>> >>>> As part of the effort to address >>>> >>>> JDK-6850612: Deprecate Class.newInstance since it violates the >>>> checked exception language contract >>>> >>>> the uses of Class.newInstance in the langtools repo have to be >>>> address in some way, either by suppressing the resulting warning or >>>> by refactoring the code to use other recommended idioms. >>>> >>>> Please review the fix for >>>> >>>> JDK-8155516: Suppress warnings from uses of deprecated >>>> Class.newInstance langtools >>>> http://cr.openjdk.java.net/~darcy/8155516.0/ >>>> >>>> which takes the suppression approach. >>>> >>>> Patch below. >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>>> --- >>>> old/src/java.compiler/share/classes/javax/tools/ToolProvider.java >>>> 2016-04-27 14:16:21.269126143 -0700 >>>> +++ >>>> new/src/java.compiler/share/classes/javax/tools/ToolProvider.java >>>> 2016-04-27 14:16:21.177126140 -0700 >>>> @@ -123,7 +123,9 @@ >>>> private static T getSystemTool(Class clazz, String >>>> moduleName, String className) { >>>> if (useLegacy) { >>>> try { >>>> - return Class.forName(className, true, >>>> ClassLoader.getSystemClassLoader()).asSubclass(clazz).newInstance(); >>>> + @SuppressWarnings("deprecation") >>>> + T result = Class.forName(className, true, >>>> ClassLoader.getSystemClassLoader()).asSubclass(clazz).newInstance(); >>>> + return result; >>>> } catch (ReflectiveOperationException e) { >>>> throw new Error(e); >>>> } >>>> --- >>>> old/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java >>>> 2016-04-27 14:16:21.573126153 -0700 >>>> +++ >>>> new/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java >>>> 2016-04-27 14:16:21.489126150 -0700 >>>> @@ -282,6 +282,7 @@ >>>> >>>> if (options.isSet(XPRINT)) { >>>> try { >>>> + @SuppressWarnings("deprecation") >>>> Processor processor = >>>> PrintingProcessor.class.newInstance(); >>>> processorIterator = List.of(processor).iterator(); >>>> } catch (Throwable t) { >>>> @@ -549,8 +550,9 @@ >>>> try { >>>> Class processorClass = >>>> processorCL.loadClass(processorName); >>>> ensureReadable(processorClass); >>>> - processor = >>>> - (Processor) >>>> (processorClass.newInstance()); >>>> + @SuppressWarnings("deprecation") >>>> + Object tmp = >>>> processorClass.newInstance(); >>>> + processor = (Processor) tmp; >>>> } catch (ClassNotFoundException cnfe) { >>>> log.error("proc.processor.not.found", processorName); >>>> return false; >>>> --- >>>> old/src/jdk.compiler/share/classes/com/sun/tools/sjavac/options/Option.java >>>> 2016-04-27 14:16:21.881126163 -0700 >>>> +++ >>>> new/src/jdk.compiler/share/classes/com/sun/tools/sjavac/options/Option.java >>>> 2016-04-27 14:16:21.797126161 -0700 >>>> @@ -151,6 +151,7 @@ >>>> // Construct transformer >>>> try { >>>> Class trCls = Class.forName(classname); >>>> + @SuppressWarnings("deprecation") >>>> Transformer transformer = (Transformer) >>>> trCls.newInstance(); >>>> transformer.setExtra(extra); >>>> helper.addTransformer(suffix, transformer); >>>> --- >>>> old/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java >>>> 2016-04-27 14:16:22.181126173 -0700 >>>> +++ >>>> new/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java >>>> 2016-04-27 14:16:22.097126171 -0700 >>>> @@ -247,6 +247,7 @@ >>>> tagClassLoader = fileManager.getClassLoader(TAGLET_PATH); >>>> Class customTagClass = >>>> tagClassLoader.loadClass(classname); >>>> ensureReadable(customTagClass); >>>> + @SuppressWarnings("deprecation") >>>> Object instance = customTagClass.newInstance(); >>>> Taglet newLegacy = new >>>> UserTaglet((jdk.javadoc.doclet.taglet.Taglet)instance); >>>> String tname = newLegacy.getName(); >>>> --- >>>> old/src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java >>>> 2016-04-27 14:16:22.481126183 -0700 >>>> +++ >>>> new/src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java >>>> 2016-04-27 14:16:22.393126180 -0700 >>>> @@ -252,7 +252,9 @@ >>>> initMessager(); >>>> messager.setLocale(locale); >>>> try { >>>> - doclet = (Doclet) docletClass.newInstance(); >>>> + @SuppressWarnings("deprecation") >>>> + Object o = docletClass.newInstance(); >>>> + doclet = (Doclet) o; >>>> } catch (InstantiationException | >>>> IllegalAccessException exc) { >>>> exc.printStackTrace(); >>>> if (!apiMode) { >>>> >>> >> > From ernimril at gmail.com Thu May 5 15:30:21 2016 From: ernimril at gmail.com (Robert Olofsson) Date: Thu, 5 May 2016 17:30:21 +0200 Subject: Experimental java compiler Message-ID: Hi! Since quite some time I am working on a java compiler on my own. My goal is to actually learn what it takes to write a full compiler for a real language. Many years ago I did take some of the compiler oriented courses at the university, but never go around to fully explore it. Now it is a pet project. This means that development is quite slow. Anyway I have quite a few already: * Hand written lexer. * Grammar based earley parsing. * Quite a few semantic tests. * Bytecode generation for quite a few things. * Parallel operations in all the different stages. I do know of the antlr-javac experiment, but that one seems to have died. I did read some of the requests for a faster more multi threaded javac so some of what I have done may be interesting to look at. I also want a faster compiler, since I work on somewhat large projects at work. I did spend some time reading the sources for javac, but found the code to be hard to work with when it comes to multi threading. In case you want to look at it, you can find my project at: https://github.com/robert-olofsson/parjac /robo -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve.drach at oracle.com Thu May 5 19:28:10 2016 From: steve.drach at oracle.com (Steve Drach) Date: Thu, 5 May 2016 12:28:10 -0700 Subject: RFR 8149757:Implement Multi-Release jar aware JavacFileManager for javac In-Reply-To: <63B271F4-F1DB-4280-B6F2-5E755FDCF92C@oracle.com> References: <63B271F4-F1DB-4280-B6F2-5E755FDCF92C@oracle.com> Message-ID: <7AE390A4-223C-4DE6-8D12-233484366D9F@oracle.com> My apologies, that seems to be an old mail that got mistakenly resent. > On Apr 5, 2016, at 9:32 AM, Steve Drach wrote: > > Hi, > > Please review the changes required to make javac and the StandardJavaFileManager multi-release jar aware. For javac, the version of the classes in a multi-release.jar is selected by the -release (or -target) command line option, or if the option is not present, the runtime version is selected. For the StandardJavaFileManager, the version is selected with the handleOption method. See the tests for more detail. > > issue: https://bugs.openjdk.java.net/browse/JDK-8149757 > webrev: http://cr.openjdk.java.net/~sdrach/8149757/webrev/index.html > > Thank you, > Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Fri May 6 23:22:58 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 06 May 2016 16:22:58 -0700 Subject: RFR: 8149843, 8150111 Two small changes to StandardJavaFileManager API Message-ID: <572D2752.3000607@oracle.com> This is for two small changes to the StandardJavaFileManager API. JBS: https://bugs.openjdk.java.net/browse/JDK-8149843 StandardJavaFileManager should provide a way to get paths from strings JBS: https://bugs.openjdk.java.net/browse/JDK-8150111 Need to change signature of StandardJavaFileManager.setLocationFromPaths With these changes, all standard uses of Paths.get are replaced by using a user-provided function, defaulting to Paths::get. The exceptions are: file names specified on the javac command line file names used in some internal debugging/tracing features in javac file names used in sjavac Combined specdiff: http://cr.openjdk.java.net/~jjg/8149843/specdiff.00/ Combined webrev: http://cr.openjdk.java.net/~jjg/8149843/webrev.00/ -- Jon From Jacob.Wieland at spirent.com Mon May 9 08:26:34 2016 From: Jacob.Wieland at spirent.com (Wieland, Jacob) Date: Mon, 9 May 2016 08:26:34 +0000 Subject: Trying to build a more hackable compiler... In-Reply-To: <20160119200819.129514a0@nuccy.khelekore.org> References: <20160119200819.129514a0@nuccy.khelekore.org> Message-ID: If you take suggestions, give the compiler the option to generate-bytecode-only (i.e. turn off all unnecessary semantic checks). This would solve a lot of performance issues I have when compiling generated java-surce-code (that I know is semantically correct, so semantic checks produce only warmth and consume time). Dr. Jacob Wieland Senior Software Engineer ________________________________________ From: compiler-dev on behalf of Robert Olofsson Sent: Tuesday, January 19, 2016 8:08:19 PM To: compiler-dev at openjdk.java.net Subject: Trying to build a more hackable compiler... Hi! Some time ago I started reading the code for javac and I realized that it is not a project that is easy to work on. I also realized that there are other people that want a compiler that is easier to hack. A few of the things that are requested are: * Grammar based parser * Better multi threading I did try to make a few patches for javac to at least make it better multi threaded, but realized that this was really hard to do, at least for the code I looked at. Too much global state in the lexer and parser. I realized that I actually did take a few compiler related courses so time to build something on my own, as a proof of concept. In case you want to take a look: https://github.com/robert-olofsson/parjac Initial thoughts: * Making lexing + parsing run in parallel is easy * Setting classes on types in parallel is easy * Checking other semantics in parallel is easy * Writing bytecode in parallel is easy Parsing a reasonably big code tree (27195 files with 11022 of them being java) and outputting class files containing hello-world like methods with the correct signatures is quite a lot faster than javac doing a full compile and my computer is a nuc i7, so not many cores. Sure, this is a bit of apples vs oranges, but it still indicates that it is quite possible to fulfill the wishes of a grammar based multi threaded compiler. The heavy part is currently parsing. I do know of the antlr-javac experiment, but it seems to have died, not sure what will happen to it. My experiments with antlr indicated that it is too hard to use for a java 8 grammar and it seems like it ended up being slower than ordinary javac. If this is considered advertising a non javac-compiler I do apologize, my end goal is to make javac (based on current code or some other code) be a better compiler and for now I only want to show that it seems possible to make it better. /robo Spirent Communications e-mail confidentiality. ------------------------------------------------------------------------ This e-mail contains confidential and / or privileged information belonging to Spirent Communications plc, its affiliates and / or subsidiaries. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution and / or the taking of any action based upon reliance on the contents of this transmission is strictly forbidden. If you have received this message in error please notify the sender by return e-mail and delete it from your system. Spirent Communications plc Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom. Tel No. +44 (0) 1293 767676 Fax No. +44 (0) 1293 767677 Registered in England Number 470893 Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom. Or if within the US, Spirent Communications, 27349 Agoura Road, Calabasas, CA, 91301, USA. Tel No. 1-818-676- 2300 From jonathan.gibbons at oracle.com Mon May 9 22:20:53 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 09 May 2016 15:20:53 -0700 Subject: Trying to build a more hackable compiler... In-Reply-To: References: <20160119200819.129514a0@nuccy.khelekore.org> Message-ID: <57310D45.3050308@oracle.com> You can already disable (or not enable) the "unnecessary" checks with the -Xlint option. In general, the rest of the semantic "checks" are necessary for javac to figure out the meaning of your programs. Did you have any semantic checks or performance issues in mind? -- Jon On 05/09/2016 01:26 AM, Wieland, Jacob wrote: > > If you take suggestions, give the compiler the option to generate-bytecode-only (i.e. turn off all unnecessary semantic checks). This would solve a lot of performance issues I have when compiling generated java-surce-code (that I know is semantically correct, so semantic checks produce only warmth and consume time). > > > > Dr. Jacob Wieland > Senior Software Engineer > ________________________________________ > From: compiler-dev on behalf of Robert Olofsson > Sent: Tuesday, January 19, 2016 8:08:19 PM > To: compiler-dev at openjdk.java.net > Subject: Trying to build a more hackable compiler... > > Hi! > > Some time ago I started reading the code for javac and I realized that > it is not a project that is easy to work on. I also realized that there > are other people that want a compiler that is easier to hack. A few > of the things that are requested are: > * Grammar based parser > * Better multi threading > > I did try to make a few patches for javac to at least make it better > multi threaded, but realized that this was really hard to do, at > least for the code I looked at. Too much global state in the lexer > and parser. > > I realized that I actually did take a few compiler related courses > so time to build something on my own, as a proof of concept. In case > you want to take a look: https://github.com/robert-olofsson/parjac > > Initial thoughts: > * Making lexing + parsing run in parallel is easy > * Setting classes on types in parallel is easy > * Checking other semantics in parallel is easy > * Writing bytecode in parallel is easy > > Parsing a reasonably big code tree (27195 files with > 11022 of them being java) and outputting class files > containing hello-world like methods with the correct signatures > is quite a lot faster than javac doing a full compile and my > computer is a nuc i7, so not many cores. > Sure, this is a bit of apples vs oranges, but it still > indicates that it is quite possible to fulfill the wishes > of a grammar based multi threaded compiler. The heavy > part is currently parsing. > > I do know of the antlr-javac experiment, but it seems to > have died, not sure what will happen to it. My experiments > with antlr indicated that it is too hard to use for a java 8 > grammar and it seems like it ended up being slower than > ordinary javac. > > If this is considered advertising a non javac-compiler I do > apologize, my end goal is to make javac (based on current code or some > other code) be a better compiler and for now I only want to show that it > seems possible to make it better. > > /robo > > > > > Spirent Communications e-mail confidentiality. > ------------------------------------------------------------------------ > This e-mail contains confidential and / or privileged information belonging to Spirent Communications plc, its affiliates and / or subsidiaries. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution and / or the taking of any action based upon reliance on the contents of this transmission is strictly forbidden. If you have received this message in error please notify the sender by return e-mail and delete it from your system. > > Spirent Communications plc > Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom. > Tel No. +44 (0) 1293 767676 > Fax No. +44 (0) 1293 767677 > > Registered in England Number 470893 > Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom. > > Or if within the US, > > Spirent Communications, > 27349 Agoura Road, Calabasas, CA, 91301, USA. > Tel No. 1-818-676- 2300 From jonathan.gibbons at oracle.com Tue May 10 15:50:54 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 10 May 2016 08:50:54 -0700 Subject: Trying to build a more hackable compiler... In-Reply-To: References: <20160119200819.129514a0@nuccy.khelekore.org> , <57310D45.3050308@oracle.com> Message-ID: <5732035E.5010504@oracle.com> On 05/10/2016 05:58 AM, Wieland, Jacob wrote: > I refer to the bughttps://bugs.openjdk.java.net/browse/JDK-8039262 which I hope will be addressed again in the future because this degradation is still unacceptable to me. The bug you reference has been fixed. -- Jon From Jacob.Wieland at spirent.com Tue May 10 12:58:38 2016 From: Jacob.Wieland at spirent.com (Wieland, Jacob) Date: Tue, 10 May 2016 12:58:38 +0000 Subject: Trying to build a more hackable compiler... In-Reply-To: <57310D45.3050308@oracle.com> References: <20160119200819.129514a0@nuccy.khelekore.org> , <57310D45.3050308@oracle.com> Message-ID: There seem to have been some checks for bridge-methods added for java 7 which were not done for java 6. As far as I understood, bridge methods can only occur in contexts where generic types occur. Since I only generate java 1.4 code (with no generics), these checks are obviously totally unnecessary (as are other generics-related checks and all checks that only produce warnings). I am told that they are the reason for the massive performance degradation from java 6 to java 7/8/9 of javac (uses 4 times the CPU power, much more memory and still needs 10 to 20% more time than java 6, in my opinion related to garbage collection). I refer to the bug https://bugs.openjdk.java.net/browse/JDK-8039262 which I hope will be addressed again in the future because this degradation is still unacceptable to me. Of course, I would be interested how much more efficient the parallel compiler fares with the given example code ;-) Feel free to use it as a benchmark. It makes heavy use of non-static nested and anonymous classes.  BR, Jacob ________________________________________ From: compiler-dev on behalf of Jonathan Gibbons Sent: Tuesday, May 10, 2016 12:20:53 AM To: compiler-dev at openjdk.java.net Subject: Re: Trying to build a more hackable compiler... You can already disable (or not enable) the "unnecessary" checks with the -Xlint option. In general, the rest of the semantic "checks" are necessary for javac to figure out the meaning of your programs. Did you have any semantic checks or performance issues in mind? -- Jon On 05/09/2016 01:26 AM, Wieland, Jacob wrote: > > If you take suggestions, give the compiler the option to generate-bytecode-only (i.e. turn off all unnecessary semantic checks). This would solve a lot of performance issues I have when compiling generated java-surce-code (that I know is semantically correct, so semantic checks produce only warmth and consume time). > > > > Dr. Jacob Wieland > Senior Software Engineer > ________________________________________ > From: compiler-dev on behalf of Robert Olofsson > Sent: Tuesday, January 19, 2016 8:08:19 PM > To: compiler-dev at openjdk.java.net > Subject: Trying to build a more hackable compiler... > > Hi! > > Some time ago I started reading the code for javac and I realized that > it is not a project that is easy to work on. I also realized that there > are other people that want a compiler that is easier to hack. A few > of the things that are requested are: > * Grammar based parser > * Better multi threading > > I did try to make a few patches for javac to at least make it better > multi threaded, but realized that this was really hard to do, at > least for the code I looked at. Too much global state in the lexer > and parser. > > I realized that I actually did take a few compiler related courses > so time to build something on my own, as a proof of concept. In case > you want to take a look: https://github.com/robert-olofsson/parjac > > Initial thoughts: > * Making lexing + parsing run in parallel is easy > * Setting classes on types in parallel is easy > * Checking other semantics in parallel is easy > * Writing bytecode in parallel is easy > > Parsing a reasonably big code tree (27195 files with > 11022 of them being java) and outputting class files > containing hello-world like methods with the correct signatures > is quite a lot faster than javac doing a full compile and my > computer is a nuc i7, so not many cores. > Sure, this is a bit of apples vs oranges, but it still > indicates that it is quite possible to fulfill the wishes > of a grammar based multi threaded compiler. The heavy > part is currently parsing. > > I do know of the antlr-javac experiment, but it seems to > have died, not sure what will happen to it. My experiments > with antlr indicated that it is too hard to use for a java 8 > grammar and it seems like it ended up being slower than > ordinary javac. > > If this is considered advertising a non javac-compiler I do > apologize, my end goal is to make javac (based on current code or some > other code) be a better compiler and for now I only want to show that it > seems possible to make it better. > > /robo > > > > > Spirent Communications e-mail confidentiality. > ------------------------------------------------------------------------ > This e-mail contains confidential and / or privileged information belonging to Spirent Communications plc, its affiliates and / or subsidiaries. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution and / or the taking of any action based upon reliance on the contents of this transmission is strictly forbidden. If you have received this message in error please notify the sender by return e-mail and delete it from your system. > > Spirent Communications plc > Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom. > Tel No. +44 (0) 1293 767676 > Fax No. +44 (0) 1293 767677 > > Registered in England Number 470893 > Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom. > > Or if within the US, > > Spirent Communications, > 27349 Agoura Road, Calabasas, CA, 91301, USA. > Tel No. 1-818-676- 2300 From jonathan.gibbons at oracle.com Tue May 10 20:37:22 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 10 May 2016 13:37:22 -0700 Subject: RFR: 8150011 Update javac to generate V53.0 class files Message-ID: <57324682.2000406@oracle.com> This is the change to have javac generate v53 class files in conjunction with -target 9 (either explicit or implicit). This change was first widely announced back in January 2016. Announcement: http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-January/003507.html JBS: https://bugs.openjdk.java.net/browse/JDK-8150011 Webrev: http://cr.openjdk.java.net/~jjg/8150011/webrev.00/ -- Jon From joe.darcy at oracle.com Tue May 10 21:16:37 2016 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 10 May 2016 14:16:37 -0700 Subject: RFR: 8150011 Update javac to generate V53.0 class files In-Reply-To: <57324682.2000406@oracle.com> References: <57324682.2000406@oracle.com> Message-ID: <280975d1-b6b0-25f0-27b3-8a6d9a07ad91@oracle.com> Looks good Jon; cheers, -Joe On 5/10/2016 1:37 PM, Jonathan Gibbons wrote: > This is the change to have javac generate v53 class files in > conjunction with -target 9 (either explicit or implicit). > This change was first widely announced back in January 2016. > > Announcement: > http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-January/003507.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8150011 > Webrev: http://cr.openjdk.java.net/~jjg/8150011/webrev.00/ > > -- Jon From vicente.romero at oracle.com Wed May 11 22:27:29 2016 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Wed, 11 May 2016 18:27:29 -0400 Subject: RFR: 8149843, 8150111 Two small changes to StandardJavaFileManager API In-Reply-To: <572D2752.3000607@oracle.com> References: <572D2752.3000607@oracle.com> Message-ID: <5733B1D1.7070304@oracle.com> approved, Thanks, Vicente On 05/06/2016 07:22 PM, Jonathan Gibbons wrote: > This is for two small changes to the StandardJavaFileManager API. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8149843 > StandardJavaFileManager should provide a way to get paths from strings > > JBS: https://bugs.openjdk.java.net/browse/JDK-8150111 > Need to change signature of StandardJavaFileManager.setLocationFromPaths > > With these changes, all standard uses of Paths.get are replaced by using > a user-provided function, defaulting to Paths::get. > > The exceptions are: > file names specified on the javac command line > file names used in some internal debugging/tracing features in javac > file names used in sjavac > > Combined specdiff: http://cr.openjdk.java.net/~jjg/8149843/specdiff.00/ > Combined webrev: http://cr.openjdk.java.net/~jjg/8149843/webrev.00/ > > -- Jon From jan.lahoda at oracle.com Thu May 12 15:21:56 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 12 May 2016 17:21:56 +0200 Subject: RFR: 8149843, 8150111 Two small changes to StandardJavaFileManager API In-Reply-To: <5733B1D1.7070304@oracle.com> References: <572D2752.3000607@oracle.com> <5733B1D1.7070304@oracle.com> Message-ID: <57349F94.6000002@oracle.com> Looks fine to me too. Jan On 12.5.2016 00:27, Vicente-Arturo Romero-Zaldivar wrote: > approved, > > Thanks, > Vicente > > On 05/06/2016 07:22 PM, Jonathan Gibbons wrote: >> This is for two small changes to the StandardJavaFileManager API. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8149843 >> StandardJavaFileManager should provide a way to get paths from strings >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8150111 >> Need to change signature of StandardJavaFileManager.setLocationFromPaths >> >> With these changes, all standard uses of Paths.get are replaced by using >> a user-provided function, defaulting to Paths::get. >> >> The exceptions are: >> file names specified on the javac command line >> file names used in some internal debugging/tracing features in javac >> file names used in sjavac >> >> Combined specdiff: http://cr.openjdk.java.net/~jjg/8149843/specdiff.00/ >> Combined webrev: http://cr.openjdk.java.net/~jjg/8149843/webrev.00/ >> >> -- Jon > From jonathan.gibbons at oracle.com Thu May 12 18:26:51 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 12 May 2016 11:26:51 -0700 Subject: RFR: 8149843, 8150111 Two small changes to StandardJavaFileManager API In-Reply-To: <57349F94.6000002@oracle.com> References: <572D2752.3000607@oracle.com> <5733B1D1.7070304@oracle.com> <57349F94.6000002@oracle.com> Message-ID: <5734CAEB.4090706@oracle.com> After merging with the latest jdk9/dev bits, some additional minor changes are required in jdk.jshell, to avoid the use of Iterable. The most obvious change is simply to use List instead, as shown here. $ hg diff src/jdk.jshell diff -r c51b40933e0c src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java --- a/src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java Wed May 11 20:28:22 2016 +0000 +++ b/src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java Thu May 12 11:25:46 2016 -0700 @@ -1045,7 +1045,7 @@ public SourceCache(AnalyzeTask originalTask) { this.originalTask = originalTask; - Iterable sources = findSources(); + List sources = findSources(); if (sources.iterator().hasNext()) { StandardJavaFileManager fm = compiler.getStandardFileManager(null, null, null); try { @@ -1145,9 +1145,9 @@ } } - private Iterable availableSources; + private List availableSources; - private Iterable findSources() { + private List findSources() { if (availableSources != null) { return availableSources; } On 05/12/2016 08:21 AM, Jan Lahoda wrote: > Looks fine to me too. > > Jan > > On 12.5.2016 00:27, Vicente-Arturo Romero-Zaldivar wrote: >> approved, >> >> Thanks, >> Vicente >> >> On 05/06/2016 07:22 PM, Jonathan Gibbons wrote: >>> This is for two small changes to the StandardJavaFileManager API. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8149843 >>> StandardJavaFileManager should provide a way to get paths from strings >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8150111 >>> Need to change signature of >>> StandardJavaFileManager.setLocationFromPaths >>> >>> With these changes, all standard uses of Paths.get are replaced by >>> using >>> a user-provided function, defaulting to Paths::get. >>> >>> The exceptions are: >>> file names specified on the javac command line >>> file names used in some internal debugging/tracing features in >>> javac >>> file names used in sjavac >>> >>> Combined specdiff: http://cr.openjdk.java.net/~jjg/8149843/specdiff.00/ >>> Combined webrev: http://cr.openjdk.java.net/~jjg/8149843/webrev.00/ >>> >>> -- Jon >> From jan.lahoda at oracle.com Thu May 12 18:31:40 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 12 May 2016 20:31:40 +0200 Subject: RFR: 8149843, 8150111 Two small changes to StandardJavaFileManager API In-Reply-To: <5734CAEB.4090706@oracle.com> References: <572D2752.3000607@oracle.com> <5733B1D1.7070304@oracle.com> <57349F94.6000002@oracle.com> <5734CAEB.4090706@oracle.com> Message-ID: <5734CC0C.2060607@oracle.com> Seems fine. Jan On 12.5.2016 20:26, Jonathan Gibbons wrote: > After merging with the latest jdk9/dev bits, some additional minor > changes are required in jdk.jshell, to avoid the use of Iterable extends Path>. The most obvious change is simply to use List > instead, as shown here. > > $ hg diff src/jdk.jshell > diff -r c51b40933e0c > src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java > --- > a/src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java > Wed May 11 20:28:22 2016 +0000 > +++ > b/src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java > Thu May 12 11:25:46 2016 -0700 > @@ -1045,7 +1045,7 @@ > > public SourceCache(AnalyzeTask originalTask) { > this.originalTask = originalTask; > - Iterable sources = findSources(); > + List sources = findSources(); > if (sources.iterator().hasNext()) { > StandardJavaFileManager fm = > compiler.getStandardFileManager(null, null, null); > try { > @@ -1145,9 +1145,9 @@ > } > } > > - private Iterable availableSources; > + private List availableSources; > > - private Iterable findSources() { > + private List findSources() { > if (availableSources != null) { > return availableSources; > } > > > > On 05/12/2016 08:21 AM, Jan Lahoda wrote: >> Looks fine to me too. >> >> Jan >> >> On 12.5.2016 00:27, Vicente-Arturo Romero-Zaldivar wrote: >>> approved, >>> >>> Thanks, >>> Vicente >>> >>> On 05/06/2016 07:22 PM, Jonathan Gibbons wrote: >>>> This is for two small changes to the StandardJavaFileManager API. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8149843 >>>> StandardJavaFileManager should provide a way to get paths from strings >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8150111 >>>> Need to change signature of >>>> StandardJavaFileManager.setLocationFromPaths >>>> >>>> With these changes, all standard uses of Paths.get are replaced by >>>> using >>>> a user-provided function, defaulting to Paths::get. >>>> >>>> The exceptions are: >>>> file names specified on the javac command line >>>> file names used in some internal debugging/tracing features in >>>> javac >>>> file names used in sjavac >>>> >>>> Combined specdiff: http://cr.openjdk.java.net/~jjg/8149843/specdiff.00/ >>>> Combined webrev: http://cr.openjdk.java.net/~jjg/8149843/webrev.00/ >>>> >>>> -- Jon >>> > From vicente.romero at oracle.com Thu May 12 18:31:41 2016 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Thu, 12 May 2016 14:31:41 -0400 Subject: RFR: 8149843, 8150111 Two small changes to StandardJavaFileManager API In-Reply-To: <5734CAEB.4090706@oracle.com> References: <572D2752.3000607@oracle.com> <5733B1D1.7070304@oracle.com> <57349F94.6000002@oracle.com> <5734CAEB.4090706@oracle.com> Message-ID: <5734CC0D.2060200@oracle.com> I'm OK with the last changes, Thanks, Vicente On 05/12/2016 02:26 PM, Jonathan Gibbons wrote: > After merging with the latest jdk9/dev bits, some additional minor > changes are required in jdk.jshell, to avoid the use of Iterable extends Path>. The most obvious change is simply to use List > instead, as shown here. > > $ hg diff src/jdk.jshell > diff -r c51b40933e0c > src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java > --- > a/src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java > Wed May 11 20:28:22 2016 +0000 > +++ > b/src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java > Thu May 12 11:25:46 2016 -0700 > @@ -1045,7 +1045,7 @@ > > public SourceCache(AnalyzeTask originalTask) { > this.originalTask = originalTask; > - Iterable sources = findSources(); > + List sources = findSources(); > if (sources.iterator().hasNext()) { > StandardJavaFileManager fm = > compiler.getStandardFileManager(null, null, null); > try { > @@ -1145,9 +1145,9 @@ > } > } > > - private Iterable availableSources; > + private List availableSources; > > - private Iterable findSources() { > + private List findSources() { > if (availableSources != null) { > return availableSources; > } > > > > On 05/12/2016 08:21 AM, Jan Lahoda wrote: >> Looks fine to me too. >> >> Jan >> >> On 12.5.2016 00:27, Vicente-Arturo Romero-Zaldivar wrote: >>> approved, >>> >>> Thanks, >>> Vicente >>> >>> On 05/06/2016 07:22 PM, Jonathan Gibbons wrote: >>>> This is for two small changes to the StandardJavaFileManager API. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8149843 >>>> StandardJavaFileManager should provide a way to get paths from strings >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8150111 >>>> Need to change signature of >>>> StandardJavaFileManager.setLocationFromPaths >>>> >>>> With these changes, all standard uses of Paths.get are replaced by >>>> using >>>> a user-provided function, defaulting to Paths::get. >>>> >>>> The exceptions are: >>>> file names specified on the javac command line >>>> file names used in some internal debugging/tracing features in >>>> javac >>>> file names used in sjavac >>>> >>>> Combined specdiff: >>>> http://cr.openjdk.java.net/~jjg/8149843/specdiff.00/ >>>> Combined webrev: http://cr.openjdk.java.net/~jjg/8149843/webrev.00/ >>>> >>>> -- Jon >>> > From iris.clark at oracle.com Fri May 13 23:20:23 2016 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 13 May 2016 16:20:23 -0700 (PDT) Subject: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version Message-ID: Hi. Reviving this work from a few months back. Please review the following changes to move jdk.Version to jdk.lang.Runtime.Version. Bug 8144062: Move jdk.Version to java.lang.Runtime.Version https://bugs.openjdk.java.net/browse/JDK-8144062 webrev http://cr.openjdk.java.net/~iris/verona/8144062/webrev.1/ When jdk.Version was initially pushed in jdk-9+1-5, it was Improperly exported by java.base. After exploring a few options, the best choice was to move jdk.Version to java.lang.Runtime.Version (a nested class of Runtime). By making Version an SE API, it may be exported by the java.base module. As part of the move, a limited number of chnages were made to the Version class: - Change package name and class declaration (to static) - Eliminate use of "JDK" when describing a Java SE API - Initial clarifications related to zeros (trailing vs. Internal components) - Small typographical and grammatical enhancements - Indentation The complete Runtime.Version specification is available here: http://cr.openjdk.java.net/~iris/verona/8144062/doc.1/java/lang/Runtime.Version.html The old jdk.Version.current() was replaced with Runtime.version(). In System.getProperties(), we indicate which version-related system properties may be supported by Runtime.Version. The remaining jdk and langtools file changes are all side-effects of changing jdk.Version.current() to Runtime.version(). Thanks, Iris From forax at univ-mlv.fr Fri May 13 23:31:36 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 14 May 2016 01:31:36 +0200 (CEST) Subject: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version In-Reply-To: References: Message-ID: <1554585217.477366.1463182296059.JavaMail.zimbra@u-pem.fr> Hi Iris, is there a way to avoid to use regex when parsing the version ? java.lang.Runtime.Version is used during the boot process, so now every Java programs loads a bunch of classes related to java.util.regex even if they do not use any regex or use another regex engine (like Nashorn or JRuby). regards, R?mi ----- Mail original ----- > De: "Iris Clark" > ?: "Java Core Libs" , compiler-dev at openjdk.java.net > Cc: verona-dev at openjdk.java.net > Envoy?: Samedi 14 Mai 2016 01:20:23 > Objet: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version > > Hi. > > Reviving this work from a few months back. > > Please review the following changes to move jdk.Version to > java.lang.Runtime.Version. > > Bug > > 8144062: Move jdk.Version to java.lang.Runtime.Version > https://bugs.openjdk.java.net/browse/JDK-8144062 > > webrev > > http://cr.openjdk.java.net/~iris/verona/8144062/webrev.1/ > > When jdk.Version was initially pushed in jdk-9+1-5, it was > Improperly exported by java.base. After exploring a few > options, the best choice was to move jdk.Version to > java.lang.Runtime.Version (a nested class of Runtime). By > making Version an SE API, it may be exported by the java.base > module. > > As part of the move, a limited number of chnages were > made to the Version class: > > - Change package name and class declaration (to static) > - Eliminate use of "JDK" when describing a Java SE API > - Initial clarifications related to zeros (trailing vs. > Internal components) > - Small typographical and grammatical enhancements > - Indentation > > The complete Runtime.Version specification is available here: > > http://cr.openjdk.java.net/~iris/verona/8144062/doc.1/java/lang/Runtime.Version.html > > The old jdk.Version.current() was replaced with > Runtime.version(). > > In System.getProperties(), we indicate which version-related > system properties may be supported by Runtime.Version. > > The remaining jdk and langtools file changes are all > side-effects of changing jdk.Version.current() to > Runtime.version(). > > Thanks, > Iris > From iris.clark at oracle.com Mon May 16 17:52:33 2016 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 16 May 2016 10:52:33 -0700 (PDT) Subject: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version In-Reply-To: <1554585217.477366.1463182296059.JavaMail.zimbra@u-pem.fr> References: <1554585217.477366.1463182296059.JavaMail.zimbra@u-pem.fr> Message-ID: Hi, Remi. Thanks for taking the time to review this change. > java.lang.Runtime.Version is used during the boot process I don?t think that Runtime.Version is used during boot because I'm not seeing it loaded with a small test program invoked with "java -verbose:class Hi". In fact, I'm not seeing a difference in the number of loaded classes between promoted build 118 and my build for 8144062 (based on jdk9/dev). See appended stats. If my test program is in a JAR file, then more classes are loaded including Runtime.Version; however the equivalent number of classes are loaded before my changes too. The performance problem identified by the following bug should resolve this issue: 8150678: JarFile stream() and entries(0 methods need performance enhancement https://bugs.openjdk.java.net/browse/JDK-8150678 Regards, Iris ----- $ cat Hi.java public class Hi { public static void main(String ... args) { System.out.println("hi"); System.exit(42); } $ wc Hi.ver* 501 2000 39758 Hi.verbose-118 576 2300 45915 Hi.verbose-118-jar 501 2000 39734 Hi.verbose-8144062 576 2300 45905 Hi.verbose-8144062-jar 2154 8600 171312 total -----Original Message----- From: Remi Forax [mailto:forax at univ-mlv.fr] Sent: Friday, May 13, 2016 4:32 PM To: Iris Clark Cc: Java Core Libs; compiler-dev at openjdk.java.net; verona-dev at openjdk.java.net Subject: Re: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version Hi Iris, is there a way to avoid to use regex when parsing the version ? java.lang.Runtime.Version is used during the boot process, so now every Java programs loads a bunch of classes related to java.util.regex even if they do not use any regex or use another regex engine (like Nashorn or JRuby). regards, R?mi ----- Mail original ----- > De: "Iris Clark" > ?: "Java Core Libs" , > compiler-dev at openjdk.java.net > Cc: verona-dev at openjdk.java.net > Envoy?: Samedi 14 Mai 2016 01:20:23 > Objet: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version > > Hi. > > Reviving this work from a few months back. > > Please review the following changes to move jdk.Version to > java.lang.Runtime.Version. > > Bug > > 8144062: Move jdk.Version to java.lang.Runtime.Version > https://bugs.openjdk.java.net/browse/JDK-8144062 > > webrev > > http://cr.openjdk.java.net/~iris/verona/8144062/webrev.1/ > > When jdk.Version was initially pushed in jdk-9+1-5, it was Improperly > exported by java.base. After exploring a few options, the best choice > was to move jdk.Version to java.lang.Runtime.Version (a nested class > of Runtime). By making Version an SE API, it may be exported by the > java.base module. > > As part of the move, a limited number of chnages were made to the > Version class: > > - Change package name and class declaration (to static) > - Eliminate use of "JDK" when describing a Java SE API > - Initial clarifications related to zeros (trailing vs. > Internal components) > - Small typographical and grammatical enhancements > - Indentation > > The complete Runtime.Version specification is available here: > > > http://cr.openjdk.java.net/~iris/verona/8144062/doc.1/java/lang/Runtim > e.Version.html > > The old jdk.Version.current() was replaced with Runtime.version(). > > In System.getProperties(), we indicate which version-related system > properties may be supported by Runtime.Version. > > The remaining jdk and langtools file changes are all side-effects of > changing jdk.Version.current() to Runtime.version(). > > Thanks, > Iris > From forax at univ-mlv.fr Mon May 16 18:38:03 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Mon, 16 May 2016 20:38:03 +0200 (CEST) Subject: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version In-Reply-To: References: <1554585217.477366.1463182296059.JavaMail.zimbra@u-pem.fr> Message-ID: <103793588.142588.1463423883417.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Iris Clark" > ?: "Remi Forax" > Cc: "Java Core Libs" , compiler-dev at openjdk.java.net, verona-dev at openjdk.java.net > Envoy?: Lundi 16 Mai 2016 19:52:33 > Objet: RE: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version > > Hi, Remi. Hi Iris, > > Thanks for taking the time to review this change. > > > java.lang.Runtime.Version is used during the boot process > > I don?t think that Runtime.Version is used during boot because > I'm not seeing it loaded with a small test program invoked with > "java -verbose:class Hi". In fact, I'm not seeing a difference > in the number of loaded classes between promoted build 118 and > my build for 8144062 (based on jdk9/dev). See appended stats. > > If my test program is in a JAR file, then more classes are > loaded including Runtime.Version; however the equivalent number > of classes are loaded before my changes too. I've double checked and yes, Runtime.Version is not loaded by default, my bad on this, it's own runtime that has an indirect dependency on Runtime.Version. > > The performance problem identified by the following bug should > resolve this issue: > > 8150678: JarFile stream() and entries(0 methods need performance > enhancement > https://bugs.openjdk.java.net/browse/JDK-8150678 > > Regards, > Iris regards, R?mi > > ----- > $ cat Hi.java > public class Hi { > public static void main(String ... args) { > System.out.println("hi"); > System.exit(42); > } > $ wc Hi.ver* > 501 2000 39758 Hi.verbose-118 > 576 2300 45915 Hi.verbose-118-jar > 501 2000 39734 Hi.verbose-8144062 > 576 2300 45905 Hi.verbose-8144062-jar > 2154 8600 171312 total > > -----Original Message----- > From: Remi Forax [mailto:forax at univ-mlv.fr] > Sent: Friday, May 13, 2016 4:32 PM > To: Iris Clark > Cc: Java Core Libs; compiler-dev at openjdk.java.net; > verona-dev at openjdk.java.net > Subject: Re: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version > > Hi Iris, > is there a way to avoid to use regex when parsing the version ? > > java.lang.Runtime.Version is used during the boot process, so now every Java > programs loads a bunch of classes related to java.util.regex even if they do > not use any regex or use another regex engine (like Nashorn or JRuby). > > regards, > R?mi > > ----- Mail original ----- > > De: "Iris Clark" > > ?: "Java Core Libs" , > > compiler-dev at openjdk.java.net > > Cc: verona-dev at openjdk.java.net > > Envoy?: Samedi 14 Mai 2016 01:20:23 > > Objet: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version > > > > Hi. > > > > Reviving this work from a few months back. > > > > Please review the following changes to move jdk.Version to > > java.lang.Runtime.Version. > > > > Bug > > > > 8144062: Move jdk.Version to java.lang.Runtime.Version > > https://bugs.openjdk.java.net/browse/JDK-8144062 > > > > webrev > > > > http://cr.openjdk.java.net/~iris/verona/8144062/webrev.1/ > > > > When jdk.Version was initially pushed in jdk-9+1-5, it was Improperly > > exported by java.base. After exploring a few options, the best choice > > was to move jdk.Version to java.lang.Runtime.Version (a nested class > > of Runtime). By making Version an SE API, it may be exported by the > > java.base module. > > > > As part of the move, a limited number of chnages were made to the > > Version class: > > > > - Change package name and class declaration (to static) > > - Eliminate use of "JDK" when describing a Java SE API > > - Initial clarifications related to zeros (trailing vs. > > Internal components) > > - Small typographical and grammatical enhancements > > - Indentation > > > > The complete Runtime.Version specification is available here: > > > > > > http://cr.openjdk.java.net/~iris/verona/8144062/doc.1/java/lang/Runtim > > e.Version.html > > > > The old jdk.Version.current() was replaced with Runtime.version(). > > > > In System.getProperties(), we indicate which version-related system > > properties may be supported by Runtime.Version. > > > > The remaining jdk and langtools file changes are all side-effects of > > changing jdk.Version.current() to Runtime.version(). > > > > Thanks, > > Iris > > > From claes.redestad at oracle.com Mon May 16 21:42:09 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 16 May 2016 23:42:09 +0200 Subject: Javadoc performance issue: Configuration.getText uses exceptional flow Message-ID: <573A3EB1.4070308@oracle.com> Hi, while profiling a few javadoc benchmarks that have regressed over the course of JDK 9, I noticed a couple of percent of the time is being spent throwing exceptions which are dealt with as a normal control flow. This proof-of-concept patch exposes a way for the doclet code to ask the message provider if the key exists instead: http://cr.openjdk.java.net/~redestad/scratch/javadoc_rb.01/ ... and consistently show improvements from 3-19% over a range of javadoc microbenchmarks. I've not been able to find a regression in our tracking that matches the improvement pattern, so this might have been around for a while. So if this patch looks reasonable I'll file the bug and send out an RFR. Thanks! /Claes From jonathan.gibbons at oracle.com Mon May 16 22:21:03 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 16 May 2016 15:21:03 -0700 Subject: Javadoc performance issue: Configuration.getText uses exceptional flow In-Reply-To: <573A3EB1.4070308@oracle.com> References: <573A3EB1.4070308@oracle.com> Message-ID: <573A47CF.8060304@oracle.com> The patch would be nicer if the getDocletSpecificMessage() call were only written once instead of twice per enclosing call. -- Jon On 05/16/2016 02:42 PM, Claes Redestad wrote: > Hi, > > while profiling a few javadoc benchmarks that have regressed over the > course of JDK 9, I noticed a couple of percent of the time is being > spent throwing exceptions which are dealt with as a normal control flow. > > This proof-of-concept patch exposes a way for the doclet code to ask > the message provider if the key exists instead: > > http://cr.openjdk.java.net/~redestad/scratch/javadoc_rb.01/ > > ... and consistently show improvements from 3-19% over a range of > javadoc microbenchmarks. > > I've not been able to find a regression in our tracking that matches > the improvement pattern, so this might have been around for a while. > So if this patch looks reasonable I'll file the bug and send out an RFR. > > Thanks! > > /Claes > > From jonathan.gibbons at oracle.com Mon May 16 23:22:55 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 16 May 2016 16:22:55 -0700 Subject: RFR: 8149599: Update Minefield test Message-ID: <573A564F.1020908@oracle.com> This is a change to re-enable the venerable MineField.sh test, which has been somewhat hacked and eventually disabled during the development of Project Jigsaw. While cleaning up and translating the test into Java code, it uncovered a bug in classpath handling in the runtime (JDK-8156989, already fixed by Alan B), and so the shell form of the test has been given a stay of execution for a while. There is a comment in the code to explain the rationale for the JDK 9 cleanup. JBS: https://bugs.openjdk.java.net/browse/JDK-8149599 Webrev: http://cr.openjdk.java.net/~jjg/8149599/webrev.01/ webrev.00 has the test case that exposed JDK-8156989 commented out; webrev.01 has that test case enabled. -- Jon From martinrb at google.com Tue May 17 02:06:19 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 16 May 2016 19:06:19 -0700 Subject: RFR: 8149599: Update Minefield test In-Reply-To: <573A564F.1020908@oracle.com> References: <573A564F.1020908@oracle.com> Message-ID: Looks good to me! I'm happy my weird little test is stil earning its keep. On Mon, May 16, 2016 at 4:22 PM, Jonathan Gibbons wrote: > This is a change to re-enable the venerable MineField.sh test, which has > been somewhat hacked and eventually disabled during the development of > Project Jigsaw. > > While cleaning up and translating the test into Java code, it uncovered a > bug in classpath handling in the runtime (JDK-8156989, already fixed by Alan > B), and so the shell form of the test has been given a stay of execution for > a while. > > There is a comment in the code to explain the rationale for the JDK 9 > cleanup. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8149599 > Webrev: http://cr.openjdk.java.net/~jjg/8149599/webrev.01/ > > webrev.00 has the test case that exposed JDK-8156989 commented out; > webrev.01 has that test case enabled. > > -- Jon From joe.darcy at oracle.com Tue May 17 18:48:02 2016 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 17 May 2016 11:48:02 -0700 Subject: JDK 9 RFR of JDK-6415644 Make javax.lang.model.SourceVersion more informative Message-ID: <1ab4c15f-d0c3-b29f-0109-5ae8e0851d81@oracle.com> Hello, Please review this webrev to add some version-sensitive keyword and name queries: JDK-6415644 Make javax.lang.model.SourceVersion more informative http://cr.openjdk.java.net/~darcy/6415644.0/ Thanks, -Joe From jonathan.gibbons at oracle.com Tue May 17 18:52:39 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 17 May 2016 11:52:39 -0700 Subject: JDK 9 RFR of JDK-6415644 Make javax.lang.model.SourceVersion more informative In-Reply-To: <1ab4c15f-d0c3-b29f-0109-5ae8e0851d81@oracle.com> References: <1ab4c15f-d0c3-b29f-0109-5ae8e0851d81@oracle.com> Message-ID: <573B6877.3040602@oracle.com> Joe, Is there a CCC to reference w.r.t. _ as a keyword? -- Jon On 05/17/2016 11:48 AM, joe darcy wrote: > Hello, > > Please review this webrev to add some version-sensitive keyword and > name queries: > > JDK-6415644 Make javax.lang.model.SourceVersion more informative > > http://cr.openjdk.java.net/~darcy/6415644.0/ > > Thanks, > > -Joe > From jan.lahoda at oracle.com Tue May 17 20:00:32 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 17 May 2016 22:00:32 +0200 Subject: JDK 9 RFR of JDK-6415644 Make javax.lang.model.SourceVersion more informative In-Reply-To: <573B6877.3040602@oracle.com> References: <1ab4c15f-d0c3-b29f-0109-5ae8e0851d81@oracle.com> <573B6877.3040602@oracle.com> Message-ID: <573B7860.1020606@oracle.com> Hi Jon, '_' as a one-character identifier was disallowed under JDK-8061549: https://bugs.openjdk.java.net/browse/JDK-8061549 Jan On 17.5.2016 20:52, Jonathan Gibbons wrote: > Joe, > > Is there a CCC to reference w.r.t. _ as a keyword? > > -- Jon > > > On 05/17/2016 11:48 AM, joe darcy wrote: >> Hello, >> >> Please review this webrev to add some version-sensitive keyword and >> name queries: >> >> JDK-6415644 Make javax.lang.model.SourceVersion more informative >> >> http://cr.openjdk.java.net/~darcy/6415644.0/ >> >> Thanks, >> >> -Joe >> > From jonathan.gibbons at oracle.com Tue May 17 20:07:13 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 17 May 2016 13:07:13 -0700 Subject: JDK 9 RFR of JDK-6415644 Make javax.lang.model.SourceVersion more informative In-Reply-To: <573B7860.1020606@oracle.com> References: <1ab4c15f-d0c3-b29f-0109-5ae8e0851d81@oracle.com> <573B6877.3040602@oracle.com> <573B7860.1020606@oracle.com> Message-ID: <573B79F1.9080200@oracle.com> I knew the rules for '_' were being updated; I had not appreciated it would come back as a keyword. This is the reference I was looking for: https://bugs.openjdk.java.net/browse/JDK-8065599 -- Jon On 05/17/2016 01:00 PM, Jan Lahoda wrote: > Hi Jon, > > '_' as a one-character identifier was disallowed under JDK-8061549: > https://bugs.openjdk.java.net/browse/JDK-8061549 > > Jan > > On 17.5.2016 20:52, Jonathan Gibbons wrote: >> Joe, >> >> Is there a CCC to reference w.r.t. _ as a keyword? >> >> -- Jon >> >> >> On 05/17/2016 11:48 AM, joe darcy wrote: >>> Hello, >>> >>> Please review this webrev to add some version-sensitive keyword and >>> name queries: >>> >>> JDK-6415644 Make javax.lang.model.SourceVersion more informative >>> >>> http://cr.openjdk.java.net/~darcy/6415644.0/ >>> >>> Thanks, >>> >>> -Joe >>> >> From jonathan.gibbons at oracle.com Tue May 17 20:11:53 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 17 May 2016 13:11:53 -0700 Subject: JDK 9 RFR of JDK-6415644 Make javax.lang.model.SourceVersion more informative In-Reply-To: <1ab4c15f-d0c3-b29f-0109-5ae8e0851d81@oracle.com> References: <1ab4c15f-d0c3-b29f-0109-5ae8e0851d81@oracle.com> Message-ID: <573B7B09.6050708@oracle.com> Looks OK to me. You could micro-optimize these lines 318 String id = s.toString(); 319 if ("_".equals(id)) { to use .contentEquals and aboid a possibly unnecessary .toString(). -- Jon On 05/17/2016 11:48 AM, joe darcy wrote: > Hello, > > Please review this webrev to add some version-sensitive keyword and > name queries: > > JDK-6415644 Make javax.lang.model.SourceVersion more informative > > http://cr.openjdk.java.net/~darcy/6415644.0/ > > Thanks, > > -Joe > From jonathan.gibbons at oracle.com Tue May 17 21:10:55 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 17 May 2016 14:10:55 -0700 Subject: JDK 9 RFR of JDK-6415644 Make javax.lang.model.SourceVersion more informative In-Reply-To: <573B7B09.6050708@oracle.com> References: <1ab4c15f-d0c3-b29f-0109-5ae8e0851d81@oracle.com> <573B7B09.6050708@oracle.com> Message-ID: <573B88DF.4070906@oracle.com> That being said, the implementation does not appear to give what might be considered correct answers to isKeyword("assert", SourceVersion.RELEASE0); isKeyword("enum", SourceVersion.RELEASE0); I can't help feeling that the body of isKeyword is likely to evolve into a strings-in-switch ;-) -- Jon On 05/17/2016 01:11 PM, Jonathan Gibbons wrote: > Looks OK to me. > > You could micro-optimize these lines > > 318 String id = s.toString(); > 319 if ("_".equals(id)) { > > to use .contentEquals and aboid a possibly unnecessary .toString(). > > -- Jon > > > > On 05/17/2016 11:48 AM, joe darcy wrote: >> Hello, >> >> Please review this webrev to add some version-sensitive keyword and >> name queries: >> >> JDK-6415644 Make javax.lang.model.SourceVersion more informative >> >> http://cr.openjdk.java.net/~darcy/6415644.0/ >> >> Thanks, >> >> -Joe >> > From joe.darcy at oracle.com Tue May 17 22:03:41 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 17 May 2016 15:03:41 -0700 Subject: JDK 9 RFR of JDK-6415644 Make javax.lang.model.SourceVersion more informative In-Reply-To: <573B88DF.4070906@oracle.com> References: <1ab4c15f-d0c3-b29f-0109-5ae8e0851d81@oracle.com> <573B7B09.6050708@oracle.com> <573B88DF.4070906@oracle.com> Message-ID: <573B953D.20102@oracle.com> Hi Jon, On 5/17/2016 2:10 PM, Jonathan Gibbons wrote: > That being said, the implementation does not appear to give what > might be considered correct answers to > isKeyword("assert", SourceVersion.RELEASE0); > isKeyword("enum", SourceVersion.RELEASE0); > > I can't help feeling that the body of isKeyword is likely to evolve > into a strings-in-switch ;-) As you wish, including version-sensitive results and tests for "strictfp", "assert", "enum", etc. Thanks, -Joe > > -- Jon > > On 05/17/2016 01:11 PM, Jonathan Gibbons wrote: >> Looks OK to me. >> >> You could micro-optimize these lines >> >> 318 String id = s.toString(); >> 319 if ("_".equals(id)) { >> >> to use .contentEquals and aboid a possibly unnecessary .toString(). >> >> -- Jon >> >> >> >> On 05/17/2016 11:48 AM, joe darcy wrote: >>> Hello, >>> >>> Please review this webrev to add some version-sensitive keyword and >>> name queries: >>> >>> JDK-6415644 Make javax.lang.model.SourceVersion more informative >>> >>> http://cr.openjdk.java.net/~darcy/6415644.0/ >>> >>> Thanks, >>> >>> -Joe >>> >> > From joe.darcy at oracle.com Tue May 17 22:04:49 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 17 May 2016 15:04:49 -0700 Subject: JDK 9 RFR of JDK-6415644 Make javax.lang.model.SourceVersion more informative In-Reply-To: <573B953D.20102@oracle.com> References: <1ab4c15f-d0c3-b29f-0109-5ae8e0851d81@oracle.com> <573B7B09.6050708@oracle.com> <573B88DF.4070906@oracle.com> <573B953D.20102@oracle.com> Message-ID: <573B9580.9030303@oracle.com> PS And know remembering to include the new link! http://cr.openjdk.java.net/~darcy/6415644.1/ -Joe On 5/17/2016 3:03 PM, Joseph D. Darcy wrote: > Hi Jon, > > On 5/17/2016 2:10 PM, Jonathan Gibbons wrote: >> That being said, the implementation does not appear to give what >> might be considered correct answers to >> isKeyword("assert", SourceVersion.RELEASE0); >> isKeyword("enum", SourceVersion.RELEASE0); >> >> I can't help feeling that the body of isKeyword is likely to evolve >> into a strings-in-switch ;-) > > As you wish, including version-sensitive results and tests for > "strictfp", "assert", "enum", etc. > > Thanks, > > -Joe > > >> >> -- Jon >> >> On 05/17/2016 01:11 PM, Jonathan Gibbons wrote: >>> Looks OK to me. >>> >>> You could micro-optimize these lines >>> >>> 318 String id = s.toString(); >>> 319 if ("_".equals(id)) { >>> >>> to use .contentEquals and aboid a possibly unnecessary .toString(). >>> >>> -- Jon >>> >>> >>> >>> On 05/17/2016 11:48 AM, joe darcy wrote: >>>> Hello, >>>> >>>> Please review this webrev to add some version-sensitive keyword and >>>> name queries: >>>> >>>> JDK-6415644 Make javax.lang.model.SourceVersion more informative >>>> >>>> http://cr.openjdk.java.net/~darcy/6415644.0/ >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>> >> > From jonathan.gibbons at oracle.com Tue May 17 22:24:52 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 17 May 2016 15:24:52 -0700 Subject: JDK 9 RFR of JDK-6415644 Make javax.lang.model.SourceVersion more informative In-Reply-To: <573B9580.9030303@oracle.com> References: <1ab4c15f-d0c3-b29f-0109-5ae8e0851d81@oracle.com> <573B7B09.6050708@oracle.com> <573B88DF.4070906@oracle.com> <573B953D.20102@oracle.com> <573B9580.9030303@oracle.com> Message-ID: <573B9A34.4010208@oracle.com> OK, I have to ask, what is the ordering of the cases? :-) In the array in the previous version, they were (mostly) sorted alphabetically down the columns. ("for" If" "goto" "implements" was a bit anomalous.) The sort in cases labels is more cryptic, leading me to look for acrostics and other hidden messages to aliens. Aha, I think I've found the hidden meaning! Who else can spot it? -- Jon On 05/17/2016 03:04 PM, Joseph D. Darcy wrote: > PS And know remembering to include the new link! > > http://cr.openjdk.java.net/~darcy/6415644.1/ > > -Joe > > On 5/17/2016 3:03 PM, Joseph D. Darcy wrote: >> Hi Jon, >> >> On 5/17/2016 2:10 PM, Jonathan Gibbons wrote: >>> That being said, the implementation does not appear to give what >>> might be considered correct answers to >>> isKeyword("assert", SourceVersion.RELEASE0); >>> isKeyword("enum", SourceVersion.RELEASE0); >>> >>> I can't help feeling that the body of isKeyword is likely to evolve >>> into a strings-in-switch ;-) >> >> As you wish, including version-sensitive results and tests for >> "strictfp", "assert", "enum", etc. >> >> Thanks, >> >> -Joe >> >> >>> >>> -- Jon >>> >>> On 05/17/2016 01:11 PM, Jonathan Gibbons wrote: >>>> Looks OK to me. >>>> >>>> You could micro-optimize these lines >>>> >>>> 318 String id = s.toString(); >>>> 319 if ("_".equals(id)) { >>>> >>>> to use .contentEquals and aboid a possibly unnecessary .toString(). >>>> >>>> -- Jon >>>> >>>> >>>> >>>> On 05/17/2016 11:48 AM, joe darcy wrote: >>>>> Hello, >>>>> >>>>> Please review this webrev to add some version-sensitive keyword >>>>> and name queries: >>>>> >>>>> JDK-6415644 Make javax.lang.model.SourceVersion more informative >>>>> >>>>> http://cr.openjdk.java.net/~darcy/6415644.0/ >>>>> >>>>> Thanks, >>>>> >>>>> -Joe >>>>> >>>> >>> >> > From joe.darcy at oracle.com Tue May 17 22:40:02 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 17 May 2016 15:40:02 -0700 Subject: JDK 9 RFR of JDK-6415644 Make javax.lang.model.SourceVersion more informative In-Reply-To: <573B9A34.4010208@oracle.com> References: <1ab4c15f-d0c3-b29f-0109-5ae8e0851d81@oracle.com> <573B7B09.6050708@oracle.com> <573B88DF.4070906@oracle.com> <573B953D.20102@oracle.com> <573B9580.9030303@oracle.com> <573B9A34.4010208@oracle.com> Message-ID: <573B9DC2.2020008@oracle.com> On 5/17/2016 3:24 PM, Jonathan Gibbons wrote: > OK, I have to ask, what is the ordering of the cases? :-) > > In the array in the previous version, they were (mostly) sorted > alphabetically down > the columns. ("for" If" "goto" "implements" was a bit anomalous.) > The sort in cases labels is more cryptic, leading me to look for > acrostics and other > hidden messages to aliens. > > Aha, I think I've found the hidden meaning! Who else can spot it? ;-) IIRC, the original ordering of the set construction matched the ordering of the listing in the corresponding section of the JLS. The new order resulted from cut-and-pasting the 5 columns of the set construction into 4 columns of cases. I'd be happy to reorder this more conceptually access (or is it visibility?) modifiers "public", "protected", "private"; flow control "if", "do", "while", ... -Joe > > -- Jon > > > On 05/17/2016 03:04 PM, Joseph D. Darcy wrote: >> PS And know remembering to include the new link! >> >> http://cr.openjdk.java.net/~darcy/6415644.1/ >> >> -Joe >> >> On 5/17/2016 3:03 PM, Joseph D. Darcy wrote: >>> Hi Jon, >>> >>> On 5/17/2016 2:10 PM, Jonathan Gibbons wrote: >>>> That being said, the implementation does not appear to give what >>>> might be considered correct answers to >>>> isKeyword("assert", SourceVersion.RELEASE0); >>>> isKeyword("enum", SourceVersion.RELEASE0); >>>> >>>> I can't help feeling that the body of isKeyword is likely to evolve >>>> into a strings-in-switch ;-) >>> >>> As you wish, including version-sensitive results and tests for >>> "strictfp", "assert", "enum", etc. >>> >>> Thanks, >>> >>> -Joe >>> >>> >>>> >>>> -- Jon >>>> >>>> On 05/17/2016 01:11 PM, Jonathan Gibbons wrote: >>>>> Looks OK to me. >>>>> >>>>> You could micro-optimize these lines >>>>> >>>>> 318 String id = s.toString(); >>>>> 319 if ("_".equals(id)) { >>>>> >>>>> to use .contentEquals and aboid a possibly unnecessary .toString(). >>>>> >>>>> -- Jon >>>>> >>>>> >>>>> >>>>> On 05/17/2016 11:48 AM, joe darcy wrote: >>>>>> Hello, >>>>>> >>>>>> Please review this webrev to add some version-sensitive keyword >>>>>> and name queries: >>>>>> >>>>>> JDK-6415644 Make javax.lang.model.SourceVersion more informative >>>>>> >>>>>> http://cr.openjdk.java.net/~darcy/6415644.0/ >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Joe >>>>>> >>>>> >>>> >>> >> > From jonathan.gibbons at oracle.com Tue May 17 23:28:07 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 17 May 2016 16:28:07 -0700 Subject: JDK 9 RFR of JDK-6415644 Make javax.lang.model.SourceVersion more informative In-Reply-To: <573B9DC2.2020008@oracle.com> References: <1ab4c15f-d0c3-b29f-0109-5ae8e0851d81@oracle.com> <573B7B09.6050708@oracle.com> <573B88DF.4070906@oracle.com> <573B953D.20102@oracle.com> <573B9580.9030303@oracle.com> <573B9A34.4010208@oracle.com> <573B9DC2.2020008@oracle.com> Message-ID: <573BA907.2000803@oracle.com> Either alphabetic or grouped by function would be good. -- Jon On 05/17/2016 03:40 PM, Joseph D. Darcy wrote: > > On 5/17/2016 3:24 PM, Jonathan Gibbons wrote: >> OK, I have to ask, what is the ordering of the cases? :-) >> >> In the array in the previous version, they were (mostly) sorted >> alphabetically down >> the columns. ("for" If" "goto" "implements" was a bit anomalous.) >> The sort in cases labels is more cryptic, leading me to look for >> acrostics and other >> hidden messages to aliens. >> >> Aha, I think I've found the hidden meaning! Who else can spot it? > > ;-) > > IIRC, the original ordering of the set construction matched the > ordering of the listing in the corresponding section of the JLS. > > The new order resulted from cut-and-pasting the 5 columns of the set > construction into 4 columns of cases. > > I'd be happy to reorder this more conceptually access (or is it > visibility?) modifiers "public", "protected", "private"; flow control > "if", "do", "while", ... > > -Joe > >> >> -- Jon >> >> >> On 05/17/2016 03:04 PM, Joseph D. Darcy wrote: >>> PS And know remembering to include the new link! >>> >>> http://cr.openjdk.java.net/~darcy/6415644.1/ >>> >>> -Joe >>> >>> On 5/17/2016 3:03 PM, Joseph D. Darcy wrote: >>>> Hi Jon, >>>> >>>> On 5/17/2016 2:10 PM, Jonathan Gibbons wrote: >>>>> That being said, the implementation does not appear to give what >>>>> might be considered correct answers to >>>>> isKeyword("assert", SourceVersion.RELEASE0); >>>>> isKeyword("enum", SourceVersion.RELEASE0); >>>>> >>>>> I can't help feeling that the body of isKeyword is likely to >>>>> evolve into a strings-in-switch ;-) >>>> >>>> As you wish, including version-sensitive results and tests for >>>> "strictfp", "assert", "enum", etc. >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>>> >>>>> >>>>> -- Jon >>>>> >>>>> On 05/17/2016 01:11 PM, Jonathan Gibbons wrote: >>>>>> Looks OK to me. >>>>>> >>>>>> You could micro-optimize these lines >>>>>> >>>>>> 318 String id = s.toString(); >>>>>> 319 if ("_".equals(id)) { >>>>>> >>>>>> to use .contentEquals and aboid a possibly unnecessary .toString(). >>>>>> >>>>>> -- Jon >>>>>> >>>>>> >>>>>> >>>>>> On 05/17/2016 11:48 AM, joe darcy wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review this webrev to add some version-sensitive keyword >>>>>>> and name queries: >>>>>>> >>>>>>> JDK-6415644 Make javax.lang.model.SourceVersion more >>>>>>> informative >>>>>>> >>>>>>> http://cr.openjdk.java.net/~darcy/6415644.0/ >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -Joe >>>>>>> >>>>>> >>>>> >>>> >>> >> > From mandy.chung at oracle.com Wed May 18 17:40:27 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 18 May 2016 10:40:27 -0700 Subject: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version In-Reply-To: References: Message-ID: <29AA7813-44E0-4BB1-937E-1BCAB46F9367@oracle.com> > On May 13, 2016, at 4:20 PM, Iris Clark wrote: > > Hi. > > Reviving this work from a few months back. > > Please review the following changes to move jdk.Version to > jdk.lang.Runtime.Version. > > Bug > > 8144062: Move jdk.Version to java.lang.Runtime.Version > https://bugs.openjdk.java.net/browse/JDK-8144062 > > webrev > > http://cr.openjdk.java.net/~iris/verona/8144062/webrev.1/ The change looks fine. Minor comments: 1178 * @throws IllegalArgumentException 1179 * If the given string cannot be interpreted as a valid 1180 * version 1185 * @throws NumberFormatException 1186 * If an element of the version number or the build number 1187 * cannot be represented as an {@link Integer} It?s okay to specify @throws NumberFormatException while @throws IAE (merging the description) should be adequate (the implementation stays the same). Something you can consider in the future. 1189 * @return This version It seems clearer to say "@return the Version of the given string? (this is a static method and no ?This version?) Mandy From joe.darcy at oracle.com Wed May 18 18:15:52 2016 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 18 May 2016 11:15:52 -0700 Subject: JDK 9 RFR of JDK-6415644 Make javax.lang.model.SourceVersion more informative In-Reply-To: <573BA907.2000803@oracle.com> References: <1ab4c15f-d0c3-b29f-0109-5ae8e0851d81@oracle.com> <573B7B09.6050708@oracle.com> <573B88DF.4070906@oracle.com> <573B953D.20102@oracle.com> <573B9580.9030303@oracle.com> <573B9A34.4010208@oracle.com> <573B9DC2.2020008@oracle.com> <573BA907.2000803@oracle.com> Message-ID: <6a0d3479-c3c0-b815-e287-02faf33f8256@oracle.com> Now grouped by function in: http://cr.openjdk.java.net/~darcy/6415644.2/ Cheers, -Joe On 5/17/2016 4:28 PM, Jonathan Gibbons wrote: > Either alphabetic or grouped by function would be good. > > -- Jon > > > On 05/17/2016 03:40 PM, Joseph D. Darcy wrote: >> >> On 5/17/2016 3:24 PM, Jonathan Gibbons wrote: >>> OK, I have to ask, what is the ordering of the cases? :-) >>> >>> In the array in the previous version, they were (mostly) sorted >>> alphabetically down >>> the columns. ("for" If" "goto" "implements" was a bit anomalous.) >>> The sort in cases labels is more cryptic, leading me to look for >>> acrostics and other >>> hidden messages to aliens. >>> >>> Aha, I think I've found the hidden meaning! Who else can spot it? >> >> ;-) >> >> IIRC, the original ordering of the set construction matched the >> ordering of the listing in the corresponding section of the JLS. >> >> The new order resulted from cut-and-pasting the 5 columns of the set >> construction into 4 columns of cases. >> >> I'd be happy to reorder this more conceptually access (or is it >> visibility?) modifiers "public", "protected", "private"; flow control >> "if", "do", "while", ... >> >> -Joe >> >>> >>> -- Jon >>> >>> >>> On 05/17/2016 03:04 PM, Joseph D. Darcy wrote: >>>> PS And know remembering to include the new link! >>>> >>>> http://cr.openjdk.java.net/~darcy/6415644.1/ >>>> >>>> -Joe >>>> >>>> On 5/17/2016 3:03 PM, Joseph D. Darcy wrote: >>>>> Hi Jon, >>>>> >>>>> On 5/17/2016 2:10 PM, Jonathan Gibbons wrote: >>>>>> That being said, the implementation does not appear to give what >>>>>> might be considered correct answers to >>>>>> isKeyword("assert", SourceVersion.RELEASE0); >>>>>> isKeyword("enum", SourceVersion.RELEASE0); >>>>>> >>>>>> I can't help feeling that the body of isKeyword is likely to >>>>>> evolve into a strings-in-switch ;-) >>>>> >>>>> As you wish, including version-sensitive results and tests for >>>>> "strictfp", "assert", "enum", etc. >>>>> >>>>> Thanks, >>>>> >>>>> -Joe >>>>> >>>>> >>>>>> >>>>>> -- Jon >>>>>> >>>>>> On 05/17/2016 01:11 PM, Jonathan Gibbons wrote: >>>>>>> Looks OK to me. >>>>>>> >>>>>>> You could micro-optimize these lines >>>>>>> >>>>>>> 318 String id = s.toString(); >>>>>>> 319 if ("_".equals(id)) { >>>>>>> >>>>>>> to use .contentEquals and aboid a possibly unnecessary .toString(). >>>>>>> >>>>>>> -- Jon >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 05/17/2016 11:48 AM, joe darcy wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review this webrev to add some version-sensitive keyword >>>>>>>> and name queries: >>>>>>>> >>>>>>>> JDK-6415644 Make javax.lang.model.SourceVersion more >>>>>>>> informative >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~darcy/6415644.0/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -Joe >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From jonathan.gibbons at oracle.com Wed May 18 18:25:22 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 18 May 2016 11:25:22 -0700 Subject: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version In-Reply-To: References: Message-ID: <573CB392.9050301@oracle.com> Langtools changes are OK, including the indirect use of the revised Version in jar-fs. -- Jon On 05/13/2016 04:20 PM, Iris Clark wrote: > Hi. > > Reviving this work from a few months back. > > Please review the following changes to move jdk.Version to > jdk.lang.Runtime.Version. > > Bug > > 8144062: Move jdk.Version to java.lang.Runtime.Version > https://bugs.openjdk.java.net/browse/JDK-8144062 > > webrev > > http://cr.openjdk.java.net/~iris/verona/8144062/webrev.1/ > > When jdk.Version was initially pushed in jdk-9+1-5, it was > Improperly exported by java.base. After exploring a few > options, the best choice was to move jdk.Version to > java.lang.Runtime.Version (a nested class of Runtime). By > making Version an SE API, it may be exported by the java.base > module. > > As part of the move, a limited number of chnages were > made to the Version class: > > - Change package name and class declaration (to static) > - Eliminate use of "JDK" when describing a Java SE API > - Initial clarifications related to zeros (trailing vs. > Internal components) > - Small typographical and grammatical enhancements > - Indentation > > The complete Runtime.Version specification is available here: > > http://cr.openjdk.java.net/~iris/verona/8144062/doc.1/java/lang/Runtime.Version.html > > The old jdk.Version.current() was replaced with > Runtime.version(). > > In System.getProperties(), we indicate which version-related > system properties may be supported by Runtime.Version. > > The remaining jdk and langtools file changes are all > side-effects of changing jdk.Version.current() to > Runtime.version(). > > Thanks, > Iris From joe.darcy at oracle.com Wed May 18 19:55:18 2016 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 18 May 2016 12:55:18 -0700 Subject: JDK 9 request for specification changes of JDK-8032230: Enhance javax.a.p.RoundEnvironment after repeating annotations Message-ID: <2f908c4d-bbfc-f42b-8728-6e2bf806c3a6@oracle.com> Hello, Please review the patch below which proposes a new method to address JDK-8032230: Enhance javax.a.p.RoundEnvironment after repeating annotations At present, this is just a review of the specification of the default method in the interface and *not* a more optimized implementation in the javac RoundEnvironemnt implementation (and not any tests that would be needed for the new functionality). Note that the bug proposes adding two methods RoundEnvironment.getElementsAnnotatedWith(Set> s) RoundEnvironment.getElementsAnnotatedWith(Set s) but these methods would clash since their erasure is the same. *sad tromphone* Therefore, I'm only proposing to add the Class-based variant since that one is the more commonly used of the two. Thanks, -Joe + /** + * Returns the elements annotated with any of the given annotation + * types. + * + * @apiNote This method may be useful when processing repeating + * annotations by looking for an annotation type and its + * containing annotation type at the same time. + * + * @implSpec The default implementation of this method creates an + * empty result set, iterates over the annotations in the argument + * set calling {@link #getElementsAnnotatedWith(TypeElement)} on + * each annotation and adding those results to the result + * set. Finally, the contents of the result set are returned as an + * unmodifiable set. + * + * @param annotations annotation type being requested + * @return the elements annotated with the given annotation types, + * or an empty set if there are none + * @throws IllegalArgumentException if the any elements of the + * argument set do not represent an annotation type + * @since 9 + */ + default Set getElementsAnnotatedWith(Set> annotations){ + HashSet result = new HashSet<>(); + for (Class annotation : annotations) { + result.addAll(getElementsAnnotatedWith(annotation)); + } + return Collections.unmodifiableSet(result); + } From jonathan.gibbons at oracle.com Wed May 18 20:05:56 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 18 May 2016 13:05:56 -0700 Subject: JDK 9 request for specification changes of JDK-8032230: Enhance javax.a.p.RoundEnvironment after repeating annotations In-Reply-To: <2f908c4d-bbfc-f42b-8728-6e2bf806c3a6@oracle.com> References: <2f908c4d-bbfc-f42b-8728-6e2bf806c3a6@oracle.com> Message-ID: <573CCB24.2030705@oracle.com> It's sad to see the preference given to the more intellectually suspect of the two possibilities. It would be nice to see the nice name given to the intellectually superior of the possibilities (i.e AnnotationMirror) and then figure out how to deal with the other case. As well as the possibility of another method name, have you ever considered the possibility of conversion functions of Elements/Types/ that can convert between (collection of) Annotation and (collection of) AnnotationMirror? -- Jon On 05/18/2016 12:55 PM, joe darcy wrote: > Hello, > > Please review the patch below which proposes a new method to address > > JDK-8032230: Enhance javax.a.p.RoundEnvironment after repeating > annotations > > At present, this is just a review of the specification of the default > method in the interface and *not* a more optimized implementation in > the javac RoundEnvironemnt implementation (and not any tests that > would be needed for the new functionality). > > Note that the bug proposes adding two methods > > RoundEnvironment.getElementsAnnotatedWith(Set Annotation>> s) > RoundEnvironment.getElementsAnnotatedWith(Set s) > > but these methods would clash since their erasure is the same. *sad > tromphone* > > Therefore, I'm only proposing to add the Class-based variant since > that one is the more commonly used of the two. > > Thanks, > > -Joe > > > + /** > + * Returns the elements annotated with any of the given annotation > + * types. > + * > + * @apiNote This method may be useful when processing repeating > + * annotations by looking for an annotation type and its > + * containing annotation type at the same time. > + * > + * @implSpec The default implementation of this method creates an > + * empty result set, iterates over the annotations in the argument > + * set calling {@link #getElementsAnnotatedWith(TypeElement)} on > + * each annotation and adding those results to the result > + * set. Finally, the contents of the result set are returned as an > + * unmodifiable set. > + * > + * @param annotations annotation type being requested > + * @return the elements annotated with the given annotation types, > + * or an empty set if there are none > + * @throws IllegalArgumentException if the any elements of the > + * argument set do not represent an annotation type > + * @since 9 > + */ > + default Set > getElementsAnnotatedWith(Set> annotations){ > + HashSet result = new HashSet<>(); > + for (Class annotation : annotations) { > + result.addAll(getElementsAnnotatedWith(annotation)); > + } > + return Collections.unmodifiableSet(result); > + } > From joe.darcy at oracle.com Wed May 18 20:26:11 2016 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 18 May 2016 13:26:11 -0700 Subject: JDK 9 request for specification changes of JDK-8032230: Enhance javax.a.p.RoundEnvironment after repeating annotations In-Reply-To: <573CCB24.2030705@oracle.com> References: <2f908c4d-bbfc-f42b-8728-6e2bf806c3a6@oracle.com> <573CCB24.2030705@oracle.com> Message-ID: <590ed79c-51a6-7cf3-3f5c-c088fab06574@oracle.com> Hi Jon, On 5/18/2016 1:05 PM, Jonathan Gibbons wrote: > It's sad to see the preference given to the more intellectually > suspect of the two possibilities. Agreed, sad but pragmatic. > > It would be nice to see the nice name given to the intellectually > superior of the possibilities (i.e AnnotationMirror) and then figure > out how to deal with the other case. How about the name "getElementsAnnotatedWithAny" for both variations? That potentially avoids confusion over whether or not the elements have to be modified with any of the annotations or all of them. > > As well as the possibility of another method name, have you ever > considered the possibility of conversion functions of > Elements/Types/ that can convert between (collection > of) Annotation and (collection of) AnnotationMirror? Internally, for the existing methods javac does convert the Class-based version to the TypeElement based version, but I don't think we want the specification to require that. Thanks, -Joe > > -- Jon > > On 05/18/2016 12:55 PM, joe darcy wrote: >> Hello, >> >> Please review the patch below which proposes a new method to address >> >> JDK-8032230: Enhance javax.a.p.RoundEnvironment after repeating >> annotations >> >> At present, this is just a review of the specification of the default >> method in the interface and *not* a more optimized implementation in >> the javac RoundEnvironemnt implementation (and not any tests that >> would be needed for the new functionality). >> >> Note that the bug proposes adding two methods >> >> RoundEnvironment.getElementsAnnotatedWith(Set> Annotation>> s) >> RoundEnvironment.getElementsAnnotatedWith(Set s) >> >> but these methods would clash since their erasure is the same. *sad >> tromphone* >> >> Therefore, I'm only proposing to add the Class-based variant since >> that one is the more commonly used of the two. >> >> Thanks, >> >> -Joe >> >> >> + /** >> + * Returns the elements annotated with any of the given annotation >> + * types. >> + * >> + * @apiNote This method may be useful when processing repeating >> + * annotations by looking for an annotation type and its >> + * containing annotation type at the same time. >> + * >> + * @implSpec The default implementation of this method creates an >> + * empty result set, iterates over the annotations in the argument >> + * set calling {@link #getElementsAnnotatedWith(TypeElement)} on >> + * each annotation and adding those results to the result >> + * set. Finally, the contents of the result set are returned as an >> + * unmodifiable set. >> + * >> + * @param annotations annotation type being requested >> + * @return the elements annotated with the given annotation types, >> + * or an empty set if there are none >> + * @throws IllegalArgumentException if the any elements of the >> + * argument set do not represent an annotation type >> + * @since 9 >> + */ >> + default Set >> getElementsAnnotatedWith(Set> annotations){ >> + HashSet result = new HashSet<>(); >> + for (Class annotation : annotations) { >> + result.addAll(getElementsAnnotatedWith(annotation)); >> + } >> + return Collections.unmodifiableSet(result); >> + } >> > From jonathan.gibbons at oracle.com Wed May 18 20:33:25 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 18 May 2016 13:33:25 -0700 Subject: JDK 9 request for specification changes of JDK-8032230: Enhance javax.a.p.RoundEnvironment after repeating annotations In-Reply-To: <590ed79c-51a6-7cf3-3f5c-c088fab06574@oracle.com> References: <2f908c4d-bbfc-f42b-8728-6e2bf806c3a6@oracle.com> <573CCB24.2030705@oracle.com> <590ed79c-51a6-7cf3-3f5c-c088fab06574@oracle.com> Message-ID: <573CD195.2070606@oracle.com> On 05/18/2016 01:26 PM, joe darcy wrote: > Hi Jon, > > On 5/18/2016 1:05 PM, Jonathan Gibbons wrote: >> It's sad to see the preference given to the more intellectually >> suspect of the two possibilities. > > Agreed, sad but pragmatic. > >> >> It would be nice to see the nice name given to the intellectually >> superior of the possibilities (i.e AnnotationMirror) and then figure >> out how to deal with the other case. > > How about the name "getElementsAnnotatedWithAny" for both variations? > That potentially avoids confusion over whether or not the elements > have to be modified with any of the annotations or all of them. That's a good clarification. Also, in similar cases of erasure clashes, (e.g. StandardJavaFileManager) we've included distinguishing words in the method name. > >> >> As well as the possibility of another method name, have you ever >> considered the possibility of conversion functions of >> Elements/Types/ that can convert between (collection >> of) Annotation and (collection of) AnnotationMirror? > > Internally, for the existing methods javac does convert the > Class-based version to the TypeElement based version, but I don't > think we want the specification to require that. The spec need not require it because if nothing else the type might not exist in both worlds, but it could offer it as an optional operation. > > Thanks, > > -Joe > >> >> -- Jon >> >> On 05/18/2016 12:55 PM, joe darcy wrote: >>> Hello, >>> >>> Please review the patch below which proposes a new method to address >>> >>> JDK-8032230: Enhance javax.a.p.RoundEnvironment after repeating >>> annotations >>> >>> At present, this is just a review of the specification of the >>> default method in the interface and *not* a more optimized >>> implementation in the javac RoundEnvironemnt implementation (and not >>> any tests that would be needed for the new functionality). >>> >>> Note that the bug proposes adding two methods >>> >>> RoundEnvironment.getElementsAnnotatedWith(Set>> Annotation>> s) >>> RoundEnvironment.getElementsAnnotatedWith(Set s) >>> >>> but these methods would clash since their erasure is the same. *sad >>> tromphone* >>> >>> Therefore, I'm only proposing to add the Class-based variant since >>> that one is the more commonly used of the two. >>> >>> Thanks, >>> >>> -Joe >>> >>> >>> + /** >>> + * Returns the elements annotated with any of the given annotation >>> + * types. >>> + * >>> + * @apiNote This method may be useful when processing repeating >>> + * annotations by looking for an annotation type and its >>> + * containing annotation type at the same time. >>> + * >>> + * @implSpec The default implementation of this method creates an >>> + * empty result set, iterates over the annotations in the argument >>> + * set calling {@link #getElementsAnnotatedWith(TypeElement)} on >>> + * each annotation and adding those results to the result >>> + * set. Finally, the contents of the result set are returned as an >>> + * unmodifiable set. >>> + * >>> + * @param annotations annotation type being requested >>> + * @return the elements annotated with the given annotation types, >>> + * or an empty set if there are none >>> + * @throws IllegalArgumentException if the any elements of the >>> + * argument set do not represent an annotation type >>> + * @since 9 >>> + */ >>> + default Set >>> getElementsAnnotatedWith(Set> annotations){ >>> + HashSet result = new HashSet<>(); >>> + for (Class annotation : annotations) { >>> + result.addAll(getElementsAnnotatedWith(annotation)); >>> + } >>> + return Collections.unmodifiableSet(result); >>> + } >>> >> > From alex.buckley at oracle.com Wed May 18 20:45:55 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 18 May 2016 13:45:55 -0700 Subject: JDK 9 request for specification changes of JDK-8032230: Enhance javax.a.p.RoundEnvironment after repeating annotations In-Reply-To: <2f908c4d-bbfc-f42b-8728-6e2bf806c3a6@oracle.com> References: <2f908c4d-bbfc-f42b-8728-6e2bf806c3a6@oracle.com> Message-ID: <573CD483.9020204@oracle.com> On 5/18/2016 12:55 PM, joe darcy wrote: > Please review the patch below which proposes a new method to address > > JDK-8032230: Enhance javax.a.p.RoundEnvironment after repeating > annotations > > At present, this is just a review of the specification of the default > method in the interface and *not* a more optimized implementation in the > javac RoundEnvironemnt implementation (and not any tests that would be > needed for the new functionality). The rationale for a new method is that it "may be useful [to consider] looking for an annotation type and its containing annotation type at the same time". I guess there's an assumption that the pre-existing method getElementsAnnotatedWith(Class) is called first with an argument Foo.class and then if no results is called again with an argument FooContainer.class. It would certainly be behaviorally incompatible for the pre-existing method to be changed to detect when Foo.class is a repeatable annotation type and go off looking for @FooContainer annotations of its own accord. So, if we want to look for an @Foo annotation and an @FooContainer annotation "at the same time", then how about the new method being: ----- Set<...> getElementsAssociatedWith(Class a) Returns the elements with which annotations of the given type are _associated_. [Cross-ref to j.l.r.AnnotatedElement where the richness of "associated" is explained.] ----- If you prefer the method proposed below, consider a varargs Class parameter rather than a Set. Alex > Note that the bug proposes adding two methods > > RoundEnvironment.getElementsAnnotatedWith(Set Annotation>> s) > RoundEnvironment.getElementsAnnotatedWith(Set s) > > but these methods would clash since their erasure is the same. *sad > tromphone* > > Therefore, I'm only proposing to add the Class-based variant since that > one is the more commonly used of the two. > > Thanks, > > -Joe > > > + /** > + * Returns the elements annotated with any of the given annotation > + * types. > + * > + * @apiNote This method may be useful when processing repeating > + * annotations by looking for an annotation type and its > + * containing annotation type at the same time. > + * > + * @implSpec The default implementation of this method creates an > + * empty result set, iterates over the annotations in the argument > + * set calling {@link #getElementsAnnotatedWith(TypeElement)} on > + * each annotation and adding those results to the result > + * set. Finally, the contents of the result set are returned as an > + * unmodifiable set. > + * > + * @param annotations annotation type being requested > + * @return the elements annotated with the given annotation types, > + * or an empty set if there are none > + * @throws IllegalArgumentException if the any elements of the > + * argument set do not represent an annotation type > + * @since 9 > + */ > + default Set getElementsAnnotatedWith(Set extends Annotation>> annotations){ > + HashSet result = new HashSet<>(); > + for (Class annotation : annotations) { > + result.addAll(getElementsAnnotatedWith(annotation)); > + } > + return Collections.unmodifiableSet(result); > + } > From jan.lahoda at oracle.com Wed May 18 20:48:21 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 18 May 2016 22:48:21 +0200 Subject: JDK 9 request for specification changes of JDK-8032230: Enhance javax.a.p.RoundEnvironment after repeating annotations In-Reply-To: <590ed79c-51a6-7cf3-3f5c-c088fab06574@oracle.com> References: <2f908c4d-bbfc-f42b-8728-6e2bf806c3a6@oracle.com> <573CCB24.2030705@oracle.com> <590ed79c-51a6-7cf3-3f5c-c088fab06574@oracle.com> Message-ID: <573CD515.4090602@oracle.com> On 18.5.2016 22:26, joe darcy wrote: > Hi Jon, > > On 5/18/2016 1:05 PM, Jonathan Gibbons wrote: >> It's sad to see the preference given to the more intellectually >> suspect of the two possibilities. > > Agreed, sad but pragmatic. Would it make sense to use varargs instead of a Set? If we assume the typical use will be something like: round.getElementsAnnotatedWithAny(annotation, containerAnnotation) it might be more convenient to have the method take a vararg than a Set (and would avoid the problem with the erasure clash as another benefit). Jan > >> >> It would be nice to see the nice name given to the intellectually >> superior of the possibilities (i.e AnnotationMirror) and then figure >> out how to deal with the other case. > > How about the name "getElementsAnnotatedWithAny" for both variations? > That potentially avoids confusion over whether or not the elements have > to be modified with any of the annotations or all of them. > >> >> As well as the possibility of another method name, have you ever >> considered the possibility of conversion functions of >> Elements/Types/ that can convert between (collection >> of) Annotation and (collection of) AnnotationMirror? > > Internally, for the existing methods javac does convert the Class-based > version to the TypeElement based version, but I don't think we want the > specification to require that. > > Thanks, > > -Joe > >> >> -- Jon >> >> On 05/18/2016 12:55 PM, joe darcy wrote: >>> Hello, >>> >>> Please review the patch below which proposes a new method to address >>> >>> JDK-8032230: Enhance javax.a.p.RoundEnvironment after repeating >>> annotations >>> >>> At present, this is just a review of the specification of the default >>> method in the interface and *not* a more optimized implementation in >>> the javac RoundEnvironemnt implementation (and not any tests that >>> would be needed for the new functionality). >>> >>> Note that the bug proposes adding two methods >>> >>> RoundEnvironment.getElementsAnnotatedWith(Set>> Annotation>> s) >>> RoundEnvironment.getElementsAnnotatedWith(Set s) >>> >>> but these methods would clash since their erasure is the same. *sad >>> tromphone* >>> >>> Therefore, I'm only proposing to add the Class-based variant since >>> that one is the more commonly used of the two. >>> >>> Thanks, >>> >>> -Joe >>> >>> >>> + /** >>> + * Returns the elements annotated with any of the given annotation >>> + * types. >>> + * >>> + * @apiNote This method may be useful when processing repeating >>> + * annotations by looking for an annotation type and its >>> + * containing annotation type at the same time. >>> + * >>> + * @implSpec The default implementation of this method creates an >>> + * empty result set, iterates over the annotations in the argument >>> + * set calling {@link #getElementsAnnotatedWith(TypeElement)} on >>> + * each annotation and adding those results to the result >>> + * set. Finally, the contents of the result set are returned as an >>> + * unmodifiable set. >>> + * >>> + * @param annotations annotation type being requested >>> + * @return the elements annotated with the given annotation types, >>> + * or an empty set if there are none >>> + * @throws IllegalArgumentException if the any elements of the >>> + * argument set do not represent an annotation type >>> + * @since 9 >>> + */ >>> + default Set >>> getElementsAnnotatedWith(Set> annotations){ >>> + HashSet result = new HashSet<>(); >>> + for (Class annotation : annotations) { >>> + result.addAll(getElementsAnnotatedWith(annotation)); >>> + } >>> + return Collections.unmodifiableSet(result); >>> + } >>> >> > From jonathan.gibbons at oracle.com Wed May 18 20:55:22 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 18 May 2016 13:55:22 -0700 Subject: JDK 9 request for specification changes of JDK-8032230: Enhance javax.a.p.RoundEnvironment after repeating annotations In-Reply-To: <573CD515.4090602@oracle.com> References: <2f908c4d-bbfc-f42b-8728-6e2bf806c3a6@oracle.com> <573CCB24.2030705@oracle.com> <590ed79c-51a6-7cf3-3f5c-c088fab06574@oracle.com> <573CD515.4090602@oracle.com> Message-ID: <573CD6BA.2030202@oracle.com> Jan, You're getting very close to suggesting a method that takes a predicate, and we could provide a variety of predicates for (anyOf, allOf) x (Annotation, AnnotationMirror) x (varags, collection) -- Jon On 05/18/2016 01:48 PM, Jan Lahoda wrote: > On 18.5.2016 22:26, joe darcy wrote: >> Hi Jon, >> >> On 5/18/2016 1:05 PM, Jonathan Gibbons wrote: >>> It's sad to see the preference given to the more intellectually >>> suspect of the two possibilities. >> >> Agreed, sad but pragmatic. > > Would it make sense to use varargs instead of a Set? If we assume the > typical use will be something like: > round.getElementsAnnotatedWithAny(annotation, containerAnnotation) > > it might be more convenient to have the method take a vararg than a > Set (and would avoid the problem with the erasure clash as another > benefit). > > Jan > >> >>> >>> It would be nice to see the nice name given to the intellectually >>> superior of the possibilities (i.e AnnotationMirror) and then figure >>> out how to deal with the other case. >> >> How about the name "getElementsAnnotatedWithAny" for both variations? >> That potentially avoids confusion over whether or not the elements have >> to be modified with any of the annotations or all of them. >> >>> >>> As well as the possibility of another method name, have you ever >>> considered the possibility of conversion functions of >>> Elements/Types/ that can convert between (collection >>> of) Annotation and (collection of) AnnotationMirror? >> >> Internally, for the existing methods javac does convert the Class-based >> version to the TypeElement based version, but I don't think we want the >> specification to require that. >> >> Thanks, >> >> -Joe >> >>> >>> -- Jon >>> >>> On 05/18/2016 12:55 PM, joe darcy wrote: >>>> Hello, >>>> >>>> Please review the patch below which proposes a new method to address >>>> >>>> JDK-8032230: Enhance javax.a.p.RoundEnvironment after repeating >>>> annotations >>>> >>>> At present, this is just a review of the specification of the default >>>> method in the interface and *not* a more optimized implementation in >>>> the javac RoundEnvironemnt implementation (and not any tests that >>>> would be needed for the new functionality). >>>> >>>> Note that the bug proposes adding two methods >>>> >>>> RoundEnvironment.getElementsAnnotatedWith(Set>>> Annotation>> s) >>>> RoundEnvironment.getElementsAnnotatedWith(Set s) >>>> >>>> but these methods would clash since their erasure is the same. *sad >>>> tromphone* >>>> >>>> Therefore, I'm only proposing to add the Class-based variant since >>>> that one is the more commonly used of the two. >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>>> >>>> + /** >>>> + * Returns the elements annotated with any of the given >>>> annotation >>>> + * types. >>>> + * >>>> + * @apiNote This method may be useful when processing repeating >>>> + * annotations by looking for an annotation type and its >>>> + * containing annotation type at the same time. >>>> + * >>>> + * @implSpec The default implementation of this method creates an >>>> + * empty result set, iterates over the annotations in the >>>> argument >>>> + * set calling {@link #getElementsAnnotatedWith(TypeElement)} on >>>> + * each annotation and adding those results to the result >>>> + * set. Finally, the contents of the result set are returned >>>> as an >>>> + * unmodifiable set. >>>> + * >>>> + * @param annotations annotation type being requested >>>> + * @return the elements annotated with the given annotation >>>> types, >>>> + * or an empty set if there are none >>>> + * @throws IllegalArgumentException if the any elements of the >>>> + * argument set do not represent an annotation type >>>> + * @since 9 >>>> + */ >>>> + default Set >>>> getElementsAnnotatedWith(Set> >>>> annotations){ >>>> + HashSet result = new HashSet<>(); >>>> + for (Class annotation : annotations) { >>>> + result.addAll(getElementsAnnotatedWith(annotation)); >>>> + } >>>> + return Collections.unmodifiableSet(result); >>>> + } >>>> >>> >> From joe.darcy at oracle.com Wed May 18 21:02:03 2016 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 18 May 2016 14:02:03 -0700 Subject: JDK 9 request for specification changes of JDK-8032230: Enhance javax.a.p.RoundEnvironment after repeating annotations In-Reply-To: <573CD6BA.2030202@oracle.com> References: <2f908c4d-bbfc-f42b-8728-6e2bf806c3a6@oracle.com> <573CCB24.2030705@oracle.com> <590ed79c-51a6-7cf3-3f5c-c088fab06574@oracle.com> <573CD515.4090602@oracle.com> <573CD6BA.2030202@oracle.com> Message-ID: Combining suggestions, two methods default Set getElementsAnnotatedWithAny(TypeElement... annotations) default Set getElementsAnnotatedWithAny(Set> annotations) No varargs in the second case because of heap pollution with the wildcarded Class type and the inability to use @SafeVarargs on this method since it can be overridden. I'd prefer a set of methods like the above that weren't only tied to repeating annotations since I think there are other use cases where it is helpful to find more than one annotation at a time. Fuller diff below. Thanks, -Joe /** + * Returns the elements annotated with one or more of the given + * annotation types. + * + * @apiNote This method may be useful when processing repeating + * annotations by looking for an annotation type and its + * containing annotation type at the same time. + * + * @implSpec The default implementation of this method creates an + * empty result set, iterates over the annotations in the argument + * set calling {@link #getElementsAnnotatedWith(TypeElement)} on + * each annotation and adding those results to the result + * set. Finally, the contents of the result set are returned as an + * unmodifiable set. + * + * @param annotations annotation types being requested + * @return the elements annotated with one or more of the given + * annotation types, or an empty set if there are none + * @throws IllegalArgumentException if the any elements of the + * argument set do not represent an annotation type + * @since 9 + */ + default Set getElementsAnnotatedWithAny(TypeElement... annotations){ + HashSet result = new HashSet<>(); + for (TypeElement annotation : annotations) { + result.addAll(getElementsAnnotatedWith(annotation)); + } + return Collections.unmodifiableSet(result); + } + /** + * Returns the elements annotated with one or more of the given + * annotation types. + * + * @apiNote This method may be useful when processing repeating + * annotations by looking for an annotation type and its + * containing annotation type at the same time. + * + * @implSpec The default implementation of this method creates an + * empty result set, iterates over the annotations in the argument + * set calling {@link #getElementsAnnotatedWith(Class)} on + * each annotation and adding those results to the result + * set. Finally, the contents of the result set are returned as an + * unmodifiable set. + * + * @param annotations annotation types being requested + * @return the elements annotated with one or more of the given + * annotation types, or an empty set if there are none + * @throws IllegalArgumentException if the any elements of the + * argument set do not represent an annotation type + * @since 9 + */ + default Set getElementsAnnotatedWithAny(Set> annotations){ + HashSet result = new HashSet<>(); + for (Class annotation : annotations) { + result.addAll(getElementsAnnotatedWith(annotation)); + } + return Collections.unmodifiableSet(result); + } On 5/18/2016 1:55 PM, Jonathan Gibbons wrote: > Jan, > > You're getting very close to suggesting a method that takes a > predicate, and we could provide a variety of predicates for (anyOf, > allOf) x (Annotation, AnnotationMirror) x (varags, collection) > > -- Jon > > On 05/18/2016 01:48 PM, Jan Lahoda wrote: >> On 18.5.2016 22:26, joe darcy wrote: >>> Hi Jon, >>> >>> On 5/18/2016 1:05 PM, Jonathan Gibbons wrote: >>>> It's sad to see the preference given to the more intellectually >>>> suspect of the two possibilities. >>> >>> Agreed, sad but pragmatic. >> >> Would it make sense to use varargs instead of a Set? If we assume the >> typical use will be something like: >> round.getElementsAnnotatedWithAny(annotation, containerAnnotation) >> >> it might be more convenient to have the method take a vararg than a >> Set (and would avoid the problem with the erasure clash as another >> benefit). >> >> Jan >> >>> >>>> >>>> It would be nice to see the nice name given to the intellectually >>>> superior of the possibilities (i.e AnnotationMirror) and then figure >>>> out how to deal with the other case. >>> >>> How about the name "getElementsAnnotatedWithAny" for both variations? >>> That potentially avoids confusion over whether or not the elements have >>> to be modified with any of the annotations or all of them. >>> >>>> >>>> As well as the possibility of another method name, have you ever >>>> considered the possibility of conversion functions of >>>> Elements/Types/ that can convert between (collection >>>> of) Annotation and (collection of) AnnotationMirror? >>> >>> Internally, for the existing methods javac does convert the Class-based >>> version to the TypeElement based version, but I don't think we want the >>> specification to require that. >>> >>> Thanks, >>> >>> -Joe >>> >>>> >>>> -- Jon >>>> >>>> On 05/18/2016 12:55 PM, joe darcy wrote: >>>>> Hello, >>>>> >>>>> Please review the patch below which proposes a new method to address >>>>> >>>>> JDK-8032230: Enhance javax.a.p.RoundEnvironment after repeating >>>>> annotations >>>>> >>>>> At present, this is just a review of the specification of the default >>>>> method in the interface and *not* a more optimized implementation in >>>>> the javac RoundEnvironemnt implementation (and not any tests that >>>>> would be needed for the new functionality). >>>>> >>>>> Note that the bug proposes adding two methods >>>>> >>>>> RoundEnvironment.getElementsAnnotatedWith(Set>>>> Annotation>> s) >>>>> RoundEnvironment.getElementsAnnotatedWith(Set s) >>>>> >>>>> but these methods would clash since their erasure is the same. *sad >>>>> tromphone* >>>>> >>>>> Therefore, I'm only proposing to add the Class-based variant since >>>>> that one is the more commonly used of the two. >>>>> >>>>> Thanks, >>>>> >>>>> -Joe >>>>> >>>>> >>>>> + /** >>>>> + * Returns the elements annotated with any of the given >>>>> annotation >>>>> + * types. >>>>> + * >>>>> + * @apiNote This method may be useful when processing repeating >>>>> + * annotations by looking for an annotation type and its >>>>> + * containing annotation type at the same time. >>>>> + * >>>>> + * @implSpec The default implementation of this method >>>>> creates an >>>>> + * empty result set, iterates over the annotations in the >>>>> argument >>>>> + * set calling {@link #getElementsAnnotatedWith(TypeElement)} on >>>>> + * each annotation and adding those results to the result >>>>> + * set. Finally, the contents of the result set are returned >>>>> as an >>>>> + * unmodifiable set. >>>>> + * >>>>> + * @param annotations annotation type being requested >>>>> + * @return the elements annotated with the given annotation >>>>> types, >>>>> + * or an empty set if there are none >>>>> + * @throws IllegalArgumentException if the any elements of the >>>>> + * argument set do not represent an annotation type >>>>> + * @since 9 >>>>> + */ >>>>> + default Set >>>>> getElementsAnnotatedWith(Set> >>>>> annotations){ >>>>> + HashSet result = new HashSet<>(); >>>>> + for (Class annotation : annotations) { >>>>> + result.addAll(getElementsAnnotatedWith(annotation)); >>>>> + } >>>>> + return Collections.unmodifiableSet(result); >>>>> + } >>>>> >>>> >>> > From iris.clark at oracle.com Wed May 18 21:04:34 2016 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 18 May 2016 14:04:34 -0700 (PDT) Subject: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version In-Reply-To: <573CB392.9050301@oracle.com> References: <573CB392.9050301@oracle.com> Message-ID: <0133a4b9-17cc-4ba9-96ce-ec4b523067af@default> Hi, Jon. >> http://cr.openjdk.java.net/~iris/verona/8144062/webrev.1/ > Langtools changes are OK, including the indirect use of the revised > Version in jar-fs. Thanks for the Review. Regards, Iris From iris.clark at oracle.com Wed May 18 21:52:49 2016 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 18 May 2016 14:52:49 -0700 (PDT) Subject: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version In-Reply-To: <29AA7813-44E0-4BB1-937E-1BCAB46F9367@oracle.com> References: <29AA7813-44E0-4BB1-937E-1BCAB46F9367@oracle.com> Message-ID: <0452bb32-8bd4-4236-83e9-912f9055ddbc@default> Hi, Mandy. Thanks for taking the time to Review. >> http://cr.openjdk.java.net/~iris/verona/8144062/webrev.1/ > The change looks fine. Minor comments: > > 1178 * @throws IllegalArgumentException > 1179 * If the given string cannot be interpreted as a valid > 1180 * version > 1185 * @throws NumberFormatException > 1186 * If an element of the version number or the build number > 1187 * cannot be represented as an {@link Integer} > > It?s okay to specify @throws NumberFormatException while @throws IAE (merging > the description) should be adequate (the implementation stays the same). > Something you can consider in the future. Sounds good as a future update. > 1189 * @return This version > It seems clearer to say "@return the Version of the given string? (this is a > static method and no ?This version?) Nice catch. Updated: 1189c1189 < * @return This version --- > * @return The Version of the given string Thank you so much for volunteering to Sponsor this change for me. I'll send you the changesets as soon as I've finished testing my sync with jdk9/dev. Regards, Iris From iris.clark at oracle.com Thu May 19 19:42:53 2016 From: iris.clark at oracle.com (Iris Clark) Date: Thu, 19 May 2016 12:42:53 -0700 (PDT) Subject: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version In-Reply-To: <0452bb32-8bd4-4236-83e9-912f9055ddbc@default> References: <29AA7813-44E0-4BB1-937E-1BCAB46F9367@oracle.com> <0452bb32-8bd4-4236-83e9-912f9055ddbc@default> Message-ID: <54fe3060-f264-4cc1-8a5c-be0cc1b0f2d0@default> Hi, Mandy. Thank you so much for pushing the changesets [0,1] for this bug. Regards, Iris [0]: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3976fadb091d [1]: http://hg.openjdk.java.net/jdk9/dev/langtools/rev/2a49d47a37d8 From paul.sandoz at oracle.com Fri May 20 13:38:05 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 20 May 2016 15:38:05 +0200 Subject: RFR 8149821 Add VarHandle signature-polymorphic invocation byte code tests Message-ID: Hi Please review. http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149821-javac-vh-sig-poly-test/webrev/ As suggested as a follow up in the initial review of VarHandles integration here is a small extension to an existing test to check compilation of a signature polymorphic VarHandle methods, in addition to that of a MethodHandle. Thanks, Paul. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jonathan.gibbons at oracle.com Fri May 20 20:54:47 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 20 May 2016 13:54:47 -0700 Subject: RFR: 8157474: clean up/simplify/rename ModuleWrappers class Message-ID: <573F7997.8000800@oracle.com> Please review this change to simplify and rename the javac ModuleWrappers class. There is no deliberate change in functionality. JBS: https://bugs.openjdk.java.net/browse/JDK-8157474 Webrev: http://cr.openjdk.java.net/~jjg/8157474/webrev.00/ -- Jon From jonathan.gibbons at oracle.com Fri May 20 22:42:59 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 20 May 2016 15:42:59 -0700 Subject: JDK 9 RFR of JDK-6415644 Make javax.lang.model.SourceVersion more informative In-Reply-To: <6a0d3479-c3c0-b815-e287-02faf33f8256@oracle.com> References: <1ab4c15f-d0c3-b29f-0109-5ae8e0851d81@oracle.com> <573B7B09.6050708@oracle.com> <573B88DF.4070906@oracle.com> <573B953D.20102@oracle.com> <573B9580.9030303@oracle.com> <573B9A34.4010208@oracle.com> <573B9DC2.2020008@oracle.com> <573BA907.2000803@oracle.com> <6a0d3479-c3c0-b815-e287-02faf33f8256@oracle.com> Message-ID: <573F92F3.1080807@oracle.com> Looks good, -- Jon On 05/18/2016 11:15 AM, joe darcy wrote: > Now grouped by function in: > > http://cr.openjdk.java.net/~darcy/6415644.2/ > > Cheers, > > -Joe > > On 5/17/2016 4:28 PM, Jonathan Gibbons wrote: >> Either alphabetic or grouped by function would be good. >> >> -- Jon >> >> >> On 05/17/2016 03:40 PM, Joseph D. Darcy wrote: >>> >>> On 5/17/2016 3:24 PM, Jonathan Gibbons wrote: >>>> OK, I have to ask, what is the ordering of the cases? :-) >>>> >>>> In the array in the previous version, they were (mostly) sorted >>>> alphabetically down >>>> the columns. ("for" If" "goto" "implements" was a bit anomalous.) >>>> The sort in cases labels is more cryptic, leading me to look for >>>> acrostics and other >>>> hidden messages to aliens. >>>> >>>> Aha, I think I've found the hidden meaning! Who else can spot it? >>> >>> ;-) >>> >>> IIRC, the original ordering of the set construction matched the >>> ordering of the listing in the corresponding section of the JLS. >>> >>> The new order resulted from cut-and-pasting the 5 columns of the set >>> construction into 4 columns of cases. >>> >>> I'd be happy to reorder this more conceptually access (or is it >>> visibility?) modifiers "public", "protected", "private"; flow >>> control "if", "do", "while", ... >>> >>> -Joe >>> >>>> >>>> -- Jon >>>> >>>> >>>> On 05/17/2016 03:04 PM, Joseph D. Darcy wrote: >>>>> PS And know remembering to include the new link! >>>>> >>>>> http://cr.openjdk.java.net/~darcy/6415644.1/ >>>>> >>>>> -Joe >>>>> >>>>> On 5/17/2016 3:03 PM, Joseph D. Darcy wrote: >>>>>> Hi Jon, >>>>>> >>>>>> On 5/17/2016 2:10 PM, Jonathan Gibbons wrote: >>>>>>> That being said, the implementation does not appear to give >>>>>>> what might be considered correct answers to >>>>>>> isKeyword("assert", SourceVersion.RELEASE0); >>>>>>> isKeyword("enum", SourceVersion.RELEASE0); >>>>>>> >>>>>>> I can't help feeling that the body of isKeyword is likely to >>>>>>> evolve into a strings-in-switch ;-) >>>>>> >>>>>> As you wish, including version-sensitive results and tests for >>>>>> "strictfp", "assert", "enum", etc. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Joe >>>>>> >>>>>> >>>>>>> >>>>>>> -- Jon >>>>>>> >>>>>>> On 05/17/2016 01:11 PM, Jonathan Gibbons wrote: >>>>>>>> Looks OK to me. >>>>>>>> >>>>>>>> You could micro-optimize these lines >>>>>>>> >>>>>>>> 318 String id = s.toString(); >>>>>>>> 319 if ("_".equals(id)) { >>>>>>>> >>>>>>>> to use .contentEquals and aboid a possibly unnecessary >>>>>>>> .toString(). >>>>>>>> >>>>>>>> -- Jon >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 05/17/2016 11:48 AM, joe darcy wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Please review this webrev to add some version-sensitive >>>>>>>>> keyword and name queries: >>>>>>>>> >>>>>>>>> JDK-6415644 Make javax.lang.model.SourceVersion more >>>>>>>>> informative >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~darcy/6415644.0/ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -Joe >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From mandy.chung at oracle.com Fri May 20 23:20:52 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 20 May 2016 16:20:52 -0700 Subject: RFR: 8157474: clean up/simplify/rename ModuleWrappers class In-Reply-To: <573F7997.8000800@oracle.com> References: <573F7997.8000800@oracle.com> Message-ID: <9005C575-A1F4-4B3E-A75E-C3BE9651EE07@oracle.com> > On May 20, 2016, at 1:54 PM, Jonathan Gibbons wrote: > > Please review this change to simplify and rename the javac ModuleWrappers class. > There is no deliberate change in functionality. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8157474 > Webrev: http://cr.openjdk.java.net/~jjg/8157474/webrev.00/ Looks fine. Nits: 58 public static final class ServiceLoaderHelper { You have a good convention to name the helper class same as the JDK 9 class name. Should this ServiceLoaderHelper one be renamed to ?ServiceLoader? too? On this Class::forName call: 123 moduleFinderClass = Class.forName("java.lang.module.ModuleFinder", false, ClassLoader.getSystemClassLoader()); It?s okay to use ClassLoader.getSystemClassLoader() for delegation. Since the classes are in java.base, it?s safe to always pass null loader. It?s nit. Mandy From jonathan.gibbons at oracle.com Fri May 20 23:25:21 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 20 May 2016 16:25:21 -0700 Subject: RFR: 8157474: clean up/simplify/rename ModuleWrappers class In-Reply-To: <9005C575-A1F4-4B3E-A75E-C3BE9651EE07@oracle.com> References: <573F7997.8000800@oracle.com> <9005C575-A1F4-4B3E-A75E-C3BE9651EE07@oracle.com> Message-ID: <573F9CE1.9060503@oracle.com> On 05/20/2016 04:20 PM, Mandy Chung wrote: >> On May 20, 2016, at 1:54 PM, Jonathan Gibbons wrote: >> >> Please review this change to simplify and rename the javac ModuleWrappers class. >> There is no deliberate change in functionality. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8157474 >> Webrev: http://cr.openjdk.java.net/~jjg/8157474/webrev.00/ > Looks fine. Nits: > > 58 public static final class ServiceLoaderHelper { > > You have a good convention to name the helper class same as the JDK 9 class name. Should this ServiceLoaderHelper one be renamed to ?ServiceLoader? too? Good point. It was deliberate to use Helper, but since we only use this for a static method, and never need to create a wrapped instance of ServiceLoader, we can probably simplify the name. > > On this Class::forName call: > 123 moduleFinderClass = Class.forName("java.lang.module.ModuleFinder", false, ClassLoader.getSystemClassLoader()); > > It?s okay to use ClassLoader.getSystemClassLoader() for delegation. Since the classes are in java.base, it?s safe to always pass null loader. It?s nit. null is good. Thanks for the tip. > > Mandy From jonathan.gibbons at oracle.com Fri May 20 23:32:00 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 20 May 2016 16:32:00 -0700 Subject: RFR: 8157474: clean up/simplify/rename ModuleWrappers class In-Reply-To: <573F9CE1.9060503@oracle.com> References: <573F7997.8000800@oracle.com> <9005C575-A1F4-4B3E-A75E-C3BE9651EE07@oracle.com> <573F9CE1.9060503@oracle.com> Message-ID: <573F9E70.6020601@oracle.com> On 05/20/2016 04:25 PM, Jonathan Gibbons wrote: > > > On 05/20/2016 04:20 PM, Mandy Chung wrote: >>> On May 20, 2016, at 1:54 PM, Jonathan Gibbons >>> wrote: >>> >>> Please review this change to simplify and rename the javac >>> ModuleWrappers class. >>> There is no deliberate change in functionality. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8157474 >>> Webrev: http://cr.openjdk.java.net/~jjg/8157474/webrev.00/ >> Looks fine. Nits: >> >> 58 public static final class ServiceLoaderHelper { >> >> You have a good convention to name the helper class same as the JDK 9 >> class name. Should this ServiceLoaderHelper one be renamed to >> ?ServiceLoader? too? > > Good point. It was deliberate to use Helper, but since we only use > this for a static method, and never need to create a wrapped instance > of ServiceLoader, we can probably simplify the name. ... but the return type is a real ServiceLoader, so it would cause confusion to force the call site to deal with the same class name in two different packages. > >> >> On this Class::forName call: >> 123 moduleFinderClass = >> Class.forName("java.lang.module.ModuleFinder", false, >> ClassLoader.getSystemClassLoader()); >> >> It?s okay to use ClassLoader.getSystemClassLoader() for delegation. >> Since the classes are in java.base, it?s safe to always pass null >> loader. It?s nit. > > null is good. Thanks for the tip. > >> >> Mandy > From mandy.chung at oracle.com Fri May 20 23:46:43 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 20 May 2016 16:46:43 -0700 Subject: RFR: 8157474: clean up/simplify/rename ModuleWrappers class In-Reply-To: <573F9E70.6020601@oracle.com> References: <573F7997.8000800@oracle.com> <9005C575-A1F4-4B3E-A75E-C3BE9651EE07@oracle.com> <573F9CE1.9060503@oracle.com> <573F9E70.6020601@oracle.com> Message-ID: <6130682D-FBF3-4587-A40F-95E206B0EE99@oracle.com> > On May 20, 2016, at 4:32 PM, Jonathan Gibbons wrote: > > > > On 05/20/2016 04:25 PM, Jonathan Gibbons wrote: >> >> >> On 05/20/2016 04:20 PM, Mandy Chung wrote: >>>> On May 20, 2016, at 1:54 PM, Jonathan Gibbons wrote: >>>> >>>> Please review this change to simplify and rename the javac ModuleWrappers class. >>>> There is no deliberate change in functionality. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8157474 >>>> Webrev: http://cr.openjdk.java.net/~jjg/8157474/webrev.00/ >>> Looks fine. Nits: >>> >>> 58 public static final class ServiceLoaderHelper { >>> >>> You have a good convention to name the helper class same as the JDK 9 class name. Should this ServiceLoaderHelper one be renamed to ?ServiceLoader? too? >> >> Good point. It was deliberate to use Helper, but since we only use this for a static method, and never need to create a wrapped instance of ServiceLoader, we can probably simplify the name. > ... but the return type is a real ServiceLoader, so it would cause confusion to force the call site to deal with the same class name in two different packages. Ah? that explains it when it was not renamed. Looks good. Mandy From maurizio.cimadamore at oracle.com Mon May 23 09:39:43 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 23 May 2016 10:39:43 +0100 Subject: RFR 8149821 Add VarHandle signature-polymorphic invocation byte code tests In-Reply-To: References: Message-ID: <5742CFDF.4060505@oracle.com> Looks good - a nice extension of the existing test. Maurizio On 20/05/16 14:38, Paul Sandoz wrote: > Hi > > Please review. > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149821-javac-vh-sig-poly-test/webrev/ > > As suggested as a follow up in the initial review of VarHandles integration here is a small extension to an existing test to check compilation of a signature polymorphic VarHandle methods, in addition to that of a MethodHandle. > > Thanks, > Paul. From joe.darcy at oracle.com Mon May 23 18:21:28 2016 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 23 May 2016 11:21:28 -0700 Subject: JDK 9 request for specification changes of JDK-8032230: Enhance javax.a.p.RoundEnvironment after repeating annotations In-Reply-To: References: <2f908c4d-bbfc-f42b-8728-6e2bf806c3a6@oracle.com> <573CCB24.2030705@oracle.com> <590ed79c-51a6-7cf3-3f5c-c088fab06574@oracle.com> <573CD515.4090602@oracle.com> <573CD6BA.2030202@oracle.com> Message-ID: <4ade37d0-bedb-64d5-250a-ac5f40725d2b@oracle.com> Hello, Please now review a webrev including the specification and some tests: http://cr.openjdk.java.net/~darcy/8032230.0/ Thanks, -Joe On 5/18/2016 2:02 PM, joe darcy wrote: > Combining suggestions, two methods > > default Set > getElementsAnnotatedWithAny(TypeElement... annotations) > > default Set > getElementsAnnotatedWithAny(Set> annotations) > > No varargs in the second case because of heap pollution with the > wildcarded Class type and the inability to use @SafeVarargs on this > method since it can be overridden. > > I'd prefer a set of methods like the above that weren't only tied to > repeating annotations since I think there are other use cases where it > is helpful to find more than one annotation at a time. > > Fuller diff below. > > Thanks, > > -Joe > > > /** > + * Returns the elements annotated with one or more of the given > + * annotation types. > + * > + * @apiNote This method may be useful when processing repeating > + * annotations by looking for an annotation type and its > + * containing annotation type at the same time. > + * > + * @implSpec The default implementation of this method creates an > + * empty result set, iterates over the annotations in the argument > + * set calling {@link #getElementsAnnotatedWith(TypeElement)} on > + * each annotation and adding those results to the result > + * set. Finally, the contents of the result set are returned as an > + * unmodifiable set. > + * > + * @param annotations annotation types being requested > + * @return the elements annotated with one or more of the given > + * annotation types, or an empty set if there are none > + * @throws IllegalArgumentException if the any elements of the > + * argument set do not represent an annotation type > + * @since 9 > + */ > + default Set > getElementsAnnotatedWithAny(TypeElement... annotations){ > + HashSet result = new HashSet<>(); > + for (TypeElement annotation : annotations) { > + result.addAll(getElementsAnnotatedWith(annotation)); > + } > + return Collections.unmodifiableSet(result); > + } > > + /** > + * Returns the elements annotated with one or more of the given > + * annotation types. > + * > + * @apiNote This method may be useful when processing repeating > + * annotations by looking for an annotation type and its > + * containing annotation type at the same time. > + * > + * @implSpec The default implementation of this method creates an > + * empty result set, iterates over the annotations in the argument > + * set calling {@link #getElementsAnnotatedWith(Class)} on > + * each annotation and adding those results to the result > + * set. Finally, the contents of the result set are returned as an > + * unmodifiable set. > + * > + * @param annotations annotation types being requested > + * @return the elements annotated with one or more of the given > + * annotation types, or an empty set if there are none > + * @throws IllegalArgumentException if the any elements of the > + * argument set do not represent an annotation type > + * @since 9 > + */ > + default Set > getElementsAnnotatedWithAny(Set> > annotations){ > + HashSet result = new HashSet<>(); > + for (Class annotation : annotations) { > + result.addAll(getElementsAnnotatedWith(annotation)); > + } > + return Collections.unmodifiableSet(result); > + } > > > On 5/18/2016 1:55 PM, Jonathan Gibbons wrote: >> Jan, >> >> You're getting very close to suggesting a method that takes a >> predicate, and we could provide a variety of predicates for (anyOf, >> allOf) x (Annotation, AnnotationMirror) x (varags, collection) >> >> -- Jon >> >> On 05/18/2016 01:48 PM, Jan Lahoda wrote: >>> On 18.5.2016 22:26, joe darcy wrote: >>>> Hi Jon, >>>> >>>> On 5/18/2016 1:05 PM, Jonathan Gibbons wrote: >>>>> It's sad to see the preference given to the more intellectually >>>>> suspect of the two possibilities. >>>> >>>> Agreed, sad but pragmatic. >>> >>> Would it make sense to use varargs instead of a Set? If we assume >>> the typical use will be something like: >>> round.getElementsAnnotatedWithAny(annotation, containerAnnotation) >>> >>> it might be more convenient to have the method take a vararg than a >>> Set (and would avoid the problem with the erasure clash as another >>> benefit). >>> >>> Jan >>> >>>> >>>>> >>>>> It would be nice to see the nice name given to the intellectually >>>>> superior of the possibilities (i.e AnnotationMirror) and then figure >>>>> out how to deal with the other case. >>>> >>>> How about the name "getElementsAnnotatedWithAny" for both variations? >>>> That potentially avoids confusion over whether or not the elements >>>> have >>>> to be modified with any of the annotations or all of them. >>>> >>>>> >>>>> As well as the possibility of another method name, have you ever >>>>> considered the possibility of conversion functions of >>>>> Elements/Types/ that can convert between (collection >>>>> of) Annotation and (collection of) AnnotationMirror? >>>> >>>> Internally, for the existing methods javac does convert the >>>> Class-based >>>> version to the TypeElement based version, but I don't think we want >>>> the >>>> specification to require that. >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>>>> >>>>> -- Jon >>>>> >>>>> On 05/18/2016 12:55 PM, joe darcy wrote: >>>>>> Hello, >>>>>> >>>>>> Please review the patch below which proposes a new method to address >>>>>> >>>>>> JDK-8032230: Enhance javax.a.p.RoundEnvironment after repeating >>>>>> annotations >>>>>> >>>>>> At present, this is just a review of the specification of the >>>>>> default >>>>>> method in the interface and *not* a more optimized implementation in >>>>>> the javac RoundEnvironemnt implementation (and not any tests that >>>>>> would be needed for the new functionality). >>>>>> >>>>>> Note that the bug proposes adding two methods >>>>>> >>>>>> RoundEnvironment.getElementsAnnotatedWith(Set>>>>> Annotation>> s) >>>>>> RoundEnvironment.getElementsAnnotatedWith(Set s) >>>>>> >>>>>> but these methods would clash since their erasure is the same. *sad >>>>>> tromphone* >>>>>> >>>>>> Therefore, I'm only proposing to add the Class-based variant since >>>>>> that one is the more commonly used of the two. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Joe >>>>>> >>>>>> >>>>>> + /** >>>>>> + * Returns the elements annotated with any of the given >>>>>> annotation >>>>>> + * types. >>>>>> + * >>>>>> + * @apiNote This method may be useful when processing repeating >>>>>> + * annotations by looking for an annotation type and its >>>>>> + * containing annotation type at the same time. >>>>>> + * >>>>>> + * @implSpec The default implementation of this method >>>>>> creates an >>>>>> + * empty result set, iterates over the annotations in the >>>>>> argument >>>>>> + * set calling {@link >>>>>> #getElementsAnnotatedWith(TypeElement)} on >>>>>> + * each annotation and adding those results to the result >>>>>> + * set. Finally, the contents of the result set are returned >>>>>> as an >>>>>> + * unmodifiable set. >>>>>> + * >>>>>> + * @param annotations annotation type being requested >>>>>> + * @return the elements annotated with the given annotation >>>>>> types, >>>>>> + * or an empty set if there are none >>>>>> + * @throws IllegalArgumentException if the any elements of the >>>>>> + * argument set do not represent an annotation type >>>>>> + * @since 9 >>>>>> + */ >>>>>> + default Set >>>>>> getElementsAnnotatedWith(Set> >>>>>> annotations){ >>>>>> + HashSet result = new HashSet<>(); >>>>>> + for (Class annotation : >>>>>> annotations) { >>>>>> + result.addAll(getElementsAnnotatedWith(annotation)); >>>>>> + } >>>>>> + return Collections.unmodifiableSet(result); >>>>>> + } >>>>>> >>>>> >>>> >> > From srikanth.adayapalam at oracle.com Tue May 24 09:14:43 2016 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Tue, 24 May 2016 14:44:43 +0530 Subject: RFR: Backport of fix for https://bugs.openjdk.java.net/browse/JDK-8129740 Message-ID: <57441B83.2010100@oracle.com> Hello! https://bugs.openjdk.java.net/browse/JDK-8157142 requests for a backport of the fix made for https://bugs.openjdk.java.net/browse/JDK-8129740 (1) The original patch does not apply as is after path shuffling. However, manual application of the two failed hunks in LambdaToMethod.java is straightforward and does not call for any real change in code. (2) The file test/tools/javac/lambda/T8129740/SourceToSourceTranslationTest.java required some rewriting since the ToolBox class API is different between JDK9 and JDK8. Langtools + JCK tests have been run and are all green. Please review here: http://cr.openjdk.java.net/~sadayapalam/JDK-8157142/webrev.00/ Thanks in advance, Srikanth -------------- next part -------------- An HTML attachment was scrubbed... URL: From srikanth.adayapalam at oracle.com Tue May 24 09:37:53 2016 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Tue, 24 May 2016 15:07:53 +0530 Subject: RFR: Javadoc adjustment for https://bugs.openjdk.java.net/browse/JDK-8033812 Message-ID: <574420F1.5060207@oracle.com> Hello, Thanks in advance for reviewing this minor change to the javadoc of ElementType.TYPE_USE made for JDK-8033812 Thanks! Srikanth -------------- next part -------------- An HTML attachment was scrubbed... URL: From srikanth.adayapalam at oracle.com Tue May 24 09:41:04 2016 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Tue, 24 May 2016 15:11:04 +0530 Subject: RFR: Javadoc adjustment for https://bugs.openjdk.java.net/browse/JDK-8033812 In-Reply-To: <574420F1.5060207@oracle.com> References: <574420F1.5060207@oracle.com> Message-ID: <574421B0.6070807@oracle.com> The link to review: http://cr.openjdk.java.net/~sadayapalam/JDK-8033812/webrev.00/ Thanks! Srikanth On Tuesday 24 May 2016 03:07 PM, Srikanth wrote: > Hello, > > Thanks in advance for reviewing this minor change to the javadoc of > ElementType.TYPE_USE made for JDK-8033812 > > Thanks! > Srikanth -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Tue May 24 09:55:36 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 24 May 2016 10:55:36 +0100 Subject: RFR: Backport of fix for https://bugs.openjdk.java.net/browse/JDK-8129740 In-Reply-To: <57441B83.2010100@oracle.com> References: <57441B83.2010100@oracle.com> Message-ID: <57442518.2080903@oracle.com> Looks good! Maurizio On 24/05/16 10:14, Srikanth wrote: > Hello! > > https://bugs.openjdk.java.net/browse/JDK-8157142 requests for a > backport of the > fix made for https://bugs.openjdk.java.net/browse/JDK-8129740 > > (1) The original patch does not apply as is after path shuffling. > > However, manual application of the two failed hunks in > LambdaToMethod.java is straightforward > and does not call for any real change in code. > > (2) The file > test/tools/javac/lambda/T8129740/SourceToSourceTranslationTest.java > required some rewriting since the ToolBox class API is different between > JDK9 and JDK8. > > Langtools + JCK tests have been run and are all green. > > Please review here: > > http://cr.openjdk.java.net/~sadayapalam/JDK-8157142/webrev.00/ > > Thanks in advance, > Srikanth > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Tue May 24 09:57:39 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 24 May 2016 10:57:39 +0100 Subject: RFR: Javadoc adjustment for https://bugs.openjdk.java.net/browse/JDK-8033812 In-Reply-To: <574421B0.6070807@oracle.com> References: <574420F1.5060207@oracle.com> <574421B0.6070807@oracle.com> Message-ID: <57442593.3020704@oracle.com> Looks good! Maurizio On 24/05/16 10:41, Srikanth wrote: > The link to review: > > http://cr.openjdk.java.net/~sadayapalam/JDK-8033812/webrev.00/ > > Thanks! > Srikanth > > On Tuesday 24 May 2016 03:07 PM, Srikanth wrote: >> Hello, >> >> Thanks in advance for reviewing this minor change to the javadoc of >> ElementType.TYPE_USE made for JDK-8033812 >> >> Thanks! >> Srikanth > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Tue May 24 16:18:51 2016 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 24 May 2016 09:18:51 -0700 Subject: JDK 9 request for specification changes of JDK-8032230: Enhance javax.a.p.RoundEnvironment after repeating annotations In-Reply-To: <4ade37d0-bedb-64d5-250a-ac5f40725d2b@oracle.com> References: <2f908c4d-bbfc-f42b-8728-6e2bf806c3a6@oracle.com> <573CCB24.2030705@oracle.com> <590ed79c-51a6-7cf3-3f5c-c088fab06574@oracle.com> <573CD515.4090602@oracle.com> <573CD6BA.2030202@oracle.com> <4ade37d0-bedb-64d5-250a-ac5f40725d2b@oracle.com> Message-ID: <0e72d560-d8a5-0583-513d-a44d3f330dfd@oracle.com> Updated webrev: http://cr.openjdk.java.net/~darcy/8032230.1/ Now with specialized implementation in javac's implementation of RoundEnvironment and separate tests of the default methods in the interface and the javac implementation. Thanks, -Joe On 5/23/2016 11:21 AM, joe darcy wrote: > Hello, > > Please now review a webrev including the specification and some tests: > > http://cr.openjdk.java.net/~darcy/8032230.0/ > > Thanks, > > -Joe > > > On 5/18/2016 2:02 PM, joe darcy wrote: >> Combining suggestions, two methods >> >> default Set >> getElementsAnnotatedWithAny(TypeElement... annotations) >> >> default Set >> getElementsAnnotatedWithAny(Set> >> annotations) >> >> No varargs in the second case because of heap pollution with the >> wildcarded Class type and the inability to use @SafeVarargs on this >> method since it can be overridden. >> >> I'd prefer a set of methods like the above that weren't only tied to >> repeating annotations since I think there are other use cases where >> it is helpful to find more than one annotation at a time. >> >> Fuller diff below. >> >> Thanks, >> >> -Joe >> >> >> /** >> + * Returns the elements annotated with one or more of the given >> + * annotation types. >> + * >> + * @apiNote This method may be useful when processing repeating >> + * annotations by looking for an annotation type and its >> + * containing annotation type at the same time. >> + * >> + * @implSpec The default implementation of this method creates an >> + * empty result set, iterates over the annotations in the argument >> + * set calling {@link #getElementsAnnotatedWith(TypeElement)} on >> + * each annotation and adding those results to the result >> + * set. Finally, the contents of the result set are returned as an >> + * unmodifiable set. >> + * >> + * @param annotations annotation types being requested >> + * @return the elements annotated with one or more of the given >> + * annotation types, or an empty set if there are none >> + * @throws IllegalArgumentException if the any elements of the >> + * argument set do not represent an annotation type >> + * @since 9 >> + */ >> + default Set >> getElementsAnnotatedWithAny(TypeElement... annotations){ >> + HashSet result = new HashSet<>(); >> + for (TypeElement annotation : annotations) { >> + result.addAll(getElementsAnnotatedWith(annotation)); >> + } >> + return Collections.unmodifiableSet(result); >> + } >> >> + /** >> + * Returns the elements annotated with one or more of the given >> + * annotation types. >> + * >> + * @apiNote This method may be useful when processing repeating >> + * annotations by looking for an annotation type and its >> + * containing annotation type at the same time. >> + * >> + * @implSpec The default implementation of this method creates an >> + * empty result set, iterates over the annotations in the argument >> + * set calling {@link #getElementsAnnotatedWith(Class)} on >> + * each annotation and adding those results to the result >> + * set. Finally, the contents of the result set are returned as an >> + * unmodifiable set. >> + * >> + * @param annotations annotation types being requested >> + * @return the elements annotated with one or more of the given >> + * annotation types, or an empty set if there are none >> + * @throws IllegalArgumentException if the any elements of the >> + * argument set do not represent an annotation type >> + * @since 9 >> + */ >> + default Set >> getElementsAnnotatedWithAny(Set> >> annotations){ >> + HashSet result = new HashSet<>(); >> + for (Class annotation : annotations) { >> + result.addAll(getElementsAnnotatedWith(annotation)); >> + } >> + return Collections.unmodifiableSet(result); >> + } >> >> >> On 5/18/2016 1:55 PM, Jonathan Gibbons wrote: >>> Jan, >>> >>> You're getting very close to suggesting a method that takes a >>> predicate, and we could provide a variety of predicates for (anyOf, >>> allOf) x (Annotation, AnnotationMirror) x (varags, collection) >>> >>> -- Jon >>> >>> On 05/18/2016 01:48 PM, Jan Lahoda wrote: >>>> On 18.5.2016 22:26, joe darcy wrote: >>>>> Hi Jon, >>>>> >>>>> On 5/18/2016 1:05 PM, Jonathan Gibbons wrote: >>>>>> It's sad to see the preference given to the more intellectually >>>>>> suspect of the two possibilities. >>>>> >>>>> Agreed, sad but pragmatic. >>>> >>>> Would it make sense to use varargs instead of a Set? If we assume >>>> the typical use will be something like: >>>> round.getElementsAnnotatedWithAny(annotation, containerAnnotation) >>>> >>>> it might be more convenient to have the method take a vararg than a >>>> Set (and would avoid the problem with the erasure clash as another >>>> benefit). >>>> >>>> Jan >>>> >>>>> >>>>>> >>>>>> It would be nice to see the nice name given to the intellectually >>>>>> superior of the possibilities (i.e AnnotationMirror) and then figure >>>>>> out how to deal with the other case. >>>>> >>>>> How about the name "getElementsAnnotatedWithAny" for both variations? >>>>> That potentially avoids confusion over whether or not the elements >>>>> have >>>>> to be modified with any of the annotations or all of them. >>>>> >>>>>> >>>>>> As well as the possibility of another method name, have you ever >>>>>> considered the possibility of conversion functions of >>>>>> Elements/Types/ that can convert between (collection >>>>>> of) Annotation and (collection of) AnnotationMirror? >>>>> >>>>> Internally, for the existing methods javac does convert the >>>>> Class-based >>>>> version to the TypeElement based version, but I don't think we >>>>> want the >>>>> specification to require that. >>>>> >>>>> Thanks, >>>>> >>>>> -Joe >>>>> >>>>>> >>>>>> -- Jon >>>>>> >>>>>> On 05/18/2016 12:55 PM, joe darcy wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review the patch below which proposes a new method to >>>>>>> address >>>>>>> >>>>>>> JDK-8032230: Enhance javax.a.p.RoundEnvironment after repeating >>>>>>> annotations >>>>>>> >>>>>>> At present, this is just a review of the specification of the >>>>>>> default >>>>>>> method in the interface and *not* a more optimized >>>>>>> implementation in >>>>>>> the javac RoundEnvironemnt implementation (and not any tests that >>>>>>> would be needed for the new functionality). >>>>>>> >>>>>>> Note that the bug proposes adding two methods >>>>>>> >>>>>>> RoundEnvironment.getElementsAnnotatedWith(Set>>>>>> Annotation>> s) >>>>>>> RoundEnvironment.getElementsAnnotatedWith(Set s) >>>>>>> >>>>>>> but these methods would clash since their erasure is the same. *sad >>>>>>> tromphone* >>>>>>> >>>>>>> Therefore, I'm only proposing to add the Class-based variant since >>>>>>> that one is the more commonly used of the two. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -Joe >>>>>>> >>>>>>> >>>>>>> + /** >>>>>>> + * Returns the elements annotated with any of the given >>>>>>> annotation >>>>>>> + * types. >>>>>>> + * >>>>>>> + * @apiNote This method may be useful when processing >>>>>>> repeating >>>>>>> + * annotations by looking for an annotation type and its >>>>>>> + * containing annotation type at the same time. >>>>>>> + * >>>>>>> + * @implSpec The default implementation of this method >>>>>>> creates an >>>>>>> + * empty result set, iterates over the annotations in the >>>>>>> argument >>>>>>> + * set calling {@link >>>>>>> #getElementsAnnotatedWith(TypeElement)} on >>>>>>> + * each annotation and adding those results to the result >>>>>>> + * set. Finally, the contents of the result set are >>>>>>> returned as an >>>>>>> + * unmodifiable set. >>>>>>> + * >>>>>>> + * @param annotations annotation type being requested >>>>>>> + * @return the elements annotated with the given annotation >>>>>>> types, >>>>>>> + * or an empty set if there are none >>>>>>> + * @throws IllegalArgumentException if the any elements of the >>>>>>> + * argument set do not represent an annotation type >>>>>>> + * @since 9 >>>>>>> + */ >>>>>>> + default Set >>>>>>> getElementsAnnotatedWith(Set> >>>>>>> annotations){ >>>>>>> + HashSet result = new HashSet<>(); >>>>>>> + for (Class annotation : >>>>>>> annotations) { >>>>>>> + result.addAll(getElementsAnnotatedWith(annotation)); >>>>>>> + } >>>>>>> + return Collections.unmodifiableSet(result); >>>>>>> + } >>>>>>> >>>>>> >>>>> >>> >> > From joe.darcy at oracle.com Tue May 24 16:26:08 2016 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 24 May 2016 09:26:08 -0700 Subject: RFR: Javadoc adjustment for https://bugs.openjdk.java.net/browse/JDK-8033812 In-Reply-To: <57442593.3020704@oracle.com> References: <574420F1.5060207@oracle.com> <574421B0.6070807@oracle.com> <57442593.3020704@oracle.com> Message-ID: +1 -Joe On 5/24/2016 2:57 AM, Maurizio Cimadamore wrote: > Looks good! > > Maurizio > > On 24/05/16 10:41, Srikanth wrote: >> The link to review: >> >> http://cr.openjdk.java.net/~sadayapalam/JDK-8033812/webrev.00/ >> >> Thanks! >> Srikanth >> >> On Tuesday 24 May 2016 03:07 PM, Srikanth wrote: >>> Hello, >>> >>> Thanks in advance for reviewing this minor change to the javadoc of >>> ElementType.TYPE_USE made for JDK-8033812 >>> >>> Thanks! >>> Srikanth >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrej.golovnin at gmail.com Wed May 25 08:41:37 2016 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Wed, 25 May 2016 10:41:37 +0200 Subject: A bug in the Java 8 compiler. Message-ID: Hi all, consider following code: public class Main { public static class Details { // NOP } public static class Mapper { public T getMapped(String str) { return null; } public List
getDetails(T entity) { return Collections.emptyList(); } } public static List
calcDetails() { Optional opt = Optional.empty(); return opt.map(m -> getDetails("A", m)) .orElseGet(() -> Collections.emptyList()); } private static List
getDetails(String str, Mapper mapper) { E entity = mapper.getMapped(str); return mapper.getDetails(entity); } } When I try to compile it, I get following error message: Main.java:29: error: incompatible types: Object cannot be converted to List
.orElseGet(() -> Collections.emptyList()); ^ Note: Main.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. 1 error Neither Eclipse nor Intellij IDEA show an error in the line 29. The Eclipse Java Compiler is able to compile this code. And the latest JDK 9 compiler is able to compile this code too. But the problem is still reproducible in JDK 8u102 Build 04. It would be nice if you could fix it in JDK 8 too as we hit this problem multiple times in our project. And I'm sure other developers may hit this problem too. Adding a cast fixes the problem for now: public static List
calcDetails() { Optional opt = Optional.empty(); return (List
) opt.map(m -> getDetails("A", m)) .orElseGet(() -> Collections.emptyList()); } Best regards, Andrej Golovnin From forax at univ-mlv.fr Wed May 25 10:55:52 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 25 May 2016 12:55:52 +0200 (CEST) Subject: A bug in the Java 8 compiler. In-Reply-To: References: Message-ID: <849908774.1375756.1464173752196.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Andrej Golovnin" > ?: "Compiler Dev" > Envoy?: Mercredi 25 Mai 2016 10:41:37 > Objet: A bug in the Java 8 compiler. > > Hi all, > > consider following code: > > public class Main { > > public static class Details { > // NOP > } > > public static class Mapper { > > public T getMapped(String str) { > return null; > } > > public List
getDetails(T entity) { > return Collections.emptyList(); > } > > } > > public static List
calcDetails() { > Optional opt = Optional.empty(); > return opt.map(m -> getDetails("A", m)) > .orElseGet(() -> Collections.emptyList()); > } > > private static List
getDetails(String str, > Mapper mapper) > { > E entity = mapper.getMapped(str); > return mapper.getDetails(entity); > } > > } > > > When I try to compile it, I get following error message: > > Main.java:29: error: incompatible types: Object cannot be converted to > List
> .orElseGet(() -> Collections.emptyList()); > ^ > Note: Main.java uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > 1 error > > Neither Eclipse nor Intellij IDEA show an error in the line 29. > The Eclipse Java Compiler is able to compile this code. > And the latest JDK 9 compiler is able to compile this code too. > But the problem is still reproducible in JDK 8u102 Build 04. > It would be nice if you could fix it in JDK 8 too as we hit this problem > multiple times in our project. And I'm sure other developers may hit > this problem too. > > Adding a cast fixes the problem for now: > > public static List
calcDetails() { > Optional opt = Optional.empty(); > return (List
) opt.map(m -> getDetails("A", m)) > .orElseGet(() -> Collections.emptyList()); > } > Optional is a rare type i.e. a mix between a parameterized type and a raw type, declaring opt as a, Optional> instead should solve your issue. FWIW, I'm no sure it's not a regression of jdk 9 instead of a bug in jdk8 (trying to do inference with a rare type). > > Best regards, > Andrej Golovnin > R?mi From maurizio.cimadamore at oracle.com Wed May 25 11:12:35 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 25 May 2016 12:12:35 +0100 Subject: A bug in the Java 8 compiler. In-Reply-To: <849908774.1375756.1464173752196.JavaMail.zimbra@u-pem.fr> References: <849908774.1375756.1464173752196.JavaMail.zimbra@u-pem.fr> Message-ID: <574588A3.6090605@oracle.com> On 25/05/16 11:55, Remi Forax wrote: > Optional is a rare type i.e. a mix between a parameterized type and a raw type, declaring opt as a, Optional> instead should solve your issue. > > FWIW, I'm no sure it's not a regression of jdk 9 instead of a bug in jdk8 (trying to do inference with a rare type). Hi By rare type the spec usually means a qualified type which has some raw portions - i.e. given the hierarchy: class Outer { class Inner { } } This is a rare type: Outer.Inner Rare types are disallowed since JDK 5. I don't think Optional falls in this category; that's just a regular parameterized type where the type parameter happens to be a raw type. I don't see any reason as to why the compiler should disallow that and infer 'm' in the lambda as a raw Mapper. I believe the problem seen by Andrej is caused by the fact that JDK 8 and early JDK 9 used to propagate unchecked-ness in a wrong way - the body of the lambda here is calling: getDetails("A", m) where 'm' is raw - this means an unchecked warning is probably generated here. When that happens in 8, the implementation erroneously propagates the uncheckedness outwards, which results in the enclosing method type to be erased too - leading up to this error. We do not plan to backport such fixes because, as discussed in these threads [1], the compatibility impact is not negligible. Maurizio [1] - http://mail.openjdk.java.net/pipermail/compiler-dev/2016-January/009947.html From jonathan.gibbons at oracle.com Thu May 26 00:32:45 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 25 May 2016 17:32:45 -0700 Subject: RFR: 8156962 javac should support options specified in _JAVAC_OPTIONS Message-ID: <5746442D.8090108@oracle.com> This review is for javac to provide limited support to accept options specified in an environment variable when invoked from the command line. JBS: https://bugs.openjdk.java.net/browse/JDK-8156962 Webrev: http://cr.openjdk.java.net/~jjg/8156962/webrev.00/ -- Jon From jonathan.gibbons at oracle.com Thu May 26 00:57:35 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 25 May 2016 17:57:35 -0700 Subject: JDK 9 request for specification changes of JDK-8032230: Enhance javax.a.p.RoundEnvironment after repeating annotations In-Reply-To: <0e72d560-d8a5-0583-513d-a44d3f330dfd@oracle.com> References: <2f908c4d-bbfc-f42b-8728-6e2bf806c3a6@oracle.com> <573CCB24.2030705@oracle.com> <590ed79c-51a6-7cf3-3f5c-c088fab06574@oracle.com> <573CD515.4090602@oracle.com> <573CD6BA.2030202@oracle.com> <4ade37d0-bedb-64d5-250a-ac5f40725d2b@oracle.com> <0e72d560-d8a5-0583-513d-a44d3f330dfd@oracle.com> Message-ID: <574649FF.1030104@oracle.com> Joe, TestingRoundEnvironment is (mostly) cleaver, but why do you bother to override the default methods, and then call them via super? Why not just not override them in the first place? Since this is a class that is simply implementing an interface, the only method can can be invoked is the default method from the interface. -- Jon On 05/24/2016 09:18 AM, joe darcy wrote: > Updated webrev: > > http://cr.openjdk.java.net/~darcy/8032230.1/ > > Now with specialized implementation in javac's implementation of > RoundEnvironment and separate tests of the default methods in the > interface and the javac implementation. > > Thanks, > > -Joe > > > On 5/23/2016 11:21 AM, joe darcy wrote: >> Hello, >> >> Please now review a webrev including the specification and some tests: >> >> http://cr.openjdk.java.net/~darcy/8032230.0/ >> >> Thanks, >> >> -Joe >> >> >> On 5/18/2016 2:02 PM, joe darcy wrote: >>> Combining suggestions, two methods >>> >>> default Set >>> getElementsAnnotatedWithAny(TypeElement... annotations) >>> >>> default Set >>> getElementsAnnotatedWithAny(Set> >>> annotations) >>> >>> No varargs in the second case because of heap pollution with the >>> wildcarded Class type and the inability to use @SafeVarargs on this >>> method since it can be overridden. >>> >>> I'd prefer a set of methods like the above that weren't only tied to >>> repeating annotations since I think there are other use cases where >>> it is helpful to find more than one annotation at a time. >>> >>> Fuller diff below. >>> >>> Thanks, >>> >>> -Joe >>> >>> >>> /** >>> + * Returns the elements annotated with one or more of the given >>> + * annotation types. >>> + * >>> + * @apiNote This method may be useful when processing repeating >>> + * annotations by looking for an annotation type and its >>> + * containing annotation type at the same time. >>> + * >>> + * @implSpec The default implementation of this method creates an >>> + * empty result set, iterates over the annotations in the argument >>> + * set calling {@link #getElementsAnnotatedWith(TypeElement)} on >>> + * each annotation and adding those results to the result >>> + * set. Finally, the contents of the result set are returned as an >>> + * unmodifiable set. >>> + * >>> + * @param annotations annotation types being requested >>> + * @return the elements annotated with one or more of the given >>> + * annotation types, or an empty set if there are none >>> + * @throws IllegalArgumentException if the any elements of the >>> + * argument set do not represent an annotation type >>> + * @since 9 >>> + */ >>> + default Set >>> getElementsAnnotatedWithAny(TypeElement... annotations){ >>> + HashSet result = new HashSet<>(); >>> + for (TypeElement annotation : annotations) { >>> + result.addAll(getElementsAnnotatedWith(annotation)); >>> + } >>> + return Collections.unmodifiableSet(result); >>> + } >>> >>> + /** >>> + * Returns the elements annotated with one or more of the given >>> + * annotation types. >>> + * >>> + * @apiNote This method may be useful when processing repeating >>> + * annotations by looking for an annotation type and its >>> + * containing annotation type at the same time. >>> + * >>> + * @implSpec The default implementation of this method creates an >>> + * empty result set, iterates over the annotations in the argument >>> + * set calling {@link #getElementsAnnotatedWith(Class)} on >>> + * each annotation and adding those results to the result >>> + * set. Finally, the contents of the result set are returned as an >>> + * unmodifiable set. >>> + * >>> + * @param annotations annotation types being requested >>> + * @return the elements annotated with one or more of the given >>> + * annotation types, or an empty set if there are none >>> + * @throws IllegalArgumentException if the any elements of the >>> + * argument set do not represent an annotation type >>> + * @since 9 >>> + */ >>> + default Set >>> getElementsAnnotatedWithAny(Set> >>> annotations){ >>> + HashSet result = new HashSet<>(); >>> + for (Class annotation : annotations) { >>> + result.addAll(getElementsAnnotatedWith(annotation)); >>> + } >>> + return Collections.unmodifiableSet(result); >>> + } >>> >>> >>> On 5/18/2016 1:55 PM, Jonathan Gibbons wrote: >>>> Jan, >>>> >>>> You're getting very close to suggesting a method that takes a >>>> predicate, and we could provide a variety of predicates for (anyOf, >>>> allOf) x (Annotation, AnnotationMirror) x (varags, collection) >>>> >>>> -- Jon >>>> >>>> On 05/18/2016 01:48 PM, Jan Lahoda wrote: >>>>> On 18.5.2016 22:26, joe darcy wrote: >>>>>> Hi Jon, >>>>>> >>>>>> On 5/18/2016 1:05 PM, Jonathan Gibbons wrote: >>>>>>> It's sad to see the preference given to the more intellectually >>>>>>> suspect of the two possibilities. >>>>>> >>>>>> Agreed, sad but pragmatic. >>>>> >>>>> Would it make sense to use varargs instead of a Set? If we assume >>>>> the typical use will be something like: >>>>> round.getElementsAnnotatedWithAny(annotation, containerAnnotation) >>>>> >>>>> it might be more convenient to have the method take a vararg than >>>>> a Set (and would avoid the problem with the erasure clash as >>>>> another benefit). >>>>> >>>>> Jan >>>>> >>>>>> >>>>>>> >>>>>>> It would be nice to see the nice name given to the intellectually >>>>>>> superior of the possibilities (i.e AnnotationMirror) and then >>>>>>> figure >>>>>>> out how to deal with the other case. >>>>>> >>>>>> How about the name "getElementsAnnotatedWithAny" for both >>>>>> variations? >>>>>> That potentially avoids confusion over whether or not the >>>>>> elements have >>>>>> to be modified with any of the annotations or all of them. >>>>>> >>>>>>> >>>>>>> As well as the possibility of another method name, have you ever >>>>>>> considered the possibility of conversion functions of >>>>>>> Elements/Types/ that can convert between >>>>>>> (collection >>>>>>> of) Annotation and (collection of) AnnotationMirror? >>>>>> >>>>>> Internally, for the existing methods javac does convert the >>>>>> Class-based >>>>>> version to the TypeElement based version, but I don't think we >>>>>> want the >>>>>> specification to require that. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Joe >>>>>> >>>>>>> >>>>>>> -- Jon >>>>>>> >>>>>>> On 05/18/2016 12:55 PM, joe darcy wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review the patch below which proposes a new method to >>>>>>>> address >>>>>>>> >>>>>>>> JDK-8032230: Enhance javax.a.p.RoundEnvironment after >>>>>>>> repeating >>>>>>>> annotations >>>>>>>> >>>>>>>> At present, this is just a review of the specification of the >>>>>>>> default >>>>>>>> method in the interface and *not* a more optimized >>>>>>>> implementation in >>>>>>>> the javac RoundEnvironemnt implementation (and not any tests that >>>>>>>> would be needed for the new functionality). >>>>>>>> >>>>>>>> Note that the bug proposes adding two methods >>>>>>>> >>>>>>>> RoundEnvironment.getElementsAnnotatedWith(Set>>>>>>> Annotation>> s) >>>>>>>> RoundEnvironment.getElementsAnnotatedWith(Set s) >>>>>>>> >>>>>>>> but these methods would clash since their erasure is the same. >>>>>>>> *sad >>>>>>>> tromphone* >>>>>>>> >>>>>>>> Therefore, I'm only proposing to add the Class-based variant since >>>>>>>> that one is the more commonly used of the two. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -Joe >>>>>>>> >>>>>>>> >>>>>>>> + /** >>>>>>>> + * Returns the elements annotated with any of the given >>>>>>>> annotation >>>>>>>> + * types. >>>>>>>> + * >>>>>>>> + * @apiNote This method may be useful when processing >>>>>>>> repeating >>>>>>>> + * annotations by looking for an annotation type and its >>>>>>>> + * containing annotation type at the same time. >>>>>>>> + * >>>>>>>> + * @implSpec The default implementation of this method >>>>>>>> creates an >>>>>>>> + * empty result set, iterates over the annotations in the >>>>>>>> argument >>>>>>>> + * set calling {@link >>>>>>>> #getElementsAnnotatedWith(TypeElement)} on >>>>>>>> + * each annotation and adding those results to the result >>>>>>>> + * set. Finally, the contents of the result set are >>>>>>>> returned as an >>>>>>>> + * unmodifiable set. >>>>>>>> + * >>>>>>>> + * @param annotations annotation type being requested >>>>>>>> + * @return the elements annotated with the given >>>>>>>> annotation types, >>>>>>>> + * or an empty set if there are none >>>>>>>> + * @throws IllegalArgumentException if the any elements of >>>>>>>> the >>>>>>>> + * argument set do not represent an annotation type >>>>>>>> + * @since 9 >>>>>>>> + */ >>>>>>>> + default Set >>>>>>>> getElementsAnnotatedWith(Set> >>>>>>>> annotations){ >>>>>>>> + HashSet result = new HashSet<>(); >>>>>>>> + for (Class annotation : >>>>>>>> annotations) { >>>>>>>> + result.addAll(getElementsAnnotatedWith(annotation)); >>>>>>>> + } >>>>>>>> + return Collections.unmodifiableSet(result); >>>>>>>> + } >>>>>>>> >>>>>>> >>>>>> >>>> >>> >> > From joe.darcy at oracle.com Thu May 26 02:46:10 2016 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 25 May 2016 19:46:10 -0700 Subject: JDK 9 request for specification changes of JDK-8032230: Enhance javax.a.p.RoundEnvironment after repeating annotations In-Reply-To: <574649FF.1030104@oracle.com> References: <2f908c4d-bbfc-f42b-8728-6e2bf806c3a6@oracle.com> <573CCB24.2030705@oracle.com> <590ed79c-51a6-7cf3-3f5c-c088fab06574@oracle.com> <573CD515.4090602@oracle.com> <573CD6BA.2030202@oracle.com> <4ade37d0-bedb-64d5-250a-ac5f40725d2b@oracle.com> <0e72d560-d8a5-0583-513d-a44d3f330dfd@oracle.com> <574649FF.1030104@oracle.com> Message-ID: <535abf49-f597-5580-81eb-42f827a24fc7@oracle.com> Hi Jon, On 5/25/2016 5:57 PM, Jonathan Gibbons wrote: > Joe, > > TestingRoundEnvironment is (mostly) cleaver, but why do you bother to > override the default methods, and then call them via super? > > Why not just not override them in the first place? Since this is a > class that is simply implementing an interface, the only method can > can be invoked is the default method from the interface. I thought, perhaps incorrectly, that explicitly calling the interface methods (as opposed to not overriding those methods) would more clearly indicate the intention of the wrapper class. Do you think a more explicit comment about this intention on the wrapper class would help clarify matters? -Joe > > -- Jon > > > > On 05/24/2016 09:18 AM, joe darcy wrote: >> Updated webrev: >> >> http://cr.openjdk.java.net/~darcy/8032230.1/ >> >> Now with specialized implementation in javac's implementation of >> RoundEnvironment and separate tests of the default methods in the >> interface and the javac implementation. >> >> Thanks, >> >> -Joe >> >> >> On 5/23/2016 11:21 AM, joe darcy wrote: >>> Hello, >>> >>> Please now review a webrev including the specification and some tests: >>> >>> http://cr.openjdk.java.net/~darcy/8032230.0/ >>> >>> Thanks, >>> >>> -Joe >>> >>> >>> On 5/18/2016 2:02 PM, joe darcy wrote: >>>> Combining suggestions, two methods >>>> >>>> default Set >>>> getElementsAnnotatedWithAny(TypeElement... annotations) >>>> >>>> default Set >>>> getElementsAnnotatedWithAny(Set> >>>> annotations) >>>> >>>> No varargs in the second case because of heap pollution with the >>>> wildcarded Class type and the inability to use @SafeVarargs on this >>>> method since it can be overridden. >>>> >>>> I'd prefer a set of methods like the above that weren't only tied >>>> to repeating annotations since I think there are other use cases >>>> where it is helpful to find more than one annotation at a time. >>>> >>>> Fuller diff below. >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>>> >>>> /** >>>> + * Returns the elements annotated with one or more of the given >>>> + * annotation types. >>>> + * >>>> + * @apiNote This method may be useful when processing repeating >>>> + * annotations by looking for an annotation type and its >>>> + * containing annotation type at the same time. >>>> + * >>>> + * @implSpec The default implementation of this method creates an >>>> + * empty result set, iterates over the annotations in the >>>> argument >>>> + * set calling {@link #getElementsAnnotatedWith(TypeElement)} on >>>> + * each annotation and adding those results to the result >>>> + * set. Finally, the contents of the result set are returned >>>> as an >>>> + * unmodifiable set. >>>> + * >>>> + * @param annotations annotation types being requested >>>> + * @return the elements annotated with one or more of the given >>>> + * annotation types, or an empty set if there are none >>>> + * @throws IllegalArgumentException if the any elements of the >>>> + * argument set do not represent an annotation type >>>> + * @since 9 >>>> + */ >>>> + default Set >>>> getElementsAnnotatedWithAny(TypeElement... annotations){ >>>> + HashSet result = new HashSet<>(); >>>> + for (TypeElement annotation : annotations) { >>>> + result.addAll(getElementsAnnotatedWith(annotation)); >>>> + } >>>> + return Collections.unmodifiableSet(result); >>>> + } >>>> >>>> + /** >>>> + * Returns the elements annotated with one or more of the given >>>> + * annotation types. >>>> + * >>>> + * @apiNote This method may be useful when processing repeating >>>> + * annotations by looking for an annotation type and its >>>> + * containing annotation type at the same time. >>>> + * >>>> + * @implSpec The default implementation of this method creates an >>>> + * empty result set, iterates over the annotations in the >>>> argument >>>> + * set calling {@link #getElementsAnnotatedWith(Class)} on >>>> + * each annotation and adding those results to the result >>>> + * set. Finally, the contents of the result set are returned >>>> as an >>>> + * unmodifiable set. >>>> + * >>>> + * @param annotations annotation types being requested >>>> + * @return the elements annotated with one or more of the given >>>> + * annotation types, or an empty set if there are none >>>> + * @throws IllegalArgumentException if the any elements of the >>>> + * argument set do not represent an annotation type >>>> + * @since 9 >>>> + */ >>>> + default Set >>>> getElementsAnnotatedWithAny(Set> >>>> annotations){ >>>> + HashSet result = new HashSet<>(); >>>> + for (Class annotation : annotations) { >>>> + result.addAll(getElementsAnnotatedWith(annotation)); >>>> + } >>>> + return Collections.unmodifiableSet(result); >>>> + } >>>> >>>> >>>> On 5/18/2016 1:55 PM, Jonathan Gibbons wrote: >>>>> Jan, >>>>> >>>>> You're getting very close to suggesting a method that takes a >>>>> predicate, and we could provide a variety of predicates for >>>>> (anyOf, allOf) x (Annotation, AnnotationMirror) x (varags, >>>>> collection) >>>>> >>>>> -- Jon >>>>> >>>>> On 05/18/2016 01:48 PM, Jan Lahoda wrote: >>>>>> On 18.5.2016 22:26, joe darcy wrote: >>>>>>> Hi Jon, >>>>>>> >>>>>>> On 5/18/2016 1:05 PM, Jonathan Gibbons wrote: >>>>>>>> It's sad to see the preference given to the more intellectually >>>>>>>> suspect of the two possibilities. >>>>>>> >>>>>>> Agreed, sad but pragmatic. >>>>>> >>>>>> Would it make sense to use varargs instead of a Set? If we assume >>>>>> the typical use will be something like: >>>>>> round.getElementsAnnotatedWithAny(annotation, containerAnnotation) >>>>>> >>>>>> it might be more convenient to have the method take a vararg than >>>>>> a Set (and would avoid the problem with the erasure clash as >>>>>> another benefit). >>>>>> >>>>>> Jan >>>>>> >>>>>>> >>>>>>>> >>>>>>>> It would be nice to see the nice name given to the intellectually >>>>>>>> superior of the possibilities (i.e AnnotationMirror) and then >>>>>>>> figure >>>>>>>> out how to deal with the other case. >>>>>>> >>>>>>> How about the name "getElementsAnnotatedWithAny" for both >>>>>>> variations? >>>>>>> That potentially avoids confusion over whether or not the >>>>>>> elements have >>>>>>> to be modified with any of the annotations or all of them. >>>>>>> >>>>>>>> >>>>>>>> As well as the possibility of another method name, have you ever >>>>>>>> considered the possibility of conversion functions of >>>>>>>> Elements/Types/ that can convert between >>>>>>>> (collection >>>>>>>> of) Annotation and (collection of) AnnotationMirror? >>>>>>> >>>>>>> Internally, for the existing methods javac does convert the >>>>>>> Class-based >>>>>>> version to the TypeElement based version, but I don't think we >>>>>>> want the >>>>>>> specification to require that. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -Joe >>>>>>> >>>>>>>> >>>>>>>> -- Jon >>>>>>>> >>>>>>>> On 05/18/2016 12:55 PM, joe darcy wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Please review the patch below which proposes a new method to >>>>>>>>> address >>>>>>>>> >>>>>>>>> JDK-8032230: Enhance javax.a.p.RoundEnvironment after >>>>>>>>> repeating >>>>>>>>> annotations >>>>>>>>> >>>>>>>>> At present, this is just a review of the specification of the >>>>>>>>> default >>>>>>>>> method in the interface and *not* a more optimized >>>>>>>>> implementation in >>>>>>>>> the javac RoundEnvironemnt implementation (and not any tests that >>>>>>>>> would be needed for the new functionality). >>>>>>>>> >>>>>>>>> Note that the bug proposes adding two methods >>>>>>>>> >>>>>>>>> RoundEnvironment.getElementsAnnotatedWith(Set>>>>>>>> Annotation>> s) >>>>>>>>> RoundEnvironment.getElementsAnnotatedWith(Set >>>>>>>>> s) >>>>>>>>> >>>>>>>>> but these methods would clash since their erasure is the same. >>>>>>>>> *sad >>>>>>>>> tromphone* >>>>>>>>> >>>>>>>>> Therefore, I'm only proposing to add the Class-based variant >>>>>>>>> since >>>>>>>>> that one is the more commonly used of the two. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -Joe >>>>>>>>> >>>>>>>>> >>>>>>>>> + /** >>>>>>>>> + * Returns the elements annotated with any of the given >>>>>>>>> annotation >>>>>>>>> + * types. >>>>>>>>> + * >>>>>>>>> + * @apiNote This method may be useful when processing >>>>>>>>> repeating >>>>>>>>> + * annotations by looking for an annotation type and its >>>>>>>>> + * containing annotation type at the same time. >>>>>>>>> + * >>>>>>>>> + * @implSpec The default implementation of this method >>>>>>>>> creates an >>>>>>>>> + * empty result set, iterates over the annotations in the >>>>>>>>> argument >>>>>>>>> + * set calling {@link >>>>>>>>> #getElementsAnnotatedWith(TypeElement)} on >>>>>>>>> + * each annotation and adding those results to the result >>>>>>>>> + * set. Finally, the contents of the result set are >>>>>>>>> returned as an >>>>>>>>> + * unmodifiable set. >>>>>>>>> + * >>>>>>>>> + * @param annotations annotation type being requested >>>>>>>>> + * @return the elements annotated with the given >>>>>>>>> annotation types, >>>>>>>>> + * or an empty set if there are none >>>>>>>>> + * @throws IllegalArgumentException if the any elements >>>>>>>>> of the >>>>>>>>> + * argument set do not represent an annotation type >>>>>>>>> + * @since 9 >>>>>>>>> + */ >>>>>>>>> + default Set >>>>>>>>> getElementsAnnotatedWith(Set> >>>>>>>>> annotations){ >>>>>>>>> + HashSet result = new HashSet<>(); >>>>>>>>> + for (Class annotation : >>>>>>>>> annotations) { >>>>>>>>> + result.addAll(getElementsAnnotatedWith(annotation)); >>>>>>>>> + } >>>>>>>>> + return Collections.unmodifiableSet(result); >>>>>>>>> + } >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >>> >> > From jonathan.gibbons at oracle.com Thu May 26 02:58:52 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 25 May 2016 19:58:52 -0700 Subject: JDK 9 request for specification changes of JDK-8032230: Enhance javax.a.p.RoundEnvironment after repeating annotations In-Reply-To: <535abf49-f597-5580-81eb-42f827a24fc7@oracle.com> References: <2f908c4d-bbfc-f42b-8728-6e2bf806c3a6@oracle.com> <573CCB24.2030705@oracle.com> <590ed79c-51a6-7cf3-3f5c-c088fab06574@oracle.com> <573CD515.4090602@oracle.com> <573CD6BA.2030202@oracle.com> <4ade37d0-bedb-64d5-250a-ac5f40725d2b@oracle.com> <0e72d560-d8a5-0583-513d-a44d3f330dfd@oracle.com> <574649FF.1030104@oracle.com> <535abf49-f597-5580-81eb-42f827a24fc7@oracle.com> Message-ID: <5746666C.4040408@oracle.com> Well, it did seem strange to have the overriding method (just) call the method it was overriding ;-) One alternative for your consideration: Instead of 109 @Override 110 public Set getElementsAnnotatedWithAny(TypeElement... a) { 111 // Default method defined in the interface 112 return RoundEnvironment.super.getElementsAnnotatedWithAny(a); 113 } how about 109 // inherit default impl of this method from the interface 110 // public Set getElementsAnnotatedWithAny(TypeElement... a) Or, you could put comments on the class itself. // This class delegates all abstract methods on the interface to the {@code RoundEnvironment} // provided when the class is created, relying on the default methods provided in the interface // for ....(fill in details)... Whichever way you go, overriding the methods or not, I think some clarifying comments are in order. -- Jon On 05/25/2016 07:46 PM, joe darcy wrote: > Hi Jon, > > > On 5/25/2016 5:57 PM, Jonathan Gibbons wrote: >> Joe, >> >> TestingRoundEnvironment is (mostly) cleaver, but why do you bother to >> override the default methods, and then call them via super? >> >> Why not just not override them in the first place? Since this is a >> class that is simply implementing an interface, the only method can >> can be invoked is the default method from the interface. > > I thought, perhaps incorrectly, that explicitly calling the interface > methods (as opposed to not overriding those methods) would more > clearly indicate the intention of the wrapper class. > > Do you think a more explicit comment about this intention on the > wrapper class would help clarify matters? > > -Joe > >> >> -- Jon >> >> >> >> On 05/24/2016 09:18 AM, joe darcy wrote: >>> Updated webrev: >>> >>> http://cr.openjdk.java.net/~darcy/8032230.1/ >>> >>> Now with specialized implementation in javac's implementation of >>> RoundEnvironment and separate tests of the default methods in the >>> interface and the javac implementation. >>> >>> Thanks, >>> >>> -Joe >>> >>> >>> On 5/23/2016 11:21 AM, joe darcy wrote: >>>> Hello, >>>> >>>> Please now review a webrev including the specification and some tests: >>>> >>>> http://cr.openjdk.java.net/~darcy/8032230.0/ >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>>> >>>> On 5/18/2016 2:02 PM, joe darcy wrote: >>>>> Combining suggestions, two methods >>>>> >>>>> default Set >>>>> getElementsAnnotatedWithAny(TypeElement... annotations) >>>>> >>>>> default Set >>>>> getElementsAnnotatedWithAny(Set> >>>>> annotations) >>>>> >>>>> No varargs in the second case because of heap pollution with the >>>>> wildcarded Class type and the inability to use @SafeVarargs on >>>>> this method since it can be overridden. >>>>> >>>>> I'd prefer a set of methods like the above that weren't only tied >>>>> to repeating annotations since I think there are other use cases >>>>> where it is helpful to find more than one annotation at a time. >>>>> >>>>> Fuller diff below. >>>>> >>>>> Thanks, >>>>> >>>>> -Joe >>>>> >>>>> >>>>> /** >>>>> + * Returns the elements annotated with one or more of the given >>>>> + * annotation types. >>>>> + * >>>>> + * @apiNote This method may be useful when processing repeating >>>>> + * annotations by looking for an annotation type and its >>>>> + * containing annotation type at the same time. >>>>> + * >>>>> + * @implSpec The default implementation of this method >>>>> creates an >>>>> + * empty result set, iterates over the annotations in the >>>>> argument >>>>> + * set calling {@link #getElementsAnnotatedWith(TypeElement)} on >>>>> + * each annotation and adding those results to the result >>>>> + * set. Finally, the contents of the result set are returned >>>>> as an >>>>> + * unmodifiable set. >>>>> + * >>>>> + * @param annotations annotation types being requested >>>>> + * @return the elements annotated with one or more of the given >>>>> + * annotation types, or an empty set if there are none >>>>> + * @throws IllegalArgumentException if the any elements of the >>>>> + * argument set do not represent an annotation type >>>>> + * @since 9 >>>>> + */ >>>>> + default Set >>>>> getElementsAnnotatedWithAny(TypeElement... annotations){ >>>>> + HashSet result = new HashSet<>(); >>>>> + for (TypeElement annotation : annotations) { >>>>> + result.addAll(getElementsAnnotatedWith(annotation)); >>>>> + } >>>>> + return Collections.unmodifiableSet(result); >>>>> + } >>>>> >>>>> + /** >>>>> + * Returns the elements annotated with one or more of the given >>>>> + * annotation types. >>>>> + * >>>>> + * @apiNote This method may be useful when processing repeating >>>>> + * annotations by looking for an annotation type and its >>>>> + * containing annotation type at the same time. >>>>> + * >>>>> + * @implSpec The default implementation of this method >>>>> creates an >>>>> + * empty result set, iterates over the annotations in the >>>>> argument >>>>> + * set calling {@link #getElementsAnnotatedWith(Class)} on >>>>> + * each annotation and adding those results to the result >>>>> + * set. Finally, the contents of the result set are returned >>>>> as an >>>>> + * unmodifiable set. >>>>> + * >>>>> + * @param annotations annotation types being requested >>>>> + * @return the elements annotated with one or more of the given >>>>> + * annotation types, or an empty set if there are none >>>>> + * @throws IllegalArgumentException if the any elements of the >>>>> + * argument set do not represent an annotation type >>>>> + * @since 9 >>>>> + */ >>>>> + default Set >>>>> getElementsAnnotatedWithAny(Set> >>>>> annotations){ >>>>> + HashSet result = new HashSet<>(); >>>>> + for (Class annotation : annotations) { >>>>> + result.addAll(getElementsAnnotatedWith(annotation)); >>>>> + } >>>>> + return Collections.unmodifiableSet(result); >>>>> + } >>>>> >>>>> >>>>> On 5/18/2016 1:55 PM, Jonathan Gibbons wrote: >>>>>> Jan, >>>>>> >>>>>> You're getting very close to suggesting a method that takes a >>>>>> predicate, and we could provide a variety of predicates for >>>>>> (anyOf, allOf) x (Annotation, AnnotationMirror) x (varags, >>>>>> collection) >>>>>> >>>>>> -- Jon >>>>>> >>>>>> On 05/18/2016 01:48 PM, Jan Lahoda wrote: >>>>>>> On 18.5.2016 22:26, joe darcy wrote: >>>>>>>> Hi Jon, >>>>>>>> >>>>>>>> On 5/18/2016 1:05 PM, Jonathan Gibbons wrote: >>>>>>>>> It's sad to see the preference given to the more intellectually >>>>>>>>> suspect of the two possibilities. >>>>>>>> >>>>>>>> Agreed, sad but pragmatic. >>>>>>> >>>>>>> Would it make sense to use varargs instead of a Set? If we >>>>>>> assume the typical use will be something like: >>>>>>> round.getElementsAnnotatedWithAny(annotation, containerAnnotation) >>>>>>> >>>>>>> it might be more convenient to have the method take a vararg >>>>>>> than a Set (and would avoid the problem with the erasure clash >>>>>>> as another benefit). >>>>>>> >>>>>>> Jan >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> It would be nice to see the nice name given to the intellectually >>>>>>>>> superior of the possibilities (i.e AnnotationMirror) and then >>>>>>>>> figure >>>>>>>>> out how to deal with the other case. >>>>>>>> >>>>>>>> How about the name "getElementsAnnotatedWithAny" for both >>>>>>>> variations? >>>>>>>> That potentially avoids confusion over whether or not the >>>>>>>> elements have >>>>>>>> to be modified with any of the annotations or all of them. >>>>>>>> >>>>>>>>> >>>>>>>>> As well as the possibility of another method name, have you ever >>>>>>>>> considered the possibility of conversion functions of >>>>>>>>> Elements/Types/ that can convert between >>>>>>>>> (collection >>>>>>>>> of) Annotation and (collection of) AnnotationMirror? >>>>>>>> >>>>>>>> Internally, for the existing methods javac does convert the >>>>>>>> Class-based >>>>>>>> version to the TypeElement based version, but I don't think we >>>>>>>> want the >>>>>>>> specification to require that. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -Joe >>>>>>>> >>>>>>>>> >>>>>>>>> -- Jon >>>>>>>>> >>>>>>>>> On 05/18/2016 12:55 PM, joe darcy wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Please review the patch below which proposes a new method to >>>>>>>>>> address >>>>>>>>>> >>>>>>>>>> JDK-8032230: Enhance javax.a.p.RoundEnvironment after >>>>>>>>>> repeating >>>>>>>>>> annotations >>>>>>>>>> >>>>>>>>>> At present, this is just a review of the specification of the >>>>>>>>>> default >>>>>>>>>> method in the interface and *not* a more optimized >>>>>>>>>> implementation in >>>>>>>>>> the javac RoundEnvironemnt implementation (and not any tests >>>>>>>>>> that >>>>>>>>>> would be needed for the new functionality). >>>>>>>>>> >>>>>>>>>> Note that the bug proposes adding two methods >>>>>>>>>> >>>>>>>>>> RoundEnvironment.getElementsAnnotatedWith(Set>>>>>>>>> Annotation>> s) >>>>>>>>>> RoundEnvironment.getElementsAnnotatedWith(Set >>>>>>>>>> s) >>>>>>>>>> >>>>>>>>>> but these methods would clash since their erasure is the >>>>>>>>>> same. *sad >>>>>>>>>> tromphone* >>>>>>>>>> >>>>>>>>>> Therefore, I'm only proposing to add the Class-based variant >>>>>>>>>> since >>>>>>>>>> that one is the more commonly used of the two. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> -Joe >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> + /** >>>>>>>>>> + * Returns the elements annotated with any of the given >>>>>>>>>> annotation >>>>>>>>>> + * types. >>>>>>>>>> + * >>>>>>>>>> + * @apiNote This method may be useful when processing >>>>>>>>>> repeating >>>>>>>>>> + * annotations by looking for an annotation type and its >>>>>>>>>> + * containing annotation type at the same time. >>>>>>>>>> + * >>>>>>>>>> + * @implSpec The default implementation of this method >>>>>>>>>> creates an >>>>>>>>>> + * empty result set, iterates over the annotations in >>>>>>>>>> the argument >>>>>>>>>> + * set calling {@link >>>>>>>>>> #getElementsAnnotatedWith(TypeElement)} on >>>>>>>>>> + * each annotation and adding those results to the result >>>>>>>>>> + * set. Finally, the contents of the result set are >>>>>>>>>> returned as an >>>>>>>>>> + * unmodifiable set. >>>>>>>>>> + * >>>>>>>>>> + * @param annotations annotation type being requested >>>>>>>>>> + * @return the elements annotated with the given >>>>>>>>>> annotation types, >>>>>>>>>> + * or an empty set if there are none >>>>>>>>>> + * @throws IllegalArgumentException if the any elements >>>>>>>>>> of the >>>>>>>>>> + * argument set do not represent an annotation type >>>>>>>>>> + * @since 9 >>>>>>>>>> + */ >>>>>>>>>> + default Set >>>>>>>>>> getElementsAnnotatedWith(Set> >>>>>>>>>> annotations){ >>>>>>>>>> + HashSet result = new HashSet<>(); >>>>>>>>>> + for (Class annotation : >>>>>>>>>> annotations) { >>>>>>>>>> + result.addAll(getElementsAnnotatedWith(annotation)); >>>>>>>>>> + } >>>>>>>>>> + return Collections.unmodifiableSet(result); >>>>>>>>>> + } >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> > From srikanth.adayapalam at oracle.com Thu May 26 03:51:29 2016 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Thu, 26 May 2016 09:21:29 +0530 Subject: RFR: Javadoc adjustment for https://bugs.openjdk.java.net/browse/JDK-8033812 In-Reply-To: <57442593.3020704@oracle.com> References: <574420F1.5060207@oracle.com> <574421B0.6070807@oracle.com> <57442593.3020704@oracle.com> Message-ID: <574672C1.4060005@oracle.com> Per Elena's suggestion (Thanks!), here is another revision that simply elides mention of count of type contexts - thus this is a slightly better future proof version. Please re-review: http://cr.openjdk.java.net/~sadayapalam/webrev.01/ TIA Srikanth On Tuesday 24 May 2016 03:27 PM, Maurizio Cimadamore wrote: > Looks good! > > Maurizio > > On 24/05/16 10:41, Srikanth wrote: >> The link to review: >> >> http://cr.openjdk.java.net/~sadayapalam/JDK-8033812/webrev.00/ >> >> Thanks! >> Srikanth >> >> On Tuesday 24 May 2016 03:07 PM, Srikanth wrote: >>> Hello, >>> >>> Thanks in advance for reviewing this minor change to the javadoc of >>> ElementType.TYPE_USE made for JDK-8033812 >>> >>> Thanks! >>> Srikanth >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steff.nicolas at gmail.com Thu May 26 04:32:38 2016 From: steff.nicolas at gmail.com (=?UTF-8?Q?St=C3=A9phane_NICOLAS?=) Date: Wed, 25 May 2016 21:32:38 -0700 Subject: Why the annotation processing API ? Message-ID: Hi folks, I know a simple mail like this generally has very minimal value. But still, it's been around 2-3 years now that I work on Android, doing a lot of work around reflection and annotation processing. I don't like the annotation processing API. I still find every concept hard to remember, and it is always taking time to get immersed into it for a new project. Thus, I don't understand, very humbly and very honestly, why this API even exists. Why can't we simply use reflection-like APIs ? It would not be that complex to expose an API that looks like reflection (read-only of course, no new instance of classes, to method calls or setting/getting field values, just the discovery part). I could see over the past years that the newer versions of the JDK are aligning more and more the capacities of the annotation processing API with reflection APIs. Some subtle changes but always in this direction. All you can do with reflection is now possible with annotation processing (read-only still, as stated above). Does it sound completely stupid to ask that javac annotation processor API for JDK 10 would actually match reflection API ? Reflection API is so simple and it describes OO code in a natural way for all java coders. Methods, classes, fields... much simpler than an element type with a kind that you can cast into I don't know what ! Annotation processing API is not clear. It is obviously overworked, complex, abstract, very scholar and hard to use. Is there anything that can be done with respect to this problem ? I hope I am not saying something completely dumb here, but I have been thinking about this for a very long time now. S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Thu May 26 05:26:43 2016 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 25 May 2016 22:26:43 -0700 Subject: JDK 9 request for specification changes of JDK-8032230: Enhance javax.a.p.RoundEnvironment after repeating annotations In-Reply-To: <5746666C.4040408@oracle.com> References: <2f908c4d-bbfc-f42b-8728-6e2bf806c3a6@oracle.com> <573CCB24.2030705@oracle.com> <590ed79c-51a6-7cf3-3f5c-c088fab06574@oracle.com> <573CD515.4090602@oracle.com> <573CD6BA.2030202@oracle.com> <4ade37d0-bedb-64d5-250a-ac5f40725d2b@oracle.com> <0e72d560-d8a5-0583-513d-a44d3f330dfd@oracle.com> <574649FF.1030104@oracle.com> <535abf49-f597-5580-81eb-42f827a24fc7@oracle.com> <5746666C.4040408@oracle.com> Message-ID: <2d461ffd-d579-7935-98c6-dd00f2615f5f@oracle.com> Hi Jon, Will push with an explanatory note on the TestingRoundEnvironment class. Thanks, -Joe On 5/25/2016 7:58 PM, Jonathan Gibbons wrote: > Well, it did seem strange to have the overriding method (just) call > the method it was overriding ;-) > > > One alternative for your consideration: > > Instead of > > 109 @Override > 110 public Set > getElementsAnnotatedWithAny(TypeElement... a) { > 111 // Default method defined in the interface > 112 return > RoundEnvironment.super.getElementsAnnotatedWithAny(a); > 113 } > > how about > > 109 // inherit default impl of this method from the interface > 110 // public Set > getElementsAnnotatedWithAny(TypeElement... a) > > > Or, you could put comments on the class itself. > // This class delegates all abstract methods on the interface to > the {@code RoundEnvironment} > // provided when the class is created, relying on the default > methods provided in the interface > // for ....(fill in details)... > > Whichever way you go, overriding the methods or not, I think some > clarifying comments are > in order. > > -- Jon > > > On 05/25/2016 07:46 PM, joe darcy wrote: >> Hi Jon, >> >> >> On 5/25/2016 5:57 PM, Jonathan Gibbons wrote: >>> Joe, >>> >>> TestingRoundEnvironment is (mostly) cleaver, but why do you bother >>> to override the default methods, and then call them via super? >>> >>> Why not just not override them in the first place? Since this is a >>> class that is simply implementing an interface, the only method can >>> can be invoked is the default method from the interface. >> >> I thought, perhaps incorrectly, that explicitly calling the interface >> methods (as opposed to not overriding those methods) would more >> clearly indicate the intention of the wrapper class. >> >> Do you think a more explicit comment about this intention on the >> wrapper class would help clarify matters? >> >> -Joe >> >>> >>> -- Jon >>> >>> >>> >>> On 05/24/2016 09:18 AM, joe darcy wrote: >>>> Updated webrev: >>>> >>>> http://cr.openjdk.java.net/~darcy/8032230.1/ >>>> >>>> Now with specialized implementation in javac's implementation of >>>> RoundEnvironment and separate tests of the default methods in the >>>> interface and the javac implementation. >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>>> >>>> On 5/23/2016 11:21 AM, joe darcy wrote: >>>>> Hello, >>>>> >>>>> Please now review a webrev including the specification and some >>>>> tests: >>>>> >>>>> http://cr.openjdk.java.net/~darcy/8032230.0/ >>>>> >>>>> Thanks, >>>>> >>>>> -Joe >>>>> >>>>> >>>>> On 5/18/2016 2:02 PM, joe darcy wrote: >>>>>> Combining suggestions, two methods >>>>>> >>>>>> default Set >>>>>> getElementsAnnotatedWithAny(TypeElement... annotations) >>>>>> >>>>>> default Set >>>>>> getElementsAnnotatedWithAny(Set> >>>>>> annotations) >>>>>> >>>>>> No varargs in the second case because of heap pollution with the >>>>>> wildcarded Class type and the inability to use @SafeVarargs on >>>>>> this method since it can be overridden. >>>>>> >>>>>> I'd prefer a set of methods like the above that weren't only tied >>>>>> to repeating annotations since I think there are other use cases >>>>>> where it is helpful to find more than one annotation at a time. >>>>>> >>>>>> Fuller diff below. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Joe >>>>>> >>>>>> >>>>>> /** >>>>>> + * Returns the elements annotated with one or more of the given >>>>>> + * annotation types. >>>>>> + * >>>>>> + * @apiNote This method may be useful when processing repeating >>>>>> + * annotations by looking for an annotation type and its >>>>>> + * containing annotation type at the same time. >>>>>> + * >>>>>> + * @implSpec The default implementation of this method >>>>>> creates an >>>>>> + * empty result set, iterates over the annotations in the >>>>>> argument >>>>>> + * set calling {@link >>>>>> #getElementsAnnotatedWith(TypeElement)} on >>>>>> + * each annotation and adding those results to the result >>>>>> + * set. Finally, the contents of the result set are returned >>>>>> as an >>>>>> + * unmodifiable set. >>>>>> + * >>>>>> + * @param annotations annotation types being requested >>>>>> + * @return the elements annotated with one or more of the given >>>>>> + * annotation types, or an empty set if there are none >>>>>> + * @throws IllegalArgumentException if the any elements of the >>>>>> + * argument set do not represent an annotation type >>>>>> + * @since 9 >>>>>> + */ >>>>>> + default Set >>>>>> getElementsAnnotatedWithAny(TypeElement... annotations){ >>>>>> + HashSet result = new HashSet<>(); >>>>>> + for (TypeElement annotation : annotations) { >>>>>> + result.addAll(getElementsAnnotatedWith(annotation)); >>>>>> + } >>>>>> + return Collections.unmodifiableSet(result); >>>>>> + } >>>>>> >>>>>> + /** >>>>>> + * Returns the elements annotated with one or more of the given >>>>>> + * annotation types. >>>>>> + * >>>>>> + * @apiNote This method may be useful when processing repeating >>>>>> + * annotations by looking for an annotation type and its >>>>>> + * containing annotation type at the same time. >>>>>> + * >>>>>> + * @implSpec The default implementation of this method >>>>>> creates an >>>>>> + * empty result set, iterates over the annotations in the >>>>>> argument >>>>>> + * set calling {@link #getElementsAnnotatedWith(Class)} on >>>>>> + * each annotation and adding those results to the result >>>>>> + * set. Finally, the contents of the result set are returned >>>>>> as an >>>>>> + * unmodifiable set. >>>>>> + * >>>>>> + * @param annotations annotation types being requested >>>>>> + * @return the elements annotated with one or more of the given >>>>>> + * annotation types, or an empty set if there are none >>>>>> + * @throws IllegalArgumentException if the any elements of the >>>>>> + * argument set do not represent an annotation type >>>>>> + * @since 9 >>>>>> + */ >>>>>> + default Set >>>>>> getElementsAnnotatedWithAny(Set> >>>>>> annotations){ >>>>>> + HashSet result = new HashSet<>(); >>>>>> + for (Class annotation : >>>>>> annotations) { >>>>>> + result.addAll(getElementsAnnotatedWith(annotation)); >>>>>> + } >>>>>> + return Collections.unmodifiableSet(result); >>>>>> + } >>>>>> >>>>>> >>>>>> On 5/18/2016 1:55 PM, Jonathan Gibbons wrote: >>>>>>> Jan, >>>>>>> >>>>>>> You're getting very close to suggesting a method that takes a >>>>>>> predicate, and we could provide a variety of predicates for >>>>>>> (anyOf, allOf) x (Annotation, AnnotationMirror) x (varags, >>>>>>> collection) >>>>>>> >>>>>>> -- Jon >>>>>>> >>>>>>> On 05/18/2016 01:48 PM, Jan Lahoda wrote: >>>>>>>> On 18.5.2016 22:26, joe darcy wrote: >>>>>>>>> Hi Jon, >>>>>>>>> >>>>>>>>> On 5/18/2016 1:05 PM, Jonathan Gibbons wrote: >>>>>>>>>> It's sad to see the preference given to the more intellectually >>>>>>>>>> suspect of the two possibilities. >>>>>>>>> >>>>>>>>> Agreed, sad but pragmatic. >>>>>>>> >>>>>>>> Would it make sense to use varargs instead of a Set? If we >>>>>>>> assume the typical use will be something like: >>>>>>>> round.getElementsAnnotatedWithAny(annotation, containerAnnotation) >>>>>>>> >>>>>>>> it might be more convenient to have the method take a vararg >>>>>>>> than a Set (and would avoid the problem with the erasure clash >>>>>>>> as another benefit). >>>>>>>> >>>>>>>> Jan >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> It would be nice to see the nice name given to the >>>>>>>>>> intellectually >>>>>>>>>> superior of the possibilities (i.e AnnotationMirror) and then >>>>>>>>>> figure >>>>>>>>>> out how to deal with the other case. >>>>>>>>> >>>>>>>>> How about the name "getElementsAnnotatedWithAny" for both >>>>>>>>> variations? >>>>>>>>> That potentially avoids confusion over whether or not the >>>>>>>>> elements have >>>>>>>>> to be modified with any of the annotations or all of them. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> As well as the possibility of another method name, have you ever >>>>>>>>>> considered the possibility of conversion functions of >>>>>>>>>> Elements/Types/ that can convert between >>>>>>>>>> (collection >>>>>>>>>> of) Annotation and (collection of) AnnotationMirror? >>>>>>>>> >>>>>>>>> Internally, for the existing methods javac does convert the >>>>>>>>> Class-based >>>>>>>>> version to the TypeElement based version, but I don't think we >>>>>>>>> want the >>>>>>>>> specification to require that. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -Joe >>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- Jon >>>>>>>>>> >>>>>>>>>> On 05/18/2016 12:55 PM, joe darcy wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> Please review the patch below which proposes a new method to >>>>>>>>>>> address >>>>>>>>>>> >>>>>>>>>>> JDK-8032230: Enhance javax.a.p.RoundEnvironment after >>>>>>>>>>> repeating >>>>>>>>>>> annotations >>>>>>>>>>> >>>>>>>>>>> At present, this is just a review of the specification of >>>>>>>>>>> the default >>>>>>>>>>> method in the interface and *not* a more optimized >>>>>>>>>>> implementation in >>>>>>>>>>> the javac RoundEnvironemnt implementation (and not any tests >>>>>>>>>>> that >>>>>>>>>>> would be needed for the new functionality). >>>>>>>>>>> >>>>>>>>>>> Note that the bug proposes adding two methods >>>>>>>>>>> >>>>>>>>>>> RoundEnvironment.getElementsAnnotatedWith(Set>>>>>>>>>> Annotation>> s) >>>>>>>>>>> RoundEnvironment.getElementsAnnotatedWith(Set >>>>>>>>>>> s) >>>>>>>>>>> >>>>>>>>>>> but these methods would clash since their erasure is the >>>>>>>>>>> same. *sad >>>>>>>>>>> tromphone* >>>>>>>>>>> >>>>>>>>>>> Therefore, I'm only proposing to add the Class-based variant >>>>>>>>>>> since >>>>>>>>>>> that one is the more commonly used of the two. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> -Joe >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> + /** >>>>>>>>>>> + * Returns the elements annotated with any of the given >>>>>>>>>>> annotation >>>>>>>>>>> + * types. >>>>>>>>>>> + * >>>>>>>>>>> + * @apiNote This method may be useful when processing >>>>>>>>>>> repeating >>>>>>>>>>> + * annotations by looking for an annotation type and its >>>>>>>>>>> + * containing annotation type at the same time. >>>>>>>>>>> + * >>>>>>>>>>> + * @implSpec The default implementation of this method >>>>>>>>>>> creates an >>>>>>>>>>> + * empty result set, iterates over the annotations in >>>>>>>>>>> the argument >>>>>>>>>>> + * set calling {@link >>>>>>>>>>> #getElementsAnnotatedWith(TypeElement)} on >>>>>>>>>>> + * each annotation and adding those results to the result >>>>>>>>>>> + * set. Finally, the contents of the result set are >>>>>>>>>>> returned as an >>>>>>>>>>> + * unmodifiable set. >>>>>>>>>>> + * >>>>>>>>>>> + * @param annotations annotation type being requested >>>>>>>>>>> + * @return the elements annotated with the given >>>>>>>>>>> annotation types, >>>>>>>>>>> + * or an empty set if there are none >>>>>>>>>>> + * @throws IllegalArgumentException if the any elements >>>>>>>>>>> of the >>>>>>>>>>> + * argument set do not represent an annotation type >>>>>>>>>>> + * @since 9 >>>>>>>>>>> + */ >>>>>>>>>>> + default Set >>>>>>>>>>> getElementsAnnotatedWith(Set> >>>>>>>>>>> annotations){ >>>>>>>>>>> + HashSet result = new HashSet<>(); >>>>>>>>>>> + for (Class annotation : >>>>>>>>>>> annotations) { >>>>>>>>>>> + result.addAll(getElementsAnnotatedWith(annotation)); >>>>>>>>>>> + } >>>>>>>>>>> + return Collections.unmodifiableSet(result); >>>>>>>>>>> + } >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From maurizio.cimadamore at oracle.com Thu May 26 13:00:19 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 26 May 2016 14:00:19 +0100 Subject: RFR: Javadoc adjustment for https://bugs.openjdk.java.net/browse/JDK-8033812 In-Reply-To: <574672C1.4060005@oracle.com> References: <574420F1.5060207@oracle.com> <574421B0.6070807@oracle.com> <57442593.3020704@oracle.com> <574672C1.4060005@oracle.com> Message-ID: <5746F363.1040508@oracle.com> Looks good Maurizio On 26/05/16 04:51, Srikanth wrote: > > Per Elena's suggestion (Thanks!), here is another revision that simply > elides mention > of count of type contexts - thus this is a slightly better future > proof version. > > Please re-review: > > http://cr.openjdk.java.net/~sadayapalam/webrev.01/ > > TIA > Srikanth > > On Tuesday 24 May 2016 03:27 PM, Maurizio Cimadamore wrote: >> Looks good! >> >> Maurizio >> >> On 24/05/16 10:41, Srikanth wrote: >>> The link to review: >>> >>> http://cr.openjdk.java.net/~sadayapalam/JDK-8033812/webrev.00/ >>> >>> Thanks! >>> Srikanth >>> >>> On Tuesday 24 May 2016 03:07 PM, Srikanth wrote: >>>> Hello, >>>> >>>> Thanks in advance for reviewing this minor change to the javadoc of >>>> ElementType.TYPE_USE made for JDK-8033812 >>>> >>>> Thanks! >>>> Srikanth >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Thu May 26 14:47:03 2016 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Thu, 26 May 2016 10:47:03 -0400 Subject: RFR: 8156962 javac should support options specified in _JAVAC_OPTIONS In-Reply-To: <5746442D.8090108@oracle.com> References: <5746442D.8090108@oracle.com> Message-ID: <57470C67.4000903@oracle.com> Hi, The test seems to have some indentation issues, no need for another iteration though. Looks good, Thanks, Vicente On 05/25/2016 08:32 PM, Jonathan Gibbons wrote: > This review is for javac to provide limited support to accept options > specified in an environment variable when invoked from the command line. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8156962 > Webrev: http://cr.openjdk.java.net/~jjg/8156962/webrev.00/ > > -- Jon From jonathan.gibbons at oracle.com Thu May 26 15:30:16 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 26 May 2016 08:30:16 -0700 Subject: Why the annotation processing API ? In-Reply-To: References: Message-ID: <57471688.7020600@oracle.com> On 05/25/2016 09:32 PM, St?phane NICOLAS wrote: > Hi folks, > > I know a simple mail like this generally has very minimal value. But > still, it's been around 2-3 years now that I work on Android, doing a > lot of work around reflection and annotation processing. > > I don't like the annotation processing API. I still find every concept > hard to remember, and it is always taking time to get immersed into it > for a new project. > > Thus, I don't understand, very humbly and very honestly, why this API > even exists. Why can't we simply use reflection-like APIs ? It would > not be that complex to expose an API that looks like reflection > (read-only of course, no new instance of classes, to method calls or > setting/getting field values, just the discovery part). > > I could see over the past years that the newer versions of the JDK are > aligning more and more the capacities of the annotation processing API > with reflection APIs. Some subtle changes but always in this > direction. All you can do with reflection is now possible with > annotation processing (read-only still, as stated above). > > Does it sound completely stupid to ask that javac annotation processor > API for JDK 10 would actually match reflection API ? Reflection API is > so simple and it describes OO code in a natural way for all java > coders. Methods, classes, fields... much simpler than an element type > with a kind that you can cast into I don't know what ! Annotation > processing API is not clear. It is obviously overworked, complex, > abstract, very scholar and hard to use. > > Is there anything that can be done with respect to this problem ? > I hope I am not saying something completely dumb here, but I have been > thinking about this for a very long time now. > > S. > You are probably conflating two concepts. There is the "Annotation Processing API", javax.annotation.processing, and there is the "Language Model API", javax.lang.model. You can think of the Language Model API as "compile-time reflection". It allows you to reflect over declarations without the constraints of the classes having to be loaded into class loaders, and it can also work on classes that only exist in source form. As such, it can even give access to documentation comments contained in the source code. One notable feature is that you can use the Language Model API to reflect over different versions of classes than those in the current runtime. For example, you can run javac on JDK 9 and use the Language Model API to examine the classes for JDK 8, and vice versa. The Annotation Processing API can be thought of as an API for compiler "plugins". It allows you to extend the capabilities of the compiler to examine the code being compiled, using the Language Model API, and (within some well defined limitations) it allows you to generate additional classes to be included in the compilation. All three APIs, the Annotation Processing API, the Language Model API, and the runtime-reflection API (java.lang.reflect) all have their place in the Java ecosystem. -- Jon From steff.nicolas at gmail.com Thu May 26 16:02:13 2016 From: steff.nicolas at gmail.com (=?UTF-8?Q?St=C3=A9phane_NICOLAS?=) Date: Thu, 26 May 2016 09:02:13 -0700 Subject: Why the annotation processing API ? In-Reply-To: <57471688.7020600@oracle.com> References: <57471688.7020600@oracle.com> Message-ID: Thx Jonathan for pointing this. You are right, I was talking about the language model API, not the annotation processing api itself. So yeah, here I was suggesting that the language model should be replaced, or there should be an abstraction layer that would make it look like the reflection API. Developers would know that the Classes, Methods, Fields etc exposed during annotation processing time by this new API are not the same as reflection objects exposed during runtime. But still it would so much easier to manipulate this reflection like API at the annotation processing stage. That's a simple suggestion, though it would imply a big change. Thx for taking the time to answer to it. Stephane 2016-05-26 8:30 GMT-07:00 Jonathan Gibbons : > On 05/25/2016 09:32 PM, St?phane NICOLAS wrote: > >> Hi folks, >> >> I know a simple mail like this generally has very minimal value. But >> still, it's been around 2-3 years now that I work on Android, doing a lot >> of work around reflection and annotation processing. >> >> I don't like the annotation processing API. I still find every concept >> hard to remember, and it is always taking time to get immersed into it for >> a new project. >> >> Thus, I don't understand, very humbly and very honestly, why this API >> even exists. Why can't we simply use reflection-like APIs ? It would not be >> that complex to expose an API that looks like reflection (read-only of >> course, no new instance of classes, to method calls or setting/getting >> field values, just the discovery part). >> >> I could see over the past years that the newer versions of the JDK are >> aligning more and more the capacities of the annotation processing API with >> reflection APIs. Some subtle changes but always in this direction. All you >> can do with reflection is now possible with annotation processing >> (read-only still, as stated above). >> >> Does it sound completely stupid to ask that javac annotation processor >> API for JDK 10 would actually match reflection API ? Reflection API is so >> simple and it describes OO code in a natural way for all java coders. >> Methods, classes, fields... much simpler than an element type with a kind >> that you can cast into I don't know what ! Annotation processing API is not >> clear. It is obviously overworked, complex, abstract, very scholar and hard >> to use. >> >> Is there anything that can be done with respect to this problem ? >> I hope I am not saying something completely dumb here, but I have been >> thinking about this for a very long time now. >> >> S. >> >> > You are probably conflating two concepts. There is the "Annotation > Processing API", javax.annotation.processing, and there is the "Language > Model API", javax.lang.model. > > You can think of the Language Model API as "compile-time reflection". It > allows you to reflect over declarations without the constraints of the > classes having to be loaded into class loaders, and it can also work on > classes that only exist in source form. As such, it can even give access to > documentation comments contained in the source code. One notable feature > is that you can use the Language Model API to reflect over different > versions of classes than those in the current runtime. For example, you > can run javac on JDK 9 and use the Language Model API to examine the > classes for JDK 8, and vice versa. > > The Annotation Processing API can be thought of as an API for compiler > "plugins". It allows you to extend the capabilities of the compiler to > examine the code being compiled, using the Language Model API, and (within > some well defined limitations) it allows you to generate additional classes > to be included in the compilation. > > All three APIs, the Annotation Processing API, the Language Model API, and > the runtime-reflection API (java.lang.reflect) all have their place in the > Java ecosystem. > > -- Jon > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Thu May 26 16:07:06 2016 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 26 May 2016 09:07:06 -0700 Subject: Why the annotation processing API ? In-Reply-To: References: Message-ID: <7403843e-2298-b850-41c5-27550d7138d9@oracle.com> On 5/25/2016 9:32 PM, St?phane NICOLAS wrote: > Hi folks, > > I know a simple mail like this generally has very minimal value. But > still, it's been around 2-3 years now that I work on Android, doing a > lot of work around reflection and annotation processing. > > I don't like the annotation processing API. I still find every concept > hard to remember, and it is always taking time to get immersed into it > for a new project. > > Thus, I don't understand, very humbly and very honestly, why this API > even exists. Why can't we simply use reflection-like APIs ? It would > not be that complex to expose an API that looks like reflection > (read-only of course, no new instance of classes, to method calls or > setting/getting field values, just the discovery part). > The core reflection API has a number of serious design flaws, for a detailed discussion see Gilad Bracha and David Ungar. Mirrors: Design Principles for Meta-level Facilities of Object-Oriented Programming Languages. In Proc. of the ACM Conf. on Object-Oriented Programming, Systems, Languages and Applications, October 2004. http://www.bracha.org/mirrors.pdf With the benefit of hindsight, these problems were avoided in the language model portion of the annotation processing API, javax.lang.model. Cheers, -Joe From steff.nicolas at gmail.com Thu May 26 16:14:14 2016 From: steff.nicolas at gmail.com (=?UTF-8?Q?St=C3=A9phane_NICOLAS?=) Date: Thu, 26 May 2016 09:14:14 -0700 Subject: Why the annotation processing API ? In-Reply-To: <7403843e-2298-b850-41c5-27550d7138d9@oracle.com> References: <7403843e-2298-b850-41c5-27550d7138d9@oracle.com> Message-ID: Thx Joe, I will read the paper in the next few days. It's been a while I didn't read a research paper on Java ;) 2016-05-26 9:07 GMT-07:00 joe darcy : > > On 5/25/2016 9:32 PM, St?phane NICOLAS wrote: > >> Hi folks, >> >> I know a simple mail like this generally has very minimal value. But >> still, it's been around 2-3 years now that I work on Android, doing a lot >> of work around reflection and annotation processing. >> >> I don't like the annotation processing API. I still find every concept >> hard to remember, and it is always taking time to get immersed into it for >> a new project. >> >> Thus, I don't understand, very humbly and very honestly, why this API >> even exists. Why can't we simply use reflection-like APIs ? It would not be >> that complex to expose an API that looks like reflection (read-only of >> course, no new instance of classes, to method calls or setting/getting >> field values, just the discovery part). >> >> > The core reflection API has a number of serious design flaws, for a > detailed discussion see > > Gilad Bracha and David Ungar. Mirrors: Design Principles for Meta-level > Facilities of Object-Oriented Programming Languages. In Proc. of the ACM > Conf. on Object-Oriented Programming, Systems, Languages and Applications, > October 2004. > http://www.bracha.org/mirrors.pdf > > With the benefit of hindsight, these problems were avoided in the language > model portion of the annotation processing API, javax.lang.model. > > Cheers, > > -Joe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Thu May 26 19:39:52 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 26 May 2016 12:39:52 -0700 Subject: RFR: Javadoc adjustment for https://bugs.openjdk.java.net/browse/JDK-8033812 In-Reply-To: <574672C1.4060005@oracle.com> References: <574420F1.5060207@oracle.com> <574421B0.6070807@oracle.com> <57442593.3020704@oracle.com> <574672C1.4060005@oracle.com> Message-ID: <57475108.7020007@oracle.com> The count of type contexts is an important "self check" in the JLS -- the precision of the count forces me to regularly re-check the accuracy of the count, which in turn helps to ensure that ALL type contexts are handled in far flung sections of the JLS. However, I agree it's fair to elide the count in the API spec. Alex On 5/25/2016 8:51 PM, Srikanth wrote: > > Per Elena's suggestion (Thanks!), here is another revision that simply > elides mention > of count of type contexts - thus this is a slightly better future proof > version. > > Please re-review: > > http://cr.openjdk.java.net/~sadayapalam/webrev.01/ > > TIA > Srikanth > > On Tuesday 24 May 2016 03:27 PM, Maurizio Cimadamore wrote: >> Looks good! >> >> Maurizio >> >> On 24/05/16 10:41, Srikanth wrote: >>> The link to review: >>> >>> http://cr.openjdk.java.net/~sadayapalam/JDK-8033812/webrev.00/ >>> >>> Thanks! >>> Srikanth >>> >>> On Tuesday 24 May 2016 03:07 PM, Srikanth wrote: >>>> Hello, >>>> >>>> Thanks in advance for reviewing this minor change to the javadoc of >>>> ElementType.TYPE_USE made for JDK-8033812 >>>> >>>> Thanks! >>>> Srikanth >>> >> > From jonathan.gibbons at oracle.com Fri May 27 18:28:28 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 27 May 2016 11:28:28 -0700 Subject: RFR: 8049896: Clean up (Basic)JavacTask.getTypeMirror Message-ID: <574891CC.6070506@oracle.com> Please review this small change to detect and handle an invalid argument to this method. JBS: https://bugs.openjdk.java.net/browse/JDK-8049896 Webrev: http://cr.openjdk.java.net/~jjg/8049896/webrev/ -- Jon From vicente.romero at oracle.com Fri May 27 18:55:00 2016 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Fri, 27 May 2016 14:55:00 -0400 Subject: RFR: 8049896: Clean up (Basic)JavacTask.getTypeMirror In-Reply-To: <574891CC.6070506@oracle.com> References: <574891CC.6070506@oracle.com> Message-ID: <57489804.9060504@oracle.com> accepted, Thanks, Vicente On 05/27/2016 02:28 PM, Jonathan Gibbons wrote: > Please review this small change to detect and handle an invalid > argument to this method. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8049896 > Webrev: http://cr.openjdk.java.net/~jjg/8049896/webrev/ > > -- Jon From v.plizga at ftc.ru Fri May 13 04:40:59 2016 From: v.plizga at ftc.ru (Plizga Vladimir) Date: Fri, 13 May 2016 04:40:59 -0000 Subject: JDK-8145489 NPE in javac during Attribute stage. Sequel Message-ID: Hello! I'm the initiator of issue https://bugs.openjdk.java.net/browse/JDK-8145489 "NullPointerException while compiling certain annotations". The issue was closed because the assignee (Fairoz Matte) unfortunately couldn't reproduce it and I had no additional info by that moment. But the bug is still actual for our project and recently I researched it in detail. I've sent the results by email to Fairoz a week ago but I didn't receive any answer. Hope you can help me. 1. I've significantly simplified the code snippet to reproduce the bug. Now it consists of just 3 short Java files located in 'mypackage' package: package mypackage; public @interface PackageAnnotation { Class classyAnnotationMember(); } package mypackage; public class MyClass { public class MyInnerClass { } } @PackageAnnotation(classyAnnotationMember = MyClass.MyInnerClass.class) package mypackage; An attempt to compile this files with javac 1.8.0_92 will end up with NullPointerException during Attribute stage (see the stacktrace in JDK-8145489). 2. The source of the error is condition ?!env.next.tree.hasTag(REFERENCE)? in com/sun/tools/javac/comp/Attr.java:3335 line that was added in JDK 1.8. AFAIU there is no enclosing environment for some class-type members of annotations at the topmost (package) level. That's why "env.next == null" and "env.next.tree" fails with NPE. 3. As a temporal workaround (in order to proceed with my current task) I?ve fixed the problem in 1.8.0_92 compiler?s source code by prepending the new condition with a naive checking for enclosing environment nullness: (env.next != null && !env.next.tree.hasTag(REFERENCE)) and rebuilt the compiler. This fix has not affected the amount of successfully passed tests run with jtreg and has allowed me to proceed. I believe Oracle engineers would find a truly proper way to fix it:) I hope this information would be enough to reproduce and fix the bug. If not, you are welcome to request anything else. Thanks, Vladimir Plizga