On 10/6/15 6:06 AM, Alexander Scherbatiy wrote:
On 10/3/2015 5:40 AM, Stuart Marks wrote:
The weird one is in AquaTabbedPaneUI.java, which has
protected Boolean isDefaultFocusReceiver = null;
I do not mean to change the isDefaultFocusReceivertype type to boolean. It
was just interesting are there pros and cons to use a short version with
autoboxing for assignment:
isDefaultFocusReceiver = defaultFocusReceiver != null &&
defaultFocusReceiver.equals(component);
instead of the long version:
isDefaultFocusReceiver = Boolean.valueOf(defaultFocusReceiver != null &&
defaultFocusReceiver.equals(component));
I agree, changing Boolean to boolean here is too invasive for a cleanup change.
Right, the "interesting" issue is if this code were changed to use autoboxing,
it would end up being this:
if (isDefaultFocusReceiver == null) {
// ...
isDefaultFocusReceiver = defaultFocusReceiver != null &&
defaultFocusReceiver.equals(component);
}
The isDefaultFocusReceiver field is being checked against null and then a
boolean value is being assigned to it. That looks strange.
I guess in this case the call to Boolean.valueOf() makes it clearer what's going
on. But I'll leave the final decision to you.
s'marks
Thanks,
Alexandr.
Ugh! It would be nice to get rid of null as a marker for uninitialized state,
but that might require too much analysis to show that the change would be
correct. This is, I think, the only case where the code has to be explicit
about dealing with a boxed Boolean object that might be null, as opposed to
true or false.
The only place that really has to do that is isDefaultFocusReceiver(), which
checks for null up front. I'm not sure that using Boolean.valueOf() and
Boolean.booleanValue() in the rest of the method are really helpful in
denoting that this is a boxed, nullable Boolean though. So I'd switch to
autoboxing here too.
s'marks
