Bug 26452 - Wrong automatically generated import statements
Summary: Wrong automatically generated import statements
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows 2000
: P3 normal (vote)
Target Milestone: 2.1 M4   Edit
Assignee: Olivier Thomann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-11-15 05:27 EST by Radek Szklarczyk CLA
Modified: 2002-12-17 10:37 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Radek Szklarczyk CLA 2002-11-15 05:27:11 EST
For the following class:

public final class OuterClass {
	
	void outerMethod() {
		
		new Object() {
			
			class Subroutine {
			}
			
			private void innerMethod() {
				Subroutine sub = null;
			}
			
		};
	}
}

When one presses ctrl+shift+o the following statement is added:

import OuterClass..Subroutine;
Comment 1 Adam Kiezun CLA 2002-11-15 07:43:18 EST
it actually puts something even stranger:

import OuterClass.$local$.Subroutine;

Comment 2 Martin Aeschlimann CLA 2002-11-19 11:41:44 EST
the type binding for A reports as 'isMember()' and 'isLocal' at the same time.
Comment 3 Olivier Thomann CLA 2002-11-19 14:29:26 EST
You mean the type binding for 'sub'?
Comment 4 Olivier Thomann CLA 2002-11-19 14:34:14 EST
Martin, isMember() and isLocal() answers true in this specific case. This is normal.
Strictly speaking this type is a member type and it is also a local type.
So in your algorithm you should check first isLocal() and then isMember().
Ok with that?
Comment 5 Martin Aeschlimann CLA 2002-11-20 03:33:39 EST
I think what you mean is isNested:
The Javadoc of ITypeBinding.isMember says:
 * <p>
 * A member type is any class or interface declared as a member of
 * another class or interface. A member type is a subspecies of nested
 * type, and mutually exclusive with local types.
 * </p>
Comment 6 Olivier Thomann CLA 2002-11-20 14:19:48 EST
Then the doc of isMember() should be fixed.
Comment 7 Jim des Rivieres CLA 2002-11-20 15:24:47 EST
I agree with Martin that the problem is that Subroutine is being classified
as isLocal and isMember. It should be classified as !isLocal and isMember,
because it is a member of a type. This aspect of the spec is consistent with 
JLS 14.3 ("A local class is a nested class that is not a member of any class 
and that has a name.") 

Our API is inconsistent with the JLS wrt local and anonymous classes (JLS says 
anonymous classes are not local classes, whereas our API says that
anonymous classes are a subspecies of local classes). While I wish we were 
better aligned with the JLS in all aspects, I believe we should leave the API 
as is and bring the implementation into line with it.

Expected outcome:
OuterClass - isClass, isTopLevel, !isLocal, !isAnonymous, !isMember, !isNested
anon #1 - isClass, !isTopLevel, isLocal, isAnonymous, !isMember, isNested
Subroutine - isClass, !isTopLevel, !isLocal, !isAnonymous, isMember, isNested
Comment 8 Olivier Thomann CLA 2002-11-20 16:11:29 EST
I will implement Jim's last statement.
Is this ok for you?
Comment 9 Olivier Thomann CLA 2002-11-20 16:54:58 EST
I have a fix for this one, but I won't release it as long as the JDT/UI tests
are not green. Even if without my changes, I have many errors, so it is
impossible for me to check that this fix doesn't break anything.
All JDT Core tests are green with the fix.
Comment 10 Martin Aeschlimann CLA 2002-11-21 09:15:54 EST
I fixed the tests. Please try again.

Is there a name for all types that are visibile, e.g can be imported (top level 
or a member where no declaring type is anonymous or local)?

This is a test I have to perform often and which I thought is solved with 
binding.isTopLevel || binding.isMember. From this PR I see that isMember is not 
enough and that I have to test the parents.
Comment 11 Olivier Thomann CLA 2002-11-21 09:43:14 EST
Your test binding.isTopLevel || binding.isMember is not enough anyway. You 
really need to find out that all parents are members or top levels. So I will 
release my change as soon as I run all the tests. We will have a consistent 
behavior according to the specs, but that won't solve your problem if you don't 
look through the parents.
Comment 12 Olivier Thomann CLA 2002-11-21 14:07:46 EST
I still have numerous errors in ExtractInterfacesTests.
Comment 13 Olivier Thomann CLA 2002-11-21 14:12:39 EST
I fixed the bug with isLocal() answering true for a member class of a local 
class.
Fixed and released in 2.1 stream.
Regression test added.
Comment 14 David Audel CLA 2002-12-17 10:37:14 EST
Verified.