Re: this reference in Java constructors
Thomas Pornin wrote:
According to Joshua Cranmer <Pidgeot18@verizon.invalid>:
The more technical answer:
When you construct an object with new Foo();, this is the bytecode
generated (roughly):
anew Foo
dup
invokespecial Foo#<init>()V
[the last reference on the stack you are free to do what you will with
Just for completeness: the JVM also verifies that whenever an object is
created (with the 'new' ocode) then a call to a constructor necessarily
follows, before any other use of the reference to the new instance. The
JVM also checks that each constructor begins with an invocation of a
constructor in the superclass.
Only "sort of." It's fairly easy to get an arbitrary
amount of code executed *before* the superclass' constructor
runs, as in
class Counterexample extends HasBoolConstructor {
Counterexample() {
super(boolMethod());
}
private bool boolMethod() {
// Twelve SQL queries,
// Eleven XML parses,
// Ten external programs,
// Nine RMI calls,
// Eight LDAP queries,
// Seven serializations,
// Six caught exceptions,
// Five di-a-logs!
// Four URLs,
// Three GC's,
// Two JAR downloads, and
return pearTree.add("Partridge");
}
private static final HashSet<String> pearTree =
new HashSet<String>();
}
The point is that the constructor gets hold of the new object (under the
name of 'this') before anyone else. Therefore, it is up to that constructor
to initialize fields as it sees fit. But nothing prevents the constructor
itself from showing the not-yet-initialized instance to whatever code it
wishes. What Java ensures is that the constructor _can_ keep things
tidy and protected from external interference; but it does not prevent the
constructor from being as untidy as it sees fit.
Right you are.
--
Eric Sosman
esosman@ieee-dot-org.invalid