Can a constructor call a internal method?

[ThaRez]

Can a constructor call a method that is specifed in the same class?
Can this be done by referreing to the method like this.methodName?
In this case, does the constructor has to be written after the method?
Thanks!

Richard

 

[GregSmith]

Can a constructor call a method that is specifed in the same class?
Can this be done by referreing to the method like this.methodName?
In this case, does the constructor has to be written after the method?
Thanks!

Richard

yes - a constructor is only slightly more special than any other method
yes - "this" exists within the constructor. however, some stylists
claim that "this" isnt completely defined until the constructor is
complete
no - the constructor can appear anywhere in the source module.

Greg

 

[ThaRez]

yes - a constructor is only slightly more special than any other method
yes - "this" exists within the constructor. however, some stylists
claim that "this" isnt completely defined until the constructor is
complete
no - the constructor can appear anywhere in the source module.

Greg

Thank you!

Richard

 

[Rene]

yes - a constructor is only slightly more special than any other method
yes - "this" exists within the constructor. however, some stylists
claim that "this" isnt completely defined until the constructor is
complete

The reason being that you have to be careful using "this" in the
constructor. When you do, you may under _NO_ condition leak it out. (A
method could for example register the "instance" which in reality isn't
completely instantiated yet, somwhere else and another thread picks it up
-- and all hell breaks lose).

It is perfectly valid to use this in the constructor and things like

class foo {

private int field;

public foo(int field) {
this.field = field;
}
}

are common and not bad at all nor dangerous. However, do not leak the
"this" and follow all execution paths so you are sure that specific "this"
is never used outside this class until the constructor has finished.

Or to put it in another way: "this" or rather the object it points to is in
an undefined state when accessed from *another thread* while the
constructor is still running. This can have the side effect that while
everything is initialized within the object and the constructor is just
about to exit, another thread who accesses the same instance via the this
reference it got somehow, may see a completely empty/uninitialized object.
It may run perfectly well on a single-processor system but fail every time
on a multiprocessor system due to memory caching effects.

In short: just don't leak it and watch out if you're going to assign it to
some public static variable. Otherwise you can't IMHO do anything wrong
with it.

CU

Rene

 

[jeffc]

It may run perfectly well on a single-processor system but fail every time
on a multiprocessor system due to memory caching effects.

Or vice versa, presumably.

 

[Steve Horsley]

The reason being that you have to be careful using "this" in the
constructor. When you do, you may under _NO_ condition leak it out. (A
method could for example register the "instance" which in reality isn't
completely instantiated yet, somwhere else and another thread picks it up
-- and all hell breaks lose).

I believe another possible problem is if the method the constructor gets
overridden in a sub-class. The overridden version may try and use variables
that the constructor hasn't initialised yet.

To prevent this, only call private or final methods from your constructor.

Steve

 

[Rene]

I believe another possible problem is if the method the constructor gets
overridden in a sub-class. The overridden version may try and use
variables that the constructor hasn't initialised yet.

That is possible?? It has always been my belief (can't test it right now)
that you cannot ever override a constructor and that the superclass'
constructor always runs through completely first. I mean, Java prevents
calling super() anywhere except as first operation within a constructor. Ok
thinking about it now, what exactly happens if you omit super() ? I can see
some problems if you have several different constructors and one with no
args (that does not initialize needed fields but might get called by java
if you don't have an explicit super(..) call) but I'd file this under
programmer's logic mistakes.

To prevent this, only call private or final methods from your
constructor.

That does not prevent you from leaking "this" prematurely. I know, I did
once, ran into problems, got the shirt

CU

Rene

 

[Rene]

Or vice versa, presumably.

Or never, or only once in a while or always. It is a race condition
actually and probably best described as "undefined behaviour".

CU

Rene

 

[Chris Uppal]

That is possible?? It has always been my belief (can't test it right now)
that you cannot ever override a constructor and that the superclass'
constructor always runs through completely first.

That's correct. But I think that you've misinterpreted Steve: he was talking
about the case where you override a method that is /called/ from the
constructor.

Ok thinking about it now, what exactly happens if you omit super() ?

If you don't begin a constructor with an explicit call to another constructor
(of the same class or the superclass) then the compiler will insert a call to
the superclass's no-args constructor for you.

-- chris

 

[Morten Alver]

That is possible?? It has always been my belief (can't test it right now)

that you cannot ever override a constructor and that the superclass'
constructor always runs through completely first. I mean, Java prevents
calling super() anywhere except as first operation within a constructor. Ok
thinking about it now, what exactly happens if you omit super() ? I can see
some problems if you have several different constructors and one with no
args (that does not initialize needed fields but might get called by java
if you don't have an explicit super(..) call) but I'd file this under
programmer's logic mistakes.

The constructor cannot be overridden. If you omit super(), the
superclass constructor will still be called. I think the grandparent
poster meant that the method the constructor calls can be overridden -
which can be prevented by only calling private or final methods.


Morten

 

[Rene]

That's correct. But I think that you've misinterpreted Steve: he was
talking about the case where you override a method that is /called/ from
the constructor.


If you don't begin a constructor with an explicit call to another
constructor (of the same class or the superclass) then the compiler will
insert a call to the superclass's no-args constructor for you.

Ok, there you can run into a problem if the noarg-constructor of the
superclass does not initialize everything. I sometimes do that if I have an
object that is either properly constructed (with an arg-constructor) or
instantiated using a no-arg constructor and then use some sort of
serialization to fill in values (read from a socket) or so. There are other
methods and I could use a factory instead but this is one of the instances
where it may become a problem.

If you then omit the correct super-call in a derivative class, any access
to any field will of course find the default values which may or may not be
bad.

But I believe we drift away from the original question ... ?

CU

Rene

 

[Rene]

The constructor cannot be overridden. If you omit super(), the
superclass constructor will still be called. I think the grandparent
poster meant that the method the constructor calls can be overridden -
which can be prevented by only calling private or final methods.

Ah yes, thanks, I see the greater picture then. Yeah, perfectly valid to
use this in that context.

CU

Rene

 

[jeffc]

That is possible?? It has always been my belief (can't test it right now)
that you cannot ever override a constructor and that the superclass'
constructor always runs through completely first. I mean, Java prevents
calling super() anywhere except as first operation within a constructor. Ok
thinking about it now, what exactly happens if you omit super() ?

Well you can't really. As long as your constructor isn't calling another
(overloaded) constructor, then it's going to call super() whether you like it or
not.