commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: [weaver]/[bcel] WAS [privilizer] promotion plan
Date Wed, 05 Dec 2012 15:48:55 GMT
A [weaver] component as I envisioning it would provide e.g. a
BytecodeWeaver interface, a custom implementation of which could be
specified via:

- the Maven plugin
- the Antlib
- the Java API

Thus IMO it would be quite natural for [nabla] to make use of [weaver].

>From Torsten's/Mark's/Stephen's comments it sounds like using ASM might be
less painful after all, dog food be damned.  :/

@Emmanuel:  My approach with the Antlib was to create a shaded uberjar so
that the user wouldn't have to worry about dependencies.  This came out to
900K, but typically this would be added to Ant's classpath rather than
shipped per-project.  The API jar is 3K, and would be the only thing
required for compilation.  Scale that by N weaver implementations (some of
which possibly won't use a custom, or any, annotation) and the size of
compilation dependencies would seem easily manageable.  Agreed?

Matt


On Wed, Dec 5, 2012 at 4:16 AM, Luc Maisonobe <Luc.Maisonobe@free.fr> wrote:

> Hi all,
>
> Le 04/12/2012 23:54, Matt Benson a écrit :
> > Well, it looks like the most comfortable avenue for everyone is Commons
> > [weaver].  IMO [weaver] would look like a framework for implementing any
> > kind of code weaving, so the most important decision is the look of the
> > API, and it would seem that eating our own dog food would be appropriate
> in
> > Commons.  Thus I would propose that [weaver] be built on top of [BCEL],
> and
> > I would think it likely that we might provide a nice (fluent?) API for
> > common code modifications.
> >
> > Firstly, does anyone object to using [BCEL] as [weaver]'s foundation?;
> > secondly, can anyone tell me what (Java 7?) features [BCEL] currently
> > lacks?; thirdly, does any of us already have the expertise to add these?
>
> The [nabla] project also needs bytecode engineering. I don't know if it
> would fit within [weaver] API as it is really specific. It creates
> completely new classes using exisitng classes as templates, and the new
> classes generated methods contain deep modifications of the original
> methods (data flow analysis, types change, signatures changed, binding
> between generated and original methods and fields ...). Long ago, when
> [nabla] was only a personal project not yet contributed to commons, I
> used [BCEL] as the underlying bytecode engineering library. I finally
> switched to ASM as the [BCEL] API  was not sufficient for some of my
> needs, whereas ASM was a perfect fit.
>
> Once again, I'm not sure if [nabla] could benefit from [weaver], so this
> comment may not be relevant in the discussion.
>
> best regards,
> Luc
>
> >
> > Thanks,
> > Matt
> >
> >
> > On Fri, Nov 30, 2012 at 6:35 AM, Emmanuel Bourg <ebourg@apache.org>
> wrote:
> >
> >> Le 29/11/2012 19:12, Matt Benson a écrit :
> >>> 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).
> >>
> >> For such a component BCEL would be an implementation detail, so I don't
> >> think it should be a sub part of BCEL.
> >>
> >> If an annotation equivalent to @SwingInvokeLater can be added to the
> >> project I would be highly interested in using it.
> >>
> >> As for the name of the component, what about Commons Weaver ?
> >>
> >> Emmanuel Bourg
> >>
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

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