Say, want to see API information obtained from a Java binary?
%
javap java.lang.Object Compiled from
"Object.java"
public class
java.lang.Object{
public
java.lang.Object();
public final native
java.lang.Class getClass();
public native int
hashCode();
public boolean
equals(java.lang.Object);
protected native
java.lang.Object clone() throws
java.lang.CloneNotSupportedException;
public
java.lang.String toString();
public final native
void notify();
public final native void
notifyAll();
public final native void wait(long)
throws java.lang.InterruptedException;
public
final void wait(long, int) throws
java.lang.InterruptedException;
public final void
wait() throws
java.lang.InterruptedException;
protected void
finalize() throws java.lang.Throwable;
static
{};
}
"javap" can print interface information from any class in
the current classpath. (The usual flags for amending it on the commandline are
present).
Just in that one class, you can see:
- Native language
methods: getClass(), clone(), notify(), notifyAll(), wait(long).
- References
to other classes: java.lang.Class, java.lang.CloneNotSupportedException,
java.lang.String, java.lang.InterruptedException, and
java.lang.Throwable.
- Methods that cannot be replaced in a subclass:
getClass(), notify(), and the others marked "final".
This is just the
technical information needed to make sure a program is syntactically valid:
basically, to make sure the "plugs" in your code fit the "sockets" in
java.lang.Object. How many sockets there are, and what their names are.
The
semantic meaning cannot be obtained by machine. You'd have to decompile the
code and understand it.
And there's a flag for that: -c... you get back Java
VM assembly instructions, so really it's disassemble, not decompile.
If you
look at something more complicated, you'll be able to see the instance and class
variables as well. Errr, static variables? (The overloading of the C linkage
and storage scope specifier "static" gets confusing fast.)
[ Reply to This | Parent | # ]
|