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

[Dawid Weiss]

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 [1]; 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 [2] for a list of methods in the JDK, for
instance.

Dawid

[1] https://github.com/policeman-tools/forbidden-apis
[2] https://github.com/policeman-tools/forbidden-apis/tree/master/src/main/resources/de/thetaphi/forbiddenapis/signatures

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.
>>> 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