Community
Participate
Working Groups
20021126 package p; class A{ A(){ } } class B extends A{ B(){ } } search for references to A's constructor - you'll find B's construcotr i guess that's because of the implicit call to super()
even worse here: package p; class A{ A(){ } } class B extends A{ } class B is reported as a reference to A
This works as designed. What is the problem?
Actually, this is a good feature for refactor: when refactoring A() to A(int i) in the second test case, you want to add a B(int i) constructor.
No response. Closing since it works as designed.
(sorry for not replying so long) are you sure? reporting a class as a reference to a construcotr is incorrect i think. also construcotrs are statically bounnd - reporting them as if there were a hierarchy of them is incorrect as well. in my code i had to put a rather nasty workaround for this bug.
> are you sure? Yes, I'm sure it was a design choice :-) (see JDT Core build notes and the 'New and noteworthy' notes for M2) >reporting a class as a reference to a construcotr is incorrect i think. If we want to report them, and the class as no constructor, this is the only IJavaElement we can provide. >also construcotrs are statically bounnd - reporting them as if there were a >hierarchy of them is incorrect as well. Not sure I understand this. What hierarchy? >in my code i had to put a rather nasty workaround for this bug. I'm sorry about that, but I think it is good to have it when doing a regular search. For example, a uses case would be: Before I delete a constructor I want to know what other constructors/classes will be impacted.
