Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 77918

Summary: [compiler] Unnecessary implementation of interface in class declaration
Product: [Eclipse Project] JDT Reporter: Vijay Aravamudhan <avijayr>
Component: CoreAssignee: Kent Johnson <kent_johnson>
Status: CLOSED FIXED QA Contact:
Severity: enhancement    
Priority: P3 CC: akiezun, david_audel, ggregory, markus.kell.r, philippe_mulet
Version: 3.1   
Target Milestone: 3.4 M4   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
Suggested implementation + test cases
none
Proposed patch
none
Supplement to patch to make it suppressable none

Description Vijay Aravamudhan CLA 2004-11-04 21:35:40 EST
I have seen in a lot of projects where, at the initial time of development, a
subclass implements an interface. During sbsequent development, the super class
itself implements the same interface, and the subclasses need not explicitly
declare this relationship. But a lot of developers forget this and so it just
clutters the hierarchy. I am not sure whether this actually bloats the .class
files, but this could be considered a "code clean-up" issue and would be really
easy if there were a detector for this. Would it be easy to traverse the AST
tree and report such occurrances as compiler warnings or tasks?
Comment 1 Philipe Mulet CLA 2004-11-05 07:09:27 EST
Are you talking about having redundant references to an interface in a type
hierarchy ?

e.g.
class X implements I {}
class Y extends X implements I {} 
Comment 2 Vijay Aravamudhan CLA 2004-11-05 09:29:41 EST
YEs - that is exactly what I was referring to.
Comment 3 Philipe Mulet CLA 2004-11-05 12:00:29 EST
Indeed, this feels like a useful notification.
Comment 4 Kent Johnson CLA 2005-03-08 10:51:59 EST
*** Bug 84663 has been marked as a duplicate of this bug. ***
Comment 5 Markus Keller CLA 2007-02-02 04:48:58 EST
*** Bug 150229 has been marked as a duplicate of this bug. ***
Comment 6 Maxime Daniel CLA 2007-06-15 07:41:17 EDT
Exploratory work makes progress. The definite code will have to be fine-tuned depending on the results of bug 192620.
Comment 7 Maxime Daniel CLA 2007-06-18 05:01:22 EDT
Created attachment 71591 [details]
Suggested implementation + test cases

This is my first attempt to implement the feature, Kent please comment.

The following are known limitations/potential further improvements, that we may want to tackle or not depending on the cost/benefit analysis of each of them:
- I have chosen not to introduce a new warning token for this (neither for 
  SuppressWarning, nor for the -warn option of the batch compiler); I found none 
  that, IMO, matches this warning; accordingly, it will be tuned from the UI
  or the options file only, which I believe is acceptable;
- we may want to try to provide the user with a more detailed message, aka add
  one of the super-types that already implement the redundant interface; did the
  simplest thing so far;
- did not attempt to implement a similar check against interfaces themselves; 
  would need to climb up the extends chain; may be far less desirable a warning
  anyway.

The ISV doc will need to get modified once we all agree on names etc.

A separate bug will need to be opened against UI to surface the option in the preferences.
Comment 8 Kent Johnson CLA 2007-06-18 16:27:02 EDT
I think we should detect redundant interfaces in the MethodVerifier as we walk up the hierarchy to find superclasses/superinterfaces.

I also think we need to find redundant superinterfaces in interfaces & not just classes.
Comment 9 Maxime Daniel CLA 2007-06-19 08:38:52 EDT
(In reply to comment #8)
> I think we should detect redundant interfaces in the MethodVerifier as we walk
> up the hierarchy to find superclasses/superinterfaces.
I cannot see the relationship to methods. Could you elaborate please?
Comment 10 Kent Johnson CLA 2007-06-19 09:41:51 EDT
It has nothing to do with methods, but the verifier walks the hierarchy looking for inherited methods & can easily handle another warning about redundant interfaces.
Comment 11 Maxime Daniel CLA 2007-06-19 09:53:32 EDT
Sure. Yet segregating type-related checks into methods like ClassScope#checkParameterizedSuperTypeCollisions and others seems to be frequent in the current code base. Also, unless we make the default level for this to be warning instead of ignore, a separate call would likely optimize the 'default warnings' case (one single test to exclude the call - interleaving the checks into the method verifier code may call for more?)
Comment 12 Kent Johnson CLA 2007-06-28 15:24:10 EDT
Take a look at MethodVerifier15.findSuperinterfaceCollisions()

Should be able to add a warning in much the same way.
Comment 13 Vijay Aravamudhan CLA 2007-08-17 08:56:49 EDT
Is there any progress on integrating the supplied patch to the codebase?
Comment 14 Maxime Daniel CLA 2007-08-27 04:12:54 EDT
Philippe, is this to be reassigned to Kent?
Comment 15 Vijay Aravamudhan CLA 2007-11-01 12:08:11 EDT
Any updates on this?
Comment 16 Kent Johnson CLA 2007-11-01 12:21:35 EDT
No not yet - hopefully in the next few weeks, I'll take another crack at it.
Comment 17 Kent Johnson CLA 2007-11-07 15:09:34 EST
Created attachment 82360 [details]
Proposed patch

This seems to do the trick and gives us the possibility to cache the unique superinterfaces in the verifier
Comment 18 Kent Johnson CLA 2007-11-08 11:24:29 EST
Released into HEAD for 3.4M4

Added tests to GenericTypeTest and SuperTypeTest
Comment 19 Philipe Mulet CLA 2007-11-08 12:09:45 EST
Created attachment 82461 [details]
Supplement to patch to make it suppressable

With this extra change, the new warning should be suppressable using
@SuppressWarnings("unused")
Comment 20 Kent Johnson CLA 2007-11-08 12:25:13 EST
Released additional change in CompilerOptions and added AnnotationTest 239
Comment 21 David Audel CLA 2007-12-11 06:58:28 EST
Verified for 3.4M4 using build I20071210-1800.
Comment 22 Vijay Aravamudhan CLA 2008-01-09 17:04:40 EST
Closing
Comment 23 Markus Keller CLA 2009-10-02 09:40:28 EDT
*** Bug 75951 has been marked as a duplicate of this bug. ***