Hi Stephen, Remi,
I would *love* to just get rid of the caches of integral boxed types and get rid
of their constructors. Unfortunately people have been using the constructors for
20 years, but the valueOf(i) methods were added with autoboxing in Java 5,
"only" 11.5 years ago.
We did think about deprecating with forRemoval=true, but after some analysis we
felt that, practically speaking, we wouldn't actually be able to remove them
soon (i.e., in the next release after 9) so we decided not to specify
forRemoval=true.
The caching requirements were added to JLS 3/e (Java 5) and were adjusted in
Java 8, I think. The *specification* of caching in the valueOf(i) methods wasn't
added until Java 7, though I think they've always actually done the caching
since Java 5. But note the JLS doesn't specify the use of valueOf(); it merely
makes some equality and identity requirements. So there's some squishiness here.
I doubt we'd be able to get rid of the caching entirely, but we might be able to
adjust it someone to facilitate optimizations that Vladimir mentioned, or to
ease the transition to value types in the future.
s'marks
On 4/15/16 3:51 AM, Stephen Colebourne wrote:
FWIW. I would prefer to see these constructors removed and the JLS
simplified at the earliest possible date. Not using these classes as
the value types for primitives in Valhalla would be very confusing.
Stephen
On 15 April 2016 at 08:49, Remi Forax <fo...@univ-mlv.fr> wrote:
Hi Heinz,
i think we should go nuclear on this, deprecate the Integer constructor *and*
remove the line in the spec that says that Integer.valueOf (and Byte, Short,
Character, Long) uses a cache and admit that the Java spec should not have a
premature optimization carved in it.
About your example about EA, do you agree that if the set is declared as a
Set<int>, there is no such issue anymore ?
