Summary: | [1.5][compiler] Contrary behaviour to Sun's compiler concerning typed classes, non-static inner classes and inheritence | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Tobias Riemenschneider <tobys> | ||||
Component: | Core | Assignee: | Philipe Mulet <philippe_mulet> | ||||
Status: | VERIFIED FIXED | QA Contact: | |||||
Severity: | critical | ||||||
Priority: | P3 | ||||||
Version: | 3.2 | ||||||
Target Milestone: | 3.2 M6 | ||||||
Hardware: | PC | ||||||
OS: | Windows XP | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Tobias Riemenschneider
2006-02-23 12:23:21 EST
Please explain why this is 'critical' ? (In reply to comment #1) > Please explain why this is 'critical' ? We (research group database systems [http://dbs.mathematik.uni-marburg.de] of Philipps-University Marburg [http://www.uni-marburg.de]) use Eclipse for developing our research projects PIPES [http://dbs.mathematik.uni-marburg.de/Home/Research/Projects/PIPES] and XXL [http://dbs.mathematik.uni-marburg.de/Home/Research/Projects/XXL]. For several conferences (e.g. ICDE [ http://icde06.cc.gatech.edu/] and EDBT [http://www.edbt2006.de]) we need code that is compatible with Java - but it cannot be developed using Eclipse. Even worse, Eclipse shows a completely contrary behaviour to Sun's compiler, i.e., code that is Java-compatible isn't accepted by Eclipse and code that is 'Eclipse'-compatible isn't accepted by Java. As a workaround we must develop our projects using Eclipse and in a second step verify the code produced by Eclipse for being Java-compatible and fixing the bugs made by Elipse, before publishing code fragments and the whole library respectively. That causes an additional expenditure of time and it is rather difficult for our research group to compensate it. I understand. Is this the only pattern you saw ? I believe this is a bug in javac 1.5. No capture should be involved in this process. FYI - javac from jdk1.6b73 does also accept the code as expected. Added regression test: GenericTypeTest#test924 Glancing through their bug database, they seem to have a couple of issues with generic member types. Some of them got fixed in 6.0 only. Seems to be one of these (couldn't find a specific bug for it though). You should report this to them. Closing as invalid, since our behavior is legite. Simpler testcase: import java.util.*; public class X { public void foo() { List<? extends List<Object>> RESULT = null; List<? extends Object> lst = null; RESULT = Collections.singletonList( Collections.singletonList( lst.get(0))); } } oops wrong bug for previous comment addition I've compared javac's behaviour (1.6.0-beta2-b73) with 3.2M5a's behaviour and I still think there's a bug related to 3.2M5a. While javac compiles the different versions mentioned in the report without any compile time error, 3.2M5a rejects some versions as being wrong. Below I will provide a complete list of the different cases and compare javac's and 3.2M5a's behaviour. The third case shown below is rejected by 3.2M5a although - as mentioned in comment #4 - no capture should be involved in this process, while javac accepts all cases. (1) First method definition: > Test.java >>> class Outer<O> { class Inner {} static void method(Outer.Inner x) {} } class ExtendedOuter<E> extends Outer<E> { class ExtendedInner extends Inner { { Outer.method(this); } } } < Test.java <<< Both, javac and 3.2M5a accept the piece of code. (2) Second method definition: > Test.java >>> class Outer<O> { class Inner {} static void method(Outer<?>.Inner x) {} } class ExtendedOuter<E> extends Outer<E> { class ExtendedInner extends Inner { { Outer.method(this); } } } < Test.java <<< Both, javac and 3.2M5a accept the piece of code. (3) Third method definition: > Test.java >>> class Outer<O> { class Inner {} static <I> void method(Outer<I>.Inner x) {} } class ExtendedOuter<E> extends Outer<E> { class ExtendedInner extends Inner { { Outer.method(this); } } } < Test.java <<< 3.2M5a rejects the method as being not applicable for the given argument, while javac accepts it. Agreed. The latter scenario should be accepted. Problem lies in our inference when dealing with enclosing parameterized types. Added GenericTypeTest#test937-939 Created attachment 35608 [details]
patch for properly inferring through enclosing param type
Good find Tobias. Released fix to HEAD. If you find subsequent issues, please file them as new bug reports. Verified for 3.2 M6 using build I20060328-0010 |