RFR: JDK-5108778 Too many instances of java.lang.Boolean created in Java application

[Stuart Marks]

On 9/28/15 2:03 AM, Alexander Scherbatiy wrote:
>   Is it possible to use autoboxing in the fix instead of
> Boolean.valueOf(someBooleanVariable)?

Hi,

These cases are all interesting because they end up requiring boxed Boolean 
values, whether explicitly or implicitly via autoboxing:

1. AquaTabbedPaneUI.java -- use of boxed Boolean as a tri-state (!)

2. CAccessibility.java -- return value from Callable<Boolean>

3. LWCToolkit.java -- value in Properties (like Map<Object,Object>)

For #2 and #3 I think auto-boxing instead of valueOf() is just fine. I guess 
using Boolean.TRUE or Boolean.FALSE instead of true or false is ok, as it's a 
micro-optimization to prevent autoboxing from generating a call to 
Boolean.valueOf(true|false). I'm sure the JIT compiler will inline such calls, 
so this speeds up interpreted code a tiny bit at the expense of a little 
verbosity in the code.

The explicit calls to Boolean.valueOf(some boolean expression) I think can 
simply be replaced with autoboxing in all cases.

The weird one is in AquaTabbedPaneUI.java, which has

     protected Boolean isDefaultFocusReceiver = null;

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