You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bcel-user@jakarta.apache.org by Weijiang Yu <wj...@cs.utexas.edu> on 2003/09/18 23:31:44 UTC
class hierarchy?
For an invokestruction calling a method m, I am able to get m's class
info as the follwing:
cn = m.getClassName(cpg);
jc = Repository.lookupClass(cn);
My question is, how can I obtain all classes in which the method m could
be overrided? In other words, how can I obtain all methods that can be
called at runtime? It requires some kind of class tree, and I don't know
if BCEL provides ways to do that.
Weijiang
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-user-help@jakarta.apache.org
Re: class hierarchy?
Posted by Fausto Spoto <fa...@univr.it>.
Hi. Sorry for the very late reply, late summer holidays...
> Another issue is when we search a tree, e.g. invokevirtual #C::f(), we
> load class file C (suppose it can be loaded), and find f() is not defined
> within the class file, do we just need to look for C's superclasses?
When you write C::f() people mean the method syntactically specified in
the bytecode, not the result of method resolution (5.4.3.3 of the Java
virtual machine official specification). Note that the resolved method
is only known at run-time, unless you assume that the class hierarchy
is immutable. Anyway, the resolved method must exist by definition.
The syntactical method might not exist.
The target object (what you have on the operand stack at call-time) must
be assignment-compatible with the class of the syntactical method.
Hence, if this method does not exist, you might end up calling a method
of a superclass of C. Namely, the resolved method. But you can also call
all redefinitions of f() in the subclasses of C.
> On the other hand,
> if there is a definition of f() in C's class file, we just need to look
> for C's subclasses since f() may be overridden. Correct me if I was wrong.
This is corrected, because in this case the resolved method coincides
with the syntactical method.
Note that resolution uses accessibility modifiers to find the resolved
method. This makes things still more complicated...
Fausto
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-user-help@jakarta.apache.org
Re: class hierarchy?
Posted by Weijiang Yu <wj...@cs.utexas.edu>.
Thanks for your comments.
So I need to contruct a class tree from the scretch -- the tree could be
built by using some data structure so that operations on it such as
insertion and search could be very fast. Actually some study indicates
that the average depth of class hierarchy of java applications is about 2,
so for a "invokevirtual #C::f()", the performance of looking for
superclasses and subclasses of C may not be bad, but the class tree itself
is very big.
Another issue is when we search a tree, e.g. invokevirtual #C::f(), we
load class file C (suppose it can be loaded), and find f() is not defined
within the class file, do we just need to look for C's superclasses? That
is, we don't need to check C's subclasses in this case, no matter what
runtime type of 'objectref' is for this instruction. On the other hand,
if there is a definition of f() in C's class file, we just need to look
for C's subclasses since f() may be overridden. Correct me if I was wrong.
thanks!!
Weijiang Yu
On Fri, 19 Sep 2003, Fausto Spoto wrote:
>
> First of all, note that an
>
> invokevirtual class.method
>
> can actually end up calling methods defined in *superclasses* of
> "class", because of the late binding mechanism:
>
> A a = new A();
> a.toString();
>
> calls Object.toString() if A extends Object and A does not redefine
> toString().
>
> The information you are looking for is not directly provided by bcel
> since it is not contained in the .class files. A class does not know
> which are its subclasses. You have to scan the .class files accessible
> through the classpath, and check if they define a method which can be
> called by the invokevirtual. As I showed before, this is not just a
> matter of checking for a subclass. Moreover, parsing all such classes
> through bcel would be slow and memory consuming. Think about using
> standard Java reflection instead. Remeber, finally, that the result
> would be different in different running environments, where different
> classes might be installed...
>
> By the way, your problem is called "class hierarchy analysis". Check
>
> Dean, Grove and Chambers, "Optimization of OO Programs using Static
> Class Hierarchy Analysis", ECOOP'95, volume 952 of Lecture Notes in
> Computer Science, Springer-Verlag, 1995.
>
> - Fausto Spoto
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: bcel-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-user-help@jakarta.apache.org
Re: class hierarchy?
Posted by Weijiang Yu <wj...@cs.utexas.edu>.
Thanks for your comments.
So I need to contruct a class tree from the scretch -- the tree could be
built by using some data structure so that operations on it such as
insertion and search could be very fast. Actually some study indicates
that the average depth of class hierarchy of java applications is about 2,
so for a "invokevirtual #C::f()", the performance of looking for
superclasses and subclasses of C may not be bad, but the class tree itself
is very big.
Another issue is when we search a tree, e.g. invokevirtual #C::f(), we
load class file C (suppose it can be loaded), and find f() is not defined
within the class file, do we just need to look for C's superclasses? That
is, we don't need to check C's subclasses in this case, no matter what
runtime type of 'objectref' is for this instruction. On the other hand,
if there is a definition of f() in C's class file, we just need to look
for C's subclasses since f() may be overridden. Correct me if I was wrong.
thanks!!
Weijiang Yu
On Fri, 19 Sep 2003, Fausto Spoto wrote:
>
> First of all, note that an
>
> invokevirtual class.method
>
> can actually end up calling methods defined in *superclasses* of
> "class", because of the late binding mechanism:
>
> A a = new A();
> a.toString();
>
> calls Object.toString() if A extends Object and A does not redefine
> toString().
>
> The information you are looking for is not directly provided by bcel
> since it is not contained in the .class files. A class does not know
> which are its subclasses. You have to scan the .class files accessible
> through the classpath, and check if they define a method which can be
> called by the invokevirtual. As I showed before, this is not just a
> matter of checking for a subclass. Moreover, parsing all such classes
> through bcel would be slow and memory consuming. Think about using
> standard Java reflection instead. Remeber, finally, that the result
> would be different in different running environments, where different
> classes might be installed...
>
> By the way, your problem is called "class hierarchy analysis". Check
>
> Dean, Grove and Chambers, "Optimization of OO Programs using Static
> Class Hierarchy Analysis", ECOOP'95, volume 952 of Lecture Notes in
> Computer Science, Springer-Verlag, 1995.
>
> - Fausto Spoto
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: bcel-user-help@jakarta.apache.org
>
>
Re: class hierarchy?
Posted by Fausto Spoto <fa...@univr.it>.
Weijiang Yu wrote:
> My question is, how can I obtain all classes in which the method m could
> be overrided? In other words, how can I obtain all methods that can be
> called at runtime? It requires some kind of class tree, and I don't know
> if BCEL provides ways to do that.
First of all, note that an
invokevirtual class.method
can actually end up calling methods defined in *superclasses* of
"class", because of the late binding mechanism:
A a = new A();
a.toString();
calls Object.toString() if A extends Object and A does not redefine
toString().
The information you are looking for is not directly provided by bcel
since it is not contained in the .class files. A class does not know
which are its subclasses. You have to scan the .class files accessible
through the classpath, and check if they define a method which can be
called by the invokevirtual. As I showed before, this is not just a
matter of checking for a subclass. Moreover, parsing all such classes
through bcel would be slow and memory consuming. Think about using
standard Java reflection instead. Remeber, finally, that the result
would be different in different running environments, where different
classes might be installed...
By the way, your problem is called "class hierarchy analysis". Check
Dean, Grove and Chambers, "Optimization of OO Programs using Static
Class Hierarchy Analysis", ECOOP'95, volume 952 of Lecture Notes in
Computer Science, Springer-Verlag, 1995.
- Fausto Spoto
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-user-help@jakarta.apache.org
Re: class hierarchy?
Posted by Fausto Spoto <fa...@univr.it>.
Weijiang Yu wrote:
> My question is, how can I obtain all classes in which the method m could
> be overrided? In other words, how can I obtain all methods that can be
> called at runtime? It requires some kind of class tree, and I don't know
> if BCEL provides ways to do that.
First of all, note that an
invokevirtual class.method
can actually end up calling methods defined in *superclasses* of
"class", because of the late binding mechanism:
A a = new A();
a.toString();
calls Object.toString() if A extends Object and A does not redefine
toString().
The information you are looking for is not directly provided by bcel
since it is not contained in the .class files. A class does not know
which are its subclasses. You have to scan the .class files accessible
through the classpath, and check if they define a method which can be
called by the invokevirtual. As I showed before, this is not just a
matter of checking for a subclass. Moreover, parsing all such classes
through bcel would be slow and memory consuming. Think about using
standard Java reflection instead. Remeber, finally, that the result
would be different in different running environments, where different
classes might be installed...
By the way, your problem is called "class hierarchy analysis". Check
Dean, Grove and Chambers, "Optimization of OO Programs using Static
Class Hierarchy Analysis", ECOOP'95, volume 952 of Lecture Notes in
Computer Science, Springer-Verlag, 1995.
- Fausto Spoto