Bug 127296 - [codeassist] Add the ability to hide deprecated methods from Code Assist
Summary: [codeassist] Add the ability to hide deprecated methods from Code Assist
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.2   Edit
Hardware: PC Windows XP
: P3 critical with 2 votes (vote)
Target Milestone: 3.2 M5   Edit
Assignee: David Audel CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-02-10 13:34 EST by Francis Lui CLA
Modified: 2006-02-15 12:14 EST (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Francis Lui CLA 2006-02-10 13:34:36 EST
In any old API that has shipped for 4 versions, there are methods you wish you
hadn't exposed, but are now exposed, and which you need to keep to maintain
backward compatibility with existing applications.  Code migration costs can be
very steep for large companies, and can block upgrades of your products.

Filtering based on access restrictions only allows you to filter on a per-package or per-class basis; you cannot hide individual methods in a class and expose other methods in the same class.

.NET 1.0+ and Visual Studio .NET 2002+ have the
[EditorBrowsable(EditorBrowsableState.Never)] attribute (analogous to JDK 1.5
annotations) with which you can tag individual methods to hide such public
internal methods and properties.

Java and Eclipse need a similar mechanism.  The @deprecated javadoc tag is a
good first step, but the method still appears in Eclipse Code Assist.  If
Eclipse had a feature to simply hide all @deprecated methods and classes from
Code Assist (not just crossing them out), that would solve the problem for us.

I propose that the Eclipse team add a new "Hide deprecated references" checkbox in the Workspace "Preferences" dialog under "Java" / "Editor" / "Code Assist" / "Sorting and Filtering".

Business Objects needs this for Crystal Reports for Eclipse.
Comment 1 Dani Megert CLA 2006-02-11 10:41:08 EST
+1

See also discussions in bug 106000.
Comment 2 Francis Lui CLA 2006-02-12 01:06:30 EST
When do you think you could schedule this work?

M5 (as a developer, I know that would be asking too much  :)  ) or M6?

Thanks!

Francis
Comment 3 Philipe Mulet CLA 2006-02-13 03:54:12 EST
This is conditionned by an API change. So if it occurs with 3.2, it must occur by M5, which means this early this week.
Comment 4 Francis Lui CLA 2006-02-13 04:58:00 EST
Great!  So is your answer, "yes, it will be in M5," or "no, it's too late to make it into M5?"

The "Target Milestone" is still set to "---".
Comment 5 David Audel CLA 2006-02-13 10:44:12 EST
Fixed and tests added
  CompletionTests#testDeprecationCheck1() -> testDeprecationCheck16()

Added filtering of deprecated types and members.
Deprecated types and members aren't filtered if they are defined in the same compilation unit as completion location.

eg. 
/** @deprecated */
class X {
  X| // X should be proposed in this case
}

Added a new option CODEASSIST_DEPRECATION_CHECK in JavaCore.

*  CODEASSIST / Activate Deprecation Sensitive Completion
*    When active, completion doesn't show deprecated members and types.
*     - option id:         "org.eclipse.jdt.core.codeComplete.deprecationCheck"
*     - possible values:   { "enabled", "disabled" }
*     - default:           "disable"
Comment 6 David Audel CLA 2006-02-13 10:52:40 EST
I open a new bug to request the addition of this option in the Content Assist preference page (bug 127481).
Comment 7 David Audel CLA 2006-02-14 04:35:44 EST
Currently filtering doesn't work correctly for type references (bug 127628). This problem won't be fixed for 3.2M5.
Comment 8 Frederic Fusier CLA 2006-02-15 12:14:23 EST
Note that bug 127628 was not fixed for M5 as it needs an additional char in index file and we wanted to measure impact on performances before release this change...
Comment 9 Frederic Fusier CLA 2006-02-15 12:14:37 EST
Verified for 3.2 M5 using build I20060215-0010.