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
Re: [privilizer] promotion plan
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 smime.p7s Description: Signature cryptographique S/MIME
Re: [privilizer] promotion plan
This components reminds me of Project Lombok [1]. As I understand the approach is different, Lombok uses JavaC annotations to generate the additional code at compile time, while Privilizer post process the class files with Javassist and works at the bytecode level. Lombok has a @DoPrivileged annotation, as well as many other ones [2][3]. The one I find very useful is the @SwingInvokeLater annotation [4] to ensure the code runs on the UI thread. That's a killer feature when developing Swing applications. Maybe the scope of [privilizer] could be widened to other annotations post processing? I don't know if it's worth competing with Lombok though. Emmanuel Bourg [1] http://projectlombok.org [2] http://projectlombok.org/features [3] https://github.com/peichhorn/lombok-pg/wiki [4] http://peichhorn.github.com/lombok-pg/SwingInvoke.html Le 28/11/2012 21:44, Matt Benson a écrit : Hi all, As long as I've been part of the Commons community I don't know that I've encountered this exact situation: a committer adds some code to the sandbox that is more or less complete. I don't know precisely what requirements must be met before we promote [privilizer] to proper. We seem to have interest from one or more members of the PMC as prospective users; this would seem to imply that were I hit by a bus there ought to be someone interested in maintaining the component. Speaking for BVal I intend to put this component to immediate use there (that's what I wrote it for!). Mark has mentioned that OWB and perhaps other ASF projects might want to make use of it. What else do I need to do? Matt smime.p7s Description: Signature cryptographique S/MIME
Re: [privilizer] promotion plan
Lombok features feels like they could belong in [lang]. Gary On Thu, Nov 29, 2012 at 9:10 AM, Emmanuel Bourg ebo...@apache.org wrote: This components reminds me of Project Lombok [1]. As I understand the approach is different, Lombok uses JavaC annotations to generate the additional code at compile time, while Privilizer post process the class files with Javassist and works at the bytecode level. Lombok has a @DoPrivileged annotation, as well as many other ones [2][3]. The one I find very useful is the @SwingInvokeLater annotation [4] to ensure the code runs on the UI thread. That's a killer feature when developing Swing applications. Maybe the scope of [privilizer] could be widened to other annotations post processing? I don't know if it's worth competing with Lombok though. Emmanuel Bourg [1] http://projectlombok.org [2] http://projectlombok.org/features [3] https://github.com/peichhorn/lombok-pg/wiki [4] http://peichhorn.github.com/lombok-pg/SwingInvoke.html Le 28/11/2012 21:44, Matt Benson a écrit : Hi all, As long as I've been part of the Commons community I don't know that I've encountered this exact situation: a committer adds some code to the sandbox that is more or less complete. I don't know precisely what requirements must be met before we promote [privilizer] to proper. We seem to have interest from one or more members of the PMC as prospective users; this would seem to imply that were I hit by a bus there ought to be someone interested in maintaining the component. Speaking for BVal I intend to put this component to immediate use there (that's what I wrote it for!). Mark has mentioned that OWB and perhaps other ASF projects might want to make use of it. What else do I need to do? Matt -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [privilizer] promotion plan
Interesting; I apparently hadn't looked at Lombok apparently since they've added the @DoPrivileged annotation (pretty sure it wasn't always there). 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. Matt On Thu, Nov 29, 2012 at 9:15 AM, Gary Gregory garydgreg...@gmail.comwrote: Lombok features feels like they could belong in [lang]. Gary On Thu, Nov 29, 2012 at 9:10 AM, Emmanuel Bourg ebo...@apache.org wrote: This components reminds me of Project Lombok [1]. As I understand the approach is different, Lombok uses JavaC annotations to generate the additional code at compile time, while Privilizer post process the class files with Javassist and works at the bytecode level. Lombok has a @DoPrivileged annotation, as well as many other ones [2][3]. The one I find very useful is the @SwingInvokeLater annotation [4] to ensure the code runs on the UI thread. That's a killer feature when developing Swing applications. Maybe the scope of [privilizer] could be widened to other annotations post processing? I don't know if it's worth competing with Lombok though. Emmanuel Bourg [1] http://projectlombok.org [2] http://projectlombok.org/features [3] https://github.com/peichhorn/lombok-pg/wiki [4] http://peichhorn.github.com/lombok-pg/SwingInvoke.html Le 28/11/2012 21:44, Matt Benson a écrit : Hi all, As long as I've been part of the Commons community I don't know that I've encountered this exact situation: a committer adds some code to the sandbox that is more or less complete. I don't know precisely what requirements must be met before we promote [privilizer] to proper. We seem to have interest from one or more members of the PMC as prospective users; this would seem to imply that were I hit by a bus there ought to be someone interested in maintaining the component. Speaking for BVal I intend to put this component to immediate use there (that's what I wrote it for!). Mark has mentioned that OWB and perhaps other ASF projects might want to make use of it. What else do I need to do? Matt -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [privilizer] promotion plan
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 smime.p7s Description: Signature cryptographique S/MIME
Re: [privilizer] promotion plan
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
[privilizer] promotion plan
Hi all, As long as I've been part of the Commons community I don't know that I've encountered this exact situation: a committer adds some code to the sandbox that is more or less complete. I don't know precisely what requirements must be met before we promote [privilizer] to proper. We seem to have interest from one or more members of the PMC as prospective users; this would seem to imply that were I hit by a bus there ought to be someone interested in maintaining the component. Speaking for BVal I intend to put this component to immediate use there (that's what I wrote it for!). Mark has mentioned that OWB and perhaps other ASF projects might want to make use of it. What else do I need to do? Matt
Re: [privilizer] promotion plan
Another aspect to consider is would this new privalizer component (not crazy about the name ATM) fit in an existing Commons component? On Wed, Nov 28, 2012 at 3:44 PM, Matt Benson gudnabr...@gmail.com wrote: Hi all, As long as I've been part of the Commons community I don't know that I've encountered this exact situation: a committer adds some code to the sandbox that is more or less complete. I don't know precisely what requirements must be met before we promote [privilizer] to proper. We seem to have interest from one or more members of the PMC as prospective users; this would seem to imply that were I hit by a bus there ought to be someone interested in maintaining the component. Speaking for BVal I intend to put this component to immediate use there (that's what I wrote it for!). Mark has mentioned that OWB and perhaps other ASF projects might want to make use of it. What else do I need to do? Matt -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [privilizer] promotion plan
Hi Gary, Feel free to suggest one or more alternate names, and we can vote on them! The intent is to quickly convey that the component equips your code to run in a Java security constrained environment, thus privilizer or that which makes your code privileged. Since the main use of the component is to instrument compiled code during the build process (a possible future enhancement is to support RT enhancement in a custom classloader), I don't see that it fits into any existing component, but am open to correction. Thanks for your interest, Matt On Wed, Nov 28, 2012 at 2:55 PM, Gary Gregory garydgreg...@gmail.comwrote: Another aspect to consider is would this new privalizer component (not crazy about the name ATM) fit in an existing Commons component? On Wed, Nov 28, 2012 at 3:44 PM, Matt Benson gudnabr...@gmail.com wrote: Hi all, As long as I've been part of the Commons community I don't know that I've encountered this exact situation: a committer adds some code to the sandbox that is more or less complete. I don't know precisely what requirements must be met before we promote [privilizer] to proper. We seem to have interest from one or more members of the PMC as prospective users; this would seem to imply that were I hit by a bus there ought to be someone interested in maintaining the component. Speaking for BVal I intend to put this component to immediate use there (that's what I wrote it for!). Mark has mentioned that OWB and perhaps other ASF projects might want to make use of it. What else do I need to do? Matt -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [privilizer] promotion plan
Pretty sure you didn't intend to drop the list; adding back. ;) Using BCEL to do the dirty work could be an option, though I confess I wouldn't mind seeing that done for a v1.1. The codebase-formerly-known-as-privileged-method-weaver feels as much to me like part of the current BCEL as a plumber does a box of pipe wrenches; i.e. this feels to me like confusing the container for the thing contained. I'm not *vehemently* opposed to a restructured BCEL with a core and various tool modules, but such would be the only direction I could see that would include this codebase as part of BCEL. Matt On Wed, Nov 28, 2012 at 3:24 PM, Gary Gregory garydgreg...@gmail.comwrote: Hi Matt, Byte code twiddling could be seen to fit nicely in BCEL, which is already a Commons project and could use some fresh blood. [privilege] (easier to type for me) would be a specific application for BCEL so it would be be as nicely layered on top on BCEL as much as on the side. And you'd loose the ASM aspect. Thinking about the eating of the dog food, I would love to see BCEL revitalized, which would also help Xalan, another BCEL user. If we do not want to go that route, then we can discuss improving on the name. Gary On Wed, Nov 28, 2012 at 4:08 PM, Matt Benson gudnabr...@gmail.com wrote: Hi Gary, Feel free to suggest one or more alternate names, and we can vote on them! The intent is to quickly convey that the component equips your code to run in a Java security constrained environment, thus privilizer or that which makes your code privileged. Since the main use of the component is to instrument compiled code during the build process (a possible future enhancement is to support RT enhancement in a custom classloader), I don't see that it fits into any existing component, but am open to correction. Thanks for your interest, Matt On Wed, Nov 28, 2012 at 2:55 PM, Gary Gregory garydgreg...@gmail.comwrote: Another aspect to consider is would this new privalizer component (not crazy about the name ATM) fit in an existing Commons component? On Wed, Nov 28, 2012 at 3:44 PM, Matt Benson gudnabr...@gmail.comwrote: Hi all, As long as I've been part of the Commons community I don't know that I've encountered this exact situation: a committer adds some code to the sandbox that is more or less complete. I don't know precisely what requirements must be met before we promote [privilizer] to proper. We seem to have interest from one or more members of the PMC as prospective users; this would seem to imply that were I hit by a bus there ought to be someone interested in maintaining the component. Speaking for BVal I intend to put this component to immediate use there (that's what I wrote it for!). Mark has mentioned that OWB and perhaps other ASF projects might want to make use of it. What else do I need to do? Matt -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [privilizer] promotion plan
+1 It might fit to any component which does _not_ introduce a runtime dependency but is only needed at compile time. Basically the privilizer is kind of a preprocessor. If such a kind of component already exists in commons, then we can look if it fits to the business of this component. Otherwise it's a new module imo. LieGrue, strub - Original Message - From: Matt Benson gudnabr...@gmail.com To: Gary Gregory garydgreg...@gmail.com Cc: Commons Developers List dev@commons.apache.org Sent: Wednesday, November 28, 2012 10:08 PM Subject: Re: [privilizer] promotion plan Hi Gary, Feel free to suggest one or more alternate names, and we can vote on them! The intent is to quickly convey that the component equips your code to run in a Java security constrained environment, thus privilizer or that which makes your code privileged. Since the main use of the component is to instrument compiled code during the build process (a possible future enhancement is to support RT enhancement in a custom classloader), I don't see that it fits into any existing component, but am open to correction. Thanks for your interest, Matt On Wed, Nov 28, 2012 at 2:55 PM, Gary Gregory garydgreg...@gmail.comwrote: Another aspect to consider is would this new privalizer component (not crazy about the name ATM) fit in an existing Commons component? On Wed, Nov 28, 2012 at 3:44 PM, Matt Benson gudnabr...@gmail.com wrote: Hi all, As long as I've been part of the Commons community I don't know that I've encountered this exact situation: a committer adds some code to the sandbox that is more or less complete. I don't know precisely what requirements must be met before we promote [privilizer] to proper. We seem to have interest from one or more members of the PMC as prospective users; this would seem to imply that were I hit by a bus there ought to be someone interested in maintaining the component. Speaking for BVal I intend to put this component to immediate use there (that's what I wrote it for!). Mark has mentioned that OWB and perhaps other ASF projects might want to make use of it. What else do I need to do? Matt -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [privilizer] promotion plan
FWIW, Simone and I had, in the past, discussed privately whether some tree of post-compilation tools might make a sensible family of commons component modules. We had originally been thinking along the lines of JDK6 annotation processors, which [*privilizer] is not (no open API exists allowing these to modify bytecode), but the basic principle applies... Note that [attributes] was/is more or less this type of component. Matt On Wed, Nov 28, 2012 at 4:00 PM, Mark Struberg strub...@yahoo.de wrote: +1 It might fit to any component which does _not_ introduce a runtime dependency but is only needed at compile time. Basically the privilizer is kind of a preprocessor. If such a kind of component already exists in commons, then we can look if it fits to the business of this component. Otherwise it's a new module imo. LieGrue, strub - Original Message - From: Matt Benson gudnabr...@gmail.com To: Gary Gregory garydgreg...@gmail.com Cc: Commons Developers List dev@commons.apache.org Sent: Wednesday, November 28, 2012 10:08 PM Subject: Re: [privilizer] promotion plan Hi Gary, Feel free to suggest one or more alternate names, and we can vote on them! The intent is to quickly convey that the component equips your code to run in a Java security constrained environment, thus privilizer or that which makes your code privileged. Since the main use of the component is to instrument compiled code during the build process (a possible future enhancement is to support RT enhancement in a custom classloader), I don't see that it fits into any existing component, but am open to correction. Thanks for your interest, Matt On Wed, Nov 28, 2012 at 2:55 PM, Gary Gregory garydgreg...@gmail.comwrote: Another aspect to consider is would this new privalizer component (not crazy about the name ATM) fit in an existing Commons component? On Wed, Nov 28, 2012 at 3:44 PM, Matt Benson gudnabr...@gmail.com wrote: Hi all, As long as I've been part of the Commons community I don't know that I've encountered this exact situation: a committer adds some code to the sandbox that is more or less complete. I don't know precisely what requirements must be met before we promote [privilizer] to proper. We seem to have interest from one or more members of the PMC as prospective users; this would seem to imply that were I hit by a bus there ought to be someone interested in maintaining the component. Speaking for BVal I intend to put this component to immediate use there (that's what I wrote it for!). Mark has mentioned that OWB and perhaps other ASF projects might want to make use of it. What else do I need to do? Matt -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [privilizer] promotion plan
On 11/28/12 12:44 PM, Matt Benson wrote: Hi all, As long as I've been part of the Commons community I don't know that I've encountered this exact situation: a committer adds some code to the sandbox that is more or less complete. I don't know precisely what requirements must be met before we promote [privilizer] to proper. We seem to have interest from one or more members of the PMC as prospective users; this would seem to imply that were I hit by a bus there ought to be someone interested in maintaining the component. Speaking for BVal I intend to put this component to immediate use there (that's what I wrote it for!). Mark has mentioned that OWB and perhaps other ASF projects might want to make use of it. What else do I need to do? Matt Traditionally, we have just required a) community and b) close to release-ability. In the olden days, we used to like to see 3 committers interested in working on the thing. Looks to me like [privilizer] is in good shape on both accounts, albeit with the 3 committers spread about the ASF. That is not a problem for Commons, IMO. I would be +1 to promote. All you need to do is kick off a promotion vote. Phil P.S. I vaguely recall [primitives] having a similar birth some years ago. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
