Bug 87463 - The built-in Eclipse compiler behaves differently than IBM or Sun JDK
Summary: The built-in Eclipse compiler behaves differently than IBM or Sun JDK
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.0.1   Edit
Hardware: PC Windows XP
: P3 critical (vote)
Target Milestone: 3.1 M6   Edit
Assignee: Philipe Mulet CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-03-08 22:03 EST by Thomas Pollinger CLA
Modified: 2005-03-31 09:55 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 Thomas Pollinger CLA 2005-03-08 22:03:33 EST
The following code snippet does not compile in Eclipse 3.0.1 or 3.1 (it however
compiles in Eclipse 2.0.3 or with IBM or Sun JDK 1.4.2):

public class test2 {
    public void test() {
        class C {
            public C() {}

            public void foo() {
                System.out.println("hello");
            }
    	}

        int n = 0;
        switch (n) {        
	    case 0: {
        	C c2 = new C();
    	}
        }
    }
}

The following modifications make it work:
1. Adding another case 1: below case 0: that refers to C makes it compile.
2. Removing the inner scope in case 0: makes it work.
3. Moving the inner class C from the method scope to the test2 scope makes it
work as well.
Comment 1 Thomas Pollinger CLA 2005-03-08 22:06:32 EST
BTW, forgot to mention the compiler error message:

Severity	Description	Resource	In Folder	Location	Creation Time
2	C cannot be resolved or is not a type	test2.java	test	line 27	March 8, 2005
19:01:05
Comment 2 Philipe Mulet CLA 2005-03-09 03:47:56 EST
Reproduced. This is indeed our bug.
Comment 3 Philipe Mulet CLA 2005-03-09 03:48:39 EST
When addressed, do you need this to be backported to 3.0.* maintenance stream ?
i.e. how 'critical' is this ?
Comment 4 Philipe Mulet CLA 2005-03-09 09:15:12 EST
Problem got introduced when adding support for preventing referencing local
types across switch case statement blocks (see bug 52221).
Tuned implementation to handle this situation, and also possibly nested switch
statements:

public class X {
	public void test() {
		int l = 1;
		switch(l) {
			case 1: 
				class C {
					public C() {
					}
		
					public void foo() {
						System.out.println("hello");
					}
				}
				int n = 0;
				switch (n) {
					case 0 :
						if (true) {
							C c2 = new C();
						}
				}
		}
	}
}

Added LookupTest#052-053.
Fixed
Comment 5 Thomas Pollinger CLA 2005-03-09 17:43:43 EST
We have a workaround for this problem where if this specific case happens, it
can be compiled by the regular JDK that sits on the server. As such, it would
not qualify for upgrading our current 3.0.1 workbench to have this fix in. The
next window of opportunity to upgrade the workbench might probably be 3.1 already.
So from our standpoint, it does not need to be backported to 3.0.x.
Thanks for the quick turnaround.
Comment 6 Philipe Mulet CLA 2005-03-09 17:49:06 EST
Thanks for the assessment
Comment 7 David Audel CLA 2005-03-31 09:55:12 EST
Verified in I20050330-0500