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

Alexander Scherbatiy alexandr.scherbatiy at oracle.com
Tue Oct 6 13:06:57 UTC 2015


On 10/3/2015 5:40 AM, Stuart Marks wrote:
>
>
> 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;
>

   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));

    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



More information about the macosx-port-dev mailing list