Community
Participate
Working Groups
Suns Java 1.5 compiler has an option "-target cldc1.0", which should be supported by Eclipse. See: http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javac.html#crosscomp-options This option is useful when doing builds for a J2ME environment.
This is not the same stack map table attribute than the one for 1.6. I need to find the specs in order to know if the support for 1.6 could be tweaked to generate the attribute for cldc1.0.
I got access to the cldc1.0 specs and the StackMap attribute in cldc is different from the StackMapTable attribute in 1.6. They have some similarities, but it would required a specific handling. The data collected for the generation of the stack map table attribute should be sufficient to generate the stack map attribute.
Also cldc target should inline jsrs.
Should also check whether floating point is allowed there.
Not for 3.2, but maybe 3.3
Floating point is supported on CLDC 1.1
Strange enough - the cldc1.0 target option has disappeared from javac! The option is no longer present in the 1.5 documentation and javac for Java 6 no longer accepts the option. Anybody got a clue on WHY this has been dropped?
reopening for consideration during 3.4 cycle
We'll start by supporting CLDC1.1 first (updated title accordingly). And if needed we can try later on to support CLDC1.0.
(In reply to comment #9) > We'll start by supporting CLDC1.1 first (updated title accordingly). And if > needed we can try later on to support CLDC1.0. > That's fine with me.
The only difference from compiler standpoint between cldc1.0 and cldc1.1 is that floating point operations should be forbidden in cldc1.0. It is unclear whether we want to put in place a specific control on the compiler, or rather rely on users to restrain themselves. The latter seems to be fairly tolerated by users. So until this becomes an issue, we can safely claim cldc1.1 compliance. This being said, we could still want cldc1.0 target, to stamp the classfiles accordingly (still not rejecting floating point operations).
Created attachment 78342 [details] Proposed fix This patch adds cldc stack generation in the batch compiler when the target -cldc1.1 is used. It also automatically inlines the jsrs. I'll release it for 3.4M2. I keep this bug opened till we figure out if this is enough.
Of course to get the same support in Eclipse, the UI needs to be updated. Does it sound reasonable to limit the source version to 1.3 and the compliance version to 1.3? I don't see the point of having source 1.4 if assert statement cannot be supported (java.lang.AssertionError doesn't seem to be part of the cldc1.1 classes). Therefore it would be consistent to keep the compliance also to 1.3. Any thoughts?
We might want to be able to use compliance 1.4 since this is not incompatible with source 1.3. Technically speaking I am not sure that the compliance really matters, but I don't see the point of allowing 1.5 or above.
It seems that we could remove the generation of these attributes (Synthetic, SourceFile, LineNumberTable, LocalVariableTable and Deprecated) since these attributes don't need to be handled by a CLDC implementation.
Created attachment 78358 [details] Proposed fix Patch released for 3.4M2. It contains the new constant VERSION_CLDC_1_1 in org.eclipse.jdt.core.JavaCore that will allow the UI to update the compiler preference page.
(In reply to comment #14) > We might want to be able to use compliance 1.4 since this is not incompatible > with source 1.3. Technically speaking I am not sure that the compliance really > matters, but I don't see the point of allowing 1.5 or above. > Personally I would like to see the support for 1.5 due to the existence of generics (which is a really good thing considering avoidance of unnecessary bugs), but there may be other problems around that too.
(In reply to comment #17) > Personally I would like to see the support for 1.5 due to the existence of > generics (which is a really good thing considering avoidance of unnecessary > bugs), but there may be other problems around that too. I don't really understand the reason why 1.5 should be considered. 1) The cldc libraries don't contain generic types. I guess this is the case. 2) Since the compilation should be done with cldc libraries on the classpath, the compiler won't like the fact that generics are used if the libraries are not generics. For example, import java.util.Hashtable; public class X { public static Hashtable<String> context; } ends up with this error when cldc1.1 libraries are used to compile the code. ---------- 1. ERROR in D:\tests_sources\X.java (at line 4) public static Hashtable<String> context; ^^^^^^^^^ The type Hashtable is not generic; it cannot be parameterized with arguments <String> ---------- 1 problem (1 error) A cldc1.1 implementation is supposed to be able to "read" .class files up to 1.4 target. I haven't read anything related to the java.lang.AssertionError not being present in cldc1.1 libraries. I don't see how 1.4 code that uses assertions could be run on a cldc1.1 implementation. I don't have a reference platform to try it. Do you still believe that 1.5 should be supported?
The request in comment 17 sounds similar to allowing compiling 1.5 sources for 1.4 targets (-target jsr14). This is a separate issue to pure CLDC 1.1 output which is the goal of this bug report. As said, CLDC1.1 libraries are not generic today, and not using Java5 sources. I recommend closing this bug as fixed, and leaving 1.5 concerns to a separate (new) bug.
OK(In reply to comment #19) > The request in comment 17 sounds similar to allowing compiling 1.5 sources for > 1.4 targets (-target jsr14). This is a separate issue to pure CLDC 1.1 output > which is the goal of this bug report. > > As said, CLDC1.1 libraries are not generic today, and not using Java5 sources. > > I recommend closing this bug as fixed, and leaving 1.5 concerns to a separate > (new) bug. > OK
Released for 3.34M2.
Verified with 3.2M4.
