Community
Participate
Working Groups
Build ID: M20080911-1700 Steps To Reproduce: 1. create a new java project 2. create a new class named "Test" 3. in the Test.java source import a non existing class: import somepackage.SomeClass; and use this class somewhere in Test: public class Test implements SomeClass {... 4. The generated Test.class contains references to the unavailable SomeClass. This is different from older versions (used 3.3.1.1 before) where all references got removed (which is better). More information: The 3.4. version correctly adds an empty constructor which throws an Error with "Unresolved compilation problems..." string. However the references are still there! Original Test.java code: package com.test; import somepackage.SomeClass; public class Test implements SomeClass {} Eclipse 3.4 compiled to Test.class and decompiled with jad: package com.test; import SomeClass; public class Test implements SomeClass{ public Test(){ throw new Error("Unresolved compilation problems: \n\tThe import somepackage cannot be resolved\n\tSomeClass cannot be resolved to a type\n"); } } As you see, the import of the classname is still there (only the packagename was removed?!) and the reference to the class SomeClass is also still there. The Error text in the constructor was created correctly, but the references are not removed. Older versions of Eclipse (used Eclipse 3.3.1.1 Europa before) generated a class file with all unresolved references removed: package com.test; public class Test{ public Test(){ throw new Error("Unresolved compilation problems: \n\tThe import somepackage cannot be resolved\n\tSomeClass cannot be resolved to a type\n"); } } I need the old behaviour back. It allows me to preverify the whole source (this is part of a MIDP build environment) and run a project even if it contains compile errors in classes that are not used at runtime. Additionally the generated class file seems to be invalid as the package name was removed from the import and such a class cannot be used even if the "somepackage.SomeClass" would be available.
I believe this comes from the missing type support. The only thing we need to do in this case would be to set the superclass to Object if it is a missing type.
> It allows me to preverify the whole source (this is part of a MIDP build environment) and run a project even if it contains compile errors in classes that are not used at runtime. The new behavior is required for JSR-269, so old behavior is not going to come back easily. How is it different from not being able to run binaries which are referring to types not on the classpath ? (i.e. the reference to missing type was present when compiled, but not available at runtime...). The new behavior is making both source and binary scenario behave somewhat consistently.
Actually this behavior breaks functionality provided before. Isn't there a way to provide a switch in the compiler settings to let the user configure the behavior? Maybe something like this: * Generate no classfile on compile Errors * Generate JSR-269 compatible classfiles I have no idea how much people will benefit from this change, but if we can't get back the old behavior eclipse >3.4 will be useless for us and quite a couple of other J2ME Developers which rely on this feature. Also any kind of suggestion to workaround this problem is very welcome.
So how is that different from a situation where some binaries are missing some super types ? I can see the trouble in your case for super types from sources. Are you asking for any method referencing a missing type in its signature being not included as well ?
Also note that this is not new in 3.4.1, this change got released along the lines of 3.4.0 (M4 or M5).
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
