JDK 10/11 RFR of JDK-8189146: Have use of "var" in 9 and earlier source versions issue a warning

[Jonathan Gibbons]

On 01/12/2018 11:59 AM, joe darcy wrote:
> PS Link to webrev below.
>
>
> On 1/12/2018 11:13 AM, joe darcy wrote:
>> Hi Maurizio,
>>
>>
>>
>
> [snip]
>
>>
>>>
>>> I believe what comes out of the compiler is in sync with what you 
>>> wanted, but the patch is not as trivial as we originally had hoped, 
>>> which, in my mind, makes it more for 11 than for 10.
>>
>> Hmm. I agree the current patch is more intricate than desired for 
>> this stage of JDK 10.
>>
>> Arguably the largest compatibility impact from var is no longer being 
>> able to use var as a type name, at least it is the  impact that might 
>> be hardest to overcome in terms of having to rename a type rather 
>> than rename a variable. So for a patch appropriate for 10 at this 
>> stage, I'll prepare a simple patch for consideration that just warns 
>> on type name. Then if that is acceptable for 10, your patch could go 
>> into JDK 11 under a follow-up bug.
>>
>
> The iteration at
>
>     http://cr.openjdk.java.net/~darcy/8189146.4/
>
> goes back to the initial limited attempt at only warning for type 
> names (which also covers type variables) but preserves the more 
> precise testing developed in subsequent iterations.
>
> Thanks,
>
> -Joe

OK.

It is a general rule for javac that javac should be able to compile a 
program without generating any warnings. Any warnings should be 
suppressible either by using @SuppressWarnings, or a command-line 
option, or (in a few cases) changing the source code to something 
equivalent, without changing the intended functionality.

I can see how it would be difficult to use the Lint mechanism in the 
parser, since even the deferred-lint-warnings mechanism doesn't kick in 
until later. So that means in this case, the remediation to avoid this 
proposed new warning is to change the source code in question. And that 
is acceptable, in part because of the expected low number of occurrences 
of this warning, and because the code will have to be changed eventually 
anyway, in later releases where the warning is promoted to an error.

-- Jon