Test for JDK-5108778 Too many instances of java.lang.Boolean created in Java application
dawid.weiss at gmail.com
Wed Oct 7 06:51:35 UTC 2015
A @Discouraged(String seeAlternative) annotation? This also applies to
things like Vector or Hashtable (which arguably have a
slightly different semantics from ArrayList or HashMap, but if somebody uses
them it's very likely a mistake).
This reminds me of the work Uwe Schindler did with his "forbidden
APIs" tool ; many projects are currently using it to avoid trappy
APIs. The tool emits a warning and an explanation when it encounters
such API usage, see  for a list of methods in the JDK, for
On Wed, Oct 7, 2015 at 2:01 AM, Stuart Marks <stuart.marks at oracle.com> wrote:
> 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.
>>> 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
> 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. 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.
More information about the core-libs-dev