<AWT Dev> RFR: JDK-5108778 Too many instances of java.lang.Boolean created in Java application(macos)
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:
> For some general discussion on regression-tests for this please find the
> thread in discuss and for the general suggestion to make more
> wrapper-type-constructors deprecated find  at core-libs-dev.
>  http://mail.openjdk.java.net/pipermail/discuss/2015-October/003805.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
>>> 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 &&
>> instead of the long version:
>> isDefaultFocusReceiver = Boolean.valueOf(defaultFocusReceiver !=
>> null && defaultFocusReceiver.equals(component));
>>> 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.
More information about the awt-dev