RFR: 5108778 Too many instances of java.lang.Boolean created in Java application(core-libs)

Sebastian Sickelmann sebastian.sickelmann at gmx.de
Fri Oct 9 19:23:08 UTC 2015


On 10/09/2015 08:58 PM, Stuart Marks wrote:
> On 10/9/15 4:16 AM, Aleksey Shipilev wrote:
>> Please note that "static final Boolean myBool = new
>> Boolean(true).booleanValue()" is a spec-recommended way to avoid binary
>> incompatibilities caused by conditional compilation. See JLS 13.4.9.
>> Therefore, deprecating Boolean constructors is a spec issue as well.
>
> Well, not "recommended" :-) but point well taken. From JLS 13.4.9:
I didn't know that there is a recommended workaround for this in the
JLS, but maybe it is in the wrong chapter. Chapter "13 Binary
Compatibility" is fine for the first part of "13.4.9 |final| Fields
and |static| Constant Variables". But the workaround for should be
documented in a chapter that handles the conditional compilation. The
only place i could find is the end of "14.21. Unreachable Statements"
>
>> We note, but do not recommend, that if a field of primitive type of an
>> interface may change, its value may be expressed idiomatically as in:
>>     boolean debug = new Boolean(true).booleanValue();
>
> The bit about conditional compilation is with regard to constant
> expressions. The goal here is to get a boolean value into the
> initializer of a field, but to have that initializer not be a constant
> expression. I think that
>
>     Boolean.valueOf(true).booleanValue()

I have tried it. And it works as described on primitive types. So a

static final Boolean myBool = new Boolean(true).booleanValue()

is not needed because-

static final Boolean myBool = true

works too due to autoboxing and implicitly changing to

static final Boolean myBool = Boolean.valueOf(true)

>
> would be sufficient for this and avoids using the constructor.
And i think i would use Boolean.TRUE.booleanValue() to do the trick on
booleans. The valueOf works best with every other Wrapper-Type.
>
> I'll file a bug on the JLS for this.
What is the Bug-Number. Maybe i can watch and comment on this.

Thanks
>
> Thanks!
>
> s'marks
>




More information about the core-libs-dev mailing list