Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] Fwd: AspectJ with Lombok?

Hi Andy,

Just to keep you updated, I managed to get a debug session working with a remote debugger.  Indeed, I had incorrectly jarjar'ed the aj lib, and once I re jarjar'ed it, I got lombok to recognize it.  Unfortunately though, it still is not lombok'ing.

That being said, I'm having a lot of difficulty in debugging the lombok code.  It uses a bunch of jdt libs to compile, but they aren't the actual ones being used during the debug process (I presume it is using different versions), so stepping through code is a nightmare as the source lines don't actually match up with the remote process being debugged.  I have to dig around a little more there and see if I can find out why.

In the meantime, I've posted some questions to the lombok list hoping others can point me in a helpful debug process, but so far am awaiting a response.

The only thing I noticed from a quick look is the entry point into the lombok lib from ajc and from javac seem to be from two different places.  Is that possible?  Lombok process gets bootstrapped  via APT (from what I can tell).  Is it possible that ajc launches the APT process from a different point than javac?

Thanks,

Eric


On Fri, Sep 19, 2014 at 10:00 PM, Eric Benzacar <eric@xxxxxxxxxxx> wrote:
Thanks - that'll give me something to play with over the weekend if I get some time.   It never occurred to me to try remote debugging on a local process.  Will give that a shot as well.

I'll keep you posted on my results. 

Thanks,

Eric

On Fri, Sep 19, 2014 at 4:19 PM, Andy Clement <andrew.clement@xxxxxxxxx> wrote:
The three jars are supersets of one another. If you jarjar aspectjtools and just use that, it has everything in (including weaver/runtime). In fact the compiler classes are only in aspectjtools.

For debugging, can you just use JVM remote debugging? Set that -Xdebug etc when launching (or in JVM_OPTS if using a script) and then attach the eclipse debugger to it?

> [WARNING] You aren't using a compiler supported by lombok, so lombok will not work and has been disabled.
> Your processor is: org.aspectj.org.eclipse.jdt.internal.compiler.apt.dispatch.BatchProcessingEnvImpl

That does sound like jarjar didn't behave. Did you 'jar -tvf' your jar and check everything had been changed back to org.eclipse.jdt?

In theory it would also be possible to build an AspectJ package that included those additional bundles lombok wants from eclipse, and jarjar those too so the prefixes are all in agreement (org.aspectj.org.eclipse.jdt).  Then once that package name was supported throughout lombok it ought to all work - that is probably what would need doing to get it behaving in the Eclipse IDE too. Create an extra bundle with the prefixed forms of the JDT UI packages for use just in this context.

cheers,
Andy

On 19 September 2014 11:10, Eric B <ebenzacar@xxxxxxxxx> wrote:
No only a couple of places that use it.  I think the biggest problem is in a single class which is related to the agent for Eclipse - I think.  I temporarily commented it out.

But even with the problem class removed, it isn't generating the correct sources.  And I am having a lot of difficulty figuring out how to debug this when I run it command line, so it's not a very effective debugging process adding in printlns as I go along but without being able to inspect any vars, or even know which implementations are being called for what.

I like your suggesting of trying to jarjar aspectj, but not sure which pkgs need to be modified: aspectjrt, aspectjtools, or aspectjweaver?  I actually tried to jarjar all 3, just to be safe, but when I run ajc with lombok, I get the following error:

[WARNING] You aren't using a compiler supported by lombok, so lombok will not work and has been disabled.
Your processor is: org.aspectj.org.eclipse.jdt.internal.compiler.apt.dispatch.BatchProcessingEnvImpl
Lombok supports: sun/apple javac 1.6, ECJ

Which to me looks like I missed something when I jarjar'ed the pkgs.

But my rule was pretty basic:
rule org.aspectj.org.eclipse.jdt.* org.eclipse.jdt.@1
java -jar ~/Documents/Dev/libs/jarjar/jarjar-1.4.jar process lombok.jarjar.txt ../1.8.2/aspectjtools-1.8.2.jar aspectjtools-1.8.2_lombok.jar

And then pointed to the newly created 1.8.2_lombok version in my maven pom.

So I'm a little lost/confused at this point.  Not sure what/where to try to tackle next.  Was hoping to get some more direction from Reinier Zwitserloot or Roel Spilker (the lead devs) but haven't heard anything back from them yet.

Am open to any suggestions.  I was really hoping to use Lombok instead of Roo (had an unpleasant Roo experience) and not using any spring-data stuff, so figured lombok would be easier.  But I don't know if I'll ever get there.

Thanks,

Eric

