Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
Date: Fri, 22 Aug 2003 17:24:58 -0500
Subject: Re: [bcel] Is anyone a BCEL expert?
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
From: Dain Sundstrom <dain@coredevelopers.net>
To: geronimo-dev@incubator.apache.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <Pine.LNX.4.44.0308221712290.3061-100000@www.princetongames.org>
Message-Id: <7701E275-D4EF-11D7-8482-000393DB559A@coredevelopers.net>

On Friday, August 22, 2003, at 04:17 PM, Aaron Mulder wrote:

> 	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.

I really think we need to use BCEL as this code will need to be 
maintained for a long time.  Hopefully, you can help whomever takes up 
this one.

> 	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?

This is exactly what we do.  We generate a concrete subclass of the 
abstract implementation and redirect the abstract accessors to the 
persistence engine.  Of course, it still uses an invocation handler as 
the entry point, but there is certainly no reflection.  There is 
reflection for CMP 1.1, which we are required to support, and that is 
why I want to use BCEL.

-dain