<AWT Dev> RFR: JDK-5108778 Too many instances of java.lang.Boolean created in Java application(macos)

Alexander Scherbatiy alexandr.scherbatiy at oracle.com
Thu Oct 8 11:06:40 UTC 2015

   The fix looks good to me.

   Note that there are usually necessary to have at least two reviewers 
for a fix in Open JDK.

   Are you going to push the fix as part of other fixes for different 
JDK areas or as a separate fix?
   In the second case you need to file a new bug for it.


On 10/7/2015 10:59 PM, Sebastian Sickelmann wrote:
> Please find the updated webrev at:
> http://cr.openjdk.java.net/~sebastian/5108778/macos/webrev.00/
> For some general discussion on regression-tests for this please find the
> thread in discuss[0][1] and for the general suggestion to make more
> wrapper-type-constructors deprecated find [2] at core-libs-dev.
> [0]
> http://mail.openjdk.java.net/pipermail/discuss/2015-September/003804.html
> [1] http://mail.openjdk.java.net/pipermail/discuss/2015-October/003805.html
> [2]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/035642.html
> -- Sebastian
> On 10/06/2015 03:06 PM, Alexander Scherbatiy wrote:
>> 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 awt-dev mailing list