Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [aspectj-users] AspectJ 1.1 and J2ME

Thanks for the clear instructions Ayla, we'll verify this and add it to the
FAQ.

Mik

--
http://kerstens.org/mik
 

> -----Original Message-----
> From: aspectj-users-admin@xxxxxxxxxxx [mailto:aspectj-users-
> admin@xxxxxxxxxxx] On Behalf Of Ayla Débora
> Sent: Thursday, July 03, 2003 5:44 AM
> To: aspectj-users@xxxxxxxxxxx
> 
> 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
> >
> 
> 
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users



Back to the top