Test for JDK-5108778 Too many instances of java.lang.Boolean created in Java application
stuart.marks at oracle.com
Wed Oct 7 00:01:11 UTC 2015
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.
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
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. 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
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.
More information about the core-libs-dev