Very strange behavior with Tertiary op, null and autoboxing

[Sideswipe]

I have this code:

public Boolean getValue(ItemAttributeSource source) {
Currency c = FIXED_SHIPPING_CHARGE.getValue(source);

return (c != null ? c.compareTo(c.getUnit().ZERO_VALUE) > 0 :
null);
}

it compiles happy and runs fine on RHEL3 using JDK 1.6.0_03.

This same exact code throws a NullPointerException on Windows XP JDK
1.6.0_02 (same problem happened on 1.5) because of this autoboxing
behavior:

Boolean a = null;
boolean b = a;

System.out.println(b); // NPE here as expected

So, what's happening is that on linux the Type of the 3rd operand is
determined and the 2nd is boxed to it
On windows, the second operand type is determined (primitive boolean)
and then the 3rd operand is boxed to it which is producing a NPE.

Also, on Linux it compiles fine and figures out the correct boxing
type is Boolean (that is the return type). On Windows it requires an
explicit cast of the second operand to (Boolean) to make this work.

Can someone explain this to me?

Christian Bongiorno
http://christian.bongiorno.org

 

[Daniel Pitts]

I have this code:

public Boolean getValue(ItemAttributeSource source) {
Currency c = FIXED_SHIPPING_CHARGE.getValue(source);

return (c != null ? c.compareTo(c.getUnit().ZERO_VALUE) > 0 :
null);

}

it compiles happy and runs fine on RHEL3 using JDK 1.6.0_03.

This same exact code throws a NullPointerException on Windows XP JDK
1.6.0_02 (same problem happened on 1.5) because of this autoboxing
behavior:

Boolean a = null;
boolean b = a;

System.out.println(b); // NPE here as expected

So, what's happening is that on linux the Type of the 3rd operand is
determined and the 2nd is boxed to it
On windows, the second operand type is determined (primitive boolean)
and then the 3rd operand is boxed to it which is producing a NPE.

Also, on Linux it compiles fine and figures out the correct boxing
type is Boolean (that is the return type). On Windows it requires an
explicit cast of the second operand to (Boolean) to make this work.

Can someone explain this to me?

Christian Bongiornohttp://christian.bongiorno.org

<http://java.sun.com/docs/books/jls/third_edition/html/
expressions.html#15.25>

"If one of the second and third operands is of type boolean and the
type of the other is of type Boolean, then the type of the conditional
expression is boolean."

Sounds like it should throw an NPE whenever c==null in this case.

The clearer way to do this is:
if (c== null) { return null; }
return c.compareTo(ZERO) > 0;

Although, I would take it a step further, and replace the Boolean
return value with a "ShippingCharge" value that has the appropriate
handling of true/false/"null". Also, make the ShippingCharge object
returned never be null, but instead create a special value that
handles the business logic of that case. Polymorphism is your friend.

 

[Sideswipe]

So then the Linux Version is bugged? The behavior should be identical
regardless of platform -- this is a definite portability issue.
As for changing the return type -- you assume I control the code and
can jam that down other peoples throats.

I must have read an old version of the spec as the one I read was
silent on this. I did also remove the ternary operator to eliminate
ambiguity.

 

[Daniel Pitts]

Please don't top post.

So then the Linux Version is bugged? The behavior should be identical
regardless of platform -- this is a definite portability issue.
As for changing the return type -- you assume I control the code and
can jam that down other peoples throats.

I made no such assumption. I simply gave you a gem of good advice on
how it *should* be done. Whether you have the clout with your
coworkers isn't my problem

I must have read an old version of the spec as the one I read was
silent on this. I did also remove the ternary operator to eliminate
ambiguity.

That's a good step in the right direction.

 

[Zig]

So then the Linux Version is bugged? The behavior should be identical
regardless of platform -- this is a definite portability issue.
As for changing the return type -- you assume I control the code and
can jam that down other peoples throats.

As an aside, it's considered a portability issue if the compiled bytecode
from one platform has a different result when moved to another platform..

When you're moving the source instead of the bytecode to a different
platform, and compiling with a (slightly) different compiler, it becomes a
compiler issue instead. Efforts are made to ensure source is reasonably
effortless to port between platforms and java versions, but there is no
guarantee, and incompatibilites can and do come up.

Daniel's advice is solid. As an observation, I've begun configuring my IDE
to generate warnings wherever autoboxing is lurking in production code.
Don't get me wrong: it's great for unit tests, but in production code it
seems to cause more problems than it solves (and has turned out to be the
source of numerous NullPointerExceptions and ClassCastExceptions, not to
mention some performance surprises when an inexperienced developer
replaced a "double" with a "Double"). If you're not willing to go to that
extreme, you might find that the IDE will offer some color-coding, so you
can see where it is inserting the hidden box expansion. In your case:

return Boolean.valueOf(c != null ? c.compareTo(c.getUnit().ZERO_VALUE) > 0
: null.booleanValue());

vs

return c != null ? Boolean.valueOf(c.compareTo(c.getUnit().ZERO_VALUE) >
0) : null;

I think most IDEs will offer to highlight the section of code being
wrapped by the <Type>.valueOf() / unbox call.

HTH,

-Zig