Test for JDK-5108778 Too many instances of java.lang.Boolean created in Java application

[Stuart Marks]

On 10/6/15 3:24 AM, Stephen Colebourne wrote:
> Moving to core-libs:
>
> On 3 October 2015 at 03:20, Stuart Marks <stuart.marks at oracle.com> wrote:
>> An interesting exercise would be to add the @Deprecated annotation to the
>> Boolean constructor and build the JDK and see how many warnings result. That
>> might be a quick way to find the code that needs to be fixed.
>
> I'd really like to see this. Specifically, adding @Deprecated to _all_
> constructors on Boolean, Short, Integer, Long, Character, Float,
> Double. This may require some additional factory methods to be added.
>
> Doing this for Java 9 would be good preparation for value types. While
> the Valhalla team are not currently talking about converting these
> classes to values, they are clearly very value-like. Pushing users to
> treat them more as values seems like a Good Thing. It might even tip
> the balance towards making them actual value types.

Hi Stephen,

Interesting. There are a few issues at play here; let me try to separate them.

In my message above, I merely suggested that Sebastian add @Deprecated to the 
Boolean constructors in his source tree as a means of static analysis. This is a 
quick way to derive a set of targets for cleaning up.

That said, it's worth considering changing the Java SE API to deprecate Boolean 
and possibly other box constructors. As things stand today, though, the 
situation with deprecation is quite confusing. It's not clear whether 
deprecating something means that it will eventually be removed. When something 
becomes deprecated, people's responses are all over the map. It's either "ignore 
it, they've never removed anything from the JDK" or "they can't remove that, it 
will cause massive breakage!!" So the notion of deprecation will have to be 
clarified first.

I'm working on a draft JEP (not yet public) for this, but some early thoughts 
along these lines were presented by my alter ego Dr Deprecator at JavaOne last 
year.[1] Basically, you'd want some marking that doesn't mean that the API will 
be removed, but that will issue a warning to developers suggesting they use a 
different API instead.

I think it's pretty clear that we should "deprecate" in some fashion the Boolean 
and Byte constructors, since boxes for all possible values of these types are 
cached and reused.

The case for deprecating other box constructors is less clear in my mind. For 
example, Double.valueOf(d) always calls new Double(d); no Double boxes are 
cached. One could imagine caching specific boxes such as zero, but there are 
very few such values that would make sense to cache. The benefit of telling 
programmers to convert new Double(d) to Double.valueOf(d) thus seems quite small 
to me.

Then again, in a value-typed future, there might be some advantages to doing 
this that I'm not aware of. Some time ago Brian Goetz was quite skeptical that 
the primitive boxes could ever become true value types. But things might have 
changed, so I'll avoid forming a strong opinion on this issue until we hear more 
about how value types might impact this issue.

s'marks



[1] https://oracleus.activeevents.com/2014/connect/sessionDetail.ww?SESSION_ID=6377