Community
Participate
Working Groups
Linux Ubuntu 9.04 x86 JDK 1.6.0_13 Eclipse 3.5.0 Build id: I20090313-0100 (M6) Along with methods declared in type "StringBuffer", getMethods() returns some methods of supertype "AbstractStringBuilder", which does not match documentation. Looks like the returned array contains methods of AbstractStringBuilder which are overridden in StringBuffer but with covariant return type. This is contract violation, because according documentation IType.getMethods() must returns only methods declared in this type but not in supertypes. Example of incorrect method returned: java.lang.AbstractStringBuilder append(java.lang.Object)#2 [in StringBuffer [in StringBuffer.class [in java.lang [in /usr/lib/jvm/java-6-sun-1.6.0.13/jre/lib/rt.jar]]]] I tested this with jdk1.6 but I believe this is reproducible for jdk1.5 also.
Will investigate this.
(In reply to comment #1) > Will investigate this. Reproduced the problem with Sun JDK 1.6.0_13, Eclipse 3.5M7. Under investigation.
(In reply to comment #2) > (In reply to comment #1) > > Will investigate this. > Reproduced the problem with Sun JDK 1.6.0_13, > Eclipse 3.5M7. Under investigation. OK, After analysis, it appears that this case should be closed as INVALID as actually there is no bug here. The "extra" methods that are allegedly incorrectly returned are not originating from the super class, but instead are the "bridge" methods synthesized by the compiler on behalf of the sub class (in this case StringBuffer) to implement covariant return types. That getMethods may return synthetic methods is documented on IType.getMethods(): /** * Returns the methods and constructors declared by this type. * For binary types, this may include the special <code><clinit></code>; method * and synthetic methods. ... */ A client that doesn't want to see these synthetic methods can trivially filter them by code such as : BinaryType b = ... IMethod [] methods = b.getMethods(); for (int i = 0; i < methods.length; i++) { if (org.eclipse.jdt.core.Flags.isSynthetic(methods[i].getFlags())) continue; /* process methods[i] here */ For instance, the package explorer view uses this approach to filter out the synthetic methods from the viewer.
Verified for 3.5RC1
Oh, now I see. Thank you for your time.
