• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Devaka Cooray
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Knute Snortum
  • Bear Bibeault
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Piet Souris
  • Ganesh Patekar
Bartenders:
  • Frits Walraven
  • Carey Brown
  • Tim Holloway

weird ternary operator

 
Ranch Hand
Posts: 78
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi

I came across the following code which compiles fine..

int i = (Boolean.TRUE == Boolean.FALSE) ? 0 : null;

It does not make sence to assign a 'null' to a primitive.
But when I tried to print the value of 'i' after the statement,
it resulted in NPE..
How strange!!!

-S
 
Ranch Hand
Posts: 1780
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You're using Java >= 1.5, right? The following line also works and
gives you a hint as to what's going on...

In the original code, the 0 was boxed into an Integer, and type of the
conditional expression is Integer, then the result of that was
unboxed so it could be assigned to an int. Of course, when you unbox null,
the result is a NPE.

Here, I think the compiler is being too accomodating with boxing/unboxing
 
author and iconoclast
Posts: 24203
43
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Scary, isn't it? In Java 5, we have "autoboxing" and "autounboxing", or automatic conversion between wrapper types and primitives. The conditional is being interpreted as something like

int i = false ? 0 : ((Integer) null).intValue();

so any time this line is executed -- not just when you try to print the result -- you'll get a NullPointerException.
 
Vadiraj Deshpande
Ranch Hand
Posts: 78
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks to both of you Jeff and Ernest.. and yes I am using j2se 5.0.
But why can't this will compile:

int i = null;

How can the compiler catch this one while ignoring the possible disaster in the previous one?

-S
 
Jeff Albertson
Ranch Hand
Posts: 1780
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I guess the short answer is that the syntax rules are complex enough for
some surprising results!
 
Vadiraj Deshpande
Ranch Hand
Posts: 78
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Jeff Albrechtsen:
I guess the short answer is that the syntax rules are complex enough for
some surprising results!



True.. Ernest's reply shows what goes undercover..

-S
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Santosh Deshpande:
Thanks to both of you Jeff and Ernest.. and yes I am using j2se 5.0.
But why can't this will compile:

int i = null;

How can the compiler catch this one while ignoring the possible disaster in the previous one?

-S



The difference is that the above is *sure* disaster, whereas the former code "only" was possible disaster...
 
Vadiraj Deshpande
Ranch Hand
Posts: 78
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
agree
 
author
Posts: 4107
28
Google Web Toolkit Eclipse IDE Flex
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
All really scary if you ask me...
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!