From vicente.romero at oracle.com  Fri Dec  1 14:34:56 2017
From: vicente.romero at oracle.com (Vicente Romero)
Date: Fri, 1 Dec 2017 09:34:56 -0500
Subject: RFR JDK-8191969: javac produces incorrect
 RuntimeInvisibleTypeAnnotations length attribute
In-Reply-To: <5A202E89.9090808@oracle.com>
References: <5A1D4C66.5010605@oracle.com> <5A202E89.9090808@oracle.com>
Message-ID: <82bfb1b2-c917-bf88-7e71-9334035b4631@oracle.com>

looks good,

Vicente

On 11/30/2017 11:15 AM, Jan Lahoda wrote:
> To me, looks OK, but unfortunately I not a jdk8u Reviewer.
>
> Jan
>
> On 28.11.2017 12:45, Srikanth wrote:
>>
>> Hello,
>>
>> JDK-8191969 is a JDK8u backport task created for JDK-8144185 which was
>> pushed for JDK10
>> here: http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/0b32afcabef4
>>
>> We have a request from asm tool maintainers and also from other sources
>> through the sustenance channel for a backport.
>>
>> Synopsis:
>>
>> Basically problem arises when metadata that models the type annotations
>> on a captured outer local are shared with the lambda implementation
>> method's formal parameter that corresponds to the
>> captured outer local.
>>
>> Any changes to one will invalidate the other. This is in fact what
>> causes grief for asm.
>>
>> However, as per the spec clarification spelled out here:
>> http://mail.openjdk.java.net/pipermail/compiler-dev/2015-December/009866.html 
>>
>> we should not be transmitting the annotations from the captured outer
>> locals to any formal parameter that represents/reifies the captured
>> outer local in a synthetic lambda implementation method.
>>
>> Thus aligning to the spec, makes the problem vanish automatically.
>>
>> 8u webrev:
>>
>> http://cr.openjdk.java.net/~sadayapalam/JDK-8191969/webrev.00/
>>
>> (This is essentially the same fix pushed for jdk10, with the patch
>> manually applied to jdk8u-dev)
>>
>> All relevant tests are green. Please review.
>> Thanks in advance.
>> Srikanth
>>
>>


From kumar.x.srinivasan at oracle.com  Fri Dec  1 14:41:44 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Fri, 01 Dec 2017 06:41:44 -0800
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <badb6f618f5b489ca634adb6b545b152@sap.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
 <5A1C4081.2090107@oracle.com> <badb6f618f5b489ca634adb6b545b152@sap.com>
Message-ID: <5A216A28.3030702@oracle.com>

Hi,

Besides my private comments to you, there are 2-3 internal tests
which fail.

Have you run all the langtools tests ? There are 4 Windows tests
that fail with langtools:

jdk/javadoc/doclet/testHelpOption/TestHelpOption.java
jdk/javadoc/tool/CheckResourceKeys.java
jdk/javadoc/tool/ToolProviderTest.java
tools/javap/InvalidOptions.java
tools/jdeps/MultiReleaseJar.java

This changeset needs to be vetted thoroughly using internal build and 
test systems.
Any Oracle engineer willing to sponsor this ?

Kumar

On 11/28/2017 3:16 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> I uploaded a new webrev:
> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.04/
>
> This includes the changes
>    - to jshell requested by Robert
>    - to the test as requested by Kumar.
>
> See also incremental patch and the test output including all the
> help messages referenced in the webrev.
>
> Best regards,
>    Goetz.
>
>> -----Original Message-----
>> From: Kumar Srinivasan [mailto:kumar.x.srinivasan at oracle.com]
>> Sent: Montag, 27. November 2017 17:43
>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>> Cc: core-libs-dev at openjdk.java.net; 'compiler-dev at openjdk.java.net'
>> <compiler-dev at openjdk.java.net>; serviceability-dev (serviceability-
>> dev at openjdk.java.net) <serviceability-dev at openjdk.java.net>
>> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
>>
>> Hi,
>>
>> I looked at some of the components I maintain, and they look good.
>>
>> Wrt. the test:
>>
>> 1. The local variables/fields don't comply with the coding conventions,
>> we have been
>>        following in the JDK.
>>
>> 2.  Hmm, someone parked a .ini file in bin directory, later removed,
>>        perhaps on windows simply check for .exe ? Should a check exist
>>        to verify if file has executable permissions ?"File.canExecute".
>>
>>    171     // Returns true if the file is not a tool.
>>    172     static boolean notATool(String file) {
>>    173         file = file.toLowerCase();
>>    174         if (file.endsWith(".dll") ||
>>    175             file.endsWith(".map") ||
>>    176             file.endsWith(".pdb") ||
>>    177             file.equals("server")) {  // server subdir on windows.
>>    178             return true;
>>    179         }
>>    180         return false;
>>    181     }
>>
>>
>> 3.  Typo in comment
>>
>> 201     // Check whether 'flag' appears in 'line' as a word of itself. I must not
>>
>> s/I must/It must/
>>
>>
>> 4. There is a method to check for isEnglishLocale in TestHelper, perhaps
>> use it
>> to have the test bale out in non english locales as early as possible ?
>>
>> 5.  Has this been tested on all platforms ? do you need help testing it ?
>>
>> Kumar
>>
>>
>> On 11/17/2017 3:23 AM, Lindenmaier, Goetz wrote:
>>> Hi,
>>>
>>> please review this change. I also filed a CSR for this:
>>> http://cr.openjdk.java.net/~goetz/wr17/8189102-
>> helpMessage/webrev.02/
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
>>>
>>> See the webrev for a detailed description of the changes.
>>>
>>> If required, I'll make break-out changes to be reviewed separately.
>>>
>>> I had posted a RFR before, but improved the change to
>>> give a more complete overview of currently supported flags
>>> for the CSR:
>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
>> October/028615.html
>>> Best regards,
>>>     Goetz.
>>>

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

From goetz.lindenmaier at sap.com  Fri Dec  1 15:16:47 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 1 Dec 2017 15:16:47 +0000
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <5A216A28.3030702@oracle.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
 <5A1C4081.2090107@oracle.com> <badb6f618f5b489ca634adb6b545b152@sap.com>
 <5A216A28.3030702@oracle.com>
Message-ID: <2ac9c1e37d8e493aa5b581d1a69862e8@sap.com>

Hi Kumar, 

I'm already looking at the issues from your other mail.
Detailed comments will follow.

I'll also check and fix the new tests you report. 
I think we don't run the langtool tests, i.e. I know
we didn't run them before the repos were
merged.  Obviously we should add them to our testing :)

Thanks for further testing and best regards,
  Goetz.


> -----Original Message-----
> From: Kumar Srinivasan [mailto:kumar.x.srinivasan at oracle.com]
> Sent: Freitag, 1. Dezember 2017 15:42
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: core-libs-dev at openjdk.java.net; 'compiler-dev at openjdk.java.net'
> <compiler-dev at openjdk.java.net>; serviceability-dev (serviceability-
> dev at openjdk.java.net) <serviceability-dev at openjdk.java.net>
> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
> 
> Hi,
> 
> Besides my private comments to you, there are 2-3 internal tests
> which fail.
> 
> Have you run all the langtools tests ? There are 4 Windows tests
> that fail with langtools:
> 
> jdk/javadoc/doclet/testHelpOption/TestHelpOption.java
> jdk/javadoc/tool/CheckResourceKeys.java
> jdk/javadoc/tool/ToolProviderTest.java
> tools/javap/InvalidOptions.java
> tools/jdeps/MultiReleaseJar.java
> 
> This changeset needs to be vetted thoroughly using internal build and test
> systems.
> Any Oracle engineer willing to sponsor this ?
> 
> Kumar
> 
> 
> On 11/28/2017 3:16 AM, Lindenmaier, Goetz wrote:
> 
> 
> 	Hi,
> 
> 	I uploaded a new webrev:
> 	http://cr.openjdk.java.net/~goetz/wr17/8189102-
> helpMessage/webrev.04/
> 
> 	This includes the changes
> 	  - to jshell requested by Robert
> 	  - to the test as requested by Kumar.
> 
> 	See also incremental patch and the test output including all the
> 	help messages referenced in the webrev.
> 
> 	Best regards,
> 	  Goetz.
> 
> 
> 		-----Original Message-----
> 		From: Kumar Srinivasan
> [mailto:kumar.x.srinivasan at oracle.com]
> 		Sent: Montag, 27. November 2017 17:43
> 		To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> <mailto:goetz.lindenmaier at sap.com>
> 		Cc: core-libs-dev at openjdk.java.net <mailto:core-libs-
> dev at openjdk.java.net> ; 'compiler-dev at openjdk.java.net
> <mailto:compiler-dev at openjdk.java.net> '
> 		<compiler-dev at openjdk.java.net> <mailto:compiler-
> dev at openjdk.java.net> ; serviceability-dev (serviceability-
> 		dev at openjdk.java.net <mailto:dev at openjdk.java.net> )
> <serviceability-dev at openjdk.java.net> <mailto:serviceability-
> dev at openjdk.java.net>
> 		Subject: Re: RFR: 8189102: All tools should support -?, -h and -
> -help
> 
> 		Hi,
> 
> 		I looked at some of the components I maintain, and they look
> good.
> 
> 		Wrt. the test:
> 
> 		1. The local variables/fields don't comply with the coding
> conventions,
> 		we have been
> 		      following in the JDK.
> 
> 		2.  Hmm, someone parked a .ini file in bin directory, later
> removed,
> 		      perhaps on windows simply check for .exe ? Should a
> check exist
> 		      to verify if file has executable permissions
> ?"File.canExecute".
> 
> 		  171     // Returns true if the file is not a tool.
> 		  172     static boolean notATool(String file) {
> 		  173         file = file.toLowerCase();
> 		  174         if (file.endsWith(".dll") ||
> 		  175             file.endsWith(".map") ||
> 		  176             file.endsWith(".pdb") ||
> 		  177             file.equals("server")) {  // server subdir on
> windows.
> 		  178             return true;
> 		  179         }
> 		  180         return false;
> 		  181     }
> 
> 
> 		3.  Typo in comment
> 
> 		201     // Check whether 'flag' appears in 'line' as a word of
> itself. I must not
> 
> 		s/I must/It must/
> 
> 
> 		4. There is a method to check for isEnglishLocale in
> TestHelper, perhaps
> 		use it
> 		to have the test bale out in non english locales as early as
> possible ?
> 
> 		5.  Has this been tested on all platforms ? do you need help
> testing it ?
> 
> 		Kumar
> 
> 
> 		On 11/17/2017 3:23 AM, Lindenmaier, Goetz wrote:
> 
> 			Hi,
> 
> 			please review this change. I also filed a CSR for this:
> 			http://cr.openjdk.java.net/~goetz/wr17/8189102-
> 
> 		helpMessage/webrev.02/
> 
> 			Bug: https://bugs.openjdk.java.net/browse/JDK-
> 8189102
> 			CSR: https://bugs.openjdk.java.net/browse/JDK-
> 8191477
> 
> 			See the webrev for a detailed description of the
> changes.
> 
> 			If required, I'll make break-out changes to be
> reviewed separately.
> 
> 			I had posted a RFR before, but improved the change
> to
> 			give a more complete overview of currently
> supported flags
> 			for the CSR:
> 			http://mail.openjdk.java.net/pipermail/hotspot-
> dev/2017-
> 
> 		October/028615.html
> 
> 
> 			Best regards,
> 			   Goetz.
> 
> 
> 
> 


From jonathan.gibbons at oracle.com  Sat Dec  2 00:29:38 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 01 Dec 2017 16:29:38 -0800
Subject: RFR 8189749: Devise strategy for making source level checks more
 uniform
In-Reply-To: <0d223e68-de26-1e59-adad-1f57c9d28762@oracle.com>
References: <af46e66f-a0b7-2a65-7ca7-cecd3bbd7a43@oracle.com>
 <0d223e68-de26-1e59-adad-1f57c9d28762@oracle.com>
Message-ID: <5A21F3F2.2060609@oracle.com>

+1. Very nice.

Nit: I would suggest changing multi-catch statements to the plural form.

tests/MulticatchNotSupported.java:39: error: multi-catch statement is 
not supported in -source 6

-- Jon

On 11/28/2017 06:19 AM, Maurizio Cimadamore wrote:
> Updated webrev here:
>
> http://cr.openjdk.java.net/~mcimadamore/8189749-v2/
>
> I've included a report of the diagnostics that have been tweaked by 
> this webrev here to make sure that singular vs. plural is used 
> effectively:
>
> http://cr.openjdk.java.net/~mcimadamore/8189749-v2/diags.html
>
> Cheers
> Maurizio
>
>
> On 20/10/17 19:07, Maurizio Cimadamore wrote:
>> Hi,
>> this biggie patch allows the treatment of source level checks to be 
>> more uniform. The general problem is explained in details here:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8189749
>>
>> Webrev is here:
>>
>> http://cr.openjdk.java.net/~mcimadamore/8189749/
>>
>> The way I approached this, was to create a first class entity, an 
>> enum called Feature. Each 'feature' has:
>>
>> * a min source level (e.g. what is the min source level required to 
>> compile that feature, meaning that lower levels will result in errors)
>> * a max source level (e.g. what is the max source level required to 
>> compile that feature, meaning that higher levels will result in errors)
>> * an optional resource key
>>
>> The first two properties are obviously used to decided if feature XYZ 
>> can be used given source level N. The last property is used to 
>> automate generation of source check diagnostics. Note that this patch 
>> introduce a _single_ source check diagnostic:
>>
>> # 0: message segment (feature), 1: string (found version), 2: string 
>> (expected version)
>> compiler.misc.feature.not.supported.in.source=\
>>    {0} not supported in -source {1}\n\
>>     (use -source {2} or higher to enable {0})
>>
>> And then there's a bunch of feature fragments, example:
>>
>> compiler.misc.feature.modules=\
>>     modules
>>
>> compiler.misc.feature.diamond.and.anon.class=\
>>     ''<>'' with anonymous inner classes
>>
>> compiler.misc.feature.binary.lit=\
>>     binary literals
>>
>> (and many more :-))
>>
>> Since each feature 'knows' its fragment, it is super easy for the 
>> compiler to generate the source level check diagnostic for any 
>> feature. And, if you need to add a new feature, you just need to add 
>> an enum value, and wired it up with the corresponding resource key - 
>> done :-)
>>
>> Since this change affects the way in which source check diagnostics 
>> are generated, quite a lot of changes were required to adjust 
>> expected output in golden files. Aside from those changes, I also 
>> addressed the following issues:
>>
>> * JavaTokenizer was not using SOURCE_LEVEL flags for its diagnostics, 
>> and it was not using the new diagnostic framework to generate errors, 
>> which made the porting harder - so I've fixed that
>> * CALog in Completeness analyzer required a new override for an 
>> AbstractLog::error variant that was probably forgotten (this was 
>> required otherwise CompletenessAnalyzerTest was failing after the 
>> change above)
>> * Log has a 'feature' so that diagnostics marked with the 
>> SOURCE_LEVEL flag can be reported only once per source. But this 
>> check was only looking at the 'head' of a diagnostic, ignoring all 
>> arguments. Since now all source level check diagnostics share the 
>> same head, I needed to tweak the logic to also compare arguments - or 
>> else, one source level check error being reported would also disable 
>> unrelated source level check diags.
>>
>> Then there were a bunch of mechanical translation, for instance 
>> idioms such as:
>>
>> allowSimplifiedVarargs = source.allowSimplifiedVarargs();
>>
>> Were rewritten as:
>>
>> allowSimplifiedVarargs = source.allowed(Feature.SIMPLIFIED_VARARGS);
>>
>> Also, in JavacParser, this idiom:
>>
>> checkTypeAnnotations();
>>
>> has been replaced with
>>
>> checkSourceLevel(Feature.TYPE_ANNOTATIONS);
>>
>> Where checkSourceLevel is a new general routine that works on any 
>> Feature.
>>
>> Finally, where possible, I also got rid of the various boolean flags 
>> of the kind 'allowPrivateMethodInInterfaces' - if the class already 
>> had a 'source' field, the boolean flag can be omitted, and the check 
>> can be performed on the source object itself.
>>
>> Cheers
>> Maurizio
>>
>>
>>
>


From maurizio.cimadamore at oracle.com  Mon Dec  4 12:22:19 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 4 Dec 2017 12:22:19 +0000
Subject: RFR 8189749: Devise strategy for making source level checks more
 uniform
In-Reply-To: <5A21F3F2.2060609@oracle.com>
References: <af46e66f-a0b7-2a65-7ca7-cecd3bbd7a43@oracle.com>
 <0d223e68-de26-1e59-adad-1f57c9d28762@oracle.com>
 <5A21F3F2.2060609@oracle.com>
Message-ID: <d89a0a2b-5da1-857e-718d-ca09298dd9cd@oracle.com>

Thanks,
I will make the change ahead of the push (w/o submitting another round) 
if that's ok

Maurizio


On 02/12/17 00:29, Jonathan Gibbons wrote:
> +1. Very nice.
>
> Nit: I would suggest changing multi-catch statements to the plural form.
>
> tests/MulticatchNotSupported.java:39: error: multi-catch statement is 
> not supported in -source 6
>
> -- Jon
>
> On 11/28/2017 06:19 AM, Maurizio Cimadamore wrote:
>> Updated webrev here:
>>
>> http://cr.openjdk.java.net/~mcimadamore/8189749-v2/
>>
>> I've included a report of the diagnostics that have been tweaked by 
>> this webrev here to make sure that singular vs. plural is used 
>> effectively:
>>
>> http://cr.openjdk.java.net/~mcimadamore/8189749-v2/diags.html
>>
>> Cheers
>> Maurizio
>>
>>
>> On 20/10/17 19:07, Maurizio Cimadamore wrote:
>>> Hi,
>>> this biggie patch allows the treatment of source level checks to be 
>>> more uniform. The general problem is explained in details here:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8189749
>>>
>>> Webrev is here:
>>>
>>> http://cr.openjdk.java.net/~mcimadamore/8189749/
>>>
>>> The way I approached this, was to create a first class entity, an 
>>> enum called Feature. Each 'feature' has:
>>>
>>> * a min source level (e.g. what is the min source level required to 
>>> compile that feature, meaning that lower levels will result in errors)
>>> * a max source level (e.g. what is the max source level required to 
>>> compile that feature, meaning that higher levels will result in errors)
>>> * an optional resource key
>>>
>>> The first two properties are obviously used to decided if feature 
>>> XYZ can be used given source level N. The last property is used to 
>>> automate generation of source check diagnostics. Note that this 
>>> patch introduce a _single_ source check diagnostic:
>>>
>>> # 0: message segment (feature), 1: string (found version), 2: string 
>>> (expected version)
>>> compiler.misc.feature.not.supported.in.source=\
>>> ?? {0} not supported in -source {1}\n\
>>> ??? (use -source {2} or higher to enable {0})
>>>
>>> And then there's a bunch of feature fragments, example:
>>>
>>> compiler.misc.feature.modules=\
>>> ??? modules
>>>
>>> compiler.misc.feature.diamond.and.anon.class=\
>>> ??? ''<>'' with anonymous inner classes
>>>
>>> compiler.misc.feature.binary.lit=\
>>> ??? binary literals
>>>
>>> (and many more :-))
>>>
>>> Since each feature 'knows' its fragment, it is super easy for the 
>>> compiler to generate the source level check diagnostic for any 
>>> feature. And, if you need to add a new feature, you just need to add 
>>> an enum value, and wired it up with the corresponding resource key - 
>>> done :-)
>>>
>>> Since this change affects the way in which source check diagnostics 
>>> are generated, quite a lot of changes were required to adjust 
>>> expected output in golden files. Aside from those changes, I also 
>>> addressed the following issues:
>>>
>>> * JavaTokenizer was not using SOURCE_LEVEL flags for its 
>>> diagnostics, and it was not using the new diagnostic framework to 
>>> generate errors, which made the porting harder - so I've fixed that
>>> * CALog in Completeness analyzer required a new override for an 
>>> AbstractLog::error variant that was probably forgotten (this was 
>>> required otherwise CompletenessAnalyzerTest was failing after the 
>>> change above)
>>> * Log has a 'feature' so that diagnostics marked with the 
>>> SOURCE_LEVEL flag can be reported only once per source. But this 
>>> check was only looking at the 'head' of a diagnostic, ignoring all 
>>> arguments. Since now all source level check diagnostics share the 
>>> same head, I needed to tweak the logic to also compare arguments - 
>>> or else, one source level check error being reported would also 
>>> disable unrelated source level check diags.
>>>
>>> Then there were a bunch of mechanical translation, for instance 
>>> idioms such as:
>>>
>>> allowSimplifiedVarargs = source.allowSimplifiedVarargs();
>>>
>>> Were rewritten as:
>>>
>>> allowSimplifiedVarargs = source.allowed(Feature.SIMPLIFIED_VARARGS);
>>>
>>> Also, in JavacParser, this idiom:
>>>
>>> checkTypeAnnotations();
>>>
>>> has been replaced with
>>>
>>> checkSourceLevel(Feature.TYPE_ANNOTATIONS);
>>>
>>> Where checkSourceLevel is a new general routine that works on any 
>>> Feature.
>>>
>>> Finally, where possible, I also got rid of the various boolean flags 
>>> of the kind 'allowPrivateMethodInInterfaces' - if the class already 
>>> had a 'source' field, the boolean flag can be omitted, and the check 
>>> can be performed on the source object itself.
>>>
>>> Cheers
>>> Maurizio
>>>
>>>
>>>
>>
>


From jonathan.gibbons at oracle.com  Mon Dec  4 17:15:34 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 4 Dec 2017 09:15:34 -0800
Subject: RFR 8189749: Devise strategy for making source level checks more
 uniform
In-Reply-To: <d89a0a2b-5da1-857e-718d-ca09298dd9cd@oracle.com>
References: <af46e66f-a0b7-2a65-7ca7-cecd3bbd7a43@oracle.com>
 <0d223e68-de26-1e59-adad-1f57c9d28762@oracle.com>
 <5A21F3F2.2060609@oracle.com>
 <d89a0a2b-5da1-857e-718d-ca09298dd9cd@oracle.com>
Message-ID: <2157ce58-237e-4698-50c7-79bd4fa79b3e@oracle.com>

Yes, that was my expectation.

-- Jon


On 12/4/17 4:22 AM, Maurizio Cimadamore wrote:
> Thanks,
> I will make the change ahead of the push (w/o submitting another 
> round) if that's ok
>
> Maurizio
>
>
> On 02/12/17 00:29, Jonathan Gibbons wrote:
>> +1. Very nice.
>>
>> Nit: I would suggest changing multi-catch statements to the plural form.
>>
>> tests/MulticatchNotSupported.java:39: error: multi-catch statement is 
>> not supported in -source 6
>>
>> -- Jon
>>
>> On 11/28/2017 06:19 AM, Maurizio Cimadamore wrote:
>>> Updated webrev here:
>>>
>>> http://cr.openjdk.java.net/~mcimadamore/8189749-v2/
>>>
>>> I've included a report of the diagnostics that have been tweaked by 
>>> this webrev here to make sure that singular vs. plural is used 
>>> effectively:
>>>
>>> http://cr.openjdk.java.net/~mcimadamore/8189749-v2/diags.html
>>>
>>> Cheers
>>> Maurizio
>>>
>>>
>>> On 20/10/17 19:07, Maurizio Cimadamore wrote:
>>>> Hi,
>>>> this biggie patch allows the treatment of source level checks to be 
>>>> more uniform. The general problem is explained in details here:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8189749
>>>>
>>>> Webrev is here:
>>>>
>>>> http://cr.openjdk.java.net/~mcimadamore/8189749/
>>>>
>>>> The way I approached this, was to create a first class entity, an 
>>>> enum called Feature. Each 'feature' has:
>>>>
>>>> * a min source level (e.g. what is the min source level required to 
>>>> compile that feature, meaning that lower levels will result in errors)
>>>> * a max source level (e.g. what is the max source level required to 
>>>> compile that feature, meaning that higher levels will result in 
>>>> errors)
>>>> * an optional resource key
>>>>
>>>> The first two properties are obviously used to decided if feature 
>>>> XYZ can be used given source level N. The last property is used to 
>>>> automate generation of source check diagnostics. Note that this 
>>>> patch introduce a _single_ source check diagnostic:
>>>>
>>>> # 0: message segment (feature), 1: string (found version), 2: 
>>>> string (expected version)
>>>> compiler.misc.feature.not.supported.in.source=\
>>>> ?? {0} not supported in -source {1}\n\
>>>> ??? (use -source {2} or higher to enable {0})
>>>>
>>>> And then there's a bunch of feature fragments, example:
>>>>
>>>> compiler.misc.feature.modules=\
>>>> ??? modules
>>>>
>>>> compiler.misc.feature.diamond.and.anon.class=\
>>>> ??? ''<>'' with anonymous inner classes
>>>>
>>>> compiler.misc.feature.binary.lit=\
>>>> ??? binary literals
>>>>
>>>> (and many more :-))
>>>>
>>>> Since each feature 'knows' its fragment, it is super easy for the 
>>>> compiler to generate the source level check diagnostic for any 
>>>> feature. And, if you need to add a new feature, you just need to 
>>>> add an enum value, and wired it up with the corresponding resource 
>>>> key - done :-)
>>>>
>>>> Since this change affects the way in which source check diagnostics 
>>>> are generated, quite a lot of changes were required to adjust 
>>>> expected output in golden files. Aside from those changes, I also 
>>>> addressed the following issues:
>>>>
>>>> * JavaTokenizer was not using SOURCE_LEVEL flags for its 
>>>> diagnostics, and it was not using the new diagnostic framework to 
>>>> generate errors, which made the porting harder - so I've fixed that
>>>> * CALog in Completeness analyzer required a new override for an 
>>>> AbstractLog::error variant that was probably forgotten (this was 
>>>> required otherwise CompletenessAnalyzerTest was failing after the 
>>>> change above)
>>>> * Log has a 'feature' so that diagnostics marked with the 
>>>> SOURCE_LEVEL flag can be reported only once per source. But this 
>>>> check was only looking at the 'head' of a diagnostic, ignoring all 
>>>> arguments. Since now all source level check diagnostics share the 
>>>> same head, I needed to tweak the logic to also compare arguments - 
>>>> or else, one source level check error being reported would also 
>>>> disable unrelated source level check diags.
>>>>
>>>> Then there were a bunch of mechanical translation, for instance 
>>>> idioms such as:
>>>>
>>>> allowSimplifiedVarargs = source.allowSimplifiedVarargs();
>>>>
>>>> Were rewritten as:
>>>>
>>>> allowSimplifiedVarargs = source.allowed(Feature.SIMPLIFIED_VARARGS);
>>>>
>>>> Also, in JavacParser, this idiom:
>>>>
>>>> checkTypeAnnotations();
>>>>
>>>> has been replaced with
>>>>
>>>> checkSourceLevel(Feature.TYPE_ANNOTATIONS);
>>>>
>>>> Where checkSourceLevel is a new general routine that works on any 
>>>> Feature.
>>>>
>>>> Finally, where possible, I also got rid of the various boolean 
>>>> flags of the kind 'allowPrivateMethodInInterfaces' - if the class 
>>>> already had a 'source' field, the boolean flag can be omitted, and 
>>>> the check can be performed on the source object itself.
>>>>
>>>> Cheers
>>>> Maurizio
>>>>
>>>>
>>>>
>>>
>>
>


From maurizio.cimadamore at oracle.com  Mon Dec  4 18:04:30 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 4 Dec 2017 18:04:30 +0000
Subject: RFR 8189749: Devise strategy for making source level checks more
 uniform
In-Reply-To: <2157ce58-237e-4698-50c7-79bd4fa79b3e@oracle.com>
References: <af46e66f-a0b7-2a65-7ca7-cecd3bbd7a43@oracle.com>
 <0d223e68-de26-1e59-adad-1f57c9d28762@oracle.com>
 <5A21F3F2.2060609@oracle.com>
 <d89a0a2b-5da1-857e-718d-ca09298dd9cd@oracle.com>
 <2157ce58-237e-4698-50c7-79bd4fa79b3e@oracle.com>
Message-ID: <ceee1d9b-2b5d-b2ac-e198-b1e9acc7829b@oracle.com>

Thanks - fixed and pushed!

Maurizio


On 04/12/17 17:15, Jonathan Gibbons wrote:
> Yes, that was my expectation.
>
> -- Jon
>
>
> On 12/4/17 4:22 AM, Maurizio Cimadamore wrote:
>> Thanks,
>> I will make the change ahead of the push (w/o submitting another 
>> round) if that's ok
>>
>> Maurizio
>>
>>
>> On 02/12/17 00:29, Jonathan Gibbons wrote:
>>> +1. Very nice.
>>>
>>> Nit: I would suggest changing multi-catch statements to the plural 
>>> form.
>>>
>>> tests/MulticatchNotSupported.java:39: error: multi-catch statement 
>>> is not supported in -source 6
>>>
>>> -- Jon
>>>
>>> On 11/28/2017 06:19 AM, Maurizio Cimadamore wrote:
>>>> Updated webrev here:
>>>>
>>>> http://cr.openjdk.java.net/~mcimadamore/8189749-v2/
>>>>
>>>> I've included a report of the diagnostics that have been tweaked by 
>>>> this webrev here to make sure that singular vs. plural is used 
>>>> effectively:
>>>>
>>>> http://cr.openjdk.java.net/~mcimadamore/8189749-v2/diags.html
>>>>
>>>> Cheers
>>>> Maurizio
>>>>
>>>>
>>>> On 20/10/17 19:07, Maurizio Cimadamore wrote:
>>>>> Hi,
>>>>> this biggie patch allows the treatment of source level checks to 
>>>>> be more uniform. The general problem is explained in details here:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8189749
>>>>>
>>>>> Webrev is here:
>>>>>
>>>>> http://cr.openjdk.java.net/~mcimadamore/8189749/
>>>>>
>>>>> The way I approached this, was to create a first class entity, an 
>>>>> enum called Feature. Each 'feature' has:
>>>>>
>>>>> * a min source level (e.g. what is the min source level required 
>>>>> to compile that feature, meaning that lower levels will result in 
>>>>> errors)
>>>>> * a max source level (e.g. what is the max source level required 
>>>>> to compile that feature, meaning that higher levels will result in 
>>>>> errors)
>>>>> * an optional resource key
>>>>>
>>>>> The first two properties are obviously used to decided if feature 
>>>>> XYZ can be used given source level N. The last property is used to 
>>>>> automate generation of source check diagnostics. Note that this 
>>>>> patch introduce a _single_ source check diagnostic:
>>>>>
>>>>> # 0: message segment (feature), 1: string (found version), 2: 
>>>>> string (expected version)
>>>>> compiler.misc.feature.not.supported.in.source=\
>>>>> ?? {0} not supported in -source {1}\n\
>>>>> ??? (use -source {2} or higher to enable {0})
>>>>>
>>>>> And then there's a bunch of feature fragments, example:
>>>>>
>>>>> compiler.misc.feature.modules=\
>>>>> ??? modules
>>>>>
>>>>> compiler.misc.feature.diamond.and.anon.class=\
>>>>> ??? ''<>'' with anonymous inner classes
>>>>>
>>>>> compiler.misc.feature.binary.lit=\
>>>>> ??? binary literals
>>>>>
>>>>> (and many more :-))
>>>>>
>>>>> Since each feature 'knows' its fragment, it is super easy for the 
>>>>> compiler to generate the source level check diagnostic for any 
>>>>> feature. And, if you need to add a new feature, you just need to 
>>>>> add an enum value, and wired it up with the corresponding resource 
>>>>> key - done :-)
>>>>>
>>>>> Since this change affects the way in which source check 
>>>>> diagnostics are generated, quite a lot of changes were required to 
>>>>> adjust expected output in golden files. Aside from those changes, 
>>>>> I also addressed the following issues:
>>>>>
>>>>> * JavaTokenizer was not using SOURCE_LEVEL flags for its 
>>>>> diagnostics, and it was not using the new diagnostic framework to 
>>>>> generate errors, which made the porting harder - so I've fixed that
>>>>> * CALog in Completeness analyzer required a new override for an 
>>>>> AbstractLog::error variant that was probably forgotten (this was 
>>>>> required otherwise CompletenessAnalyzerTest was failing after the 
>>>>> change above)
>>>>> * Log has a 'feature' so that diagnostics marked with the 
>>>>> SOURCE_LEVEL flag can be reported only once per source. But this 
>>>>> check was only looking at the 'head' of a diagnostic, ignoring all 
>>>>> arguments. Since now all source level check diagnostics share the 
>>>>> same head, I needed to tweak the logic to also compare arguments - 
>>>>> or else, one source level check error being reported would also 
>>>>> disable unrelated source level check diags.
>>>>>
>>>>> Then there were a bunch of mechanical translation, for instance 
>>>>> idioms such as:
>>>>>
>>>>> allowSimplifiedVarargs = source.allowSimplifiedVarargs();
>>>>>
>>>>> Were rewritten as:
>>>>>
>>>>> allowSimplifiedVarargs = source.allowed(Feature.SIMPLIFIED_VARARGS);
>>>>>
>>>>> Also, in JavacParser, this idiom:
>>>>>
>>>>> checkTypeAnnotations();
>>>>>
>>>>> has been replaced with
>>>>>
>>>>> checkSourceLevel(Feature.TYPE_ANNOTATIONS);
>>>>>
>>>>> Where checkSourceLevel is a new general routine that works on any 
>>>>> Feature.
>>>>>
>>>>> Finally, where possible, I also got rid of the various boolean 
>>>>> flags of the kind 'allowPrivateMethodInInterfaces' - if the class 
>>>>> already had a 'source' field, the boolean flag can be omitted, and 
>>>>> the check can be performed on the source object itself.
>>>>>
>>>>> Cheers
>>>>> Maurizio
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>


From cushon at google.com  Mon Dec  4 21:37:37 2017
From: cushon at google.com (Liam Miller-Cushon)
Date: Mon, 4 Dec 2017 13:37:37 -0800
Subject: RFR 8189708: class reading issue with named and annotated
 parameters
In-Reply-To: <CAL4QsgsFpyKG3fVrwzrtpat6La_Mm8X6tm5n=P+Qwf3+q7E5MQ@mail.gmail.com>
References: <CAL4QsgtDfRxacW3iWS_+1RxorSHin9_OCV+PUXw=shH+zD0H7Q@mail.gmail.com>
 <59E9A5B5.5060200@oracle.com>
 <CAL4Qsguo_rcHUYKNKuavFQO1QDA-T8xTWtO_abPZuqT-oy3DVQ@mail.gmail.com>
 <CAL4QsgsFpyKG3fVrwzrtpat6La_Mm8X6tm5n=P+Qwf3+q7E5MQ@mail.gmail.com>
Message-ID: <CAL4Qsgt3opbb5APWhigjHgQw_0hO4t_AR6AsdURZpovbdz6ikQ@mail.gmail.com>

Hi, is there any more feedback on this?

On Fri, Oct 20, 2017 at 5:51 PM, Liam Miller-Cushon <cushon at google.com>
wrote:

> Here's an updated patch that incorporates your approach:
> http://cr.openjdk.java.net/~cushon/8007720/webrev.01/
>
> I included the fix for JDK-8177486 so I could test the inner class / enum
> constructor case. If this looks like it's on the right track I'll move that
> part (and the corresponding tests) back into a separate change.
>
> On Fri, Oct 20, 2017 at 9:30 AM, Liam Miller-Cushon <cushon at google.com>
> wrote:
>
>> Thanks for the comments,
>>
>> On Fri, Oct 20, 2017 at 12:28 AM, Jan Lahoda <jan.lahoda at oracle.com>
>> wrote:
>>>
>>> -what happens if there are both runtime invisible and visible
>>> annotations of method's parameters? Seems those that appear later will
>>> overwrite those that appear sooner?
>>>
>>
>> Oops, thanks. The way your patch handles that looks good to me.
>>
>>
>>> -the MethodSymbol.savedParameterAnnotations is only used during reading
>>> inside the ClassReader, right? It seems wasteful to have it as a field on
>>> each MethodSymbol, better would be a field in ClassReader.
>>>
>>
>> Sounds good. I'll try to avoid having savedParameterNames as a field in
>> MethodSymbol also. Do you remember if you encountered any issues with that
>> in your patch?
>>
>>
>>> -please check what happens for annotations on constructors of
>>> enums/non-static innerclasses
>>>
>>
>> Will do. (Also, note that there appears to be an issue with reading
>> MethodParameters on constructors of enums/non-static inner classes:
>> JDK-8177486)
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171204/664057e1/attachment-0001.html>

From cushon at google.com  Tue Dec  5 23:39:18 2017
From: cushon at google.com (Liam Miller-Cushon)
Date: Tue, 5 Dec 2017 15:39:18 -0800
Subject: Do package-infos need to be reset between annotation processing
 rounds?
Message-ID: <CAL4QsgswjOw3E5=X2B5oKARGBMRYS2a+9-1=jFMePXKh6z-9GA@mail.gmail.com>

I have a question about the logic in JavacProcessingEnvironment's
treeCleaner that resets package-info state between annotation processing
rounds [1].

JDK-8193037 describes an issue where package-infos loaded from the
classpath are reset by treeCleaner. Those symbols doesn't get reinitialized
correctly, and package annotations are not visible during subsequent
annotation processing rounds.

I wondered if the logic was only meant to apply to package-infos being
compiled from source in the current compilation (similar to how
module-infos are handle by treeCleaner), but I'm having trouble
understanding when that logic is necessary. Commenting out
`node.packge.package_info.reset();` and `node.packge.reset();` in
treeCleaner doesn't break any jtreg tests. Does anyone have examples where
that code is needed? I'd like to add a regression test to ensure the fix
for JDK-8193037 doesn't interfere with the original purpose of that code.

Thanks,

[1]
http://hg.openjdk.java.net/jdk/jdk/file/a358ebcfacfb/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java#l1518
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171205/f7cb6efa/attachment.html>

From jonathan.gibbons at oracle.com  Wed Dec  6 00:46:35 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 05 Dec 2017 16:46:35 -0800
Subject: Do package-infos need to be reset between annotation processing
 rounds?
In-Reply-To: <CAL4QsgswjOw3E5=X2B5oKARGBMRYS2a+9-1=jFMePXKh6z-9GA@mail.gmail.com>
References: <CAL4QsgswjOw3E5=X2B5oKARGBMRYS2a+9-1=jFMePXKh6z-9GA@mail.gmail.com>
Message-ID: <5A273DEB.5060402@oracle.com>

Liam,

What about the case where an annotation processor generates the 
package-info.java file? Is that a case where it is important to reinit 
the packge symbol correctly, so that the newly generated code is read?

-- Jon

On 12/05/2017 03:39 PM, Liam Miller-Cushon wrote:
> I have a question about the logic in JavacProcessingEnvironment's 
> treeCleaner that resets package-info state between annotation 
> processing rounds [1].
>
> JDK-8193037 describes an issue where package-infos loaded from the 
> classpath are reset by treeCleaner. Those symbols doesn't get 
> reinitialized correctly, and package annotations are not visible 
> during subsequent annotation processing rounds.
>
> I wondered if the logic was only meant to apply to package-infos being 
> compiled from source in the current compilation (similar to how 
> module-infos are handle by treeCleaner), but I'm having trouble 
> understanding when that logic is necessary. Commenting out 
> `node.packge.package_info.reset();` and `node.packge.reset();` in 
> treeCleaner doesn't break any jtreg tests. Does anyone have examples 
> where that code is needed? I'd like to add a regression test to ensure 
> the fix for JDK-8193037 doesn't interfere with the original purpose of 
> that code.
>
> Thanks,
>
> [1] 
> http://hg.openjdk.java.net/jdk/jdk/file/a358ebcfacfb/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java#l1518


From cushon at google.com  Wed Dec  6 01:39:43 2017
From: cushon at google.com (Liam Miller-Cushon)
Date: Tue, 5 Dec 2017 17:39:43 -0800
Subject: Do package-infos need to be reset between annotation processing
 rounds?
In-Reply-To: <5A273DEB.5060402@oracle.com>
References: <CAL4QsgswjOw3E5=X2B5oKARGBMRYS2a+9-1=jFMePXKh6z-9GA@mail.gmail.com>
 <5A273DEB.5060402@oracle.com>
Message-ID: <CAL4QsgtTYEDtGHamouGj4JkVbZzBmEMC0ZjopYc9BEcSS8D=qA@mail.gmail.com>

Thanks! If an annotated package-info is loaded from the class path, and
then a processor generates a package-info that contains no annotations, the
reset is necessary. (The reset isn't necessary if the new package-info is
annotated, since the old annotations get overwritten even if they weren't
reset between rounds.)

On Tue, Dec 5, 2017 at 4:46 PM, Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> Liam,
>
> What about the case where an annotation processor generates the
> package-info.java file? Is that a case where it is important to reinit the
> packge symbol correctly, so that the newly generated code is read?
>
> -- Jon
>
>
> On 12/05/2017 03:39 PM, Liam Miller-Cushon wrote:
>
>> I have a question about the logic in JavacProcessingEnvironment's
>> treeCleaner that resets package-info state between annotation processing
>> rounds [1].
>>
>> JDK-8193037 describes an issue where package-infos loaded from the
>> classpath are reset by treeCleaner. Those symbols doesn't get reinitialized
>> correctly, and package annotations are not visible during subsequent
>> annotation processing rounds.
>>
>> I wondered if the logic was only meant to apply to package-infos being
>> compiled from source in the current compilation (similar to how
>> module-infos are handle by treeCleaner), but I'm having trouble
>> understanding when that logic is necessary. Commenting out
>> `node.packge.package_info.reset();` and `node.packge.reset();` in
>> treeCleaner doesn't break any jtreg tests. Does anyone have examples where
>> that code is needed? I'd like to add a regression test to ensure the fix
>> for JDK-8193037 doesn't interfere with the original purpose of that code.
>>
>> Thanks,
>>
>> [1] http://hg.openjdk.java.net/jdk/jdk/file/a358ebcfacfb/src/jdk
>> .compiler/share/classes/com/sun/tools/javac/processing/Jav
>> acProcessingEnvironment.java#l1518
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171205/8a59793b/attachment.html>

From cushon at google.com  Wed Dec  6 01:49:22 2017
From: cushon at google.com (Liam Miller-Cushon)
Date: Tue, 5 Dec 2017 17:49:22 -0800
Subject: RFR: 8193037 package-info annotations are not reported when
 annotation processing is enabled
Message-ID: <CAL4Qsgu6DS1ZfkG4AvYmWtgFJsiZx_cu4CfPoQCcpeDaDcdEFw@mail.gmail.com>

Hello,

Please review the following fix for JDK-8193037.

javac should only reset package-info symbols between annotation processing
rounds if
the package-info is being compiled from source. Previously package-infos
loaded from
the classpath were reset and not reinitialized, leading to package
annotations being
unavailable during later annotation processing rounds.

I included an additional test case to ensure that package-infos are still
reset when
necessary. Related discussion:
http://mail.openjdk.java.net/pipermail/compiler-dev/2017-December/011398.html

bug: https://bugs.openjdk.java.net/browse/JDK-8193037
webrev: http://cr.openjdk.java.net/~cushon/8193037/webrev.00/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171205/7c196f2c/attachment.html>

From jonathan.gibbons at oracle.com  Wed Dec  6 02:09:10 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 05 Dec 2017 18:09:10 -0800
Subject: Do package-infos need to be reset between annotation processing
 rounds?
In-Reply-To: <CAL4QsgtTYEDtGHamouGj4JkVbZzBmEMC0ZjopYc9BEcSS8D=qA@mail.gmail.com>
References: <CAL4QsgswjOw3E5=X2B5oKARGBMRYS2a+9-1=jFMePXKh6z-9GA@mail.gmail.com>
 <5A273DEB.5060402@oracle.com>
 <CAL4QsgtTYEDtGHamouGj4JkVbZzBmEMC0ZjopYc9BEcSS8D=qA@mail.gmail.com>
Message-ID: <5A275146.3080903@oracle.com>

Generally, annotation processing is supposed to only create information 
where there was no information previously,  so if a package had a 
package-info with annotations, it seems like it should be an error to 
override it with another package-info, with or without annotations.

-- Jon

On 12/05/2017 05:39 PM, Liam Miller-Cushon wrote:
> Thanks! If an annotated package-info is loaded from the class path, 
> and then a processor generates a package-info that contains no 
> annotations, the reset is necessary. (The reset isn't necessary if the 
> new package-info is annotated, since the old annotations get 
> overwritten even if they weren't reset between rounds.)
>
> On Tue, Dec 5, 2017 at 4:46 PM, Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>
>     Liam,
>
>     What about the case where an annotation processor generates the
>     package-info.java file? Is that a case where it is important to
>     reinit the packge symbol correctly, so that the newly generated
>     code is read?
>
>     -- Jon
>
>
>     On 12/05/2017 03:39 PM, Liam Miller-Cushon wrote:
>
>         I have a question about the logic in
>         JavacProcessingEnvironment's treeCleaner that resets
>         package-info state between annotation processing rounds [1].
>
>         JDK-8193037 describes an issue where package-infos loaded from
>         the classpath are reset by treeCleaner. Those symbols doesn't
>         get reinitialized correctly, and package annotations are not
>         visible during subsequent annotation processing rounds.
>
>         I wondered if the logic was only meant to apply to
>         package-infos being compiled from source in the current
>         compilation (similar to how module-infos are handle by
>         treeCleaner), but I'm having trouble understanding when that
>         logic is necessary. Commenting out
>         `node.packge.package_info.reset();` and `node.packge.reset();`
>         in treeCleaner doesn't break any jtreg tests. Does anyone have
>         examples where that code is needed? I'd like to add a
>         regression test to ensure the fix for JDK-8193037 doesn't
>         interfere with the original purpose of that code.
>
>         Thanks,
>
>         [1]
>         http://hg.openjdk.java.net/jdk/jdk/file/a358ebcfacfb/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java#l1518
>         <http://hg.openjdk.java.net/jdk/jdk/file/a358ebcfacfb/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java#l1518>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171205/5a7f81fa/attachment-0001.html>

From cushon at google.com  Wed Dec  6 02:24:36 2017
From: cushon at google.com (Liam Miller-Cushon)
Date: Tue, 5 Dec 2017 18:24:36 -0800
Subject: Do package-infos need to be reset between annotation processing
 rounds?
In-Reply-To: <5A275146.3080903@oracle.com>
References: <CAL4QsgswjOw3E5=X2B5oKARGBMRYS2a+9-1=jFMePXKh6z-9GA@mail.gmail.com>
 <5A273DEB.5060402@oracle.com>
 <CAL4QsgtTYEDtGHamouGj4JkVbZzBmEMC0ZjopYc9BEcSS8D=qA@mail.gmail.com>
 <5A275146.3080903@oracle.com>
Message-ID: <CAL4QsgtmieC+a1vi9FremH3T2emMTuxqO_YLJrPq6V2T3xm1Og@mail.gmail.com>

Is overriding package-infos different or worse than overriding other
symbols? I've seen a number of examples where the same source file was
compiled multiple times and the earlier results ended up on the class path
of the later compilations, so a processor-generated class was both on the
class path and generated during the compilation. Making that an error would
be a somewhat invasive breaking change. I agree that it should be
discouraged, but I'm not sure it's worth making an error? (Unless there's
something special about package-infos that I'm missing.)

On Tue, Dec 5, 2017 at 6:09 PM, Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> Generally, annotation processing is supposed to only create information
> where there was no information previously,  so if a package had a
> package-info with annotations, it seems like it should be an error to
> override it with another package-info, with or without annotations.
>
> -- Jon
>
>
> On 12/05/2017 05:39 PM, Liam Miller-Cushon wrote:
>
> Thanks! If an annotated package-info is loaded from the class path, and
> then a processor generates a package-info that contains no annotations, the
> reset is necessary. (The reset isn't necessary if the new package-info is
> annotated, since the old annotations get overwritten even if they weren't
> reset between rounds.)
>
> On Tue, Dec 5, 2017 at 4:46 PM, Jonathan Gibbons <
> jonathan.gibbons at oracle.com> wrote:
>
>> Liam,
>>
>> What about the case where an annotation processor generates the
>> package-info.java file? Is that a case where it is important to reinit the
>> packge symbol correctly, so that the newly generated code is read?
>>
>> -- Jon
>>
>>
>> On 12/05/2017 03:39 PM, Liam Miller-Cushon wrote:
>>
>>> I have a question about the logic in JavacProcessingEnvironment's
>>> treeCleaner that resets package-info state between annotation processing
>>> rounds [1].
>>>
>>> JDK-8193037 describes an issue where package-infos loaded from the
>>> classpath are reset by treeCleaner. Those symbols doesn't get reinitialized
>>> correctly, and package annotations are not visible during subsequent
>>> annotation processing rounds.
>>>
>>> I wondered if the logic was only meant to apply to package-infos being
>>> compiled from source in the current compilation (similar to how
>>> module-infos are handle by treeCleaner), but I'm having trouble
>>> understanding when that logic is necessary. Commenting out
>>> `node.packge.package_info.reset();` and `node.packge.reset();` in
>>> treeCleaner doesn't break any jtreg tests. Does anyone have examples where
>>> that code is needed? I'd like to add a regression test to ensure the fix
>>> for JDK-8193037 doesn't interfere with the original purpose of that code.
>>>
>>> Thanks,
>>>
>>> [1] http://hg.openjdk.java.net/jdk/jdk/file/a358ebcfacfb/src/jdk
>>> .compiler/share/classes/com/sun/tools/javac/processing/Javac
>>> ProcessingEnvironment.java#l1518
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171205/5d253dd8/attachment.html>

From jonathan.gibbons at oracle.com  Wed Dec  6 07:48:14 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 5 Dec 2017 23:48:14 -0800
Subject: Do package-infos need to be reset between annotation processing
 rounds?
In-Reply-To: <CAL4QsgtmieC+a1vi9FremH3T2emMTuxqO_YLJrPq6V2T3xm1Og@mail.gmail.com>
References: <CAL4QsgswjOw3E5=X2B5oKARGBMRYS2a+9-1=jFMePXKh6z-9GA@mail.gmail.com>
 <5A273DEB.5060402@oracle.com>
 <CAL4QsgtTYEDtGHamouGj4JkVbZzBmEMC0ZjopYc9BEcSS8D=qA@mail.gmail.com>
 <5A275146.3080903@oracle.com>
 <CAL4QsgtmieC+a1vi9FremH3T2emMTuxqO_YLJrPq6V2T3xm1Og@mail.gmail.com>
Message-ID: <7c9034fd-c538-44a0-95b6-c0b91ee71f43@oracle.com>

We'll need Joe "Mr Annotation Processing" Darcy to chime in here, but 
the Filer is supposed to detect clashes, and prevent 
overwriting/overriding symbols. That's definitely supposed to happen for 
normal classes/interfaces; I could believe that package-info has been 
overlooked, but I would expect it to follow the same guidelines.

-- Jon


On 12/5/17 6:24 PM, Liam Miller-Cushon wrote:
> Is overriding package-infos different or worse than overriding other 
> symbols? I've seen a number of examples where the same source file was 
> compiled multiple times and the earlier results ended up on the class 
> path of the later compilations, so a processor-generated class was 
> both on the class path and generated during the compilation. Making 
> that an error would be a somewhat invasive breaking change. I agree 
> that it should be discouraged, but I'm not sure it's worth making an 
> error? (Unless there's something special about package-infos that I'm 
> missing.)
>
> On Tue, Dec 5, 2017 at 6:09 PM, Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>
>     Generally, annotation processing is supposed to only create
>     information where there was no information previously,? so if a
>     package had a package-info with annotations, it seems like it
>     should be an error to override it with another package-info, with
>     or without annotations.
>
>     -- Jon
>
>
>     On 12/05/2017 05:39 PM, Liam Miller-Cushon wrote:
>>     Thanks! If an annotated package-info is loaded from the class
>>     path, and then a processor generates a package-info that contains
>>     no annotations, the reset is necessary. (The reset isn't
>>     necessary if the new package-info is annotated, since the old
>>     annotations get overwritten even if they weren't reset between
>>     rounds.)
>>
>>     On Tue, Dec 5, 2017 at 4:46 PM, Jonathan Gibbons
>>     <jonathan.gibbons at oracle.com
>>     <mailto:jonathan.gibbons at oracle.com>> wrote:
>>
>>         Liam,
>>
>>         What about the case where an annotation processor generates
>>         the package-info.java file? Is that a case where it is
>>         important to reinit the packge symbol correctly, so that the
>>         newly generated code is read?
>>
>>         -- Jon
>>
>>
>>         On 12/05/2017 03:39 PM, Liam Miller-Cushon wrote:
>>
>>             I have a question about the logic in
>>             JavacProcessingEnvironment's treeCleaner that resets
>>             package-info state between annotation processing rounds [1].
>>
>>             JDK-8193037 describes an issue where package-infos loaded
>>             from the classpath are reset by treeCleaner. Those
>>             symbols doesn't get reinitialized correctly, and package
>>             annotations are not visible during subsequent annotation
>>             processing rounds.
>>
>>             I wondered if the logic was only meant to apply to
>>             package-infos being compiled from source in the current
>>             compilation (similar to how module-infos are handle by
>>             treeCleaner), but I'm having trouble understanding when
>>             that logic is necessary. Commenting out
>>             `node.packge.package_info.reset();` and
>>             `node.packge.reset();` in treeCleaner doesn't break any
>>             jtreg tests. Does anyone have examples where that code is
>>             needed? I'd like to add a regression test to ensure the
>>             fix for JDK-8193037 doesn't interfere with the original
>>             purpose of that code.
>>
>>             Thanks,
>>
>>             [1]
>>             http://hg.openjdk.java.net/jdk/jdk/file/a358ebcfacfb/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java#l1518
>>             <http://hg.openjdk.java.net/jdk/jdk/file/a358ebcfacfb/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java#l1518>
>>
>>
>>
>
>

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

From cushon at google.com  Wed Dec  6 09:11:56 2017
From: cushon at google.com (Liam Miller-Cushon)
Date: Wed, 6 Dec 2017 01:11:56 -0800
Subject: Do package-infos need to be reset between annotation processing
 rounds?
In-Reply-To: <7c9034fd-c538-44a0-95b6-c0b91ee71f43@oracle.com>
References: <CAL4QsgswjOw3E5=X2B5oKARGBMRYS2a+9-1=jFMePXKh6z-9GA@mail.gmail.com>
 <5A273DEB.5060402@oracle.com>
 <CAL4QsgtTYEDtGHamouGj4JkVbZzBmEMC0ZjopYc9BEcSS8D=qA@mail.gmail.com>
 <5A275146.3080903@oracle.com>
 <CAL4QsgtmieC+a1vi9FremH3T2emMTuxqO_YLJrPq6V2T3xm1Og@mail.gmail.com>
 <7c9034fd-c538-44a0-95b6-c0b91ee71f43@oracle.com>
Message-ID: <CAL4QsgsDqd=tS4ZeRZ72ou+4gQRzLk9S60cQBSUvso+00R2DoQ@mail.gmail.com>

I think the current implementation of Filer doesn't check if generated
classes override arbitrary classes on the classpath, it only checks if they
clash with previously generated classes, or the sources and classes that
were explicit inputs to the compilation:
http://hg.openjdk.java.net/jdk/jdk/file/a9405d9ca8a8/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacFiler.java#l719

On Tue, Dec 5, 2017 at 11:48 PM, Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> We'll need Joe "Mr Annotation Processing" Darcy to chime in here, but the
> Filer is supposed to detect clashes, and prevent overwriting/overriding
> symbols. That's definitely supposed to happen for normal
> classes/interfaces; I could believe that package-info has been overlooked,
> but I would expect it to follow the same guidelines.
>
> -- Jon
>
> On 12/5/17 6:24 PM, Liam Miller-Cushon wrote:
>
> Is overriding package-infos different or worse than overriding other
> symbols? I've seen a number of examples where the same source file was
> compiled multiple times and the earlier results ended up on the class path
> of the later compilations, so a processor-generated class was both on the
> class path and generated during the compilation. Making that an error would
> be a somewhat invasive breaking change. I agree that it should be
> discouraged, but I'm not sure it's worth making an error? (Unless there's
> something special about package-infos that I'm missing.)
>
> On Tue, Dec 5, 2017 at 6:09 PM, Jonathan Gibbons <
> jonathan.gibbons at oracle.com> wrote:
>
>> Generally, annotation processing is supposed to only create information
>> where there was no information previously,  so if a package had a
>> package-info with annotations, it seems like it should be an error to
>> override it with another package-info, with or without annotations.
>>
>> -- Jon
>>
>>
>> On 12/05/2017 05:39 PM, Liam Miller-Cushon wrote:
>>
>> Thanks! If an annotated package-info is loaded from the class path, and
>> then a processor generates a package-info that contains no annotations, the
>> reset is necessary. (The reset isn't necessary if the new package-info is
>> annotated, since the old annotations get overwritten even if they weren't
>> reset between rounds.)
>>
>> On Tue, Dec 5, 2017 at 4:46 PM, Jonathan Gibbons <
>> jonathan.gibbons at oracle.com> wrote:
>>
>>> Liam,
>>>
>>> What about the case where an annotation processor generates the
>>> package-info.java file? Is that a case where it is important to reinit the
>>> packge symbol correctly, so that the newly generated code is read?
>>>
>>> -- Jon
>>>
>>>
>>> On 12/05/2017 03:39 PM, Liam Miller-Cushon wrote:
>>>
>>>> I have a question about the logic in JavacProcessingEnvironment's
>>>> treeCleaner that resets package-info state between annotation processing
>>>> rounds [1].
>>>>
>>>> JDK-8193037 describes an issue where package-infos loaded from the
>>>> classpath are reset by treeCleaner. Those symbols doesn't get reinitialized
>>>> correctly, and package annotations are not visible during subsequent
>>>> annotation processing rounds.
>>>>
>>>> I wondered if the logic was only meant to apply to package-infos being
>>>> compiled from source in the current compilation (similar to how
>>>> module-infos are handle by treeCleaner), but I'm having trouble
>>>> understanding when that logic is necessary. Commenting out
>>>> `node.packge.package_info.reset();` and `node.packge.reset();` in
>>>> treeCleaner doesn't break any jtreg tests. Does anyone have examples where
>>>> that code is needed? I'd like to add a regression test to ensure the fix
>>>> for JDK-8193037 doesn't interfere with the original purpose of that code.
>>>>
>>>> Thanks,
>>>>
>>>> [1] http://hg.openjdk.java.net/jdk/jdk/file/a358ebcfacfb/src/jdk
>>>> .compiler/share/classes/com/sun/tools/javac/processing/Javac
>>>> ProcessingEnvironment.java#l1518
>>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171206/7c900dfd/attachment-0001.html>

From jan.lahoda at oracle.com  Wed Dec  6 21:11:58 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 6 Dec 2017 22:11:58 +0100
Subject: RFR: JDK-8189778: Jshell crash on tab for StringBuilder.append(
In-Reply-To: <59FB10F5.4000407@oracle.com>
References: <59F1AC72.4020202@oracle.com> <59F8A8E6.6030609@oracle.com>
 <59FB10F5.4000407@oracle.com>
Message-ID: <5A285D1E.5090205@oracle.com>

Hi,

A webrev updated to the current state and with some further fixes is here:
http://cr.openjdk.java.net/~jlahoda/8189778/webrev.02/

On 2.11.2017 13:35, Kumar Srinivasan wrote:
>
> Hi Jan,
>
> Generally it looks fine to me, a few nits...
>
> JavadocHelper.java
>
> 1.
>
> -                        //which will be resolve in visitInheritDoc:
> suggest....
> +                        //which will be resolved in visitInheritDoc:

Done.

>
> 2. Suggest adding a space after /** or /* makes it a little easier
> to read the comments.

Done.

>
> 3.
>
> - //insertPos (as future missing elements should be inserted behind
> + //insertPos (as future missing elements should be inserted before

The missing elements are inserted behind the tree that was visited by 
the method.

>
> 4.
> -  //if there is a newline immediatelly after this tree, insert after
> +   //if there is a newline immediately after this tree, insert after

Done. Also changed "after" to "behind".

>
> 5. Several private methods have have javadoc comments /**, do you
> run javadoc -private on jshell sources ?

Changed to comments to /*.

Any feedback is welcome!

Thanks,
    Jan

>
> You may want to get Jon's review on this, he is much more familiar
> with these things, than I.
>
> Thanks
> Kumar
>
>> I've updated to patch to have some comments at places that seemed
>> important:
>> http://cr.openjdk.java.net/~jlahoda/8189778/webrev.01/
>>
>> Jan
>>
>> On 26.10.2017 11:35, Jan Lahoda wrote:
>>> Hi,
>>>
>>> Typing:
>>> jshell> StringBuilder sb = new StringBuilder();
>>> jshell> sb.append(<tab><tab>
>>>
>>> Will lead to an exception:
>>> jshell> sb.append(Exception in thread "main"
>>> java.lang.StringIndexOutOfBoundsException: start -59, end -59, length
>>> 238
>>> [snip]
>>> jdk.compiler/jdk.internal.shellsupport.doc.JavadocHelper$OnDemandJavadocHelper.getResolvedDocComment(JavadocHelper.java:481)
>>>
>>>
>>>
>>> The reason is that the javadoc for StringBuilder.append(CharSequence,
>>> int, int) is:
>>>      /**
>>>       * @throws     IndexOutOfBoundsException {@inheritDoc}
>>>       */
>>>
>>> The JavadocHelper tries to fill in the missing javadoc entries, but that
>>> fails because it tries to insert the preceding entries at an
>>> uninitialized place.
>>>
>>> The proposed patch:
>>> -fixes the above
>>> -adds a test that runs the JavadocHelper on all
>>> methods/fields/constructors of top-level types in all exported packages
>>> (this runs for a considerable time, and we may need to disable this test
>>> if it proves to be too heavyweight)
>>> -adds a few more test cases for problems found by the above test
>>> -fixes the javadoc resolution to treat missing javadoc body as
>>> {@inheritDoc} (so that the overridden method's javadoc text is used if
>>> missing in this method)
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189778
>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8189778/webrev.00/
>>>
>>> Feedback is welcome.
>>>
>>> Thanks,
>>>      Jan
>

From goetz.lindenmaier at sap.com  Thu Dec  7 11:20:40 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 7 Dec 2017 11:20:40 +0000
Subject: FW: RFR(M): 8189102: All tools should support -?, -h and --help
In-Reply-To: <8aa25976d496465fac00a4ae3628e533@sap.com>
References: <c27028f9f5844c3c818885f88c75f84b@sap.com>
 <8aa25976d496465fac00a4ae3628e533@sap.com>
Message-ID: <456c694ec25a42658af1b8600aaa136d@sap.com>

Hi,

... missed some lists in my first post ...

I prepared a fifth webrev for this change.  Please review.

It incorporates the changes requested by the CSR reviewers 
(not to remove docuemtation of '-help' where is was documented
before) and the changes proposed by Kumar:
http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.05/

See also the information in the webrev  itself, there are also patch files
with the incremental builds.

This change contains fixes for some langtool tests.
I ran the following test suites on it:
hotspot, jdk, langtools, nashorn, jaxp, most of them on 
all the platforms we build.

Best regards,
  Goetz.




> -----Original Message-----
> From: Lindenmaier, Goetz
> Sent: Mittwoch, 11. Oktober 2017 22:07
> To: hotspot-dev developers <hotspot-dev at openjdk.java.net>
> Subject: RFR(M): 8189102: All tools should support -?, -h and --help
> 
> Hi
> 
> The tools in jdk should all show the same behavior wrt. help flags.
> This change normalizes the help flags of a row of the tools in the jdk.
> Java accepts -?, -h and --help, thus I changed the tools to support
> these, too.  Some tools exited with '1' after displaying the help message,
> I turned this to '0'.
> 
> Maybe this is not the right mailing list for this, please advise.
> 
> Please review this change. I please need a sponsor.
> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.01/
> 
> In detail, this fixes the help message of the following tools:
> jar          -? -h --help;  added -?.
> jarsigner    -? -h --help;  added --help. -help accepted but not documented.
> javac        -?    --help;  added -?. Removed -help. -h is taken for other purpose
> javadoc      -? -h --help;  added -h -?. Removed -help
> javap        -? -h --help;  added -h. -help accepted but no more documented.
> jcmd         -? -h --help;  added -? --help. -help accepted but no more
> documented. Changed return value to '0'
> jdb          -? -h --help;  added -? -h --help. -help accepted but no more
> documented.
> jdeprscan    -? -h --help;  added -?
> jinfo        -? -h --help;  added -? --help. -help accepted but no more
> documented.
> jjs             -h --help;  Replaced -help by --help. Adding more not straight
> forward.
> jps          -? -h --help;  added -? --help. -help accepted but no more
> documented.
> jshell       -? -h --help;  added -?
> jstat        -? -h --help;  added -h --help. -help accepted but no more
> documented.
> 
> Best regards,
>   Goetz.

From joe.darcy at oracle.com  Thu Dec  7 17:12:05 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Thu, 7 Dec 2017 09:12:05 -0800
Subject: JDK 10 RFR of JDK-8193191: Update JavacTestingAbstractProcessor for
 JDK 10
Message-ID: <d9ff6249-1f66-d093-f5c7-d24acc28c960@oracle.com>

Hello,

Please review the straightforward patch below to update the 
JavacTestingAbstractProcessor utility superclass to JDK 10.

      JDK-8193191: Update JavacTestingAbstractProcessor for JDK 10

Besides the use of Set.of, most of the updates are just bumping 
@SupportedSourceVersion annotation from 9 to 10.

Thanks,

-Joe

diff -r 56d3576aadd5 
test/langtools/tools/javac/lib/JavacTestingAbstractProcessor.java
--- a/test/langtools/tools/javac/lib/JavacTestingAbstractProcessor.java 
Mon Dec 04 19:12:57 2017 +0100
+++ b/test/langtools/tools/javac/lib/JavacTestingAbstractProcessor.java 
Thu Dec 07 09:04:27 2017 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2010, 2015, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2010, 2017, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -31,13 +31,7 @@
   * An abstract annotation processor tailored to {@code javac} 
regression testing.
   */
  public abstract class JavacTestingAbstractProcessor extends 
AbstractProcessor {
-    private static final Set<String> allAnnotations;
-
-    static {
-        Set<String> tmp = new HashSet<>();
-        tmp.add("*");
-        allAnnotations = Collections.unmodifiableSet(tmp);
-    }
+    private static final Set<String> allAnnotations = Set.of("*");

      protected Elements eltUtils;
      protected Elements elements;
@@ -116,7 +110,7 @@
       * corresponding platform visitor type.
       */

-    @SupportedSourceVersion(RELEASE_9)
+    @SupportedSourceVersion(RELEASE_10)
      public static abstract class AbstractAnnotationValueVisitor<R, P> 
extends AbstractAnnotationValueVisitor9<R, P> {

          /**
@@ -127,7 +121,7 @@
          }
      }

-    @SupportedSourceVersion(RELEASE_9)
+    @SupportedSourceVersion(RELEASE_10)
      public static abstract class AbstractElementVisitor<R, P> extends 
AbstractElementVisitor9<R, P> {
          /**
           * Constructor for concrete subclasses to call.
@@ -137,7 +131,7 @@
          }
      }

-    @SupportedSourceVersion(RELEASE_9)
+    @SupportedSourceVersion(RELEASE_10)
      public static abstract class AbstractTypeVisitor<R, P> extends 
AbstractTypeVisitor9<R, P> {
          /**
           * Constructor for concrete subclasses to call.
@@ -147,7 +141,7 @@
          }
      }

-    @SupportedSourceVersion(RELEASE_9)
+    @SupportedSourceVersion(RELEASE_10)
      public static class ElementKindVisitor<R, P> extends 
ElementKindVisitor9<R, P> {
          /**
           * Constructor for concrete subclasses; uses {@code null} for the
@@ -168,7 +162,7 @@
          }
      }

-    @SupportedSourceVersion(RELEASE_9)
+    @SupportedSourceVersion(RELEASE_10)
      public static class ElementScanner<R, P> extends 
ElementScanner9<R, P> {
          /**
           * Constructor for concrete subclasses; uses {@code null} for the
@@ -187,7 +181,7 @@
          }
      }

-    @SupportedSourceVersion(RELEASE_9)
+    @SupportedSourceVersion(RELEASE_10)
      public static class SimpleAnnotationValueVisitor<R, P> extends 
SimpleAnnotationValueVisitor9<R, P> {
          /**
           * Constructor for concrete subclasses; uses {@code null} for the
@@ -208,7 +202,7 @@
          }
      }

-    @SupportedSourceVersion(RELEASE_9)
+    @SupportedSourceVersion(RELEASE_10)
      public static class SimpleElementVisitor<R, P> extends 
SimpleElementVisitor9<R, P> {
          /**
           * Constructor for concrete subclasses; uses {@code null} for the
@@ -229,7 +223,7 @@
          }
      }

-    @SupportedSourceVersion(RELEASE_9)
+    @SupportedSourceVersion(RELEASE_10)
      public static class SimpleTypeVisitor<R, P> extends 
SimpleTypeVisitor9<R, P> {
          /**
           * Constructor for concrete subclasses; uses {@code null} for the
@@ -250,7 +244,7 @@
          }
      }

-    @SupportedSourceVersion(RELEASE_9)
+    @SupportedSourceVersion(RELEASE_10)
      public static class TypeKindVisitor<R, P> extends 
TypeKindVisitor9<R, P> {
          /**
           * Constructor for concrete subclasses to call; uses {@code null}


From joe.darcy at oracle.com  Thu Dec  7 17:29:10 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Thu, 7 Dec 2017 09:29:10 -0800
Subject: JDK 10 RFR of JDK-8193194: Update javax.lang.model.util visitors for
 10
Message-ID: <83025f84-5fc1-4f27-3b02-dcb31e8e2639@oracle.com>

Hello,

The javax.lang.model API was introduced in JDK 6 via JSR 269. In JDK 7, 
8, and 9 new sets of concrete visitors were added in the 
javax.lang.model.util package. In JDKs 7, 8, and 9, there were new 
language changes that required new modeling constructs. There are no 
such changes in JDK 10. Therefore, a new set of visitors will not be 
added for JDK 10. However, some minor updates to the JDK 9 visitors 
should be made to indicate they cover both JDK 9 and JDK 10 constructs.

Please review the patch below which implements the updates.

-Joe

diff -r 56d3576aadd5 
src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor9.java
--- 
a/src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor9.java 
Mon Dec 04 19:12:57 2017 +0100
+++ 
b/src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor9.java 
Thu Dec 07 09:28:13 2017 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2011, 2014, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2011, 2017, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -32,7 +32,7 @@
  /**
   * A skeletal visitor for annotation values with default behavior
   * appropriate for the {@link SourceVersion#RELEASE_9 RELEASE_9}
- * source version.
+ * and {@link SourceVersion#RELEASE_10 RELEASE_10} source versions.
   *
   * <p> <b>WARNING:</b> The {@code AnnotationValueVisitor} interface
   * implemented by this class may have methods added to it in the
@@ -59,7 +59,7 @@
   * @see AbstractAnnotationValueVisitor8
   * @since 9
   */
- at SupportedSourceVersion(RELEASE_9)
+ at SupportedSourceVersion(RELEASE_10)
  public abstract class AbstractAnnotationValueVisitor9<R, P> extends 
AbstractAnnotationValueVisitor8<R, P> {

      /**
diff -r 56d3576aadd5 
src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor9.java
--- 
a/src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor9.java 
Mon Dec 04 19:12:57 2017 +0100
+++ 
b/src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor9.java 
Thu Dec 07 09:28:13 2017 -0800
@@ -34,7 +34,7 @@
  /**
   * A skeletal visitor of program elements with default behavior
   * appropriate for the {@link SourceVersion#RELEASE_9 RELEASE_9}
- * source version.
+ * and {@link SourceVersion#RELEASE_10 RELEASE_10} source versions.
   *
   * <p> <b>WARNING:</b> The {@code ElementVisitor} interface
   * implemented by this class may have methods added to it in the
@@ -65,7 +65,7 @@
   * @since 9
   * @spec JPMS
   */
- at SupportedSourceVersion(RELEASE_9)
+ at SupportedSourceVersion(RELEASE_10)
  public abstract class AbstractElementVisitor9<R, P> extends 
AbstractElementVisitor8<R, P> {
      /**
       * Constructor for concrete subclasses to call.
diff -r 56d3576aadd5 
src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor9.java
--- 
a/src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor9.java 
Mon Dec 04 19:12:57 2017 +0100
+++ 
b/src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor9.java 
Thu Dec 07 09:28:13 2017 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2011, 2014, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2011, 2017, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -27,13 +27,13 @@

  import javax.annotation.processing.SupportedSourceVersion;
  import javax.lang.model.type.*;
-
+import javax.lang.model.SourceVersion;
  import static javax.lang.model.SourceVersion.*;

  /**
   * A skeletal visitor of types with default behavior appropriate for
- * the {@link javax.lang.model.SourceVersion#RELEASE_9 RELEASE_9}
- * source version.
+ * the {@link SourceVersion#RELEASE_9 RELEASE_9}
+ * and {@link SourceVersion#RELEASE_10 RELEASE_10} source versions.
   *
   * <p> <b>WARNING:</b> The {@code TypeVisitor} interface implemented
   * by this class may have methods added to it in the future to
@@ -63,7 +63,7 @@
   * @see AbstractTypeVisitor8
   * @since 9
   */
- at SupportedSourceVersion(RELEASE_9)
+ at SupportedSourceVersion(RELEASE_10)
  public abstract class AbstractTypeVisitor9<R, P> extends 
AbstractTypeVisitor8<R, P> {
      /**
       * Constructor for concrete subclasses to call.
diff -r 56d3576aadd5 
src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor9.java
--- 
a/src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor9.java 
Mon Dec 04 19:12:57 2017 +0100
+++ 
b/src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor9.java 
Thu Dec 07 09:28:13 2017 -0800
@@ -33,7 +33,8 @@
  /**
   * A visitor of program elements based on their {@linkplain
   * ElementKind kind} with default behavior appropriate for the {@link
- * SourceVersion#RELEASE_9 RELEASE_9} source version.  For {@linkplain
+ * SourceVersion#RELEASE_9 RELEASE_9} and {@link
+ * SourceVersion#RELEASE_10 RELEASE_10} source versions. For {@linkplain
   * Element elements} <code><i>Xyz</i></code> that may have more than one
   * kind, the <code>visit<i>Xyz</i></code> methods in this class delegate
   * to the <code>visit<i>Xyz</i>As<i>Kind</i></code> method 
corresponding to the
@@ -77,7 +78,7 @@
   * @since 9
   * @spec JPMS
   */
- at SupportedSourceVersion(RELEASE_9)
+ at SupportedSourceVersion(RELEASE_10)
  public class ElementKindVisitor9<R, P> extends ElementKindVisitor8<R, P> {
      /**
       * Constructor for concrete subclasses; uses {@code null} for the
diff -r 56d3576aadd5 
src/java.compiler/share/classes/javax/lang/model/util/ElementScanner9.java
--- 
a/src/java.compiler/share/classes/javax/lang/model/util/ElementScanner9.java 
Mon Dec 04 19:12:57 2017 +0100
+++ 
b/src/java.compiler/share/classes/javax/lang/model/util/ElementScanner9.java 
Thu Dec 07 09:28:13 2017 -0800
@@ -34,7 +34,8 @@
  /**
   * A scanning visitor of program elements with default behavior
   * appropriate for the {@link SourceVersion#RELEASE_9 RELEASE_9}
- * source version.  The <code>visit<i>Xyz</i></code> methods in this
+ * and {@link SourceVersion#RELEASE_10 RELEASE_10} source versions.
+ * The <code>visit<i>Xyz</i></code> methods in this
   * class scan their component elements by calling {@code scan} on
   * their {@linkplain Element#getEnclosedElements enclosed elements},
   * {@linkplain ExecutableElement#getParameters parameters}, etc., as
@@ -90,7 +91,7 @@
   * @since 9
   * @spec JPMS
   */
- at SupportedSourceVersion(RELEASE_9)
+ at SupportedSourceVersion(RELEASE_10)
  public class ElementScanner9<R, P> extends ElementScanner8<R, P> {
      /**
       * Constructor for concrete subclasses; uses {@code null} for the
diff -r 56d3576aadd5 
src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor9.java
--- 
a/src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor9.java 
Mon Dec 04 19:12:57 2017 +0100
+++ 
b/src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor9.java 
Thu Dec 07 09:28:13 2017 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2011, 2014, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2011, 2017, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -32,7 +32,8 @@
  /**
   * A simple visitor for annotation values with default behavior
   * appropriate for the {@link SourceVersion#RELEASE_9 RELEASE_9}
- * source version.  Visit methods call {@link #defaultAction
+ * and {@link SourceVersion#RELEASE_10 RELEASE_10} source versions.
+ * Visit methods call {@link #defaultAction
   * defaultAction} passing their arguments to {@code defaultAction}'s
   * corresponding parameters.
   *
@@ -66,7 +67,7 @@
   * @see SimpleAnnotationValueVisitor8
   * @since 9
   */
- at SupportedSourceVersion(RELEASE_9)
+ at SupportedSourceVersion(RELEASE_10)
  public class SimpleAnnotationValueVisitor9<R, P> extends 
SimpleAnnotationValueVisitor8<R, P> {
      /**
       * Constructor for concrete subclasses; uses {@code null} for the
diff -r 56d3576aadd5 
src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor9.java
--- 
a/src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor9.java 
Mon Dec 04 19:12:57 2017 +0100
+++ 
b/src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor9.java 
Thu Dec 07 09:28:13 2017 -0800
@@ -33,7 +33,7 @@
  /**
   * A simple visitor of program elements with default behavior
   * appropriate for the {@link SourceVersion#RELEASE_9 RELEASE_9}
- * source version.
+ * and {@link SourceVersion#RELEASE_10 RELEASE_10} source versions.
   *
   * Visit methods corresponding to {@code RELEASE_9} and earlier
   * language constructs call {@link #defaultAction defaultAction},
@@ -73,7 +73,7 @@
   * @since 9
   * @spec JPMS
   */
- at SupportedSourceVersion(RELEASE_9)
+ at SupportedSourceVersion(RELEASE_10)
  public class SimpleElementVisitor9<R, P> extends 
SimpleElementVisitor8<R, P> {
      /**
       * Constructor for concrete subclasses; uses {@code null} for the
diff -r 56d3576aadd5 
src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor9.java
--- 
a/src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor9.java 
Mon Dec 04 19:12:57 2017 +0100
+++ 
b/src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor9.java 
Thu Dec 07 09:28:13 2017 -0800
@@ -32,7 +32,8 @@

  /**
   * A simple visitor of types with default behavior appropriate for the
- * {@link SourceVersion#RELEASE_9 RELEASE_9} source version.
+ * {@link SourceVersion#RELEASE_9 RELEASE_9} and
+ * {@link SourceVersion#RELEASE_10 RELEASE_10} source versions.
   *
   * Visit methods corresponding to {@code RELEASE_9} and earlier
   * language constructs call {@link #defaultAction defaultAction},
@@ -71,7 +72,7 @@
   * @see SimpleTypeVisitor7
   * @since 9
   */
- at SupportedSourceVersion(RELEASE_9)
+ at SupportedSourceVersion(RELEASE_10)
  public class SimpleTypeVisitor9<R, P> extends SimpleTypeVisitor8<R, P> {
      /**
       * Constructor for concrete subclasses; uses {@code null} for the
diff -r 56d3576aadd5 
src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor9.java
--- 
a/src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor9.java 
Mon Dec 04 19:12:57 2017 +0100
+++ 
b/src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor9.java 
Thu Dec 07 09:28:13 2017 -0800
@@ -33,7 +33,8 @@
  /**
   * A visitor of types based on their {@linkplain TypeKind kind} with
   * default behavior appropriate for the {@link SourceVersion#RELEASE_9
- * RELEASE_9} source version.  For {@linkplain
+ * RELEASE_9} and {@link SourceVersion#RELEASE_10 RELEASE_10} source
+ * versions. For {@linkplain
   * TypeMirror types} <code><i>Xyz</i></code> that may have more than one
   * kind, the <code>visit<i>Xyz</i></code> methods in this class delegate
   * to the <code>visit<i>Xyz</i>As<i>Kind</i></code> method 
corresponding to the
@@ -74,7 +75,7 @@
   * @see TypeKindVisitor8
   * @since 9
   */
- at SupportedSourceVersion(RELEASE_9)
+ at SupportedSourceVersion(RELEASE_10)
  public class TypeKindVisitor9<R, P> extends TypeKindVisitor8<R, P> {
      /**
       * Constructor for concrete subclasses to call; uses {@code null}


From jonathan.gibbons at oracle.com  Thu Dec  7 17:29:14 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 7 Dec 2017 09:29:14 -0800
Subject: JDK 10 RFR of JDK-8193191: Update JavacTestingAbstractProcessor
 for JDK 10
In-Reply-To: <d9ff6249-1f66-d093-f5c7-d24acc28c960@oracle.com>
References: <d9ff6249-1f66-d093-f5c7-d24acc28c960@oracle.com>
Message-ID: <c92ec6de-59e5-5b89-3c35-ca084419cb71@oracle.com>

+1

-- Jon


On 12/7/17 9:12 AM, joe darcy wrote:
> Hello,
>
> Please review the straightforward patch below to update the 
> JavacTestingAbstractProcessor utility superclass to JDK 10.
>
> ???? JDK-8193191: Update JavacTestingAbstractProcessor for JDK 10
>
> Besides the use of Set.of, most of the updates are just bumping 
> @SupportedSourceVersion annotation from 9 to 10.
>
> Thanks,
>
> -Joe
>
> diff -r 56d3576aadd5 
> test/langtools/tools/javac/lib/JavacTestingAbstractProcessor.java
> --- 
> a/test/langtools/tools/javac/lib/JavacTestingAbstractProcessor.java 
> Mon Dec 04 19:12:57 2017 +0100
> +++ 
> b/test/langtools/tools/javac/lib/JavacTestingAbstractProcessor.java 
> Thu Dec 07 09:04:27 2017 -0800
> @@ -1,5 +1,5 @@
> ?/*
> - * Copyright (c) 2010, 2015, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 2010, 2017, Oracle and/or its affiliates. All rights 
> reserved.
> ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> ? *
> ? * This code is free software; you can redistribute it and/or modify it
> @@ -31,13 +31,7 @@
> ? * An abstract annotation processor tailored to {@code javac} 
> regression testing.
> ? */
> ?public abstract class JavacTestingAbstractProcessor extends 
> AbstractProcessor {
> -??? private static final Set<String> allAnnotations;
> -
> -??? static {
> -??????? Set<String> tmp = new HashSet<>();
> -??????? tmp.add("*");
> -??????? allAnnotations = Collections.unmodifiableSet(tmp);
> -??? }
> +??? private static final Set<String> allAnnotations = Set.of("*");
>
> ???? protected Elements eltUtils;
> ???? protected Elements elements;
> @@ -116,7 +110,7 @@
> ????? * corresponding platform visitor type.
> ????? */
>
> -??? @SupportedSourceVersion(RELEASE_9)
> +??? @SupportedSourceVersion(RELEASE_10)
> ???? public static abstract class AbstractAnnotationValueVisitor<R, P> 
> extends AbstractAnnotationValueVisitor9<R, P> {
>
> ???????? /**
> @@ -127,7 +121,7 @@
> ???????? }
> ???? }
>
> -??? @SupportedSourceVersion(RELEASE_9)
> +??? @SupportedSourceVersion(RELEASE_10)
> ???? public static abstract class AbstractElementVisitor<R, P> extends 
> AbstractElementVisitor9<R, P> {
> ???????? /**
> ????????? * Constructor for concrete subclasses to call.
> @@ -137,7 +131,7 @@
> ???????? }
> ???? }
>
> -??? @SupportedSourceVersion(RELEASE_9)
> +??? @SupportedSourceVersion(RELEASE_10)
> ???? public static abstract class AbstractTypeVisitor<R, P> extends 
> AbstractTypeVisitor9<R, P> {
> ???????? /**
> ????????? * Constructor for concrete subclasses to call.
> @@ -147,7 +141,7 @@
> ???????? }
> ???? }
>
> -??? @SupportedSourceVersion(RELEASE_9)
> +??? @SupportedSourceVersion(RELEASE_10)
> ???? public static class ElementKindVisitor<R, P> extends 
> ElementKindVisitor9<R, P> {
> ???????? /**
> ????????? * Constructor for concrete subclasses; uses {@code null} for 
> the
> @@ -168,7 +162,7 @@
> ???????? }
> ???? }
>
> -??? @SupportedSourceVersion(RELEASE_9)
> +??? @SupportedSourceVersion(RELEASE_10)
> ???? public static class ElementScanner<R, P> extends 
> ElementScanner9<R, P> {
> ???????? /**
> ????????? * Constructor for concrete subclasses; uses {@code null} for 
> the
> @@ -187,7 +181,7 @@
> ???????? }
> ???? }
>
> -??? @SupportedSourceVersion(RELEASE_9)
> +??? @SupportedSourceVersion(RELEASE_10)
> ???? public static class SimpleAnnotationValueVisitor<R, P> extends 
> SimpleAnnotationValueVisitor9<R, P> {
> ???????? /**
> ????????? * Constructor for concrete subclasses; uses {@code null} for 
> the
> @@ -208,7 +202,7 @@
> ???????? }
> ???? }
>
> -??? @SupportedSourceVersion(RELEASE_9)
> +??? @SupportedSourceVersion(RELEASE_10)
> ???? public static class SimpleElementVisitor<R, P> extends 
> SimpleElementVisitor9<R, P> {
> ???????? /**
> ????????? * Constructor for concrete subclasses; uses {@code null} for 
> the
> @@ -229,7 +223,7 @@
> ???????? }
> ???? }
>
> -??? @SupportedSourceVersion(RELEASE_9)
> +??? @SupportedSourceVersion(RELEASE_10)
> ???? public static class SimpleTypeVisitor<R, P> extends 
> SimpleTypeVisitor9<R, P> {
> ???????? /**
> ????????? * Constructor for concrete subclasses; uses {@code null} for 
> the
> @@ -250,7 +244,7 @@
> ???????? }
> ???? }
>
> -??? @SupportedSourceVersion(RELEASE_9)
> +??? @SupportedSourceVersion(RELEASE_10)
> ???? public static class TypeKindVisitor<R, P> extends 
> TypeKindVisitor9<R, P> {
> ???????? /**
> ????????? * Constructor for concrete subclasses to call; uses {@code 
> null}
>


From jonathan.gibbons at oracle.com  Thu Dec  7 17:32:24 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 7 Dec 2017 09:32:24 -0800
Subject: JDK 10 RFR of JDK-8193194: Update javax.lang.model.util visitors
 for 10
In-Reply-To: <83025f84-5fc1-4f27-3b02-dcb31e8e2639@oracle.com>
References: <83025f84-5fc1-4f27-3b02-dcb31e8e2639@oracle.com>
Message-ID: <bb9750fe-fc64-7c28-18de-5bb393780d29@oracle.com>

+1

-- Jon


On 12/7/17 9:29 AM, joe darcy wrote:
> Hello,
>
> The javax.lang.model API was introduced in JDK 6 via JSR 269. In JDK 
> 7, 8, and 9 new sets of concrete visitors were added in the 
> javax.lang.model.util package. In JDKs 7, 8, and 9, there were new 
> language changes that required new modeling constructs. There are no 
> such changes in JDK 10. Therefore, a new set of visitors will not be 
> added for JDK 10. However, some minor updates to the JDK 9 visitors 
> should be made to indicate they cover both JDK 9 and JDK 10 constructs.
>
> Please review the patch below which implements the updates.
>
> -Joe
>
> diff -r 56d3576aadd5 
> src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor9.java
> --- 
> a/src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor9.java 
> Mon Dec 04 19:12:57 2017 +0100
> +++ 
> b/src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor9.java 
> Thu Dec 07 09:28:13 2017 -0800
> @@ -1,5 +1,5 @@
> ?/*
> - * Copyright (c) 2011, 2014, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 2011, 2017, Oracle and/or its affiliates. All rights 
> reserved.
> ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> ? *
> ? * This code is free software; you can redistribute it and/or modify it
> @@ -32,7 +32,7 @@
> ?/**
> ? * A skeletal visitor for annotation values with default behavior
> ? * appropriate for the {@link SourceVersion#RELEASE_9 RELEASE_9}
> - * source version.
> + * and {@link SourceVersion#RELEASE_10 RELEASE_10} source versions.
> ? *
> ? * <p> <b>WARNING:</b> The {@code AnnotationValueVisitor} interface
> ? * implemented by this class may have methods added to it in the
> @@ -59,7 +59,7 @@
> ? * @see AbstractAnnotationValueVisitor8
> ? * @since 9
> ? */
> - at SupportedSourceVersion(RELEASE_9)
> + at SupportedSourceVersion(RELEASE_10)
> ?public abstract class AbstractAnnotationValueVisitor9<R, P> extends 
> AbstractAnnotationValueVisitor8<R, P> {
>
> ???? /**
> diff -r 56d3576aadd5 
> src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor9.java
> --- 
> a/src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor9.java 
> Mon Dec 04 19:12:57 2017 +0100
> +++ 
> b/src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor9.java 
> Thu Dec 07 09:28:13 2017 -0800
> @@ -34,7 +34,7 @@
> ?/**
> ? * A skeletal visitor of program elements with default behavior
> ? * appropriate for the {@link SourceVersion#RELEASE_9 RELEASE_9}
> - * source version.
> + * and {@link SourceVersion#RELEASE_10 RELEASE_10} source versions.
> ? *
> ? * <p> <b>WARNING:</b> The {@code ElementVisitor} interface
> ? * implemented by this class may have methods added to it in the
> @@ -65,7 +65,7 @@
> ? * @since 9
> ? * @spec JPMS
> ? */
> - at SupportedSourceVersion(RELEASE_9)
> + at SupportedSourceVersion(RELEASE_10)
> ?public abstract class AbstractElementVisitor9<R, P> extends 
> AbstractElementVisitor8<R, P> {
> ???? /**
> ????? * Constructor for concrete subclasses to call.
> diff -r 56d3576aadd5 
> src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor9.java
> --- 
> a/src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor9.java 
> Mon Dec 04 19:12:57 2017 +0100
> +++ 
> b/src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor9.java 
> Thu Dec 07 09:28:13 2017 -0800
> @@ -1,5 +1,5 @@
> ?/*
> - * Copyright (c) 2011, 2014, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 2011, 2017, Oracle and/or its affiliates. All rights 
> reserved.
> ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> ? *
> ? * This code is free software; you can redistribute it and/or modify it
> @@ -27,13 +27,13 @@
>
> ?import javax.annotation.processing.SupportedSourceVersion;
> ?import javax.lang.model.type.*;
> -
> +import javax.lang.model.SourceVersion;
> ?import static javax.lang.model.SourceVersion.*;
>
> ?/**
> ? * A skeletal visitor of types with default behavior appropriate for
> - * the {@link javax.lang.model.SourceVersion#RELEASE_9 RELEASE_9}
> - * source version.
> + * the {@link SourceVersion#RELEASE_9 RELEASE_9}
> + * and {@link SourceVersion#RELEASE_10 RELEASE_10} source versions.
> ? *
> ? * <p> <b>WARNING:</b> The {@code TypeVisitor} interface implemented
> ? * by this class may have methods added to it in the future to
> @@ -63,7 +63,7 @@
> ? * @see AbstractTypeVisitor8
> ? * @since 9
> ? */
> - at SupportedSourceVersion(RELEASE_9)
> + at SupportedSourceVersion(RELEASE_10)
> ?public abstract class AbstractTypeVisitor9<R, P> extends 
> AbstractTypeVisitor8<R, P> {
> ???? /**
> ????? * Constructor for concrete subclasses to call.
> diff -r 56d3576aadd5 
> src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor9.java
> --- 
> a/src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor9.java 
> Mon Dec 04 19:12:57 2017 +0100
> +++ 
> b/src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor9.java 
> Thu Dec 07 09:28:13 2017 -0800
> @@ -33,7 +33,8 @@
> ?/**
> ? * A visitor of program elements based on their {@linkplain
> ? * ElementKind kind} with default behavior appropriate for the {@link
> - * SourceVersion#RELEASE_9 RELEASE_9} source version.? For {@linkplain
> + * SourceVersion#RELEASE_9 RELEASE_9} and {@link
> + * SourceVersion#RELEASE_10 RELEASE_10} source versions. For {@linkplain
> ? * Element elements} <code><i>Xyz</i></code> that may have more than one
> ? * kind, the <code>visit<i>Xyz</i></code> methods in this class delegate
> ? * to the <code>visit<i>Xyz</i>As<i>Kind</i></code> method 
> corresponding to the
> @@ -77,7 +78,7 @@
> ? * @since 9
> ? * @spec JPMS
> ? */
> - at SupportedSourceVersion(RELEASE_9)
> + at SupportedSourceVersion(RELEASE_10)
> ?public class ElementKindVisitor9<R, P> extends ElementKindVisitor8<R, 
> P> {
> ???? /**
> ????? * Constructor for concrete subclasses; uses {@code null} for the
> diff -r 56d3576aadd5 
> src/java.compiler/share/classes/javax/lang/model/util/ElementScanner9.java
> --- 
> a/src/java.compiler/share/classes/javax/lang/model/util/ElementScanner9.java 
> Mon Dec 04 19:12:57 2017 +0100
> +++ 
> b/src/java.compiler/share/classes/javax/lang/model/util/ElementScanner9.java 
> Thu Dec 07 09:28:13 2017 -0800
> @@ -34,7 +34,8 @@
> ?/**
> ? * A scanning visitor of program elements with default behavior
> ? * appropriate for the {@link SourceVersion#RELEASE_9 RELEASE_9}
> - * source version.? The <code>visit<i>Xyz</i></code> methods in this
> + * and {@link SourceVersion#RELEASE_10 RELEASE_10} source versions.
> + * The <code>visit<i>Xyz</i></code> methods in this
> ? * class scan their component elements by calling {@code scan} on
> ? * their {@linkplain Element#getEnclosedElements enclosed elements},
> ? * {@linkplain ExecutableElement#getParameters parameters}, etc., as
> @@ -90,7 +91,7 @@
> ? * @since 9
> ? * @spec JPMS
> ? */
> - at SupportedSourceVersion(RELEASE_9)
> + at SupportedSourceVersion(RELEASE_10)
> ?public class ElementScanner9<R, P> extends ElementScanner8<R, P> {
> ???? /**
> ????? * Constructor for concrete subclasses; uses {@code null} for the
> diff -r 56d3576aadd5 
> src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor9.java
> --- 
> a/src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor9.java 
> Mon Dec 04 19:12:57 2017 +0100
> +++ 
> b/src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor9.java 
> Thu Dec 07 09:28:13 2017 -0800
> @@ -1,5 +1,5 @@
> ?/*
> - * Copyright (c) 2011, 2014, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 2011, 2017, Oracle and/or its affiliates. All rights 
> reserved.
> ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> ? *
> ? * This code is free software; you can redistribute it and/or modify it
> @@ -32,7 +32,8 @@
> ?/**
> ? * A simple visitor for annotation values with default behavior
> ? * appropriate for the {@link SourceVersion#RELEASE_9 RELEASE_9}
> - * source version.? Visit methods call {@link #defaultAction
> + * and {@link SourceVersion#RELEASE_10 RELEASE_10} source versions.
> + * Visit methods call {@link #defaultAction
> ? * defaultAction} passing their arguments to {@code defaultAction}'s
> ? * corresponding parameters.
> ? *
> @@ -66,7 +67,7 @@
> ? * @see SimpleAnnotationValueVisitor8
> ? * @since 9
> ? */
> - at SupportedSourceVersion(RELEASE_9)
> + at SupportedSourceVersion(RELEASE_10)
> ?public class SimpleAnnotationValueVisitor9<R, P> extends 
> SimpleAnnotationValueVisitor8<R, P> {
> ???? /**
> ????? * Constructor for concrete subclasses; uses {@code null} for the
> diff -r 56d3576aadd5 
> src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor9.java
> --- 
> a/src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor9.java 
> Mon Dec 04 19:12:57 2017 +0100
> +++ 
> b/src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor9.java 
> Thu Dec 07 09:28:13 2017 -0800
> @@ -33,7 +33,7 @@
> ?/**
> ? * A simple visitor of program elements with default behavior
> ? * appropriate for the {@link SourceVersion#RELEASE_9 RELEASE_9}
> - * source version.
> + * and {@link SourceVersion#RELEASE_10 RELEASE_10} source versions.
> ? *
> ? * Visit methods corresponding to {@code RELEASE_9} and earlier
> ? * language constructs call {@link #defaultAction defaultAction},
> @@ -73,7 +73,7 @@
> ? * @since 9
> ? * @spec JPMS
> ? */
> - at SupportedSourceVersion(RELEASE_9)
> + at SupportedSourceVersion(RELEASE_10)
> ?public class SimpleElementVisitor9<R, P> extends 
> SimpleElementVisitor8<R, P> {
> ???? /**
> ????? * Constructor for concrete subclasses; uses {@code null} for the
> diff -r 56d3576aadd5 
> src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor9.java
> --- 
> a/src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor9.java 
> Mon Dec 04 19:12:57 2017 +0100
> +++ 
> b/src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor9.java 
> Thu Dec 07 09:28:13 2017 -0800
> @@ -32,7 +32,8 @@
>
> ?/**
> ? * A simple visitor of types with default behavior appropriate for the
> - * {@link SourceVersion#RELEASE_9 RELEASE_9} source version.
> + * {@link SourceVersion#RELEASE_9 RELEASE_9} and
> + * {@link SourceVersion#RELEASE_10 RELEASE_10} source versions.
> ? *
> ? * Visit methods corresponding to {@code RELEASE_9} and earlier
> ? * language constructs call {@link #defaultAction defaultAction},
> @@ -71,7 +72,7 @@
> ? * @see SimpleTypeVisitor7
> ? * @since 9
> ? */
> - at SupportedSourceVersion(RELEASE_9)
> + at SupportedSourceVersion(RELEASE_10)
> ?public class SimpleTypeVisitor9<R, P> extends SimpleTypeVisitor8<R, P> {
> ???? /**
> ????? * Constructor for concrete subclasses; uses {@code null} for the
> diff -r 56d3576aadd5 
> src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor9.java
> --- 
> a/src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor9.java 
> Mon Dec 04 19:12:57 2017 +0100
> +++ 
> b/src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor9.java 
> Thu Dec 07 09:28:13 2017 -0800
> @@ -33,7 +33,8 @@
> ?/**
> ? * A visitor of types based on their {@linkplain TypeKind kind} with
> ? * default behavior appropriate for the {@link SourceVersion#RELEASE_9
> - * RELEASE_9} source version.? For {@linkplain
> + * RELEASE_9} and {@link SourceVersion#RELEASE_10 RELEASE_10} source
> + * versions. For {@linkplain
> ? * TypeMirror types} <code><i>Xyz</i></code> that may have more than one
> ? * kind, the <code>visit<i>Xyz</i></code> methods in this class delegate
> ? * to the <code>visit<i>Xyz</i>As<i>Kind</i></code> method 
> corresponding to the
> @@ -74,7 +75,7 @@
> ? * @see TypeKindVisitor8
> ? * @since 9
> ? */
> - at SupportedSourceVersion(RELEASE_9)
> + at SupportedSourceVersion(RELEASE_10)
> ?public class TypeKindVisitor9<R, P> extends TypeKindVisitor8<R, P> {
> ???? /**
> ????? * Constructor for concrete subclasses to call; uses {@code null}
>


From cushon at google.com  Thu Dec  7 21:29:20 2017
From: cushon at google.com (Liam Miller-Cushon)
Date: Thu, 7 Dec 2017 13:29:20 -0800
Subject: Do package-infos need to be reset between annotation processing
 rounds?
In-Reply-To: <CAL4QsgsDqd=tS4ZeRZ72ou+4gQRzLk9S60cQBSUvso+00R2DoQ@mail.gmail.com>
References: <CAL4QsgswjOw3E5=X2B5oKARGBMRYS2a+9-1=jFMePXKh6z-9GA@mail.gmail.com>
 <5A273DEB.5060402@oracle.com>
 <CAL4QsgtTYEDtGHamouGj4JkVbZzBmEMC0ZjopYc9BEcSS8D=qA@mail.gmail.com>
 <5A275146.3080903@oracle.com>
 <CAL4QsgtmieC+a1vi9FremH3T2emMTuxqO_YLJrPq6V2T3xm1Og@mail.gmail.com>
 <7c9034fd-c538-44a0-95b6-c0b91ee71f43@oracle.com>
 <CAL4QsgsDqd=tS4ZeRZ72ou+4gQRzLk9S60cQBSUvso+00R2DoQ@mail.gmail.com>
Message-ID: <CAL4QsguXVe+1EjSt=Cvg_Gw5UhsdsRfRqaqFT-uKzBud8vMVQQ@mail.gmail.com>

The TODO in checkNameAndExistence seems relevant here. Implementing
proc.type.already.exists sounds good, but I assume it would be a warning
rather than a mandatory error? If so I think we should still improve the
handling of overwriting symbols during annotation processing with something
like the proposed fix for JDK-8193037.

I filed a bug about implementing proc.type.already.exists:
https://bugs.openjdk.java.net/browse/JDK-8193216

On Wed, Dec 6, 2017 at 1:11 AM, Liam Miller-Cushon <cushon at google.com>
wrote:

> I think the current implementation of Filer doesn't check if generated
> classes override arbitrary classes on the classpath, it only checks if they
> clash with previously generated classes, or the sources and classes that
> were explicit inputs to the compilation: http://hg.openjdk.java.net/
> jdk/jdk/file/a9405d9ca8a8/src/jdk.compiler/share/classes/
> com/sun/tools/javac/processing/JavacFiler.java#l719
>
> On Tue, Dec 5, 2017 at 11:48 PM, Jonathan Gibbons <
> jonathan.gibbons at oracle.com> wrote:
>
>> We'll need Joe "Mr Annotation Processing" Darcy to chime in here, but the
>> Filer is supposed to detect clashes, and prevent overwriting/overriding
>> symbols. That's definitely supposed to happen for normal
>> classes/interfaces; I could believe that package-info has been overlooked,
>> but I would expect it to follow the same guidelines.
>>
>> -- Jon
>>
>> On 12/5/17 6:24 PM, Liam Miller-Cushon wrote:
>>
>> Is overriding package-infos different or worse than overriding other
>> symbols? I've seen a number of examples where the same source file was
>> compiled multiple times and the earlier results ended up on the class path
>> of the later compilations, so a processor-generated class was both on the
>> class path and generated during the compilation. Making that an error would
>> be a somewhat invasive breaking change. I agree that it should be
>> discouraged, but I'm not sure it's worth making an error? (Unless there's
>> something special about package-infos that I'm missing.)
>>
>> On Tue, Dec 5, 2017 at 6:09 PM, Jonathan Gibbons <
>> jonathan.gibbons at oracle.com> wrote:
>>
>>> Generally, annotation processing is supposed to only create information
>>> where there was no information previously,  so if a package had a
>>> package-info with annotations, it seems like it should be an error to
>>> override it with another package-info, with or without annotations.
>>>
>>> -- Jon
>>>
>>>
>>> On 12/05/2017 05:39 PM, Liam Miller-Cushon wrote:
>>>
>>> Thanks! If an annotated package-info is loaded from the class path, and
>>> then a processor generates a package-info that contains no annotations, the
>>> reset is necessary. (The reset isn't necessary if the new package-info is
>>> annotated, since the old annotations get overwritten even if they weren't
>>> reset between rounds.)
>>>
>>> On Tue, Dec 5, 2017 at 4:46 PM, Jonathan Gibbons <
>>> jonathan.gibbons at oracle.com> wrote:
>>>
>>>> Liam,
>>>>
>>>> What about the case where an annotation processor generates the
>>>> package-info.java file? Is that a case where it is important to reinit the
>>>> packge symbol correctly, so that the newly generated code is read?
>>>>
>>>> -- Jon
>>>>
>>>>
>>>> On 12/05/2017 03:39 PM, Liam Miller-Cushon wrote:
>>>>
>>>>> I have a question about the logic in JavacProcessingEnvironment's
>>>>> treeCleaner that resets package-info state between annotation processing
>>>>> rounds [1].
>>>>>
>>>>> JDK-8193037 describes an issue where package-infos loaded from the
>>>>> classpath are reset by treeCleaner. Those symbols doesn't get reinitialized
>>>>> correctly, and package annotations are not visible during subsequent
>>>>> annotation processing rounds.
>>>>>
>>>>> I wondered if the logic was only meant to apply to package-infos being
>>>>> compiled from source in the current compilation (similar to how
>>>>> module-infos are handle by treeCleaner), but I'm having trouble
>>>>> understanding when that logic is necessary. Commenting out
>>>>> `node.packge.package_info.reset();` and `node.packge.reset();` in
>>>>> treeCleaner doesn't break any jtreg tests. Does anyone have examples where
>>>>> that code is needed? I'd like to add a regression test to ensure the fix
>>>>> for JDK-8193037 doesn't interfere with the original purpose of that code.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> [1] http://hg.openjdk.java.net/jdk/jdk/file/a358ebcfacfb/src/jdk
>>>>> .compiler/share/classes/com/sun/tools/javac/processing/Javac
>>>>> ProcessingEnvironment.java#l1518
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171207/f944f323/attachment-0001.html>

From jan.lahoda at oracle.com  Fri Dec  8 17:18:06 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 8 Dec 2017 18:18:06 +0100
Subject: RFR: JDK-8189782: As com.sun.tools.javac.api.JavacTool misreports
 number of arguments consumed
Message-ID: <5A2AC94E.8070506@oracle.com>

Hi,

JavaCompiler.isSupportedOption returns 1 for options like "-proc:none", 
which does not seem right. The proposed patch resolves that.

Bug: https://bugs.openjdk.java.net/browse/JDK-8189782
Webrev: http://cr.openjdk.java.net/~jlahoda/8189782/webrev.00/

How does it look?

Thanks,
    Jan

From chris.w.dennis at gmail.com  Fri Dec  8 17:34:06 2017
From: chris.w.dennis at gmail.com (Chris Dennis)
Date: Fri, 8 Dec 2017 12:34:06 -0500
Subject: Method invocation applicability rules confusion
Message-ID: <24729CCB-552C-4294-9AC4-BA0D4B7A13E1@gmail.com>

Hi All,

I?ve hit an interesting issue with an API that I am responsible for whereby the equivalent to the following does not compile:

public class TargetTypingWeirdness {

  public static void test() {
    Consumer<String> stringConsumer = System.out::println;

    f(stringConsumer, o -> o.toString());
  }

  static <T> Runnable f(Consumer<T> c, T t) {
    return () -> c.accept(t);
  }

  static <T> Consumer<Object> f(Consumer<T> c, Function<Object, T> ft) {
    return o -> c.accept(ft.apply(o));
  }
}

with:

TargetTypingWeirdness.java:9: error: reference to f is ambiguous
    f(stringConsumer, o -> o.toString());
    ^
  both method <T#1>f(Consumer<T#1>,T#1) in TargetTypingWeirdness and method <T#2>f(Consumer<T#2>,Function<Object,T#2>) in TargetTypingWeirdness match
  where T#1,T#2 are type-variables:
    T#1 extends Object declared in method <T#1>f(Consumer<T#1>,T#1)
    T#2 extends Object declared in method <T#2>f(Consumer<T#2>,Function<Object,T#2>)
TargetTypingWeirdness.java:9: error: incompatible types: cannot infer type-variable(s) T
    f(stringConsumer, o -> o.toString());
     ^
    (argument mismatch; String is not a functional interface)
  where T is a type-variable:
    T extends Object declared in method <T>f(Consumer<T>,T)
2 errors

I?m trying to figure out if this is an allowed behavior under the spec, or a bug in javac?

Any help greatly appreciated,

Chris

From jonathan.gibbons at oracle.com  Fri Dec  8 19:11:48 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 08 Dec 2017 11:11:48 -0800
Subject: RFR: JDK-8189782: As com.sun.tools.javac.api.JavacTool misreports
 number of arguments consumed
In-Reply-To: <5A2AC94E.8070506@oracle.com>
References: <5A2AC94E.8070506@oracle.com>
Message-ID: <5A2AE3F4.9080401@oracle.com>

OK.

isSupportedOption is a sad method, but the patch is in line with its 
current spec.

-- Jon

On 12/08/2017 09:18 AM, Jan Lahoda wrote:
> Hi,
>
> JavaCompiler.isSupportedOption returns 1 for options like 
> "-proc:none", which does not seem right. The proposed patch resolves 
> that.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8189782
> Webrev: http://cr.openjdk.java.net/~jlahoda/8189782/webrev.00/
>
> How does it look?
>
> Thanks,
>    Jan


From jonathan.gibbons at oracle.com  Fri Dec  8 19:17:38 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 08 Dec 2017 11:17:38 -0800
Subject: RFR: JDK-8189778: Jshell crash on tab for StringBuilder.append(
In-Reply-To: <5A285D1E.5090205@oracle.com>
References: <59F1AC72.4020202@oracle.com> <59F8A8E6.6030609@oracle.com>
 <59FB10F5.4000407@oracle.com> <5A285D1E.5090205@oracle.com>
Message-ID: <5A2AE552.9080507@oracle.com>

OK.

Long term, we should have a utility class/method somewhere, either in 
DocTrees, or in the jdk.javadoc module, to provide "official" support 
for obtaining a doc comment with `{@inheritDoc}` resolved.  One gotcha 
in that sort of code that we are becoming more aware of, is the need to 
handle inline references using `<a href="/link/">`. At least for you in 
this Shell console world, that is not such an issue.

-- Jon

On 12/06/2017 01:11 PM, Jan Lahoda wrote:
> Hi,
>
> A webrev updated to the current state and with some further fixes is 
> here:
> http://cr.openjdk.java.net/~jlahoda/8189778/webrev.02/
>
> On 2.11.2017 13:35, Kumar Srinivasan wrote:
>>
>> Hi Jan,
>>
>> Generally it looks fine to me, a few nits...
>>
>> JavadocHelper.java
>>
>> 1.
>>
>> -                        //which will be resolve in visitInheritDoc:
>> suggest....
>> +                        //which will be resolved in visitInheritDoc:
>
> Done.
>
>>
>> 2. Suggest adding a space after /** or /* makes it a little easier
>> to read the comments.
>
> Done.
>
>>
>> 3.
>>
>> - //insertPos (as future missing elements should be inserted behind
>> + //insertPos (as future missing elements should be inserted before
>
> The missing elements are inserted behind the tree that was visited by 
> the method.
>
>>
>> 4.
>> -  //if there is a newline immediatelly after this tree, insert after
>> +   //if there is a newline immediately after this tree, insert after
>
> Done. Also changed "after" to "behind".
>
>>
>> 5. Several private methods have have javadoc comments /**, do you
>> run javadoc -private on jshell sources ?
>
> Changed to comments to /*.
>
> Any feedback is welcome!
>
> Thanks,
>    Jan
>
>>
>> You may want to get Jon's review on this, he is much more familiar
>> with these things, than I.
>>
>> Thanks
>> Kumar
>>
>>> I've updated to patch to have some comments at places that seemed
>>> important:
>>> http://cr.openjdk.java.net/~jlahoda/8189778/webrev.01/
>>>
>>> Jan
>>>
>>> On 26.10.2017 11:35, Jan Lahoda wrote:
>>>> Hi,
>>>>
>>>> Typing:
>>>> jshell> StringBuilder sb = new StringBuilder();
>>>> jshell> sb.append(<tab><tab>
>>>>
>>>> Will lead to an exception:
>>>> jshell> sb.append(Exception in thread "main"
>>>> java.lang.StringIndexOutOfBoundsException: start -59, end -59, length
>>>> 238
>>>> [snip]
>>>> jdk.compiler/jdk.internal.shellsupport.doc.JavadocHelper$OnDemandJavadocHelper.getResolvedDocComment(JavadocHelper.java:481) 
>>>>
>>>>
>>>>
>>>>
>>>> The reason is that the javadoc for StringBuilder.append(CharSequence,
>>>> int, int) is:
>>>>      /**
>>>>       * @throws     IndexOutOfBoundsException {@inheritDoc}
>>>>       */
>>>>
>>>> The JavadocHelper tries to fill in the missing javadoc entries, but 
>>>> that
>>>> fails because it tries to insert the preceding entries at an
>>>> uninitialized place.
>>>>
>>>> The proposed patch:
>>>> -fixes the above
>>>> -adds a test that runs the JavadocHelper on all
>>>> methods/fields/constructors of top-level types in all exported 
>>>> packages
>>>> (this runs for a considerable time, and we may need to disable this 
>>>> test
>>>> if it proves to be too heavyweight)
>>>> -adds a few more test cases for problems found by the above test
>>>> -fixes the javadoc resolution to treat missing javadoc body as
>>>> {@inheritDoc} (so that the overridden method's javadoc text is used if
>>>> missing in this method)
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189778
>>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8189778/webrev.00/
>>>>
>>>> Feedback is welcome.
>>>>
>>>> Thanks,
>>>>      Jan
>>

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

From cushon at google.com  Fri Dec  8 19:52:43 2017
From: cushon at google.com (Liam Miller-Cushon)
Date: Fri, 8 Dec 2017 11:52:43 -0800
Subject: RFR 8193216: Filer should warn if processors redefine symbols from
 the classpath or sourcepath
Message-ID: <CAL4QsgtP0Sh4tNaS+Odk8fqOSmEfmUmtkRHcaiTAmMwPQWGKpQ@mail.gmail.com>

Hello,

Please review the following fix for JDK-8193216. The patch causes Filer to
emit a warning if an annotation processor redefines a symbol on the
classpath or sourcepath.

bug: https://bugs.openjdk.java.net/browse/JDK-8193216
webrev: http://cr.openjdk.java.net/~cushon/8193216/webrev.00/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171208/9b500317/attachment-0001.html>

From maurizio.cimadamore at oracle.com  Fri Dec  8 21:39:31 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 8 Dec 2017 21:39:31 +0000
Subject: Method invocation applicability rules confusion
In-Reply-To: <24729CCB-552C-4294-9AC4-BA0D4B7A13E1@gmail.com>
References: <24729CCB-552C-4294-9AC4-BA0D4B7A13E1@gmail.com>
Message-ID: <f2991792-d86d-26e2-5992-b76b4af43bfa@oracle.com>

This is a tricky one - I'll try to explain what's happening :-)

FIrst, let's leave lambdas on the side - this has nothing to do with it. 
And also simplify the program as follows (I've also alpha-renamed the 
type vars):

static <T> void f(Consumer<T> c, T o) { }

static <Z> void f(Consumer<Z> c, String s) { }


And consider the following invocation:

f(null, null)

Now, looking at the available signatures, one might be tempted to 
conclude that the second signature is most specific. But that's not how 
the rules in JLS 15.12.2.5 work? - those rule say that we need to do two 
applicability tests:

1) is f(Consumer<T>, T) applicable given argument types { Consumer<Z>, 
String } ?
2) is f(Consumer<Z>, String) applicable given argument types { 
Consumer<T>, T } ?

If the answer is yes to either (1) or (2), that that's the most specific 
method; if (1) and (2) are both true/false then the callsite is ambiguous.

So, let's process the two questions:

For (1) we have the following applicability tests (note that _only_ Z 
acts as an an inference variable in this test)

Consumer<T> <: Consumer<Z>
T <: String

now, no matter what we infer for Z, T<: String is always going to be 
false. So (1) is not satisfied. Let's move on to (2).

For (2) we have the following applicability tests (this time _only_ T 
acts as an inference variable)

Consumer<Z> <: Consumer<T>
String <: T

This looks more interesting. From the first constraint we derive:

Z = T

But this means that, if we incorporate bounds,

String <: T, T = Z --> String <: Z

Which is, again, false.

So, unfortunately, both applicability tests (1) and (2) fails, so 
neither method is more specific. Hence the ambiguity error.

Cheers
Maurizio




On 08/12/17 17:34, Chris Dennis wrote:
> Hi All,
>
> I?ve hit an interesting issue with an API that I am responsible for whereby the equivalent to the following does not compile:
>
> public class TargetTypingWeirdness {
>
>    public static void test() {
>      Consumer<String> stringConsumer = System.out::println;
>
>      f(stringConsumer, o -> o.toString());
>    }
>
>    static <T> Runnable f(Consumer<T> c, T t) {
>      return () -> c.accept(t);
>    }
>
>    static <T> Consumer<Object> f(Consumer<T> c, Function<Object, T> ft) {
>      return o -> c.accept(ft.apply(o));
>    }
> }
>
> with:
>
> TargetTypingWeirdness.java:9: error: reference to f is ambiguous
>      f(stringConsumer, o -> o.toString());
>      ^
>    both method <T#1>f(Consumer<T#1>,T#1) in TargetTypingWeirdness and method <T#2>f(Consumer<T#2>,Function<Object,T#2>) in TargetTypingWeirdness match
>    where T#1,T#2 are type-variables:
>      T#1 extends Object declared in method <T#1>f(Consumer<T#1>,T#1)
>      T#2 extends Object declared in method <T#2>f(Consumer<T#2>,Function<Object,T#2>)
> TargetTypingWeirdness.java:9: error: incompatible types: cannot infer type-variable(s) T
>      f(stringConsumer, o -> o.toString());
>       ^
>      (argument mismatch; String is not a functional interface)
>    where T is a type-variable:
>      T extends Object declared in method <T>f(Consumer<T>,T)
> 2 errors
>
> I?m trying to figure out if this is an allowed behavior under the spec, or a bug in javac?
>
> Any help greatly appreciated,
>
> Chris


From chris.w.dennis at gmail.com  Mon Dec 11 14:59:06 2017
From: chris.w.dennis at gmail.com (Chris Dennis)
Date: Mon, 11 Dec 2017 09:59:06 -0500
Subject: Method invocation applicability rules confusion
In-Reply-To: <f2991792-d86d-26e2-5992-b76b4af43bfa@oracle.com>
References: <24729CCB-552C-4294-9AC4-BA0D4B7A13E1@gmail.com>
 <f2991792-d86d-26e2-5992-b76b4af43bfa@oracle.com>
Message-ID: <C46752CD-A797-46B0-B76B-ABFF12B7D1BC@gmail.com>

Forgive me, it?s too long since I was at university, and then I was a physicist, so I just pretended to be good at mathematics/computer science. My intuitive understanding says that f(Consumer<T>, T>) shouldn't be considered applicable given the argument types (as per 15.12.2.3 https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.12.2.3 <https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.12.2.3>).  I?ve tried (and will continue to try) to work through the logic of that section and the accompanying details in Chapter 18, but if you could confirm that it is applicable then that would be great (at least then I?d know that what I?m doing is an academic exercise, and that I should end up proving the method is applicable).

Thanks,

Chris


> On Dec 8, 2017, at 4:39 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> This is a tricky one - I'll try to explain what's happening :-)
> 
> FIrst, let's leave lambdas on the side - this has nothing to do with it. And also simplify the program as follows (I've also alpha-renamed the type vars):
> 
> static <T> void f(Consumer<T> c, T o) { }
> 
> static <Z> void f(Consumer<Z> c, String s) { }
> 
> 
> And consider the following invocation:
> 
> f(null, null)
> 
> Now, looking at the available signatures, one might be tempted to conclude that the second signature is most specific. But that's not how the rules in JLS 15.12.2.5 work  - those rule say that we need to do two applicability tests:
> 
> 1) is f(Consumer<T>, T) applicable given argument types { Consumer<Z>, String } ?
> 2) is f(Consumer<Z>, String) applicable given argument types { Consumer<T>, T } ?
> 
> If the answer is yes to either (1) or (2), that that's the most specific method; if (1) and (2) are both true/false then the callsite is ambiguous.
> 
> So, let's process the two questions:
> 
> For (1) we have the following applicability tests (note that _only_ Z acts as an an inference variable in this test)
> 
> Consumer<T> <: Consumer<Z>
> T <: String
> 
> now, no matter what we infer for Z, T<: String is always going to be false. So (1) is not satisfied. Let's move on to (2).
> 
> For (2) we have the following applicability tests (this time _only_ T acts as an inference variable)
> 
> Consumer<Z> <: Consumer<T>
> String <: T
> 
> This looks more interesting. From the first constraint we derive:
> 
> Z = T
> 
> But this means that, if we incorporate bounds,
> 
> String <: T, T = Z --> String <: Z
> 
> Which is, again, false.
> 
> So, unfortunately, both applicability tests (1) and (2) fails, so neither method is more specific. Hence the ambiguity error.
> 
> Cheers
> Maurizio
> 
> 
> 
> 
> On 08/12/17 17:34, Chris Dennis wrote:
>> Hi All,
>> 
>> I?ve hit an interesting issue with an API that I am responsible for whereby the equivalent to the following does not compile:
>> 
>> public class TargetTypingWeirdness {
>> 
>>   public static void test() {
>>     Consumer<String> stringConsumer = System.out::println;
>> 
>>     f(stringConsumer, o -> o.toString());
>>   }
>> 
>>   static <T> Runnable f(Consumer<T> c, T t) {
>>     return () -> c.accept(t);
>>   }
>> 
>>   static <T> Consumer<Object> f(Consumer<T> c, Function<Object, T> ft) {
>>     return o -> c.accept(ft.apply(o));
>>   }
>> }
>> 
>> with:
>> 
>> TargetTypingWeirdness.java:9: error: reference to f is ambiguous
>>     f(stringConsumer, o -> o.toString());
>>     ^
>>   both method <T#1>f(Consumer<T#1>,T#1) in TargetTypingWeirdness and method <T#2>f(Consumer<T#2>,Function<Object,T#2>) in TargetTypingWeirdness match
>>   where T#1,T#2 are type-variables:
>>     T#1 extends Object declared in method <T#1>f(Consumer<T#1>,T#1)
>>     T#2 extends Object declared in method <T#2>f(Consumer<T#2>,Function<Object,T#2>)
>> TargetTypingWeirdness.java:9: error: incompatible types: cannot infer type-variable(s) T
>>     f(stringConsumer, o -> o.toString());
>>      ^
>>     (argument mismatch; String is not a functional interface)
>>   where T is a type-variable:
>>     T extends Object declared in method <T>f(Consumer<T>,T)
>> 2 errors
>> 
>> I?m trying to figure out if this is an allowed behavior under the spec, or a bug in javac?
>> 
>> Any help greatly appreciated,
>> 
>> Chris
> 

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

From maurizio.cimadamore at oracle.com  Mon Dec 11 16:26:59 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 11 Dec 2017 16:26:59 +0000
Subject: Method invocation applicability rules confusion
In-Reply-To: <C46752CD-A797-46B0-B76B-ABFF12B7D1BC@gmail.com>
References: <24729CCB-552C-4294-9AC4-BA0D4B7A13E1@gmail.com>
 <f2991792-d86d-26e2-5992-b76b4af43bfa@oracle.com>
 <C46752CD-A797-46B0-B76B-ABFF12B7D1BC@gmail.com>
Message-ID: <90d6a14d-166e-5bfb-33fd-56fc8f4224bb@oracle.com>

Note that in your original example your second argument is:

o -> o.toString()

Whenever you have a lambda (implicit, or explicit) and the target type 
is some inference variable (like T in this case), the lambda is always 
considered potentially applicable (as per 15.12.2.1).

Then, since this is an implicit lambda - implicit lambda don't do much 
in terms of ruling out applicable candidates. This is called pertinence 
to applicability - see 15.12.2.2. An implicit lambda is NOT pertinent to 
applicability, so it doesn't contribute to overload resolution.

Hence, both methods in your example are applicable.

Maurizio


On 11/12/17 14:59, Chris Dennis wrote:
> Forgive me, it?s too long since I was at university, and then I was a 
> physicist, so I just pretended to be good at mathematics/computer 
> science. My intuitive understanding says that f(Consumer<T>, T>) 
> shouldn't be considered applicable given the argument types (as per 
> 15.12.2.3 
> https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.12.2.3). 
> ?I?ve tried (and will continue to try) to work through the logic of 
> that section and the accompanying details in Chapter 18, but if you 
> could confirm that it is applicable then that would be great (at least 
> then I?d know that what I?m doing is an academic exercise, and that I 
> should end up proving the method is applicable).
>
> Thanks,
>
> Chris
>
>
>> On Dec 8, 2017, at 4:39 PM, Maurizio Cimadamore 
>> <maurizio.cimadamore at oracle.com 
>> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>>
>> This is a tricky one - I'll try to explain what's happening :-)
>>
>> FIrst, let's leave lambdas on the side - this has nothing to do with 
>> it. And also simplify the program as follows (I've also alpha-renamed 
>> the type vars):
>>
>> static <T> void f(Consumer<T> c, T o) { }
>>
>> static <Z> void f(Consumer<Z> c, String s) { }
>>
>>
>> And consider the following invocation:
>>
>> f(null, null)
>>
>> Now, looking at the available signatures, one might be tempted to 
>> conclude that the second signature is most specific. But that's not 
>> how the rules in JLS 15.12.2.5 work? - those rule say that we need to 
>> do two applicability tests:
>>
>> 1) is f(Consumer<T>, T) applicable given argument types { 
>> Consumer<Z>, String } ?
>> 2) is f(Consumer<Z>, String) applicable given argument types { 
>> Consumer<T>, T } ?
>>
>> If the answer is yes to either (1) or (2), that that's the most 
>> specific method; if (1) and (2) are both true/false then the callsite 
>> is ambiguous.
>>
>> So, let's process the two questions:
>>
>> For (1) we have the following applicability tests (note that _only_ Z 
>> acts as an an inference variable in this test)
>>
>> Consumer<T> <: Consumer<Z>
>> T <: String
>>
>> now, no matter what we infer for Z, T<: String is always going to be 
>> false. So (1) is not satisfied. Let's move on to (2).
>>
>> For (2) we have the following applicability tests (this time _only_ T 
>> acts as an inference variable)
>>
>> Consumer<Z> <: Consumer<T>
>> String <: T
>>
>> This looks more interesting. From the first constraint we derive:
>>
>> Z = T
>>
>> But this means that, if we incorporate bounds,
>>
>> String <: T, T = Z --> String <: Z
>>
>> Which is, again, false.
>>
>> So, unfortunately, both applicability tests (1) and (2) fails, so 
>> neither method is more specific. Hence the ambiguity error.
>>
>> Cheers
>> Maurizio
>>
>>
>>
>>
>> On 08/12/17 17:34, Chris Dennis wrote:
>>> Hi All,
>>>
>>> I?ve hit an interesting issue with an API that I am responsible for 
>>> whereby the equivalent to the following does not compile:
>>>
>>> public class TargetTypingWeirdness {
>>>
>>> ??public static void test() {
>>> ????Consumer<String> stringConsumer = System.out::println;
>>>
>>> ????f(stringConsumer, o -> o.toString());
>>> ??}
>>>
>>> ??static <T> Runnable f(Consumer<T> c, T t) {
>>> ????return () -> c.accept(t);
>>> ??}
>>>
>>> ??static <T> Consumer<Object> f(Consumer<T> c, Function<Object, T> ft) {
>>> ????return o -> c.accept(ft.apply(o));
>>> ??}
>>> }
>>>
>>> with:
>>>
>>> TargetTypingWeirdness.java:9: error: reference to f is ambiguous
>>> ????f(stringConsumer, o -> o.toString());
>>> ????^
>>> ??both method <T#1>f(Consumer<T#1>,T#1) in TargetTypingWeirdness and 
>>> method <T#2>f(Consumer<T#2>,Function<Object,T#2>) in 
>>> TargetTypingWeirdness match
>>> ??where T#1,T#2 are type-variables:
>>> ????T#1 extends Object declared in method <T#1>f(Consumer<T#1>,T#1)
>>> ????T#2 extends Object declared in method 
>>> <T#2>f(Consumer<T#2>,Function<Object,T#2>)
>>> TargetTypingWeirdness.java:9: error: incompatible types: cannot 
>>> infer type-variable(s) T
>>> ????f(stringConsumer, o -> o.toString());
>>> ?????^
>>> ????(argument mismatch; String is not a functional interface)
>>> ??where T is a type-variable:
>>> ????T extends Object declared in method <T>f(Consumer<T>,T)
>>> 2 errors
>>>
>>> I?m trying to figure out if this is an allowed behavior under the 
>>> spec, or a bug in javac?
>>>
>>> Any help greatly appreciated,
>>>
>>> Chris
>>
>

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

From Alan.Bateman at oracle.com  Mon Dec 11 16:52:38 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 11 Dec 2017 16:52:38 +0000
Subject: FW: RFR(M): 8189102: All tools should support -?, -h and --help
In-Reply-To: <456c694ec25a42658af1b8600aaa136d@sap.com>
References: <c27028f9f5844c3c818885f88c75f84b@sap.com>
 <8aa25976d496465fac00a4ae3628e533@sap.com>
 <456c694ec25a42658af1b8600aaa136d@sap.com>
Message-ID: <6d7d895f-9f23-fd4b-39ca-ef9bb0331fb9@oracle.com>



On 07/12/2017 11:20, Lindenmaier, Goetz wrote:
> Hi,
>
> ... missed some lists in my first post ...
>
> I prepared a fifth webrev for this change.  Please review.
>
> It incorporates the changes requested by the CSR reviewers
> (not to remove docuemtation of '-help' where is was documented
> before) and the changes proposed by Kumar:
> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.05/
>
>
Looks like it still drops -help from the javadoc usage message, I can't 
tell if you meant to do that.

-Alan.

From chris.w.dennis at gmail.com  Mon Dec 11 19:11:13 2017
From: chris.w.dennis at gmail.com (Chris Dennis)
Date: Mon, 11 Dec 2017 14:11:13 -0500
Subject: Method invocation applicability rules confusion
In-Reply-To: <90d6a14d-166e-5bfb-33fd-56fc8f4224bb@oracle.com>
References: <24729CCB-552C-4294-9AC4-BA0D4B7A13E1@gmail.com>
 <f2991792-d86d-26e2-5992-b76b4af43bfa@oracle.com>
 <C46752CD-A797-46B0-B76B-ABFF12B7D1BC@gmail.com>
 <90d6a14d-166e-5bfb-33fd-56fc8f4224bb@oracle.com>
Message-ID: <4B72017E-FC8E-498F-9045-3240C0706EAE@gmail.com>

Thank you, I now understand whats going on, I just don?t like it that much.

C?est la vie,

Chris

> On Dec 11, 2017, at 11:26 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> Note that in your original example your second argument is:
> 
> o -> o.toString()
> 
> Whenever you have a lambda (implicit, or explicit) and the target type is some inference variable (like T in this case), the lambda is always considered potentially applicable (as per 15.12.2.1).
> 
> Then, since this is an implicit lambda - implicit lambda don't do much in terms of ruling out applicable candidates. This is called pertinence to applicability - see 15.12.2.2. An implicit lambda is NOT pertinent to applicability, so it doesn't contribute to overload resolution.
> 
> Hence, both methods in your example are applicable.
> 
> Maurizio
> 
> 
> On 11/12/17 14:59, Chris Dennis wrote:
>> Forgive me, it?s too long since I was at university, and then I was a physicist, so I just pretended to be good at mathematics/computer science. My intuitive understanding says that f(Consumer<T>, T>) shouldn't be considered applicable given the argument types (as per 15.12.2.3 https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.12.2.3 <https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.12.2.3>).  I?ve tried (and will continue to try) to work through the logic of that section and the accompanying details in Chapter 18, but if you could confirm that it is applicable then that would be great (at least then I?d know that what I?m doing is an academic exercise, and that I should end up proving the method is applicable).
>> 
>> Thanks,
>> 
>> Chris
>> 
>> 
>>> On Dec 8, 2017, at 4:39 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com <mailto:maurizio.cimadamore at oracle.com>> wrote:
>>> 
>>> This is a tricky one - I'll try to explain what's happening :-)
>>> 
>>> FIrst, let's leave lambdas on the side - this has nothing to do with it. And also simplify the program as follows (I've also alpha-renamed the type vars):
>>> 
>>> static <T> void f(Consumer<T> c, T o) { }
>>> 
>>> static <Z> void f(Consumer<Z> c, String s) { }
>>> 
>>> 
>>> And consider the following invocation:
>>> 
>>> f(null, null)
>>> 
>>> Now, looking at the available signatures, one might be tempted to conclude that the second signature is most specific. But that's not how the rules in JLS 15.12.2.5 work  - those rule say that we need to do two applicability tests:
>>> 
>>> 1) is f(Consumer<T>, T) applicable given argument types { Consumer<Z>, String } ?
>>> 2) is f(Consumer<Z>, String) applicable given argument types { Consumer<T>, T } ?
>>> 
>>> If the answer is yes to either (1) or (2), that that's the most specific method; if (1) and (2) are both true/false then the callsite is ambiguous.
>>> 
>>> So, let's process the two questions:
>>> 
>>> For (1) we have the following applicability tests (note that _only_ Z acts as an an inference variable in this test)
>>> 
>>> Consumer<T> <: Consumer<Z>
>>> T <: String
>>> 
>>> now, no matter what we infer for Z, T<: String is always going to be false. So (1) is not satisfied. Let's move on to (2).
>>> 
>>> For (2) we have the following applicability tests (this time _only_ T acts as an inference variable)
>>> 
>>> Consumer<Z> <: Consumer<T>
>>> String <: T
>>> 
>>> This looks more interesting. From the first constraint we derive:
>>> 
>>> Z = T
>>> 
>>> But this means that, if we incorporate bounds,
>>> 
>>> String <: T, T = Z --> String <: Z
>>> 
>>> Which is, again, false.
>>> 
>>> So, unfortunately, both applicability tests (1) and (2) fails, so neither method is more specific. Hence the ambiguity error.
>>> 
>>> Cheers
>>> Maurizio
>>> 
>>> 
>>> 
>>> 
>>> On 08/12/17 17:34, Chris Dennis wrote:
>>>> Hi All,
>>>> 
>>>> I?ve hit an interesting issue with an API that I am responsible for whereby the equivalent to the following does not compile:
>>>> 
>>>> public class TargetTypingWeirdness {
>>>> 
>>>>   public static void test() {
>>>>     Consumer<String> stringConsumer = System.out::println;
>>>> 
>>>>     f(stringConsumer, o -> o.toString());
>>>>   }
>>>> 
>>>>   static <T> Runnable f(Consumer<T> c, T t) {
>>>>     return () -> c.accept(t);
>>>>   }
>>>> 
>>>>   static <T> Consumer<Object> f(Consumer<T> c, Function<Object, T> ft) {
>>>>     return o -> c.accept(ft.apply(o));
>>>>   }
>>>> }
>>>> 
>>>> with:
>>>> 
>>>> TargetTypingWeirdness.java:9: error: reference to f is ambiguous
>>>>     f(stringConsumer, o -> o.toString());
>>>>     ^
>>>>   both method <T#1>f(Consumer<T#1>,T#1) in TargetTypingWeirdness and method <T#2>f(Consumer<T#2>,Function<Object,T#2>) in TargetTypingWeirdness match
>>>>   where T#1,T#2 are type-variables:
>>>>     T#1 extends Object declared in method <T#1>f(Consumer<T#1>,T#1)
>>>>     T#2 extends Object declared in method <T#2>f(Consumer<T#2>,Function<Object,T#2>)
>>>> TargetTypingWeirdness.java:9: error: incompatible types: cannot infer type-variable(s) T
>>>>     f(stringConsumer, o -> o.toString());
>>>>      ^
>>>>     (argument mismatch; String is not a functional interface)
>>>>   where T is a type-variable:
>>>>     T extends Object declared in method <T>f(Consumer<T>,T)
>>>> 2 errors
>>>> 
>>>> I?m trying to figure out if this is an allowed behavior under the spec, or a bug in javac?
>>>> 
>>>> Any help greatly appreciated,
>>>> 
>>>> Chris
>>> 
>> 
> 

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

From joe.darcy at oracle.com  Tue Dec 12 07:04:40 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 11 Dec 2017 23:04:40 -0800
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to
 javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
Message-ID: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>

Hello,

With the JDK 11 line of development opening up in a few days, a few 
changes are needed to prepared to turn a JDK 10 code base into a JDK 11 
one including:

     JDK-8173382: Add -source 11 and -target 11 to javac
     JDK-8193291: Add SourceVersion.RELEASE_11

     Webev:
         http://cr.openjdk.java.net/~darcy/8173382.1/
     CSRs:
         JDK-8193350: Add -source 11 and -target 11 to javac
         JDK-8193351: Add SourceVersion.RELEASE_11

Please review the preliminary webrev and CSRs.

Note that breaking with previous contentions, the current iteration of 
the change does *not* add -source/-target "1.11" as an alias for "11". 
Only "11" is recognized.

I didn't see how to add support for an "11" value for "--release" so I 
problem listed two tests until that is sorted out.

The build is simultaneously updated to user -source/-target 11, hence 
the inclusion of build-dev.

Various langtools tests and test infrastructure is updated too.

Thanks,

-Joe


From goetz.lindenmaier at sap.com  Tue Dec 12 10:36:51 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 12 Dec 2017 10:36:51 +0000
Subject: FW: RFR(M): 8189102: All tools should support -?, -h and --help
In-Reply-To: <6d7d895f-9f23-fd4b-39ca-ef9bb0331fb9@oracle.com>
References: <c27028f9f5844c3c818885f88c75f84b@sap.com>
 <8aa25976d496465fac00a4ae3628e533@sap.com>
 <456c694ec25a42658af1b8600aaa136d@sap.com>
 <6d7d895f-9f23-fd4b-39ca-ef9bb0331fb9@oracle.com>
Message-ID: <7be3772e8060494cbecf3097bd0a8a85@sap.com>

Hi Alan,

Javadoc combines documentation and support of a flag in the
way the flag handling is implemented.  On the other side, 
it prints the help message anyways if a wrong flag is presented 
to it, so if you call it with -help you get the help message.
Therefore, in my original change where I tried to get it 
more cleaned up, I removed -help support and documentation 
from Javadoc.

I added it again and updated the table in the CSR:
http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.06/

Best regards,
  Goetz.

> -----Original Message-----
> From: Alan Bateman [mailto:Alan.Bateman at oracle.com]
> Sent: Montag, 11. Dezember 2017 17:53
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; core-libs-
> dev at openjdk.java.net; 'compiler-dev at openjdk.java.net' <compiler-
> dev at openjdk.java.net>; serviceability-dev (serviceability-
> dev at openjdk.java.net) <serviceability-dev at openjdk.java.net>
> Subject: Re: FW: RFR(M): 8189102: All tools should support -?, -h and --help
> 
> 
> 
> On 07/12/2017 11:20, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > ... missed some lists in my first post ...
> >
> > I prepared a fifth webrev for this change.  Please review.
> >
> > It incorporates the changes requested by the CSR reviewers
> > (not to remove docuemtation of '-help' where is was documented
> > before) and the changes proposed by Kumar:
> > http://cr.openjdk.java.net/~goetz/wr17/8189102-
> helpMessage/webrev.05/
> >
> >
> Looks like it still drops -help from the javadoc usage message, I can't
> tell if you meant to do that.
> 
> -Alan.

From erik.joelsson at oracle.com  Tue Dec 12 15:36:11 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 12 Dec 2017 16:36:11 +0100
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
Message-ID: <5cc0a0e6-e2a5-5232-1070-50944acc0237@oracle.com>

Build change looks good.

/Erik


On 2017-12-12 08:04, joe darcy wrote:
> Hello,
>
> With the JDK 11 line of development opening up in a few days, a few 
> changes are needed to prepared to turn a JDK 10 code base into a JDK 
> 11 one including:
>
> ??? JDK-8173382: Add -source 11 and -target 11 to javac
> ??? JDK-8193291: Add SourceVersion.RELEASE_11
>
> ??? Webev:
> ??????? http://cr.openjdk.java.net/~darcy/8173382.1/
> ??? CSRs:
> ??????? JDK-8193350: Add -source 11 and -target 11 to javac
> ??????? JDK-8193351: Add SourceVersion.RELEASE_11
>
> Please review the preliminary webrev and CSRs.
>
> Note that breaking with previous contentions, the current iteration of 
> the change does *not* add -source/-target "1.11" as an alias for "11". 
> Only "11" is recognized.
>
> I didn't see how to add support for an "11" value for "--release" so I 
> problem listed two tests until that is sorted out.
>
> The build is simultaneously updated to user -source/-target 11, hence 
> the inclusion of build-dev.
>
> Various langtools tests and test infrastructure is updated too.
>
> Thanks,
>
> -Joe
>


From paul.sandoz at oracle.com  Tue Dec 12 17:31:58 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 12 Dec 2017 09:31:58 -0800
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
Message-ID: <AB970BFA-B7C2-4945-8865-23C6FC3EF371@oracle.com>

Hi Joe,

I would like to see the class file version increment [*] in the same patch (the unified repo makes this easier now).

Then we have everything in one changeset (except for any ctsym changes?) that can be easily templated when the next increment is required, since we will be doing this far more regularly from now on.

Are there any technical impediments as to why this would be problematic?

Thanks,
Paul.

[*] here is the increment to 54 http://hg.openjdk.java.net/jdk/jdk/rev/89829dd3cc54 <http://hg.openjdk.java.net/jdk/jdk/rev/89829dd3cc54>

> On 11 Dec 2017, at 23:04, joe darcy <joe.darcy at oracle.com> wrote:
> 
> Hello,
> 
> With the JDK 11 line of development opening up in a few days, a few changes are needed to prepared to turn a JDK 10 code base into a JDK 11 one including:
> 
>    JDK-8173382: Add -source 11 and -target 11 to javac
>    JDK-8193291: Add SourceVersion.RELEASE_11
> 
>    Webev:
>        http://cr.openjdk.java.net/~darcy/8173382.1/
>    CSRs:
>        JDK-8193350: Add -source 11 and -target 11 to javac
>        JDK-8193351: Add SourceVersion.RELEASE_11
> 
> Please review the preliminary webrev and CSRs.
> 
> Note that breaking with previous contentions, the current iteration of the change does *not* add -source/-target "1.11" as an alias for "11". Only "11" is recognized.
> 
> I didn't see how to add support for an "11" value for "--release" so I problem listed two tests until that is sorted out.
> 
> The build is simultaneously updated to user -source/-target 11, hence the inclusion of build-dev.
> 
> Various langtools tests and test infrastructure is updated too.
> 
> Thanks,
> 
> -Joe
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171212/adc8f6c5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 873 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171212/adc8f6c5/signature.asc>

From joe.darcy at oracle.com  Tue Dec 12 17:52:08 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Tue, 12 Dec 2017 09:52:08 -0800
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <AB970BFA-B7C2-4945-8865-23C6FC3EF371@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <AB970BFA-B7C2-4945-8865-23C6FC3EF371@oracle.com>
Message-ID: <48fdaf67-bf68-2701-8951-753699029bf4@oracle.com>

Hi Paul,

There is sense in working in including the class file version update at 
the same time if the added complexity doesn't delay the changes.

Did the patch for the increment to 54 require previous changes in the 
bundled ASM?

Thanks,

-Joe


On 12/12/2017 9:31 AM, Paul Sandoz wrote:
> Hi Joe,
>
> I would like to see the class file version increment [*] in the same 
> patch (the unified repo makes this easier now).
>
> Then we have everything in one changeset (except for any ctsym 
> changes?) that can be easily templated when the next increment is 
> required, since we will be doing this far more regularly from now on.
>
> Are there any technical impediments as to why this would be problematic?
>
> Thanks,
> Paul.
>
> [*] here is the increment to 54 
> http://hg.openjdk.java.net/jdk/jdk/rev/89829dd3cc54
>


From paul.sandoz at oracle.com  Tue Dec 12 18:03:31 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 12 Dec 2017 10:03:31 -0800
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <48fdaf67-bf68-2701-8951-753699029bf4@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <AB970BFA-B7C2-4945-8865-23C6FC3EF371@oracle.com>
 <48fdaf67-bf68-2701-8951-753699029bf4@oracle.com>
Message-ID: <95C47796-7ED5-4855-95E4-85724A73143A@oracle.com>



> On 12 Dec 2017, at 09:52, joe darcy <joe.darcy at oracle.com> wrote:
> 
> Hi Paul,
> 
> There is sense in working in including the class file version update at the same time if the added complexity doesn't delay the changes.
> 

I sense it should be so complex and delay since the additional code changes can be copied from the prior changes which recently went through significant review.

If it helps, and since i am proposing additional work, i can merge in such changes into your patch.


> Did the patch for the increment to 54 require previous changes in the bundled ASM?
> 

The increment in and of itself requires only minimal changes to the internal ASM, it does not require the integration of a new version of ASM.  Constant dynamic only requires a minimal update to the internal ASM to skip over the new constant pool entry, since we don?t currently use ASM process or generate constant dynamic entries.

Paul.


> Thanks,
> 
> -Joe
> 
> 
> On 12/12/2017 9:31 AM, Paul Sandoz wrote:
>> Hi Joe,
>> 
>> I would like to see the class file version increment [*] in the same patch (the unified repo makes this easier now).
>> 
>> Then we have everything in one changeset (except for any ctsym changes?) that can be easily templated when the next increment is required, since we will be doing this far more regularly from now on.
>> 
>> Are there any technical impediments as to why this would be problematic?
>> 
>> Thanks,
>> Paul.
>> 
>> [*] here is the increment to 54 http://hg.openjdk.java.net/jdk/jdk/rev/89829dd3cc54
>> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 873 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171212/90a7f191/signature.asc>

From paul.sandoz at oracle.com  Tue Dec 12 18:17:46 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 12 Dec 2017 10:17:46 -0800
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <95C47796-7ED5-4855-95E4-85724A73143A@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <AB970BFA-B7C2-4945-8865-23C6FC3EF371@oracle.com>
 <48fdaf67-bf68-2701-8951-753699029bf4@oracle.com>
 <95C47796-7ED5-4855-95E4-85724A73143A@oracle.com>
Message-ID: <F2DD98DC-AA25-42B2-B094-3E374086BC68@oracle.com>



> On 12 Dec 2017, at 10:03, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:
> 
> 
> 
>> On 12 Dec 2017, at 09:52, joe darcy <joe.darcy at oracle.com> wrote:
>> 
>> Hi Paul,
>> 
>> There is sense in working in including the class file version update at the same time if the added complexity doesn't delay the changes.
>> 
> 
> I sense it should be so complex and delay since the additional code changes can be copied from the prior changes which recently went through significant review.

"I sense it should *not* be??

Paul.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 873 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171212/f6e69188/signature-0001.asc>

From david.holmes at oracle.com  Tue Dec 12 21:11:06 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 13 Dec 2017 07:11:06 +1000
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
Message-ID: <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com>

Hi Joe,

On 12/12/2017 5:04 PM, joe darcy wrote:
> Hello,
> 
> With the JDK 11 line of development opening up in a few days, a few 
> changes are needed to prepared to turn a JDK 10 code base into a JDK 11 
> one including:
> 
>  ??? JDK-8173382: Add -source 11 and -target 11 to javac
>  ??? JDK-8193291: Add SourceVersion.RELEASE_11
> 
>  ??? Webev:
>  ??????? http://cr.openjdk.java.net/~darcy/8173382.1/
>  ??? CSRs:
>  ??????? JDK-8193350: Add -source 11 and -target 11 to javac
>  ??????? JDK-8193351: Add SourceVersion.RELEASE_11
> 
> Please review the preliminary webrev and CSRs.

I don't see a change to the actual JDK version as part of this ?? hat's 
the change that will cause hotspot to fail to build in debug mode as 
soon as the version is bumped - I filed:

https://bugs.openjdk.java.net/browse/JDK-8193364

to at least get over that.

> Note that breaking with previous contentions, the current iteration of 
> the change does *not* add -source/-target "1.11" as an alias for "11". 
> Only "11" is recognized.
> 
> I didn't see how to add support for an "11" value for "--release" so I 
> problem listed two tests until that is sorted out.

Okay. It's very hard to discern what uses of "RELEASE_11" pertain to 
"-release" support and what just pertain to -source/-target. ??

> The build is simultaneously updated to user -source/-target 11, hence 
> the inclusion of build-dev.
> 
> Various langtools tests and test infrastructure is updated too.

test/langtools/tools/javac/versions/Versions.java looks like it needed 
some updates for JDK 10!

Thanks,
David

> 
> Thanks,
> 
> -Joe
> 

From joe.darcy at oracle.com  Tue Dec 12 21:27:06 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Tue, 12 Dec 2017 13:27:06 -0800
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com>
Message-ID: <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com>

Hi David,


On 12/12/2017 1:11 PM, David Holmes wrote:
> Hi Joe,
>
> On 12/12/2017 5:04 PM, joe darcy wrote:
>> Hello,
>>
>> With the JDK 11 line of development opening up in a few days, a few 
>> changes are needed to prepared to turn a JDK 10 code base into a JDK 
>> 11 one including:
>>
>>      JDK-8173382: Add -source 11 and -target 11 to javac
>>      JDK-8193291: Add SourceVersion.RELEASE_11
>>
>>      Webev:
>>          http://cr.openjdk.java.net/~darcy/8173382.1/
>>      CSRs:
>>          JDK-8193350: Add -source 11 and -target 11 to javac
>>          JDK-8193351: Add SourceVersion.RELEASE_11
>>
>> Please review the preliminary webrev and CSRs.
>
> I don't see a change to the actual JDK version as part of this ?? 

Correct; the webrev to date is the langtools portion of the new JDK 
groundbreaking, the same subset of groundbreaking I looked at for the 9 
-> 10 transition. Other pieces are needed too, including HotSpot changes 
and the actual version update.

> hat's the change that will cause hotspot to fail to build in debug 
> mode as soon as the version is bumped - I filed:
>
> https://bugs.openjdk.java.net/browse/JDK-8193364
>
> to at least get over that.
>
>> Note that breaking with previous contentions, the current iteration 
>> of the change does *not* add -source/-target "1.11" as an alias for 
>> "11". Only "11" is recognized.
>>
>> I didn't see how to add support for an "11" value for "--release" so 
>> I problem listed two tests until that is sorted out.
>
> Okay. It's very hard to discern what uses of "RELEASE_11" pertain to 
> "-release" support and what just pertain to -source/-target. ??

In this iteration, mostly -source/-target. The code that populates the 
list of releases supported by --release has had some updates since I 
last looked at it and I didn't figure that part out before sending out 
this review.

>
>> The build is simultaneously updated to user -source/-target 11, hence 
>> the inclusion of build-dev.
>>
>> Various langtools tests and test infrastructure is updated too.
>
> test/langtools/tools/javac/versions/Versions.java looks like it needed 
> some updates for JDK 10!

Better late than never ;-)

Thanks,

-Joe


From david.holmes at oracle.com  Tue Dec 12 21:32:04 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 13 Dec 2017 07:32:04 +1000
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com>
 <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com>
Message-ID: <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com>

Hi Joe,

On 13/12/2017 7:27 AM, joe darcy wrote:
> Hi David,
> 
> 
> On 12/12/2017 1:11 PM, David Holmes wrote:
>> Hi Joe,
>>
>> On 12/12/2017 5:04 PM, joe darcy wrote:
>>> Hello,
>>>
>>> With the JDK 11 line of development opening up in a few days, a few 
>>> changes are needed to prepared to turn a JDK 10 code base into a JDK 
>>> 11 one including:
>>>
>>> ???? JDK-8173382: Add -source 11 and -target 11 to javac
>>> ???? JDK-8193291: Add SourceVersion.RELEASE_11
>>>
>>> ???? Webev:
>>> ???????? http://cr.openjdk.java.net/~darcy/8173382.1/
>>> ???? CSRs:
>>> ???????? JDK-8193350: Add -source 11 and -target 11 to javac
>>> ???????? JDK-8193351: Add SourceVersion.RELEASE_11
>>>
>>> Please review the preliminary webrev and CSRs.
>>
>> I don't see a change to the actual JDK version as part of this ?? 
> 
> Correct; the webrev to date is the langtools portion of the new JDK 
> groundbreaking, the same subset of groundbreaking I looked at for the 9 
> -> 10 transition. Other pieces are needed too, including HotSpot changes 
> and the actual version update.

So what is the overall transition strategy here? I don't see how you can 
change javac to default to -source/-target 11 prior to bumping the 
actual version to 11. Or do you expect all the additional pieces to come 
together at the same time?

Thanks,
David

>> hat's the change that will cause hotspot to fail to build in debug 
>> mode as soon as the version is bumped - I filed:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8193364
>>
>> to at least get over that.
>>
>>> Note that breaking with previous contentions, the current iteration 
>>> of the change does *not* add -source/-target "1.11" as an alias for 
>>> "11". Only "11" is recognized.
>>>
>>> I didn't see how to add support for an "11" value for "--release" so 
>>> I problem listed two tests until that is sorted out.
>>
>> Okay. It's very hard to discern what uses of "RELEASE_11" pertain to 
>> "-release" support and what just pertain to -source/-target. ??
> 
> In this iteration, mostly -source/-target. The code that populates the 
> list of releases supported by --release has had some updates since I 
> last looked at it and I didn't figure that part out before sending out 
> this review.
> 
>>
>>> The build is simultaneously updated to user -source/-target 11, hence 
>>> the inclusion of build-dev.
>>>
>>> Various langtools tests and test infrastructure is updated too.
>>
>> test/langtools/tools/javac/versions/Versions.java looks like it needed 
>> some updates for JDK 10!
> 
> Better late than never ;-)
> 
> Thanks,
> 
> -Joe
> 

From joe.darcy at oracle.com  Tue Dec 12 23:20:26 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Tue, 12 Dec 2017 15:20:26 -0800
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com>
 <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com>
 <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com>
Message-ID: <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com>

Hi David,


On 12/12/2017 1:32 PM, David Holmes wrote:
> Hi Joe,
>
> On 13/12/2017 7:27 AM, joe darcy wrote:
>> Hi David,
>>
>>
>> On 12/12/2017 1:11 PM, David Holmes wrote:
>>> Hi Joe,
>>>
>>> On 12/12/2017 5:04 PM, joe darcy wrote:
>>>> Hello,
>>>>
>>>> With the JDK 11 line of development opening up in a few days, a few 
>>>> changes are needed to prepared to turn a JDK 10 code base into a 
>>>> JDK 11 one including:
>>>>
>>>>      JDK-8173382: Add -source 11 and -target 11 to javac
>>>>      JDK-8193291: Add SourceVersion.RELEASE_11
>>>>
>>>>      Webev:
>>>>          http://cr.openjdk.java.net/~darcy/8173382.1/
>>>>      CSRs:
>>>>          JDK-8193350: Add -source 11 and -target 11 to javac
>>>>          JDK-8193351: Add SourceVersion.RELEASE_11
>>>>
>>>> Please review the preliminary webrev and CSRs.
>>>
>>> I don't see a change to the actual JDK version as part of this ?? 
>>
>> Correct; the webrev to date is the langtools portion of the new JDK 
>> groundbreaking, the same subset of groundbreaking I looked at for the 
>> 9 -> 10 transition. Other pieces are needed too, including HotSpot 
>> changes and the actual version update.
>
> So what is the overall transition strategy here? I don't see how you 
> can change javac to default to -source/-target 11 prior to bumping the 
> actual version to 11. Or do you expect all the additional pieces to 
> come together at the same time?
>

For background, what we've done in the past is at the very start of a 
new JDK release, first create -source/-target ${N+1} that begin as 
aliases for ${N} and are the default -source/-target for javac. [1] As 
new language features are developed, the javac implementation adds 
allowFeatureFoo() predicates which turn into

     return sourceOptionBeingUsed >= firstSourceWhichAllowsFeature

So the operational distinction between -source ${N} and -source ${N+1} 
comes about after language changes have been made for release ${N+1}. 
For -target, since there is often not a hard dependency between new Java 
language features and JVM features, an operational distinction between 
successive values of -target, and thus successive class file versions, 
can come about later in the release. For example, in JDK 10 the language 
feature var/local variable type inference enabled by -source 10 was in 
JDK 10 builds a few months before -target 10 mapped to an updated class 
file version.

We could follow the same path for the JDK 10 -> 11 transition. Paul has 
suggested also updating the class file version at the same time this 
time around.

HTH,

-Joe

[1] Way back when, the new -source/-target values were added without 
simultaneously being made the default. This increased maintenance costs 
of javac tests and led us to implement the current policy.

From david.holmes at oracle.com  Wed Dec 13 04:56:29 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 13 Dec 2017 14:56:29 +1000
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com>
 <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com>
 <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com>
 <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com>
Message-ID: <33cac77e-a465-92c0-464e-9e086699786b@oracle.com>

Hi Joe,

On 13/12/2017 9:20 AM, joe darcy wrote:
> Hi David,
> 
> 
> On 12/12/2017 1:32 PM, David Holmes wrote:
>> Hi Joe,
>>
>> On 13/12/2017 7:27 AM, joe darcy wrote:
>>> Hi David,
>>>
>>>
>>> On 12/12/2017 1:11 PM, David Holmes wrote:
>>>> Hi Joe,
>>>>
>>>> On 12/12/2017 5:04 PM, joe darcy wrote:
>>>>> Hello,
>>>>>
>>>>> With the JDK 11 line of development opening up in a few days, a few 
>>>>> changes are needed to prepared to turn a JDK 10 code base into a 
>>>>> JDK 11 one including:
>>>>>
>>>>> ???? JDK-8173382: Add -source 11 and -target 11 to javac
>>>>> ???? JDK-8193291: Add SourceVersion.RELEASE_11
>>>>>
>>>>> ???? Webev:
>>>>> ???????? http://cr.openjdk.java.net/~darcy/8173382.1/
>>>>> ???? CSRs:
>>>>> ???????? JDK-8193350: Add -source 11 and -target 11 to javac
>>>>> ???????? JDK-8193351: Add SourceVersion.RELEASE_11
>>>>>
>>>>> Please review the preliminary webrev and CSRs.
>>>>
>>>> I don't see a change to the actual JDK version as part of this ?? 
>>>
>>> Correct; the webrev to date is the langtools portion of the new JDK 
>>> groundbreaking, the same subset of groundbreaking I looked at for the 
>>> 9 -> 10 transition. Other pieces are needed too, including HotSpot 
>>> changes and the actual version update.
>>
>> So what is the overall transition strategy here? I don't see how you 
>> can change javac to default to -source/-target 11 prior to bumping the 
>> actual version to 11. Or do you expect all the additional pieces to 
>> come together at the same time?
>>
> 
> For background, what we've done in the past is at the very start of a 
> new JDK release, first create -source/-target ${N+1} that begin as 
> aliases for ${N} and are the default -source/-target for javac. [1] As 
> new language features are developed, the javac implementation adds 
> allowFeatureFoo() predicates which turn into
> 
>  ??? return sourceOptionBeingUsed >= firstSourceWhichAllowsFeature
> 
> So the operational distinction between -source ${N} and -source ${N+1} 
> comes about after language changes have been made for release ${N+1}. 
> For -target, since there is often not a hard dependency between new Java 
> language features and JVM features, an operational distinction between 
> successive values of -target, and thus successive class file versions, 
> can come about later in the release. For example, in JDK 10 the language 
> feature var/local variable type inference enabled by -source 10 was in 
> JDK 10 builds a few months before -target 10 mapped to an updated class 
> file version.
> 
> We could follow the same path for the JDK 10 -> 11 transition. Paul has 
> suggested also updating the class file version at the same time this 
> time around.

I'm a little unclear as to the distinction between allowing for 
-source/-target 11 and switching them to be the default. Especially if 
you incorporate the classfile version change then we would have a JDK 
reporting itself as JDK 10 but which uses -source/-target 11 and 
produces version 55 classfiles. I would have thought it a two step process:
- prepare for new defaults
- switch to new defaults (in conjunction with version change)

Anyway, none of the proposed changes have any impact on hotspot AFAICT. 
It is only when the actual version is updated to 11 that hotspot, and 
other entities will have to be updated. I'm still unclear if someone is 
actually driving the entire "update to version 11" process? Is there an 
umbrella issue for it?

Thanks,
David

> 
> HTH,
> 
> -Joe
> 
> [1] Way back when, the new -source/-target values were added without 
> simultaneously being made the default. This increased maintenance costs 
> of javac tests and led us to implement the current policy.

From joe.darcy at oracle.com  Wed Dec 13 08:16:32 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 13 Dec 2017 00:16:32 -0800
Subject: Do package-infos need to be reset between annotation processing
 rounds?
In-Reply-To: <7c9034fd-c538-44a0-95b6-c0b91ee71f43@oracle.com>
References: <CAL4QsgswjOw3E5=X2B5oKARGBMRYS2a+9-1=jFMePXKh6z-9GA@mail.gmail.com>
 <5A273DEB.5060402@oracle.com>
 <CAL4QsgtTYEDtGHamouGj4JkVbZzBmEMC0ZjopYc9BEcSS8D=qA@mail.gmail.com>
 <5A275146.3080903@oracle.com>
 <CAL4QsgtmieC+a1vi9FremH3T2emMTuxqO_YLJrPq6V2T3xm1Og@mail.gmail.com>
 <7c9034fd-c538-44a0-95b6-c0b91ee71f43@oracle.com>
Message-ID: <ae24b1cb-ee8d-e3fd-7af0-8d949de96a21@oracle.com>

Hello,

Catching up on email amid JDK 10 RDP1 activities, the Filer 
specification states:

> During each run of an annotation processing tool, a file with a given 
> pathname may be created only once. If that file already exists before 
> the first attempt to create it, the old contents will be deleted. Any 
> subsequent attempt to create the same file during a run will throw a 
> |FilerException| 
> <http://download.java.net/java/jdk10/docs/api/javax/annotation/processing/FilerException.html>, 
> as will attempting to create both a class file and source file for the 
> same type name or same package name. The initial inputs 
> <http://download.java.net/java/jdk10/docs/api/javax/annotation/processing/Processor.html> 
> to the tool are considered to be created by the zeroth round; 
> therefore, attempting to create a source or class file corresponding 
> to one of those inputs will result in a |FilerException| 
> <http://download.java.net/java/jdk10/docs/api/javax/annotation/processing/FilerException.html>. 
>
>
> In general, processors must not knowingly attempt to overwrite 
> existing files that were not generated by some processor. A |Filer| 
> may reject attempts to open a file corresponding to an existing type, 
> like |java.lang.Object|. Likewise, the invoker of the annotation 
> processing tool must not knowingly configure the tool such that the 
> discovered processors will attempt to overwrite existing files that 
> were not generated.
>
http://download.java.net/java/jdk10/docs/api/javax/annotation/processing/Filer.html

For handling source files in particular:

> A source file can also be created to hold information about a package, 
> including package annotations. To create a source file for a named 
> package, have the |name| argument be the package's name followed by 
> |".package-info"|; to create a source file for an unnamed package, use 
> |"package-info"|. 

To separate a few cases, the javac Filer implementation tracks state 
about which files have been opened through the Filer on previous rounds 
of processing and throws exceptions if an attempt is made to re-open a 
file. (The check is a bit more involved; the Filer also checks the you 
don't open a class file for a type you've already opened a source file 
for, etc.) Package info files are handled the same way too. There is a 
short regression test on that functionality

test/langtools/tools/javac/processing/filer/TestPackageInfo.java

but the exception on re-opening isn't explicitly tested there. Let me do 
a quick check... the implementation has the expected behavior for 
package-info files explicitly opened by annotation processors.. I'll 
file a RFE to enhance the test to explicitly cover this case.

However, contrary to the documentation, the implementation does not 
handle the case of a package-info file given on the initial inputs, 
although types on the initial inputs are checked for properly. I believe 
something like the patch below to JavacFiler *should* resolve that 
discrepancy:

-        ClassSymbol existing;
          boolean alreadySeen = 
aggregateGeneratedSourceNames.contains(Pair.of(mod, typename)) ||
aggregateGeneratedClassNames.contains(Pair.of(mod, typename)) ||
initialClassNames.contains(typename) ||
-                              ((existing = 
elementUtils.getTypeElement(typename)) != null &&
- initialInputs.contains(existing.sourcefile));
+                              containedInInitialInputs(typename);
          if (alreadySeen) {
              if (lint)
                  log.warning(Warnings.ProcTypeRecreate(typename));
@@ -731,6 +736,27 @@
          }
      }

+    private boolean containedInInitialInputs(String typename) {
+        // Name could be a type name or the name of a package-info file
+        JavaFileObject sourceFile = null;
+
+        ClassSymbol existingClass = elementUtils.getTypeElement(typename);
+        if (existingClass != null) {
+            sourceFile = existingClass.sourcefile;
+        } else if (typename.endsWith(".package-info")) {
+            String targetName = typename.substring(0, typename.length() 
- ".package-info".length());
+            PackageSymbol existingPackage = 
elementUtils.getPackageElement(targetName);
+            if (existingPackage != null)
+                sourceFile = existingPackage.sourcefile;
+        }
+        return (sourceFile == null) ? false : 
initialInputs.contains(sourceFile);
+    }
+

*However,* the sourcefile field of the PackageSymbol doesn't seem to be 
getting set to a non-null value via the lookup process. I didn't fully 
run down which part of JavacElements or Symbol takes care of that.

In the broader sense of the intention of the Filer, in the simplest case 
of input locations and output locations being disjoint, than the rules 
quoted above should be enforced. However, people can and do run 
configurations where the input and output locations overlap, 
complicating implementing the proper intentions.

In general, package-info files should be handled analogously to source 
files for types.

HTH,

-Joe


On 12/5/2017 11:48 PM, Jonathan Gibbons wrote:
>
> We'll need Joe "Mr Annotation Processing" Darcy to chime in here, but 
> the Filer is supposed to detect clashes, and prevent 
> overwriting/overriding symbols. That's definitely supposed to happen 
> for normal classes/interfaces; I could believe that package-info has 
> been overlooked, but I would expect it to follow the same guidelines.
>
> -- Jon
>
>
> On 12/5/17 6:24 PM, Liam Miller-Cushon wrote:
>> Is overriding package-infos different or worse than overriding other 
>> symbols? I've seen a number of examples where the same source file 
>> was compiled multiple times and the earlier results ended up on the 
>> class path of the later compilations, so a processor-generated class 
>> was both on the class path and generated during the compilation. 
>> Making that an error would be a somewhat invasive breaking change. I 
>> agree that it should be discouraged, but I'm not sure it's worth 
>> making an error? (Unless there's something special about 
>> package-infos that I'm missing.)
>>
>> On Tue, Dec 5, 2017 at 6:09 PM, Jonathan Gibbons 
>> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>>
>>     Generally, annotation processing is supposed to only create
>>     information where there was no information previously, so if a
>>     package had a package-info with annotations, it seems like it
>>     should be an error to override it with another package-info, with
>>     or without annotations.
>>
>>     -- Jon
>>
>>
>>     On 12/05/2017 05:39 PM, Liam Miller-Cushon wrote:
>>>     Thanks! If an annotated package-info is loaded from the class
>>>     path, and then a processor generates a package-info that
>>>     contains no annotations, the reset is necessary. (The reset
>>>     isn't necessary if the new package-info is annotated, since the
>>>     old annotations get overwritten even if they weren't reset
>>>     between rounds.)
>>>
>>>     On Tue, Dec 5, 2017 at 4:46 PM, Jonathan Gibbons
>>>     <jonathan.gibbons at oracle.com
>>>     <mailto:jonathan.gibbons at oracle.com>> wrote:
>>>
>>>         Liam,
>>>
>>>         What about the case where an annotation processor generates
>>>         the package-info.java file? Is that a case where it is
>>>         important to reinit the packge symbol correctly, so that the
>>>         newly generated code is read?
>>>
>>>         -- Jon
>>>
>>>
>>>         On 12/05/2017 03:39 PM, Liam Miller-Cushon wrote:
>>>
>>>             I have a question about the logic in
>>>             JavacProcessingEnvironment's treeCleaner that resets
>>>             package-info state between annotation processing rounds [1].
>>>
>>>             JDK-8193037 describes an issue where package-infos
>>>             loaded from the classpath are reset by treeCleaner.
>>>             Those symbols doesn't get reinitialized correctly, and
>>>             package annotations are not visible during subsequent
>>>             annotation processing rounds.
>>>
>>>             I wondered if the logic was only meant to apply to
>>>             package-infos being compiled from source in the current
>>>             compilation (similar to how module-infos are handle by
>>>             treeCleaner), but I'm having trouble understanding when
>>>             that logic is necessary. Commenting out
>>>             `node.packge.package_info.reset();` and
>>>             `node.packge.reset();` in treeCleaner doesn't break any
>>>             jtreg tests. Does anyone have examples where that code
>>>             is needed? I'd like to add a regression test to ensure
>>>             the fix for JDK-8193037 doesn't interfere with the
>>>             original purpose of that code.
>>>
>>>             Thanks,
>>>
>>>             [1]
>>>             http://hg.openjdk.java.net/jdk/jdk/file/a358ebcfacfb/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java#l1518
>>>             <http://hg.openjdk.java.net/jdk/jdk/file/a358ebcfacfb/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java#l1518>
>>>
>>>
>>>
>>
>>
>

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

From jan.lahoda at oracle.com  Wed Dec 13 13:01:50 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 13 Dec 2017 14:01:50 +0100
Subject: RFR 8189708: class reading issue with named and annotated
 parameters
In-Reply-To: <CAL4Qsgt3opbb5APWhigjHgQw_0hO4t_AR6AsdURZpovbdz6ikQ@mail.gmail.com>
References: <CAL4QsgtDfRxacW3iWS_+1RxorSHin9_OCV+PUXw=shH+zD0H7Q@mail.gmail.com>
 <59E9A5B5.5060200@oracle.com>
 <CAL4Qsguo_rcHUYKNKuavFQO1QDA-T8xTWtO_abPZuqT-oy3DVQ@mail.gmail.com>
 <CAL4QsgsFpyKG3fVrwzrtpat6La_Mm8X6tm5n=P+Qwf3+q7E5MQ@mail.gmail.com>
 <CAL4Qsgt3opbb5APWhigjHgQw_0hO4t_AR6AsdURZpovbdz6ikQ@mail.gmail.com>
Message-ID: <5A3124BE.6020202@oracle.com>

Sorry for late reply.

Seems OK to me, only:
-the tests should be in:
test/langtools/tools/javac/MethodParameters/8189708
not in:
test/tools/javac/MethodParameters/8189708

-test/tools/javac/MethodParameters/8189708/Test.java has a weird license 
header

Vicente, could you please take a look as well?

Thanks,
     Jan

On 4.12.2017 22:37, Liam Miller-Cushon wrote:
> Hi, is there any more feedback on this?
>
> On Fri, Oct 20, 2017 at 5:51 PM, Liam Miller-Cushon <cushon at google.com
> <mailto:cushon at google.com>> wrote:
>
>     Here's an updated patch that incorporates your approach:
>     http://cr.openjdk.java.net/~cushon/8007720/webrev.01/
>     <http://cr.openjdk.java.net/~cushon/8007720/webrev.01/>
>
>     I included the fix for JDK-8177486 so I could test the inner class /
>     enum constructor case. If this looks like it's on the right track
>     I'll move that part (and the corresponding tests) back into a
>     separate change.
>
>     On Fri, Oct 20, 2017 at 9:30 AM, Liam Miller-Cushon
>     <cushon at google.com <mailto:cushon at google.com>> wrote:
>
>         Thanks for the comments,
>
>         On Fri, Oct 20, 2017 at 12:28 AM, Jan Lahoda
>         <jan.lahoda at oracle.com <mailto:jan.lahoda at oracle.com>> wrote:
>
>             -what happens if there are both runtime invisible and
>             visible annotations of method's parameters? Seems those that
>             appear later will overwrite those that appear sooner?
>
>
>         Oops, thanks. The way your patch handles that looks good to me.
>
>             -the MethodSymbol.savedParameterAnnotations is only used
>             during reading inside the ClassReader, right? It seems
>             wasteful to have it as a field on each MethodSymbol, better
>             would be a field in ClassReader.
>
>
>         Sounds good. I'll try to avoid having savedParameterNames as a
>         field in MethodSymbol also. Do you remember if you encountered
>         any issues with that in your patch?
>
>             -please check what happens for annotations on constructors
>             of enums/non-static innerclasses
>
>
>         Will do. (Also, note that there appears to be an issue with
>         reading MethodParameters on constructors of enums/non-static
>         inner classes: JDK-8177486)
>
>
>

From paul.sandoz at oracle.com  Wed Dec 13 16:44:33 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 13 Dec 2017 08:44:33 -0800
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <33cac77e-a465-92c0-464e-9e086699786b@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com>
 <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com>
 <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com>
 <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com>
 <33cac77e-a465-92c0-464e-9e086699786b@oracle.com>
Message-ID: <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com>



> On 12 Dec 2017, at 20:56, David Holmes <david.holmes at oracle.com> wrote:
> 
> Anyway, none of the proposed changes have any impact on hotspot AFAICT. It is only when the actual version is updated to 11 that hotspot, and other entities will have to be updated. I'm still unclear if someone is actually driving the entire "update to version 11" process? Is there an umbrella issue for it?
> 

No yet, i was hoping we could consolidate as much as possible under one issue thereby minimising coordination/process i.e. combine the release and class file versions under one patch. Then stand back and see what is missing e.g. ctsym stuff etc.

Paul.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 873 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171213/bbf32e21/signature.asc>

From paul.sandoz at oracle.com  Wed Dec 13 18:22:33 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 13 Dec 2017 10:22:33 -0800
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com>
 <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com>
 <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com>
 <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com>
 <33cac77e-a465-92c0-464e-9e086699786b@oracle.com>
 <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com>
Message-ID: <65256BE6-46F9-4633-A6FA-455D58787C3A@oracle.com>

Joe,

Here's a patch on top of your patch:

  http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-release-classfile-version/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-release-classfile-version/webrev/>

Currently building/testing with both patches applied.

Paul.


> On 13 Dec 2017, at 08:44, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:
> 
> 
> 
>> On 12 Dec 2017, at 20:56, David Holmes <david.holmes at oracle.com> wrote:
>> 
>> Anyway, none of the proposed changes have any impact on hotspot AFAICT. It is only when the actual version is updated to 11 that hotspot, and other entities will have to be updated. I'm still unclear if someone is actually driving the entire "update to version 11" process? Is there an umbrella issue for it?
>> 
> 
> No yet, i was hoping we could consolidate as much as possible under one issue thereby minimising coordination/process i.e. combine the release and class file versions under one patch. Then stand back and see what is missing e.g. ctsym stuff etc.
> 
> Paul.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171213/3f51ac63/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 873 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171213/3f51ac63/signature.asc>

From joe.darcy at oracle.com  Wed Dec 13 18:36:33 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 13 Dec 2017 10:36:33 -0800
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <33cac77e-a465-92c0-464e-9e086699786b@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com>
 <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com>
 <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com>
 <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com>
 <33cac77e-a465-92c0-464e-9e086699786b@oracle.com>
Message-ID: <c682f2f2-94f8-cb17-37a9-a3a56247aa92@oracle.com>

Hi David,


On 12/12/2017 8:56 PM, David Holmes wrote:
> Hi Joe,
>
> On 13/12/2017 9:20 AM, joe darcy wrote:
>> Hi David,
>>
>>
>> On 12/12/2017 1:32 PM, David Holmes wrote:
>>>

[snip]

>>>
>>
>> For background, what we've done in the past is at the very start of a 
>> new JDK release, first create -source/-target ${N+1} that begin as 
>> aliases for ${N} and are the default -source/-target for javac. [1] 
>> As new language features are developed, the javac implementation adds 
>> allowFeatureFoo() predicates which turn into
>>
>>      return sourceOptionBeingUsed >= firstSourceWhichAllowsFeature
>>
>> So the operational distinction between -source ${N} and -source 
>> ${N+1} comes about after language changes have been made for release 
>> ${N+1}. For -target, since there is often not a hard dependency 
>> between new Java language features and JVM features, an operational 
>> distinction between successive values of -target, and thus successive 
>> class file versions, can come about later in the release. For 
>> example, in JDK 10 the language feature var/local variable type 
>> inference enabled by -source 10 was in JDK 10 builds a few months 
>> before -target 10 mapped to an updated class file version.
>>
>> We could follow the same path for the JDK 10 -> 11 transition. Paul 
>> has suggested also updating the class file version at the same time 
>> this time around.
>
> I'm a little unclear as to the distinction between allowing for 
> -source/-target 11 and switching them to be the default. Especially if 
> you incorporate the classfile version change then we would have a JDK 
> reporting itself as JDK 10 but which uses -source/-target 11 and 
> produces version 55 classfiles. I would have thought it a two step 
> process:
> - prepare for new defaults
> - switch to new defaults (in conjunction with version change)
>
> Anyway, none of the proposed changes have any impact on hotspot 
> AFAICT. It is only when the actual version is updated to 11 that 
> hotspot, and other entities will have to be updated. I'm still unclear 
> if someone is actually driving the entire "update to version 11" 
> process? Is there an umbrella issue for it?
>

There are various changes associated with a JDK N to (N+1) update 
including (but not limited to):

     1) New -source/-target value in javac
     2) Make new -source/-target value the default in javac
     3) Change build of the JDK to use new -source/-target
     4) Increment version
     5) Support new --release value in javac
     6) Output new class file format
     7) Have HotSpot accept new class file format
     ...

For the last few releases, we've done 1) through 4) in b01 of the new 
release, although typically via multiple changesets since 4) has been 
done separately from 1) through 3) and 3) had to be done separately from 
1) and 2) since different repos were affected before the repo consolidation.

It is desirable but not strictly necessary to bundle this set of updates 
into as few changesets as possible. In particular, I think it is 
acceptable if the master repo has source code states before the first 
promoted build where not all of 1) through 4) are fixed.

Cheers,

-Joe

From joe.darcy at oracle.com  Wed Dec 13 18:51:32 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 13 Dec 2017 10:51:32 -0800
Subject: Do package-infos need to be reset between annotation processing
 rounds?
In-Reply-To: <ae24b1cb-ee8d-e3fd-7af0-8d949de96a21@oracle.com>
References: <CAL4QsgswjOw3E5=X2B5oKARGBMRYS2a+9-1=jFMePXKh6z-9GA@mail.gmail.com>
 <5A273DEB.5060402@oracle.com>
 <CAL4QsgtTYEDtGHamouGj4JkVbZzBmEMC0ZjopYc9BEcSS8D=qA@mail.gmail.com>
 <5A275146.3080903@oracle.com>
 <CAL4QsgtmieC+a1vi9FremH3T2emMTuxqO_YLJrPq6V2T3xm1Og@mail.gmail.com>
 <7c9034fd-c538-44a0-95b6-c0b91ee71f43@oracle.com>
 <ae24b1cb-ee8d-e3fd-7af0-8d949de96a21@oracle.com>
Message-ID: <40864745-48ce-740e-f35f-2454625fc484@oracle.com>

PS Filed

     JDK-8193462: Fix Filer handling of package-info initial elements

The not-quite-working version of the fix is at:

     http://cr.openjdk.java.net/~darcy/8193462.0/

-Joe



From jonathan.gibbons at oracle.com  Wed Dec 13 20:43:13 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 13 Dec 2017 12:43:13 -0800
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <c682f2f2-94f8-cb17-37a9-a3a56247aa92@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com>
 <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com>
 <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com>
 <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com>
 <33cac77e-a465-92c0-464e-9e086699786b@oracle.com>
 <c682f2f2-94f8-cb17-37a9-a3a56247aa92@oracle.com>
Message-ID: <ad86fb3b-6240-7ff7-d500-5113aa3e28b7@oracle.com>



On 12/13/17 10:36 AM, joe darcy wrote:
> Hi David,
>
>
> On 12/12/2017 8:56 PM, David Holmes wrote:
>> Hi Joe,
>>
>> On 13/12/2017 9:20 AM, joe darcy wrote:
>>> Hi David,
>>>
>>>
>>> On 12/12/2017 1:32 PM, David Holmes wrote:
>>>>
>
> [snip]
>
>>>>
>>>
>>> For background, what we've done in the past is at the very start of 
>>> a new JDK release, first create -source/-target ${N+1} that begin as 
>>> aliases for ${N} and are the default -source/-target for javac. [1] 
>>> As new language features are developed, the javac implementation 
>>> adds allowFeatureFoo() predicates which turn into
>>>
>>> ???? return sourceOptionBeingUsed >= firstSourceWhichAllowsFeature
>>>
>>> So the operational distinction between -source ${N} and -source 
>>> ${N+1} comes about after language changes have been made for release 
>>> ${N+1}. For -target, since there is often not a hard dependency 
>>> between new Java language features and JVM features, an operational 
>>> distinction between successive values of -target, and thus 
>>> successive class file versions, can come about later in the release. 
>>> For example, in JDK 10 the language feature var/local variable type 
>>> inference enabled by -source 10 was in JDK 10 builds a few months 
>>> before -target 10 mapped to an updated class file version.
>>>
>>> We could follow the same path for the JDK 10 -> 11 transition. Paul 
>>> has suggested also updating the class file version at the same time 
>>> this time around.
>>
>> I'm a little unclear as to the distinction between allowing for 
>> -source/-target 11 and switching them to be the default. Especially 
>> if you incorporate the classfile version change then we would have a 
>> JDK reporting itself as JDK 10 but which uses -source/-target 11 and 
>> produces version 55 classfiles. I would have thought it a two step 
>> process:
>> - prepare for new defaults
>> - switch to new defaults (in conjunction with version change)
>>
>> Anyway, none of the proposed changes have any impact on hotspot 
>> AFAICT. It is only when the actual version is updated to 11 that 
>> hotspot, and other entities will have to be updated. I'm still 
>> unclear if someone is actually driving the entire "update to version 
>> 11" process? Is there an umbrella issue for it?
>>
>
> There are various changes associated with a JDK N to (N+1) update 
> including (but not limited to):
>
> ??? 1) New -source/-target value in javac
> ??? 2) Make new -source/-target value the default in javac
> ??? 3) Change build of the JDK to use new -source/-target
> ??? 4) Increment version
> ??? 5) Support new --release value in javac
> ??? 6) Output new class file format
> ??? 7) Have HotSpot accept new class file format
> ??? ...
>
> For the last few releases, we've done 1) through 4) in b01 of the new 
> release, although typically via multiple changesets since 4) has been 
> done separately from 1) through 3) and 3) had to be done separately 
> from 1) and 2) since different repos were affected before the repo 
> consolidation.
>
> It is desirable but not strictly necessary to bundle this set of 
> updates into as few changesets as possible. In particular, I think it 
> is acceptable if the master repo has source code states before the 
> first promoted build where not all of 1) through 4) are fixed.
>
> Cheers,
>
> -Joe

There's also

3a) Update build of the INTERIM components (used for bootstrapping the 
build) to use latest GA release

Somewhat related, as a one-off,?? JDK 9 javac added a class called 
JDK9Wrappers to provide reflective access to new-in-JDK-9 API. These 
wrappers can now be removed, and the API used directly.

-- Jon

From mark.reinhold at oracle.com  Wed Dec 13 21:18:43 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 13 Dec 2017 13:18:43 -0800
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com>
 <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com>
 <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com>
 <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com>
 <33cac77e-a465-92c0-464e-9e086699786b@oracle.com>
 <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com>
Message-ID: <20171213131843.760702080@eggemoggin.niobe.net>

2017/12/13 8:44:33 -0800, paul.sandoz at oracle.com:
>> On 12 Dec 2017, at 20:56, david.holmes at oracle.com wrote:
>> 
>> Anyway, none of the proposed changes have any impact on hotspot
>> AFAICT. It is only when the actual version is updated to 11 that
>> hotspot, and other entities will have to be updated. I'm still
>> unclear if someone is actually driving the entire "update to version
>> 11" process? Is there an umbrella issue for it?
> 
> No yet, i was hoping we could consolidate as much as possible under
> one issue thereby minimising coordination/process i.e. combine the
> release and class file versions under one patch. Then stand back and
> see what is missing e.g. ctsym stuff etc.

How much of this can we parameterize and/or automate?  We are going to
have to do it every six months, after all.

Could we define a CLASSFILE_VERSION in make/autoconf/version-numbers and
then propagate that value everywhere else?  (In any actual release it'll
be VERSION_FEATURE + 44, but make it a separate variable to allow for
experimentation as with, e.g., MVT.)

Looking at Joe's webrev, many of the changes from 10 to 11 could instead
be changed to Runtime.getRuntime().version().major() (in Java code) or
VERSION_FEATURE (in Makefiles).

In javax.lang.model.SourceVersion we could define a new constant, say
RELEASE_CURRENT, whose value is that of the latest release.  Then
annotations such as

  @SupportedSourceVersion(SourceVersion.RELEASE_11)

could be replaced by

  @SupportedSourceVersion(SourceVersion.RELEASE_CURRENT)

Similarly, JDK_CURRENT could be defined in com.sun.tools.javac.Target
and then many references to JDK10 could instead refer to that.

In cases where additional code is needed, can we generate it during
the build via another Gensrc*.gmk Makefile?  That'd be more work now,
but it could save us a lot of time in the long run.

- Mark

From jonathan.gibbons at oracle.com  Wed Dec 13 21:43:47 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 13 Dec 2017 13:43:47 -0800
Subject: RFR: 8182758: Remove the Native-Header Generation Tool (javah)
In-Reply-To: <5A04E7F3.5000700@oracle.com>
References: <5A04E7F3.5000700@oracle.com>
Message-ID: <5A319F13.8010505@oracle.com>

Minor tweak to the previous round: a dangling reference to javah was 
removed from the doc comment in the jdk.compiler module-info (line 30).

http://cr.openjdk.java.net/~jjg/8182758/webrev.01/src/jdk.compiler/share/classes/module-info.java.sdiff.html

Updated webrev: http://cr.openjdk.java.net/~jjg/8182758/webrev.01/

-- Jon

On 11/09/2017 03:42 PM, Jonathan Gibbons wrote:
> Please review a fix to remove the javah tool, as previously advertised
> in JDK-8152360. (The replacement is to use the javac -h option.)
>
> Not surprisingly, most of this is removing code, with just a couple of 
> src/
> files being modified, as well as some tests.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8182758
> Webrev: http://cr.openjdk.java.net/~jjg/8182758/webrev.00/
>
> -- Jon


From stuart.marks at oracle.com  Wed Dec 13 21:38:57 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 13 Dec 2017 13:38:57 -0800
Subject: JDK 10 RFR(xs): JDK-8193476 (jdeprscan) additional version updates
 for JDK 10
Message-ID: <4329d95b-f5f5-7b09-810b-0572274d0f8f@oracle.com>

Hi all,

Please review a couple version updates for jdeprscan that need to squeak in 
before JDK 10 closes. Diffs below. Thanks.

s'marks


diff -r 31bad3096948 -r 7ebe4e27f1d0 
src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/TraverseProc.java
--- a/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/TraverseProc.java	Wed 
Dec 13 10:09:36 2017 -0800
+++ b/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/TraverseProc.java	Wed 
Dec 13 13:30:07 2017 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -45,14 +45,14 @@
  import javax.lang.model.element.TypeElement;
  import javax.lang.model.util.Elements;

-import static javax.lang.model.SourceVersion.RELEASE_9;
+import static javax.lang.model.SourceVersion.RELEASE_10;
  import javax.lang.model.element.Element;
  import javax.lang.model.element.ElementKind;
  import javax.lang.model.element.Modifier;
  import javax.lang.model.element.PackageElement;
  import javax.tools.Diagnostic;

- at SupportedSourceVersion(RELEASE_9)
+ at SupportedSourceVersion(RELEASE_10)
  @SupportedAnnotationTypes("*")
  public class TraverseProc extends AbstractProcessor {
      Elements elements;
diff -r 31bad3096948 -r 7ebe4e27f1d0 
src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/readme.md
--- a/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/readme.md	Wed Dec 13 
10:09:36 2017 -0800
+++ b/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/readme.md	Wed Dec 13 
13:30:07 2017 -0800
@@ -1,6 +1,6 @@
  <!--

-Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved.
+Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights reserved.
  DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

  This code is free software; you can redistribute it and/or modify it
@@ -62,7 +62,7 @@

              Prints out the set of deprecated APIs.

-        --release 6|7|8|9
+        --release 6|7|8|9|10

              Specifies the Java SE release that is the source of
              the list of deprecated APIs. If no --release option is
diff -r 31bad3096948 -r 7ebe4e27f1d0 
src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/resources/jdeprscan.properties
--- 
a/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/resources/jdeprscan.properties 
Wed Dec 13 10:09:36 2017 -0800
+++ 
b/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/resources/jdeprscan.properties 
Wed Dec 13 13:30:07 2017 -0800
@@ -7,7 +7,7 @@
  \       --full-version\n\
  \  -h   --help\n\
  \  -l   --list\n\
-\       --release 6|7|8|9\n\
+\       --release 6|7|8|9|10\n\
  \  -v   --verbose\n\
  \       --version


From joe.darcy at oracle.com  Wed Dec 13 21:47:28 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 13 Dec 2017 13:47:28 -0800
Subject: JDK 10 RFR(xs): JDK-8193476 (jdeprscan) additional version
 updates for JDK 10
In-Reply-To: <4329d95b-f5f5-7b09-810b-0572274d0f8f@oracle.com>
References: <4329d95b-f5f5-7b09-810b-0572274d0f8f@oracle.com>
Message-ID: <91f1bf2d-7ba8-eebb-dcb8-c9b52f636f8a@oracle.com>

Looks good Stuart; thanks,

-Joe


On 12/13/2017 1:38 PM, Stuart Marks wrote:
> Hi all,
>
> Please review a couple version updates for jdeprscan that need to 
> squeak in before JDK 10 closes. Diffs below. Thanks.
>
> s'marks
>
>
> diff -r 31bad3096948 -r 7ebe4e27f1d0 
> src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/TraverseProc.java
> --- 
> a/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/TraverseProc.java 
> Wed Dec 13 10:09:36 2017 -0800
> +++ 
> b/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/TraverseProc.java 
> Wed Dec 13 13:30:07 2017 -0800
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2016, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -45,14 +45,14 @@
>  import javax.lang.model.element.TypeElement;
>  import javax.lang.model.util.Elements;
>
> -import static javax.lang.model.SourceVersion.RELEASE_9;
> +import static javax.lang.model.SourceVersion.RELEASE_10;
>  import javax.lang.model.element.Element;
>  import javax.lang.model.element.ElementKind;
>  import javax.lang.model.element.Modifier;
>  import javax.lang.model.element.PackageElement;
>  import javax.tools.Diagnostic;
>
> - at SupportedSourceVersion(RELEASE_9)
> + at SupportedSourceVersion(RELEASE_10)
>  @SupportedAnnotationTypes("*")
>  public class TraverseProc extends AbstractProcessor {
>      Elements elements;
> diff -r 31bad3096948 -r 7ebe4e27f1d0 
> src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/readme.md
> --- a/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/readme.md 
> Wed Dec 13 10:09:36 2017 -0800
> +++ b/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/readme.md 
> Wed Dec 13 13:30:07 2017 -0800
> @@ -1,6 +1,6 @@
>  <!--
>
> -Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved.
> +Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights 
> reserved.
>  DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>
>  This code is free software; you can redistribute it and/or modify it
> @@ -62,7 +62,7 @@
>
>              Prints out the set of deprecated APIs.
>
> -        --release 6|7|8|9
> +        --release 6|7|8|9|10
>
>              Specifies the Java SE release that is the source of
>              the list of deprecated APIs. If no --release option is
> diff -r 31bad3096948 -r 7ebe4e27f1d0 
> src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/resources/jdeprscan.properties
> --- 
> a/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/resources/jdeprscan.properties 
> Wed Dec 13 10:09:36 2017 -0800
> +++ 
> b/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/resources/jdeprscan.properties 
> Wed Dec 13 13:30:07 2017 -0800
> @@ -7,7 +7,7 @@
>  \       --full-version\n\
>  \  -h   --help\n\
>  \  -l   --list\n\
> -\       --release 6|7|8|9\n\
> +\       --release 6|7|8|9|10\n\
>  \  -v   --verbose\n\
>  \       --version
>


From paul.sandoz at oracle.com  Wed Dec 13 22:09:44 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 13 Dec 2017 14:09:44 -0800
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <20171213131843.760702080@eggemoggin.niobe.net>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com>
 <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com>
 <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com>
 <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com>
 <33cac77e-a465-92c0-464e-9e086699786b@oracle.com>
 <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com>
 <20171213131843.760702080@eggemoggin.niobe.net>
Message-ID: <27501B2F-A608-43FD-9093-9CE9F2AB7E6D@oracle.com>



> On 13 Dec 2017, at 13:18, mark.reinhold at oracle.com wrote:
> 
> 2017/12/13 8:44:33 -0800, paul.sandoz at oracle.com:
>>> On 12 Dec 2017, at 20:56, david.holmes at oracle.com wrote:
>>> 
>>> Anyway, none of the proposed changes have any impact on hotspot
>>> AFAICT. It is only when the actual version is updated to 11 that
>>> hotspot, and other entities will have to be updated. I'm still
>>> unclear if someone is actually driving the entire "update to version
>>> 11" process? Is there an umbrella issue for it?
>> 
>> No yet, i was hoping we could consolidate as much as possible under
>> one issue thereby minimising coordination/process i.e. combine the
>> release and class file versions under one patch. Then stand back and
>> see what is missing e.g. ctsym stuff etc.
> 
> How much of this can we parameterize and/or automate?

I suspect quite a bit, as you present below, and i agree we should try and automate as much as possible. At the moment it?s very spaghetti-like and quite fragile.

I suggest we get the initial version bump for 11 out of the way as soon as JDK 10 branches off from the mainline then work on automation for subsequent releases.

Paul.

>  We are going to
> have to do it every six months, after all.
> 
> Could we define a CLASSFILE_VERSION in make/autoconf/version-numbers and
> then propagate that value everywhere else?  (In any actual release it'll
> be VERSION_FEATURE + 44, but make it a separate variable to allow for
> experimentation as with, e.g., MVT.)
> 
> Looking at Joe's webrev, many of the changes from 10 to 11 could instead
> be changed to Runtime.getRuntime().version().major() (in Java code) or
> VERSION_FEATURE (in Makefiles).
> 
> In javax.lang.model.SourceVersion we could define a new constant, say
> RELEASE_CURRENT, whose value is that of the latest release.  Then
> annotations such as
> 
>  @SupportedSourceVersion(SourceVersion.RELEASE_11)
> 
> could be replaced by
> 
>  @SupportedSourceVersion(SourceVersion.RELEASE_CURRENT)
> 
> Similarly, JDK_CURRENT could be defined in com.sun.tools.javac.Target
> and then many references to JDK10 could instead refer to that.
> 
> In cases where additional code is needed, can we generate it during
> the build via another Gensrc*.gmk Makefile?  That'd be more work now,
> but it could save us a lot of time in the long run.
> 
> - Mark

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 873 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171213/f493dc8a/signature.asc>

From kumar.x.srinivasan at oracle.com  Wed Dec 13 22:29:16 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Wed, 13 Dec 2017 14:29:16 -0800
Subject: RFR: 8182758: Remove the Native-Header Generation Tool (javah)
In-Reply-To: <5A319F13.8010505@oracle.com>
References: <5A04E7F3.5000700@oracle.com> <5A319F13.8010505@oracle.com>
Message-ID: <5A31A9BC.1050708@oracle.com>

Looks good.

Kumar

On 12/13/2017 1:43 PM, Jonathan Gibbons wrote:
> Minor tweak to the previous round: a dangling reference to javah was 
> removed from the doc comment in the jdk.compiler module-info (line 30).
>
> http://cr.openjdk.java.net/~jjg/8182758/webrev.01/src/jdk.compiler/share/classes/module-info.java.sdiff.html 
>
>
> Updated webrev: http://cr.openjdk.java.net/~jjg/8182758/webrev.01/
>
> -- Jon
>
> On 11/09/2017 03:42 PM, Jonathan Gibbons wrote:
>> Please review a fix to remove the javah tool, as previously advertised
>> in JDK-8152360. (The replacement is to use the javac -h option.)
>>
>> Not surprisingly, most of this is removing code, with just a couple 
>> of src/
>> files being modified, as well as some tests.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8182758
>> Webrev: http://cr.openjdk.java.net/~jjg/8182758/webrev.00/
>>
>> -- Jon
>


From brian.goetz at oracle.com  Wed Dec 13 22:32:23 2017
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 13 Dec 2017 17:32:23 -0500
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <c682f2f2-94f8-cb17-37a9-a3a56247aa92@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com>
 <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com>
 <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com>
 <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com>
 <33cac77e-a465-92c0-464e-9e086699786b@oracle.com>
 <c682f2f2-94f8-cb17-37a9-a3a56247aa92@oracle.com>
Message-ID: <1c469e01-0b07-27de-9a18-b9cee976193d@oracle.com>

Don't forget to add the new version to the list of validated versions in 
multi-release JARs...

On 12/13/2017 1:36 PM, joe darcy wrote:
>
> There are various changes associated with a JDK N to (N+1) update 
> including (but not limited to):
>
> ??? 1) New -source/-target value in javac
> ??? 2) Make new -source/-target value the default in javac
> ??? 3) Change build of the JDK to use new -source/-target
> ??? 4) Increment version
> ??? 5) Support new --release value in javac
> ??? 6) Output new class file format
> ??? 7) Have HotSpot accept new class file format 


From mark.reinhold at oracle.com  Wed Dec 13 22:36:35 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 13 Dec 2017 14:36:35 -0800
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <27501B2F-A608-43FD-9093-9CE9F2AB7E6D@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com>
 <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com>
 <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com>
 <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com>
 <33cac77e-a465-92c0-464e-9e086699786b@oracle.com>
 <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com>
 <20171213131843.760702080@eggemoggin.niobe.net>
 <27501B2F-A608-43FD-9093-9CE9F2AB7E6D@oracle.com>
Message-ID: <20171213143635.259953232@eggemoggin.niobe.net>

2017/12/13 14:09:44 -0800, paul.sandoz at oracle.com:
>> On 13 Dec 2017, at 13:18, mark.reinhold at oracle.com wrote:
>> How much of this can we parameterize and/or automate?
> 
> I suspect quite a bit, as you present below, and i agree we should try
> and automate as much as possible. At the moment it?s very
> spaghetti-like and quite fragile.
> 
> I suggest we get the initial version bump for 11 out of the way as
> soon as JDK 10 branches off from the mainline then work on automation
> for subsequent releases.

I understand that other incoming changes are waiting for the 11 version
bump, but can't we at least do the straightforward parameterizations and
introduce _CURRENT constants in this round?  We can leave anything that
requires code generation to post-11.

- Mark

From paul.sandoz at oracle.com  Wed Dec 13 23:49:53 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 13 Dec 2017 15:49:53 -0800
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <20171213143635.259953232@eggemoggin.niobe.net>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com>
 <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com>
 <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com>
 <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com>
 <33cac77e-a465-92c0-464e-9e086699786b@oracle.com>
 <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com>
 <20171213131843.760702080@eggemoggin.niobe.net>
 <27501B2F-A608-43FD-9093-9CE9F2AB7E6D@oracle.com>
 <20171213143635.259953232@eggemoggin.niobe.net>
Message-ID: <74E8560B-F02D-47CB-9A60-DC6BA4115AD2@oracle.com>



> On 13 Dec 2017, at 14:36, mark.reinhold at oracle.com wrote:
> 
> 2017/12/13 14:09:44 -0800, paul.sandoz at oracle.com:
>>> On 13 Dec 2017, at 13:18, mark.reinhold at oracle.com wrote:
>>> How much of this can we parameterize and/or automate?
>> 
>> I suspect quite a bit, as you present below, and i agree we should try
>> and automate as much as possible. At the moment it?s very
>> spaghetti-like and quite fragile.
>> 
>> I suggest we get the initial version bump for 11 out of the way as
>> soon as JDK 10 branches off from the mainline then work on automation
>> for subsequent releases.
> 
> I understand that other incoming changes are waiting for the 11 version
> bump, but can't we at least do the straightforward parameterizations and
> introduce _CURRENT constants in this round?  We can leave anything that
> requires code generation to post-11.
> 

On the lang tools side that does seem easy, but I?ll defer to Joe.

With some guidance from the build engineers i would gladly consolidate class file version declaration in C/++ files with a passed in macro, if this can be expediently worked out. I wanna push condy as early as possible in 11 :-)
If we could do something in jvm.h that would be ideal. We already have the definitions JVM_CLASSFILE_MAJOR_VERSION and JVM_CLASSFILE_MINOR_VERSION pulled in via classfile_constants.h, so how can the build process inject values into those macros?

For class file versions embedded in Java code it would make it easier if we had programmatic access. Perhaps we could have static methods on Runtime.Version to get the major/minor class file versions?

Paul.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 873 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171213/cfc4cdca/signature-0001.asc>

From cushon at google.com  Thu Dec 14 01:03:27 2017
From: cushon at google.com (Liam Miller-Cushon)
Date: Wed, 13 Dec 2017 20:03:27 -0500
Subject: Do package-infos need to be reset between annotation processing
 rounds?
In-Reply-To: <40864745-48ce-740e-f35f-2454625fc484@oracle.com>
References: <CAL4QsgswjOw3E5=X2B5oKARGBMRYS2a+9-1=jFMePXKh6z-9GA@mail.gmail.com>
 <5A273DEB.5060402@oracle.com>
 <CAL4QsgtTYEDtGHamouGj4JkVbZzBmEMC0ZjopYc9BEcSS8D=qA@mail.gmail.com>
 <5A275146.3080903@oracle.com>
 <CAL4QsgtmieC+a1vi9FremH3T2emMTuxqO_YLJrPq6V2T3xm1Og@mail.gmail.com>
 <7c9034fd-c538-44a0-95b6-c0b91ee71f43@oracle.com>
 <ae24b1cb-ee8d-e3fd-7af0-8d949de96a21@oracle.com>
 <40864745-48ce-740e-f35f-2454625fc484@oracle.com>
Message-ID: <CAL4Qsgs+tXicnkFpG+u2XMMBoiCVft+-WtX5U0krqkqRQy-z6g@mail.gmail.com>

Hello,

> the sourcefile field of the PackageSymbol doesn't seem to be getting set
to a non-null value via the lookup process. I didn't fully run down which
part of JavacElements or Symbol takes care of that.

It looks like PackageSymbol.sourcefile is only initialized by
JavadocClassFinder. PackageSymbol.package_info.sourcefile does get set up
correctly in Enter, so using `existingPackage.package_info.sourcefile` (or
setting the PackageSymbol's sourcefile in Enter at the same time as
package_info) allows the test to pass, i.e.:

    private boolean containedInInitialInputs(String typename) {
...
            if (existingPackage != null && existingPackage.package_info !=
null)
                sourceFile = existingPackage.package_info.sourcefile;
or:

--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java
@@ -379,6 +379,7 @@
             c.completer = Completer.NULL_COMPLETER;
                 c.members_field = WriteableScope.create(c);
                 tree.packge.package_info = c;
+                tree.packge.sourcefile = tree.sourcefile;
             }

And to check my understanding: the issue you discovered is separate from
both JDK-8193037 and JDK-8193216, right? Does my diagnosis of JDK-8193037
sound reasonable? And for JDK-8193216, do you think it makes sense to
consider warning in that case, even if it isn't required by the spec?

Thanks,
Liam

On Wed, Dec 13, 2017 at 1:51 PM, joe darcy <joe.darcy at oracle.com> wrote:

> PS Filed
>
>     JDK-8193462: Fix Filer handling of package-info initial elements
>
> The not-quite-working version of the fix is at:
>
>     http://cr.openjdk.java.net/~darcy/8193462.0/
>
> -Joe
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171213/b457c62f/attachment.html>

From joe.darcy at oracle.com  Thu Dec 14 01:14:00 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 13 Dec 2017 17:14:00 -0800
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <20171213131843.760702080@eggemoggin.niobe.net>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com>
 <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com>
 <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com>
 <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com>
 <33cac77e-a465-92c0-464e-9e086699786b@oracle.com>
 <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com>
 <20171213131843.760702080@eggemoggin.niobe.net>
Message-ID: <32b572b1-c1fb-8201-0438-261b6de76a2d@oracle.com>

Hello,


On 12/13/2017 1:18 PM, mark.reinhold at oracle.com wrote:
> 2017/12/13 8:44:33 -0800, paul.sandoz at oracle.com:
>>> On 12 Dec 2017, at 20:56, david.holmes at oracle.com wrote:

[snip]

>>>
>>> Looking at Joe's webrev, many of the changes from 10 to 11 could instead
>>> be changed to Runtime.getRuntime().version().major() (in Java code) or
>>> VERSION_FEATURE (in Makefiles).
>>>
>>> In javax.lang.model.SourceVersion we could define a new constant, say
>>> RELEASE_CURRENT, whose value is that of the latest release.  Then
>>> annotations such as
>>>
>>>    @SupportedSourceVersion(SourceVersion.RELEASE_11)
>>>
>>> could be replaced by
>>>
>>>    @SupportedSourceVersion(SourceVersion.RELEASE_CURRENT)
>>>
>>> Similarly, JDK_CURRENT could be defined in com.sun.tools.javac.Target
>>> and then many references to JDK10 could instead refer to that.
>>>
>>> In cases where additional code is needed, can we generate it during
>>> the build via another Gensrc*.gmk Makefile?  That'd be more work now,
>>> but it could save us a lot of time in the long run.
>>>

Some comments on the design of javax.lang.model API. The SourceVersion 
enum type has two methods

     latest()
     latestSupported()

The former returns the value corresponding to the proposed 
RELEASE_CURRENT. The latter's behavior is a bit more complicated and 
depends on the version of JDK upon which the javax.lang.model API is 
running. (It is supported and technically possible to run the 
javax.lang.model API from JDK (N+1) on top of JDK N; in that case 
latestSupported() returns RELEASE_{$N} rather than RELEASE_{$N+1}.)

By design, the results of SourceVersion. latest() are not a JLS 15.28 
"Constant Expressions" [1] and thus cannot be used to populate 
annotations directly. During JSR 269 we did consider defining a constant 
or enum constant like RELEASE_CURRENT, but rejected this for a few 
reasons. First, this value would not be a constant across time since the 
current release keeps changing. Given the compile-constants-into-class 
files behavior of javac, in general there would be subtle source 
compatibility implications to evolving the constant. In particular, a 
recompile would be necessary to pick up the revised "constant" value.

One intended use of the SourceVersion enum constants is for annotation 
processors to indicate which source versions they support as part of the 
processor <-> compiler handshake described in 
javax.annotation.processing.Processor. Supporting a new source version 
can require nontrivial updates to the logic of a processor since new 
kinds of constructs can be added to the language. Therefore, it would 
also be an attractive nuisance to make annotating a processor type with 
@SupportedSourceVersion(SourceVersion.RELEASE_CURRENT) too easy since 
the claim could easily not be true.

(Processors can get this effect today if they override 
AbstractProcessor.getSupportedSourceVersion() to return 
SourceVersion.latest() or write their own Processor implementation from 
scratch to do so.)

For these reasons, I don't think it is prudent to have a public API for 
RELEASE_CURRENT as a constant. However, it is reasonable in limited 
contexts such as within the javac testing code to use that patterns and 
I'll adjust the next iteration of the webrev accordingly.

Cheers,

-Joe

[1] https://docs.oracle.com/javase/specs/jls/se9/html/jls-15.html#jls-15.28

[2] 
http://download.java.net/java/jdk10/docs/api/javax/annotation/processing/Processor.html 



From david.holmes at oracle.com  Thu Dec 14 01:16:18 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 14 Dec 2017 11:16:18 +1000
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <c682f2f2-94f8-cb17-37a9-a3a56247aa92@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com>
 <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com>
 <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com>
 <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com>
 <33cac77e-a465-92c0-464e-9e086699786b@oracle.com>
 <c682f2f2-94f8-cb17-37a9-a3a56247aa92@oracle.com>
Message-ID: <66b253ae-ad36-846b-da02-b2b7831912f3@oracle.com>

Hi Joe,

On 14/12/2017 4:36 AM, joe darcy wrote:
> There are various changes associated with a JDK N to (N+1) update 
> including (but not limited to):
> 
>  ??? 1) New -source/-target value in javac
>  ??? 2) Make new -source/-target value the default in javac
>  ??? 3) Change build of the JDK to use new -source/-target
>  ??? 4) Increment version
>  ??? 5) Support new --release value in javac
>  ??? 6) Output new class file format
>  ??? 7) Have HotSpot accept new class file format
>  ??? ...
> 
> For the last few releases, we've done 1) through 4) in b01 of the new 
> release, although typically via multiple changesets since 4) has been 
> done separately from 1) through 3) and 3) had to be done separately from 
> 1) and 2) since different repos were affected before the repo 
> consolidation.
> 
> It is desirable but not strictly necessary to bundle this set of updates 
> into as few changesets as possible. In particular, I think it is 
> acceptable if the master repo has source code states before the first 
> promoted build where not all of 1) through 4) are fixed.

So what is currently being proposed would seem to be:

 >      1) New -source/-target value in javac
 >      2) Make new -source/-target value the default in javac
 >      3) Change build of the JDK to use new -source/-target
 >      6) Output new class file format
 >      7) Have HotSpot accept new class file format

for b01, with:

 >      4) Increment version
 >      5) Support new --release value in javac
+ whatever hotspot needs for new version, after that.

David
-----

> Cheers,
> 
> -Joe

From joe.darcy at oracle.com  Thu Dec 14 01:27:35 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 13 Dec 2017 17:27:35 -0800
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <66b253ae-ad36-846b-da02-b2b7831912f3@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com>
 <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com>
 <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com>
 <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com>
 <33cac77e-a465-92c0-464e-9e086699786b@oracle.com>
 <c682f2f2-94f8-cb17-37a9-a3a56247aa92@oracle.com>
 <66b253ae-ad36-846b-da02-b2b7831912f3@oracle.com>
Message-ID: <4e3a5a23-5eea-1d45-9262-ca5affbc1e30@oracle.com>

Hi David,


On 12/13/2017 5:16 PM, David Holmes wrote:
> Hi Joe,
>
> On 14/12/2017 4:36 AM, joe darcy wrote:
>> There are various changes associated with a JDK N to (N+1) update 
>> including (but not limited to):
>>
>>      1) New -source/-target value in javac
>>      2) Make new -source/-target value the default in javac
>>      3) Change build of the JDK to use new -source/-target
>>      4) Increment version
>>      5) Support new --release value in javac
>>      6) Output new class file format
>>      7) Have HotSpot accept new class file format
>>      ...
>>
>> For the last few releases, we've done 1) through 4) in b01 of the new 
>> release, although typically via multiple changesets since 4) has been 
>> done separately from 1) through 3) and 3) had to be done separately 
>> from 1) and 2) since different repos were affected before the repo 
>> consolidation.
>>
>> It is desirable but not strictly necessary to bundle this set of 
>> updates into as few changesets as possible. In particular, I think it 
>> is acceptable if the master repo has source code states before the 
>> first promoted build where not all of 1) through 4) are fixed.
>
> So what is currently being proposed would seem to be:
>
> >      1) New -source/-target value in javac
> >      2) Make new -source/-target value the default in javac
> >      3) Change build of the JDK to use new -source/-target
> >      6) Output new class file format
> >      7) Have HotSpot accept new class file format
>
> for b01, with:
>
> >      4) Increment version
> >      5) Support new --release value in javac
> + whatever hotspot needs for new version, after that.
>

The changes out for review, mine plus Paul's combined, do cover the 
first batch of items you list above. Items 4) and 5) could still occur 
in b01, even if not bundled with this group of changesets.

One could argue that ideally the full grouping of changes covering all 
these items should occur as the first changeset of a new release. Maybe 
we'll get there after another round or two of practice :-)

-Joe

From cushon at google.com  Thu Dec 14 02:02:23 2017
From: cushon at google.com (Liam Miller-Cushon)
Date: Wed, 13 Dec 2017 21:02:23 -0500
Subject: RFR 8189708: class reading issue with named and annotated
 parameters
In-Reply-To: <5A3124BE.6020202@oracle.com>
References: <CAL4QsgtDfRxacW3iWS_+1RxorSHin9_OCV+PUXw=shH+zD0H7Q@mail.gmail.com>
 <59E9A5B5.5060200@oracle.com>
 <CAL4Qsguo_rcHUYKNKuavFQO1QDA-T8xTWtO_abPZuqT-oy3DVQ@mail.gmail.com>
 <CAL4QsgsFpyKG3fVrwzrtpat6La_Mm8X6tm5n=P+Qwf3+q7E5MQ@mail.gmail.com>
 <CAL4Qsgt3opbb5APWhigjHgQw_0hO4t_AR6AsdURZpovbdz6ikQ@mail.gmail.com>
 <5A3124BE.6020202@oracle.com>
Message-ID: <CAL4Qsgu==iRbTuZ8oHO1P7cBFnR7Pt2FDT99KRWR6fuXsGNccQ@mail.gmail.com>

Thanks,

I updated the copyright header and moved the tests to the correct location:
http://cr.openjdk.java.net/~cushon/8007720/webrev.02/

Also - note that the patch currently includes a fix for JDK-8177486 as
well, since you suggested I add test coverage for enum and inner class
constructors, and mandated parameters aren't handled correctly without
fixing the other bug. Is it OK to have one changeset for both issues, or
should they be separated out? I could remove the enum and inner class test
coverage and the fix, and then add it back in as a follow-up change if you
prefer.

On Wed, Dec 13, 2017 at 8:01 AM, Jan Lahoda <jan.lahoda at oracle.com> wrote:

> Sorry for late reply.
>
> Seems OK to me, only:
> -the tests should be in:
> test/langtools/tools/javac/MethodParameters/8189708
> not in:
> test/tools/javac/MethodParameters/8189708
>
> -test/tools/javac/MethodParameters/8189708/Test.java has a weird license
> header
>
> Vicente, could you please take a look as well?
>
> Thanks,
>     Jan
>
> On 4.12.2017 22:37, Liam Miller-Cushon wrote:
>
>> Hi, is there any more feedback on this?
>>
>> On Fri, Oct 20, 2017 at 5:51 PM, Liam Miller-Cushon <cushon at google.com
>> <mailto:cushon at google.com>> wrote:
>>
>>     Here's an updated patch that incorporates your approach:
>>     http://cr.openjdk.java.net/~cushon/8007720/webrev.01/
>>     <http://cr.openjdk.java.net/~cushon/8007720/webrev.01/>
>>
>>     I included the fix for JDK-8177486 so I could test the inner class /
>>     enum constructor case. If this looks like it's on the right track
>>     I'll move that part (and the corresponding tests) back into a
>>     separate change.
>>
>>     On Fri, Oct 20, 2017 at 9:30 AM, Liam Miller-Cushon
>>     <cushon at google.com <mailto:cushon at google.com>> wrote:
>>
>>         Thanks for the comments,
>>
>>         On Fri, Oct 20, 2017 at 12:28 AM, Jan Lahoda
>>         <jan.lahoda at oracle.com <mailto:jan.lahoda at oracle.com>> wrote:
>>
>>             -what happens if there are both runtime invisible and
>>             visible annotations of method's parameters? Seems those that
>>             appear later will overwrite those that appear sooner?
>>
>>
>>         Oops, thanks. The way your patch handles that looks good to me.
>>
>>             -the MethodSymbol.savedParameterAnnotations is only used
>>             during reading inside the ClassReader, right? It seems
>>             wasteful to have it as a field on each MethodSymbol, better
>>             would be a field in ClassReader.
>>
>>
>>         Sounds good. I'll try to avoid having savedParameterNames as a
>>         field in MethodSymbol also. Do you remember if you encountered
>>         any issues with that in your patch?
>>
>>             -please check what happens for annotations on constructors
>>             of enums/non-static innerclasses
>>
>>
>>         Will do. (Also, note that there appears to be an issue with
>>         reading MethodParameters on constructors of enums/non-static
>>         inner classes: JDK-8177486)
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171213/da1e05b4/attachment-0001.html>

From joe.darcy at oracle.com  Thu Dec 14 03:17:56 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 13 Dec 2017 19:17:56 -0800
Subject: JDK 10 RFR of JDK-8193489: Add information about local variable type
 inference to SourceVersion.RELEASE_10
Message-ID: <a942776f-7922-889c-c62d-11dc66fece50@oracle.com>

Hello,

The javadoc for the enum constants in javax.lang.model.SourceVersion 
have short informative descriptions of the languages changes in each 
release. The text for SourceVersion.RELEASE_10 should be updated to 
mention local variable type inference (var).

Please review the patch below which adds this text.

Thanks,

-Joe

--- 
a/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java 
Wed Dec 13 17:28:24 2017 -0800
+++ 
b/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java 
Wed Dec 13 19:11:55 2017 -0800
@@ -56,7 +56,7 @@
       * 1.7: diamond syntax, try-with-resources, etc.
       * 1.8: lambda expressions and default methods
       *   9: modules, small cleanups to 1.7 and 1.8 changes
-     *  10: to-be-determined changes
+     *  10: local variable type inference (var)
       */

      /**
@@ -157,9 +157,20 @@
       * The version recognized by the Java Platform, Standard Edition
       * 10.
       *
+     * Additions in this release include local variable type inference
+     * ({@code var}).
+     *
       * @since 10
       */
       RELEASE_10;



From sundararajan.athijegannathan at oracle.com  Thu Dec 14 03:36:23 2017
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Thu, 14 Dec 2017 09:06:23 +0530
Subject: JDK 10 RFR of JDK-8193489: Add information about local variable
 type inference to SourceVersion.RELEASE_10
In-Reply-To: <a942776f-7922-889c-c62d-11dc66fece50@oracle.com>
References: <a942776f-7922-889c-c62d-11dc66fece50@oracle.com>
Message-ID: <5A31F1B7.7040903@oracle.com>

Looks good

-Sundar

On 14/12/17, 8:47 AM, joe darcy wrote:
> Hello,
>
> The javadoc for the enum constants in javax.lang.model.SourceVersion 
> have short informative descriptions of the languages changes in each 
> release. The text for SourceVersion.RELEASE_10 should be updated to 
> mention local variable type inference (var).
>
> Please review the patch below which adds this text.
>
> Thanks,
>
> -Joe
>
> --- 
> a/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java 
> Wed Dec 13 17:28:24 2017 -0800
> +++ 
> b/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java 
> Wed Dec 13 19:11:55 2017 -0800
> @@ -56,7 +56,7 @@
>       * 1.7: diamond syntax, try-with-resources, etc.
>       * 1.8: lambda expressions and default methods
>       *   9: modules, small cleanups to 1.7 and 1.8 changes
> -     *  10: to-be-determined changes
> +     *  10: local variable type inference (var)
>       */
>
>      /**
> @@ -157,9 +157,20 @@
>       * The version recognized by the Java Platform, Standard Edition
>       * 10.
>       *
> +     * Additions in this release include local variable type inference
> +     * ({@code var}).
> +     *
>       * @since 10
>       */
>       RELEASE_10;
>
>

From mark.reinhold at oracle.com  Thu Dec 14 03:39:31 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 13 Dec 2017 19:39:31 -0800
Subject: JDK 10 RFR of JDK-8193489: Add information about local variable
 type inference to SourceVersion.RELEASE_10
In-Reply-To: <a942776f-7922-889c-c62d-11dc66fece50@oracle.com>
References: <a942776f-7922-889c-c62d-11dc66fece50@oracle.com>
Message-ID: <20171213193931.649460511@eggemoggin.niobe.net>

2017/12/13 19:17:56 -0800, joe.darcy at oracle.com:
> The javadoc for the enum constants in javax.lang.model.SourceVersion 
> have short informative descriptions of the languages changes in each 
> release. The text for SourceVersion.RELEASE_10 should be updated to 
> mention local variable type inference (var).
> 
> Please review the patch below which adds this text.

-     *  10: to-be-determined changes
+     *  10: local variable type inference (var)

+     * Additions in this release include local variable type inference

In both hunks use "local-variable type" (as in the name of its JEP, 286)
so as to distinguish it from "local variable-type".

Otherwise, looks good.

- Mark

From mark.reinhold at oracle.com  Thu Dec 14 03:51:08 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 13 Dec 2017 19:51:08 -0800
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <74E8560B-F02D-47CB-9A60-DC6BA4115AD2@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com>
 <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com>
 <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com>
 <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com>
 <33cac77e-a465-92c0-464e-9e086699786b@oracle.com>
 <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com>
 <20171213131843.760702080@eggemoggin.niobe.net>
 <27501B2F-A608-43FD-9093-9CE9F2AB7E6D@oracle.com>
 <20171213143635.259953232@eggemoggin.niobe.net>
 <74E8560B-F02D-47CB-9A60-DC6BA4115AD2@oracle.com>
Message-ID: <20171213195108.806956474@eggemoggin.niobe.net>

2017/12/13 15:49:53 -0800, paul.sandoz at oracle.com:
> On 13 Dec 2017, at 14:36, mark.reinhold at oracle.com wrote:
>> I understand that other incoming changes are waiting for the 11 version
>> bump, but can't we at least do the straightforward parameterizations and
>> introduce _CURRENT constants in this round?  We can leave anything that
>> requires code generation to post-11.
> 
> On the lang tools side that does seem easy, but I?ll defer to Joe.
> 
> With some guidance from the build engineers i would gladly consolidate
> class file version declaration in C/++ files with a passed in macro,
> if this can be expediently worked out. I wanna push condy as early as
> possible in 11 :-)

Understood, but let's do the right thing (or at least closer to that)
with this yak while we're here.

> If we could do something in jvm.h that would be ideal. We already have
> the definitions JVM_CLASSFILE_MAJOR_VERSION and
> JVM_CLASSFILE_MINOR_VERSION pulled in via classfile_constants.h, so
> how can the build process inject values into those macros?

I just went through this for the versioning changes.  The attached patch
(against d2a837cf9ff1) does what you want, I think.

> For class file versions embedded in Java code it would make it easier
> if we had programmatic access. Perhaps we could have static methods on
> Runtime.Version to get the major/minor class file versions?

Sure, or maybe better to make them instance methods of Runtime.  Parsing
`System.getProperty("java.class.version")` every time is no fun.

- Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: conf-cf-version
Type: text/x-patch
Size: 4563 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171213/d5ca5fab/conf-cf-version.bin>

From david.holmes at oracle.com  Thu Dec 14 04:40:31 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 14 Dec 2017 14:40:31 +1000
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <20171213195108.806956474@eggemoggin.niobe.net>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com>
 <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com>
 <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com>
 <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com>
 <33cac77e-a465-92c0-464e-9e086699786b@oracle.com>
 <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com>
 <20171213131843.760702080@eggemoggin.niobe.net>
 <27501B2F-A608-43FD-9093-9CE9F2AB7E6D@oracle.com>
 <20171213143635.259953232@eggemoggin.niobe.net>
 <74E8560B-F02D-47CB-9A60-DC6BA4115AD2@oracle.com>
 <20171213195108.806956474@eggemoggin.niobe.net>
Message-ID: <fbb3eb65-7f6c-d905-dfc2-f1feda6016a9@oracle.com>

On 14/12/2017 1:51 PM, mark.reinhold at oracle.com wrote:
> 2017/12/13 15:49:53 -0800, paul.sandoz at oracle.com:
>> On 13 Dec 2017, at 14:36, mark.reinhold at oracle.com wrote:
>>> I understand that other incoming changes are waiting for the 11 version
>>> bump, but can't we at least do the straightforward parameterizations and
>>> introduce _CURRENT constants in this round?  We can leave anything that
>>> requires code generation to post-11.
>>
>> On the lang tools side that does seem easy, but I?ll defer to Joe.
>>
>> With some guidance from the build engineers i would gladly consolidate
>> class file version declaration in C/++ files with a passed in macro,
>> if this can be expediently worked out. I wanna push condy as early as
>> possible in 11 :-)
> 
> Understood, but let's do the right thing (or at least closer to that)
> with this yak while we're here.
> 
>> If we could do something in jvm.h that would be ideal. We already have
>> the definitions JVM_CLASSFILE_MAJOR_VERSION and
>> JVM_CLASSFILE_MINOR_VERSION pulled in via classfile_constants.h, so
>> how can the build process inject values into those macros?
> 
> I just went through this for the versioning changes.  The attached patch
> (against d2a837cf9ff1) does what you want, I think.

We can't do that. 
src/java.base/share/native/include/classfile_constants.h is an exported 
interface - at least at present - so it can't depend on something that 
has to come from the build. You'd have to generate the exported version 
with the appropriate value substituted.

David
-----

>> For class file versions embedded in Java code it would make it easier
>> if we had programmatic access. Perhaps we could have static methods on
>> Runtime.Version to get the major/minor class file versions?
> 
> Sure, or maybe better to make them instance methods of Runtime.  Parsing
> `System.getProperty("java.class.version")` every time is no fun.
> 
> - Mark
> 

From Alan.Bateman at oracle.com  Thu Dec 14 09:12:59 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 14 Dec 2017 09:12:59 +0000
Subject: 8193503: javah launcher was not removed by JDK-8191054
Message-ID: <e8ca12d6-1ed6-aca7-6d8e-b8a44d731b3a@oracle.com>

Jon removed the code for javah from the jdk.compiler module with 
JDK-8191054 but the build still creates a launcher that is now DOA with 
"Error: Could not find or load main class com.sun.tools.javah.Main in 
module jdk.compiler". This is caught by one of the launcher tests that 
checks the options of every tool in the bin directory.

The changes to drop the build of the javah launcher are trivial and I 
think we should get this into jdk/jdk before the fork for jdk/jdk10.

-Alan


diff --git a/make/launcher/Launcher-jdk.compiler.gmk 
b/make/launcher/Launcher-jdk.compiler.gmk
--- a/make/launcher/Launcher-jdk.compiler.gmk
+++ b/make/launcher/Launcher-jdk.compiler.gmk
@@ -1,5 +1,5 @@
 ?#
-# Copyright (c) 2011, 2016, Oracle and/or its affiliates. All rights 
reserved.
+# Copyright (c) 2011, 2017, Oracle and/or its affiliates. All rights 
reserved.
 ?# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 ?#
 ?# This code is free software; you can redistribute it and/or modify it
@@ -31,11 +31,6 @@
 ??? CFLAGS := -DEXPAND_CLASSPATH_WILDCARDS, \
 ?))

-$(eval $(call SetupBuildLauncher, javah, \
-??? MAIN_CLASS := com.sun.tools.javah.Main, \
-??? CFLAGS := -DEXPAND_CLASSPATH_WILDCARDS, \
-))
-
 ?$(eval $(call SetupBuildLauncher, serialver, \
 ???? MAIN_CLASS := sun.tools.serialver.SerialVer, \
 ???? CFLAGS := -DEXPAND_CLASSPATH_WILDCARDS, \
diff --git a/test/jdk/tools/launcher/ToolsOpts.java 
b/test/jdk/tools/launcher/ToolsOpts.java
--- a/test/jdk/tools/launcher/ToolsOpts.java
+++ b/test/jdk/tools/launcher/ToolsOpts.java
@@ -1,5 +1,5 @@
 ?/*
- * Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2012, 2017, Oracle and/or its affiliates. All rights 
reserved.
 ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 ? *
 ? * This code is free software; you can redistribute it and/or modify it
@@ -24,7 +24,7 @@
 ?/*
 ? * @test
 ? * @bug 8002091
- * @summary Test options patterns for javac,javah,javap and javadoc using
+ * @summary Test options patterns for javac,javap and javadoc using
 ? * javac as a test launcher. Create a dummy javac and intercept 
options to check
 ? * reception of options as passed through the launcher without having 
to launch
 ? * javac. Only -J and -cp ./* options should be consumed by the launcher.

From erik.joelsson at oracle.com  Thu Dec 14 09:21:22 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 14 Dec 2017 10:21:22 +0100
Subject: 8193503: javah launcher was not removed by JDK-8191054
In-Reply-To: <e8ca12d6-1ed6-aca7-6d8e-b8a44d731b3a@oracle.com>
References: <e8ca12d6-1ed6-aca7-6d8e-b8a44d731b3a@oracle.com>
Message-ID: <acccf0fd-f46f-d434-caa2-4e9bfba04e6d@oracle.com>

Looks good!

/Erik


On 2017-12-14 10:12, Alan Bateman wrote:
> Jon removed the code for javah from the jdk.compiler module with 
> JDK-8191054 but the build still creates a launcher that is now DOA 
> with "Error: Could not find or load main class 
> com.sun.tools.javah.Main in module jdk.compiler". This is caught by 
> one of the launcher tests that checks the options of every tool in the 
> bin directory.
>
> The changes to drop the build of the javah launcher are trivial and I 
> think we should get this into jdk/jdk before the fork for jdk/jdk10.
>
> -Alan
>
>
> diff --git a/make/launcher/Launcher-jdk.compiler.gmk 
> b/make/launcher/Launcher-jdk.compiler.gmk
> --- a/make/launcher/Launcher-jdk.compiler.gmk
> +++ b/make/launcher/Launcher-jdk.compiler.gmk
> @@ -1,5 +1,5 @@
> ?#
> -# Copyright (c) 2011, 2016, Oracle and/or its affiliates. All rights 
> reserved.
> +# Copyright (c) 2011, 2017, Oracle and/or its affiliates. All rights 
> reserved.
> ?# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> ?#
> ?# This code is free software; you can redistribute it and/or modify it
> @@ -31,11 +31,6 @@
> ??? CFLAGS := -DEXPAND_CLASSPATH_WILDCARDS, \
> ?))
>
> -$(eval $(call SetupBuildLauncher, javah, \
> -??? MAIN_CLASS := com.sun.tools.javah.Main, \
> -??? CFLAGS := -DEXPAND_CLASSPATH_WILDCARDS, \
> -))
> -
> ?$(eval $(call SetupBuildLauncher, serialver, \
> ???? MAIN_CLASS := sun.tools.serialver.SerialVer, \
> ???? CFLAGS := -DEXPAND_CLASSPATH_WILDCARDS, \
> diff --git a/test/jdk/tools/launcher/ToolsOpts.java 
> b/test/jdk/tools/launcher/ToolsOpts.java
> --- a/test/jdk/tools/launcher/ToolsOpts.java
> +++ b/test/jdk/tools/launcher/ToolsOpts.java
> @@ -1,5 +1,5 @@
> ?/*
> - * Copyright (c) 2012, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 2012, 2017, Oracle and/or its affiliates. All rights 
> reserved.
> ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> ? *
> ? * This code is free software; you can redistribute it and/or modify it
> @@ -24,7 +24,7 @@
> ?/*
> ? * @test
> ? * @bug 8002091
> - * @summary Test options patterns for javac,javah,javap and javadoc 
> using
> + * @summary Test options patterns for javac,javap and javadoc using
> ? * javac as a test launcher. Create a dummy javac and intercept 
> options to check
> ? * reception of options as passed through the launcher without having 
> to launch
> ? * javac. Only -J and -cp ./* options should be consumed by the 
> launcher.


From joe.darcy at oracle.com  Thu Dec 14 09:30:33 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Thu, 14 Dec 2017 01:30:33 -0800
Subject: 8193503: javah launcher was not removed by JDK-8191054
In-Reply-To: <e8ca12d6-1ed6-aca7-6d8e-b8a44d731b3a@oracle.com>
References: <e8ca12d6-1ed6-aca7-6d8e-b8a44d731b3a@oracle.com>
Message-ID: <691829f1-282f-bf7f-ab74-85dcdda6ca2a@oracle.com>

On 12/14/2017 1:12 AM, Alan Bateman wrote:
> Jon removed the code for javah from the jdk.compiler module with 
> JDK-8191054 but the build still creates a launcher that is now DOA 
> with "Error: Could not find or load main class 
> com.sun.tools.javah.Main in module jdk.compiler". This is caught by 
> one of the launcher tests that checks the options of every tool in the 
> bin directory.
>
> The changes to drop the build of the javah launcher are trivial and I 
> think we should get this into jdk/jdk before the fork for jdk/jdk10.

I added a similar comment in JDK-8193492: 
tools/launcher/VersionCheck.java need to be updated after JDK-8191054

https://bugs.openjdk.java.net/browse/JDK-8193492?focusedCommentId=14140245&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14140245

and with the update to Launcher-jdk.compiler.gmk the javah binary does 
indeed seem to be omitted from the bin dir.

+1

-Joe

>
> -Alan
>
>
> diff --git a/make/launcher/Launcher-jdk.compiler.gmk 
> b/make/launcher/Launcher-jdk.compiler.gmk
> --- a/make/launcher/Launcher-jdk.compiler.gmk
> +++ b/make/launcher/Launcher-jdk.compiler.gmk
> @@ -1,5 +1,5 @@
>  #
> -# Copyright (c) 2011, 2016, Oracle and/or its affiliates. All rights 
> reserved.
> +# Copyright (c) 2011, 2017, Oracle and/or its affiliates. All rights 
> reserved.
>  # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  #
>  # This code is free software; you can redistribute it and/or modify it
> @@ -31,11 +31,6 @@
>     CFLAGS := -DEXPAND_CLASSPATH_WILDCARDS, \
>  ))
>
> -$(eval $(call SetupBuildLauncher, javah, \
> -    MAIN_CLASS := com.sun.tools.javah.Main, \
> -    CFLAGS := -DEXPAND_CLASSPATH_WILDCARDS, \
> -))
> -
>  $(eval $(call SetupBuildLauncher, serialver, \
>      MAIN_CLASS := sun.tools.serialver.SerialVer, \
>      CFLAGS := -DEXPAND_CLASSPATH_WILDCARDS, \
> diff --git a/test/jdk/tools/launcher/ToolsOpts.java 
> b/test/jdk/tools/launcher/ToolsOpts.java
> --- a/test/jdk/tools/launcher/ToolsOpts.java
> +++ b/test/jdk/tools/launcher/ToolsOpts.java
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2012, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 2012, 2017, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -24,7 +24,7 @@
>  /*
>   * @test
>   * @bug 8002091
> - * @summary Test options patterns for javac,javah,javap and javadoc 
> using
> + * @summary Test options patterns for javac,javap and javadoc using
>   * javac as a test launcher. Create a dummy javac and intercept 
> options to check
>   * reception of options as passed through the launcher without having 
> to launch
>   * javac. Only -J and -cp ./* options should be consumed by the 
> launcher.


From erik.joelsson at oracle.com  Thu Dec 14 09:37:27 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 14 Dec 2017 10:37:27 +0100
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <fbb3eb65-7f6c-d905-dfc2-f1feda6016a9@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com>
 <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com>
 <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com>
 <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com>
 <33cac77e-a465-92c0-464e-9e086699786b@oracle.com>
 <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com>
 <20171213131843.760702080@eggemoggin.niobe.net>
 <27501B2F-A608-43FD-9093-9CE9F2AB7E6D@oracle.com>
 <20171213143635.259953232@eggemoggin.niobe.net>
 <74E8560B-F02D-47CB-9A60-DC6BA4115AD2@oracle.com>
 <20171213195108.806956474@eggemoggin.niobe.net>
 <fbb3eb65-7f6c-d905-dfc2-f1feda6016a9@oracle.com>
Message-ID: <1416fd03-cee1-2fb8-f672-6bb3fef07bd6@oracle.com>


On 2017-12-14 05:40, David Holmes wrote:
> On 14/12/2017 1:51 PM, mark.reinhold at oracle.com wrote:
>> I just went through this for the versioning changes.? The attached patch
>> (against d2a837cf9ff1) does what you want, I think.
>
> We can't do that. 
> src/java.base/share/native/include/classfile_constants.h is an 
> exported interface - at least at present - so it can't depend on 
> something that has to come from the build. You'd have to generate the 
> exported version with the appropriate value substituted.
>
I'm preparing a patch where we generate classfile_constants.h during the 
build, based on Mark's patch.

/Erik

From erik.joelsson at oracle.com  Thu Dec 14 11:58:13 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 14 Dec 2017 12:58:13 +0100
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <1416fd03-cee1-2fb8-f672-6bb3fef07bd6@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com>
 <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com>
 <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com>
 <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com>
 <33cac77e-a465-92c0-464e-9e086699786b@oracle.com>
 <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com>
 <20171213131843.760702080@eggemoggin.niobe.net>
 <27501B2F-A608-43FD-9093-9CE9F2AB7E6D@oracle.com>
 <20171213143635.259953232@eggemoggin.niobe.net>
 <74E8560B-F02D-47CB-9A60-DC6BA4115AD2@oracle.com>
 <20171213195108.806956474@eggemoggin.niobe.net>
 <fbb3eb65-7f6c-d905-dfc2-f1feda6016a9@oracle.com>
 <1416fd03-cee1-2fb8-f672-6bb3fef07bd6@oracle.com>
Message-ID: <5aa6d969-c5c6-577b-752d-6cc344152407@oracle.com>

And here it is: http://cr.openjdk.java.net/~erikj/8173382/webrev.01/

Feel free to incorporate this into whichever changeset you want, or I 
can push this separately.

/Erik


On 2017-12-14 10:37, Erik Joelsson wrote:
>
> On 2017-12-14 05:40, David Holmes wrote:
>> On 14/12/2017 1:51 PM, mark.reinhold at oracle.com wrote:
>>> I just went through this for the versioning changes.? The attached 
>>> patch
>>> (against d2a837cf9ff1) does what you want, I think.
>>
>> We can't do that. 
>> src/java.base/share/native/include/classfile_constants.h is an 
>> exported interface - at least at present - so it can't depend on 
>> something that has to come from the build. You'd have to generate the 
>> exported version with the appropriate value substituted.
>>
> I'm preparing a patch where we generate classfile_constants.h during 
> the build, based on Mark's patch.
>
> /Erik


From Alan.Bateman at oracle.com  Thu Dec 14 12:51:05 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 14 Dec 2017 12:51:05 +0000
Subject: 8193503: javah launcher was not removed by JDK-8191054
In-Reply-To: <acccf0fd-f46f-d434-caa2-4e9bfba04e6d@oracle.com>
References: <e8ca12d6-1ed6-aca7-6d8e-b8a44d731b3a@oracle.com>
 <acccf0fd-f46f-d434-caa2-4e9bfba04e6d@oracle.com>
Message-ID: <a5dedf60-d135-78ef-99e9-6c4f85870ab0@oracle.com>

On 14/12/2017 09:21, Erik Joelsson wrote:
> Looks good!
>
> /Erik
I'll get this in now and also create another issue to remove the other 
remnants of javah from the build (they won't impact the build output but 
will need to be cleaned up).

-Alan

From vicente.romero at oracle.com  Thu Dec 14 14:28:21 2017
From: vicente.romero at oracle.com (Vicente Romero)
Date: Thu, 14 Dec 2017 09:28:21 -0500
Subject: RFR 8189708: class reading issue with named and annotated
 parameters
In-Reply-To: <CAL4Qsgu==iRbTuZ8oHO1P7cBFnR7Pt2FDT99KRWR6fuXsGNccQ@mail.gmail.com>
References: <CAL4QsgtDfRxacW3iWS_+1RxorSHin9_OCV+PUXw=shH+zD0H7Q@mail.gmail.com>
 <59E9A5B5.5060200@oracle.com>
 <CAL4Qsguo_rcHUYKNKuavFQO1QDA-T8xTWtO_abPZuqT-oy3DVQ@mail.gmail.com>
 <CAL4QsgsFpyKG3fVrwzrtpat6La_Mm8X6tm5n=P+Qwf3+q7E5MQ@mail.gmail.com>
 <CAL4Qsgt3opbb5APWhigjHgQw_0hO4t_AR6AsdURZpovbdz6ikQ@mail.gmail.com>
 <5A3124BE.6020202@oracle.com>
 <CAL4Qsgu==iRbTuZ8oHO1P7cBFnR7Pt2FDT99KRWR6fuXsGNccQ@mail.gmail.com>
Message-ID: <193be90f-20bc-ae50-6606-1d9c6cb5f020@oracle.com>

looks good to me, only one minor comment, consider using a more 
meaningful name for:

test/langtools/tools/javac/MethodParameters/8189708/Test.java

there is no need for another review iteration for this change,

Thanks,
Vicente

On 12/13/2017 09:02 PM, Liam Miller-Cushon wrote:
> Thanks,
>
> I updated the copyright header and moved the tests to the correct 
> location:
> http://cr.openjdk.java.net/~cushon/8007720/webrev.02/ 
> <http://cr.openjdk.java.net/%7Ecushon/8007720/webrev.02/>
>
> Also - note that the patch currently includes a fix for?JDK-8177486 as 
> well, since you suggested I add test coverage for enum and inner class 
> constructors, and mandated parameters aren't handled correctly without 
> fixing the other bug. Is it OK to have one changeset for both issues, 
> or should they be separated out? I could remove the enum and inner 
> class test coverage and the fix, and then add it back in as a 
> follow-up change if you prefer.
>
> On Wed, Dec 13, 2017 at 8:01 AM, Jan Lahoda <jan.lahoda at oracle.com 
> <mailto:jan.lahoda at oracle.com>> wrote:
>
>     Sorry for late reply.
>
>     Seems OK to me, only:
>     -the tests should be in:
>     test/langtools/tools/javac/MethodParameters/8189708
>     not in:
>     test/tools/javac/MethodParameters/8189708
>
>     -test/tools/javac/MethodParameters/8189708/Test.java has a weird
>     license header
>
>     Vicente, could you please take a look as well?
>
>     Thanks,
>     ? ? Jan
>
>     On 4.12.2017 22:37, Liam Miller-Cushon wrote:
>
>         Hi, is there any more feedback on this?
>
>         On Fri, Oct 20, 2017 at 5:51 PM, Liam Miller-Cushon
>         <cushon at google.com <mailto:cushon at google.com>
>         <mailto:cushon at google.com <mailto:cushon at google.com>>> wrote:
>
>         ? ? Here's an updated patch that incorporates your approach:
>         http://cr.openjdk.java.net/~cushon/8007720/webrev.01/
>         <http://cr.openjdk.java.net/%7Ecushon/8007720/webrev.01/>
>         ? ? <http://cr.openjdk.java.net/~cushon/8007720/webrev.01/
>         <http://cr.openjdk.java.net/%7Ecushon/8007720/webrev.01/>>
>
>         ? ? I included the fix for JDK-8177486 so I could test the
>         inner class /
>         ? ? enum constructor case. If this looks like it's on the
>         right track
>         ? ? I'll move that part (and the corresponding tests) back into a
>         ? ? separate change.
>
>         ? ? On Fri, Oct 20, 2017 at 9:30 AM, Liam Miller-Cushon
>         ? ? <cushon at google.com <mailto:cushon at google.com>
>         <mailto:cushon at google.com <mailto:cushon at google.com>>> wrote:
>
>         ? ? ? ? Thanks for the comments,
>
>         ? ? ? ? On Fri, Oct 20, 2017 at 12:28 AM, Jan Lahoda
>         ? ? ? ? <jan.lahoda at oracle.com <mailto:jan.lahoda at oracle.com>
>         <mailto:jan.lahoda at oracle.com <mailto:jan.lahoda at oracle.com>>>
>         wrote:
>
>         ? ? ? ? ? ? -what happens if there are both runtime invisible and
>         ? ? ? ? ? ? visible annotations of method's parameters? Seems
>         those that
>         ? ? ? ? ? ? appear later will overwrite those that appear sooner?
>
>
>         ? ? ? ? Oops, thanks. The way your patch handles that looks
>         good to me.
>
>         ? ? ? ? ? ? -the MethodSymbol.savedParameterAnnotations is
>         only used
>         ? ? ? ? ? ? during reading inside the ClassReader, right? It seems
>         ? ? ? ? ? ? wasteful to have it as a field on each
>         MethodSymbol, better
>         ? ? ? ? ? ? would be a field in ClassReader.
>
>
>         ? ? ? ? Sounds good. I'll try to avoid having
>         savedParameterNames as a
>         ? ? ? ? field in MethodSymbol also. Do you remember if you
>         encountered
>         ? ? ? ? any issues with that in your patch?
>
>         ? ? ? ? ? ? -please check what happens for annotations on
>         constructors
>         ? ? ? ? ? ? of enums/non-static innerclasses
>
>
>         ? ? ? ? Will do. (Also, note that there appears to be an issue
>         with
>         ? ? ? ? reading MethodParameters on constructors of
>         enums/non-static
>         ? ? ? ? inner classes: JDK-8177486)
>
>
>
>

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

From vicente.romero at oracle.com  Thu Dec 14 15:20:56 2017
From: vicente.romero at oracle.com (Vicente Romero)
Date: Thu, 14 Dec 2017 10:20:56 -0500
Subject: RFR 8193216: Filer should warn if processors redefine symbols
 from the classpath or sourcepath
In-Reply-To: <CAL4QsgtP0Sh4tNaS+Odk8fqOSmEfmUmtkRHcaiTAmMwPQWGKpQ@mail.gmail.com>
References: <CAL4QsgtP0Sh4tNaS+Odk8fqOSmEfmUmtkRHcaiTAmMwPQWGKpQ@mail.gmail.com>
Message-ID: <5b2951c4-e0d2-1b4e-3158-fb506874f16c@oracle.com>

looks good,
Vicente

On 12/08/2017 02:52 PM, Liam Miller-Cushon wrote:
> Hello,
>
> Please review the following fix for JDK-8193216. The patch causes 
> Filer to emit a warning if an annotation processor redefines a symbol 
> on the classpath or sourcepath.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8193216
> webrev: http://cr.openjdk.java.net/~cushon/8193216/webrev.00/ 
> <http://cr.openjdk.java.net/%7Ecushon/8193216/webrev.00/>


From paul.sandoz at oracle.com  Thu Dec 14 16:36:58 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 14 Dec 2017 08:36:58 -0800
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <5aa6d969-c5c6-577b-752d-6cc344152407@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com>
 <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com>
 <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com>
 <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com>
 <33cac77e-a465-92c0-464e-9e086699786b@oracle.com>
 <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com>
 <20171213131843.760702080@eggemoggin.niobe.net>
 <27501B2F-A608-43FD-9093-9CE9F2AB7E6D@oracle.com>
 <20171213143635.259953232@eggemoggin.niobe.net>
 <74E8560B-F02D-47CB-9A60-DC6BA4115AD2@oracle.com>
 <20171213195108.806956474@eggemoggin.niobe.net>
 <fbb3eb65-7f6c-d905-dfc2-f1feda6016a9@oracle.com>
 <1416fd03-cee1-2fb8-f672-6bb3fef07bd6@oracle.com>
 <5aa6d969-c5c6-577b-752d-6cc344152407@oracle.com>
Message-ID: <7771FC1F-DA2E-4E63-99DD-8C7348B638C2@oracle.com>



> On 14 Dec 2017, at 03:58, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> And here it is: http://cr.openjdk.java.net/~erikj/8173382/webrev.01/
> 
> Feel free to incorporate this into whichever changeset you want, or I can push this separately.
> 

Thanks! that is exactly what i was looking for. I will merge it into my patch.

Paul.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 873 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171214/03297f13/signature.asc>

From paul.sandoz at oracle.com  Thu Dec 14 16:42:38 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 14 Dec 2017 08:42:38 -0800
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <20171213195108.806956474@eggemoggin.niobe.net>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com>
 <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com>
 <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com>
 <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com>
 <33cac77e-a465-92c0-464e-9e086699786b@oracle.com>
 <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com>
 <20171213131843.760702080@eggemoggin.niobe.net>
 <27501B2F-A608-43FD-9093-9CE9F2AB7E6D@oracle.com>
 <20171213143635.259953232@eggemoggin.niobe.net>
 <74E8560B-F02D-47CB-9A60-DC6BA4115AD2@oracle.com>
 <20171213195108.806956474@eggemoggin.niobe.net>
Message-ID: <792D57C3-183C-4AB6-9D30-3DB60C8EF67E@oracle.com>



> On 13 Dec 2017, at 19:51, mark.reinhold at oracle.com wrote:
> 
> 2017/12/13 15:49:53 -0800, paul.sandoz at oracle.com:
>> On 13 Dec 2017, at 14:36, mark.reinhold at oracle.com wrote:
>>> I understand that other incoming changes are waiting for the 11 version
>>> bump, but can't we at least do the straightforward parameterizations and
>>> introduce _CURRENT constants in this round?  We can leave anything that
>>> requires code generation to post-11.
>> 
>> On the lang tools side that does seem easy, but I?ll defer to Joe.
>> 
>> With some guidance from the build engineers i would gladly consolidate
>> class file version declaration in C/++ files with a passed in macro,
>> if this can be expediently worked out. I wanna push condy as early as
>> possible in 11 :-)
> 
> Understood, but let's do the right thing (or at least closer to that)
> with this yak while we're here.
> 
>> If we could do something in jvm.h that would be ideal. We already have
>> the definitions JVM_CLASSFILE_MAJOR_VERSION and
>> JVM_CLASSFILE_MINOR_VERSION pulled in via classfile_constants.h, so
>> how can the build process inject values into those macros?
> 
> I just went through this for the versioning changes.  The attached patch
> (against d2a837cf9ff1) does what you want, I think.
> 

Thanks, Eric?s patch takes this a few steps further and i will merge that into mine.


>> For class file versions embedded in Java code it would make it easier
>> if we had programmatic access. Perhaps we could have static methods on
>> Runtime.Version to get the major/minor class file versions?
> 
> Sure, or maybe better to make them instance methods of Runtime.

Yes, given Runtime.Version's focus on representing a version string for the platform.


>  Parsing
> `System.getProperty("java.class.version")` every time is no fun.
> 

Indeed. I?ll follow up on this yak shave with a separate issue.

Paul.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 873 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171214/a24155f8/signature.asc>

From jonathan.gibbons at oracle.com  Thu Dec 14 18:41:44 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 14 Dec 2017 10:41:44 -0800
Subject: 8193503: javah launcher was not removed by JDK-8191054
In-Reply-To: <e8ca12d6-1ed6-aca7-6d8e-b8a44d731b3a@oracle.com>
References: <e8ca12d6-1ed6-aca7-6d8e-b8a44d731b3a@oracle.com>
Message-ID: <5A32C5E8.2050702@oracle.com>

Alan,

Thanks for catching and handling this. Sorry for the scramble. I'm 
surprised it wasn't caught by the jdk-tier1 tests I ran before pushing 
the changeset.

-- Jon

On 12/14/2017 01:12 AM, Alan Bateman wrote:
> Jon removed the code for javah from the jdk.compiler module with 
> JDK-8191054 but the build still creates a launcher that is now DOA 
> with "Error: Could not find or load main class 
> com.sun.tools.javah.Main in module jdk.compiler". This is caught by 
> one of the launcher tests that checks the options of every tool in the 
> bin directory.
>
> The changes to drop the build of the javah launcher are trivial and I 
> think we should get this into jdk/jdk before the fork for jdk/jdk10.
>
> -Alan
>
>
> diff --git a/make/launcher/Launcher-jdk.compiler.gmk 
> b/make/launcher/Launcher-jdk.compiler.gmk
> --- a/make/launcher/Launcher-jdk.compiler.gmk
> +++ b/make/launcher/Launcher-jdk.compiler.gmk
> @@ -1,5 +1,5 @@
>  #
> -# Copyright (c) 2011, 2016, Oracle and/or its affiliates. All rights 
> reserved.
> +# Copyright (c) 2011, 2017, Oracle and/or its affiliates. All rights 
> reserved.
>  # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  #
>  # This code is free software; you can redistribute it and/or modify it
> @@ -31,11 +31,6 @@
>     CFLAGS := -DEXPAND_CLASSPATH_WILDCARDS, \
>  ))
>
> -$(eval $(call SetupBuildLauncher, javah, \
> -    MAIN_CLASS := com.sun.tools.javah.Main, \
> -    CFLAGS := -DEXPAND_CLASSPATH_WILDCARDS, \
> -))
> -
>  $(eval $(call SetupBuildLauncher, serialver, \
>      MAIN_CLASS := sun.tools.serialver.SerialVer, \
>      CFLAGS := -DEXPAND_CLASSPATH_WILDCARDS, \
> diff --git a/test/jdk/tools/launcher/ToolsOpts.java 
> b/test/jdk/tools/launcher/ToolsOpts.java
> --- a/test/jdk/tools/launcher/ToolsOpts.java
> +++ b/test/jdk/tools/launcher/ToolsOpts.java
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2012, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 2012, 2017, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -24,7 +24,7 @@
>  /*
>   * @test
>   * @bug 8002091
> - * @summary Test options patterns for javac,javah,javap and javadoc 
> using
> + * @summary Test options patterns for javac,javap and javadoc using
>   * javac as a test launcher. Create a dummy javac and intercept 
> options to check
>   * reception of options as passed through the launcher without having 
> to launch
>   * javac. Only -J and -cp ./* options should be consumed by the 
> launcher.


From cushon at google.com  Thu Dec 14 23:55:54 2017
From: cushon at google.com (Liam Miller-Cushon)
Date: Thu, 14 Dec 2017 18:55:54 -0500
Subject: RFR 8189708: class reading issue with named and annotated
 parameters
In-Reply-To: <193be90f-20bc-ae50-6606-1d9c6cb5f020@oracle.com>
References: <CAL4QsgtDfRxacW3iWS_+1RxorSHin9_OCV+PUXw=shH+zD0H7Q@mail.gmail.com>
 <59E9A5B5.5060200@oracle.com>
 <CAL4Qsguo_rcHUYKNKuavFQO1QDA-T8xTWtO_abPZuqT-oy3DVQ@mail.gmail.com>
 <CAL4QsgsFpyKG3fVrwzrtpat6La_Mm8X6tm5n=P+Qwf3+q7E5MQ@mail.gmail.com>
 <CAL4Qsgt3opbb5APWhigjHgQw_0hO4t_AR6AsdURZpovbdz6ikQ@mail.gmail.com>
 <5A3124BE.6020202@oracle.com>
 <CAL4Qsgu==iRbTuZ8oHO1P7cBFnR7Pt2FDT99KRWR6fuXsGNccQ@mail.gmail.com>
 <193be90f-20bc-ae50-6606-1d9c6cb5f020@oracle.com>
Message-ID: <CAL4QsguwsVrZzJ9ro6r7i-FUmwpX5Lt=ixex+4kp6jzvS4sMfA@mail.gmail.com>

Thanks for the reviews. I renamed the test, and mentioned both of the
associated bugs in the test and the commit message.

The formatted changeset is attached.

On Thu, Dec 14, 2017 at 9:28 AM, Vicente Romero <vicente.romero at oracle.com>
wrote:

> looks good to me, only one minor comment, consider using a more meaningful
> name for:
>
> test/langtools/tools/javac/MethodParameters/8189708/Test.java
>
> there is no need for another review iteration for this change,
>
> Thanks,
> Vicente
>
>
> On 12/13/2017 09:02 PM, Liam Miller-Cushon wrote:
>
> Thanks,
>
> I updated the copyright header and moved the tests to the correct location:
> http://cr.openjdk.java.net/~cushon/8007720/webrev.02/
>
> Also - note that the patch currently includes a fix for JDK-8177486 as
> well, since you suggested I add test coverage for enum and inner class
> constructors, and mandated parameters aren't handled correctly without
> fixing the other bug. Is it OK to have one changeset for both issues, or
> should they be separated out? I could remove the enum and inner class test
> coverage and the fix, and then add it back in as a follow-up change if you
> prefer.
>
> On Wed, Dec 13, 2017 at 8:01 AM, Jan Lahoda <jan.lahoda at oracle.com> wrote:
>
>> Sorry for late reply.
>>
>> Seems OK to me, only:
>> -the tests should be in:
>> test/langtools/tools/javac/MethodParameters/8189708
>> not in:
>> test/tools/javac/MethodParameters/8189708
>>
>> -test/tools/javac/MethodParameters/8189708/Test.java has a weird license
>> header
>>
>> Vicente, could you please take a look as well?
>>
>> Thanks,
>>     Jan
>>
>> On 4.12.2017 22:37, Liam Miller-Cushon wrote:
>>
>>> Hi, is there any more feedback on this?
>>>
>>> On Fri, Oct 20, 2017 at 5:51 PM, Liam Miller-Cushon <cushon at google.com
>>> <mailto:cushon at google.com>> wrote:
>>>
>>>     Here's an updated patch that incorporates your approach:
>>>     http://cr.openjdk.java.net/~cushon/8007720/webrev.01/
>>>     <http://cr.openjdk.java.net/~cushon/8007720/webrev.01/>
>>>
>>>     I included the fix for JDK-8177486 so I could test the inner class /
>>>     enum constructor case. If this looks like it's on the right track
>>>     I'll move that part (and the corresponding tests) back into a
>>>     separate change.
>>>
>>>     On Fri, Oct 20, 2017 at 9:30 AM, Liam Miller-Cushon
>>>     <cushon at google.com <mailto:cushon at google.com>> wrote:
>>>
>>>         Thanks for the comments,
>>>
>>>         On Fri, Oct 20, 2017 at 12:28 AM, Jan Lahoda
>>>         <jan.lahoda at oracle.com <mailto:jan.lahoda at oracle.com>> wrote:
>>>
>>>             -what happens if there are both runtime invisible and
>>>             visible annotations of method's parameters? Seems those that
>>>             appear later will overwrite those that appear sooner?
>>>
>>>
>>>         Oops, thanks. The way your patch handles that looks good to me.
>>>
>>>             -the MethodSymbol.savedParameterAnnotations is only used
>>>             during reading inside the ClassReader, right? It seems
>>>             wasteful to have it as a field on each MethodSymbol, better
>>>             would be a field in ClassReader.
>>>
>>>
>>>         Sounds good. I'll try to avoid having savedParameterNames as a
>>>         field in MethodSymbol also. Do you remember if you encountered
>>>         any issues with that in your patch?
>>>
>>>             -please check what happens for annotations on constructors
>>>             of enums/non-static innerclasses
>>>
>>>
>>>         Will do. (Also, note that there appears to be an issue with
>>>         reading MethodParameters on constructors of enums/non-static
>>>         inner classes: JDK-8177486)
>>>
>>>
>>>
>>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171214/fa6df99e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 8007720.patch
Type: application/octet-stream
Size: 26094 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171214/fa6df99e/8007720-0001.patch>

From cushon at google.com  Fri Dec 15 00:17:07 2017
From: cushon at google.com (Liam Miller-Cushon)
Date: Thu, 14 Dec 2017 19:17:07 -0500
Subject: RFR 8193216: Filer should warn if processors redefine symbols
 from the classpath or sourcepath
In-Reply-To: <5b2951c4-e0d2-1b4e-3158-fb506874f16c@oracle.com>
References: <CAL4QsgtP0Sh4tNaS+Odk8fqOSmEfmUmtkRHcaiTAmMwPQWGKpQ@mail.gmail.com>
 <5b2951c4-e0d2-1b4e-3158-fb506874f16c@oracle.com>
Message-ID: <CAL4Qsgu=pdajgjdyhhFu+cpOkiJgFzDp7s35XJo+KhwMyZpEow@mail.gmail.com>

Thanks for the review, the changeset is attached.

On Thu, Dec 14, 2017 at 10:20 AM, Vicente Romero <vicente.romero at oracle.com>
wrote:

> looks good,
> Vicente
>
>
> On 12/08/2017 02:52 PM, Liam Miller-Cushon wrote:
>
>> Hello,
>>
>> Please review the following fix for JDK-8193216. The patch causes Filer
>> to emit a warning if an annotation processor redefines a symbol on the
>> classpath or sourcepath.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8193216
>> webrev: http://cr.openjdk.java.net/~cushon/8193216/webrev.00/ <
>> http://cr.openjdk.java.net/%7Ecushon/8193216/webrev.00/>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171214/f7aa4336/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 8193216.patch
Type: application/octet-stream
Size: 8067 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171214/f7aa4336/8193216.patch>

From joe.darcy at oracle.com  Fri Dec 15 01:20:38 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Thu, 14 Dec 2017 17:20:38 -0800
Subject: RFR 8193216: Filer should warn if processors redefine symbols
 from the classpath or sourcepath
In-Reply-To: <CAL4Qsgu=pdajgjdyhhFu+cpOkiJgFzDp7s35XJo+KhwMyZpEow@mail.gmail.com>
References: <CAL4QsgtP0Sh4tNaS+Odk8fqOSmEfmUmtkRHcaiTAmMwPQWGKpQ@mail.gmail.com>
 <5b2951c4-e0d2-1b4e-3158-fb506874f16c@oracle.com>
 <CAL4Qsgu=pdajgjdyhhFu+cpOkiJgFzDp7s35XJo+KhwMyZpEow@mail.gmail.com>
Message-ID: <ebd2b66c-c485-8c72-34d3-e8a741b1f477@oracle.com>

Hello,

Given the change in long-standing warning behavior, to be thorough I'd 
like to see a quick CSR created for this issue. (From the issue in JBS, 
under the "More" box at the top of the page selecte "Create CSR" toward 
the bottom. Fill out the form presented in the the new issue and when 
you're ready to have it looked at hit "Finalize.")

For the test, I don't know if there would be additional coverage if a 
second compile line was added to test a pre-modules world. If Vicente or 
another javac engineer thinks this would be helpful,

...
* @compile/ref=warn.out -XDrawDiagnostics -Xlint:processing -processor 
TestProcTypeAlreadyExistsWarning B.java
* @compile/ref=warn.out -XDrawDiagnostics -Xlint:processing --release 8 
-processor TestProcTypeAlreadyExistsWarning B.java
...

I'll adjust my eventual fix for

     JDK-8193462: Fix Filer handling of package-info initial elements

to treat package-info files analogously with the changes from this issue 
after the changes go back.

Perhaps separate from this change, it may be reasonable to check for 
obviously overlaps in the source locations and target locations.

Thanks,

-Joe


On 12/14/2017 4:17 PM, Liam Miller-Cushon wrote:
> Thanks for the review, the changeset is attached.
>
> On Thu, Dec 14, 2017 at 10:20 AM, Vicente Romero 
> <vicente.romero at oracle.com <mailto:vicente.romero at oracle.com>> wrote:
>
>     looks good,
>     Vicente
>
>
>     On 12/08/2017 02:52 PM, Liam Miller-Cushon wrote:
>
>         Hello,
>
>         Please review the following fix for JDK-8193216. The patch
>         causes Filer to emit a warning if an annotation processor
>         redefines a symbol on the classpath or sourcepath.
>
>         bug: https://bugs.openjdk.java.net/browse/JDK-8193216
>         <https://bugs.openjdk.java.net/browse/JDK-8193216>
>         webrev: http://cr.openjdk.java.net/~cushon/8193216/webrev.00/
>         <http://cr.openjdk.java.net/%7Ecushon/8193216/webrev.00/>
>         <http://cr.openjdk.java.net/%7Ecushon/8193216/webrev.00/
>         <http://cr.openjdk.java.net/%7Ecushon/8193216/webrev.00/>>
>
>
>

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

From cushon at google.com  Fri Dec 15 02:36:00 2017
From: cushon at google.com (Liam Miller-Cushon)
Date: Thu, 14 Dec 2017 21:36:00 -0500
Subject: RFR 8193216: Filer should warn if processors redefine symbols
 from the classpath or sourcepath
In-Reply-To: <ebd2b66c-c485-8c72-34d3-e8a741b1f477@oracle.com>
References: <CAL4QsgtP0Sh4tNaS+Odk8fqOSmEfmUmtkRHcaiTAmMwPQWGKpQ@mail.gmail.com>
 <5b2951c4-e0d2-1b4e-3158-fb506874f16c@oracle.com>
 <CAL4Qsgu=pdajgjdyhhFu+cpOkiJgFzDp7s35XJo+KhwMyZpEow@mail.gmail.com>
 <ebd2b66c-c485-8c72-34d3-e8a741b1f477@oracle.com>
Message-ID: <CAL4Qsgu-pkBiDKYuKRC4dtYgkd2ciVQD1eamfPtTxeUNN+jzFw@mail.gmail.com>

On Thu, Dec 14, 2017 at 8:20 PM, joe darcy <joe.darcy at oracle.com> wrote:

> Given the change in long-standing warning behavior, to be thorough I'd
> like to see a quick CSR created for this issue. (From the issue in JBS,
> under the "More" box at the top of the page selecte "Create CSR" toward the
> bottom. Fill out the form presented in the the new issue and when you're
> ready to have it looked at hit "Finalize.")
>
Thanks, I started a CSR: https://bugs.openjdk.java.net/browse/JDK-8193576

Does this require a specification change? The documentation for
-Xlint:processing isn't very specific, and the documentation for Filer
doesn't discuss warnings.

> For the test, I don't know if there would be additional coverage if a
> second compile line was added to test a pre-modules world...
>
I double-checked that the test still passes with the additional compile
line.

> I'll adjust my eventual fix for
>
>     JDK-8193462: Fix Filer handling of package-info initial elements
>
> to treat package-info files analogously with the changes from this issue
> after the changes go back.
>
Thanks!

> Perhaps separate from this change, it may be reasonable to check for
> obviously overlaps in the source locations and target locations.
>
Do you have an example of that kind of overlap? I'm not certain what source
and target mean in this context.

I've seen issues related to overlaps between the sources of a compilation
and its classpath, or between jars on the classpath. That kind of overlap
is relatively common, but an optional lint warning might be nice to have.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171214/c37e13c4/attachment-0001.html>

From erik.joelsson at oracle.com  Fri Dec 15 12:40:33 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 15 Dec 2017 13:40:33 +0100
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <5cc0a0e6-e2a5-5232-1070-50944acc0237@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <5cc0a0e6-e2a5-5232-1070-50944acc0237@oracle.com>
Message-ID: <32097b10-283e-51ae-b1be-689d515cafa8@oracle.com>

Looking at JDK-8188015, I was just reminded of JDK-8188012 and 
JDK-8188013 which indicates that we have more than one place where 10 
needs to be bumped to 11

make/BuildNashorn.gmk
make/langtools/src/classes/build/tools/symbolgenerator/TransitiveDependencies.java

/Erik

On 2017-12-12 16:36, Erik Joelsson wrote:
> Build change looks good.
>
> /Erik
>
>
> On 2017-12-12 08:04, joe darcy wrote:
>> Hello,
>>
>> With the JDK 11 line of development opening up in a few days, a few 
>> changes are needed to prepared to turn a JDK 10 code base into a JDK 
>> 11 one including:
>>
>> ??? JDK-8173382: Add -source 11 and -target 11 to javac
>> ??? JDK-8193291: Add SourceVersion.RELEASE_11
>>
>> ??? Webev:
>> ??????? http://cr.openjdk.java.net/~darcy/8173382.1/
>> ??? CSRs:
>> ??????? JDK-8193350: Add -source 11 and -target 11 to javac
>> ??????? JDK-8193351: Add SourceVersion.RELEASE_11
>>
>> Please review the preliminary webrev and CSRs.
>>
>> Note that breaking with previous contentions, the current iteration 
>> of the change does *not* add -source/-target "1.11" as an alias for 
>> "11". Only "11" is recognized.
>>
>> I didn't see how to add support for an "11" value for "--release" so 
>> I problem listed two tests until that is sorted out.
>>
>> The build is simultaneously updated to user -source/-target 11, hence 
>> the inclusion of build-dev.
>>
>> Various langtools tests and test infrastructure is updated too.
>>
>> Thanks,
>>
>> -Joe
>>
>


From vicente.romero at oracle.com  Fri Dec 15 15:08:08 2017
From: vicente.romero at oracle.com (Vicente Romero)
Date: Fri, 15 Dec 2017 10:08:08 -0500
Subject: RFR 8189708: class reading issue with named and annotated
 parameters
In-Reply-To: <CAL4QsguwsVrZzJ9ro6r7i-FUmwpX5Lt=ixex+4kp6jzvS4sMfA@mail.gmail.com>
References: <CAL4QsgtDfRxacW3iWS_+1RxorSHin9_OCV+PUXw=shH+zD0H7Q@mail.gmail.com>
 <59E9A5B5.5060200@oracle.com>
 <CAL4Qsguo_rcHUYKNKuavFQO1QDA-T8xTWtO_abPZuqT-oy3DVQ@mail.gmail.com>
 <CAL4QsgsFpyKG3fVrwzrtpat6La_Mm8X6tm5n=P+Qwf3+q7E5MQ@mail.gmail.com>
 <CAL4Qsgt3opbb5APWhigjHgQw_0hO4t_AR6AsdURZpovbdz6ikQ@mail.gmail.com>
 <5A3124BE.6020202@oracle.com>
 <CAL4Qsgu==iRbTuZ8oHO1P7cBFnR7Pt2FDT99KRWR6fuXsGNccQ@mail.gmail.com>
 <193be90f-20bc-ae50-6606-1d9c6cb5f020@oracle.com>
 <CAL4QsguwsVrZzJ9ro6r7i-FUmwpX5Lt=ixex+4kp6jzvS4sMfA@mail.gmail.com>
Message-ID: <9a50dd47-ae19-ec61-172c-deedfe3e5ebc@oracle.com>

Hi,

Looks good,
Vicente

PS. do you need me to push it or can you push already?

On 12/14/2017 06:55 PM, Liam Miller-Cushon wrote:
> Thanks for the reviews. I renamed the test, and mentioned both of the 
> associated bugs in the test and the commit message.
>
> The formatted changeset is attached.
>
> On Thu, Dec 14, 2017 at 9:28 AM, Vicente Romero 
> <vicente.romero at oracle.com <mailto:vicente.romero at oracle.com>> wrote:
>
>     looks good to me, only one minor comment, consider using a more
>     meaningful name for:
>
>     test/langtools/tools/javac/MethodParameters/8189708/Test.java
>
>     there is no need for another review iteration for this change,
>
>     Thanks,
>     Vicente
>
>
>     On 12/13/2017 09:02 PM, Liam Miller-Cushon wrote:
>>     Thanks,
>>
>>     I updated the copyright header and moved the tests to the correct
>>     location:
>>     http://cr.openjdk.java.net/~cushon/8007720/webrev.02/
>>     <http://cr.openjdk.java.net/%7Ecushon/8007720/webrev.02/>
>>
>>     Also - note that the patch currently includes a fix
>>     for?JDK-8177486 as well, since you suggested I add test coverage
>>     for enum and inner class constructors, and mandated parameters
>>     aren't handled correctly without fixing the other bug. Is it OK
>>     to have one changeset for both issues, or should they be
>>     separated out? I could remove the enum and inner class test
>>     coverage and the fix, and then add it back in as a follow-up
>>     change if you prefer.
>>
>>     On Wed, Dec 13, 2017 at 8:01 AM, Jan Lahoda
>>     <jan.lahoda at oracle.com <mailto:jan.lahoda at oracle.com>> wrote:
>>
>>         Sorry for late reply.
>>
>>         Seems OK to me, only:
>>         -the tests should be in:
>>         test/langtools/tools/javac/MethodParameters/8189708
>>         not in:
>>         test/tools/javac/MethodParameters/8189708
>>
>>         -test/tools/javac/MethodParameters/8189708/Test.java has a
>>         weird license header
>>
>>         Vicente, could you please take a look as well?
>>
>>         Thanks,
>>         ? ? Jan
>>
>>         On 4.12.2017 22:37, Liam Miller-Cushon wrote:
>>
>>             Hi, is there any more feedback on this?
>>
>>             On Fri, Oct 20, 2017 at 5:51 PM, Liam Miller-Cushon
>>             <cushon at google.com <mailto:cushon at google.com>
>>             <mailto:cushon at google.com <mailto:cushon at google.com>>> wrote:
>>
>>             ? ? Here's an updated patch that incorporates your approach:
>>             http://cr.openjdk.java.net/~cushon/8007720/webrev.01/
>>             <http://cr.openjdk.java.net/%7Ecushon/8007720/webrev.01/>
>>             ? ?
>>             <http://cr.openjdk.java.net/~cushon/8007720/webrev.01/
>>             <http://cr.openjdk.java.net/%7Ecushon/8007720/webrev.01/>>
>>
>>             ? ? I included the fix for JDK-8177486 so I could test
>>             the inner class /
>>             ? ? enum constructor case. If this looks like it's on the
>>             right track
>>             ? ? I'll move that part (and the corresponding tests)
>>             back into a
>>             ? ? separate change.
>>
>>             ? ? On Fri, Oct 20, 2017 at 9:30 AM, Liam Miller-Cushon
>>             ? ? <cushon at google.com <mailto:cushon at google.com>
>>             <mailto:cushon at google.com <mailto:cushon at google.com>>> wrote:
>>
>>             ? ? ? ? Thanks for the comments,
>>
>>             ? ? ? ? On Fri, Oct 20, 2017 at 12:28 AM, Jan Lahoda
>>             ? ? ? ? <jan.lahoda at oracle.com
>>             <mailto:jan.lahoda at oracle.com>
>>             <mailto:jan.lahoda at oracle.com
>>             <mailto:jan.lahoda at oracle.com>>> wrote:
>>
>>             ? ? ? ? ? ? -what happens if there are both runtime
>>             invisible and
>>             ? ? ? ? ? ? visible annotations of method's parameters?
>>             Seems those that
>>             ? ? ? ? ? ? appear later will overwrite those that appear
>>             sooner?
>>
>>
>>             ? ? ? ? Oops, thanks. The way your patch handles that
>>             looks good to me.
>>
>>             ? ? ? ? ? ? -the MethodSymbol.savedParameterAnnotations
>>             is only used
>>             ? ? ? ? ? ? during reading inside the ClassReader, right?
>>             It seems
>>             ? ? ? ? ? ? wasteful to have it as a field on each
>>             MethodSymbol, better
>>             ? ? ? ? ? ? would be a field in ClassReader.
>>
>>
>>             ? ? ? ? Sounds good. I'll try to avoid having
>>             savedParameterNames as a
>>             ? ? ? ? field in MethodSymbol also. Do you remember if
>>             you encountered
>>             ? ? ? ? any issues with that in your patch?
>>
>>             ? ? ? ? ? ? -please check what happens for annotations on
>>             constructors
>>             ? ? ? ? ? ? of enums/non-static innerclasses
>>
>>
>>             ? ? ? ? Will do. (Also, note that there appears to be an
>>             issue with
>>             ? ? ? ? reading MethodParameters on constructors of
>>             enums/non-static
>>             ? ? ? ? inner classes: JDK-8177486)
>>
>>
>>
>>
>
>

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

From cushon at google.com  Fri Dec 15 16:35:03 2017
From: cushon at google.com (Liam Miller-Cushon)
Date: Fri, 15 Dec 2017 11:35:03 -0500
Subject: RFR 8189708: class reading issue with named and annotated
 parameters
In-Reply-To: <9a50dd47-ae19-ec61-172c-deedfe3e5ebc@oracle.com>
References: <CAL4QsgtDfRxacW3iWS_+1RxorSHin9_OCV+PUXw=shH+zD0H7Q@mail.gmail.com>
 <59E9A5B5.5060200@oracle.com>
 <CAL4Qsguo_rcHUYKNKuavFQO1QDA-T8xTWtO_abPZuqT-oy3DVQ@mail.gmail.com>
 <CAL4QsgsFpyKG3fVrwzrtpat6La_Mm8X6tm5n=P+Qwf3+q7E5MQ@mail.gmail.com>
 <CAL4Qsgt3opbb5APWhigjHgQw_0hO4t_AR6AsdURZpovbdz6ikQ@mail.gmail.com>
 <5A3124BE.6020202@oracle.com>
 <CAL4Qsgu==iRbTuZ8oHO1P7cBFnR7Pt2FDT99KRWR6fuXsGNccQ@mail.gmail.com>
 <193be90f-20bc-ae50-6606-1d9c6cb5f020@oracle.com>
 <CAL4QsguwsVrZzJ9ro6r7i-FUmwpX5Lt=ixex+4kp6jzvS4sMfA@mail.gmail.com>
 <9a50dd47-ae19-ec61-172c-deedfe3e5ebc@oracle.com>
Message-ID: <CAL4Qsgu0AOtmDkegOBTXrufr0zDwNbXxUWLpJXKweiytw9ggvg@mail.gmail.com>

I'm not a committer yet, do you mind pushing it?

On Fri, Dec 15, 2017 at 10:08 AM, Vicente Romero <vicente.romero at oracle.com>
wrote:

> Hi,
>
> Looks good,
> Vicente
>
> PS. do you need me to push it or can you push already?
>
>
> On 12/14/2017 06:55 PM, Liam Miller-Cushon wrote:
>
> Thanks for the reviews. I renamed the test, and mentioned both of the
> associated bugs in the test and the commit message.
>
> The formatted changeset is attached.
>
> On Thu, Dec 14, 2017 at 9:28 AM, Vicente Romero <vicente.romero at oracle.com
> > wrote:
>
>> looks good to me, only one minor comment, consider using a more
>> meaningful name for:
>>
>> test/langtools/tools/javac/MethodParameters/8189708/Test.java
>>
>> there is no need for another review iteration for this change,
>>
>> Thanks,
>> Vicente
>>
>>
>> On 12/13/2017 09:02 PM, Liam Miller-Cushon wrote:
>>
>> Thanks,
>>
>> I updated the copyright header and moved the tests to the correct
>> location:
>> http://cr.openjdk.java.net/~cushon/8007720/webrev.02/
>>
>> Also - note that the patch currently includes a fix for JDK-8177486 as
>> well, since you suggested I add test coverage for enum and inner class
>> constructors, and mandated parameters aren't handled correctly without
>> fixing the other bug. Is it OK to have one changeset for both issues, or
>> should they be separated out? I could remove the enum and inner class test
>> coverage and the fix, and then add it back in as a follow-up change if you
>> prefer.
>>
>> On Wed, Dec 13, 2017 at 8:01 AM, Jan Lahoda <jan.lahoda at oracle.com>
>> wrote:
>>
>>> Sorry for late reply.
>>>
>>> Seems OK to me, only:
>>> -the tests should be in:
>>> test/langtools/tools/javac/MethodParameters/8189708
>>> not in:
>>> test/tools/javac/MethodParameters/8189708
>>>
>>> -test/tools/javac/MethodParameters/8189708/Test.java has a weird
>>> license header
>>>
>>> Vicente, could you please take a look as well?
>>>
>>> Thanks,
>>>     Jan
>>>
>>> On 4.12.2017 22:37, Liam Miller-Cushon wrote:
>>>
>>>> Hi, is there any more feedback on this?
>>>>
>>>> On Fri, Oct 20, 2017 at 5:51 PM, Liam Miller-Cushon <cushon at google.com
>>>> <mailto:cushon at google.com>> wrote:
>>>>
>>>>     Here's an updated patch that incorporates your approach:
>>>>     http://cr.openjdk.java.net/~cushon/8007720/webrev.01/
>>>>     <http://cr.openjdk.java.net/~cushon/8007720/webrev.01/>
>>>>
>>>>     I included the fix for JDK-8177486 so I could test the inner class /
>>>>     enum constructor case. If this looks like it's on the right track
>>>>     I'll move that part (and the corresponding tests) back into a
>>>>     separate change.
>>>>
>>>>     On Fri, Oct 20, 2017 at 9:30 AM, Liam Miller-Cushon
>>>>     <cushon at google.com <mailto:cushon at google.com>> wrote:
>>>>
>>>>         Thanks for the comments,
>>>>
>>>>         On Fri, Oct 20, 2017 at 12:28 AM, Jan Lahoda
>>>>         <jan.lahoda at oracle.com <mailto:jan.lahoda at oracle.com>> wrote:
>>>>
>>>>             -what happens if there are both runtime invisible and
>>>>             visible annotations of method's parameters? Seems those that
>>>>             appear later will overwrite those that appear sooner?
>>>>
>>>>
>>>>         Oops, thanks. The way your patch handles that looks good to me.
>>>>
>>>>             -the MethodSymbol.savedParameterAnnotations is only used
>>>>             during reading inside the ClassReader, right? It seems
>>>>             wasteful to have it as a field on each MethodSymbol, better
>>>>             would be a field in ClassReader.
>>>>
>>>>
>>>>         Sounds good. I'll try to avoid having savedParameterNames as a
>>>>         field in MethodSymbol also. Do you remember if you encountered
>>>>         any issues with that in your patch?
>>>>
>>>>             -please check what happens for annotations on constructors
>>>>             of enums/non-static innerclasses
>>>>
>>>>
>>>>         Will do. (Also, note that there appears to be an issue with
>>>>         reading MethodParameters on constructors of enums/non-static
>>>>         inner classes: JDK-8177486)
>>>>
>>>>
>>>>
>>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171215/bd65f3ef/attachment-0001.html>

From iris.clark at oracle.com  Fri Dec 15 16:43:34 2017
From: iris.clark at oracle.com (Iris Clark)
Date: Fri, 15 Dec 2017 08:43:34 -0800 (PST)
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <32097b10-283e-51ae-b1be-689d515cafa8@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <5cc0a0e6-e2a5-5232-1070-50944acc0237@oracle.com>
 <32097b10-283e-51ae-b1be-689d515cafa8@oracle.com>
Message-ID: <7f251611-e355-4c72-80e3-faca842f84be@default>

Hi.

Another build target we need to update is LICENSE_URL in make/Docs.gmk.  Here's the equivalent bug for 10:

    https://bugs.openjdk.java.net/browse/JDK-8189919

I've requested this link:

    http://www.oracle.com/technetwork/java/javase/terms/license/java11speclicense.html

Thanks,
iris

-----Original Message-----
From: Erik Joelsson 
Sent: Friday, December 15, 2017 4:41 AM
To: joe darcy <joe.darcy at oracle.com>; compiler-dev at openjdk.java.net; build-dev <build-dev at openjdk.java.net>; STUART.MARKS <stuart.marks at oracle.com>
Cc: David Holmes <david.holmes at oracle.com>
Subject: Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

Looking at JDK-8188015, I was just reminded of JDK-8188012 and
JDK-8188013 which indicates that we have more than one place where 10 needs to be bumped to 11

make/BuildNashorn.gmk
make/langtools/src/classes/build/tools/symbolgenerator/TransitiveDependencies.java

/Erik

On 2017-12-12 16:36, Erik Joelsson wrote:
> Build change looks good.
>
> /Erik
>
>
> On 2017-12-12 08:04, joe darcy wrote:
>> Hello,
>>
>> With the JDK 11 line of development opening up in a few days, a few 
>> changes are needed to prepared to turn a JDK 10 code base into a JDK
>> 11 one including:
>>
>> ??? JDK-8173382: Add -source 11 and -target 11 to javac
>> ??? JDK-8193291: Add SourceVersion.RELEASE_11
>>
>> ??? Webev:
>> ??????? http://cr.openjdk.java.net/~darcy/8173382.1/
>> ??? CSRs:
>> ??????? JDK-8193350: Add -source 11 and -target 11 to javac
>> ??????? JDK-8193351: Add SourceVersion.RELEASE_11
>>
>> Please review the preliminary webrev and CSRs.
>>
>> Note that breaking with previous contentions, the current iteration 
>> of the change does *not* add -source/-target "1.11" as an alias for 
>> "11". Only "11" is recognized.
>>
>> I didn't see how to add support for an "11" value for "--release" so 
>> I problem listed two tests until that is sorted out.
>>
>> The build is simultaneously updated to user -source/-target 11, hence 
>> the inclusion of build-dev.
>>
>> Various langtools tests and test infrastructure is updated too.
>>
>> Thanks,
>>
>> -Joe
>>
>


From paul.sandoz at oracle.com  Fri Dec 15 18:40:31 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 15 Dec 2017 10:40:31 -0800
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <7f251611-e355-4c72-80e3-faca842f84be@default>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <5cc0a0e6-e2a5-5232-1070-50944acc0237@oracle.com>
 <32097b10-283e-51ae-b1be-689d515cafa8@oracle.com>
 <7f251611-e355-4c72-80e3-faca842f84be@default>
Message-ID: <9793A667-E002-4F6C-BAD0-F7E7776EBB92@oracle.com>

Hi Iris, Erik

We should be able to automate all the following by referring to the latest release variable, yes?

  Nashorn build targets version 9 source
  https://bugs.openjdk.java.net/browse/JDK-8188012
  http://hg.openjdk.java.net/jdk10/master/rev/0e67ab18b511

  symbolgenerator targets jdk 9 source
  https://bugs.openjdk.java.net/browse/JDK-8188013
  http://hg.openjdk.java.net/jdk10/master/rev/b4c8426fe105

  Update link to license in Docs.gmk
  https://bugs.openjdk.java.net/browse/JDK-818999
  http://hg.openjdk.java.net/jdk10/master/rev/a6e591e12f12

Paul.


> On 15 Dec 2017, at 08:43, Iris Clark <iris.clark at oracle.com> wrote:
> 
> Hi.
> 
> Another build target we need to update is LICENSE_URL in make/Docs.gmk.  Here's the equivalent bug for 10:
> 
>    https://bugs.openjdk.java.net/browse/JDK-8189919
> 
> I've requested this link:
> 
>    http://www.oracle.com/technetwork/java/javase/terms/license/java11speclicense.html
> 
> Thanks,
> iris
> 
> -----Original Message-----
> From: Erik Joelsson
> Sent: Friday, December 15, 2017 4:41 AM
> To: joe darcy <joe.darcy at oracle.com>; compiler-dev at openjdk.java.net; build-dev <build-dev at openjdk.java.net>; STUART.MARKS <stuart.marks at oracle.com>
> Cc: David Holmes <david.holmes at oracle.com>
> Subject: Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
> 
> Looking at JDK-8188015, I was just reminded of JDK-8188012 and
> JDK-8188013 which indicates that we have more than one place where 10 needs to be bumped to 11
> 
> make/BuildNashorn.gmk
> make/langtools/src/classes/build/tools/symbolgenerator/TransitiveDependencies.java
> 
> /Erik
> 
> On 2017-12-12 16:36, Erik Joelsson wrote:
>> Build change looks good.
>> 
>> /Erik
>> 
>> 
>> On 2017-12-12 08:04, joe darcy wrote:
>>> Hello,
>>> 
>>> With the JDK 11 line of development opening up in a few days, a few
>>> changes are needed to prepared to turn a JDK 10 code base into a JDK
>>> 11 one including:
>>> 
>>>     JDK-8173382: Add -source 11 and -target 11 to javac
>>>     JDK-8193291: Add SourceVersion.RELEASE_11
>>> 
>>>     Webev:
>>>         http://cr.openjdk.java.net/~darcy/8173382.1/
>>>     CSRs:
>>>         JDK-8193350: Add -source 11 and -target 11 to javac
>>>         JDK-8193351: Add SourceVersion.RELEASE_11
>>> 
>>> Please review the preliminary webrev and CSRs.
>>> 
>>> Note that breaking with previous contentions, the current iteration
>>> of the change does *not* add -source/-target "1.11" as an alias for
>>> "11". Only "11" is recognized.
>>> 
>>> I didn't see how to add support for an "11" value for "--release" so
>>> I problem listed two tests until that is sorted out.
>>> 
>>> The build is simultaneously updated to user -source/-target 11, hence
>>> the inclusion of build-dev.
>>> 
>>> Various langtools tests and test infrastructure is updated too.
>>> 
>>> Thanks,
>>> 
>>> -Joe
>>> 
>> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 873 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171215/9efcddd4/signature.asc>

From iris.clark at oracle.com  Fri Dec 15 21:10:02 2017
From: iris.clark at oracle.com (Iris Clark)
Date: Fri, 15 Dec 2017 13:10:02 -0800 (PST)
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <9793A667-E002-4F6C-BAD0-F7E7776EBB92@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <5cc0a0e6-e2a5-5232-1070-50944acc0237@oracle.com>
 <32097b10-283e-51ae-b1be-689d515cafa8@oracle.com>
 <7f251611-e355-4c72-80e3-faca842f84be@default>
 <9793A667-E002-4F6C-BAD0-F7E7776EBB92@oracle.com>
Message-ID: <34893f28-fc68-42cc-8161-5cb58746e2f3@default>

Hi, Paul.

> We should be able to automate all the following by referring to the latest release variable, yes?

[ ... ]

>   Update link to license in Docs.gmk
>   https://bugs.openjdk.java.net/browse/JDK-818999
>   http://hg.openjdk.java.net/jdk10/master/rev/a6e591e12f12

Yes!

iris

-----Original Message-----
From: Paul Sandoz 
Sent: Friday, December 15, 2017 10:41 AM
To: Iris Clark <iris.clark at oracle.com>
Cc: Erik Joelsson <erik.joelsson at oracle.com>; Joseph D. Darcy <joe.darcy at oracle.com>; compiler-dev at openjdk.java.net; build-dev <build-dev at openjdk.java.net>; Stuart Marks <stuart.marks at oracle.com>; David Holmes <david.holmes at oracle.com>
Subject: Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

Hi Iris, Erik

We should be able to automate all the following by referring to the latest release variable, yes?

  Nashorn build targets version 9 source
  https://bugs.openjdk.java.net/browse/JDK-8188012
  http://hg.openjdk.java.net/jdk10/master/rev/0e67ab18b511

  symbolgenerator targets jdk 9 source
  https://bugs.openjdk.java.net/browse/JDK-8188013
  http://hg.openjdk.java.net/jdk10/master/rev/b4c8426fe105

  Update link to license in Docs.gmk
  https://bugs.openjdk.java.net/browse/JDK-818999
  http://hg.openjdk.java.net/jdk10/master/rev/a6e591e12f12

Paul.


> On 15 Dec 2017, at 08:43, Iris Clark <iris.clark at oracle.com> wrote:
> 
> Hi.
> 
> Another build target we need to update is LICENSE_URL in make/Docs.gmk.  Here's the equivalent bug for 10:
> 
>    https://bugs.openjdk.java.net/browse/JDK-8189919
> 
> I've requested this link:
> 
>    
> http://www.oracle.com/technetwork/java/javase/terms/license/java11spec
> license.html
> 
> Thanks,
> iris
> 
> -----Original Message-----
> From: Erik Joelsson
> Sent: Friday, December 15, 2017 4:41 AM
> To: joe darcy <joe.darcy at oracle.com>; compiler-dev at openjdk.java.net; 
> build-dev <build-dev at openjdk.java.net>; STUART.MARKS 
> <stuart.marks at oracle.com>
> Cc: David Holmes <david.holmes at oracle.com>
> Subject: Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and 
> -target 11 to javac - Java Bug System & JDK-8193291: Add 
> SourceVersion.RELEASE_11
> 
> Looking at JDK-8188015, I was just reminded of JDK-8188012 and
> JDK-8188013 which indicates that we have more than one place where 10 
> needs to be bumped to 11
> 
> make/BuildNashorn.gmk
> make/langtools/src/classes/build/tools/symbolgenerator/TransitiveDepen
> dencies.java
> 
> /Erik
> 
> On 2017-12-12 16:36, Erik Joelsson wrote:
>> Build change looks good.
>> 
>> /Erik
>> 
>> 
>> On 2017-12-12 08:04, joe darcy wrote:
>>> Hello,
>>> 
>>> With the JDK 11 line of development opening up in a few days, a few 
>>> changes are needed to prepared to turn a JDK 10 code base into a JDK
>>> 11 one including:
>>> 
>>>     JDK-8173382: Add -source 11 and -target 11 to javac
>>>     JDK-8193291: Add SourceVersion.RELEASE_11
>>> 
>>>     Webev:
>>>         http://cr.openjdk.java.net/~darcy/8173382.1/
>>>     CSRs:
>>>         JDK-8193350: Add -source 11 and -target 11 to javac
>>>         JDK-8193351: Add SourceVersion.RELEASE_11
>>> 
>>> Please review the preliminary webrev and CSRs.
>>> 
>>> Note that breaking with previous contentions, the current iteration 
>>> of the change does *not* add -source/-target "1.11" as an alias for 
>>> "11". Only "11" is recognized.
>>> 
>>> I didn't see how to add support for an "11" value for "--release" so 
>>> I problem listed two tests until that is sorted out.
>>> 
>>> The build is simultaneously updated to user -source/-target 11, 
>>> hence the inclusion of build-dev.
>>> 
>>> Various langtools tests and test infrastructure is updated too.
>>> 
>>> Thanks,
>>> 
>>> -Joe
>>> 
>> 
> 


From paul.sandoz at oracle.com  Fri Dec 15 22:23:41 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 15 Dec 2017 14:23:41 -0800
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
Message-ID: <D7C83FCA-752D-461B-AA04-2AED205E80A3@oracle.com>

Here are two webrevs (in order that can be merged with the other): the class file version changes; and the build changes related to that.

  http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-classfile-version/webrev/
  http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-classfile-version-build-changes/webrev/

Testing of all three patches (jdk-tier1,jdk-tier2,jdk-tier3,hs-tier1,hs-tier2,hs-tier3,hs-tier4,hs-tier5) produced no related test failures.

Paul.


> On 11 Dec 2017, at 23:04, joe darcy <joe.darcy at oracle.com> wrote:
> 
> Hello,
> 
> With the JDK 11 line of development opening up in a few days, a few changes are needed to prepared to turn a JDK 10 code base into a JDK 11 one including:
> 
>    JDK-8173382: Add -source 11 and -target 11 to javac
>    JDK-8193291: Add SourceVersion.RELEASE_11
> 
>    Webev:
>        http://cr.openjdk.java.net/~darcy/8173382.1/
>    CSRs:
>        JDK-8193350: Add -source 11 and -target 11 to javac
>        JDK-8193351: Add SourceVersion.RELEASE_11
> 
> Please review the preliminary webrev and CSRs.
> 
> Note that breaking with previous contentions, the current iteration of the change does *not* add -source/-target "1.11" as an alias for "11". Only "11" is recognized.
> 
> I didn't see how to add support for an "11" value for "--release" so I problem listed two tests until that is sorted out.
> 
> The build is simultaneously updated to user -source/-target 11, hence the inclusion of build-dev.
> 
> Various langtools tests and test infrastructure is updated too.
> 
> Thanks,
> 
> -Joe
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 873 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171215/639e8170/signature.asc>

From erik.joelsson at oracle.com  Sat Dec 16 07:19:30 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Sat, 16 Dec 2017 08:19:30 +0100
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <9793A667-E002-4F6C-BAD0-F7E7776EBB92@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <5cc0a0e6-e2a5-5232-1070-50944acc0237@oracle.com>
 <32097b10-283e-51ae-b1be-689d515cafa8@oracle.com>
 <7f251611-e355-4c72-80e3-faca842f84be@default>
 <9793A667-E002-4F6C-BAD0-F7E7776EBB92@oracle.com>
Message-ID: <a5c7f843-7c3b-bb94-815b-f93084037257@oracle.com>

That sounds good to me.

/Erik

On 2017-12-15 19:40, Paul Sandoz wrote:
> Hi Iris, Erik
>
> We should be able to automate all the following by referring to the latest release variable, yes?
>
>    Nashorn build targets version 9 source
>    https://bugs.openjdk.java.net/browse/JDK-8188012
>    http://hg.openjdk.java.net/jdk10/master/rev/0e67ab18b511
>
>    symbolgenerator targets jdk 9 source
>    https://bugs.openjdk.java.net/browse/JDK-8188013
>    http://hg.openjdk.java.net/jdk10/master/rev/b4c8426fe105
>
>    Update link to license in Docs.gmk
>    https://bugs.openjdk.java.net/browse/JDK-818999
>    http://hg.openjdk.java.net/jdk10/master/rev/a6e591e12f12
>
> Paul.
>
>
>> On 15 Dec 2017, at 08:43, Iris Clark <iris.clark at oracle.com> wrote:
>>
>> Hi.
>>
>> Another build target we need to update is LICENSE_URL in make/Docs.gmk.  Here's the equivalent bug for 10:
>>
>>     https://bugs.openjdk.java.net/browse/JDK-8189919
>>
>> I've requested this link:
>>
>>     http://www.oracle.com/technetwork/java/javase/terms/license/java11speclicense.html
>>
>> Thanks,
>> iris
>>
>> -----Original Message-----
>> From: Erik Joelsson
>> Sent: Friday, December 15, 2017 4:41 AM
>> To: joe darcy <joe.darcy at oracle.com>; compiler-dev at openjdk.java.net; build-dev <build-dev at openjdk.java.net>; STUART.MARKS <stuart.marks at oracle.com>
>> Cc: David Holmes <david.holmes at oracle.com>
>> Subject: Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
>>
>> Looking at JDK-8188015, I was just reminded of JDK-8188012 and
>> JDK-8188013 which indicates that we have more than one place where 10 needs to be bumped to 11
>>
>> make/BuildNashorn.gmk
>> make/langtools/src/classes/build/tools/symbolgenerator/TransitiveDependencies.java
>>
>> /Erik
>>
>> On 2017-12-12 16:36, Erik Joelsson wrote:
>>> Build change looks good.
>>>
>>> /Erik
>>>
>>>
>>> On 2017-12-12 08:04, joe darcy wrote:
>>>> Hello,
>>>>
>>>> With the JDK 11 line of development opening up in a few days, a few
>>>> changes are needed to prepared to turn a JDK 10 code base into a JDK
>>>> 11 one including:
>>>>
>>>>      JDK-8173382: Add -source 11 and -target 11 to javac
>>>>      JDK-8193291: Add SourceVersion.RELEASE_11
>>>>
>>>>      Webev:
>>>>          http://cr.openjdk.java.net/~darcy/8173382.1/
>>>>      CSRs:
>>>>          JDK-8193350: Add -source 11 and -target 11 to javac
>>>>          JDK-8193351: Add SourceVersion.RELEASE_11
>>>>
>>>> Please review the preliminary webrev and CSRs.
>>>>
>>>> Note that breaking with previous contentions, the current iteration
>>>> of the change does *not* add -source/-target "1.11" as an alias for
>>>> "11". Only "11" is recognized.
>>>>
>>>> I didn't see how to add support for an "11" value for "--release" so
>>>> I problem listed two tests until that is sorted out.
>>>>
>>>> The build is simultaneously updated to user -source/-target 11, hence
>>>> the inclusion of build-dev.
>>>>
>>>> Various langtools tests and test infrastructure is updated too.
>>>>
>>>> Thanks,
>>>>
>>>> -Joe
>>>>


From goetz.lindenmaier at sap.com  Mon Dec 18 17:35:08 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 18 Dec 2017 17:35:08 +0000
Subject: FW: RFR(M): 8189102: All tools should support -?, -h and --help
In-Reply-To: <7be3772e8060494cbecf3097bd0a8a85@sap.com>
References: <c27028f9f5844c3c818885f88c75f84b@sap.com>
 <8aa25976d496465fac00a4ae3628e533@sap.com>
 <456c694ec25a42658af1b8600aaa136d@sap.com>
 <6d7d895f-9f23-fd4b-39ca-ef9bb0331fb9@oracle.com>
 <7be3772e8060494cbecf3097bd0a8a85@sap.com>
Message-ID: <2124c07d77df43369bf3080c54f314b1@sap.com>

Hi,

I had to update my webrev after the javah launcher had been removed:
http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.07/

I would appreciate a final decision to push this.

Best regards,
  Goetz.


-----Original Message-----
From: serviceability-dev [mailto:serviceability-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz
Sent: Tuesday, December 12, 2017 11:37 AM
To: Alan Bateman <Alan.Bateman at oracle.com>; core-libs-dev at openjdk.java.net; 'compiler-dev at openjdk.java.net' <compiler-dev at openjdk.java.net>; serviceability-dev (serviceability-dev at openjdk.java.net) <serviceability-dev at openjdk.java.net>
Subject: RE: FW: RFR(M): 8189102: All tools should support -?, -h and --help

Hi Alan,

Javadoc combines documentation and support of a flag in the
way the flag handling is implemented.  On the other side, 
it prints the help message anyways if a wrong flag is presented 
to it, so if you call it with -help you get the help message.
Therefore, in my original change where I tried to get it 
more cleaned up, I removed -help support and documentation 
from Javadoc.

I added it again and updated the table in the CSR:
http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.06/

Best regards,
  Goetz.

> -----Original Message-----
> From: Alan Bateman [mailto:Alan.Bateman at oracle.com]
> Sent: Montag, 11. Dezember 2017 17:53
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; core-libs-
> dev at openjdk.java.net; 'compiler-dev at openjdk.java.net' <compiler-
> dev at openjdk.java.net>; serviceability-dev (serviceability-
> dev at openjdk.java.net) <serviceability-dev at openjdk.java.net>
> Subject: Re: FW: RFR(M): 8189102: All tools should support -?, -h and --help
> 
> 
> 
> On 07/12/2017 11:20, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > ... missed some lists in my first post ...
> >
> > I prepared a fifth webrev for this change.  Please review.
> >
> > It incorporates the changes requested by the CSR reviewers
> > (not to remove docuemtation of '-help' where is was documented
> > before) and the changes proposed by Kumar:
> > http://cr.openjdk.java.net/~goetz/wr17/8189102-
> helpMessage/webrev.05/
> >
> >
> Looks like it still drops -help from the javadoc usage message, I can't
> tell if you meant to do that.
> 
> -Alan.

From joe.darcy at oracle.com  Tue Dec 19 01:33:26 2017
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Mon, 18 Dec 2017 17:33:26 -0800
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target
 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <32b572b1-c1fb-8201-0438-261b6de76a2d@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com>
 <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com>
 <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com>
 <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com>
 <33cac77e-a465-92c0-464e-9e086699786b@oracle.com>
 <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com>
 <20171213131843.760702080@eggemoggin.niobe.net>
 <32b572b1-c1fb-8201-0438-261b6de76a2d@oracle.com>
Message-ID: <5A386C66.6090505@oracle.com>

Hello,

A follow-up on defining a final field RELEASE_CURRENT  as an alias for 
the latest SourceVersion constant to allow easier updating of 
annotations using SourceVersion constants. Somewht surprisingly, this is 
not legal Java code; an annotation must use an enum constant directly 
and not a constant expression which evaluates to an enum constant.

This rules is given in JLS 9.7.1 Normal Annotations:

> T [ the element type] is not an array type, and the type of V [the 
> element value] is assignment compatible (?5.2) with T, and:
>
>     If T is a primitive type or String, then V is a constant 
> expression (?15.28).
>     If T is Class or an invocation of Class (?4.5), then V is a class 
> literal (?15.8.2).
>     If T is an enum type (?8.9), then V is an enum constant (?8.9.1).
>     V is not null.
https://docs.oracle.com/javase/specs/jls/se9/html/jls-9.html#jls-9.7.1

The wording goes back to JLS 3rd edition which introduced enums and 
annotations.

Formally, the constant expression concept in JLS 15.28 only applies to 
primitive types and Strings. Presumably, it would not be too difficult 
to expand this concept to include class literals and enum constants.

In any case, in the mean time the suggested idiom will not work and the 
changes of RELEASE_9 => RELEASE_10 will need to stay.

Updated webrev with a minor merge:

     http://cr.openjdk.java.net/~darcy/8173382.3/

Cheers,

-Joe


From paul.sandoz at oracle.com  Tue Dec 19 01:42:49 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 18 Dec 2017 17:42:49 -0800
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <5A386C66.6090505@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com>
 <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com>
 <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com>
 <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com>
 <33cac77e-a465-92c0-464e-9e086699786b@oracle.com>
 <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com>
 <20171213131843.760702080@eggemoggin.niobe.net>
 <32b572b1-c1fb-8201-0438-261b6de76a2d@oracle.com>
 <5A386C66.6090505@oracle.com>
Message-ID: <1BFAF81C-7292-4699-B696-85FB637A19D2@oracle.com>

Looks good to me.

I am including HS dev for the class file version changes:

  http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-classfile-version/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-classfile-version/webrev/>
  http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-classfile-version-build-changes/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-classfile-version-build-changes/webrev/>

We can push the above patches under the following issue rather that merge into Joe's patch:

  https://bugs.openjdk.java.net/browse/JDK-8191913 <https://bugs.openjdk.java.net/browse/JDK-8191913>

Hopefully by the next release we can merge together and with less changes required.

Paul.

> On 18 Dec 2017, at 17:33, Joseph D. Darcy <joe.darcy at oracle.com> wrote:
> 
> Hello,
> 
> A follow-up on defining a final field RELEASE_CURRENT  as an alias for the latest SourceVersion constant to allow easier updating of annotations using SourceVersion constants. Somewht surprisingly, this is not legal Java code; an annotation must use an enum constant directly and not a constant expression which evaluates to an enum constant.
> 
> This rules is given in JLS 9.7.1 Normal Annotations:
> 
>> T [ the element type] is not an array type, and the type of V [the element value] is assignment compatible (?5.2) with T, and:
>> 
>>    If T is a primitive type or String, then V is a constant expression (?15.28).
>>    If T is Class or an invocation of Class (?4.5), then V is a class literal (?15.8.2).
>>    If T is an enum type (?8.9), then V is an enum constant (?8.9.1).
>>    V is not null.
> https://docs.oracle.com/javase/specs/jls/se9/html/jls-9.html#jls-9.7.1
> 
> The wording goes back to JLS 3rd edition which introduced enums and annotations.
> 
> Formally, the constant expression concept in JLS 15.28 only applies to primitive types and Strings. Presumably, it would not be too difficult to expand this concept to include class literals and enum constants.
> 
> In any case, in the mean time the suggested idiom will not work and the changes of RELEASE_9 => RELEASE_10 will need to stay.
> 
> Updated webrev with a minor merge:
> 
>    http://cr.openjdk.java.net/~darcy/8173382.3/
> 
> Cheers,
> 
> -Joe
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171218/c69ab3f4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 873 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171218/c69ab3f4/signature.asc>

From joe.darcy at oracle.com  Tue Dec 19 01:49:42 2017
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Mon, 18 Dec 2017 17:49:42 -0800
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target
 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <1BFAF81C-7292-4699-B696-85FB637A19D2@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com>
 <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com>
 <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com>
 <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com>
 <33cac77e-a465-92c0-464e-9e086699786b@oracle.com>
 <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com>
 <20171213131843.760702080@eggemoggin.niobe.net>
 <32b572b1-c1fb-8201-0438-261b6de76a2d@oracle.com>
 <5A386C66.6090505@oracle.com>
 <1BFAF81C-7292-4699-B696-85FB637A19D2@oracle.com>
Message-ID: <5A387036.2080008@oracle.com>

Thanks Paul.

I'm doing final checks and preparations of fixes to

     JDK-8173382: Add -source 11 and -target 11 to javac
     JDK-8193291: Add SourceVersion.RELEASE_11

and expect to push shortly.

Cheers,

-Joe

On 12/18/2017 5:42 PM, Paul Sandoz wrote:
> Looks good to me.
>
> I am including HS dev for the class file version changes:
>
> http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-classfile-version/webrev/ 
> <http://cr.openjdk.java.net/%7Epsandoz/jdk/JDK-8173382-classfile-version/webrev/>
> http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-classfile-version-build-changes/webrev/ 
> <http://cr.openjdk.java.net/%7Epsandoz/jdk/JDK-8173382-classfile-version-build-changes/webrev/>
>
> We can push the above patches under the following issue rather that 
> merge into Joe's patch:
>
> https://bugs.openjdk.java.net/browse/JDK-8191913
>
> Hopefully by the next release we can merge together and with less 
> changes required.
>
> Paul.
>
>> On 18 Dec 2017, at 17:33, Joseph D. Darcy <joe.darcy at oracle.com 
>> <mailto:joe.darcy at oracle.com>> wrote:
>>
>> Hello,
>>
>> A follow-up on defining a final field RELEASE_CURRENT  as an alias 
>> for the latest SourceVersion constant to allow easier updating of 
>> annotations using SourceVersion constants. Somewht surprisingly, this 
>> is not legal Java code; an annotation must use an enum constant 
>> directly and not a constant expression which evaluates to an enum 
>> constant.
>>
>> This rules is given in JLS 9.7.1 Normal Annotations:
>>
>>> T [ the element type] is not an array type, and the type of V [the 
>>> element value] is assignment compatible (?5.2) with T, and:
>>>
>>>    If T is a primitive type or String, then V is a constant 
>>> expression (?15.28).
>>>    If T is Class or an invocation of Class (?4.5), then V is a class 
>>> literal (?15.8.2).
>>>    If T is an enum type (?8.9), then V is an enum constant (?8.9.1).
>>>    V is not null.
>> https://docs.oracle.com/javase/specs/jls/se9/html/jls-9.html#jls-9.7.1
>>
>> The wording goes back to JLS 3rd edition which introduced enums and 
>> annotations.
>>
>> Formally, the constant expression concept in JLS 15.28 only applies 
>> to primitive types and Strings. Presumably, it would not be too 
>> difficult to expand this concept to include class literals and enum 
>> constants.
>>
>> In any case, in the mean time the suggested idiom will not work and 
>> the changes of RELEASE_9 => RELEASE_10 will need to stay.
>>
>> Updated webrev with a minor merge:
>>
>>    http://cr.openjdk.java.net/~darcy/8173382.3/
>>
>> Cheers,
>>
>> -Joe
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171218/6bb31866/attachment-0001.html>

From david.holmes at oracle.com  Tue Dec 19 01:52:01 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 19 Dec 2017 11:52:01 +1000
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <1BFAF81C-7292-4699-B696-85FB637A19D2@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com>
 <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com>
 <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com>
 <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com>
 <33cac77e-a465-92c0-464e-9e086699786b@oracle.com>
 <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com>
 <20171213131843.760702080@eggemoggin.niobe.net>
 <32b572b1-c1fb-8201-0438-261b6de76a2d@oracle.com>
 <5A386C66.6090505@oracle.com>
 <1BFAF81C-7292-4699-B696-85FB637A19D2@oracle.com>
Message-ID: <4e128200-d82b-58f9-2fdb-2544833e6245@oracle.com>

On 19/12/2017 11:42 AM, Paul Sandoz wrote:
> Looks good to me.
> 
> I am including HS dev for the class file version changes:
> 
> http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-classfile-version/webrev/
> http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-classfile-version-build-changes/webrev/
> 
> We can push the above patches under the following issue rather that 
> merge into Joe's patch:
> 
> https://bugs.openjdk.java.net/browse/JDK-8191913
> 
> Hopefully by the next release we can merge together and with less 
> changes required.

Changes seem okay, but I'm still a little concerned about using 
classfile version 55 before we actually bump the JDK version to 11.

And it still isn't clear to me who will be doing the actual version 
update and when?

Thanks,
David

> Paul.
> 
>> On 18 Dec 2017, at 17:33, Joseph D. Darcy <joe.darcy at oracle.com 
>> <mailto:joe.darcy at oracle.com>> wrote:
>>
>> Hello,
>>
>> A follow-up on defining a final field RELEASE_CURRENT ?as an alias for 
>> the latest SourceVersion constant to allow easier updating of 
>> annotations using SourceVersion constants. Somewht surprisingly, this 
>> is not legal Java code; an annotation must use an enum constant 
>> directly and not a constant expression which evaluates to an enum 
>> constant.
>>
>> This rules is given in JLS 9.7.1 Normal Annotations:
>>
>>> T [ the element type] is not an array type, and the type of V [the 
>>> element value] is assignment compatible (?5.2) with T, and:
>>>
>>> ???If T is a primitive type or String, then V is a constant 
>>> expression (?15.28).
>>> ???If T is Class or an invocation of Class (?4.5), then V is a class 
>>> literal (?15.8.2).
>>> ???If T is an enum type (?8.9), then V is an enum constant (?8.9.1).
>>> ???V is not null.
>> https://docs.oracle.com/javase/specs/jls/se9/html/jls-9.html#jls-9.7.1
>>
>> The wording goes back to JLS 3rd edition which introduced enums and 
>> annotations.
>>
>> Formally, the constant expression concept in JLS 15.28 only applies to 
>> primitive types and Strings. Presumably, it would not be too difficult 
>> to expand this concept to include class literals and enum constants.
>>
>> In any case, in the mean time the suggested idiom will not work and 
>> the changes of RELEASE_9 => RELEASE_10 will need to stay.
>>
>> Updated webrev with a minor merge:
>>
>> ???http://cr.openjdk.java.net/~darcy/8173382.3/
>>
>> Cheers,
>>
>> -Joe
>>
> 

From paul.sandoz at oracle.com  Tue Dec 19 02:34:01 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 18 Dec 2017 18:34:01 -0800
Subject: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11
 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11
In-Reply-To: <4e128200-d82b-58f9-2fdb-2544833e6245@oracle.com>
References: <42594f6b-af60-3249-71d9-d64a39c802b4@oracle.com>
 <316a576c-6c87-fdc1-454d-102f3cfc1191@oracle.com>
 <30def987-3bf9-61f1-72fc-ce3b9114f555@oracle.com>
 <3de8b1ea-c737-2629-2689-3e8bda235689@oracle.com>
 <082194f6-38ca-1a10-4081-704dfb1af4a9@oracle.com>
 <33cac77e-a465-92c0-464e-9e086699786b@oracle.com>
 <4AF5DB2E-1C34-4C4A-80BD-D965E1374A9C@oracle.com>
 <20171213131843.760702080@eggemoggin.niobe.net>
 <32b572b1-c1fb-8201-0438-261b6de76a2d@oracle.com>
 <5A386C66.6090505@oracle.com>
 <1BFAF81C-7292-4699-B696-85FB637A19D2@oracle.com>
 <4e128200-d82b-58f9-2fdb-2544833e6245@oracle.com>
Message-ID: <C08EF385-D3AC-45A0-8E66-8965DAE1AED7@oracle.com>



> On 18 Dec 2017, at 17:52, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 19/12/2017 11:42 AM, Paul Sandoz wrote:
>> Looks good to me.
>> I am including HS dev for the class file version changes:
>> http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-classfile-version/webrev/
>> http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-classfile-version-build-changes/webrev/
>> We can push the above patches under the following issue rather that merge into Joe's patch:
>> https://bugs.openjdk.java.net/browse/JDK-8191913
>> Hopefully by the next release we can merge together and with less changes required.
> 
> Changes seem okay, but I'm still a little concerned about using classfile version 55 before we actually bump the JDK version to 11.
> 

Thanks, jdk and hs 1 to 4 tier testing showed no issues.


> And it still isn't clear to me who will be doing the actual version update and when?
> 

Unsure, we are still working out the steps, hopefully it would follow on fairly quickly.

Plus there are quite a few follow on actions we can do to make this simpler for next time (especially for hardcoded values in build scripts and tests).

Paul.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 873 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171218/eafd7653/signature.asc>

From maurizio.cimadamore at oracle.com  Wed Dec 20 13:00:31 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 20 Dec 2017 13:00:31 +0000
Subject: RFR 8057650: uniform error diagnostics for inconsistent inherited
 method signatures
Message-ID: <c117f954-867b-74ca-0883-0b69bd08cd93@oracle.com>

Hi,
the following is a simple patch which consolidates similar diagnostics 
caused by incompatible overrides - the diagnostics are all of the form:

type A and B are incompatible because...

So I created a toplevel key for the 'type are incompatible' bit, and a 
bunch of fragments for the various possible erroneous situations. See 
webrev here:

http://cr.openjdk.java.net/~mcimadamore/8057650/

As usual, I've also attached some examples of the touched diagnostic 
keys, as a reference.

Note that, since I was there, I made one of the diagnostics better - the 
key for 'diff.ret' used to take a String argument, while now takes a 
(method) name and a list of types (the parameters), which is consistent 
with other similar diagnostics, and avoids premature string-ification.

Cheers
Maurizio


From vicente.romero at oracle.com  Wed Dec 20 14:02:43 2017
From: vicente.romero at oracle.com (Vicente Romero)
Date: Wed, 20 Dec 2017 09:02:43 -0500
Subject: RFR 8057650: uniform error diagnostics for inconsistent inherited
 method signatures
In-Reply-To: <c117f954-867b-74ca-0883-0b69bd08cd93@oracle.com>
References: <c117f954-867b-74ca-0883-0b69bd08cd93@oracle.com>
Message-ID: <5b2ea67a-2ed8-6e27-996d-760255b6911b@oracle.com>

looks good.

Vicente

On 12/20/2017 08:00 AM, Maurizio Cimadamore wrote:
> Hi,
> the following is a simple patch which consolidates similar diagnostics 
> caused by incompatible overrides - the diagnostics are all of the form:
>
> type A and B are incompatible because...
>
> So I created a toplevel key for the 'type are incompatible' bit, and a 
> bunch of fragments for the various possible erroneous situations. See 
> webrev here:
>
> http://cr.openjdk.java.net/~mcimadamore/8057650/
>
> As usual, I've also attached some examples of the touched diagnostic 
> keys, as a reference.
>
> Note that, since I was there, I made one of the diagnostics better - 
> the key for 'diff.ret' used to take a String argument, while now takes 
> a (method) name and a list of types (the parameters), which is 
> consistent with other similar diagnostics, and avoids premature 
> string-ification.
>
> Cheers
> Maurizio
>


From p.tournaris at gmail.com  Fri Dec 29 17:23:09 2017
From: p.tournaris at gmail.com (=?UTF-8?B?zqDOsc+NzrvOv8+CLc6gzq3PhM+Bzr/PgiDOpM6/z4XPgc69zqzPgc63z4I=?=)
Date: Fri, 29 Dec 2017 19:23:09 +0200
Subject: Missing increment of local counter variable
Message-ID: <CAOUouwETopA8WoFFCB60JYti6LF9mZJrfVaJfQcnOuae2FGQ1Q@mail.gmail.com>

Hello everyone,

First time posting here :)

Stumbled upon a javac diff ->
http://hg.openjdk.java.net/jdk/jdk/rev/89f6aa26fd6c resolving
https://bugs.openjdk.java.net/browse/JDK-8177486 &
https://bugs.openjdk.java.net/browse/JDK-8007720 and noticed that the
previous implementation was using a local counter variable named `i` when
looping through the parameter types, in order to construct the parameter
name. The new implementation follows a similar path to construct the
parameter name, using the `i` local counter variable but it does not
increment it.

The method I am referring to is the `params()` in Symbol.java
http://hg.openjdk.java.net/jdk/jdk/file/89f6aa26fd6c/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java#l1883


and I think it should include an increment of `i` in line
http://hg.openjdk.java.net/jdk/jdk/file/89f6aa26fd6c/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java#l1892

Otherwise
http://hg.openjdk.java.net/jdk/jdk/file/89f6aa26fd6c/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java#l1889
on that line the `fromString("arg" + i)` will always be called with `i`
being 0 (zero).

Not sure If I can submit a patch, or how it works in general, but I was
suggested to report it in this list :)

Thank you for your time!

-- 
Pavlos-Petros Tournaris
Android Software Engineer @ Workable <http://workable.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171229/42005b48/attachment.html>

From cushon at google.com  Fri Dec 29 22:12:50 2017
From: cushon at google.com (Liam Miller-Cushon)
Date: Fri, 29 Dec 2017 17:12:50 -0500
Subject: Missing increment of local counter variable
In-Reply-To: <CAOUouwETopA8WoFFCB60JYti6LF9mZJrfVaJfQcnOuae2FGQ1Q@mail.gmail.com>
References: <CAOUouwETopA8WoFFCB60JYti6LF9mZJrfVaJfQcnOuae2FGQ1Q@mail.gmail.com>
Message-ID: <CAL4Qsgu7XnO6SZgCv7WaOcsOBB5uxVzov6_Q9Zs4+Buz5sWwrA@mail.gmail.com>

Thanks for pointing that out. It was an oversight, I filed
https://bugs.openjdk.java.net/browse/JDK-8194268.

I don't think it's a regression, though. That branch is only taken for
synthetic methods. They aren't visible during annotation processing, and
their parameter names don't appear in bytecode, so it shouldn't be possible
to observe the incorrect names.

If you saw this causing incorrect behaviour, can you share a complete
example?

On Fri, Dec 29, 2017 at 12:23 PM, ??????-?????? ????????? <
p.tournaris at gmail.com> wrote:

> Hello everyone,
>
> First time posting here :)
>
> Stumbled upon a javac diff -> http://hg.openjdk.java.net/
> jdk/jdk/rev/89f6aa26fd6c resolving https://bugs.
> openjdk.java.net/browse/JDK-8177486 & https://bugs.openjdk.java.
> net/browse/JDK-8007720 and noticed that the previous implementation was
> using a local counter variable named `i` when looping through the parameter
> types, in order to construct the parameter name. The new implementation
> follows a similar path to construct the parameter name, using the `i` local
> counter variable but it does not increment it.
>
> The method I am referring to is the `params()` in Symbol.java
> http://hg.openjdk.java.net/jdk/jdk/file/89f6aa26fd6c/src/jdk.compiler/
> share/classes/com/sun/tools/javac/code/Symbol.java#l1883
>
> and I think it should include an increment of `i` in line
> http://hg.openjdk.java.net/jdk/jdk/file/89f6aa26fd6c/
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java#l1892
>
> Otherwise http://hg.openjdk.java.net/jdk/jdk/file/
> 89f6aa26fd6c/src/jdk.compiler/share/classes/com/sun/tools/
> javac/code/Symbol.java#l1889 on that line the `fromString("arg" + i)`
> will always be called with `i` being 0 (zero).
>
> Not sure If I can submit a patch, or how it works in general, but I was
> suggested to report it in this list :)
>
> Thank you for your time!
>
> --
> Pavlos-Petros Tournaris
> Android Software Engineer @ Workable <http://workable.com/>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171229/d596e12f/attachment.html>

From p.tournaris at gmail.com  Fri Dec 29 22:16:14 2017
From: p.tournaris at gmail.com (=?UTF-8?B?zqDOsc+NzrvOv8+CLc6gzq3PhM+Bzr/PgiDOpM6/z4XPgc69zqzPgc63z4I=?=)
Date: Sat, 30 Dec 2017 00:16:14 +0200
Subject: Missing increment of local counter variable
In-Reply-To: <CAL4Qsgu7XnO6SZgCv7WaOcsOBB5uxVzov6_Q9Zs4+Buz5sWwrA@mail.gmail.com>
References: <CAOUouwETopA8WoFFCB60JYti6LF9mZJrfVaJfQcnOuae2FGQ1Q@mail.gmail.com>
 <CAL4Qsgu7XnO6SZgCv7WaOcsOBB5uxVzov6_Q9Zs4+Buz5sWwrA@mail.gmail.com>
Message-ID: <CAOUouwF-gZRTEYVwtWe8LstfXh7PC9CPk3is=W2GAzXZ6G4jhQ@mail.gmail.com>

Nope, just saw that on the diff. Have not actually found an incorrect
behaviour on an example!

Thanks for filing it!

On Sat, Dec 30, 2017 at 12:12 AM, Liam Miller-Cushon <cushon at google.com>
wrote:

> Thanks for pointing that out. It was an oversight, I filed
> https://bugs.openjdk.java.net/browse/JDK-8194268.
>
> I don't think it's a regression, though. That branch is only taken for
> synthetic methods. They aren't visible during annotation processing, and
> their parameter names don't appear in bytecode, so it shouldn't be possible
> to observe the incorrect names.
>
> If you saw this causing incorrect behaviour, can you share a complete
> example?
>
> On Fri, Dec 29, 2017 at 12:23 PM, ??????-?????? ????????? <
> p.tournaris at gmail.com> wrote:
>
>> Hello everyone,
>>
>> First time posting here :)
>>
>> Stumbled upon a javac diff -> http://hg.openjdk.java.net/
>> jdk/jdk/rev/89f6aa26fd6c resolving https://bugs.openjdk
>> .java.net/browse/JDK-8177486 & https://bugs.openjdk.java.ne
>> t/browse/JDK-8007720 and noticed that the previous implementation was
>> using a local counter variable named `i` when looping through the parameter
>> types, in order to construct the parameter name. The new implementation
>> follows a similar path to construct the parameter name, using the `i` local
>> counter variable but it does not increment it.
>>
>> The method I am referring to is the `params()` in Symbol.java
>> http://hg.openjdk.java.net/jdk/jdk/file/89f6aa26
>> fd6c/src/jdk.compiler/share/classes/com/sun/tools/javac/
>> code/Symbol.java#l1883
>>
>> and I think it should include an increment of `i` in line
>> http://hg.openjdk.java.net/jdk/jdk/file/89f6aa26fd6c/sr
>> c/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java#l1892
>>
>> Otherwise http://hg.openjdk.java.net/jdk/jdk/file/89f6aa26fd
>> 6c/src/jdk.compiler/share/classes/com/sun/tools/javac/
>> code/Symbol.java#l1889 on that line the `fromString("arg" + i)` will
>> always be called with `i` being 0 (zero).
>>
>> Not sure If I can submit a patch, or how it works in general, but I was
>> suggested to report it in this list :)
>>
>> Thank you for your time!
>>
>> --
>> Pavlos-Petros Tournaris
>> Android Software Engineer @ Workable <http://workable.com/>
>>
>>
>


-- 
Pavlos-Petros Tournaris
Android Software Engineer @ Workable <http://workable.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171230/60dac242/attachment-0001.html>

From cushon at google.com  Fri Dec 29 22:24:49 2017
From: cushon at google.com (Liam Miller-Cushon)
Date: Fri, 29 Dec 2017 17:24:49 -0500
Subject: RFR 8194268: Incorrect parameter names for synthetic methods
Message-ID: <CAL4Qsgtf47Cwjqo08oeVFobzH2tPJDyb3sdk0zRwKYm+UM_jHg@mail.gmail.com>

Hello,

This fixes a mistake in http://hg.openjdk.java.net/jdk/jdk/rev/89f6aa26fd6c
that caused incorrect parameter names to be generated for synthetic methods.
As I mentioned in the bug I don't think it's a regression, but it still
seems
worth cleaning up.

bug: https://bugs.openjdk.java.net/browse/JDK-8194268
webrev: http://cr.openjdk.java.net/~cushon/8194268/webrev.00/

Thanks,
Liam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171229/5ef78c26/attachment.html>