JDK 10/11 RFR of JDK-8189146: Have use of "var" in 9 and earlier source versions issue a warning
Jonathan Gibbons
jonathan.gibbons at oracle.com
Tue Jan 16 18:52:13 UTC 2018
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
More information about the compiler-dev
mailing list