jakarta-bcel-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From philipbor...@discoverfinancial.com
Subject Re: Emulating java.lang.reflect.AccessibleObject
Date Tue, 21 May 2002 03:06:21 GMT

I have been thinking of the reflection replacement and how it might work.
It seems to me that one would only want to optimize certain classes in
their application.  It would be a nightmare if we turned an application
with 50 classes into a sprawling nightmare of 500 classes as we create a
separate class for each method.  I like the idea of having a tagging
interface that you would implement if you knew the class would be accessed
through reflect.  On class load, the classloader would notice the interface
and perform byte code manipulation before handing the class off to the

Creating a classloader for this purpose would be no problem, but what if we
had other byte code level tools?  The original reason that I started
looking at BCEL was make it easier to generate bound and constrained fields
(ala Java Beans).  If you named your field b_myfield then an
accessor/mutator would automatically be created along with the code that
would fire a property change when the mutator was called.  If you named
your field c_myfield then the above would happen plus the mutator would
fire a vetoeable change.

It is conceivable that I would want to do both in the same class and I
don't want to have to change the source of my classloader and recompile.
Maybe as part of this project we can create a more flexible classloader
with an invoker chain that can be controlled by a properties (maybe xml)
file.  The idea would be that we would list the interface to look for (like
OptimizeForReflect or BCELBean) and then put the fully qualified classname
for the handler that would be responsible for handling that particular
interface (like org.apache.bcel.handlers.OptimizeForReflectHandler).  The
handler interface would just have one method that we would pass an
org.apace.bcel.classfile.JavaClass into.

As an answer to your question about building a reflection replacement, I
would say I am in.  I think we should include some useful tools right in
the BCEL package.  BCEL is pretty intimidating and I think that offering
some tools (that include the source code of real world solutions using BCEL
as a by-product) would make BCEL more accessible.  The reflection
replacement is a perfect place to start.  I would say we should package it
in the same jar as the rest of BCEL and keep it under the same umbrella as
the BCEL project instead of creating a separate project.

I rambled enough, tell me what you think.


                    Jim Redman                                                        
                    <jim@ergotech        To:     BCEL Users List                      
                    .com>                <bcel-user@jakarta.apache.org>         
                    05/18/2002           Subject:     Re: Emulating                   
                    06:01 AM             java.lang.reflect.AccessibleObject           
                    respond to                                                        
                    "BCEL Users                                                       

Do we have critical mass to build an reflection replacement as an open
source project?  The time we could really use it is porting to CLDC -
the J2ME standard that does not support reflection.

I have something similar for floating points (the standard does not
support floating point although most of the implementations tend to).
It takes out the floating point opcode and replaces with fixed point.



Jim Redman
(505) 662 5156

To unsubscribe, e-mail:   <mailto:bcel-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:bcel-user-help@jakarta.apache.org>

To unsubscribe, e-mail:   <mailto:bcel-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:bcel-user-help@jakarta.apache.org>

View raw message