Hi,
I recently thought too of a Reflection API and it surely would be
very useful addition.
We should start to gather proposals now, it should be however
implemented
after Release 5.0 becomes final.
Cheers
Markus
> 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
> verifier.
>
> 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.
>
> -Phil
>
>
>
>
>
> Jim Redman
>
> <jim@ergotech To: BCEL Users
> List
> .com>
> <[EMAIL PROTECTED]>
> cc:
>
> 05/18/2002 Subject: Re:
> Emulating
> 06:01 AM
> java.lang.reflect.AccessibleObject
> Please
>
> respond to
>
> "BCEL Users
>
> List"
>
>
>
>
>
>
>
>
>
> 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
>
> --
>
> Jim Redman
> (505) 662 5156
> http://www.ergotech.com
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
