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 >
