RFR: 8145471: javac changes for enhanced deprecation

Jonathan Gibbons jonathan.gibbons at oracle.com
Fri Oct 21 01:31:39 UTC 2016


On 10/18/2016 05:00 PM, Jonathan Gibbons wrote:
> Jan,
>
> You're correct, the change in make/CompileJavaModules.gmk is not 
> necessary. Well spotted.
> The changes to the other make/ file are still necessary for the time 
> being, to suppress warnings until the sources can be updated with 
> appropriate use of @SuppressWarnings.
>
> The use of the literal "true" in TypeEnter is definitely undesirable, 
> and I think you are correct in that there does not seem to be an easy 
> fix without changing how javac handles deprecation. Generally, I think 
> that this would mean that we would mean we would have to defer all 
> deprecation reporting until after annotation processing, when we can 
> reliably determine the evaluation of the @Deprecated annotation, and 
> therefore which sort of warning to generate. This is complicated by 
> the fact that the conditions for deprecated warnings and removal 
> warnings are slightly different. I will file a JBS entry.

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

>
> -- Jon
>
> On 10/18/2016 06:58 AM, Jan Lahoda wrote:
>> Overall, seem OK to me. Two comments:
>> -is the change in make/CompileJavaModules.gmk really needed given the 
>> adjusted JAVAC_WARNINGS in make/common/SetupJavaCompilers.gmk?
>>
>> -the reliance on literal "true" in TypeEnter seems suspicious to me. 
>> What if the value of the attribute is a compile-time constant? I 
>> suspect this may be non-trivial to fix, so no strict need to fix that 
>> under this patch, but I think we should have a good idea how we want 
>> this fixed, and there should be a JBS entry filled for that.
>>
>> Jan
>>
>> On 18.10.2016 00:10, Jonathan Gibbons wrote:
>>> Repeat, with subject line.
>>>
>>> -- Jon
>>>
>>> On 10/17/2016 03:03 PM, Jonathan Gibbons wrote:
>>>> Compiler folk, build folk,
>>>>
>>>> Please review this update for javac and some build files, for JEP 277.
>>>>
>>>> The work supports the enhanced Deprecation attribute, and generates a
>>>> new warning when items are referenced that are declared with
>>>> @Deprecated(forRemoval=true), in line with the proposals in JEP 277.
>>>>
>>>> The warnings are on by default, and can be suppressed with
>>>> -Xlint:-removal or @SuppressWarnings("removal").  Because the warnings
>>>> are on by default, and because the warnings currently show up when
>>>> building JDK, some minor build changes are temporarily required to
>>>> suppress the warnings that get generated during the build.
>>>>
>>>> -- Jon
>>>>
>>>> JEP: http://openjdk.java.net/jeps/277
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8145471
>>>> Webrev: http://cr.openjdk.java.net/~jjg/8145471/webrev.01/
>>>
>




More information about the build-dev mailing list