Community
Participate
Working Groups
I'm using Eclipse 3.0 (final release) and Cheetah06. In my project I have following settings: compiler compliance level - 1.5, generated class files compatibility - 1.4, source compatibility - 1.5, JRE 1.4 is in the build path. I found that simple string concatenation [a + b] is compiled to [(new StringBuilder(a)).append(b)]. When started with JRE 1.4 this program fails with NoClassDefFoundError exception (because StringBuilder is not present in JRE 1.4). Some analysis: I looked at Cheetah 06 sources and found that not target JDK version but source JDK version setting was used to make decision if it's possible to use such JDK 1.5 optimizations. Perhaps problem is in the org.eclipse.jdt.internal.compiler.codegen.CodeStream class. This class has field "targetLevel" that is used for optimization decision in different methods. In constructor this field is initialized by "sourceLevel" parameter. This constructor is called from 2 other classes: 1. From org.eclipse.jdt.internal.compiler.ClassFile constructor. It uses project "source compatibility" setting as "sourceLevel" parameter value. 2. From org.eclipse.jdt.internal.eval.CodeSnippetCodeStream (subclass of CodeStream) constructor. It uses hard coded JDK 1.4 value for "sourceLevel" parameter.
I think this bug affects all CodeStream revisions (incl. latest 3.1 builds).
Your settings are illegal. This is now rejected in latest 3.1 builds. It doesn't make sense to set the source compatibility to 1.5 and the generated class files compatibility to 1.4. The compiler is setting the generated class files compatibility to 1.5 if the source compatibility is 1.5.
I fixed the target level to be used in the CodeStream instead of the source level. This is what it was supposed to be, but we won't allow this setting to be valid. source compatibility 1.5 => generated class files compatibility 1.5.
Configuration issue won't be fixed. See bug 72640 for the issue with the target level of the code stream not being initialized with the right value.
