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.maison...@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 <ebo...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
