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 <ebo...@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 > > >
