From kelly.ohair at oracle.com Thu Sep 1 09:43:31 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 1 Sep 2011 09:43:31 -0700 Subject: Request to backport 2 Kerberos related fixes In-Reply-To: <20110901161737.GB17640@redhat.com> References: <20110810205921.GD20852@redhat.com> <3E1EF457-D1C9-4705-96C9-F078E923CFC9@oracle.com> <221E2566-525E-4516-95F1-22987979AB9E@oracle.com> <20110825220557.GF9583@rivendell.middle-earth.co.uk> <4E56FB9F.8080501@oracle.com> <20110826140949.GD714@redhat.com> <20110831204122.GI14689@redhat.com> <4E5ED322.5060705@oracle.com> <20110901161737.GB17640@redhat.com> Message-ID: <0ECC0F71-D792-4789-A85F-527CA4D3573F@oracle.com> On Sep 1, 2011, at 9:17 AM, Deepak Bhole wrote: > * Weijun Wang [2011-08-31 20:39]: >> FYI: I've asked the sustaining team to backport 6815182 to Oracle >> Java SE 6 update releases, so this is not a blocker anymore. >> >> Note: I'm not the one who can approve anything here. >> > > Ah, sorry, I thought you had to approve it. I guess it falls back to > Kelly.. > > Kelly, given Weijun's comments, are these okay for push? Yes. Approved. -kto > > Thanks, > Deepak > From kelly.ohair at oracle.com Thu Sep 1 10:18:00 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 1 Sep 2011 10:18:00 -0700 Subject: DRAFT - Approval Template Message-ID: I liked Dalibor's JDK7 Update approval template at http://openjdk.java.net/projects/jdk7u/approval-template.html For OpenJDK6 What I was thinking was: -------- DRAFT ---------- OpenJDK 6: Push Approval Request Template Push requests for OpenJDK 6 Project forest (http://hg.openjdk.java.net/jdk6/jdk6) SHOULD be sent to jdk6-dev at openjdk.java.net and follow this template: Subject: OpenJDK6 Request for approval for CR $NR - $Synopsis With the body of the email containing: * if the change applies to JDK 7, it needs to have been integrated into the JDK 7 Update repositories first. Refer to http://openjdk.java.net/projects/jdk7u/ for JDK 7 Update procedures. * if the change applies to the Oracle JDK 6 Update releases, include any information you have with regards to whether it was fixed in any JDK 6 Update release, or not. Recommendations on whether the change should or should not be included in a JDK 6 Update release can help the Oracle Sustaining team. * either a link to the publicly visible bug/CR on the bugs.sun.com site (or its equivalent), or a description of the change so a bug/CR can be created. * either a link to the publicly visible webrev or a link to the JDK 7 (or JDK 7 Update) changeset, in case it's the the same patch. If the review is taking place somewhere else, a link to the public review thread * if the fix has been reviewed the list of reviewers --------------------------- Let me know what you think. -kto -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20110901/30bf88dd/attachment.html From jonathan.gibbons at oracle.com Thu Sep 1 10:47:55 2011 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 01 Sep 2011 10:47:55 -0700 Subject: DRAFT - Approval Template In-Reply-To: References: Message-ID: <4E5FC54B.7070301@oracle.com> All these mail-based solutions are a pain to keep track of. I hope we get an issue tracking system some time, any time, that handles the approval process semi-automatically. -- Jon On 09/01/2011 10:18 AM, Kelly O'Hair wrote: > > I liked Dalibor's JDK7 Update approval template at > http://openjdk.java.net/projects/jdk7u/approval-template.html > > For OpenJDK6 What I was thinking was: > > -------- DRAFT ---------- > > OpenJDK 6: Push Approval Request Template > > Push requests for OpenJDK 6 Project forest > (http://hg.openjdk.java.net/jdk6/jdk6) > SHOULD be sent to jdk6-dev at openjdk.java.net > and follow this template: > > > Subject: OpenJDK6 Request for approval for CR $NR - $Synopsis > > With the body of the email containing: > > * if the change applies to JDK 7, it needs to have been integrated > into the JDK 7 > Update repositories first. > Refer to http://openjdk.java.net/projects/jdk7u/ for JDK 7 Update > procedures. > > * if the change applies to the Oracle JDK 6 Update releases, include > any information > you have with regards to whether it was fixed in any JDK 6 Update > release, or not. > Recommendations on whether the change should or should not be > included in a > JDK 6 Update release can help the Oracle Sustaining team. > > * either a link to the publicly visible bug/CR on the bugs.sun.com > site > (or its equivalent), or a description of the change so a bug/CR > can be created. > * either a link to the publicly visible webrev or a link to the JDK > 7 (or JDK 7 Update) > changeset, in case it's the the same patch. > If the review is taking place somewhere else, a link to the public > review thread > > * if the fix has been reviewed the list of reviewers > > --------------------------- > > Let me know what you think. > > -kto -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20110901/08df54fd/attachment.html From eric.l.2046 at gmail.com Thu Sep 1 12:12:27 2011 From: eric.l.2046 at gmail.com (Eric Liang) Date: Fri, 02 Sep 2011 03:12:27 +0800 Subject: Maybe codec bug in MS1252, i.e., encoding Cp1252 Message-ID: <4E5FD91B.3040103@gmail.com> Hi all, I've recently got an encoding error while using Cp1252 with UTF-8, the string converted from UTF-8 to Cp1252 can not be converted back: String name1 = new String( new String("??").getBytes("UTF-8"), "Cp1252"); String name2 = new String( name1.getBytes("Cp1252"), "UTF-8"); It looks like that there are some incorrect codes in jdk on encoding Cp1252, and the related codes are: 0x83 0x0192 ;Latin Small Letter F With Hook 0x8d 0x008d 0x8f 0x008f 0x90 0x0090 0x9d 0x009d ( from the Cp1252->UTF-8 map in http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1252.txt ) After I cloned the repository in http://hg.openjdk.java.net/jdk6/jdk6 and fix these codes in MS1252.java, the encoding error has gone. I guess this is the right place to discuss this problem, and the patch is in the attachment. Anyone with any comment is appreciated. Regards, Eric -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCM/CS/E/MU/P d+(-) s: a- C++ UL$ P+>++ L++ E++ W++ N+ o+>++ K+++ w !O M-(+) V-- PS+ PE+ Y+ PGP++ t? 5? X? R+>* tv@ b++++ DI-- D G++ e++>+++@ h* r !y+ ------END GEEK CODE BLOCK------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20110902/834fbece/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: codec_bug_on_MS1252.diff Type: text/x-patch Size: 2327 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20110902/834fbece/attachment.bin From xueming.shen at oracle.com Thu Sep 1 13:04:54 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 01 Sep 2011 13:04:54 -0700 Subject: Maybe codec bug in MS1252, i.e., encoding Cp1252 In-Reply-To: <4E5FD91B.3040103@gmail.com> References: <4E5FD91B.3040103@gmail.com> Message-ID: <4E5FE566.8070108@oracle.com> Hi, These 5 code points are "undefined" character in Cp1252. The first one should be 0x81 not 0x83, since 0x83<->u_0192 is defined and works correctly in Cp1252 charset). The mapping table you referred to is "bestfit" type mapping table, in which it tries to provide the mapping between the local encoding and the Unicode character set for those characters not even exist in the local encoding. Personally I don't think it's a good idea in most use scenario. All other official (from Microsoft) or un-official mapping tables clearly mark these code points "undefined" or "unused", for example http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1252.TXT http://en.wikipedia.org/wiki/Windows-1252 http://msdn.microsoft.com/en-us/library/cc195054.aspx btw, code below is incorrect, or it does not work the way you might expect. String name1 = new String( new String("??").getBytes("UTF-8"), "Cp1252"); String name2 = new String( name1.getBytes("Cp1252"), "UTF-8"); new String("??").getBytes("UTF-8") encodes your 2 Chinese character from UTF-16 to UTF-8 bytes. It does not makes sense to then decode these UTF-8 bytes back to UTF-16 (which the String object uses) by using Cp1252 charset. same for the second attempt. What did you try to achieve? decode/encode between UTF-8 bytes and CP1252 bytes? It's not going to be a round-trip conversion for those non-ASCII characters. -Sherman On 09/01/2011 12:12 PM, Eric Liang wrote: > Hi all, > I've recently got an encoding error while using Cp1252 with UTF-8, the > string converted from UTF-8 to Cp1252 can not be converted back: > > String name1 = new String( new String("??").getBytes("UTF-8"), > "Cp1252"); > String name2 = new String( name1.getBytes("Cp1252"), "UTF-8"); > > It looks like that there are some incorrect codes in jdk on encoding > Cp1252, and the related codes are: > > 0x83 0x0192 ;Latin Small Letter F With Hook > 0x8d 0x008d > 0x8f 0x008f > 0x90 0x0090 > 0x9d 0x009d > > ( from the Cp1252->UTF-8 map in > http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1252.txt > ) > > After I cloned the repository in http://hg.openjdk.java.net/jdk6/jdk6 > and fix these codes in MS1252.java, the encoding error has gone. > > I guess this is the right place to discuss this problem, and the patch > is in the attachment. Anyone with any comment is appreciated. > > Regards, > Eric > -- > -----BEGIN GEEK CODE BLOCK----- > Version: 3.1 > GCM/CS/E/MU/P d+(-) s: a- C++ UL$ P+>++ L++ E++ W++ N+ o+>++ K+++ w !O > M-(+) V-- PS+ PE+ Y+ PGP++ t? 5? X? R+>* tv@ b++++ DI-- D G++ e++>+++@ h* > r !y+ > ------END GEEK CODE BLOCK------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20110901/f8260185/attachment.html From kelly.ohair at oracle.com Thu Sep 1 13:22:00 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 1 Sep 2011 13:22:00 -0700 Subject: DRAFT - Approval Template In-Reply-To: <4E5FC54B.7070301@oracle.com> References: <4E5FC54B.7070301@oracle.com> Message-ID: <23ADF2DB-C9BA-43B0-BC6C-545BB4860038@oracle.com> I agree... someday we will. -kto On Sep 1, 2011, at 10:47 AM, Jonathan Gibbons wrote: > All these mail-based solutions are a pain to keep track of. I hope we get an issue tracking system some time, any time, that handles the approval process semi-automatically. > > -- Jon > > > On 09/01/2011 10:18 AM, Kelly O'Hair wrote: >> >> >> I liked Dalibor's JDK7 Update approval template at http://openjdk.java.net/projects/jdk7u/approval-template.html >> >> For OpenJDK6 What I was thinking was: >> >> -------- DRAFT ---------- >> >> OpenJDK 6: Push Approval Request Template >> >> Push requests for OpenJDK 6 Project forest (http://hg.openjdk.java.net/jdk6/jdk6) >> SHOULD be sent to jdk6-dev at openjdk.java.net and follow this template: >> >> >> Subject: OpenJDK6 Request for approval for CR $NR - $Synopsis >> >> With the body of the email containing: >> >> * if the change applies to JDK 7, it needs to have been integrated into the JDK 7 >> Update repositories first. >> Refer to http://openjdk.java.net/projects/jdk7u/ for JDK 7 Update procedures. >> >> * if the change applies to the Oracle JDK 6 Update releases, include any information >> you have with regards to whether it was fixed in any JDK 6 Update release, or not. >> Recommendations on whether the change should or should not be included in a >> JDK 6 Update release can help the Oracle Sustaining team. >> >> * either a link to the publicly visible bug/CR on the bugs.sun.com site >> (or its equivalent), or a description of the change so a bug/CR can be created. >> >> * either a link to the publicly visible webrev or a link to the JDK 7 (or JDK 7 Update) >> changeset, in case it's the the same patch. >> If the review is taking place somewhere else, a link to the public review thread >> >> * if the fix has been reviewed the list of reviewers >> >> --------------------------- >> >> Let me know what you think. >> >> -kto > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20110901/b7718b17/attachment.html From dbhole at redhat.com Thu Sep 1 09:17:37 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Thu, 1 Sep 2011 12:17:37 -0400 Subject: Request to backport 2 Kerberos related fixes In-Reply-To: <4E5ED322.5060705@oracle.com> References: <20110810205921.GD20852@redhat.com> <3E1EF457-D1C9-4705-96C9-F078E923CFC9@oracle.com> <221E2566-525E-4516-95F1-22987979AB9E@oracle.com> <20110825220557.GF9583@rivendell.middle-earth.co.uk> <4E56FB9F.8080501@oracle.com> <20110826140949.GD714@redhat.com> <20110831204122.GI14689@redhat.com> <4E5ED322.5060705@oracle.com> Message-ID: <20110901161737.GB17640@redhat.com> * Weijun Wang [2011-08-31 20:39]: > FYI: I've asked the sustaining team to backport 6815182 to Oracle > Java SE 6 update releases, so this is not a blocker anymore. > > Note: I'm not the one who can approve anything here. > Ah, sorry, I thought you had to approve it. I guess it falls back to Kelly.. Kelly, given Weijun's comments, are these okay for push? Thanks, Deepak From kelly.ohair at oracle.com Thu Sep 1 16:38:09 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 1 Sep 2011 16:38:09 -0700 Subject: Request to backport 2 Kerberos related fixes In-Reply-To: <20110810205921.GD20852@redhat.com> References: <20110810205921.GD20852@redhat.com> Message-ID: Just to clarify, both of these are approved for push to OpenJDK6. -kto On Aug 10, 2011, at 1:59 PM, Deepak Bhole wrote: > Hi, > > I would like to backport the following fixes from OpenJDK7 to OpenJDK6: > > -- > > 6815182: GSSAPI/SPNEGO does not work with server using MIT Kerberos library > > http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/9d5cce463fa0 > > changeset: 949:9d5cce463fa0 > user: weijun > date: Fri Mar 13 09:20:56 2009 +0800 > summary: 6815182: GSSAPI/SPNEGO does not work with server using MIT > Kerberos library > > -- > > 6979329: CCacheInputStream fails to read ticket cache files from Kerberos 1.8.1: > > http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/c1734c00a8ba > > changeset: 3122:c1734c00a8ba > user: weijun > date: Mon Nov 22 09:43:58 2010 +0800 > summary: 6979329: CCacheInputStream fails to read ticket cache files > from Kerberos 1.8.1 > > -- > > I had to update the copyright headers to apply it correctly. Updated > webrevs: > http://cr.openjdk.java.net/~dbhole/6815182-JDK6.00/ > http://cr.openjdk.java.net/~dbhole/6979329-JDK6.00/ > > Okay to push? > > Cheers, > Deepak From aph at redhat.com Fri Sep 2 02:04:10 2011 From: aph at redhat.com (Andrew Haley) Date: Fri, 02 Sep 2011 10:04:10 +0100 Subject: DRAFT - Approval Template In-Reply-To: <4E5FC54B.7070301@oracle.com> References: <4E5FC54B.7070301@oracle.com> Message-ID: <4E609C0A.8010003@redhat.com> On 09/01/2011 06:47 PM, Jonathan Gibbons wrote: > All these mail-based solutions are a pain to keep track of. I hope we > get an issue tracking system some time, any time, that handles the > approval process semi-automatically. Yabbut: mail is universal, gets mirrored, is easily searchable by Google, and so on. As long as the information about patch approvals is at least copied to a mailing list, that'll do. Andrew. From eric.l.2046 at gmail.com Fri Sep 2 02:14:51 2011 From: eric.l.2046 at gmail.com (Eric Liang) Date: Fri, 02 Sep 2011 17:14:51 +0800 Subject: Maybe codec bug in MS1252, i.e., encoding Cp1252 In-Reply-To: <4E5FE566.8070108@oracle.com> References: <4E5FD91B.3040103@gmail.com> <4E5FE566.8070108@oracle.com> Message-ID: <4E609E8B.4090404@gmail.com> On 09/02/2011 04:04 AM, Xueming Shen wrote: > Hi, > > These 5 code points are "undefined" character in Cp1252. The first one > should be 0x81 not 0x83, since 0x83<->u_0192 is defined and works > correctly in Cp1252 charset). The mapping table you referred to is > "bestfit" type mapping table, in which it tries to provide the mapping > between the local encoding and the Unicode character set for those > characters not even exist in the local encoding. Personally I don't think > it's a good idea in most use scenario. All other official (from Microsoft) > or un-official mapping tables clearly mark these code points "undefined" > or "unused", for example > > http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1252.TXT > http://en.wikipedia.org/wiki/Windows-1252 > http://msdn.microsoft.com/en-us/library/cc195054.aspx > > btw, code below is incorrect, or it does not work the way you might > expect. > > String name1 = new String( new String("??").getBytes("UTF-8"), > "Cp1252"); > String name2 = new String( name1.getBytes("Cp1252"), "UTF-8"); > > new String("??").getBytes("UTF-8") encodes your 2 Chinese character from > UTF-16 to UTF-8 bytes. It does not makes sense to then decode these UTF-8 > bytes back to UTF-16 (which the String object uses) by using Cp1252 > charset. > > same for the second attempt. > > What did you try to achieve? decode/encode between UTF-8 bytes and CP1252 > bytes? It's not going to be a round-trip conversion for those > non-ASCII characters. Thanks Sherman for your explanation. The problem occured when I was using JDBC with MySQL. The former application has stored the utf8 data to a default configured database ( with encoding is latin1 ), and get the data and decode in PHP is OK. But I failed in java when reading the data. From the document( http://dev.mysql.com/doc/refman/5.5/en/connector-j-reference-charsets.html ), latin1 in MySQL corresponds with Cp1252 in JAVA, so I found the cause, and I deem the guy here also encountered this problem ( http://forums.mysql.com/read.php?39,228068,228068#msg-228068 ). As since the data in latin1(in java) can be converted to utf8 freely and vice versa. From the wikipedia Cp1252 is treated as a superset a ISO_8859-1, so I guess the same expectation on Cp1252 as latin1 is something natural, though it does not work now. However, YMMV, would you mind give some suggestions on this? Thanks in advance. Eric -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCM/CS/E/MU/P d+(-) s: a- C++ UL$ P+>++ L++ E++ W++ N+ o+>++ K+++ w !O M-(+) V-- PS+ PE+ Y+ PGP++ t? 5? X? R+>* tv@ b++++ DI-- D G++ e++>+++@ h* r !y+ ------END GEEK CODE BLOCK------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20110902/d75d3e0e/attachment.html From xueming.shen at oracle.com Fri Sep 2 12:50:27 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 02 Sep 2011 12:50:27 -0700 Subject: Maybe codec bug in MS1252, i.e., encoding Cp1252 In-Reply-To: <4E609E8B.4090404@gmail.com> References: <4E5FD91B.3040103@gmail.com> <4E5FE566.8070108@oracle.com> <4E609E8B.4090404@gmail.com> Message-ID: <4E613383.20202@oracle.com> On 09/02/2011 02:14 AM, Eric Liang wrote: > On 09/02/2011 04:04 AM, Xueming Shen wrote: >> Hi, >> >> These 5 code points are "undefined" character in Cp1252. The first one >> should be 0x81 not 0x83, since 0x83<->u_0192 is defined and works >> correctly in Cp1252 charset). The mapping table you referred to is >> "bestfit" type mapping table, in which it tries to provide the mapping >> between the local encoding and the Unicode character set for those >> characters not even exist in the local encoding. Personally I don't think >> it's a good idea in most use scenario. All other official (from >> Microsoft) >> or un-official mapping tables clearly mark these code points "undefined" >> or "unused", for example >> >> http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1252.TXT >> http://en.wikipedia.org/wiki/Windows-1252 >> http://msdn.microsoft.com/en-us/library/cc195054.aspx >> >> btw, code below is incorrect, or it does not work the way you might >> expect. >> >> String name1 = new String( new String("??").getBytes("UTF-8"), >> "Cp1252"); >> String name2 = new String( name1.getBytes("Cp1252"), "UTF-8"); >> >> new String("??").getBytes("UTF-8") encodes your 2 Chinese character >> from >> UTF-16 to UTF-8 bytes. It does not makes sense to then decode these UTF-8 >> bytes back to UTF-16 (which the String object uses) by using Cp1252 >> charset. >> >> same for the second attempt. >> >> What did you try to achieve? decode/encode between UTF-8 bytes and CP1252 >> bytes? It's not going to be a round-trip conversion for those >> non-ASCII characters. > Thanks Sherman for your explanation. > > The problem occured when I was using JDBC with MySQL. The former > application has stored the utf8 data to a default configured database > ( with encoding is latin1 ), and get the data and decode in PHP is OK. > But I failed in java when reading the data. From the document( > http://dev.mysql.com/doc/refman/5.5/en/connector-j-reference-charsets.html > ), latin1 in MySQL corresponds with Cp1252 in JAVA, so I found the > cause, and I deem the guy here also encountered this problem ( > http://forums.mysql.com/read.php?39,228068,228068#msg-228068 ). > > As since the data in latin1(in java) can be converted to utf8 freely > and vice versa. From the wikipedia Cp1252 is treated as a superset a > ISO_8859-1, so I guess the same expectation on Cp1252 as latin1 is > something natural, though it does not work now. > > However, YMMV, would you mind give some suggestions on this? Thanks > in advance. > > Eric Windows-1252 (cp1252) is a supperset of ISO 8859-1. ISO 8859-1 is normally referred as the latin-1. What we have in Java charset repository is ISO-8859-1. The difference between ISO 8859-1 and ISO-8859-1 (with dash and without dash) is the C0 and C1 control character area. ISO-8859-1 has the C0 and C1 defined, ISO 8859-1 does not. So in your above workaround, you'd better use ISO-8859-1, stead of cp1252. I know little about JDBC + MySQL, so probably not the one to give suggestion on this topic. By simply reading the description of the problem you are facing with, I guess you'd better to set your client side encoding/charset correctly to utf-8 or gbk to receive result in Chinese correctly. -Sherman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20110902/cec4afe6/attachment.html From eric.l.2046 at gmail.com Mon Sep 5 00:56:35 2011 From: eric.l.2046 at gmail.com (Eric Liang) Date: Mon, 05 Sep 2011 15:56:35 +0800 Subject: Maybe codec bug in MS1252, i.e., encoding Cp1252 In-Reply-To: <4E613383.20202@oracle.com> References: <4E5FD91B.3040103@gmail.com> <4E5FE566.8070108@oracle.com> <4E609E8B.4090404@gmail.com> <4E613383.20202@oracle.com> Message-ID: <4E6480B3.9050103@gmail.com> On 09/03/2011 03:50 AM, Xueming Shen wrote: > On 09/02/2011 02:14 AM, Eric Liang wrote: >> On 09/02/2011 04:04 AM, Xueming Shen wrote: >>> Hi, >>> >>> These 5 code points are "undefined" character in Cp1252. The first one >>> should be 0x81 not 0x83, since 0x83<->u_0192 is defined and works >>> correctly in Cp1252 charset). The mapping table you referred to is >>> "bestfit" type mapping table, in which it tries to provide the mapping >>> between the local encoding and the Unicode character set for those >>> characters not even exist in the local encoding. Personally I don't >>> think >>> it's a good idea in most use scenario. All other official (from >>> Microsoft) >>> or un-official mapping tables clearly mark these code points "undefined" >>> or "unused", for example >>> >>> http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1252.TXT >>> http://en.wikipedia.org/wiki/Windows-1252 >>> http://msdn.microsoft.com/en-us/library/cc195054.aspx >>> >>> btw, code below is incorrect, or it does not work the way you >>> might expect. >>> >>> String name1 = new String( new String("??").getBytes("UTF-8"), >>> "Cp1252"); >>> String name2 = new String( name1.getBytes("Cp1252"), "UTF-8"); >>> >>> new String("??").getBytes("UTF-8") encodes your 2 Chinese >>> character from >>> UTF-16 to UTF-8 bytes. It does not makes sense to then decode these >>> UTF-8 >>> bytes back to UTF-16 (which the String object uses) by using Cp1252 >>> charset. >>> >>> same for the second attempt. >>> >>> What did you try to achieve? decode/encode between UTF-8 bytes and >>> CP1252 >>> bytes? It's not going to be a round-trip conversion for those >>> non-ASCII characters. >> Thanks Sherman for your explanation. >> >> The problem occured when I was using JDBC with MySQL. The former >> application has stored the utf8 data to a default configured database >> ( with encoding is latin1 ), and get the data and decode in PHP is >> OK. But I failed in java when reading the data. From the document( >> http://dev.mysql.com/doc/refman/5.5/en/connector-j-reference-charsets.html >> ), latin1 in MySQL corresponds with Cp1252 in JAVA, so I found the >> cause, and I deem the guy here also encountered this problem ( >> http://forums.mysql.com/read.php?39,228068,228068#msg-228068 ). >> >> As since the data in latin1(in java) can be converted to utf8 freely >> and vice versa. From the wikipedia Cp1252 is treated as a superset a >> ISO_8859-1, so I guess the same expectation on Cp1252 as latin1 is >> something natural, though it does not work now. >> >> However, YMMV, would you mind give some suggestions on this? Thanks >> in advance. >> >> Eric > > Windows-1252 (cp1252) is a supperset of ISO 8859-1. ISO 8859-1 is > normally referred as > the latin-1. What we have in Java charset repository is ISO-8859-1. > The difference between > ISO 8859-1 and ISO-8859-1 (with dash and without dash) is the C0 and > C1 control character > area. ISO-8859-1 has the C0 and C1 defined, ISO 8859-1 does not. > > So in your above workaround, you'd better use ISO-8859-1, stead of cp1252. Thank you for your patience. Besides the doc mentioned above, these codes indicates that Cp1252 is a formal choice: String encoding = CharsetMapping.getJavaEncodingForMysqlEncoding("latin1", (com.mysql.jdbc.Connection) conn); System.out.println("Encoding for mysql: "+encoding); And I notice that in class StandardCharsets, there is an alias of latin1 is ISO-8859-1: ht[429] = new Object[] { "latin1", "iso-8859-1" }; However, I do have tried ISO-8859-1, still does not work. > > I know little about JDBC + MySQL, so probably not the one to give > suggestion on this topic. > By simply reading the description of the problem you are facing with, > I guess you'd better > to set your client side encoding/charset correctly to utf-8 or gbk to > receive result in Chinese > correctly. > This was tested for some of my colleagues and I, it is not the right configuration in this case. I'd like to post the test codes If you were interested. And any other suggestions is also appreciated. Thanks, Eric -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCM/CS/E/MU/P d+(-) s: a- C++ UL$ P+>++ L++ E++ W++ N+ o+>++ K+++ w !O M-(+) V-- PS+ PE+ Y+ PGP++ t? 5? X? R+>* tv@ b++++ DI-- D G++ e++>+++@ h* r !y+ ------END GEEK CODE BLOCK------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20110905/0f8a2023/attachment.html From dbhole at redhat.com Tue Sep 6 13:31:15 2011 From: dbhole at redhat.com (dbhole at redhat.com) Date: Tue, 06 Sep 2011 20:31:15 +0000 Subject: hg: jdk6/jdk6/jdk: 2 new changesets Message-ID: <20110906203132.628FB473FE@hg.openjdk.java.net> Changeset: d4f7664a6c3c Author: weijun Date: 2009-03-13 09:20 +0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/d4f7664a6c3c 6815182: GSSAPI/SPNEGO does not work with server using MIT Kerberos library Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/spnego/NegTokenInit.java ! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java + test/sun/security/krb5/auto/SpnegoReqFlags.java Changeset: b139627f7bc3 Author: weijun Date: 2010-11-22 09:43 +0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/b139627f7bc3 6979329: CCacheInputStream fails to read ticket cache files from Kerberos 1.8.1 Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/ccache/CCacheInputStream.java ! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java + test/sun/security/krb5/UnknownCCEntry.java From dbhole at redhat.com Tue Sep 6 13:35:12 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Tue, 6 Sep 2011 16:35:12 -0400 Subject: Request to backport 2 Kerberos related fixes In-Reply-To: References: <20110810205921.GD20852@redhat.com> Message-ID: <20110906203511.GE2344@redhat.com> * Kelly O'Hair [2011-09-01 19:38]: > Just to clarify, both of these are approved for push to OpenJDK6. > Both have been pushed. Thank-you! Deepak From ptisnovs at redhat.com Fri Sep 9 02:02:16 2011 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Fri, 09 Sep 2011 11:02:16 +0200 Subject: Request to backport 5082756: Image I/O plug-ins set metadata boolean attributes to "true" or "false" into OpenJDK6 Message-ID: <4E69D618.4050104@redhat.com> Greetings, I'd like to backport 5082756: Image I/O plug-ins set metadata boolean attributes to "true" or "false" into OpenJDK6 Webrev is here: http://cr.openjdk.java.net/~ptisnovs/5082756/ This change has been tested without problems. Can anybody please review this change & assign bug ID to it? Thank you in advance, Pavel From philip.race at oracle.com Fri Sep 9 09:29:16 2011 From: philip.race at oracle.com (Phil Race) Date: Fri, 09 Sep 2011 09:29:16 -0700 Subject: Request to backport 5082756: Image I/O plug-ins set metadata boolean attributes to "true" or "false" into OpenJDK6 In-Reply-To: <4E69D618.4050104@redhat.com> References: <4E69D618.4050104@redhat.com> Message-ID: <4E6A3EDC.5000208@oracle.com> That was considered to be a specification change, or at least clarification and went through the CCC process for API changes for JDK 7. YOu will notice that you are changing some public API javadoc here. As such I don't think its a good candidate for a backport. -phil. On 9/9/2011 2:02 AM, Pavel Tisnovsky wrote: > Greetings, > > I'd like to backport > 5082756: Image I/O plug-ins set metadata boolean attributes to "true" or "false" > into OpenJDK6 > > Webrev is here: > http://cr.openjdk.java.net/~ptisnovs/5082756/ > > This change has been tested without problems. > > Can anybody please review this change& assign bug ID to it? > > Thank you in advance, > Pavel From ptisnovs at redhat.com Mon Sep 12 00:38:54 2011 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Mon, 12 Sep 2011 09:38:54 +0200 Subject: Request to backport 5082756: Image I/O plug-ins set metadata boolean attributes to "true" or "false" into OpenJDK6 In-Reply-To: <4E6A3EDC.5000208@oracle.com> References: <4E69D618.4050104@redhat.com> <4E6A3EDC.5000208@oracle.com> Message-ID: <4E6DB70E.50305@redhat.com> Hi Phil, thank you for review. I'm preparing several backports to JDK 6, so I'd like to know (to save your and mine time :-) if every backport containing any change in API JavaDoc (even minor clarification etc.) can not be pushed to JDK 6? Cheers, Pavel Phil Race wrote: > That was considered to be a specification change, or at least > clarification and > went through the CCC process for API changes for JDK 7. YOu will notice > that > you are changing some public API javadoc here. As such I don't think its > a good candidate for a backport. > > -phil. > > On 9/9/2011 2:02 AM, Pavel Tisnovsky wrote: >> Greetings, >> >> I'd like to backport >> 5082756: Image I/O plug-ins set metadata boolean attributes to "true" >> or "false" >> into OpenJDK6 >> >> Webrev is here: >> http://cr.openjdk.java.net/~ptisnovs/5082756/ >> >> This change has been tested without problems. >> >> Can anybody please review this change& assign bug ID to it? >> >> Thank you in advance, >> Pavel > From ptisnovs at redhat.com Mon Sep 12 01:25:12 2011 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Mon, 12 Sep 2011 10:25:12 +0200 Subject: Request to backport "6296893: BMP Writer handles TopDown property incorrectly,for some of the compression types" into OpenJDK6 Message-ID: <4E6DC1E8.3080205@redhat.com> Greetings, I'd like to backport the following change: "6296893: BMP Writer handles TopDown property incorrectly for some of the compression types" into OpenJDK6 Webrev is available here: http://cr.openjdk.java.net/~ptisnovs/6296893/ This change has been tested without problems (including the new regression test included in this backport). Can anybody please review this change & assign bug ID to it? Thank you in advance, Pavel From joe.darcy at oracle.com Mon Sep 12 06:12:25 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 12 Sep 2011 06:12:25 -0700 Subject: Request to backport 5082756: Image I/O plug-ins set metadata boolean attributes to "true" or "false" into OpenJDK6 In-Reply-To: <4E6DB70E.50305@redhat.com> References: <4E69D618.4050104@redhat.com> <4E6A3EDC.5000208@oracle.com> <4E6DB70E.50305@redhat.com> Message-ID: <4E6E0539.3070809@oracle.com> Hi Pavel. This topic is addressed in the process discussion on the OpenJDK 6 project page: "As an implementation of the Java SE 6 specification, all changes to OpenJDK 6 must be allowable within that specification. This requirement precludes many API changes. Acceptable API changes include those permitted by the endorsed standards mechanism, such as upgrading to a newer version of a standalone technology, like a component JSR. One example of such an API change was the upgrade of JAX-WS from 2.0 to 2.1 in OpenJDK 6 build b06. Changes allowable within the Java SE 6 specification may still be rejected for inclusion in OpenJDK 6 if the behavioral compatibility risk is judged as too large. Behavioral compatibility concerns implementation properties of the JDK. Clients of the JDK can knowingly or unknowingly come to rely upon implementation-specification behaviors not guaranteed by the specification and care should be taken to not break such applications needlessly. In contrast, if a change is appropriate for every other JDK release train, it is generally appropriate for OpenJDK 6 too. Examples of such universal changes include security fixes and time zone information updates." http://openjdk.java.net/projects/jdk6/ -Joe Pavel Tisnovsky wrote: > Hi Phil, > > thank you for review. I'm preparing several backports to JDK 6, so I'd like to > know (to save your and mine time :-) if every backport containing any change in > API JavaDoc (even minor clarification etc.) can not be pushed to JDK 6? > > Cheers, > Pavel > > Phil Race wrote: > >> That was considered to be a specification change, or at least >> clarification and >> went through the CCC process for API changes for JDK 7. YOu will notice >> that >> you are changing some public API javadoc here. As such I don't think its >> a good candidate for a backport. >> >> -phil. >> >> On 9/9/2011 2:02 AM, Pavel Tisnovsky wrote: >> >>> Greetings, >>> >>> I'd like to backport >>> 5082756: Image I/O plug-ins set metadata boolean attributes to "true" >>> or "false" >>> into OpenJDK6 >>> >>> Webrev is here: >>> http://cr.openjdk.java.net/~ptisnovs/5082756/ >>> >>> This change has been tested without problems. >>> >>> Can anybody please review this change& assign bug ID to it? >>> >>> Thank you in advance, >>> Pavel >>> > > From ahughes at redhat.com Mon Sep 12 11:17:39 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Mon, 12 Sep 2011 19:17:39 +0100 Subject: Request to backport 5082756: Image I/O plug-ins set metadata boolean attributes to "true" or "false" into OpenJDK6 In-Reply-To: <4E69D618.4050104@redhat.com> References: <4E69D618.4050104@redhat.com> Message-ID: <20110912181739.GA26666@rivendell.middle-earth.co.uk> On 11:02 Fri 09 Sep , Pavel Tisnovsky wrote: > Greetings, > > I'd like to backport > 5082756: Image I/O plug-ins set metadata boolean attributes to "true" or "false" > into OpenJDK6 > > Webrev is here: > http://cr.openjdk.java.net/~ptisnovs/5082756/ > > This change has been tested without problems. > > Can anybody please review this change & assign bug ID to it? > It doesn't need a bug ID; it already has one. As this was rejected, you should drop it from IcedTea. I don't remember seeing the javadoc update in your IcedTea patch or I'd have rejected it then. > Thank you in advance, > Pavel -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Mon Sep 12 11:24:22 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Mon, 12 Sep 2011 19:24:22 +0100 Subject: Request to backport "6296893: BMP Writer handles TopDown property incorrectly,for some of the compression types" into OpenJDK6 In-Reply-To: <4E6DC1E8.3080205@redhat.com> References: <4E6DC1E8.3080205@redhat.com> Message-ID: <20110912182422.GB26666@rivendell.middle-earth.co.uk> On 10:25 Mon 12 Sep , Pavel Tisnovsky wrote: > Greetings, > > I'd like to backport the following change: > "6296893: BMP Writer handles TopDown property incorrectly > for some of the compression types" into OpenJDK6 > > Webrev is available here: > http://cr.openjdk.java.net/~ptisnovs/6296893/ > > This change has been tested without problems (including the new regression test > included in this backport). > > Can anybody please review this change & assign bug ID to it? > > Thank you in advance, > Pavel You already have a bug ID; 6296893. Can I approve this as an OpenJDK6 reviewer? -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From kelly.ohair at oracle.com Tue Sep 13 11:59:01 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Tue, 13 Sep 2011 11:59:01 -0700 Subject: Request to backport "6296893: BMP Writer handles TopDown property incorrectly, for some of the compression types" into OpenJDK6 In-Reply-To: <20110912182422.GB26666@rivendell.middle-earth.co.uk> References: <4E6DC1E8.3080205@redhat.com> <20110912182422.GB26666@rivendell.middle-earth.co.uk> Message-ID: <0A61BE8A-7178-40A4-B7B3-AAE9C6DA413D@oracle.com> I am scratching my head on this one. I am not an imageio expert, but from what I read I am a bit concerned that people may have found workarounds for this problem, and this change could possibly break their workarounds. I know that sounds silly, but there it is. Is that possible? Can someone assure me that this change is harmless to the current complete jdk6 community? -kto On Sep 12, 2011, at 11:24 AM, Dr Andrew John Hughes wrote: > On 10:25 Mon 12 Sep , Pavel Tisnovsky wrote: >> Greetings, >> >> I'd like to backport the following change: >> "6296893: BMP Writer handles TopDown property incorrectly >> for some of the compression types" into OpenJDK6 >> >> Webrev is available here: >> http://cr.openjdk.java.net/~ptisnovs/6296893/ >> >> This change has been tested without problems (including the new regression test >> included in this backport). >> >> Can anybody please review this change & assign bug ID to it? >> >> Thank you in advance, >> Pavel > > You already have a bug ID; 6296893. > > Can I approve this as an OpenJDK6 reviewer? > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and IcedTea > http://www.gnu.org/software/classpath > http://icedtea.classpath.org > PGP Key: F5862A37 (https://keys.indymedia.org/) > Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From kelly.ohair at oracle.com Tue Sep 13 12:01:04 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Tue, 13 Sep 2011 12:01:04 -0700 Subject: Request to backport 5082756: Image I/O plug-ins set metadata boolean attributes to "true" or "false" into OpenJDK6 In-Reply-To: <4E69D618.4050104@redhat.com> References: <4E69D618.4050104@redhat.com> Message-ID: <2AC4E8B1-E6C6-414D-B7E8-EADD8A826D3E@oracle.com> I see no reason to backport this change. -kto On Sep 9, 2011, at 2:02 AM, Pavel Tisnovsky wrote: > Greetings, > > I'd like to backport > 5082756: Image I/O plug-ins set metadata boolean attributes to "true" or "false" > into OpenJDK6 > > Webrev is here: > http://cr.openjdk.java.net/~ptisnovs/5082756/ > > This change has been tested without problems. > > Can anybody please review this change & assign bug ID to it? > > Thank you in advance, > Pavel From ahughes at redhat.com Tue Sep 13 16:57:46 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Wed, 14 Sep 2011 00:57:46 +0100 Subject: Request to backport "6296893: BMP Writer handles TopDown property incorrectly,for some of the compression types" into OpenJDK6 In-Reply-To: <0A61BE8A-7178-40A4-B7B3-AAE9C6DA413D@oracle.com> References: <4E6DC1E8.3080205@redhat.com> <20110912182422.GB26666@rivendell.middle-earth.co.uk> <0A61BE8A-7178-40A4-B7B3-AAE9C6DA413D@oracle.com> Message-ID: <20110913235746.GC26666@rivendell.middle-earth.co.uk> On 11:59 Tue 13 Sep , Kelly O'Hair wrote: > I am scratching my head on this one. > > I am not an imageio expert, but from what I read I am a bit concerned that people may have found > workarounds for this problem, and this change could possibly break their workarounds. > I know that sounds silly, but there it is. Is that possible? > > Can someone assure me that this change is harmless to the current complete jdk6 community? > People can do all sorts of crazy hacks in their own code. We shouldn't not fix bugs because there's a risk it might break someone's code. If that was true, nothing would ever get done. Besides, given the fix is already in 7, such hacks are going to be broken now anyway. > -kto > > On Sep 12, 2011, at 11:24 AM, Dr Andrew John Hughes wrote: > > > On 10:25 Mon 12 Sep , Pavel Tisnovsky wrote: > >> Greetings, > >> > >> I'd like to backport the following change: > >> "6296893: BMP Writer handles TopDown property incorrectly > >> for some of the compression types" into OpenJDK6 > >> > >> Webrev is available here: > >> http://cr.openjdk.java.net/~ptisnovs/6296893/ > >> > >> This change has been tested without problems (including the new regression test > >> included in this backport). > >> > >> Can anybody please review this change & assign bug ID to it? > >> > >> Thank you in advance, > >> Pavel > > > > You already have a bug ID; 6296893. > > > > Can I approve this as an OpenJDK6 reviewer? > > -- > > Andrew :) > > > > Free Java Software Engineer > > Red Hat, Inc. (http://www.redhat.com) > > > > Support Free Java! > > Contribute to GNU Classpath and IcedTea > > http://www.gnu.org/software/classpath > > http://icedtea.classpath.org > > PGP Key: F5862A37 (https://keys.indymedia.org/) > > Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From kelly.ohair at oracle.com Tue Sep 13 17:33:36 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Tue, 13 Sep 2011 17:33:36 -0700 Subject: Request to backport "6296893: BMP Writer handles TopDown property incorrectly, for some of the compression types" into OpenJDK6 In-Reply-To: <20110913235746.GC26666@rivendell.middle-earth.co.uk> References: <4E6DC1E8.3080205@redhat.com> <20110912182422.GB26666@rivendell.middle-earth.co.uk> <0A61BE8A-7178-40A4-B7B3-AAE9C6DA413D@oracle.com> <20110913235746.GC26666@rivendell.middle-earth.co.uk> Message-ID: On Sep 13, 2011, at 4:57 PM, Dr Andrew John Hughes wrote: > On 11:59 Tue 13 Sep , Kelly O'Hair wrote: >> I am scratching my head on this one. >> >> I am not an imageio expert, but from what I read I am a bit concerned that people may have found >> workarounds for this problem, and this change could possibly break their workarounds. >> I know that sounds silly, but there it is. Is that possible? >> >> Can someone assure me that this change is harmless to the current complete jdk6 community? >> > > People can do all sorts of crazy hacks in their own code. We shouldn't not fix bugs > because there's a risk it might break someone's code. If that was true, nothing would > ever get done. But sometimes, when the bug has been there so long, it becomes a feature. :^( I'm just trying to make sure I don't create another disaster like when we changed the DLL files on Windows to say COMPANY=Oracle, and I broke every Eclipse user on the planet, I still have burnt fingers from that one. :^( > > Besides, given the fix is already in 7, such hacks are going to be broken now anyway. Yes, that is true, but if 7 did break something, that would be less of a surprise than being broken in 6. --- If someone from the imageio area could comment and state that this is a safe change, I will approve it. -kto > >> -kto >> >> On Sep 12, 2011, at 11:24 AM, Dr Andrew John Hughes wrote: >> >>> On 10:25 Mon 12 Sep , Pavel Tisnovsky wrote: >>>> Greetings, >>>> >>>> I'd like to backport the following change: >>>> "6296893: BMP Writer handles TopDown property incorrectly >>>> for some of the compression types" into OpenJDK6 >>>> >>>> Webrev is available here: >>>> http://cr.openjdk.java.net/~ptisnovs/6296893/ >>>> >>>> This change has been tested without problems (including the new regression test >>>> included in this backport). >>>> >>>> Can anybody please review this change & assign bug ID to it? >>>> >>>> Thank you in advance, >>>> Pavel >>> >>> You already have a bug ID; 6296893. >>> >>> Can I approve this as an OpenJDK6 reviewer? >>> -- >>> Andrew :) >>> >>> Free Java Software Engineer >>> Red Hat, Inc. (http://www.redhat.com) >>> >>> Support Free Java! >>> Contribute to GNU Classpath and IcedTea >>> http://www.gnu.org/software/classpath >>> http://icedtea.classpath.org >>> PGP Key: F5862A37 (https://keys.indymedia.org/) >>> Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 >> > > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and IcedTea > http://www.gnu.org/software/classpath > http://icedtea.classpath.org > PGP Key: F5862A37 (https://keys.indymedia.org/) > Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From philip.race at oracle.com Tue Sep 13 17:38:15 2011 From: philip.race at oracle.com (Phil Race) Date: Tue, 13 Sep 2011 17:38:15 -0700 Subject: Request to backport "6296893: BMP Writer handles TopDown property incorrectly,for some of the compression types" into OpenJDK6 In-Reply-To: <20110913235746.GC26666@rivendell.middle-earth.co.uk> References: <4E6DC1E8.3080205@redhat.com> <20110912182422.GB26666@rivendell.middle-earth.co.uk> <0A61BE8A-7178-40A4-B7B3-AAE9C6DA413D@oracle.com> <20110913235746.GC26666@rivendell.middle-earth.co.uk> Message-ID: <4E6FF777.9050702@oracle.com> The backport looks fine and I think it far more likely that without this fix, we'll be writing invalid images, rather than breaking anything people have constructed to work around it .. ie they'd have learn to avoid this. So OK by me to backport but I'm not sure there's a need to continue such backports for much longer when you can get JDK 7 instead. Or maybe this isn't proactive .. did you have a user/customer asking for it? -phil. On 9/13/11 4:57 PM, Dr Andrew John Hughes wrote: > On 11:59 Tue 13 Sep , Kelly O'Hair wrote: >> I am scratching my head on this one. >> >> I am not an imageio expert, but from what I read I am a bit concerned that people may have found >> workarounds for this problem, and this change could possibly break their workarounds. >> I know that sounds silly, but there it is. Is that possible? >> >> Can someone assure me that this change is harmless to the current complete jdk6 community? >> > People can do all sorts of crazy hacks in their own code. We shouldn't not fix bugs > because there's a risk it might break someone's code. If that was true, nothing would > ever get done. > > Besides, given the fix is already in 7, such hacks are going to be broken now anyway. > >> -kto >> >> On Sep 12, 2011, at 11:24 AM, Dr Andrew John Hughes wrote: >> >>> On 10:25 Mon 12 Sep , Pavel Tisnovsky wrote: >>>> Greetings, >>>> >>>> I'd like to backport the following change: >>>> "6296893: BMP Writer handles TopDown property incorrectly >>>> for some of the compression types" into OpenJDK6 >>>> >>>> Webrev is available here: >>>> http://cr.openjdk.java.net/~ptisnovs/6296893/ >>>> >>>> This change has been tested without problems (including the new regression test >>>> included in this backport). >>>> >>>> Can anybody please review this change& assign bug ID to it? >>>> >>>> Thank you in advance, >>>> Pavel >>> You already have a bug ID; 6296893. >>> >>> Can I approve this as an OpenJDK6 reviewer? >>> -- >>> Andrew :) >>> >>> Free Java Software Engineer >>> Red Hat, Inc. (http://www.redhat.com) >>> >>> Support Free Java! >>> Contribute to GNU Classpath and IcedTea >>> http://www.gnu.org/software/classpath >>> http://icedtea.classpath.org >>> PGP Key: F5862A37 (https://keys.indymedia.org/) >>> Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From kelly.ohair at oracle.com Tue Sep 13 17:43:56 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Tue, 13 Sep 2011 17:43:56 -0700 Subject: Request to backport "6296893: BMP Writer handles TopDown property incorrectly, for some of the compression types" into OpenJDK6 In-Reply-To: <4E6FF777.9050702@oracle.com> References: <4E6DC1E8.3080205@redhat.com> <20110912182422.GB26666@rivendell.middle-earth.co.uk> <0A61BE8A-7178-40A4-B7B3-AAE9C6DA413D@oracle.com> <20110913235746.GC26666@rivendell.middle-earth.co.uk> <4E6FF777.9050702@oracle.com> Message-ID: With Phil's comments. Then I approve. These OpenJDK6 changes are tailing off, right? Are there many more planned? -kto On Sep 13, 2011, at 5:38 PM, Phil Race wrote: > The backport looks fine and I think it far more likely that without this fix, > we'll be writing invalid images, rather than breaking anything people > have constructed to work around it .. ie they'd have learn to avoid this. > > So OK by me to backport but I'm not sure there's a need to continue > such backports for much longer when you can get JDK 7 instead. > Or maybe this isn't proactive .. did you have a user/customer asking for it? > > -phil. > > On 9/13/11 4:57 PM, Dr Andrew John Hughes wrote: >> On 11:59 Tue 13 Sep , Kelly O'Hair wrote: >>> I am scratching my head on this one. >>> >>> I am not an imageio expert, but from what I read I am a bit concerned that people may have found >>> workarounds for this problem, and this change could possibly break their workarounds. >>> I know that sounds silly, but there it is. Is that possible? >>> >>> Can someone assure me that this change is harmless to the current complete jdk6 community? >>> >> People can do all sorts of crazy hacks in their own code. We shouldn't not fix bugs >> because there's a risk it might break someone's code. If that was true, nothing would >> ever get done. >> >> Besides, given the fix is already in 7, such hacks are going to be broken now anyway. >> >>> -kto >>> >>> On Sep 12, 2011, at 11:24 AM, Dr Andrew John Hughes wrote: >>> >>>> On 10:25 Mon 12 Sep , Pavel Tisnovsky wrote: >>>>> Greetings, >>>>> >>>>> I'd like to backport the following change: >>>>> "6296893: BMP Writer handles TopDown property incorrectly >>>>> for some of the compression types" into OpenJDK6 >>>>> >>>>> Webrev is available here: >>>>> http://cr.openjdk.java.net/~ptisnovs/6296893/ >>>>> >>>>> This change has been tested without problems (including the new regression test >>>>> included in this backport). >>>>> >>>>> Can anybody please review this change& assign bug ID to it? >>>>> >>>>> Thank you in advance, >>>>> Pavel >>>> You already have a bug ID; 6296893. >>>> >>>> Can I approve this as an OpenJDK6 reviewer? >>>> -- >>>> Andrew :) >>>> >>>> Free Java Software Engineer >>>> Red Hat, Inc. (http://www.redhat.com) >>>> >>>> Support Free Java! >>>> Contribute to GNU Classpath and IcedTea >>>> http://www.gnu.org/software/classpath >>>> http://icedtea.classpath.org >>>> PGP Key: F5862A37 (https://keys.indymedia.org/) >>>> Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 > From ahughes at redhat.com Tue Sep 13 19:14:26 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Wed, 14 Sep 2011 03:14:26 +0100 Subject: Request to backport "6296893: BMP Writer handles TopDown property incorrectly,for some of the compression types" into OpenJDK6 In-Reply-To: References: <4E6DC1E8.3080205@redhat.com> <20110912182422.GB26666@rivendell.middle-earth.co.uk> <0A61BE8A-7178-40A4-B7B3-AAE9C6DA413D@oracle.com> <20110913235746.GC26666@rivendell.middle-earth.co.uk> <4E6FF777.9050702@oracle.com> Message-ID: <20110914021426.GE26666@rivendell.middle-earth.co.uk> On 17:43 Tue 13 Sep , Kelly O'Hair wrote: > With Phil's comments. Then I approve. > > These OpenJDK6 changes are tailing off, right? > Are there many more planned? > No. There are still about a hundred OpenJDK backports in IcedTea6 and we keep finding more. OpenJDK6 is not going to disappear over night, especially when OpenJDK7 is still largely untested and doesn't have a TCK available. According to http://openjdk.java.net/census/#andrew, I'm listed as an OpenJDK6 reviewer. Does this not mean I can approve such backports? > -kto > > On Sep 13, 2011, at 5:38 PM, Phil Race wrote: > > > The backport looks fine and I think it far more likely that without this fix, > > we'll be writing invalid images, rather than breaking anything people > > have constructed to work around it .. ie they'd have learn to avoid this. > > > > So OK by me to backport but I'm not sure there's a need to continue > > such backports for much longer when you can get JDK 7 instead. > > Or maybe this isn't proactive .. did you have a user/customer asking for it? > > > > -phil. > > > > On 9/13/11 4:57 PM, Dr Andrew John Hughes wrote: > >> On 11:59 Tue 13 Sep , Kelly O'Hair wrote: > >>> I am scratching my head on this one. > >>> > >>> I am not an imageio expert, but from what I read I am a bit concerned that people may have found > >>> workarounds for this problem, and this change could possibly break their workarounds. > >>> I know that sounds silly, but there it is. Is that possible? > >>> > >>> Can someone assure me that this change is harmless to the current complete jdk6 community? > >>> > >> People can do all sorts of crazy hacks in their own code. We shouldn't not fix bugs > >> because there's a risk it might break someone's code. If that was true, nothing would > >> ever get done. > >> > >> Besides, given the fix is already in 7, such hacks are going to be broken now anyway. > >> > >>> -kto > >>> > >>> On Sep 12, 2011, at 11:24 AM, Dr Andrew John Hughes wrote: > >>> > >>>> On 10:25 Mon 12 Sep , Pavel Tisnovsky wrote: > >>>>> Greetings, > >>>>> > >>>>> I'd like to backport the following change: > >>>>> "6296893: BMP Writer handles TopDown property incorrectly > >>>>> for some of the compression types" into OpenJDK6 > >>>>> > >>>>> Webrev is available here: > >>>>> http://cr.openjdk.java.net/~ptisnovs/6296893/ > >>>>> > >>>>> This change has been tested without problems (including the new regression test > >>>>> included in this backport). > >>>>> > >>>>> Can anybody please review this change& assign bug ID to it? > >>>>> > >>>>> Thank you in advance, > >>>>> Pavel > >>>> You already have a bug ID; 6296893. > >>>> > >>>> Can I approve this as an OpenJDK6 reviewer? > >>>> -- > >>>> Andrew :) > >>>> > >>>> Free Java Software Engineer > >>>> Red Hat, Inc. (http://www.redhat.com) > >>>> > >>>> Support Free Java! > >>>> Contribute to GNU Classpath and IcedTea > >>>> http://www.gnu.org/software/classpath > >>>> http://icedtea.classpath.org > >>>> PGP Key: F5862A37 (https://keys.indymedia.org/) > >>>> Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From philip.race at oracle.com Tue Sep 13 20:41:26 2011 From: philip.race at oracle.com (Phil Race) Date: Tue, 13 Sep 2011 20:41:26 -0700 Subject: Request to backport "6296893: BMP Writer handles TopDown property incorrectly,for some of the compression types" into OpenJDK6 In-Reply-To: <20110914021426.GE26666@rivendell.middle-earth.co.uk> References: <4E6DC1E8.3080205@redhat.com> <20110912182422.GB26666@rivendell.middle-earth.co.uk> <0A61BE8A-7178-40A4-B7B3-AAE9C6DA413D@oracle.com> <20110913235746.GC26666@rivendell.middle-earth.co.uk> <4E6FF777.9050702@oracle.com> <20110914021426.GE26666@rivendell.middle-earth.co.uk> Message-ID: <4E702266.50409@oracle.com> On 9/13/11 7:14 PM, Dr Andrew John Hughes wrote: > On 17:43 Tue 13 Sep , Kelly O'Hair wrote: >> With Phil's comments. Then I approve. >> >> These OpenJDK6 changes are tailing off, right? >> Are there many more planned? >> > No. There are still about a hundred OpenJDK backports in IcedTea6 and > we keep finding more. Meaning this is already in icedtea ? But still .. > OpenJDK6 is not going to disappear over night, especially when OpenJDK7 > is still largely untested and doesn't have a TCK available. I don't know about "largely untested" as its been TCKed and its the RI for 7 ... its mostly the same as the commercial product ... etc .. We stopped pro-actively backporting to "closed" 6 what seems like eons ago in favour of 7. > According to http://openjdk.java.net/census/#andrew, I'm listed as an > OpenJDK6 reviewer. Does this not mean I can approve such backports? Reviewer means that the code is OK, but "individual engineer reviewing code" != "product/release owner" -phil. >> -kto >> >> On Sep 13, 2011, at 5:38 PM, Phil Race wrote: >> >>> The backport looks fine and I think it far more likely that without this fix, >>> we'll be writing invalid images, rather than breaking anything people >>> have constructed to work around it .. ie they'd have learn to avoid this. >>> >>> So OK by me to backport but I'm not sure there's a need to continue >>> such backports for much longer when you can get JDK 7 instead. >>> Or maybe this isn't proactive .. did you have a user/customer asking for it? >>> >>> -phil. >>> >>> On 9/13/11 4:57 PM, Dr Andrew John Hughes wrote: >>>> On 11:59 Tue 13 Sep , Kelly O'Hair wrote: >>>>> I am scratching my head on this one. >>>>> >>>>> I am not an imageio expert, but from what I read I am a bit concerned that people may have found >>>>> workarounds for this problem, and this change could possibly break their workarounds. >>>>> I know that sounds silly, but there it is. Is that possible? >>>>> >>>>> Can someone assure me that this change is harmless to the current complete jdk6 community? >>>>> >>>> People can do all sorts of crazy hacks in their own code. We shouldn't not fix bugs >>>> because there's a risk it might break someone's code. If that was true, nothing would >>>> ever get done. >>>> >>>> Besides, given the fix is already in 7, such hacks are going to be broken now anyway. >>>> >>>>> -kto >>>>> >>>>> On Sep 12, 2011, at 11:24 AM, Dr Andrew John Hughes wrote: >>>>> >>>>>> On 10:25 Mon 12 Sep , Pavel Tisnovsky wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> I'd like to backport the following change: >>>>>>> "6296893: BMP Writer handles TopDown property incorrectly >>>>>>> for some of the compression types" into OpenJDK6 >>>>>>> >>>>>>> Webrev is available here: >>>>>>> http://cr.openjdk.java.net/~ptisnovs/6296893/ >>>>>>> >>>>>>> This change has been tested without problems (including the new regression test >>>>>>> included in this backport). >>>>>>> >>>>>>> Can anybody please review this change& assign bug ID to it? >>>>>>> >>>>>>> Thank you in advance, >>>>>>> Pavel >>>>>> You already have a bug ID; 6296893. >>>>>> >>>>>> Can I approve this as an OpenJDK6 reviewer? >>>>>> -- >>>>>> Andrew :) >>>>>> >>>>>> Free Java Software Engineer >>>>>> Red Hat, Inc. (http://www.redhat.com) >>>>>> >>>>>> Support Free Java! >>>>>> Contribute to GNU Classpath and IcedTea >>>>>> http://www.gnu.org/software/classpath >>>>>> http://icedtea.classpath.org >>>>>> PGP Key: F5862A37 (https://keys.indymedia.org/) >>>>>> Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From Vincent.Monfort at inria.fr Wed Sep 14 01:21:18 2011 From: Vincent.Monfort at inria.fr (Monfort Vincent) Date: Wed, 14 Sep 2011 10:21:18 +0200 Subject: [Bug report] "invalid" class files in openjdk6 In-Reply-To: <4E705F98.9080307@irisa.fr> References: <4E6DC1E8.3080205@redhat.com> <20110912182422.GB26666@rivendell.middle-earth.co.uk> <0A61BE8A-7178-40A4-B7B3-AAE9C6DA413D@oracle.com> <20110913235746.GC26666@rivendell.middle-earth.co.uk> <4E6FF777.9050702@oracle.com> <20110914021426.GE26666@rivendell.middle-earth.co.uk> <4E702266.50409@oracle.com> <4E705F98.9080307@irisa.fr> Message-ID: <4E7063FE.70600@inria.fr> Hello, I preferred post this message on a bug tracker but I did not find one for open-jdk ... I actually working on a static analysis tool for java bytecode (http://sawja.inria.fr/) and this tool checks some properties described by the VM Specification on the class File Format for the flags on a class file. It seems that some of the class files included in the jre archive: "rt.jar" of the open-jdk distribution do not comply with this specification (checked on jdk 1.6 18 and 20). The class files concerned are "package-info.class" files that could be used for documentation and annotation on a package, but since annotation could be used at runtime level it must respects class File Format ... Moreover the Oracle jdk distribution does not have the same issue. The problem is the following for these classes the flags ACC_INTERFACE is set and not the ACC_ABSTRACT and it does not comply with the specification (regarding the revised version of class File Format ) indicating: "An interface is distinguished by its ACC_INTERFACE flag being set. If its ACC_INTERFACE flag is not set, this class file defines a class, not an interface. _If the ACC_INTERFACE flag of this class file is set, its ACC_ABSTRACT flag must also be set_ (?2.13.1) and its ACC_PUBLIC flag may be set. Such a class file must not have any of the other flags in Table 4.1 set. An annotation type must have its ACC_ANNOTATION flag set. If the ACC_ANNOTATION flag is set, the ACC_INTERFACE flag must be set as well." The exact class files concerned are the following in both 18 and 20 versions: com.sun.istack.internal.package-info com.sun.xml.internal.bind.api.package-info com.sun.xml.internal.bind.v2.package-info com.sun.xml.internal.bind.v2.runtime.output.package-info com.sun.xml.internal.bind.v2.schemagen.package-info com.sun.xml.internal.ws.api.message.package-info com.sun.xml.internal.ws.api.package-info com.sun.xml.internal.ws.api.pipe.helper.package-info com.sun.xml.internal.ws.api.pipe.package-info com.sun.xml.internal.ws.api.server.package-info com.sun.xml.internal.ws.api.wsdl.parser.package-info com.sun.xml.internal.ws.client.package-info com.sun.xml.internal.ws.developer.package-info com.sun.xml.internal.ws.message.jaxb.package-info com.sun.xml.internal.ws.message.package-info com.sun.xml.internal.ws.package-info com.sun.xml.internal.ws.server.package-info Best regards -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20110914/acd24a06/attachment.html From ahughes at redhat.com Wed Sep 14 09:19:52 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Wed, 14 Sep 2011 17:19:52 +0100 Subject: Request to backport "6296893: BMP Writer handles TopDown property incorrectly,for some of the compression types" into OpenJDK6 In-Reply-To: <4E702266.50409@oracle.com> References: <4E6DC1E8.3080205@redhat.com> <20110912182422.GB26666@rivendell.middle-earth.co.uk> <0A61BE8A-7178-40A4-B7B3-AAE9C6DA413D@oracle.com> <20110913235746.GC26666@rivendell.middle-earth.co.uk> <4E6FF777.9050702@oracle.com> <20110914021426.GE26666@rivendell.middle-earth.co.uk> <4E702266.50409@oracle.com> Message-ID: <20110914161952.GH26666@rivendell.middle-earth.co.uk> On 20:41 Tue 13 Sep , Phil Race wrote: > On 9/13/11 7:14 PM, Dr Andrew John Hughes wrote: > > On 17:43 Tue 13 Sep , Kelly O'Hair wrote: > >> With Phil's comments. Then I approve. > >> > >> These OpenJDK6 changes are tailing off, right? > >> Are there many more planned? > >> > > No. There are still about a hundred OpenJDK backports in IcedTea6 and > > we keep finding more. > > Meaning this is already in icedtea ? But still .. > Yes, in HEAD but not yet in a release. We try to upstream these backports as time allows, but this is starting to sound like you'd rather we didn't bother. Is this the case? > > OpenJDK6 is not going to disappear over night, especially when OpenJDK7 > > is still largely untested and doesn't have a TCK available. > > I don't know about "largely untested" as its been TCKed and its the RI > for 7 ... Sorry, I should clarify; I mean "largely untested" in comparison to OpenJDK6. We can build binaries of OpenJDK7 for use in Fedora, RHEL, etc. but there is no TCK to verify them against and they've not really had any real-world testing as yet (we're not even two months in yet). This is compared with OpenJDK6 binaries which are TCKed for every new release and have had years of real-world usage. As I'm sure you know, a source code base can't be TCKed. Only binaries built from it can. The snapshot used for the RI, which I presume is what you were referring to as having being TCKed, is already outdated and there will be differences between this and our builds, which will only increase with time. In short, we can't start to consider dropping OpenJDK6 until 7 is an acceptable equivalent. If Oracle want to see OpenJDK6 tail off, the TCK for 7 needs to be available under the same license as that for 6, so binaries of 7 can be tested. > its mostly the same as the commercial product ... etc .. I assume you mean the proprietary Oracle builds; there's nothing non-commercial about OpenJDK6/7. I don't think some vague idea of "mostly the same" is good enough. In my experience, it hasn't been in the past. Our experience with OpenJDK6 vs. the proprietary JDK6, which had apparently passed the TCK, was that quite a number of failures were found with OpenJDK6 initially. Given that this time the open derivative is closer to the proprietary build and has also apparently passed the TCK itself, things should be easier but I still don't think we can take it for granted that our binaries pass because the proprietary Oracle ones do. > We stopped pro-actively backporting to "closed" 6 what seems like eons > ago in favour of 7. I don't see how this is relevant, given you're referring to a completely different product with different release cycles and support. FWIW, Oracle, for the most part, have never pro-actively backported to OpenJDK6. Bar a number of langtools and HotSpot changes, we've had to do pretty much all the work. > > > According to http://openjdk.java.net/census/#andrew, I'm listed as an > > OpenJDK6 reviewer. Does this not mean I can approve such backports? > > Reviewer means that the code is OK, but "individual engineer reviewing > code" != "product/release owner" Ok, so it's fairly meaningless then, as I've already been doing that for years. > > -phil. > >> -kto > >> -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From kelly.ohair at oracle.com Wed Sep 14 09:59:37 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 14 Sep 2011 09:59:37 -0700 Subject: Request to backport "6296893: BMP Writer handles TopDown property incorrectly, for some of the compression types" into OpenJDK6 In-Reply-To: <20110914161952.GH26666@rivendell.middle-earth.co.uk> References: <4E6DC1E8.3080205@redhat.com> <20110912182422.GB26666@rivendell.middle-earth.co.uk> <0A61BE8A-7178-40A4-B7B3-AAE9C6DA413D@oracle.com> <20110913235746.GC26666@rivendell.middle-earth.co.uk> <4E6FF777.9050702@oracle.com> <20110914021426.GE26666@rivendell.middle-earth.co.uk> <4E702266.50409@oracle.com> <20110914161952.GH26666@rivendell.middle-earth.co.uk> Message-ID: <6401FA08-7717-437D-BE75-3222E03AD52A@oracle.com> I did not mean to imply that OpenJDK6 changes cannot be made or there is some specific limit. But it has just made sense in the past to try and stop changing the older releases in favor of the newer ones at some point. I'm just wondering what to expect in the months ahead for OpenJDK6. I will continue to approve any changes to OpenJDK6 that make sense and follow the rules we have tried to have on this release. So I'm trying to do a bit of a balancing act here, I want OpenJDK6 to be as stable and valuable as possible, but a big part of that stability is trying to NOT change what does not need changing to avoid unwanted regressions or surprising changes in behavior. I am relying on many people to help me with these approvals when it's not obvious to me what to do. -kto On Sep 14, 2011, at 9:19 AM, Dr Andrew John Hughes wrote: > On 20:41 Tue 13 Sep , Phil Race wrote: >> On 9/13/11 7:14 PM, Dr Andrew John Hughes wrote: >>> On 17:43 Tue 13 Sep , Kelly O'Hair wrote: >>>> With Phil's comments. Then I approve. >>>> >>>> These OpenJDK6 changes are tailing off, right? >>>> Are there many more planned? >>>> >>> No. There are still about a hundred OpenJDK backports in IcedTea6 and >>> we keep finding more. >> >> Meaning this is already in icedtea ? But still .. >> > > Yes, in HEAD but not yet in a release. > > We try to upstream these backports as time allows, but this is starting to > sound like you'd rather we didn't bother. Is this the case? > >>> OpenJDK6 is not going to disappear over night, especially when OpenJDK7 >>> is still largely untested and doesn't have a TCK available. >> >> I don't know about "largely untested" as its been TCKed and its the RI >> for 7 ... > > Sorry, I should clarify; I mean "largely untested" in comparison to > OpenJDK6. We can build binaries of OpenJDK7 for use in Fedora, RHEL, > etc. but there is no TCK to verify them against and they've not really > had any real-world testing as yet (we're not even two months in yet). > This is compared with OpenJDK6 binaries which are TCKed for every new > release and have had years of real-world usage. > > As I'm sure you know, a source code base can't be TCKed. Only > binaries built from it can. The snapshot used for the RI, which I > presume is what you were referring to as having being TCKed, is > already outdated and there will be differences between this and our > builds, which will only increase with time. > > In short, we can't start to consider dropping OpenJDK6 until 7 is an > acceptable equivalent. If Oracle want to see OpenJDK6 tail off, the > TCK for 7 needs to be available under the same license as that for 6, > so binaries of 7 can be tested. > >> its mostly the same as the commercial product ... etc .. > > I assume you mean the proprietary Oracle builds; there's nothing > non-commercial about OpenJDK6/7. I don't think some vague idea of > "mostly the same" is good enough. In my experience, it hasn't been > in the past. > > Our experience with OpenJDK6 vs. the proprietary JDK6, which had > apparently passed the TCK, was that quite a number of failures were > found with OpenJDK6 initially. Given that this time the open > derivative is closer to the proprietary build and has also apparently > passed the TCK itself, things should be easier but I still don't think > we can take it for granted that our binaries pass because the > proprietary Oracle ones do. > >> We stopped pro-actively backporting to "closed" 6 what seems like eons >> ago in favour of 7. > > I don't see how this is relevant, given you're referring to a completely > different product with different release cycles and support. > > FWIW, Oracle, for the most part, have never pro-actively backported to > OpenJDK6. Bar a number of langtools and HotSpot changes, we've had to > do pretty much all the work. > >> >>> According to http://openjdk.java.net/census/#andrew, I'm listed as an >>> OpenJDK6 reviewer. Does this not mean I can approve such backports? >> >> Reviewer means that the code is OK, but "individual engineer reviewing >> code" != "product/release owner" > > Ok, so it's fairly meaningless then, as I've already been doing that for years. > >> >> -phil. >>>> -kto >>>> > > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and IcedTea > http://www.gnu.org/software/classpath > http://icedtea.classpath.org > PGP Key: F5862A37 (https://keys.indymedia.org/) > Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37