Project Lombok and AspectJ

[Hendy Irawan]

I wonder if Lombok should be implemented using AspectJ aspects.

As it stands now, most source-level operations and IDE functionality
is disrupted by Lombok. AspectJ has IDE support in Eclipse, and some
Lombok functionality is implementable using AspectJ.

Out of an IDE, AspectJ has a stable compile-time weaver that acts like
what Lombok does now.

[Petr Jiricka]

I can not speak for Reinier and Roel, but...

I must say I am not quite knowledgeable about AspectJ, so I don't know
how such an implementation would work. When you say "implemented using
AspectJ aspects" - do you mean that these aspects would be an
intermediate build product? And how would they be produced? There
would still need to be something that creates these aspects, and this
'something' would require tools support, and Eclipse could be
disrupted by it...

Or would the aspects be somehow visible to the user and present in the
source? What I like about Lombok is that (unlike AspectJ) it builds on
top of the existing Java language features and development processes,
without introducing new concepts to the programmer. So no new
language, no new build setup - you just drop Lombok on your classpath
and continue writing standard Java code.

So, can you please clarify how specifically would aspects be used?

Also, when you say *some* Lombok functionality is implementable using
AspectJ, what about the rest of the functionality?

My feeling is that overall, AspectJ is an overkill for implementing
Lombok. AspectJ introduces a whole new language - something you don't
need and don't want in the Lombok world. The fact that Eclipse
supports AspectJ right now and does not support Lombok 100% correctly
- well that's a problem to be solved on the Eclipse side.

Petr

> --
> You received this message because you are subscribed to the Google
> Groups group for http://projectlombok.org/
>
> To post to this group, send email to project...@googlegroups.com
> To unsubscribe from this group, send email to
> project-lombo...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/project-lombok?hl=en

[Moandji Ezana]

I agree with Petr that AspectJ seems like overkill at a language-level, but it might work well at an application-level. For example, I get the impression that something like Spring Roo, which makes heavy use of AspectJ, is Lombok at the application level*, as it generates a bunch of boilerplate code that you never see, without introducing any special runtime dependencies. 

Moandji

* Of course, it's initial aim is to be Grails for Java.

[Petr Jiricka]

On Mar 15, 2010, at 8:35 PM, Moandji Ezana wrote:

I agree with Petr that AspectJ seems like overkill at a language-level, but it might work well at an application-level. For example, I get the impression that something like Spring Roo, which makes heavy use of AspectJ, is Lombok at the application level*, as it generates a bunch of boilerplate code that you never see, without introducing any special runtime dependencies. 

I agree that having a solution at an application level would be great, and this is exactly the motivation behind the Dynamic Finders library I wrote about a few weeks ago: http://groups.google.com/group/project-lombok/browse_thread/thread/a8c01b2226c081cb/56d0ded1abcd5434?lnk=raot#56d0ded1abcd5434

My post also makes a reference/comparison to Spring Roo, as I admit that the library is influenced by Roo. My library aims to address the data/persistence layer, as that's IMO the most useful part (more useful than e.g. generating the UI, because - how often do you really use a generated UI?)

One interesting part of the Roo-generated UI code is the controller. This (like the data layer) also uses AspectJ - but it seems that the same effect could be achieved with Lombok without AspectJ - one would just need to have Lombok annotations for Spring MVC.

Petr

Moandji

* Of course, it's initial aim is to be Grails for Java.