Bug 99606 - Subtype not found if parameterized on inner class
Summary: Subtype not found if parameterized on inner class
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.1 RC3   Edit
Assignee: Jerome Lanneluc CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-06-13 06:56 EDT by David Saff CLA
Modified: 2005-06-16 13:48 EDT (History)
3 users (show)

See Also:


Attachments
Change in SourceIndexerRequestor and DiskIndex (4.12 KB, patch)
2005-06-15 06:59 EDT, Jerome Lanneluc CLA
no flags Details | Diff
Regression test (2.17 KB, patch)
2005-06-15 06:59 EDT, Jerome Lanneluc CLA
no flags Details | Diff
Improved fix (4.21 KB, patch)
2005-06-16 06:21 EDT, Jerome Lanneluc CLA
no flags Details | Diff
Regression test (2.19 KB, patch)
2005-06-16 06:22 EDT, Jerome Lanneluc CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David Saff CLA 2005-06-13 06:56:00 EDT
In RC2.  Given code:

class Sub extends ArrayList<Sub.Color> {
	static class Color {}
}

Requesting a Type Hierarchy for ArrayList does not display Sub.  However, if Sub
is moved to a new file (note bug 99605), then ArrayList does show Sub as a subclass.
Comment 1 Dirk Baeumer CLA 2005-06-13 18:46:29 EDT
Only happens when ArrayList is paramterized with Sub.Color. Works for

class Sub extends ArrayList<String> {
	static class Color {}
}

however you have to close the type hiearchy view and reopen it. Type Sub is also
missing in the quick type hierarchy.

Moving to JDT/Core.
Comment 2 Philipe Mulet CLA 2005-06-14 15:49:48 EDT
Jerome - pls investigate as a possible RC3 candidate
Comment 3 Jerome Lanneluc CLA 2005-06-15 06:59:13 EDT
Created attachment 23153 [details]
Change in SourceIndexerRequestor and DiskIndex

Problem was in SourceIndexRequestor that didn't extract correctly the simple
name when the type was parameterized with a member type (Y<X.Color>).
Changed SourceIndexerRequestor to correctly extract the simple name in this
case and changed the DiskIndex version number to force reindexing.
Comment 4 Jerome Lanneluc CLA 2005-06-15 06:59:34 EDT
Created attachment 23154 [details]
Regression test
Comment 5 Philipe Mulet CLA 2005-06-15 07:41:35 EDT
+1 for RC3

Dirk - pls cast your vote
Comment 6 Dirk Baeumer CLA 2005-06-15 11:10:05 EDT
I know that I put the bug onto the important list of JDT/UI but given the
overall bug load and the "more than one line" fix I opt to postpone this one.
But this might be simply my paranoia. Comments from JDT/Core side ?

A couple of findings

+	int length = length = typeName.length;

looks strange to me.

Is it sure that the typeName never ends with a dot. Otherwise lastDot + 1 will
be outside of the char array. And can it happend that typename looks like
<nn.xx> when lastDot > lastGenericStart.

Might be a good 3.1.1 item.
Comment 7 Philipe Mulet CLA 2005-06-15 12:42:29 EDT
I would fix it still. Will review change with Jerome.
Note that I would walk the type name backwards instead.
Comment 8 Philipe Mulet CLA 2005-06-16 06:18:22 EDT
Change reviewed. Looks ok once loop is backward and weird assignment removed
(compiler should diagnose it).
Comment 9 Jerome Lanneluc CLA 2005-06-16 06:21:06 EDT
Created attachment 23280 [details]
Improved fix

Removed the int length = length = ... assignment (thanks Dirk).
Now looping from end to start.
Comment 10 Jerome Lanneluc CLA 2005-06-16 06:22:22 EDT
Created attachment 23281 [details]
Regression test

(previous regression test was for another bug)
Comment 11 Dirk Baeumer CLA 2005-06-16 06:53:10 EDT
Reviewed improved fix.

+1 for RC3.
Comment 12 Jerome Lanneluc CLA 2005-06-16 07:36:35 EDT
Thanks Dirk.
Released improved fix and regression test.
Comment 13 Olivier Thomann CLA 2005-06-16 13:48:44 EDT
Verified using N20050616-0010 + JDT/Core HEAD