Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Language IDEs » Java Development Tools (JDT) » InternalCompletionContext.getExpectedTypesKeys returns add type keys
InternalCompletionContext.getExpectedTypesKeys returns add type keys [message #1076342] Wed, 31 July 2013 08:00 Go to next message
Marcel Bruch is currently offline Marcel BruchFriend
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)
Re: InternalCompletionContext.getExpectedTypesKeys returns add type keys [message #1077506 is a reply to message #1076342] Thu, 01 August 2013 20:28 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
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
Re: InternalCompletionContext.getExpectedTypesKeys returns add type keys [message #1077518 is a reply to message #1077506] Thu, 01 August 2013 20:50 Go to previous messageGo to next message
Marcel Bruch is currently offline Marcel BruchFriend
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 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
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
Re: InternalCompletionContext.getExpectedTypesKeys returns add type keys [message #1077537 is a reply to message #1077531] Thu, 01 August 2013 21:16 Go to previous messageGo to next message
Marcel Bruch is currently offline Marcel BruchFriend
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
Re: InternalCompletionContext.getExpectedTypesKeys returns add type keys [message #1077561 is a reply to message #1077537] Thu, 01 August 2013 22:01 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
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
Re: InternalCompletionContext.getExpectedTypesKeys returns add type keys [message #1078012 is a reply to message #1077561] Fri, 02 August 2013 12:24 Go to previous message
Marcel Bruch is currently offline Marcel BruchFriend
Messages: 289
Registered: July 2009
Senior Member

You probably made my day...
Previous Topic:How do I change the default window that source files get opened in?
Next Topic:AST Newbee Question
Goto Forum:
  


Current Time: Thu Apr 18 17:26:21 GMT 2024

Powered by FUDForum. Page generated in 0.02044 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top