Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail
From: Tobias Blass <tobiasblass@gmx.net>
Newsgroups: comp.lang.java.programmer
Subject: Re: calling own methods from constructor
Date: Thu, 7 Apr 2011 10:58:31 +0000 (UTC)
Organization: A noiseless patient Spider
Lines: 45
Message-ID: <ink5cn$e78$1@dont-email.me>
References: <slrnippkd9.phi.avl@gamma.logic.tuwien.ac.at> <2011040622233261380-angrybaldguy@gmailcom> <slrnipr02k.phi.avl@gamma.logic.tuwien.ac.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 7 Apr 2011 10:58:31 +0000 (UTC)
Injection-Info: mx03.eternal-september.org; posting-host="RMN3ouwFys9bx3aIdUo62A"; logging-data="14568"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/N7QvQwEz406ah7D1rTmVHxAkyPJT69MU="
User-Agent: slrn/0.9.9p1 (Linux)
Cancel-Lock: sha1:xmxUvPTS6IR+OVphKZWG/xqyWvg=
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:2922

On 2011-04-07, Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> wrote:
> Owen Jacobson <angrybaldguy@gmail.com> wrote:
>> On 2011-04-06 16:48:41 -0400, Andreas Leitgeb said:
>>
>>> There is well-known danger in calling own methods from the
>>> constructor, namely that the method called may be overridden
>>> by a subclass, which is really instanciated, but whose specific
>>> constructor has not yet been run.
>>> 
>>> I do not intend to delve into the details of static, private
>>> or final methods, or final'ity of the class itself (and maybe
>>> others) avoiding these problems, but instead I'm curious, why
>>> Java just doesn't simply forbid the dangerous calls.
>>
>> It's hard to prove that a constructor never calls a virtual method. Consider:
>> [ example of c'tor calling a private method "internalInit", which in turn
>>   calls virtual "virtualMethod". ]
>
> Good point. The compiler couldn't (at least not statically) prevent
> indirect calling of overridable non-static methods.
>
> But otoh., it refuses to compile this:
>   String bad = (String) new Integer(42);
> while allowing this: (sure bomb at runtime)
>   String bad = (String) (Object) new Integer(42);
>
> So, not being able to prevent something happening indirectly,
> doesn't imply that the direct way would need to be allowed, too.
>
> So, it boils down to the original question of whether there is also
> a good use of constructors (directly or indirectly) invoking
> overridable virtual methods.
>
> What it "good"? I have no exact definition, but if one of the 
> Java gurus (Brian Goetz, Joshua Bloch, James Gosling,...) ever
> before suggested a pattern that would involve it, then chances
> are good, that I'd accept it. Also, if the JSL or one of the big
> Java-based projects used it. Tom's example (Library) didn't
> convince me so far.
>
Why should it complain about your second example? You tell the Compiler
explicitly "Please consider this Integer as Object and this Object as String,
I know types don't match but I know what I'm doing" (I'm programming in C at
the moment where the Compiler doesn't complain about things javac wouldn't
even compile as in your first example, so YMMV)