JEP: Extending generics to support primitive type arguments

[Alex Buckley]

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

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!
>>>>>       >
>>>>>       >
>>>>>
>>>>>
>>>>
>