Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 463533 - Signature.getSignatureSimpleName() returns different results for resolved and unresolved extends
Summary: Signature.getSignatureSimpleName() returns different results for resolved and...
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 4.5   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 4.5 M7   Edit
Assignee: Stephan Herrmann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 334281
  Show dependency tree
 
Reported: 2015-03-30 21:35 EDT by Brian de Alwis CLA
Modified: 2015-04-27 04:22 EDT (History)
2 users (show)

See Also:
jarthana: review+

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Brian de Alwis CLA 2015-03-30 21:35:29 EDT 
4.5 M6

I'm seeing different results from Signature.getSignatureSimpleName() when called with an extends type signature.

From a display page:

    Signature.getSignatureSimpleName("+Ljava.lang.CharSequence;")
	 (java.lang.String) CharSequence

    Signature.getSignatureSimpleName("+QCharSequence;")
	 (java.lang.String) ? extends CharSequence

This came about from bug 334281c4 where we're trying to determine if two method signatures, one resolved and the other unresolved, are the same:

   (Ljava.lang.Iterable<+Ljava.lang.CharSequence;>;Lorg.eclipse.xtext.util.IAcceptor<Lorg.eclipse.xtext.xbase.compiler.CompilationTestHelper$Result;>;)V

   (QIterable<+QCharSequence;>;QIAcceptor<QResult;>;)V
Comment 1 Stephan Herrmann CLA 2015-03-31 12:05:21 EDT 
I can see that org.eclipse.jdt.core.Signature.getSignatureSimpleName(char[]) is inconsistent between the two given examples. When simplifying the resolved variant we drop the "? extends" prefix.

Given that Signature is API with lots of clients I'm reluctant, however, to make a call which version is correct, or even: whether the given input should be accepted.

The javadoc requires a "type signature" as input. Strictly speaking, a wildcard in Java is not a type. OTOH, I can see that getTypeSignatureKind(char[]) does accept wildcards (and will answer WILDCARD_TYPE_SIGNATURE).

Adjusting the resolved case to what we already answer in the unresolved case seems to make sense, but deciding either way feels like an API change to me.
Comment 2 Eclipse Genie CLA 2015-03-31 12:30:14 EDT 
New Gerrit change created: https://git.eclipse.org/r/44931
Comment 3 Stephan Herrmann CLA 2015-03-31 12:33:45 EDT 
(In reply to Eclipse Genie from comment #2)
> New Gerrit change created: https://git.eclipse.org/r/44931

@Jay, the proposed fix is straight-forward, but I'd still like a second and third opinion before releasing (including Hudson).
Comment 4 Jay Arthanareeswaran CLA 2015-04-01 02:40:08 EDT 
Patch looks good.
Comment 6 Stephan Herrmann CLA 2015-04-01 14:58:35 EDT 
(In reply to Jay Arthanareeswaran from comment #4)
> Patch looks good.

thanks, released for 4.5 M7.
Comment 7 Jay Arthanareeswaran CLA 2015-04-27 04:22:09 EDT 
Verified for 4.5 M7 with build I20150426-2000.