I agree that a simple reflection-replacement example would be ideal as a nice-sized example that covers many bcel concepts without an overwhelming amount of code. I also believe that many people would find it useful off- the-shelf.
As for the explosion of classes, that worries me too. Our system can potentially generate hundreds, if not thousands, of classes this way. Therefore, I have put in a threshold value so that we use reflection for a given Method/Field until the threshold is crossed, and then we generate the byte code to speed up those hot spots. > > 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. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
