RFR: 8145471: javac changes for enhanced deprecation
jonathan.gibbons at oracle.com
Wed Oct 19 00:00:02 UTC 2016
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.
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.
> 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