Re: [aspectj-users] AspectJ 1.1 and J2ME

[Ayla Débora <ayladebora@xxxxxxxxxx>]

Hi everybody,

if anybody else is interested in using AspectJ 1.1 with J2ME, I've found a
solution. I know it is not the best one, but it can help.
I'm using "ANT" to perform the following tasks in order to compile and
execute in the emulator a J2ME application using aspects:
1 - Compile the .java files that are not aspects using "javac", with
"bootclasspath" option set to MIDP api.
2 - Generate a JAR containing the generated .class files
3 - Invoke "ajc" by "iajc" task from ANT entering the JAR generated on the
previous step and the aspect files as "injars" and "sourceroots" values
respectively.
4 - Execute "preverify.exe" from the Wireless Toolkit with the classes
generated on step 3 as an argument, and "aspectjrt.jar" in the classpath
5 - Execute "emulador.exe", also from the Toolkit, and include the
preverified classes in the classpath.

Attention: Depending on the AspectJ constructions being used, some AspectJ
.class files must be included in the preverified classes directory, but it
may be necessary to change them, compile and preverify before.

Best regards,
  Ayla

----- Original Message -----
From: <Jim.Hugunin@xxxxxxxx>
To: <aspectj-users@xxxxxxxxxxx>
Sent: Thursday, June 19, 2003 2:12 PM
Subject: RE: [aspectj-users] AspectJ 1.1 and J2ME


> ayladebora wrote:
> > I've done the same thing with AspectJ 1.06. But with
> > AspectJ1.1 we don't have the -preprocess option. One possible
> > solution (that I have not tried yet) would be to use ajc (and
> > the midpapi as a library) and compile the code, including
> > aspects. Then, we decompile the obtained .class files and try
> > to compile them again using the option specific for J2ME (or
> > the Wireless Toolkit as I did with the previous version).
> > I did not tried that yet because I thing it is an "ugly"
> > solution and specific J2SE classes may be included again. So,
> > I would need to analyze the decompiled code, and change it,
> > if necessary.
> > I would be very glad if anybody else can give another idea.
>
> AspectJ-1.1 should generate class files that are compatible with J2ME so
long as you don't use either cflow or thisJoinPoint in your aspects (see 1
for more details) and your pure Java code is J2ME compatible already.
>
> If I understand it correctly, your problem is that you want to use the
J2ME reduced runtime library at compile-time so that you will get
compile-time errors when you try to use classes that aren't available.  The
easiest solution for you would be if SUN or someone else produced a tool
that would check a compiled system for J2ME compliance.  Then you could
build your tool using midpapi as a library and run the checker on the
generated .class files.
>
> A better solution is to fix ajc so that it can build a system when only
provided with the J2ME runtime.  If an AspectJ+J2ME developer is interested
in fixing this, I'd be happy to help you along.  The first thing I'd try
would be setting the
org.aspectj.ajdt.internal.compiler.problem.AjProblemReporter.DUMP_STACK flag
to true in the hopes of finding out where in the ajc code the missing class
errors are coming from.  Let me know if you want to pursue this further and
I can give you more pointers (on aspectj-dev@xxxxxxxxxxx).
>
> -Jim
>
>
> (1) The limitations on not using cflow or thisJoinPoint are fixable by
improving the org.aspectj.runtime library.  The cflow limitation should be
fairly easy to fix by including a small custom version of the Stack class.
The thisJoinPoint limitation might be harder due to the major limitations on
reflection in J2ME, but it should be possible to build a version that can at
least support some minimal toString() and getSourceLocation() methods.
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users
>