uninitialized variable

[asit]

Consider these two snippets of code

//1st one
public class TestOne{
public static void main(String [] args) {
int x;
int y = 10;
if(y == 10){
x = 10;
}
System.out.println(x);
}
}

//2nd one
public class TestTwo{
public static void main(String [] args) {
int x;
int y = 10;
if(true){
x = 10;
}
System.out.println(x);
}
}



Why 2nd one is not an error, but the 1st one ????

 

[Wojtek]

Eric Sosman wrote :

Occasionally, Java's inability (or refusal) to see that some
execution paths are impossible leads to a situation where you must
make a needless initialization just to pacify the compiler.

A real example:

---------------------------------
String indent;

if ( isLogging )
{
indent = " ";
log(indent + "Message" );
}

....

if ( isLogging )
log(indent + "Message 2" );
---------------------------------

Here the compile will fail because indent is not initialized in its
second use, even though if isLogging is true, then it will be
initialized by the time of the seond call. So you need:

String indent = null;

to keep the compiler happy.

 

[Mark Space]

Consider these two snippets of code

//1st one
public class TestOne{
public static void main(String [] args) {
int x;
int y = 10;

Aaaaahhhh! The indentation! It burnsss ussss!

 

[Roedy Green]

Why 2nd one is not an error, but the 1st one ????

Javac is not all that bright at noticing the if always goes through
the same branch. "if (true )" it can figure out, but not much more.
--
Roedy Green Canadian Mind Products
http://mindprod.com

Never discourage anyone... who continually makes progress, no matter how slow.
~ Plato 428 BC died: 348 BC at age: 80

 

[Joshua Cranmer]

Why 2nd one is not an error, but the 1st one ????

In short, because seeing "obvious" true statements is a slippery slope.
Observe:

int x, y = 0;
for (int i = 0; i < 1; i++)
y += i;

if (y == 0) {
x = 0;
}

Should x be definitely assigned? If not, how is that any different from
the first example (the y += i is only executed once)?

 

[Mark Space]

In short, because seeing "obvious" true statements is a slippery slope.
Observe:

int x, y = 0;
for (int i = 0; i < 1; i++)
y += i;

if (y == 0) {
x = 0;
}

Should x be definitely assigned? If not, how is that any different from
the first example (the y += i is only executed once)?

Also I think we should point out:

public static void main(String[] args) {

final int y = 3;
int x;

if( y == 3 ) {
x = 10;
}
System.out.println(x);
}

Also compiles and runs fine.

 

[Lew]

Eric Sosman wrote :

A real example:

---------------------------------
String indent;

if ( isLogging )
{
indent = " ";
log(indent + "Message" );
}

...

if ( isLogging )
log(indent + "Message 2" );
---------------------------------

Here the compile will fail because indent is not initialized in its
second use, even though if isLogging is true, then it will be
initialized by the time of the seond call. So you need:

Not necessarily. Another thread may have changed 'isLogging' after the first
check. There's just not enough proof that the string is definitely assigned
for the second 'if' clause.

At least not without the compiler trying to second-guess every single run-time
variation on the use of the class, which is more work than it needs to do when
it's so very simple to report that the variable is not definitely assigned,
and for the programmer to follow your advice with:

 

[Roedy Green]

Take
your medicine like a grown-up; lots of worse things happen every day.

I think that a bit harsh. He noticed an anomaly and was curious to the
source. That curiosity is something want to encourage.
--
Roedy Green Canadian Mind Products
http://mindprod.com

Never discourage anyone... who continually makes progress, no matter how slow.
~ Plato 428 BC died: 348 BC at age: 80

 

[Mike Schilling]

Not necessarily. Another thread may have changed 'isLogging' after
the first check.

Unless it's a local variable, of course.

 

[Eric Sosman]

I think that a bit harsh. He noticed an anomaly and was curious to the
source. That curiosity is something want to encourage.

In the preceding part of my reply (which you snipped),
I gave both an explanation of the compiler's reasons and a
pointer for further study. "Harsh?"

> [...] no [...]

> [...] No [...]

> [...] don't [...]

> [...] not [...]

> [...] Nothing [...]

(Look it up on Google Groups if you doubt my sources.) From
these excerpts, I conclude that R.G. is a nattering nabob of
negativism. Harrumph!

 

[Wojtek]

Lew wrote :

Another thread may have changed 'isLogging' after the first check.

Grumble grumble, stupid compiler cannot divine my intent...

Yes you are right. Even though isLogging actually is Log.isTraceLogging
which is set at application startup and never modified during runtime.

 

[Tom McGlynn]

This is a general comment on the thread rather than a specific
response to Roedy...

I'm intrigued by the general tone of the responses: this is a bit of a
quirk in Java and you just have to live with it. For me the rules of
-- and philosophy behind -- definite assignment are what makes Java a
language I like to program in and a real step forward from
predecessors like C and Fortran.

Why do I feel this way?

We always talk about Java as being portable. However C and Fortran
and C++ and all are also very portable so long as they are used
properly. Good Fortran will run beautifully on a much larger range of
platforms than Java can aspire to. However I don't always write
perfect programs. Every once in a while )) I write a bug. The
consequences in C and Fortran may be large or small, but critically
they are very likely to be undefined and vary substantially from
implementation to implementation.

Java is the first language that I've worked in extensively which
really supports the philosophy that it is as helpful when programs
fail consistently when they are wrong as that they work consistently
when they are correct. Consequently Java has a much more precise view
of what constitutes a correct program and what is not. This precision
comes at the cost of a bit of seeming arbitrariness in the treatment
of
uninitialized variables, but the rules are pretty clear and far better
than leaving it to the compiler to decide if it can prove that a
variable is set.

Nothing's perfect, but I submit that Java's seemingly arbitrary rules
for definite assignment are a step in that direction.

Regards,
Tom McGlynn

 

[Roedy Green]

In the preceding part of my reply (which you snipped),
I gave both an explanation of the compiler's reasons and a
pointer for further study. "Harsh?"

"take your medicine like a grownup" is patronising. It implies the
person you are talking to is your inferior. "lots of lots of worse
things happen every day" sounds like you are saying he is being
childish and petulant for taking an interest in the phenomenon.

You have to be careful with such phrases. In person your tone of voice
shows you are not being insulting, just colourful. In ASCII text all
you have are the literal words.
--
Roedy Green Canadian Mind Products
http://mindprod.com

If everyone lived the way people do in Vancouver, we would need three more entire planets to support us.
~ Guy Dauncey

 

[John B. Matthews]

"take your medicine like a grownup" is patronising. It implies the
person you are talking to is your inferior. "lots of worse things
happen every day" sounds like you are saying he is being childish and
petulant for taking an interest in the phenomenon.

I did not take this meaning at all. I've wondered about errors like
this, too. I found it helpful to learn that sometimes you just have to
throw the compiler a bone.

I sense you mean to defend the OP, but there is no reason to think s/he
took umbrage. I sense also that you lament the decline of usenet, but I
think ambitious prosecutors, greedy ISPs and proprietary fora bear more
of the blame.

You have to be careful with such phrases. In person your tone of
voice shows you are not being insulting, just colourful. In ASCII
text all you have are the literal words.

This is surely true, but your signature quotes, for example, are
routinely patronizing, most recently insulting everyone in Vancouver
while ignoring those villains in nearby Maple Ridge

I'm inclined to let Roedy be Roedy, Eric be Eric, etc.