geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship" <hls...@comcast.net>
Subject [BCEL] and Javassist
Date Fri, 22 Aug 2003 21:35:24 GMT
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
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com

> -----Original Message-----
> From: Dain Sundstrom [mailto:dain@coredevelopers.net] 
> Sent: Friday, August 22, 2003 11:12 AM
> To: geronimo-dev@incubator.apache.org
> 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
>   *************************/
> 


Mime
View raw message