Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] Adding getter/setter using AspectJ

Hi John,

On 13 July 2011 23:43, John Patterson <jdpatterson@xxxxxxxxx> wrote:
> I would be very interested in such a feature.  Currently I use Lombok to
> generate getters and setters (toString, hashCode, constructors etc) at the
> source tree parsing level.  It works quite well and is more addictive than
> good smack.  Unfortunately its eclipse integration is not compatible with
> the AspectJ plugin - it just stops working if you add the aspect nature to a
> project.

I don't know how Lombok does its thing so can't say if this ought to
work.  It is possible what stops it is simply that we have 'jarjar'd
the eclipse jdt packages in our compiler to avoid clashing with
existing JDT.  Perhaps if we ran lombok though a similar jarjar run
(to change its references from jdt names to our package names), it
would produce a version more compatible with AspectJ.

> BTW, how does one go about "extending AspectJ" to create accessors?  I would
> love to start using AspectJ but giving up Lombok in return has so far
> stopped me getting any further than a quick experiment.

Well unfortunately the compiler isn't built to be user extensible -
some APT thing should be possible but I haven't tried it recently (I
remember working on getting APT to
behave for some early Spring Roo prototype, but in the end they didn't use it).

The steps I would take are:
- define the new annotations
- recognize them at compile time and generate the extra members with
appropriate implementations.

I don't think the weaver would need modification as these are things
that only affect the type which is annotated, so can all be completely
implemented at compile time.

Hmm, actually, I changed my mind there -  if you ITD'd a new field
with one of these new annotations on (e.g. the one to create get/set)
then the weaver would need updating to create them - in cases where
the aspect including the ITD is applied in a binary weave.

But all that is achievable, and isn't *too* bad a fit for AOP.

> Also, a related question; I would like to generate fast accessors that
> bypass the security manager (like CGLIB FastMethod).  So far I can only
> think of doing this at the source level by generating something like
> setField(String name, Object value).  Is there any way AspectJ could be
> "extended" to help here?  I want to avoid bytecode generating a new class at
> runtime to avoid serialization problems.

What would setField(String name, Object value) do? something like:

  if (name.equals("foo")) {
     this.foo=value;
  } else if (name.equals("bar")) {
    this.bar=value;
  }...

AspectJ can be extended to do things like that, but we'd need a
compelling use case and justification that it fits into an Aspect
Oriented Programming language.

If one purpose is just faster than reflective invocation, perhaps
MethodHandles in Java7 will go some way to making it more efficient
(I'm not sure how they play with the security manager, but I thought
they were less strict, being checked once rather than on each use).

cheers
Andy


Back to the top