Community
Participate
Working Groups
The AspectJ runtime does not support J2ME CLDC. It would be good to have a version of the runtime that runs on CLDC since it is the most common of all the Java platforms. The necessary modifications are mostly trivial and are required because certain classes and methods are missing from CLDC (e.g. java.util.List and java.lang.ClassLoader). The main problem that occurs with CLDC is that the primitive types (e.g. int) have no corresponding type (Integer.TYPE). This can be solved by writing a wrapper class, e.g. ClassOrPrimitive which can represent either a class or a primitive and is used in place of Class in the runtime. Once a patch to the existing runtime is created it could be used to create a CLDC version of the runtime for each release. The compiler also needs a small modification to work with CLDC. At present ajc will report an error that the java.io.Serialisable and java.lang.Cloneable classes are missing because these aren't present in CLDC.
I was aware that we had added some stuff to aspectjrt that might cause problems for Java 1.1 users (I guess we don't have many users on that level of Java). So I'm not surprised we are also affecting J2ME users - I would *love* to get the necessary patches to support J2ME. if they impact performance of the library too much we may have to think about packaging a second version for j2me consumers but I'd like to at least see what is involved in the change before deciding to ship multiple runtimes. Were you really using AJ 1.2.1? As recently we have changed the library a lot for AspectJ5 features and it may well use other classes that are missing in your environment - it would be nice if we could address this before AspectJ5 ships... I know how to fix the Serializable/Cloneable - that shouldn't be hard.
I'm attaching a patch for the org.aspectj/modules/runtime module against yesterday's CVS HEAD. J2ME CLDC [http://java.sun.com/products/cldc/] is a subset of J2SE. The primary restrictions of CLDC 1.0 are: No floating point types. No object finalization or weak references. No JNI or reflection (hence no object serialization). No thread groups or daemon threads. No application-defined class loaders. The ApsectJ runtime uses weak references, reflection, ThreadLocal and application-defined class loaders and also includes references to float and double. The patch removes the use of these features however I've tried to retain as much of the API as possible. I also removed ThreadStackFactory since it is unnecessary on CLDC (no CLDC implementation has ThreadLocal) and it is important to keep the number of classes to a minum on CLDC/MIDP devices (many applications use only two or three classes).
Created attachment 20502 [details] Patch against CVS HEAD 29/4/2005 to make the AspectJ runtime CLDC compatible.
Runtime is the surface of the iceberg. f.e. pertypewithin of 1.5.x is using WeakHashMap under the hood (the weaver inject some constructs, or the compiled aspect does use that even if your aspect source does not). aside the patch removes some must have things, like "Aspects" which is indeed reflection based. I think this CLDC support is likely to end up in a branch or at least in a new module, with a note on what is supported and what is not (f.e @pcd are probably not).
WeakHashMap, IIRC, is 1.2+ so this will break compatibility on 1.1 let alone CLDC. Putting the CLDC runtime library in a separate module makes sense to me since the changes are quite substantial and affect the features that are supported. The compiler will need to know if the target is CLDC or not and emit appropriate errors if an unsupported feature is used.
Take a look at this before 1.5.0 final ships. Shipping a separate aspectjrt.jar for this environment seems sensible, but significant modifications to the compiler to detect targetting the CLDC environment and putting out appropriate errors is likely to be beyond 1.5.0.
moving to 1.5.1 - not high enough priority for the majority of users to hold 1.5.0 for this.
I think the missing java.io.Serializable/java.lang.Cloneable errors are actually generated by Apache BCEL. org/aspectj/apache/bcel/Constants.java has the line: public final static String[] INTERFACES_IMPLEMENTED_BY_ARRAYS = {"java.lang.Cloneable", "java.io.Serializable"}; - this assumption is incorrect for CLDC.
1.5.1 includes FAQ update to say what works on what level of J2ME, can still do more.
... but that 'more' wont be done in 1.5.2
Bug 113948 might be one way to lay the groundwork for this.
I recently updated the patch to work with 1.5.2 (will upload when I get the time). I am using org.aspectj/modules/runtime as the base. Is this right? I've added empty java.io.Serializable and java.lang.Cloneable interfaces to the runtime to work around the compiler 'bug' detailed in comment #8. It is possible to use some features of AspectJ on CLDC (i.e. those that don't need reflection) with a very minimal runtime consisting of org.aspect.lang.NoAspectBoundException, java.io.Serializable and java.lang.Cloneable. Perhaps this could be added to the FAQ? (I'm happy to provide more specific instructions if necessary). I could package up a JAR with the runtime in and then the FAQ could include some short instructions on how to use it and point to this bug for people who want to use AspectJ with CLDC/MIDP right now.
Hi, I'm very much interested in your patch and runtime jar file. Have you posted them somewhere already? Thanks for the effort, I believe Aspectj+J2ME will be big.
I'm there with Juliano--It would be great if we could have the patch/jar of the modified sources/binary. I'm hoping to use AspectJ to develop J2ME tests and right now I'm stuck... I'm sure many other people would benefit from this... Thank you so much for your hard work! Best regards, Adrian (In reply to comment #14) > Hi, > > I'm very much interested in your patch and runtime jar file. Have you posted > them somewhere already? Thanks for the effort, I believe Aspectj+J2ME will be > big. > (In reply to comment #13) > I recently updated the patch to work with 1.5.2 (will upload when I get the > time). I am using org.aspectj/modules/runtime as the base. Is this right? I've > added empty java.io.Serializable and java.lang.Cloneable interfaces to the > runtime to work around the compiler 'bug' detailed in comment #8. > > It is possible to use some features of AspectJ on CLDC (i.e. those that don't > need reflection) with a very minimal runtime consisting of > org.aspect.lang.NoAspectBoundException, java.io.Serializable and > java.lang.Cloneable. Perhaps this could be added to the FAQ? (I'm happy to > provide more specific instructions if necessary). > > I could package up a JAR with the runtime in and then the FAQ could include > some short instructions on how to use it and point to this bug for people who > want to use AspectJ with CLDC/MIDP right now. > (In reply to comment #13) > I recently updated the patch to work with 1.5.2 (will upload when I get the > time). I am using org.aspectj/modules/runtime as the base. Is this right? I've > added empty java.io.Serializable and java.lang.Cloneable interfaces to the > runtime to work around the compiler 'bug' detailed in comment #8. > > It is possible to use some features of AspectJ on CLDC (i.e. those that don't > need reflection) with a very minimal runtime consisting of > org.aspect.lang.NoAspectBoundException, java.io.Serializable and > java.lang.Cloneable. Perhaps this could be added to the FAQ? (I'm happy to > provide more specific instructions if necessary). > > I could package up a JAR with the runtime in and then the FAQ could include > some short instructions on how to use it and point to this bug for people who > want to use AspectJ with CLDC/MIDP right now. >
My apologies for attaching the whole whack of comments earlier on :(
Does anyone have a newer version of the j2me patch? Looks like there is still no official version :-(
