Community
Participate
Working Groups
When using a deprecated method, JDT gives and appropriate warning with QuickFixes to - add @SuppressWarnings("deprecation") to the statement - add @SuppressWarnings("deprecation") to the method There can also be for to add at the class level too. This will be helpful when the whole class littered with intentional usage of deprecated code and developer does not want to litter is further.
(In reply to comment #0) > When using a deprecated method, JDT gives and appropriate warning with > QuickFixes to > - add @SuppressWarnings("deprecation") to the statement > - add @SuppressWarnings("deprecation") to the method > > There can also be for to add at the class level too. I think the intention here is to provide quick fixes for the smallest possible scope. A class would be too big a scope in the general case. > This will be helpful when > the whole class littered with intentional usage of deprecated code and > developer does not want to litter is further. Having said that I think there is a scope to be a bit intelligent here. Maybe we can check if the class is indeed littered with deprecated code i.e. several methods (say half the methods) use deprecated code, in that case we may add the annotation to the class. This would be a bit similar to the multi-fix case in that we look at other problem markers as well, but the fix happens only at one location. An example of such a scenario would be org.eclipse.jdt.ui.tests.wizardapi.NewJavaProjectWizardTest Markus, thoughts?
(In reply to comment #1) > Having said that I think there is a scope to be a bit intelligent here. Maybe > we can check if the class is indeed littered with deprecated code Of course we also need a clear definition that a class is indeed littered with deprecated code.
Example: Usage of Eclipse Preferences. Even though the InstanceScope constructor is deprecated, you would not really go ahead and change it to InstanceScope.INSTANCE all over the code This leave us with two points 1. May be we can show QF for class if one or more methods are already marked. In such case, you can remove the one at the method 2. Can we provide QF for fixing deprecated stuff. I know its very difficult but for subset we can. Like I want to deprecate an API, JDT can provide someway for me to also hook in the refactoring for the QF. May be using Annotations 3. Perhaps Point 2 should be a separate request 4. I know I said two points. 3 and 4 are not really the points I wish to make here :)
(In reply to comment #3) > Example: Usage of Eclipse Preferences. Even though the InstanceScope > constructor is deprecated, you would not really go ahead and change it to > InstanceScope.INSTANCE all over the code In this case I would, as I prefer to get rid of deprecated code if possible. And it is already done in JDT/UI. > 1. May be we can show QF for class if one or more methods are already marked. > In such case, you can remove the one at the method Good point. Though we still do not have a clear definition of 'class littered with deprecated' code.
(In reply to comment #4) > (In reply to comment #3) > > Example: Usage of Eclipse Preferences. Even though the InstanceScope > > constructor is deprecated, you would not really go ahead and change it to > > InstanceScope.INSTANCE all over the code > In this case I would, as I prefer to get rid of deprecated code if possible. +1, completely agree.
(In reply to comment #4) > (In reply to comment #3) > > Example: Usage of Eclipse Preferences. Even though the InstanceScope > > constructor is deprecated, you would not really go ahead and change it to > > InstanceScope.INSTANCE all over the code > In this case I would, as I prefer to get rid of deprecated code if possible. > And it is already done in JDT/UI. Not everywhere. May be for InstanceScope, but just JDT/UI plug-in gives out 519 deprecated code usage warnings. Also you may have fixed the JDT/UI code but others may be still still using and do not wish to change because it actually works! > > 1. May be we can show QF for class if one or more methods are already marked. > > In such case, you can remove the one at the method > Good point. Though we still do not have a clear definition of 'class littered > with deprecated' code. Definition: A class with frequent usage of deprecated API. So frequent that almost every method uses it and when you try to @Suppress annotations for them you curse who deprecated that API :) Try placing the Suppress annotations in these classes /org.eclipse.jdt.ui/src/org/eclipse/jdt/internal/ui/text/PreferencesAdapter.java /org.eclipse.jdt.ui/src/org/eclipse/jdt/internal/ui/JavaPlugin.java /org.eclipse.jdt.ui/src/org/eclipse/jdt/internal/ui/dialogs/TypeSelectionComponent.java /org.eclipse.jdt.ui/src/org/eclipse/jdt/internal/ui/dialogs/TypeSelectionDialog2.java And yes, you need to enable the warnings for the usage of deprecated code you enable to enable the preference on Java -> Compiler -> Error/Warnings -> Deprecated and restricted API
No plans to do this.
