Community
Participate
Working Groups
I20051130-1215 Several jdt.core APIs don't work correctly for a constructor of a binary inner class. One thing is bug 47354 (wrong display in the outline view), but there are many other cases where APIs don't work e.g. on constructor java.util.zip.ZipFile.ZipFileInputStream(long, long, ZipFile): - codeSelect returns the enclosing type, not the constructor - getElementAt() returns the enclosing type - search does not work on the element when selected in the outline - the element from the outline does not have a valid source range - IMethodBinding#getJavaElement() returns a non-existent IMethod (which would nevertheless have the right parameter names, parameter types, and source range). Feel free to mark as dup of bug 47354 if this is really all the same problem.
Created attachment 31868 [details] Proposed patch and regression tests
Released patch and regression tests. Note that finding references to such constructor still doesn't work and is captured in bug 122880.
I just synchronized with JDT/Core HEAD and tried the fix. It seems to work fine, but there's an inconsistency now: IMethod#getParameterNames() now returns 2 names, but IMethod#getParameterTypes() still returns 3 types (including the synthetic parameter). Shall I open a new bug for this or will it be addressed as part of bug 122880 or bug 47354?
That would be the same problem as described in bug 47354. getParameterNames() comes from the attached source and getParameterTypes() comes from the binary. Unfortunately binary and source are always inconsistent in the case of a method/constructor of a binary member type.
Verified for 3.2 M5 using build I20060214-0010.
I'm not sure if I have found the same problem again in RC1, Build id: I20060413-1718. I'm trying to get source range for explicit constructors of inner classes from binary types, like the one from HasMap$Entry class in JDK 1.5. If I call IClassFile.getElementAt() on HashMap, then I get the Entry as BinaryType, but not the constructor itself. If I then call IClassFile.getElementAt() on HasMap$Entry, then I get null because org.eclipse.jdt.internal.core.SourceMapper could not find the appropriate source range for binary method (Entry constructor) in getSourceRange(). But the source code for this constructor exist (and the binary method "Entry" itself too), so I think that the bug is still not fixed. As summary: - getElementAt() returns the enclosing type - SourceMapper.getSourceRange() returns UNKNOWN_RANGE
Oh, the difference to the first example java.util.zip.ZipFile.ZipFileInputStream is that java.util.HasMap.Entry is a static inner class and it uses generics. In my case java.util.zip.ZipFile.ZipFileInputStream seems to work fine (got right source range for it), but java.util.HasMap.Entry not...
Andrei, could you please open a new bug with steps to reproduce the problem and we will investigate ?
comment 8: I have entered bug 137847.
