Re: [weaver]/[bcel] WAS [privilizer] promotion plan
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 gudnabr...@gmail.com To: Commons Developers List dev@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 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [weaver]/[bcel] WAS [privilizer] promotion plan
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=revisionrevision=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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [weaver]/[bcel] WAS [privilizer] promotion plan
On 4 December 2012 23:05, Gary Gregory garydgreg...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [weaver]/[bcel] WAS [privilizer] promotion plan
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
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 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
[weaver]/[bcel] WAS [privilizer] promotion plan
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 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
Re: [weaver]/[bcel] WAS [privilizer] promotion plan
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 gudnabr...@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 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
Re: [weaver]/[bcel] WAS [privilizer] promotion plan
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 gudnabr...@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 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
Re: [weaver]/[bcel] WAS [privilizer] promotion plan
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 tcu...@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 gudnabr...@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 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
Re: [weaver]/[bcel] WAS [privilizer] promotion plan
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 garydgreg...@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 gudnabr...@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 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
Re: [weaver]/[bcel] WAS [privilizer] promotion plan
On Wed, Dec 5, 2012 at 12:06 AM, Gary Gregory garydgreg...@gmail.comwrote: 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
