JEP: Extending generics to support primitive type arguments

[Alex Buckley]

Assume I agree with every word you say below. It remains a fact that the 
spec made guarantees and people were therefore entitled to rely on those 
guarantees for all future time. Maybe it was a "little dumb" of them, 
because, sure, 10+ years later a feature might get pulled. But it should 
never be "very very dumb" to rely on the spec for 1, 5, or 10 years.

Alex

On 7/7/2014 3:16 PM, Remi Forax wrote:
>
> On 07/07/2014 11:28 PM, Alex Buckley wrote:
>> I wasn't trying to make a general point about the direction of
>> specialized generics. It could well be that the flyweight boxing goes
>> away. I was merely pointing out that anyone relying on the identity of
>> Integer objects is _not_ being very very dumb, because the Java
>> language was designed to support == in limited cases.
>>
>> Alex
>
> Flyweight boxing can still stand but only when needed, i.e. you can
> still use a cache when boxing is required but allows JITs to unbox when
> needed (let say in loops by example). Flyweight boxing is an
> implementation detail and not something that the Java spec should mandate.
>
> Relying on == on any wrapper types in the code is dumb because while you
> can predict what happen for values between -128 and 127,
> you can not predict what's happen for a value outside of this range, ==
> may or may not returns true, the spec doesn't say that the value 128
> is not cached (BTW, you can change the high value of the range with
> -Djava.lang.Integer.IntegerCache.high=128).
>
> So basically, either you think that you are smart enough to guarantee
> that a code will never use a value outside the -128..127 range,
> and you are dumb because requirements and codes change or you know that
> == on a wrapper type has not a well defined semantics
> and you don't use it.
>
> Rémi
>
>>
>> On 7/7/2014 2:18 PM, Remi Forax wrote:
>>> As a the guardian of the temple, I understand that you don't want to
>>> erase that line, but this line screams "premature optimization".
>>> This sentence should not exist in the spec of a modern language.
>>>
>>> "If the value |p| being boxed is an integer literal of type |int|
>>> between |-128| and |127| inclusive (§3.10.1
>>> <http://docs.oracle.com/javase/specs/jls/se8/html/jls-3.html#jls-3.10.1>),
>>>
>>> or the boolean literal |true| or |false| (§3.10.3
>>> <http://docs.oracle.com/javase/specs/jls/se8/html/jls-3.html#jls-3.10.3>),
>>>
>>> or a character literal between |'\u0000'| and |'\u007f'| inclusive
>>> (§3.10.4
>>> <http://docs.oracle.com/javase/specs/jls/se8/html/jls-3.html#jls-3.10.4>),
>>>
>>> then let |a| and |b| be the results of any two boxing conversions of
>>> |p|. It is always the case that |a| |==| |b|. "
>>>
>>> The spec of the Java memory model has changed (1.5 vs pre-1.5) for very
>>> similar reasons, so I don't see why we can not at least discuss about
>>> removing this line.
>>> Removing it will just make all implementations of the spec less evil.
>>>
>>> Rémi
>>>
>>> On 07/07/2014 08:07 PM, Alex Buckley wrote:
>>>> Notwithstanding the flyweight rule at
>>>> http://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.7-300
>>>>
>>>> ...
>>>>
>>>> Alex
>>>>
>>>> On 7/7/2014 9:47 AM, Stephen Colebourne wrote:
>>>>> Sometimes compatibility can go too far. This might be one of those
>>>>> times. Anyone relying on the identity of Integer is being very very
>>>>> dumb (not just a little dumb), and breaking their code seems like it
>>>>> could be a reasonable trade off compared with the potential benefits.
>>>>> Stephen
>>>>>
>>>>>
>>>>> On 7 July 2014 17:25, Brian Goetz <brian.goetz at oracle.com> wrote:
>>>>>> We couldn't possibly remove it; that could break existing code. (Just
>>>>>> because its dumb to rely on the identity of an Integer, doesn't mean
>>>>>> people
>>>>>> haven't.)  All we can do is hope to obsolete it.
>>>>>>
>>>>>> Compatibility is a harsh mistress.
>>>>>>
>>>>>>
>>>>>> On 7/6/2014 9:35 AM, Martijn Verburg wrote:
>>>>>>>
>>>>>>> Hi Brian,
>>>>>>>
>>>>>>> I'll echo Paul and add "Good Luck" :-). My only real comment is
>>>>>>> that I'm
>>>>>>> not sure the question of: "Is there any impact / change / removal
>>>>>>> required for the existing autoboxing/unboxing functionality"?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Martijn
>>>>>>>
>>>>>>>
>>>>>>> On 26 June 2014 19:20, Paul Benedict <pbenedict at apache.org
>>>>>>> <mailto:pbenedict at apache.org>> wrote:
>>>>>>>
>>>>>>>      Brian, what a puzzler! This might be the most complex proposed
>>>>>>>      feature yet.
>>>>>>>      It will be a treat to see how others solve the problem.
>>>>>>>
>>>>>>>      Here is my first comment...
>>>>>>>      Given T=int, I would like to see the JVM magically substitute
>>>>>>> in an
>>>>>>>      "object" that's backed by the primitive. I use "object" in
>>>>>>> quotes
>>>>>>>      because I
>>>>>>>      am not referring to something that's instantiated per
>>>>>>> primitive value
>>>>>>> --
>>>>>>>      but some sort of synthetic singleton where all int primitives
>>>>>>> point
>>>>>>>      to the
>>>>>>>      same one. Since there is no other state in this "object" but
>>>>>>> the value
>>>>>>>      itself, this seems okay. The primitive value is actually the
>>>>>>> "this"
>>>>>>>      pointer
>>>>>>>      in the virtual method call.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>      Cheers,
>>>>>>>      Paul
>>>>>>>
>>>>>>>
>>>>>>>      On Fri, Jun 20, 2014 at 8:41 PM, Brian Goetz
>>>>>>> <brian.goetz at oracle.com
>>>>>>>      <mailto:brian.goetz at oracle.com>> wrote:
>>>>>>>
>>>>>>>       > I've submitted the following JEP for extending generics to
>>>>>>> support
>>>>>>>       > primitive type arguments:
>>>>>>>       >
>>>>>>>       > https://bugs.openjdk.java.net/browse/JDK-8046267
>>>>>>>       >
>>>>>>>       > Comments welcome!
>>>>>>>       >
>>>>>>>       >
>>>>>>>
>>>>>>>
>>>>>>
>>>
>