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

Dawid Weiss 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 [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?SESSIONID=6377

More information about the core-libs-dev mailing list