geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: [bcel] Is anyone a BCEL expert?
Date Fri, 22 Aug 2003 21:17:24 GMT
	I have a Proxy implementation for JDK 1.2 that I could contribute
(e.g. I have copyright), either as a starter implementation or for
reference.  It's the one used by OpenEJB for JDK 1.2 support.  But it
doesn't use BCEL.  I've used BCEL a bit, enough to do everything up until
field interception, but I'm probably going to be spending my time on
JSR-88 more than this in the short term.

	BTW, I'm not convinced the best way to handle CMP 2.0 is to allow
the Proxy to extend abstract classes as well as interfaces.  If we have
the byte code wizardry to do the byte code mangling for the last point,
why don't we just generate non-proxy concrete subclasses of the CMP 2.0
abstract classes and ditch the reflection altogether?


On Fri, 22 Aug 2003, Dain Sundstrom wrote:
> 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
>   *************************/

View raw message