[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: Polymorphism and BCEL Arrin Daley Tue Oct 21 18:00:42 2008

Hi Zagi

I don't think it's going to be easy.

If using your example you have loaded class A and you want to find out as you load and/or transform class A what the possible matches for m1() look like then you would have to try to load all potential subclasses, how would you know that there aren't more subclasses out there? without knowing something about the possible sources (which class loaders) of these classes I don't think you can.

What are you trying to do? perhaps there is another way you can transform the surrounding code or perhaps record what needs to be done so that when an subclass is loaded the appropriate action can be taken?

To answer your question I don't think there's any support in BCEL as generally there's no support for going down the type tree (only going up ie you can ask the superclasses of a JavaClass object), this would be asking for information that BCEL can't know yet because the dynamic classloading will not have loaded all possible subclasses (the best it could provide would be the currently loaded subclasses which it doesn't to my knowledge)

You could only build and traverse your own tree if you could be sure with the particular application you're transforming that you have loaded all possible subtypes.

I think I have some code for finding the possible types within a method, but some of these could be abstract and therefore not contain the actual method code anyway. ie in your example the code would find that in this method "inst" could either be of type A or of type B but if say type B were abstract (in your example it can't be) then this wouldn't help find the actual m1() method. I did this using some of the verifier code and simulating the method execution, it's an expensive thing to do so you would probably want to limit it's use.

Hope this helps

Bye Arrin


Getting the code of a method that is called through the invokevirtual 
instruction means lots of work. Due to polymorphism the dynamic type of the 
caller reference may be any type in the transitive closure of the static type.
Therefore you have to build up the a tree with all possible descendants of the 
static type and look into all the methods that match the signature. I'm curious 
 if there is any support for this in BCEL or if just everybody builds his own 
tree and traverse it.


here an example:

class A

class B extends A

 A inst = new A();
 inst.m1(); // m1 of A
 inst = new B();
 inst.m1(); // m1 of B

in both cases the bytecode looks like:
invokevirtual A/m1()V

now you want to get hand on the instructionlist of any matching method i.e. m1 
of A and m1 of B

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]