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 (<cough> Optional.get </cough>) 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> T getSystemTool(Class<T> 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 (<cough> Optional.get </cough>) 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> T getSystemTool(Class<T> 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: <CADc61QSGF3jFiKkK7YmmW1joOSitG9nz=oAX-FdWVFmT+vC-KA@mail.gmail.com>

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: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160505/ccb961db/attachment.html>

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 <steve.drach at oracle.com> 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 <https://bugs.openjdk.java.net/browse/JDK-8149757>
> webrev: http://cr.openjdk.java.net/~sdrach/8149757/webrev/index.html <http://cr.openjdk.java.net/~sdrach/8149757/webrev/index.html>
> 
> Thank you,
> Steve

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160505/68c5ef97/attachment.html>

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: <BY2PR10MB08564A47A7E0493FA17D7966E5700@BY2PR10MB0856.namprd10.prod.outlook.com>



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 <compiler-dev-bounces at openjdk.java.net> on behalf of Robert Olofsson <robert.olofsson at khelekore.org>
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: <BY2PR10MB08564A47A7E0493FA17D7966E5700@BY2PR10MB0856.namprd10.prod.outlook.com>
References: <20160119200819.129514a0@nuccy.khelekore.org>
	<BY2PR10MB08564A47A7E0493FA17D7966E5700@BY2PR10MB0856.namprd10.prod.outlook.com>
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 <compiler-dev-bounces at openjdk.java.net> on behalf of Robert Olofsson <robert.olofsson at khelekore.org>
> 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: <BY2PR10MB08566D3D93E21755794B0CA9E5710@BY2PR10MB0856.namprd10.prod.outlook.com>
References: <20160119200819.129514a0@nuccy.khelekore.org>	<BY2PR10MB08564A47A7E0493FA17D7966E5700@BY2PR10MB0856.namprd10.prod.outlook.com>,
	<57310D45.3050308@oracle.com>
	<BY2PR10MB08566D3D93E21755794B0CA9E5710@BY2PR10MB0856.namprd10.prod.outlook.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>
	<BY2PR10MB08564A47A7E0493FA17D7966E5700@BY2PR10MB0856.namprd10.prod.outlook.com>,
	<57310D45.3050308@oracle.com>
Message-ID: <BY2PR10MB08566D3D93E21755794B0CA9E5710@BY2PR10MB0856.namprd10.prod.outlook.com>

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 <compiler-dev-bounces at openjdk.java.net> on behalf of Jonathan Gibbons <jonathan.gibbons at oracle.com>
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 <compiler-dev-bounces at openjdk.java.net> on behalf of Robert Olofsson <robert.olofsson at khelekore.org>
> 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<? 
extends Path>. The most obvious change is simply to use List<Path> 
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<? extends Path> sources = findSources();
+            List<Path> sources = findSources();
              if (sources.iterator().hasNext()) {
                  StandardJavaFileManager fm = 
compiler.getStandardFileManager(null, null, null);
                  try {
@@ -1145,9 +1145,9 @@
          }
      }

-    private Iterable<? extends Path> availableSources;
+    private List<Path> availableSources;

-    private Iterable<? extends Path> findSources() {
+    private List<Path> 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<Path>
> 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<? extends Path> sources = findSources();
> +            List<Path> sources = findSources();
>               if (sources.iterator().hasNext()) {
>                   StandardJavaFileManager fm =
> compiler.getStandardFileManager(null, null, null);
>                   try {
> @@ -1145,9 +1145,9 @@
>           }
>       }
>
> -    private Iterable<? extends Path> availableSources;
> +    private List<Path> availableSources;
>
> -    private Iterable<? extends Path> findSources() {
> +    private List<Path> 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<Path> 
> 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<? extends Path> sources = findSources();
> +            List<Path> sources = findSources();
>              if (sources.iterator().hasNext()) {
>                  StandardJavaFileManager fm = 
> compiler.getStandardFileManager(null, null, null);
>                  try {
> @@ -1145,9 +1145,9 @@
>          }
>      }
>
> -    private Iterable<? extends Path> availableSources;
> +    private List<Path> availableSources;
>
> -    private Iterable<? extends Path> findSources() {
> +    private List<Path> 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: <bff10acf-1bc3-4439-a664-6b0fc439ff0d@default>

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: <bff10acf-1bc3-4439-a664-6b0fc439ff0d@default>
References: <bff10acf-1bc3-4439-a664-6b0fc439ff0d@default>
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" <iris.clark at oracle.com>
> ?: "Java Core Libs" <core-libs-dev at openjdk.java.net>, 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: <bff10acf-1bc3-4439-a664-6b0fc439ff0d@default>
	<1554585217.477366.1463182296059.JavaMail.zimbra@u-pem.fr>
Message-ID: <abc61aac-e80a-467d-a4ae-6acf3b9a4383@default>

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" <iris.clark at oracle.com>
> ?: "Java Core Libs" <core-libs-dev at openjdk.java.net>, 
> 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: <abc61aac-e80a-467d-a4ae-6acf3b9a4383@default>
References: <bff10acf-1bc3-4439-a664-6b0fc439ff0d@default>
	<1554585217.477366.1463182296059.JavaMail.zimbra@u-pem.fr>
	<abc61aac-e80a-467d-a4ae-6acf3b9a4383@default>
Message-ID: <103793588.142588.1463423883417.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Iris Clark" <iris.clark at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Java Core Libs" <core-libs-dev at openjdk.java.net>, 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" <iris.clark at oracle.com>
> > ?: "Java Core Libs" <core-libs-dev at openjdk.java.net>,
> > 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: <CA+kOe0-=OB+rB=aoagS+vOC0iha+s=6Cu_HWL-JhVmNezPJvRA@mail.gmail.com>

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
<jonathan.gibbons at oracle.com> 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: <bff10acf-1bc3-4439-a664-6b0fc439ff0d@default>
References: <bff10acf-1bc3-4439-a664-6b0fc439ff0d@default>
Message-ID: <29AA7813-44E0-4BB1-937E-1BCAB46F9367@oracle.com>


> On May 13, 2016, at 4:20 PM, Iris Clark <iris.clark at oracle.com> 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: <bff10acf-1bc3-4439-a664-6b0fc439ff0d@default>
References: <bff10acf-1bc3-4439-a664-6b0fc439ff0d@default>
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<Class<? extends 
Annotation>> s)
RoundEnvironment.getElementsAnnotatedWith(Set<AnnotationMirror> 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<? extends Element> getElementsAnnotatedWith(Set<Class<? 
extends Annotation>> annotations){
+        HashSet<Element> result = new HashSet<>();
+        for (Class<? extends Annotation> 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/<something-new>  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<Class<? extends 
> Annotation>> s)
> RoundEnvironment.getElementsAnnotatedWith(Set<AnnotationMirror> 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<? extends Element> 
> getElementsAnnotatedWith(Set<Class<? extends Annotation>> annotations){
> +        HashSet<Element> result = new HashSet<>();
> +        for (Class<? extends Annotation> 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/<something-new>  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<Class<? extends 
>> Annotation>> s)
>> RoundEnvironment.getElementsAnnotatedWith(Set<AnnotationMirror> 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<? extends Element> 
>> getElementsAnnotatedWith(Set<Class<? extends Annotation>> annotations){
>> +        HashSet<Element> result = new HashSet<>();
>> +        for (Class<? extends Annotation> 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/<something-new>  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<Class<? extends 
>>> Annotation>> s)
>>> RoundEnvironment.getElementsAnnotatedWith(Set<AnnotationMirror> 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<? extends Element> 
>>> getElementsAnnotatedWith(Set<Class<? extends Annotation>> annotations){
>>> +        HashSet<Element> result = new HashSet<>();
>>> +        for (Class<? extends Annotation> 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<? extends Annotation>) 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<? extends Annotation> 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<Class<? extends
> Annotation>> s)
> RoundEnvironment.getElementsAnnotatedWith(Set<AnnotationMirror> 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<? extends Element> getElementsAnnotatedWith(Set<Class<?
> extends Annotation>> annotations){
> +        HashSet<Element> result = new HashSet<>();
> +        for (Class<? extends Annotation> 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/<something-new>  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<Class<? extends
>>> Annotation>> s)
>>> RoundEnvironment.getElementsAnnotatedWith(Set<AnnotationMirror> 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<? extends Element>
>>> getElementsAnnotatedWith(Set<Class<? extends Annotation>> annotations){
>>> +        HashSet<Element> result = new HashSet<>();
>>> +        for (Class<? extends Annotation> 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/<something-new>  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<Class<? extends
>>>> Annotation>> s)
>>>> RoundEnvironment.getElementsAnnotatedWith(Set<AnnotationMirror> 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<? extends Element>
>>>> getElementsAnnotatedWith(Set<Class<? extends Annotation>> 
>>>> annotations){
>>>> +        HashSet<Element> result = new HashSet<>();
>>>> +        for (Class<? extends Annotation> 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: <b640ee83-1e6d-39b9-4c82-89ab7ec38b87@oracle.com>

Combining suggestions, two methods

     default Set<? extends Element> 
getElementsAnnotatedWithAny(TypeElement... annotations)

     default Set<? extends Element> 
getElementsAnnotatedWithAny(Set<Class<? extends Annotation>> 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<? extends Element> 
getElementsAnnotatedWithAny(TypeElement... annotations){
+        HashSet<Element> 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<? extends Element> 
getElementsAnnotatedWithAny(Set<Class<? extends Annotation>> annotations){
+        HashSet<Element> result = new HashSet<>();
+        for (Class<? extends Annotation> 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/<something-new>  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<Class<? extends
>>>>> Annotation>> s)
>>>>> RoundEnvironment.getElementsAnnotatedWith(Set<AnnotationMirror> 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<? extends Element>
>>>>> getElementsAnnotatedWith(Set<Class<? extends Annotation>> 
>>>>> annotations){
>>>>> +        HashSet<Element> result = new HashSet<>();
>>>>> +        for (Class<? extends Annotation> 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: <bff10acf-1bc3-4439-a664-6b0fc439ff0d@default>
	<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: <bff10acf-1bc3-4439-a664-6b0fc439ff0d@default>
	<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: <bff10acf-1bc3-4439-a664-6b0fc439ff0d@default>
	<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: <BBFC958D-E8FA-4B77-B923-C6E378A1B320@oracle.com>

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: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160520/98a0c30c/signature.asc>

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 <jonathan.gibbons at oracle.com> 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 <jonathan.gibbons at oracle.com> 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 
>>> <jonathan.gibbons at oracle.com> 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 <jonathan.gibbons at oracle.com> 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 <jonathan.gibbons at oracle.com> 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: <BBFC958D-E8FA-4B77-B923-C6E378A1B320@oracle.com>
References: <BBFC958D-E8FA-4B77-B923-C6E378A1B320@oracle.com>
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: <b640ee83-1e6d-39b9-4c82-89ab7ec38b87@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>
	<b640ee83-1e6d-39b9-4c82-89ab7ec38b87@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<? extends Element> 
> getElementsAnnotatedWithAny(TypeElement... annotations)
>
>     default Set<? extends Element> 
> getElementsAnnotatedWithAny(Set<Class<? extends Annotation>> 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<? extends Element> 
> getElementsAnnotatedWithAny(TypeElement... annotations){
> +        HashSet<Element> 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<? extends Element> 
> getElementsAnnotatedWithAny(Set<Class<? extends Annotation>> 
> annotations){
> +        HashSet<Element> result = new HashSet<>();
> +        for (Class<? extends Annotation> 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/<something-new>  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<Class<? extends
>>>>>> Annotation>> s)
>>>>>> RoundEnvironment.getElementsAnnotatedWith(Set<AnnotationMirror> 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<? extends Element>
>>>>>> getElementsAnnotatedWith(Set<Class<? extends Annotation>> 
>>>>>> annotations){
>>>>>> +        HashSet<Element> result = new HashSet<>();
>>>>>> +        for (Class<? extends Annotation> 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: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160524/aaffa09b/attachment.html>

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: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160524/226aa4d0/attachment-0001.html>

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: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160524/5a3ea366/attachment.html>

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: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160524/771520ac/attachment.html>

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: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160524/35d6b917/attachment.html>

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>
	<b640ee83-1e6d-39b9-4c82-89ab7ec38b87@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<? extends Element> 
>> getElementsAnnotatedWithAny(TypeElement... annotations)
>>
>>     default Set<? extends Element> 
>> getElementsAnnotatedWithAny(Set<Class<? extends Annotation>> 
>> 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<? extends Element> 
>> getElementsAnnotatedWithAny(TypeElement... annotations){
>> +        HashSet<Element> 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<? extends Element> 
>> getElementsAnnotatedWithAny(Set<Class<? extends Annotation>> 
>> annotations){
>> +        HashSet<Element> result = new HashSet<>();
>> +        for (Class<? extends Annotation> 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/<something-new>  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<Class<? extends
>>>>>>> Annotation>> s)
>>>>>>> RoundEnvironment.getElementsAnnotatedWith(Set<AnnotationMirror> 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<? extends Element>
>>>>>>> getElementsAnnotatedWith(Set<Class<? extends Annotation>> 
>>>>>>> annotations){
>>>>>>> +        HashSet<Element> result = new HashSet<>();
>>>>>>> +        for (Class<? extends Annotation> 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: <c6b9bf21-cf41-8828-2303-6288e4f07a40@oracle.com>

+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: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160524/1defa3fd/attachment-0001.html>

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: <CAM6ZMz8E+-6EA=mQa3wNnFyq4u5sQgab6x78AOPst6TYW0Cqgg@mail.gmail.com>

Hi all,

consider following code:

public class Main {

    public static class Details {
        // NOP
    }

    public static class Mapper<T> {

        public T getMapped(String str) {
            return null;
        }

        public List<Details> getDetails(T entity) {
            return Collections.emptyList();
        }

    }

    public static List<Details> calcDetails() {
        Optional<Mapper> opt = Optional.empty();
        return opt.map(m -> getDetails("A", m))
                  .orElseGet(() -> Collections.emptyList());
    }

    private static <E> List<Details> getDetails(String str,
           Mapper<E> 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<Details>
                  .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<Details> calcDetails() {
        Optional<Mapper> opt = Optional.empty();
        return (List<Details>) 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: <CAM6ZMz8E+-6EA=mQa3wNnFyq4u5sQgab6x78AOPst6TYW0Cqgg@mail.gmail.com>
References: <CAM6ZMz8E+-6EA=mQa3wNnFyq4u5sQgab6x78AOPst6TYW0Cqgg@mail.gmail.com>
Message-ID: <849908774.1375756.1464173752196.JavaMail.zimbra@u-pem.fr>



----- Mail original -----
> De: "Andrej Golovnin" <andrej.golovnin at gmail.com>
> ?: "Compiler Dev" <compiler-dev at openjdk.java.net>
> 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<T> {
> 
>         public T getMapped(String str) {
>             return null;
>         }
> 
>         public List<Details> getDetails(T entity) {
>             return Collections.emptyList();
>         }
> 
>     }
> 
>     public static List<Details> calcDetails() {
>         Optional<Mapper> opt = Optional.empty();
>         return opt.map(m -> getDetails("A", m))
>                   .orElseGet(() -> Collections.emptyList());
>     }
> 
>     private static <E> List<Details> getDetails(String str,
>            Mapper<E> 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<Details>
>                   .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<Details> calcDetails() {
>         Optional<Mapper> opt = Optional.empty();
>         return (List<Details>) opt.map(m -> getDetails("A", m))
>                   .orElseGet(() -> Collections.emptyList());
>     }
> 

Optional<Mapper> is a rare type i.e. a mix between a parameterized type and a raw type, declaring opt as a, Optional<Mapper<?>> 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: <CAM6ZMz8E+-6EA=mQa3wNnFyq4u5sQgab6x78AOPst6TYW0Cqgg@mail.gmail.com>
	<849908774.1375756.1464173752196.JavaMail.zimbra@u-pem.fr>
Message-ID: <574588A3.6090605@oracle.com>



On 25/05/16 11:55, Remi Forax wrote:
> Optional<Mapper> is a rare type i.e. a mix between a parameterized type and a raw type, declaring opt as a, Optional<Mapper<?>> 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<X> {
    class Inner<Y> { }
}

This is a rare type:

Outer.Inner<String>

Rare types are disallowed since JDK 5.

I don't think Optional<Mapper> 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>
	<b640ee83-1e6d-39b9-4c82-89ab7ec38b87@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<? extends Element> 
>>> getElementsAnnotatedWithAny(TypeElement... annotations)
>>>
>>>     default Set<? extends Element> 
>>> getElementsAnnotatedWithAny(Set<Class<? extends Annotation>> 
>>> 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<? extends Element> 
>>> getElementsAnnotatedWithAny(TypeElement... annotations){
>>> +        HashSet<Element> 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<? extends Element> 
>>> getElementsAnnotatedWithAny(Set<Class<? extends Annotation>> 
>>> annotations){
>>> +        HashSet<Element> result = new HashSet<>();
>>> +        for (Class<? extends Annotation> 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/<something-new>  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<Class<? extends
>>>>>>>> Annotation>> s)
>>>>>>>> RoundEnvironment.getElementsAnnotatedWith(Set<AnnotationMirror> 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<? extends Element>
>>>>>>>> getElementsAnnotatedWith(Set<Class<? extends Annotation>> 
>>>>>>>> annotations){
>>>>>>>> +        HashSet<Element> result = new HashSet<>();
>>>>>>>> +        for (Class<? extends Annotation> 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>
	<b640ee83-1e6d-39b9-4c82-89ab7ec38b87@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<? extends Element> 
>>>> getElementsAnnotatedWithAny(TypeElement... annotations)
>>>>
>>>>     default Set<? extends Element> 
>>>> getElementsAnnotatedWithAny(Set<Class<? extends Annotation>> 
>>>> 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<? extends Element> 
>>>> getElementsAnnotatedWithAny(TypeElement... annotations){
>>>> +        HashSet<Element> 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<? extends Element> 
>>>> getElementsAnnotatedWithAny(Set<Class<? extends Annotation>> 
>>>> annotations){
>>>> +        HashSet<Element> result = new HashSet<>();
>>>> +        for (Class<? extends Annotation> 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/<something-new>  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<Class<? extends
>>>>>>>>> Annotation>> s)
>>>>>>>>> RoundEnvironment.getElementsAnnotatedWith(Set<AnnotationMirror> 
>>>>>>>>> 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<? extends Element>
>>>>>>>>> getElementsAnnotatedWith(Set<Class<? extends Annotation>> 
>>>>>>>>> annotations){
>>>>>>>>> +        HashSet<Element> result = new HashSet<>();
>>>>>>>>> +        for (Class<? extends Annotation> 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>
	<b640ee83-1e6d-39b9-4c82-89ab7ec38b87@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<? extends Element> 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<? extends Element> 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<? extends Element> 
>>>>> getElementsAnnotatedWithAny(TypeElement... annotations)
>>>>>
>>>>>     default Set<? extends Element> 
>>>>> getElementsAnnotatedWithAny(Set<Class<? extends Annotation>> 
>>>>> 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<? extends Element> 
>>>>> getElementsAnnotatedWithAny(TypeElement... annotations){
>>>>> +        HashSet<Element> 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<? extends Element> 
>>>>> getElementsAnnotatedWithAny(Set<Class<? extends Annotation>> 
>>>>> annotations){
>>>>> +        HashSet<Element> result = new HashSet<>();
>>>>> +        for (Class<? extends Annotation> 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/<something-new>  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<Class<? extends
>>>>>>>>>> Annotation>> s)
>>>>>>>>>> RoundEnvironment.getElementsAnnotatedWith(Set<AnnotationMirror> 
>>>>>>>>>> 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<? extends Element>
>>>>>>>>>> getElementsAnnotatedWith(Set<Class<? extends Annotation>> 
>>>>>>>>>> annotations){
>>>>>>>>>> +        HashSet<Element> result = new HashSet<>();
>>>>>>>>>> +        for (Class<? extends Annotation> 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: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160526/a3a9df89/attachment-0001.html>

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: <CALo37o6jy4xs6Ts7-opCJQuSFP_xKUGsvOPKZGmQiFH5r+ishQ@mail.gmail.com>

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: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160525/6255a9ba/attachment.html>

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>
	<b640ee83-1e6d-39b9-4c82-89ab7ec38b87@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<? extends Element> 
> 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<? extends Element> 
> 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<? extends Element> 
>>>>>> getElementsAnnotatedWithAny(TypeElement... annotations)
>>>>>>
>>>>>>     default Set<? extends Element> 
>>>>>> getElementsAnnotatedWithAny(Set<Class<? extends Annotation>> 
>>>>>> 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<? extends Element> 
>>>>>> getElementsAnnotatedWithAny(TypeElement... annotations){
>>>>>> +        HashSet<Element> 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<? extends Element> 
>>>>>> getElementsAnnotatedWithAny(Set<Class<? extends Annotation>> 
>>>>>> annotations){
>>>>>> +        HashSet<Element> result = new HashSet<>();
>>>>>> +        for (Class<? extends Annotation> 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/<something-new>  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<Class<? extends
>>>>>>>>>>> Annotation>> s)
>>>>>>>>>>> RoundEnvironment.getElementsAnnotatedWith(Set<AnnotationMirror> 
>>>>>>>>>>> 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<? extends Element>
>>>>>>>>>>> getElementsAnnotatedWith(Set<Class<? extends Annotation>> 
>>>>>>>>>>> annotations){
>>>>>>>>>>> +        HashSet<Element> result = new HashSet<>();
>>>>>>>>>>> +        for (Class<? extends Annotation> 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: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160526/9bdcb4e3/attachment.html>

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: <CALo37o6jy4xs6Ts7-opCJQuSFP_xKUGsvOPKZGmQiFH5r+ishQ@mail.gmail.com>
References: <CALo37o6jy4xs6Ts7-opCJQuSFP_xKUGsvOPKZGmQiFH5r+ishQ@mail.gmail.com>
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: <CALo37o6jy4xs6Ts7-opCJQuSFP_xKUGsvOPKZGmQiFH5r+ishQ@mail.gmail.com>
	<57471688.7020600@oracle.com>
Message-ID: <CALo37o7ZXMcvWfot094LzS0gLKk-oFLHrTeAm-LdOZY5D=YTXg@mail.gmail.com>

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 <jonathan.gibbons at 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160526/ca662372/attachment.html>

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: <CALo37o6jy4xs6Ts7-opCJQuSFP_xKUGsvOPKZGmQiFH5r+ishQ@mail.gmail.com>
References: <CALo37o6jy4xs6Ts7-opCJQuSFP_xKUGsvOPKZGmQiFH5r+ishQ@mail.gmail.com>
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: <CALo37o6jy4xs6Ts7-opCJQuSFP_xKUGsvOPKZGmQiFH5r+ishQ@mail.gmail.com>
	<7403843e-2298-b850-41c5-27550d7138d9@oracle.com>
Message-ID: <CALo37o4rFbe7ohF2pOxgbz-tFErqriM9uAqEjYpqzm2CmzNtGQ@mail.gmail.com>

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 <joe.darcy at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160526/b0ff8ea2/attachment.html>

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: <da16120eb5304738b90efb3f3fcb7e9f@nut-mbx-1.win.ftc.ru>

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:

<File PackageAnnotation.java>
package mypackage;
public @interface PackageAnnotation {
  Class<?> classyAnnotationMember();
}
</File PackageAnnotation.java>

<File MyClass.java>
package mypackage;
public class MyClass {
  public class MyInnerClass { }
}
</File MyClass.java>

<File package-info.java>
@PackageAnnotation(classyAnnotationMember = MyClass.MyInnerClass.class)
package mypackage;
</File package-info.java>

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