[weaver]/[bcel] WAS [privilizer] promotion plan

[Matt Benson <gu...@gmail.com>]

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?

Thanks,
Matt


On Fri, Nov 30, 2012 at 6:35 AM, Emmanuel Bourg <eb...@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
>
>
>

Re: [weaver]/[bcel] WAS [privilizer] promotion plan

[Torsten Curdt <tc...@vafer.org>]

On Wed, Dec 5, 2012 at 12:06 AM, Gary Gregory <ga...@gmail.com>wrote:

> Sadly I do not see much BCEL activity in Commons...
>
> Does ASM fully support Java 7?
>

For a while now

http://weblogs.java.net/blog/forax/archive/2011/04/17/asm-4-rc1-released

An implementation-neutral API does not sound like a such great idea TBH.
Especially as this still does not help with BCEL development.

cheers,
Torsten

Re: [weaver]/[bcel] WAS [privilizer] promotion plan

[Gary Gregory <ga...@gmail.com>]

Sadly I do not see much BCEL activity in Commons...

Does ASM fully support Java 7?

Gary

On Dec 4, 2012, at 18:01, Torsten Curdt <tc...@vafer.org> wrote:

> I would suggest to go with ASM instead ...unless there are people that are
> eager to work on BCEL.
>
> cheers,
> Torsten
>
>
> On Tue, Dec 4, 2012 at 11:54 PM, Matt Benson <gu...@gmail.com> wrote:
>
>> 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?
>>
>> Thanks,
>> Matt
>>
>>
>> On Fri, Nov 30, 2012 at 6:35 AM, Emmanuel Bourg <eb...@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

Re: [weaver]/[bcel] WAS [privilizer] promotion plan

[Torsten Curdt <tc...@vafer.org>]

I would suggest to go with ASM instead ...unless there are people that are
eager to work on BCEL.

cheers,
Torsten


On Tue, Dec 4, 2012 at 11:54 PM, Matt Benson <gu...@gmail.com> wrote:

> 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?
>
> Thanks,
> Matt
>
>
> On Fri, Nov 30, 2012 at 6:35 AM, Emmanuel Bourg <eb...@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
> >
> >
> >
>

Re: [weaver]/[bcel] WAS [privilizer] promotion plan

[Stephen Colebourne <sc...@joda.org>]

On 4 December 2012 23:05, Gary Gregory <ga...@gmail.com> wrote:
> I like the name weaver.
>
> Does it make sense to allow different libs to be plugged in? BCEL,
> ASM... Or do do we have to pick one?

Based on what I see in various projects, ASM won, BCEL lost. Main
problem tends to be different versions of ASM being incompatible.

Stephen

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [weaver]/[bcel] WAS [privilizer] promotion plan

[Matt Benson <gu...@gmail.com>]

I'm not opposed to multiple backends, but this dictates that [weaver] must
have its own implementation-neutral API.  I don't know that I'm prepared to
create it.

Matt


On Tue, Dec 4, 2012 at 5:05 PM, Gary Gregory <ga...@gmail.com> wrote:

> I like the name weaver.
>
> Does it make sense to allow different libs to be plugged in? BCEL,
> ASM... Or do do we have to pick one?
>
> Gary
>
> On Dec 4, 2012, at 17:55, Matt Benson <gu...@gmail.com> wrote:
>
> > 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?
> >
> > Thanks,
> > Matt
> >
> >
> > On Fri, Nov 30, 2012 at 6:35 AM, Emmanuel Bourg <eb...@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
>
>

Re: [weaver]/[bcel] WAS [privilizer] promotion plan

[Gary Gregory <ga...@gmail.com>]

I like the name weaver.

Does it make sense to allow different libs to be plugged in? BCEL,
ASM... Or do do we have to pick one?

Gary

On Dec 4, 2012, at 17:55, Matt Benson <gu...@gmail.com> wrote:

> 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?
>
> Thanks,
> Matt
>
>
> On Fri, Nov 30, 2012 at 6:35 AM, Emmanuel Bourg <eb...@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

Re: [weaver]/[bcel] WAS [privilizer] promotion plan

[Emmanuel Bourg <eb...@apache.org>]

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.

Let's start with a modest goal, we certainly don't want to reimplement
AspectJ. The public API should only consists in the annotations. The
weaving engine is our little internal mess.


> 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?

If you are willing to spend some time on this why not, but I really
don't think it's important. I would just keep what's already done.

As a Ant user my only criteria would be to have small dependencies, such
that the size of the jar providing the weaving task isn't too big. I
generally don't like putting a 1 MB jar to my project.

Emmanuel Bourg

Re: [weaver]/[bcel] WAS [privilizer] promotion plan

[Mark Thomas <ma...@apache.org>]

On 04/12/2012 22:54, Matt Benson wrote:
> 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?;

No objection but I would query how much life there is in BCEL at the moment.

> secondly, can anyone tell me what (Java 7?) features [BCEL] currently
> lacks?;

See https://issues.apache.org/bugzilla/show_bug.cgi?id=51661
and
http://svn.apache.org/viewvc?view=revision&revision=1377530

Essentially, the new types need to be added to the visitor interface and
then all the classes that implement visitor need to be updated to handle
the new types.

> thirdly, does any of us already have the expertise to add these?

I have to read the Java Language Specification to figure out what was
new and needed to be added for Java 7 support. If a committer was so
inclined, there should be enough information available to figure out how
the visitor implementations need to be amended.

I suppose I could do this but I simply don't have the time given my
other commitments.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [weaver]/[bcel] WAS [privilizer] promotion plan

[Mark Struberg <st...@yahoo.de>]

One of the stuff I heard way back was that BCEL still has no native Java7 support. 
Is this still true? Imo that was one of the reasons why openjpa went for doing parts of the bytecode stuff with ASM...

Happy to get proved wrong ;)

LieGrue,
strub




----- Original Message -----
> From: Matt Benson <gu...@gmail.com>
> To: Commons Developers List <de...@commons.apache.org>
> Cc: 
> Sent: Wednesday, December 5, 2012 4:48 PM
> Subject: Re: [weaver]/[bcel] WAS [privilizer] promotion plan
> 
> 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 <Lu...@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 
> <eb...@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
>> 
>> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [weaver]/[bcel] WAS [privilizer] promotion plan

[Matt Benson <gu...@gmail.com>]

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 <Lu...@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 <eb...@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
>
>

Re: [weaver]/[bcel] WAS [privilizer] promotion plan

[Luc Maisonobe <Lu...@free.fr>]

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