On Fri, Sep 19, 2014 at 12:19 PM, Andy Clement <andrew.clement@xxxxxxxxx> wrote:
For AspectJ we only repackage the minimum we have to do get the compiler going. That is JDT Core plus the annotations support (for annotation processing) and the dependencies of that. We don't touch JDT UI.  This does mean that AJDT does some mapping between the two - fixing exactly the problem you described of having a org.eclipse.jdt.XXX and needing a org.aspectj.org.eclipse.jdt.XXX.  I can see that those UI ones do relate to source manipulation/refactoring (which arguably is not actually a UI concern - but that's another story).

Is it a lot of places where you get that problem in lombok?

On the command line I could maybe imagine a 'hack' to test whether this thing will work at all by jarjar'ing aspectj and converting it back to just org.eclipse.jdt - but that solution wouldn't fly in Eclipse where we rely on the different package names to avoid tripping over real jdt.

cheers,
Andy

On 18 September 2014 18:57, Eric B <ebenzacar@xxxxxxxxx> wrote:
I've been working on it, but it isn't as obvious as I hoped/thought.  I quickly tried to JarJar the compiled package but it didn't work.  So I started manually renaming everything in the packages by hand in the lombok sources.  However, I ran into a problem that I am not sure how to resolve.  Some of Lombok relies on some non-aspectj rebranded packages, specifically: 
   org.eclipse.jdt.internal.corext
   org.eclipse.jdt.internal.ui


The biggest problem I have is that Lombok uses classes from these packages and tries to pass org.aspectj.xxx classes as arguments to their methods.  Since the classes are original org.eclipse.jdt packages, obviously the arguments do not match the expected type.  ie: passed an org.aspectj.org.eclipse.jdt argument but expecting a org.eclispe.jdt argument.


I tried searching the org.aspectj github site, but can't find either of those two packages having been re-branded.  More importantly, I don't know if/how Lombok hooks into Eclipse; where it relies on original source pkg naming.

Do either of the packages mean anything to you?

Thanks,

Eric


On Thu, Sep 18, 2014 at 2:16 PM, Andy Clement <andrew.clement@xxxxxxxxx> wrote:
The ECJ packages are renamed but there are also numerous extensions here and there to support the likes of ITDs which affect type/method resolution. If you clone the AspectJ repo: https://github.com/eclipse/org.aspectj you will see the compiler in the org.eclipse.jdt.core module - the binary and src are in there. That module is actually built from the repo org.aspectj.shadows - browsing that is more complicated so I'd say glance into the src/zip. I can't say whether lombok would be compatible apart from the package prefix but my gut feeling would be that it would just work.  I wonder if running a jarjar on the lombok code to replace occurrences org org.eclipse.jdt. with org.aspectj.org.eclipse.jdt. might get it into a working state.

cheers,
Andy

On 18 September 2014 09:41, Eric B <ebenzacar@xxxxxxxxx> wrote:
Hi Andy,

Your reply just came in as I was writing my addendum.  I ran across the following post on SO that could hopefully help (http://stackoverflow.com/questions/6107197/how-does-lombok-work).

Lombok codes against a) internal javac apis and b) internal eclipse apis (in a separate processor). JSR 269 does not let you modify existing source code, but when you cast an Element to the underlying AST node, you can actually modify the AST (which is what project Lombok does).

I'm not entirely sure how much ajc deviates from ejc.  Have you just renamed all the packages to be org.aspectj?  Where would I find the sources for EJC to see how much/where AJC deviates?

Thanks,

Eric



On Thu, Sep 18, 2014 at 11:25 AM, Andy Clement <andrew.clement@xxxxxxxxx> wrote:
I had a brief look at this when we added annotation processing support to AspectJ as that is what I thought Lombok was doing. But then I discovered that I think it wanted to be run as an agent when using the Eclipse Java Compiler (on which AspectJ is based). If I recall correctly lombok had hardcoded classnames for ECJ classes in it and in AspectJ we prefix those with "org.aspectj." - that is as far as I got looking though, I'm afraid.  It would be great if someone had a bit more time than me to dig into it.  Possibly you just need a lombok that recognizes this variant of ECJ.

I think within eclipse some people have been turning on both java and aspectj builders to get it to work a little better. the java builder allowing lombok to run then AspectJ running afterwards but that sounds pretty ugly so I've never tried it.

cheers,
Andy

On 17 September 2014 20:27, Eric B <ebenzacar@xxxxxxxxx> wrote:
I'm trying to use Lombok (http://projectlombok.org/) in an AspectJ project, but when I enable AspectJ, none of my generated lombok code is added to my byte code.

I'm not entirely sure how lombok interacts with Javac, but my guess is that the ajc compiler does not recognize lombok the way javac does.

Is there anyway to make these two play nicely?  Can I configure ajc to use/recognize lombok properly?  Or am I forced to pick only one of the two technologies?

Thanks,

Eric


_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users


_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users




_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users


_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users


_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users


_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users


_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users


_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users



Back to the top