JEP: Extending generics to support primitive type arguments

Mon Jul 7 23:23:54 UTC 2014

On 07/08/2014 12:30 AM, Alex Buckley wrote:
> 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

People are never dumb to assume that the spec never change.
But the semantics of == as defined by the spec is dumb and leads a lot 
of people to think that they can write code that do a == on wrapper types,
so most of the codes (if not all) that do a ==  on wrapper types are broken.

So I have no problem to remove that sentence from the spec given that
1) we acknowledge that fact publicly, explain why, apologize and swear 
that we will not do it again for the next 20 years
2) The VM has a special flag that logs every usages of == on a wrapper 
types.
3) javac emit a warning if you try to do a == on wrapper types
     (I know it's not enough people can still use a 
IdentityHashMap<Integer, ...> but it will cover the majority of the 
broken codes)

Rémi

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