From martijnverburg at gmail.com Sun Jul 6 13:35:10 2014 From: martijnverburg at gmail.com (Martijn Verburg) Date: Sun, 6 Jul 2014 14:35:10 +0100 Subject: JEP: Extending generics to support primitive type arguments In-Reply-To: References: <53A4E2CA.9090603@oracle.com> Message-ID: 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 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 > 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! > > > > > From brian.goetz at oracle.com Mon Jul 7 16:25:43 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 07 Jul 2014 12:25:43 -0400 Subject: JEP: Extending generics to support primitive type arguments In-Reply-To: References: <53A4E2CA.9090603@oracle.com>

Message-ID: <53BACA07.1010208@oracle.com> 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 > 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 > 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! > > > > > > From brian.goetz at oracle.com Mon Jul 7 16:40:55 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 07 Jul 2014 12:40:55 -0400 Subject: Result: New Project: Valhalla Message-ID: <53BACD97.5040500@oracle.com> Voting on Project Valhalla [1], with initial Lead of Brian Goetz, is now closed. Yes: 22 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the new Project and its initial Lead. -Brian Goetz [1] http://mail.openjdk.java.net/pipermail/announce/2014-June/000174.html From scolebourne at joda.org Mon Jul 7 16:47:15 2014 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 7 Jul 2014 17:47:15 +0100 Subject: JEP: Extending generics to support primitive type arguments In-Reply-To: <53BACA07.1010208@oracle.com> References: <53A4E2CA.9090603@oracle.com>

<53BACA07.1010208@oracle.com> Message-ID: 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 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 > > 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 > > 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! >> > >> > >> >> > From alex.buckley at oracle.com Mon Jul 7 18:07:58 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 07 Jul 2014 11:07:58 -0700 Subject: JEP: Extending generics to support primitive type arguments In-Reply-To: References: <53A4E2CA.9090603@oracle.com>

<53BACA07.1010208@oracle.com> Message-ID: <53BAE1FE.2080300@oracle.com> 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 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 >> > 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 >> > 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! >>> > >>> > >>> >>> >> From forax at univ-mlv.fr Mon Jul 7 21:18:42 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 07 Jul 2014 23:18:42 +0200 Subject: JEP: Extending generics to support primitive type arguments In-Reply-To: <53BAE1FE.2080300@oracle.com> References: <53A4E2CA.9090603@oracle.com>

