Bug 86330 - deprecated class method warning diagnosed as method
Summary: deprecated class method warning diagnosed as method
Status: RESOLVED WONTFIX
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows XP
: P3 minor (vote)
Target Milestone: 3.1 M6   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-02-23 13:46 EST by Ed Willink CLA
Modified: 2005-02-24 16:25 EST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Willink CLA 2005-02-23 13:46:05 EST
Given a deprecated class warning such as that on org.eclipse.swt.custom.TableTree
introduced in 3.1M5a, an invocation such as viewer.getTableTree().getTable()
is shown as invoking the deprecated getTable() method rather than the
deprecated class.
Comment 1 Olivier Thomann CLA 2005-02-23 15:58:15 EST
When the bit set is AccDeprecatedImplicitly, we might want to check if the
declaring class is set as AccDeprecated.
Comment 2 Philipe Mulet CLA 2005-02-23 17:02:27 EST
When a type is deprecated, all its members are implicitly considered as such. We
do not distinguish whether it is directly or indirectly deprecated.

What are you exactly suggesting ?  
Comment 3 Olivier Thomann CLA 2005-02-23 23:04:05 EST
I believe that Edward meant that it is enough to report the deprecation against
the type.
Comment 4 Ed Willink CLA 2005-02-24 01:44:26 EST
I meant that it would be more helpful to report the type deprecated when the
type is deprecated and the method deprecated only when the method is explicitly
deprecated.

I was faced with a method deprecated message, but a method that was not, so I
started searching round for inherited deprecation/a bug on indirected
deprecation ... before finding the type deprecation.
Comment 5 Philipe Mulet CLA 2005-02-24 04:50:51 EST
Problem is that there may not be an explicit reference to a truly deprecated
type, and we'd have to have different error messages for the different cases.

/** @deprecated */
class X {
   class Y {
       void foo() {}
   }
}
class Z {
  static X.Y create() { ... }
}


class Bar {
  void bar() {
     Z.create().foo();  // deprecated though no direct ref to X
  }  
}
Comment 6 Philipe Mulet CLA 2005-02-24 04:51:35 EST
We will stick to current behavior, this is the first complaint we got ever.
Comment 7 Ed Willink CLA 2005-02-24 16:25:18 EST
Your decision obviously; I just find it odd that the Java generic messages
have got so much more helpful as we go 3.1M3/4/5, yet here is a case
where you could again be helpful. Even just including the word "implicit"
in the error message for the implicit deprecation would be better than nothing.

With regard to different error messages for different cases: surely that
is good? A system with a single "syntax error" for all cases has never
been user friendly. As a user I want to know why the method is deprecated,
not just that it is. If there are multiple reasons then there are multiple
messages.