Eclipse Community Forums: Java Development Tools (JDT) » InternalCompletionContext.getExpectedTypesKeys returns add type keys

Home » Language IDEs » Java Development Tools (JDT) » InternalCompletionContext.getExpectedTypesKeys returns add type keys

Show: Today's Messages :: Show Polls :: Message Navigator

InternalCompletionContext.getExpectedTypesKeys returns add type keys [message #1076342]

Wed, 31 July 2013 08:00

Marcel Bruch

Messages: 289
Registered: July 2009

Senior Member

Hi JDT,

we stumbled over a completion scenario which we can't make sense of. Maybe one of you guys can help us out here?

The code in which completion is triggered is as follows:

import java.util.*;

public class TestClass1  {
	public void __test() throws Exception {
		java.util.Arrays.asList(get$)
	}
}

For this particular completion location (->$), InternalCompletionContext.getExpectedTypesKeys returns "[Ljava/util/Arrays;.asList<T:Ljava/lang/Object;>([TT;)Ljava/util/List<TT;>;:TT;" which looks a bit broken to me.

Shouldn't it just return Ljava/util/List<T> or something along these lines?

Best,
Marcel

(We are working on Eclipse Kepler SR0)

Report message to a moderator

Re: InternalCompletionContext.getExpectedTypesKeys returns add type keys [message #1077506 is a reply to message #1076342]

Thu, 01 August 2013 20:28

Stephan Herrmann

Messages: 1853
Registered: July 2009

Senior Member

Hi Marcel,
Marcel Bruch wrote on Wed, 31 July 2013 10:00

InternalCompletionContext.getExpectedTypesKeys returns "[Ljava/util/Arrays;.asList<T:Ljava/lang/Object;>([TT;)Ljava/util/List<TT;>;:TT;" which looks a bit broken to me.

Yeah, that makes for some tricky parsing.

If this is to express the expected type for a parameter for asList() then we'd either expect T[] or T, right?

But then, T isn't really a type in Java, so we have to be more specific.

In a binary signature a type variable T would be encoded as "[TT;", but I guess the signature also has to include the element which declares T.

As we recognize "[" and "TT;" as head and tail of the string, we are left with this

Ljava/util/Arrays;.asList<T:Ljava/lang/Object;>([TT;)Ljava/util/List<TT;>;

Decoded into source language:

List<T> Arrays.asList<T extends Object>(T)

Yep, that's the element which declares "T".

Makes more sense now?

As you certainly don't want to do this parsing yourself, org.eclipse.jdt.core.Signature will be your friend, but you probably know that.

cheers,
Stephan

Report message to a moderator

Re: InternalCompletionContext.getExpectedTypesKeys returns add type keys [message #1077518 is a reply to message #1077506]

Thu, 01 August 2013 20:50

Marcel Bruch

Messages: 289
Registered: July 2009

Senior Member

Hi Stephan,

just to be sure i got you right. The signature is syntactically correct (I have no doubt now Wink

But why is expected type key not just the parameter of the first argument "T[]" (+ generics information) but the whole method signature?

Is the method signature what I must expect to get from getExpected*Type*Keys? (yes/no is enough)

Thanks,
Marcel

[Updated on: Thu, 01 August 2013 20:56]

Report message to a moderator

Re: InternalCompletionContext.getExpectedTypesKeys returns add type keys [message #1077531 is a reply to message #1077518]

Thu, 01 August 2013 21:08

Stephan Herrmann

Messages: 1853
Registered: July 2009

Senior Member

Quote:

(yes/no is enough)

The reason I started babbling in the first place is: I don't have a clear yes/no answer Smile

Looking at InternalCompletionContext.getExpectedTypeKeys90 I now see that we're not really speaking about signatures, but about Binding#computeUniqueKey().

So, to understand, why the string is so complex we should see that there may be many type variables called "T", but what we need here is a globally unique key.

For details and entertainment you might have a look at org.eclipse.jdt.internal.compiler.lookup.TypeVariableBinding.computeUniqueKey(boolean) Smile

OTOH, this being a key you shouldn't actually try to interpret this, but only use it for passing it back into JDT.

HTH,
Stephan

Report message to a moderator

Re: InternalCompletionContext.getExpectedTypesKeys returns add type keys [message #1077537 is a reply to message #1077531]

Thu, 01 August 2013 21:16

Marcel Bruch

Messages: 289
Registered: July 2009

Senior Member

Thanks again. Last question on this:

I would like to know that the expected type is an Array of Object to make reasonable recommendations. I just tried a couple of things on Signature but could not find a good result to resolve the type to something meaningful except [TT; - and apparently this signature thingish thing this goes a bit beyond my knowledge. Can scribble a way how I can resolve this in a secure way to a "normal" non-parameterized type?

This would certainly get you in the right position for a beer at EclipseCon Wink

Report message to a moderator

Re: InternalCompletionContext.getExpectedTypesKeys returns add type keys [message #1077561 is a reply to message #1077537]

Thu, 01 August 2013 22:01

Stephan Herrmann

Messages: 1853
Registered: July 2009

Senior Member

Question: how did you end up calling getExpectedTypesKeys(), wouldn't getExpectedTypesSignatures() be your guy?

The result from that method - I'd expect - should be ready for decoding by methods from class Signature, no?

For going from T to Object you could be lucky by calling getTypeParameterBounds().

Stephan

Report message to a moderator