Bug 434960

Summary: Noextend and Noimplement on superclass's superclass is not respected
Product: [Eclipse Project] PDE Reporter: Vikas Chandra <Vikas.Chandra>
Component: API ToolsAssignee: PDE API Tools Inbox <pde-apitools-inbox>
Status: RESOLVED WONTFIX QA Contact:
Severity: normal    
Priority: P3 CC: curtis.windatt.public
Version: 4.4Keywords: readme
Target Milestone: 4.4   
Hardware: PC   
OS: Windows 7   
Whiteboard:
Attachments:
Description Flags
test project to recreate this
none
problem after the fix none

Description Vikas Chandra CLA 2014-05-15 09:14:38 EDT
Created attachment 243124 [details]
test project to recreate this

In plugin 1


public class ClassTest1 extends ClassTest2 implements inf1{


}


In plugin 2
public class ClassTest2 extends ClassTest3{

}
import org.eclipse.pde.api.tools.annotations.NoExtend;

@NoExtend
public class ClassTest3 {

}

There should be an error reported that ClassTest2 cannot extend ClassTest3 but no errors come.

Same for noimplement
Comment 1 Curtis Windatt CLA 2014-05-15 09:20:28 EDT
I'm guessing this is similar to bug 433527 where we don't walk the entire hierarchy for performance reasons.
Comment 2 Vikas Chandra CLA 2014-05-22 09:23:44 EDT
Created attachment 243396 [details]
problem after the fix

This will be the error after the fix for @NoExtends. I am refining/cleaning the code currently.

The approach is same as used in  IllegalImplementsProblemDetector.

considerReference(IReference reference) for IllegalExtendsProblemDetector would be overrided . A map of fRestrictedClasses would be kept which will have all the superclasses as the classes to be checked during isProblem ( which again would be overriden in IllegalImplementsProblemDetector).

The problem string will be changed as per the image attached.

Since all these superclass are already cached, I don't expect a performance hit.
We need to be more careful while fixing the refresh bug .

Please let me know if the problem message and the approach is OK .
Comment 3 Curtis Windatt CLA 2014-05-22 12:07:38 EDT
This is a case where adding an API problem would likely cause more problems than it would solve.  While I would describe this as 'poor API design' in plugin 2, API Tools has to assume it was done intentionally.  ClassTest1 is using an API with no direct restrictions, and they shouldn't be given an api error for using ClassTest2.