JDK-8189145 : Define "future" lint category
  • Type: Enhancement
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 10
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2017-10-10
  • Updated: 2020-10-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 17
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Various language changes, banning underscore, "_", as an identifier (JDK-8061549) and using "var" to indicate local variable type inference (JDK-8151454), create situations where it is reasonable for javac to warn about source constructs that will be forbidden or questionable in future source versions. This includes when a javac is used to compile to older source versions using -source N or --release N, the latter available as of JDK 9.

However, it is also reasonable to allow programmers to suppress warnings today about changes that may or will come tomorrow.

This can be accomplished by defining a "future" lint category, enabled by default, which can be suppressed by SuppressedWarnings.
[~jlahoda] notes that currently DeferredLintHandler cannot be used in the parser, but has ideas on how to do so.

Summarizing a conversation with [~jjg], the implementation challenge here has been how to suppress the "future" category warning in cases they are found earlier in the compiler pipeline than annotations are available. Two particular examples, using "_" as a parameter name or "var" has a type name are motivating use cases for this enhancement. Both of those coding patterns are detected in the parser and have properly-versioned handling using the Source.Feature mechanism. However, the parser does not have full access to the information needed to determine "is @SuppressWarnings("future") in effect for this declaration?" That information is available in a later compiler phase. There may already be a mechanism to handle such deferred warnings; if so, it might be usable to implement this feature.

[~darcy] See com.sun.tools.javac.code.DeferredLintHandler. You can get an instance from the context in the normal manner: deferredLintHandler = DeferredLintHandler.instance(context); See example usage in com.sun.tools.javac.comp.Modules, which is the code to handle module declarations and set up the module graph. Like the parser, this code runs before the annotations machinery is available to determine whether a lint warning should be suppressed or not.

It's trivial (one word, and one resource) to add a new category; it would be worthwhile having some specific examples of where we will use it. The use case of warnings given in conjunction with older --source/--release options is interesting.

Re-targeting to new lint category to JDK 11.