Community
Participate
Working Groups
BETA_JAVA7 For bug 351048, we'd like to render the type arguments of the declaring type for a constructor invocation in the Javadoc hover. Example: new ArrayList<>() codeSelect returns an IMethod with key: Ljava/util/ArrayList<Ljava/lang/String;>;.()V The necessary information is already available in the key, but BindingKey doesn't offer API to read the type arguments of the declaring type. Best would be an API like this: /** * Returns the binding key of the declaring type of the element * represented by this binding key. If the binding key does not represent * a member or if the member doesn't have a declaring type, returns * <code>null</code>. * * @return the type binding key or <code>null</code> * @since 3.7 */ public BindingKey getDeclaringType() { // FIXME: this is a hack int dot = this.key.indexOf('.'); if (dot == -1) return null; return new BindingKey(this.key.substring(0, dot)); } An alternative could be to improve IMethod#getDeclaringType(): Currently, this returns an unresolved type, but it could also return a resolved type whose key contains the type arguments.
I will work on this.
Created attachment 199650 [details] Proposed patch + tests
Markus, Can you please review. Thanks in advance.
Created attachment 199675 [details] Patch for ASTView We have a problem with parameterized types here. Apply the attached patch to the ASTView (http://www.eclipse.org/jdt/ui/astview/, take BETA_JAVA7 branch). I expected the new binding properties "*** getKey().getDeclaringType()" and "*** getDeclaringClass().getKey()" to always be the same. But in some cases, the binding key doesn't contain the declaring type's type parameters (declarations of fields, methods, type parameters) while for member and local types, and for references to fields and methods, the type arguments are available. I'm not sure yet what's the best way to proceed. Ideas welcome. For bug 351048, I only need the type arguments for constructor invocations. Maybe we should narrow the API to just support this use case. Here's my toy class: package org.test; public class BindingKeysTest<TPAR> { static class StaticMember { } class Member { } int field; BindingKeysTest<? extends java.util.List<TPAR>> field2; void foo() { int var; BindingKeysTest<Integer> var2= new BindingKeysTest<Integer>(); var2.foo(); field2= new BindingKeysTest(); class Locl<E> { /** * Ctor * @param arg the arg! */ public Locl(E arg) { } } Locl<Integer> locl = new Locl<Integer>(42); System.out.println(locl); class Local2 { /** * Ctor Local2 */ Local2() { } } Local2 l2= new Local2(); } }
(In reply to comment #4) Thanks Markus for catching the issues. I completely missed verifying the declarations. I should use the ASTview! As the signature doesn't have the type information of the type for declarations, this API probably doesn't make sense. I couldn't think of any good alternative apart from you doing the same in your code. cc'ing Olivier for any ideas.
I think the best solution is to go with the proposed patch but document the limitations e.g. like this: * <p> * Note that only binding keys for references to methods and fields * are fully supported. E.g. the declaring type of a method declaration * will miss any type parameters.
I agree that documenting the limitations is one option but this can be done in JDT/UI and hence why is the API needed?
> this can be done in JDT/UI and hence why is the API needed? Because the format of the keys is not specified, see IBinding#getKey(). Since the format can change, parsing the key would be a illegal access to internal information.
(In reply to comment #8) > > this can be done in JDT/UI and hence why is the API needed? > > Because the format of the keys is not specified, see IBinding#getKey(). Since > the format can change, parsing the key would be a illegal access to internal > information. However the key as in char[] is returned by the JDT/Core. Hence, I will be sceptical of changing that.
Yes, that's what IBinding#getKey() says. But it doesn't matter, since we won't add a layer breaker anyway. Parsing of the key format is a JDT Core job. So we have 3 choices: 1. Do nothing, i.e. don't implement bug 351048. 2. Release the patch with the additional Javadoc. 3. Try to implement the alternative I mentioned in comment 0 (make IMethod#getDeclaringType() return a resolved type if the target IMethod is resolved) My favorite is 3.
> My favorite is 3. *** Bad typo ***, I meant my favorite is **2.**
(In reply to comment #11) > > My favorite is 3. > *** Bad typo ***, I meant my favorite is **2.** Same for me. We should prevent external scanning of the keys as much as possible.
Created attachment 200490 [details] Proposed patch + regression test Same patch with the updated javadoc.
We are taking stock of where things stand for 3.7.1 - Markus, does the patch posted at comment#13 meet your needs ?
> Markus, does the patch posted at comment#13 meet your needs ? Yes, but you have to change it to @since 3.7.1 (+ an API filter for the warning).
Made the since tag to have 3.7.1 and added the filters and released in 3.7.1 and HEAD.
Verified in M20110825-0847 and I20110823-0925. Filed bug 355934 for a problem with constructor invocations that are assigned to a field.
