JEP: Extending generics to support primitive type arguments

[Remi Forax]

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