instrumenting a constructor

[heisenberg]

The java compiler enforces a rule that simply stated requires that a
derived class's constructor must, upon entry, immediately call its
superclass's constructor.

I wish to insert bytecode into a set of java class constructors at load
time; Trust me when I say that it will be a far easier implementation
if my bytecode is placed at the start of the constructor (rather than
after the call to the superclass).

I have prototyped a solution using a couple of variants and they all
seem to work fine; I am, however, concerned about potential cases that
I may not be aware of.

Does anyone know of a condition in which the above implementation will
cause the application class to misbehave or fail; any comments are most
welcome.

Thanks

 

[Patricia Shanahan]

The java compiler enforces a rule that simply stated requires that a
derived class's constructor must, upon entry, immediately call its
superclass's constructor.

I wish to insert bytecode into a set of java class constructors at load
time; Trust me when I say that it will be a far easier implementation
if my bytecode is placed at the start of the constructor (rather than
after the call to the superclass).

I have prototyped a solution using a couple of variants and they all
seem to work fine; I am, however, concerned about potential cases that
I may not be aware of.

Does anyone know of a condition in which the above implementation will
cause the application class to misbehave or fail; any comments are most
welcome.

Thanks

The safest approach would be to observe the limitations for explicit
constructor invocation:

"An explicit constructor invocation statement in a constructor body may
not refer to any instance variables or instance methods declared in this
class or any superclass, or use this or super in any expression;
otherwise, a compile-time error occurs."

[http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#229267]

If your work could have happened as a side effect of calculating a
parameter for an explicit constructor invocation, under those rules, it
should be OK. The explicit constructor parameters have to be calculated
before the actual call.

Patricia

 

[Chris Uppal]

Does anyone know of a condition in which the above implementation will
cause the application class to misbehave or fail; any comments are most
welcome.

If you haven't already read what passes for a "specification" of the
verification algorithm in the JVM spec then you should probably take some time
to do so. I think it amounts to: you're OK provided you don't let any
references to the partially created object "leak" until after the superclass's
<init> method has returned.

Also, if you are running on a pre 1.4 (or was it pre 1.3 ?) JVM, the verifier
rejected some legal bytecode such as that generated by javac for a method like

void method
{
class Local {};
}

where the constructor for Local assigns to the newly allocated object's
synthetic "outer" field before calling the superclass's <init> method.

-- chris

 

[Tor Iver Wilhelmsen]

The java compiler enforces a rule that simply stated requires that a
derived class's constructor must, upon entry, immediately call its
superclass's constructor.

Sort of. It can use static members and _parameters_ in expressions in
the call to super(), but not its instance members. These expressions
of course end up as bytecodes that precede the call to "invokespecial
Superclass::<init>".

Example:

public class Supertest extends Testsuper {

static String aValue = "SomeValue";

public Supertest(boolean aFlag) {
super(aFlag? "Yes" : "No");
}

public Supertest(String overwritten) {
super(overwritten = "Foo");
}

public Supertest() {
super(aValue = "AnotherValue");
}

}

class Testsuper {
public Testsuper(String value) {
}
}

And formally, you can substitute the call to super() with a call to
this() (with the same options of using expressions) to invoke some
other constructor in the same class. And yes, the compiler will detect
recursive/circular invocations of this().