[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [aspectj-users] coverage, decompile, recompile
|
My experience is that you're wasting your time. From what I gather,
decompilability was not really on anyone's priority list in 1.1 or 1.2.
I view decompiling aspectj as a way to understand a single source file,
but not suitable as a platform for recompilation/further source
transformation. I base these impressions solely on my experience with
decompiling a few aspectj files, so I can't regard my advice as
authoritative.
Cheers,
Nick
P.S. AspectJ 1.2 also generates bytecode that's incompatible with
JRockit (https://bugs.eclipse.org/bugs/show_bug.cgi?id=63347), if that
tells you anything about how close its output forms match those of
javac.
On May 28, 2004, at 8:40 AM, Jules Gosnell wrote:
Thanks for the suggestion, Ron.
I tried that. Things look a little better - I don't get the inner
class problem first anymore - but this one instead :
/home/jgosnell/cvs/wadi/src/java/org/codehaus/wadi/shared/
NameChecking.java:33 error Syntax error, insert "AssignmentOperator
ArrayInitializer" to complete Expression
ajc$perSingletonInstance;
^^^^^^^^^^^^^^^
/home/jgosnell/cvs/wadi/src/java/org/codehaus/wadi/shared/
NameChecking.java:34 error Syntax error on token "Invalid Character",
throw expected
if(ajc$perSingletonInstance == null) goto _L2; else goto _L1
The code at this point has decompiled to :
public static NameChecking aspectOf()
{
ajc$perSingletonInstance; // < line 33
if(ajc$perSingletonInstance == null) goto _L2; else goto _L1
_L1:
return;
_L2:
throw new
NoAspectBoundException("org_codehaus_wadi_shared_NameChecking",
ajc$initFailureCause);
}
public static boolean hasAspect()
{
return ajc$perSingletonInstance != null;
}
Line 33 looks very dodgy :-(. It looks like a variable declaration
with no type... JAD bug ?
I'm using :
aspectj1.2 for the original compile and recompile step.
jad v1.5.8e for the decompilation.
Should this sort of thing work, or am I wasting my time ?
Thanks for any help.
Jules
DiFrango, Ron wrote:
Jules,
This is a known problem with AspectJ. The following link should get
you to
the bug report:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=46298
One alternative approach you could take is to re-name your .aj files
to
.java and the aspectj compiler will work fine.
Ron
-----Original Message-----
From: Jules Gosnell [mailto:jules@xxxxxxxxxxxxxxxxxx] Sent: Friday,
May 28, 2004 10:32 AM
To: aspectj-users@xxxxxxxxxxx
Subject: [aspectj-users] coverage, decompile, recompile
Because AspectJ compiles directly from .aj to .class with no
intermediate .java stage, I am currently thwarted in my efforts to
run e.g. Clover over my codebase to do coverage testing.
Clover only understands Java (AFAIK).
I guess this must be the situation for a number of useful tools.
I recently had the idea of compiling .aj to .class, decompiling
.class to .java and then recompiling .java back to .class with
clover...
Needless to say this was wishful thinking (I used the latest JAD,
which wasn't happy with the version of my class files). The first
recompilation error, of many, turned out to be an inner class that
had got lost - further investiation revealed that jad had failed to
decompile it :
WEB-INF/classes/org/codehaus/wadi/jetty/
Manager$HouseKeeper.class...The class file version is 48.0 (only
45.3, 46.0 and 47.0 are supported)
Generating jad/org/codehaus/wadi/jetty/Manager$HouseKeeper.java
Couldn't resolve all access$ methods in method run
Has anyone else tried anything like this ?
Is it possible to decompile Aspectj programs back into Java, or do
they contain untranslatable bytecode ?
Is there a better decompiler around ?
Cheers,
Jules
--
/**********************************
* Jules Gosnell
* Partner
* Core Developers Network (Europe)
*
* www.coredevelopers.net
*
* Open Source Training & Support.
**********************************/
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-users