Re: this reference in Java constructors
Lew wrote:
Eric Sosman wrote:
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() {
[...]
return pearTree.add("Partridge");
}
private static final HashSet<String> pearTree =
new HashSet<String>();
}
Lew wrote:
In addition to the obvious dangers here that you've already discussed,
the instance-level access to a static structure is problematic. This is
a well-crafted example of code idioms to avoid.
Eric Sosman wrote:
Okay, it was a whimsical example -- but maybe because of
whimsy I'm about to learn something I didn't know. Why is it
"problematic" to access a static element from non-static code?
That isn't what I said.
class Problematic {
public void announce() {
System.out.println("Problematic?");
}
}
That's not the same at all. What I said is that "the access ... is
problematic", that is, the particular one under discussion, not just
any access.
The access to which I referred was an instance-level write to a static
memory structure. Your new example is a write to a stream, thus there
is no further state to observe. Apples and oranges.
System.out isn't static? PrintStream has no observable state?
In your first example the access is problematic because it isn't
thread safe. That is not true for your second example.
Red herring. Use Collections.synchronizedMap() on it if you like:
Now it's thread-safe, but still static. What's "problematic?"
--
Eric.Sosman@sun.com