United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4216683 Inconvenient javac deprecation warning suppression
JDK-4216683 : Inconvenient javac deprecation warning suppression

Details
Type:
Bug
Submit Date:
1999-03-03
Status:
Closed
Updated Date:
2003-04-12
Project Name:
JDK
Resolved Date:
2002-09-02
Component:
tools
OS:
solaris_2.6,generic,windows_2000
Sub-Component:
javac
CPU:
x86,sparc,generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
1.1.7,1.2.1,1.2.2,1.4.0
Fixed Versions:
1.4.2 (mantis)

Related Reports
Duplicate:
Duplicate:

Sub Tasks

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
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
WORK AROUND



Name: dbT83986			Date: 03/02/99


Compile file-by-file
======================================================================
                                     
2004-06-11
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



Hardware and Software, Engineered to Work Together