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 <[email protected]> wrote: > > > On 10/6/15 3:24 AM, Stephen Colebourne wrote: >> >> Moving to core-libs: >> >> On 3 October 2015 at 03:20, Stuart Marks <[email protected]> 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
