JDK-4216683 : Inconvenient javac deprecation warning suppression
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 1.1.7,1.2.1,1.2.2,1.4.0
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,solaris_2.6,windows_2000
  • CPU: generic,x86,sparc
  • Submitted: 1999-03-03
  • Updated: 2003-04-12
  • Resolved: 2002-09-02
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.
Other
1.4.2 mantisFixed
Related Reports
Duplicate :  
Duplicate :  
Description

Name: dbT83986			Date: 03/02/99


javac -deprecation doesn't print a warning of a usage in file A.java of a deprecated method in B.java if B.java is being
compiled at the same time as A.java. This is not an unreasonable idea, but it turns out that in the case I am using to be
exactly incorrect. I DO want to see these warnings. I can break down the compile into file-by-file, but this takes a while
to execute. How about a -reallyShowMeAllDeprecationWarnings option?
(Review ID: 49011)
======================================================================

Name: yyT116575			Date: 07/18/2001


java version "1.2.2"
Classic VM (build Linux_JDK_1.2.2_FCS, native threads, sunwjit)


I'd like to see deprection warnings even if I compile the complete the
deprecated code fragment and its user at the same time.

For correct static analysis of a project it is not enough to create the class
file if the .java file has changed. Dependency are much more complex. To be sure that everything is statically correct I'd like to compile the complete
project and get every warning I can get.

If parts of my project are deprecated I'd like to get warnings from the compiler about which other parts I'll have to change.
(Review ID: 128335)
======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis mantis-b02 FIXED IN: mantis mantis-b02 INTEGRATED IN: mantis mantis-b02 VERIFIED IN: mantis
2004-06-14

WORK AROUND Name: dbT83986 Date: 03/02/99 Compile file-by-file ======================================================================
2004-06-11

EVALUATION I am guessing that the assumption here is that files being compiled at once are part of the user's own application, thus he presumably knows what he is doing and doesn't want to be bothered with the warnings. Given that it is easy to suppress unwanted deprecation warnings, however, it seems that the warnings should be handled uniformly. Reproduced in JDK1.2fcs and JDK1.3-R. william.maddox@Eng 1999-12-20 This is handled uniformly between the two compilers, but nowhere is the desired behavior specified. ###@###.### 2001-11-12 I am planning to change the behavior for 1.4.2 (Mantis). The new behavior will be to suppress deprecation messages only when either (1) the use is within a deprecated method, or (2) the deprecated method and the use are contained within the same outermost class. It will no longer matter whether things are compiled together or separately. To elaborate on (1), there will be no message when a deprecated class is extended by a deprecated class, a deprecated method is called by a deprecated method, or a deprecated super constructor is called from a deprecated constructor. ###@###.### 2002-05-20
2002-05-20