99995 – [code assist] Code Assist for parameterized anonymous types: overridden methods for raw, not parameterized

Bug 99995 - [code assist] Code Assist for parameterized anonymous types: overridden methods for raw, not parameterized

Summary: [code assist] Code Assist for parameterized anonymous types: overridden metho...

Status:	VERIFIED FIXED

Alias:	None

Product:	JDT
Classification:	Eclipse Project
Component:	UI (show other bugs)
Version:	3.1
Hardware:	PC Windows XP

Importance:	P3 normal (vote)
Target Milestone:	3.1.1
Assignee:	Tobias Widmer
QA Contact:

URL:
Whiteboard:
Keywords:

Depends on:
Blocks:

Reported:	2005-06-14 12:04 EDT by Markus Keller
Modified:	2005-09-02 08:27 EDT (History)
CC List:	2 users (show)

See Also:

Attachments
patch (8.08 KB, patch) 2005-06-16 05:54 EDT, Tobias Widmer	no flags	Details \| Diff
View All 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 Markus Keller

2005-06-14 12:04:01 EDT

I20050610-1757 (3.1RC2)

public class Anon {
	void test() {
		new java.util.ArrayList<Integer>()
	}
}

Invoke content assist after 'ArrayList<Integer>(' and choose the anonymous.
-> The methods to be overridden are constructed for a raw ArrayList (they have
their 'E's replaced by 'Object' instead of 'Integer').

Comment 1 Dirk Baeumer

2005-06-14 17:25:54 EDT

Tobias, can you please investigate.

Comment 2 Tobias Widmer

2005-06-15 12:03:57 EDT

The problem is IJavaProject#findType, which does not work for parameterized 
types and local types. To fix the case for parameterized types, I suggest to 
extract the correct type signature from the proposal's signature.

To fix the proposal for local types, we have to investigate in using the 
supplied binding key. This won't happen anymore for 3.1.

Comment 3 Tobias Widmer

2005-06-16 05:54:52 EDT

Created attachment 23276 [details]
patch

This patch fixes the code to retrieve the supertype to use the declaration
signature obtained from JDT Core

Comment 4 Tobias Widmer

2005-06-16 05:58:17 EDT

Filed bug 100365 to track binding key issue

Comment 5 Dirk Baeumer

2005-06-16 06:13:55 EDT

Tobias, in general not renaming elements makes it easier to read patches.

Some questions:

- why do we check fDeclarationSignature != null. We assert it to not be null in
  the constructor.
-

+1 for RC3 from my side, but I want to get Martins opinion because he knows this
area very well.

Martin, can you please vote

Comment 6 Tobias Widmer

2005-06-16 06:18:27 EDT

The name fDeclaringType is a misnomer and has lead to some confusion when 
reviewing the code.

Comment 7 Tobias Widmer

2005-06-16 06:19:20 EDT

The null check is indeed not necessary

Comment 8 Dirk Baeumer

2005-06-16 09:46:18 EDT

After checking it again the patch as some low risk to break scenarios that are
currently tested. To avoid redoing the testing I now opt to postpone > 3.1

Tobias, this is a good candiate for 3.1.1. We should release it early 3.2 and
the think about back porting it.

Comment 9 Tobias Widmer

2005-06-30 05:41:29 EDT

Fixed in HEAD > 20050630

Comment 10 Tobias Widmer

2005-08-08 07:02:27 EDT

Martin, can you please vote on this one?

Comment 11 Martin Aeschlimann

2005-08-09 04:58:57 EDT

patch looks good!

Comment 12 Tobias Widmer

2005-08-10 08:49:10 EDT

Fixed in 3.1 maintenance stream > 200508010

Comment 13 Tom Hofmann

2005-09-02 08:10:32 EDT

verifying...

Comment 14 Tom Hofmann

2005-09-02 08:27:12 EDT

verified the correct type substitutions are made.