<53BACA07.1010208@oracle.com> <53BAE1FE.2080300@oracle.com> Message-ID: <53BB0EB2.3050205@univ-mlv.fr> 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 ), or the boolean literal |true| or |false| (?3.10.3 ), or a character literal between |'\u0000'| and |'\u007f'| inclusive (?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 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 >>> > 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 >>>> >>> > 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! >>>> > >>>> > >>>> >>>> >>> From alex.buckley at oracle.com Mon Jul 7 21:28:12 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 07 Jul 2014 14:28:12 -0700 Subject: JEP: Extending generics to support primitive type arguments In-Reply-To: <53BB0EB2.3050205@univ-mlv.fr> References: <53A4E2CA.9090603@oracle.com>

<53BACA07.1010208@oracle.com> <53BAE1FE.2080300@oracle.com> <53BB0EB2.3050205@univ-mlv.fr> Message-ID: <53BB10EC.30607@oracle.com> 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 > ), > or the boolean literal |true| or |false| (?3.10.3 > ), > or a character literal between |'\u0000'| and |'\u007f'| inclusive > (?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 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 >>>> > 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 >>>>> >>>> > 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! >>>>> > >>>>> > >>>>> >>>>> >>>> > From forax at univ-mlv.fr Mon Jul 7 22:16:13 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 08 Jul 2014 00:16:13 +0200 Subject: JEP: Extending generics to support primitive type arguments In-Reply-To: <53BB10EC.30607@oracle.com> References: <53A4E2CA.9090603@oracle.com>

<53BACA07.1010208@oracle.com> <53BAE1FE.2080300@oracle.com> <53BB0EB2.3050205@univ-mlv.fr> <53BB10EC.30607@oracle.com> Message-ID: <53BB1C2D.9010304@univ-mlv.fr> 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 >> ), >> >> or the boolean literal |true| or |false| (?3.10.3 >> ), >> >> or a character literal between |'\u0000'| and |'\u007f'| inclusive >> (?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 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 >>>>> > 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 >>>>>> >>>>> > 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! >>>>>> > >>>>>> > >>>>>> >>>>>> >>>>> >> From alex.buckley at oracle.com Mon Jul 7 22:30:25 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 07 Jul 2014 15:30:25 -0700 Subject: JEP: Extending generics to support primitive type arguments In-Reply-To: <53BB1C2D.9010304@univ-mlv.fr> References: <53A4E2CA.9090603@oracle.com>

<53BACA07.1010208@oracle.com> <53BAE1FE.2080300@oracle.com> <53BB0EB2.3050205@univ-mlv.fr> <53BB10EC.30607@oracle.com> <53BB1C2D.9010304@univ-mlv.fr> Message-ID: <53BB1F81.3050103@oracle.com> 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 >>> ), >>> >>> or the boolean literal |true| or |false| (?3.10.3 >>> ), >>> >>> or a character literal between |'\u0000'| and |'\u007f'| inclusive >>> (?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 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 >>>>>> > 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 >>>>>>> >>>>>> > 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! >>>>>>> > >>>>>>> > >>>>>>> >>>>>>> >>>>>> >>> > From forax at univ-mlv.fr Mon Jul 7 23:23:54 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 08 Jul 2014 01:23:54 +0200 Subject: JEP: Extending generics to support primitive type arguments In-Reply-To: <53BB1F81.3050103@oracle.com> References: <53A4E2CA.9090603@oracle.com>

<53BACA07.1010208@oracle.com> <53BAE1FE.2080300@oracle.com> <53BB0EB2.3050205@univ-mlv.fr> <53BB10EC.30607@oracle.com> <53BB1C2D.9010304@univ-mlv.fr> <53BB1F81.3050103@oracle.com> Message-ID: <53BB2C0A.3040809@univ-mlv.fr> 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 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 >>>> ), >>>> >>>> >>>> or the boolean literal |true| or |false| (?3.10.3 >>>> ), >>>> >>>> >>>> or a character literal between |'\u0000'| and |'\u007f'| inclusive >>>> (?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 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 >>>>>>> > 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 >>>>>>>> >>>>>>> > 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! >>>>>>>> > >>>>>>>> > >>>>>>>> >>>>>>>> >>>>>>> >>>> >> From pbenedict at apache.org Tue Jul 8 15:43:18 2014 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 8 Jul 2014 10:43:18 -0500 Subject: JEP: Extending generics to support primitive type arguments Message-ID: Brian, I'll start by saying this field of research is well out of my purview, but hopefully I am communicating something useful at a high-level. In summary, I tend to believe that the specialization of primitives should be done rather transparently and OOP should be the favored paradigm. By that, I mean that T is really an expression for a "value based object" singleton. For example, no matter how many T are referenced, they all refer to the same singleton instance. Existing parametrized classes assume working with T>=Object and continue to do so. My goal, as such, is to take away the problems that would exist if T could be an object or a primitive; I prefer an answer where that dichotomy does not exist. As a happy consequence, the problem of "assignment to null" also goes away since we would continue to deal with an object (or something object-ish) in Java. I start my introducing new specialized singletons primitive wrappers. All the singleton classes are like Enum, in which only the JVM can instantiate them. There is no language or runtime behavior to make your own instance. Notwithstanding the names, let's pretend this: T => T T => T T => T T => T T => T T => T T => T T => T Unlike today's java.lang wrappers, these classes do not contain any instance state. They do not have an internal reference to the "value" they represent. That's because, as singletons often do, the state information is going to be passed around in method calls. Being a "value based object", the only state such a being has is the value itself. So how does the singleton know what value it is operating on? The value is going to be masqueraded as the "this" pointer for instance operations. [I am unsure at this point how the "this" pointer should be encoded. For values <=32 bits, the "this" pointer could be byte/short/int/char itself; otherwise perhaps it could be a pointer into the stack where the value resides. I don't have an answer right now, but I sense the latter should be preferred. For this piece of code: Box box = new Box(100); I don't know how to write the above in bytecode, but Box receives a SingletonInteger through a pointer that leads to the value of "100" -- either directly or through some internal data structure that the JVM knows about. JVM internals are beyond me but I hope you get the point. If anything I said has merit, hopefully all "value based objects" could be represented in the same manner. That is, there is no instantiation, there is no state, and it's all pointer based references to the value. As this is likely to be full of holes, I hope others can contribute and build upon and correct this. Cheers, Paul From pbenedict at apache.org Wed Jul 16 20:45:06 2014 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 16 Jul 2014 15:45:06 -0500 Subject: JEP: Extending generics to support primitive type arguments Message-ID: For anyone reading, the discussion has moved here: http://mail.openjdk.java.net/mailman/listinfo/valhalla-dev Cheers, Paul