geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: [BCEL] and Javassist
Date Fri, 22 Aug 2003 22:30:58 GMT
Except Java Assist is LGPL and controlled by Marc Fleury, who 
definitely does not want to see this project succeed.

To be honest, I just want a simple solution to the problem, but it 
needs to be fast otherwise we can just use reflection.  If there is 
some (free) tool out there that we can use that does this in 4 line of 
code that would be cool, but I really, really, really don't want to get 
into a huge AOP discussion right now.  We have a fairly small set of 
places we need to generate byte code, and we especially don't need to 
be side tracked into an exploration into AOP frameworks.


On Friday, August 22, 2003, at 04:35 PM, Howard M. Lewis Ship wrote:

> Or you could use Javassist for dynamic interface creation.
> HiveMind uses Javassist extensively with great success.
> Javassist is part of JBoss, but is under a joint MPL/LGPL license.
> Javassist's can do all manner of build-time and compile-time class 
> enhancement; much of the
> framework is geared towards AOP, but it is also useful for more 
> mundane tasks.
> Big claim to fame is that you specify method bodies in a Java-like 
> syntax, for example:
> {
>   if (_inner == null)
>     _inner = lookupInner();
>   return _inner.someMethod($$);
> }
> Might be a method body for an method, "someMethod()".  The $$ syntax 
> is a way of specifying the
> parameter list for someMethod(), perfect for this kind of 
> re-invocation.  Javassist parses this to
> an AST tree and builds the bytecode from it.  It has a number of 
> extensions and special variables
> that are suitable for modifying existing classes in a number of 
> AOP-like ways.
> Javassist understands the majority of Java language syntax, so you 
> don't need to know bytecode to do
> bytecode things.  That's a big plus for me.
> In addition, Tapestry uses Javassist following the EJB 2.0 CMP 
> pattern; that is, you often put
> abstract accessor methods in your classes and Tapestry builds the 
> concrete subclass for you (from an
> XML page or component specification). Javassist makes this very easy.
> --
> Howard M. Lewis Ship
> Creator, Tapestry: Java Web Components
>> -----Original Message-----
>> From: Dain Sundstrom []
>> Sent: Friday, August 22, 2003 11:12 AM
>> To:
>> Subject: [bcel] Is anyone a BCEL expert?
>> We are going to need some BCEL code which varies from simple to quite
>> complex.  If you are an expert or eager to learn, here is
>> what we need
>> (from simple to complex):
>> Interface proxy generator -- This is a copy of
>> java.reflection.Proxy.
>> Why do we need a copy?  Well I think it is a good starting point for
>> the rest of the stuff, and I know we can do it better.  I would like
>> the proxy generator to be able to generate class names that have some
>> meaning other then Proxy$24, and I think we can write code that this
>> faster.
>> Dynamic instance factory -- One slow thing we will run into with the
>> proxy generator above is normally the core of the generator
>> looks like
>> this:
>> 	Object getProxy(Class[] interfaces) {
>> 		Class clazz = getProxyClass(interfaces);
>> 		Constructor constructor = clazz.getConstructor(null);
>> 		constructor.newInstance(null);
>> 	}
>> Jeremy and I did some benchmarks the other day and the call to
>> newInstance on constructor is surprisingly expensive (the rest can be
>> optimized out).  The fastest way we found to create a class was to
>> generate the byte code for an instance factory.  The factory would be
>> the equivalent of this Java code:
>> 	public class MyProxyInstanceFactory implements InstanceFactory {
>> 		public Object newInstance() {
>> 			return new MyProxy();
>> 		}
>> 	}
>> So the line newInstance line becomes:
>> 	InstanceFactory factory = getInstanceFactory(clazz);
>> 	return factory.newInstance();
>> Notice this is not using a reflection call, it would raw byte code to
>> create a new instance the normal java way and has the exact same cost
>> as calling an interface method (duh, it is a call on an interface
>> method).  This is another flexibility versus speed trade off.
>>  To keep
>> the factory simple, it can only create classes with no arguments.  I
>> used beclifier to do this, but I really don't understand BECL, so I
>> would not want to commit it.
>> Abstract class proxy generator -- We need this for the CMP 2.x
>> implementation.  In CMP 2.x the bean provider writes an
>> abstract class
>> and we generate a concrete sub class.  I think the best way to
>> implement this, is to extend the interface proxy generator above, to
>> allow one of the specified interfaces to be a class.  When it
>> detects a
>> real class, the proxy generator would generate a subclass of
>> the class
>> and implement any abstract methods by delegating them to an
>> InvocationHandler.
>> Field interception -- This will make CMP 1.x much easier to
>> implement.
>> In CMP 1.x, the bean provider writes a concrete class where the
>> persistent fields are simple public fields of the class.  If we can
>> replace all byte code that access these fields with a call to the
>> InvocationHandler, it will make CMP 1.x look like CMP 2.x.  This
>> technique is also used by JDO so it will make our JDO implementation
>> (when we get to that) easier.
>> This should be a very fun project.  I'd do it myself, but
>> I've got too
>> many other things on my plate right now.
>> -dain
>> /*************************
>>   * Dain Sundstrom
>>   * Partner
>>   * Core Developers Network
>>   *************************/

  * Dain Sundstrom
  * Partner
  * Core Developers Network

View raw message