RFR(m): 8145468 deprecations for java.lang

[Stuart Marks]

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 <forax at 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 ?