Path: csiph.com!eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail
From: =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk>
Newsgroups: comp.lang.java.programmer
Subject: Re: A hypothetical compiler extension
Date: Tue, 27 Oct 2015 22:21:20 -0400
Organization: Aioe.org NNTP Server
Lines: 49
Message-ID: <n0pbf2$ld5$1@speranza.aioe.org>
References: <extension-20151027221547@ram.dialup.fu-berlin.de>
NNTP-Posting-Host: 1lM8B9/qdtKBc/uIRK2Gjw.user.speranza.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
X-Notice: Filtered by postfilter v. 0.8.2
Xref: csiph.com comp.lang.java.programmer:32950

On 10/27/2015 5:24 PM, Stefan Ram wrote:
>    The following is hypothetical AFAIK, but wouldn't it be nice?
>
>    One calls
>
> javac -Xlint:null
>
>    and then
>
> void m( final java.lang.Object o )
> { java.lang.System.out.println
>    ( o.toString() ); }
>
>    gives
>
>    ( o.toString() ); }
>      ^
> Warning: o might be null.
>
>    . One rewrites to
>
> void m( final java.lang.Object o )
> { if( o != null )
>    java.lang.System.out.println
>    ( o.toString() ); }
>
>    and the warning disappears.
>
>    Javac alread has path-value-analysis as it already can
>    detect when a path of execution of a method (think of
>    nested ifs) accesses a variable that has not been
>    defined yet in this path.

I don't think it would be appropriate for the compiler
to complain about something that very well may not be
a problem due to something being done in the calling code.

Defensive coding is good, but it should be a developer
choice not something that the compiler get involved in.

The local variable not having gotten a value is a slightly
different case as it will either happen or the code has
been structured badly for the task.

Arne