From dmytro_sheyko at hotmail.com Thu Jan 3 04:35:32 2008 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Thu, 3 Jan 2008 19:35:32 +0700 Subject: [patch] 6646584 Compound assignment with Byte, Short and Character In-Reply-To: <3362899.51199308554859.JavaMail.Nelson@mail-apac.sun.com> References: <3362899.51199308554859.JavaMail.Nelson@mail-apac.sun.com> Message-ID: Hi, Attached patch that is to fix bug#6646584 Problem description:Javac forbids compound assignment if lhs is of type Byte, Short, Character. In other words following code should be compiled without any error:public class T { public void assignop_Byte(Byte v) { v += 1; // should be ok } public void assignop_Short(Short v) { v += 1; // should be ok } public void assignop_Character(Character v) { v += 1; // should be ok } public void assignop_Integer_long(Integer v) { v += 1L; // should be ok } public void assignop_Integer_double(Integer v) { v += 1.0; // should be ok } public void assignop_byte(byte v) { v += 1; // is ok } public void assignop_short(short v) { v += 1; // is ok } public void assignop_char(char v) { v += 1; // is ok } public void assignop_int_long(int v) { v += 1L; // is ok } public void assignop_int_double(int v) { v += 1.0; // is ok }} _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20080103/6d585eb5/attachment.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 6646584.diff Url: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20080103/6d585eb5/6646584.diff From dmytro_sheyko at hotmail.com Thu Jan 3 05:12:11 2008 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Thu, 3 Jan 2008 20:12:11 +0700 Subject: [patch] 6646584 Compound assignment with Byte, Short and Character In-Reply-To: <2ABC0102-05B2-4964-ADDE-A05B0149391E@gmail.com> References: <3362899.51199308554859.JavaMail.Nelson@mail-apac.sun.com> <2ABC0102-05B2-4964-ADDE-A05B0149391E@gmail.com> Message-ID: Sure, http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6646584 From: peter.ahe at gmail.comTo: dmytro_sheyko at hotmail.comSubject: Re: [patch] 6646584 Compound assignment with Byte, Short and CharacterDate: Thu, 3 Jan 2008 13:57:52 +0100CC: compiler-dev at openjdk.java.net I cannot access the bug report. Could someone provide a link? Cheers, Peter Sent from my iPhone On Jan 3, 2008, at 13:35, Dmytro Sheyko wrote: Hi, Attached patch that is to fix bug#6646584 Problem description:Javac forbids compound assignment if lhs is of type Byte, Short, Character. _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20080103/33df9218/attachment.html From peter at ahe.dk Thu Jan 3 06:22:53 2008 From: peter at ahe.dk (=?ISO-8859-1?Q?Peter_Ah=E9?=) Date: Thu, 3 Jan 2008 15:22:53 +0100 Subject: [patch] 6646584 Compound assignment with Byte, Short and Character In-Reply-To: References: <3362899.51199308554859.JavaMail.Nelson@mail-apac.sun.com> <2ABC0102-05B2-4964-ADDE-A05B0149391E@gmail.com> Message-ID: It is not a bug. See http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.26.2 and http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#5.1.7 . There is no unboxing conversion from int to, for example, Short. I think this is deliberate, as it would require a narrowing primitive conversion from int to short and a possible loss of information. See: http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#5.1.3 See also: http://blogs.sun.com/ahe/entry/contributing_to_javac Cheers, Peter On Jan 3, 2008, at 2:12 PM, Dmytro Sheyko wrote: > Sure, > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6646584 > > From: peter.ahe at gmail.com > To: dmytro_sheyko at hotmail.com > Subject: Re: [patch] 6646584 Compound assignment with Byte, Short > and Character > Date: Thu, 3 Jan 2008 13:57:52 +0100 > CC: compiler-dev at openjdk.java.net > > I cannot access the bug report. Could someone provide a link? > > Cheers, > Peter > > Sent from my iPhone > > On Jan 3, 2008, at 13:35, Dmytro Sheyko > wrote: > > Hi, > > Attached patch that is to fix bug#6646584 > > Problem description: > Javac forbids compound assignment if lhs is of type Byte, Short, > Character. > > Express yourself instantly with MSN Messenger! MSN Messenger From dmytro_sheyko at hotmail.com Thu Jan 3 07:39:39 2008 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Thu, 3 Jan 2008 22:39:39 +0700 Subject: [patch] 6646584 Compound assignment with Byte, Short and Character In-Reply-To: References: <3362899.51199308554859.JavaMail.Nelson@mail-apac.sun.com> <2ABC0102-05B2-4964-ADDE-A05B0149391E@gmail.com> Message-ID: Well... Is there any reason to reject following statement B += 1; where 'B' is a variable of wrapper type 'java.lang.Byte' and accept in the same time following statements b += 1; ++B; where 'b' a variable of primitive type 'int'? Of course, besides that it is implied by JLS. I don't think that JLS was written so as intentionally reject compound assignments with some wrapper types. And current behavior seems inconsistent for me.If you like, this is RFE to JLS rather than bug in javac. > CC: compiler-dev at openjdk.java.net> From: peter at ahe.dk> To: dmytro_sheyko at hotmail.com> Subject: Re: [patch] 6646584 Compound assignment with Byte, Short and Character> Date: Thu, 3 Jan 2008 15:22:53 +0100> > It is not a bug. See http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.26.2 > and http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#5.1.7 > . There is no unboxing conversion from int to, for example, Short. I > think this is deliberate, as it would require a narrowing primitive > conversion from int to short and a possible loss of information. See: http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#5.1.3> > See also: http://blogs.sun.com/ahe/entry/contributing_to_javac> > Cheers,> Peter> > On Jan 3, 2008, at 2:12 PM, Dmytro Sheyko wrote:> > > Sure,> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6646584> >> > From: peter.ahe at gmail.com> > To: dmytro_sheyko at hotmail.com> > Subject: Re: [patch] 6646584 Compound assignment with Byte, Short > > and Character> > Date: Thu, 3 Jan 2008 13:57:52 +0100> > CC: compiler-dev at openjdk.java.net> >> > I cannot access the bug report. Could someone provide a link?> >> > Cheers,> > Peter> >> > Sent from my iPhone> >> > On Jan 3, 2008, at 13:35, Dmytro Sheyko > > wrote:> >> > Hi,> >> > Attached patch that is to fix bug#6646584> >> > Problem description:> > Javac forbids compound assignment if lhs is of type Byte, Short, > > Character.> >> > Express yourself instantly with MSN Messenger! MSN Messenger> _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20080103/b028c713/attachment.html From forax at univ-mlv.fr Thu Jan 3 07:54:12 2008 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 03 Jan 2008 16:54:12 +0100 Subject: [patch] 6646584 Compound assignment with Byte, Short and Character In-Reply-To: References: <3362899.51199308554859.JavaMail.Nelson@mail-apac.sun.com> <2ABC0102-05B2-4964-ADDE-A05B0149391E@gmail.com> Message-ID: <477D0524.1070501@univ-mlv.fr> Dmytro Sheyko a ?crit : > Well... > > Is there any reason to reject following statement > > B += 1; > > where 'B' is a variable of wrapper type 'java.lang.Byte' and accept in > the same time following statements > > b += 1; > ++B; > > where 'b' a variable of primitive type 'int'? Of course, besides that > it is implied by JLS. I don't think that JLS was written so as > intentionally reject compound assignments with some wrapper types. And > current behavior seems inconsistent for me. > > If you like, this is RFE to JLS rather than bug in javac. yes, for me it's a bug of the JLS3. R?mi From Alex.Buckley at Sun.COM Mon Jan 7 14:39:09 2008 From: Alex.Buckley at Sun.COM (Alex Buckley) Date: Mon, 07 Jan 2008 14:39:09 -0800 Subject: [patch] 6646584 Compound assignment with Byte, Short and Character In-Reply-To: <477D0524.1070501@univ-mlv.fr> References: <3362899.51199308554859.JavaMail.Nelson@mail-apac.sun.com> <2ABC0102-05B2-4964-ADDE-A05B0149391E@gmail.com> <477D0524.1070501@univ-mlv.fr> Message-ID: <4782AA0D.4000006@Sun.COM> There is already an RFE filed against the spec to allow these compound assignments. Please see http://bugs.sun.com/view_bug.do?bug_id=5009476 which I have updated with an evaluation of why it might (or might not) be a good idea. Alex Spec Lead, Java Language & VM R?mi Forax wrote: > Dmytro Sheyko a ?crit : >> Well... >> >> Is there any reason to reject following statement >> >> B += 1; >> >> where 'B' is a variable of wrapper type 'java.lang.Byte' and accept in >> the same time following statements >> >> b += 1; >> ++B; >> >> where 'b' a variable of primitive type 'int'? Of course, besides that >> it is implied by JLS. I don't think that JLS was written so as >> intentionally reject compound assignments with some wrapper types. And >> current behavior seems inconsistent for me. >> >> If you like, this is RFE to JLS rather than bug in javac. > yes, for me it's a bug of the JLS3. > > R?mi From forax at univ-mlv.fr Mon Jan 7 15:19:09 2008 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 08 Jan 2008 00:19:09 +0100 Subject: [patch] 6646584 Compound assignment with Byte, Short and Character In-Reply-To: <4782AA0D.4000006@Sun.COM> References: <3362899.51199308554859.JavaMail.Nelson@mail-apac.sun.com> <2ABC0102-05B2-4964-ADDE-A05B0149391E@gmail.com> <477D0524.1070501@univ-mlv.fr> <4782AA0D.4000006@Sun.COM> Message-ID: <4782B36D.7000607@univ-mlv.fr> Alex Buckley a ?crit : > There is already an RFE filed against the spec to allow these compound > assignments. Please see http://bugs.sun.com/view_bug.do?bug_id=5009476 > which I have updated with an evaluation of why it might (or might not) > be a good idea. alex wrote: >The question is: do you think a compound assignment to a wrapper should behave like a compound assignment to a primitive, >even if both may lose information ? yes > Alternatively: given that we already have information-losing compound assignments, >should we allow more? no >Since this issue unquestionably creates developer confusion, >I have some sympathy with aligning compound primitive and wrapper assignments by expanding casting conversion >to allow int->Byte/Short/Character. Sorry, i am confused. Do you want to expand casting convertion for all conversions or only for compound assignment to a wrapper ? In my opinion, the first JLS allows b+=1, i think retrospectively that it was a mistake. Now, we have to live with that. Tiger introduces auto-boxing/unboxing, to avoid surprises and puzzlers, wrappers should behave like primitives as much as possible. So I am strongly in favor of allowing B+=1 but I am against creating new holes by allowing int->Byte/Short/Character anywhere. > > Alex > Spec Lead, Java Language & VM R?mi From Alex.Buckley at Sun.COM Mon Jan 7 18:37:26 2008 From: Alex.Buckley at Sun.COM (Alex Buckley) Date: Mon, 07 Jan 2008 18:37:26 -0800 Subject: [patch] 6646584 Compound assignment with Byte, Short and Character In-Reply-To: <4782B36D.7000607@univ-mlv.fr> References: <3362899.51199308554859.JavaMail.Nelson@mail-apac.sun.com> <2ABC0102-05B2-4964-ADDE-A05B0149391E@gmail.com> <477D0524.1070501@univ-mlv.fr> <4782AA0D.4000006@Sun.COM> <4782B36D.7000607@univ-mlv.fr> Message-ID: <4782E1E6.7090306@Sun.COM> Hi R?mi, I've updated the evaluation of 5009476 to propose changing the definition of compound assignment in some cases, rather than a global change in casting conversion. This will be visible on bugs.sun.com within 24 hours, I guess. Please direct further comments about the JLS changes to the bugs.sun.com page, rather than compiler-dev. Alex R?mi Forax wrote: > Alex Buckley a ?crit : >> There is already an RFE filed against the spec to allow these compound >> assignments. Please see http://bugs.sun.com/view_bug.do?bug_id=5009476 >> which I have updated with an evaluation of why it might (or might not) >> be a good idea. > alex wrote: > >> The question is: do you think a compound assignment to a wrapper >> should behave like a compound assignment to a primitive, >> even if both may lose information ? > > yes > >> Alternatively: given that we already have information-losing compound >> assignments, >> should we allow more? > > no > >> Since this issue unquestionably creates developer confusion, >> I have some sympathy with aligning compound primitive and wrapper >> assignments by expanding casting conversion >> to allow int->Byte/Short/Character. > > Sorry, i am confused. > Do you want to expand casting convertion for all conversions or only for > compound assignment to a wrapper ? > > In my opinion, the first JLS allows b+=1, i think retrospectively that > it was a mistake. > Now, we have to live with that. Tiger introduces auto-boxing/unboxing, > to avoid surprises > and puzzlers, wrappers should behave like primitives as much as possible. > > So I am strongly in favor of allowing B+=1 but I am against creating > new holes > by allowing int->Byte/Short/Character anywhere. > > >> >> Alex >> Spec Lead, Java Language & VM > R?mi From dmytro_sheyko at hotmail.com Wed Jan 9 23:14:05 2008 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Thu, 10 Jan 2008 14:14:05 +0700 Subject: [patch] 6646584 Compound assignment with Byte, Short and Character In-Reply-To: <4782E1E6.7090306@Sun.COM> References: <3362899.51199308554859.JavaMail.Nelson@mail-apac.sun.com> <2ABC0102-05B2-4964-ADDE-A05B0149391E@gmail.com> <477D0524.1070501@univ-mlv.fr> <4782AA0D.4000006@Sun.COM> <4782B36D.7000607@univ-mlv.fr> <4782E1E6.7090306@Sun.COM> Message-ID: Hi, Can patches that require specification change be applied to KSL? _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20080110/b992ec97/attachment.html From michaelbailey0 at gmail.com Wed Jan 30 14:51:24 2008 From: michaelbailey0 at gmail.com (Michael Bailey) Date: Wed, 30 Jan 2008 14:51:24 -0800 Subject: [PATCH] 4741726: allow Object += String Message-ID: <3a07d78d0801301451n676109dfp2729490dbae93d0@mail.gmail.com> This is a patch to address a change from JLS 2 to JLS 3 in section 15.26.2 where this statement was removed: "All compound assignment operators require both operands to be of primitive type, except for +=, which allows the right-hand operand to be of any type if the left-hand operand is of type String." Object x = "Hi "; String i = " world"; x += i; // This should compile under JLS3 Neal Gafter pointed out the spec change and Alex Buckley confirmed that it was a javac bug. Attached is a patch that removes the corresponding check. There should probably be a test put into the TCK. Michael Bailey -------------- next part -------------- A non-text attachment was scrubbed... Name: javac.patch Type: text/x-patch Size: 1320 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20080130/3e0c8cde/javac.patch