commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: [privilizer] promotion plan
Date Thu, 29 Nov 2012 18:12:11 GMT
Hi Emmanuel, and thanks for your elaboration.  It seems Lombok primarily
(exclusively?) takes the approach of altering the AST of a given Java file,
and it appears they may now support both Oracle and Eclipse compilers.  I
still don't know that I quite consider their approach to be a
Commons-friendly one, but I take your point that this might be just one of
potentially unlimited code modifications a new component could support.
This would go back to the idea of something like a BCEL library
(notwithstanding the fact that the existing privilizer code does not use
BCEL).

Matt


On Thu, Nov 29, 2012 at 10:13 AM, Emmanuel Bourg <ebourg@apache.org> wrote:

> Le 29/11/2012 16:41, Matt Benson a écrit :
> > Interesting; I apparently hadn't looked at Lombok apparently since
> they've
> > added the @DoPrivileged annotation (pretty sure it wasn't always there).
>
> You probably looked in the core of Lombok, @DoPrivileged is in the
> companion project lombok-pg.
>
>
> > My problem with Lombok is that, as I understand it, they have to resort
> to
> > "tricks" due to the limitations of the public annotation processing APIs,
> > they are only compatible with the Oracle compiler, have problems when
> used
> > with other technologies e.g. AspectJ (IIRC).  If not for these
> shortcomings
> > (and I have no doubt the Lombok team would have done things "correctly"
> > were that option open to them) I would have been using Lombok long ago.
>
> I guess the technique adopted by Lombok is the only one suitable for
> generating new methods like getters and setters, otherwise the
> compilation would fail when calling a not yet generated method. Bytecode
> processing would not allow that.
>
> For altering the body of existing methods like @DoPrivileged or
> @SwingInvokeLater bytecode processing is perfectly fine.
>
>
> Emmanuel Bourg
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message