JDK-8194764 : javac incorrectly flags deprecated for removal imports
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 10,11
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2018-01-08
  • Updated: 2018-04-05
  • Resolved: 2018-02-07
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 10 JDK 11
10 b43Fixed 11Fixed
Related Reports
Blocks :  
JDK-8194651 - javadoc: mark the com.sun.javadoc API for removal
Description
After applying the attached patch, while compiling with the Intelij IDE or by using ant to build, javac emits errors for imports referencing Deprecated/forRemoval classes, however build the jdk images using make does not exhibit the problem. The bug here is that error at import sites cannot be
suppressed.

The theory is that it could be the ordering of files from returned by the  filesystem, although the issue seems to be reproducible on both Windows and Linux (OEL).
Comments
Fix request approved jjg, Group Lead
06-02-2018
Fix Request Incorrect warning produced which can lead to compilation failures if -Werror is enabled. The fix is trivial, just changing source level range for the warning from MIN-9 to MIN-8, as it was in JDK 8, with a minimal risk. Tests enhanced to explicitly test "-source 9", in addition to existing tests that test "-source 8" and "-source <current>". Webrev: http://cr.openjdk.java.net/~jlahoda/8194764/webrev.00/ Review thread: http://mail.openjdk.java.net/pipermail/compiler-dev/2018-January/011608.html
26-01-2018
I deeply apologize for not looking at this sooner, I completely missed this bug. Sorry for that. I think I know where is the problem: the deprecation warnings on imports should still be printed for -source < 8, and should only be suppressed by -source 9+. But unfortunately, Source.Feature has this line: DEPRECATION_ON_IMPORT(MIN, JDK9) And my understanding is that the range is inclusive, i.e. the produces the warnings even for -source 9. Should I think be: DEPRECATION_ON_IMPORT(MIN, JDK8) To reproduce: --- D.java package x; @Deprecated(forRemoval=true) public class D {} ---X.java package x; import x.D; public class X { public static void main(String[] args) { D d; } } --- --- $ javac D.java X.java /tmp/X.java:8: warning: [removal] D in x has been deprecated and marked for removal D d; ^ 1 warning --- This is OK. But: --- $ javac -source 9 D.java X.java warning: [options] bootstrap class path not set in conjunction with -source 9 /tmp/X.java:3: warning: [removal] D in x has been deprecated and marked for removal import x.D; ^ /tmp/X.java:7: warning: [removal] D in x has been deprecated and marked for removal D d; ^ 3 warnings --- I think this also explains the difference between the builds: the ant build is (still) using "-source 9", I think, making the problem visible.
23-01-2018
@jjg said he will look into this.
23-01-2018
Ok sounds good, Jan please feel free to downgrade the bug as you see fit. ILW => MLL => P3.
10-01-2018
#2 to make progress
10-01-2018
So what do I do for my javadoc deprecation removal work I have three possible paths: 1. wait for this bug to be fixed 2. update the ant properties to be consistent with the JDK build 3. remove the imports in the two old javadoc files where this was observed.
10-01-2018
Agreed that (in general) the build systems should be equivalent, but in this case, the difference paid off, and revealed a genuine bug ;-)
09-01-2018
Ok, I misunderstood - I thought the warning was warranted. In any case, aligning the two build systems is not a workaround - both builds should have identical behaviours! Also, the bug description should be updated (and maybe priority lowered?) as it says error cannot be suppressed, while clearly using -Xlint:-removal makes the problem go away?
09-01-2018
No. Changing the Makefile or build.properties file would be a workaround, not a fix. (But it is a useful explanation of the difference in behavior.) As Joe noted, we are *never* supposed to generate deprecation warnings on import statements, even if all warnings are maximally enabled, such as -Xlint:all. The DISABLE_WARNINGS is very sad; we should work to remove most of those entries, which are (probably) the result of a union of existing options when we consolidated the repos.
09-01-2018
Seems to me that maybe this is just a difference between official 'make' build and ant developer build? Make says this (see make/common/SetupJavaCompilers.gmk): DISABLE_WARNINGS := -Xlint:all,-deprecation,-removal,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally But Ant says this (make/langtools/build.properties) javac.opts = -XDignore.symbol.file=true -Xlint:all,-deprecation,-options,-exports -Werror -g:source,lines,vars This difference has been there for a long time, but I suspect that the recent source version bump has triggered the problem. If I'm correct, the only required action is to bring the developer build.properties file in sync with what make says.
09-01-2018
TypeEnter.attribImportType is correctly, temporarily, suppressing warnings at line 433 Lint prevLint = chk.setLint(allowDeprecationOnImport ? lint : lint.suppress(LintCategory.DEPRECATION, LintCategory.REMOVAL)); Check if warning is suppressed is in Check.warnDeprecated, line 204 if (sym.isDeprecatedForRemoval()) { if (!lint.isSuppressed(LintCategory.REMOVAL)) { if (sym.kind == MDL) { removalHandler.report(pos, "has.been.deprecated.for.removal.module", sym); } else { removalHandler.report(pos, "has.been.deprecated.for.removal", sym, sym.location()); } } Hypothesis ... The call to warnDeprecated is in a deferredLintHandler ... so maybe the wrong value of lint is being used when warnDeprecated is finally called; i.e. maybe the DeferredLintHandler should cache the value of lint that was current at the time the call was deferred.
08-01-2018
Not requiring deprecation on import statements was a change made in JDK 9 under JEP 211/JDK-8042566.
08-01-2018
Here is a -doe traceback [exec] import com.sun.javadoc.ClassDoc; [exec] ^ [exec] java.lang.RuntimeException [exec] at jdk.compiler/com.sun.tools.javac.util.Log.writeDiagnostic(Log.java:745) [exec] at jdk.compiler/com.sun.tools.javac.util.Log$DefaultDiagnosticHandler.report(Log.java:702) [exec] at jdk.compiler/com.sun.tools.javac.util.Log.report(Log.java:672) [exec] at jdk.compiler/com.sun.tools.javac.util.AbstractLog.mandatoryWarning(AbstractLog.java:318) [exec] at jdk.compiler/com.sun.tools.javac.util.AbstractLog.mandatoryWarning(AbstractLog.java:309) [exec] at jdk.compiler/com.sun.tools.javac.util.MandatoryWarningHandler.logMandatoryWarning(MandatoryWarningHandler.java:255) [exec] at jdk.compiler/com.sun.tools.javac.util.MandatoryWarningHandler.report(MandatoryWarningHandler.java:133) [exec] at jdk.compiler/com.sun.tools.javac.comp.Check.warnDeprecated(Check.java:210) [exec] at jdk.compiler/com.sun.tools.javac.comp.Check.lambda$checkDeprecated$5(Check.java:3296) [exec] at jdk.compiler/com.sun.tools.javac.code.DeferredLintHandler.report(DeferredLintHandler.java:79) [exec] at jdk.compiler/com.sun.tools.javac.comp.Check.checkDeprecated(Check.java:3296) [exec] at jdk.compiler/com.sun.tools.javac.comp.Attr.checkIdInternal(Attr.java:3969) [exec] at jdk.compiler/com.sun.tools.javac.comp.Attr.checkId(Attr.java:3816) [exec] at jdk.compiler/com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:3700) [exec] at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:2110) [exec] at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:653) [exec] at jdk.compiler/com.sun.tools.javac.comp.Attr.attribType(Attr.java:713) [exec] at jdk.compiler/com.sun.tools.javac.comp.Attr.attribType(Attr.java:706) [exec] at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.attribImportType(TypeEnter.java:439) [exec] at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.doImport(TypeEnter.java:422) [exec] at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.resolveImports(TypeEnter.java:362) [exec] at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.runPhase(TypeEnter.java:319) [exec] at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$Phase.doCompleteEnvs(TypeEnter.java:280) [exec] at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$Phase.completeEnvs(TypeEnter.java:249) [exec] at jdk.compiler/com.sun.tools.javac.comp.TypeEnter.complete(TypeEnter.java:198) [exec] at jdk.compiler/com.sun.tools.javac.code.Symbol.complete(Symbol.java:633) [exec] at jdk.compiler/com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1308) [exec] at jdk.compiler/com.sun.tools.javac.comp.Enter.complete(Enter.java:583) [exec] at jdk.compiler/com.sun.tools.javac.comp.Enter.main(Enter.java:560) [exec] at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:1058) [exec] at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:929) [exec] at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:306) [exec] at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:165) [exec] at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57) [exec] at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43)
08-01-2018
Are you sure you're compiling with current javac and not JDK 8 javac: JAVA_HOME=/usr/jdk/instances/jdk1.8.0
08-01-2018