Community
Participate
Working Groups
Build Identifier: 20110615-0604 When trying to open call hierarchy for the constructors of ThreadLocalMap, the private ThreadLocalMap(ThreadLocalMap parentMap) constructor works as expected, but for the ThreadLocalMap(ThreadLocal firstKey, Object firstValue) constructor no callers are found. Also for the constructor of ThreadLocalMap.Entry, which is called multiple times in ThreadLocalMap no callers are found by Open Call Hierarchy. Reproducible: Always Steps to Reproduce: 1. use Open Type to open ThreadLocalMap (from java.lang.ThreadLocal) 2. select the ThreadLocalMap(ThreadLocal firstKey, Object firstValue) constructor and run Open Call Hierarchy 3. in the call hierarchy view verify that no callers are found
Search for references also fails. JDT UI doesn't get any search results. AST and binding resolution look OK, since Mark Occurrences finds the references. However, IMethodBinding#getJavaElement() returns a wrongly inexistent element for these constructor bindings. The IMethod's parameter types seem to contain a "Ljava.lang.ThreadLocal<TT;>;" too much.
(In reply to comment #1) > Search for references also fails. JDT UI doesn't get any search results. > > AST and binding resolution look OK, since Mark Occurrences finds the > references. However, IMethodBinding#getJavaElement() returns a wrongly > inexistent element for these constructor bindings. The IMethod's parameter > types seem to contain a "Ljava.lang.ThreadLocal<TT;>;" too much. That first parameter is artfully crafted to match the binary signature, where the enclosing instance is passed to the constructor via synth arg. Let me see what else I can find..
(In reply to comment #2) > Let me see what else I can find.. Lots of confusion regarding constructors of binary nested classes :-/ First I had to learn that BinaryMethod indeed reflects the signature exactly as stored in the byte code, i.e., synthetic arguments are shown. Second, ThreadLocalMap being a static nested class does not insert synthetic arguments for its constructors. Third, org.eclipse.jdt.internal.core.util.Util.getUnresolvedJavaElement(MethodBinding, WorkingCopyOwner, BindingsToNodesMap) adds a synthetic argument even for constructors of static nested classes. Forth, ConstructorPattern(char[],char[],char[][],char[][],int,int) uses a halfhearted heuristic to determine whether the first parameter is such a synthetic one: "does the type match the enclosing class?" I assume this is the root cause for this particular problem, because ThreadLocal$ThreadLocalMap(ThreadLocal,Object) is an example of where this heuristic fails. In bug 277669 comment 6 Olivier mentioned that the current implementation fails for exactly one method in the whole JDK. Olivier, is this that one method?? Note that the related bug 275853 is still (or again) unresolved.
(In reply to comment #3) > Forth, ConstructorPattern(char[],char[],char[][],char[][],int,int) > uses a halfhearted heuristic to determine whether the first parameter > is such a synthetic one: "does the type match the enclosing class?" xref: this was introduced for bug 95152
Stephan, Moving to you as you are working on it.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
