From Erik.Trimble at Sun.COM Tue Dec 1 14:21:34 2009 From: Erik.Trimble at Sun.COM (Erik Trimble) Date: Tue, 01 Dec 2009 14:21:34 -0800 Subject: Hotspot 16 Build 13 has been promoted... Message-ID: <4B1596EE.4030607@sun.com> Build 13 of Hotspot 16 has been promoted and has successfully completed PIT. This Hotspot build will be integrated into the Sun JDK 6 Update 18 Build 06 codebase. Build 13 is likely to be the last build of Hotspot 16 before the release of 6u18. There _might_ be one more build this week, so I'll keep everyone informed. If it occurs, Build 14 will ABSOLUTELY be the last build of HS16 going into 6u18. The latest promoted bits can be found (as usual) in: http://hg.openjdk.java.net/hsx/hsx16/master The Hg tip for this build is: http://hg.openjdk.java.net/hsx/hsx16/master/rev/b6e6e189e1db Here is the PIT certificate: ============= Component : VM Status : 0 major failures, 0 minor failures Date : 12/01/2009 at 07:18 Tested By : Nicolay.Haustov at sun.com and VM SQE Cost(total man-days): 1 Workspace : http://hg.openjdk.java.net/hsx/hsx16/master Bundles : JPRT: 2009-11-26-060126.et151817.hs16b13 Platforms : Solaris Sparc 11(32), -client Solaris Sparc 11(32), -server Solaris Sparc 10(32), -client Solaris Sparc 10(32), -server Solaris x86 11(32), -client Solaris x86 11(32), -server Solaris x86 10(32), -client Solaris x86 10(32), -server WinXP Prof(32), -client WinXP Prof(32), -server WinXP Home(32), -client WinXP Home(32), -server Win Server 2003(32), -client Win Server 2003(32), -server Windows Vista 32 bit, -client Windows Vista 32 bit, -server Windows Vista 64 bit, -client Windows Vista 64 bit, -server RH AS4.0 (32), -client RH AS4.0 (32), -server SuSE SLES 8(32), -client SuSE SLES 8(32), -server Solaris AMD64(64jdk), -d64/-server Sol Sparc 10(64OS)(64jdk), -d64/-server win server2003 AMD(64OS)(64jdk), -d64/-server RH AS4.0 AMD(64OS)(64jdk), -d64/-server SuSE SLES8 AMD(64OS)(64jdk), -d64/-server Others Tests : /net/sqenfs-1.sfbay/export1/comp/vm/testbase Browsers : NA Patches : NA Logs : http://sqeweb.sfbay.sun.com/nfs/results/vm/gtee/HSX/PIT/VM/16/b13/jdk6u18b06/ Number of Tests Executed : 619188 product tests, 0 unit tests, 0 tck tests Bug verification status: ====================================== Tested, Pass: 6821003: Update hotspot windows os_win32 for windows 7 6842999: Update hotspot windows os_win32 for windows 2008 R2 6892079: live value must not be garbage failure after fix for 6854812 6904191: OptimizeStringConcat should be product instead of experimental Tested, Pass (partial fixes): Tested, Fail: Untested bug fixes: Bugs/rfes with no unit tests: Other reasons: 6828069: Change JDK_MINOR_VER to 6 for 6Update HS versions 6904996: Bump the HS16 build number to 13 New bugs filed: Bugs in PIT build: Bugs in earlier promoted build: 6825772: DEBUG MESSAGE: corrupted control word detected Number of PIT requested: 1 Integration target J2SE build number: 1.6.0_18-b06 Issues and Notes: This is HS 16 b13 PIT for JDK 6u18 b06. ------------------------------- >From Nicolay.Haustov at sun.com and VM SQE -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA From Erik.Trimble at Sun.COM Tue Dec 1 14:27:46 2009 From: Erik.Trimble at Sun.COM (Erik Trimble) Date: Tue, 01 Dec 2009 14:27:46 -0800 Subject: Tagging in the HSX releases... Message-ID: <4B159862.9040800@sun.com> After some internal discussion, and taking into account the already-voiced opinions here in favor of it, I'll be adding Mercurial Tags to the repositories to indicate the Hotspot Build number. I plan to go all the way back to the release of Hotspot 16 and tag as appropriate. All future HSX work will include the proper tags. The tags will be of the form: hsX-bY where X is the Hotspot major version number OR the major.minor version number (e.g. 16 or 16.1 ) Y is the build number, two digits in length, with a leading 0 if necessary. (e.g. 09 or 12 ) Thus, tags will look like: hs16-b13 or hs16.1-b02 This change should make determination of what is included in a HSX build simpler, and cloning much easier. Please refer to the Mercurial documentation for how to use Tags during cloning or other operations. -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA From gnu_andrew at member.fsf.org Wed Dec 2 09:19:22 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 2 Dec 2009 17:19:22 +0000 Subject: Tagging in the HSX releases... In-Reply-To: <4B159862.9040800@sun.com> References: <4B159862.9040800@sun.com> Message-ID: <17c6771e0912020919u67e69bd4l8a871a4946002d74@mail.gmail.com> 2009/12/1 Erik Trimble : > After some internal discussion, and taking into account the already-voiced > opinions here in favor of it, ?I'll be adding Mercurial Tags to the > repositories to indicate the Hotspot Build number. > > I plan to go all the way back to the release of Hotspot 16 and tag as > appropriate. All future HSX work will include the proper tags. > > The tags will be of the form: > > hsX-bY > > where X is the Hotspot major version number OR the major.minor version > number (e.g. ?16 ?or ?16.1 ) > Y is the build number, two digits in length, with a leading 0 if necessary. > ?(e.g. ?09 ?or 12 ) > > Thus, tags will look like: > > hs16-b13 > > or > > hs16.1-b02 > > > This change should make determination of what is included in a HSX build > simpler, and cloning much easier. > > Please refer to the Mercurial documentation for how to use Tags during > cloning or other operations. > > -- > Erik Trimble > Java System Support > Mailstop: ?usca22-123 > Phone: ?x17195 > Santa Clara, CA > > This is good to hear. I was planning to add such tags when we imported hs16 into OpenJDK6, so this saves me the job! :-) -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Thu Dec 3 07:54:41 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 3 Dec 2009 15:54:41 +0000 Subject: Backport AWT test fix to OpenJDK6 Message-ID: <17c6771e0912030754i12f210aer851f502a9bd795ba@mail.gmail.com> The test test/java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html fails consistently due to a Proxy-based workaround. This patch: http://hg.openjdk.java.net/jdk7/awt/jdk/rev/35d43184687d just committed to OpenJDK7 removes the workaround as discussed here: http://mail.openjdk.java.net/pipermail/awt-dev/2009-October/000984.html Are we ok to backport this to OpenJDK6 for b18? Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Thu Dec 3 08:28:57 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 3 Dec 2009 16:28:57 +0000 Subject: [security-dev 01423]: Please review patch for regression test sun/security/tools/keytool/StartDate In-Reply-To: <4B17BC1B.2020209@redhat.com> References: <4B17BC1B.2020209@redhat.com> Message-ID: <17c6771e0912030828l6c03cbe0x35ae3123b34d2830@mail.gmail.com> 2009/12/3 Pavel Tisnovsky : > Hi, > > patch for regression test sun/security/tools/keytool/StartDate.java > (included in OpenJDK6) is exposed at > > http://cr.openjdk.java.net/~ptisnovs/StartDateTest/ > > and prepared for review. > > This patch ensures, that this test does not fail on December(s) due to > incorrect comparison of two months (12 != 0). > > Can you please review and possibly approve this patch? > > Pavel Tisnovsky > Red Hat > This looks sane to me, and indeed the fix has already been applied in OpenJDK7: http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/2c37083730b1 Joe, can we please backport this to OpenJDK6? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Joe.Darcy at Sun.COM Thu Dec 3 13:02:11 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Thu, 03 Dec 2009 13:02:11 -0800 Subject: Backport AWT test fix to OpenJDK6 In-Reply-To: <17c6771e0912030754i12f210aer851f502a9bd795ba@mail.gmail.com> References: <17c6771e0912030754i12f210aer851f502a9bd795ba@mail.gmail.com> Message-ID: <4B182753.8040709@sun.com> Andrew John Hughes wrote: > The test test/java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html > fails consistently due to a Proxy-based workaround. This patch: > > http://hg.openjdk.java.net/jdk7/awt/jdk/rev/35d43184687d > > just committed to OpenJDK7 removes the workaround as discussed here: > http://mail.openjdk.java.net/pipermail/awt-dev/2009-October/000984.html > > Are we ok to backport this to OpenJDK6 for b18? > > Sure; backport away :-) Thanks, -Joe From Joe.Darcy at Sun.COM Thu Dec 3 13:48:10 2009 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Thu, 03 Dec 2009 13:48:10 -0800 Subject: [security-dev 01423]: Please review patch for regression test sun/security/tools/keytool/StartDate In-Reply-To: <17c6771e0912030828l6c03cbe0x35ae3123b34d2830@mail.gmail.com> References: <4B17BC1B.2020209@redhat.com> <17c6771e0912030828l6c03cbe0x35ae3123b34d2830@mail.gmail.com> Message-ID: <4B18321A.7080409@sun.com> Andrew John Hughes wrote: > 2009/12/3 Pavel Tisnovsky : > >> Hi, >> >> patch for regression test sun/security/tools/keytool/StartDate.java >> (included in OpenJDK6) is exposed at >> >> http://cr.openjdk.java.net/~ptisnovs/StartDateTest/ >> >> and prepared for review. >> >> This patch ensures, that this test does not fail on December(s) due to >> incorrect comparison of two months (12 != 0). >> >> Can you please review and possibly approve this patch? >> >> Pavel Tisnovsky >> Red Hat >> >> > > This looks sane to me, and indeed the fix has already been applied in OpenJDK7: > > http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/2c37083730b1 > > Joe, can we please backport this to OpenJDK6? > -- > Certainly! Thanks, -Joe From Weijun.Wang at Sun.COM Thu Dec 3 16:29:27 2009 From: Weijun.Wang at Sun.COM (Max (Weijun) Wang) Date: Fri, 04 Dec 2009 08:29:27 +0800 Subject: [security-dev 01426]: Re: Please review patch for regression test sun/security/tools/keytool/StartDate In-Reply-To: <4B18321A.7080409@sun.com> References: <4B17BC1B.2020209@redhat.com> <17c6771e0912030828l6c03cbe0x35ae3123b34d2830@mail.gmail.com> <4B18321A.7080409@sun.com> Message-ID: <131762B8-1466-4322-BC0A-517C6B82EC74@sun.com> Hi Joe I'll backport the fix to openjdk-6. In fact, I haven't made any changes to openjdk-6 except for SSR releases. Just browse hg.openjdk.java.net and find only one openjdk-6 entrance: http://hg.openjdk.java.net/jdk6/jdk6-gate/jdk/ So there's no sub repo for different groups and this is the one I should putback to? Do I need to use JPRT to putback the fix or I can simply "hg push"? I remember JPRT was needed when the repo was initialized some time ago. Thanks Max On Dec 4, 2009, at 5:48 AM, Joe Darcy wrote: > Andrew John Hughes wrote: >> 2009/12/3 Pavel Tisnovsky : >> >>> Hi, >>> >>> patch for regression test sun/security/tools/keytool/StartDate.java >>> (included in OpenJDK6) is exposed at >>> >>> http://cr.openjdk.java.net/~ptisnovs/StartDateTest/ >>> >>> and prepared for review. >>> >>> This patch ensures, that this test does not fail on December(s) >>> due to >>> incorrect comparison of two months (12 != 0). >>> >>> Can you please review and possibly approve this patch? >>> >>> Pavel Tisnovsky >>> Red Hat >>> >>> >> >> This looks sane to me, and indeed the fix has already been applied >> in OpenJDK7: >> >> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/2c37083730b1 >> >> Joe, can we please backport this to OpenJDK6? >> -- >> > > Certainly! > > Thanks, > > -Joe From Joe.Darcy at Sun.COM Thu Dec 3 16:41:42 2009 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Thu, 03 Dec 2009 16:41:42 -0800 Subject: [security-dev 01426]: Re: Please review patch for regression test sun/security/tools/keytool/StartDate In-Reply-To: <131762B8-1466-4322-BC0A-517C6B82EC74@sun.com> References: <4B17BC1B.2020209@redhat.com> <17c6771e0912030828l6c03cbe0x35ae3123b34d2830@mail.gmail.com> <4B18321A.7080409@sun.com> <131762B8-1466-4322-BC0A-517C6B82EC74@sun.com> Message-ID: <4B185AC6.1060507@sun.com> Max (Weijun) Wang wrote: > Hi Joe > > I'll backport the fix to openjdk-6. Great. > > In fact, I haven't made any changes to openjdk-6 except for SSR > releases. Just browse hg.openjdk.java.net and find only one openjdk-6 > entrance: > > http://hg.openjdk.java.net/jdk6/jdk6-gate/jdk/ Correct; there is only the master OpenJDK 6 repo; there are no integration repos like TL in JDK 7. > > So there's no sub repo for different groups and this is the one I > should putback to? > > Do I need to use JPRT to putback the fix or I can simply "hg push"? I > remember JPRT was needed when the repo was initialized some time ago. You may use jprt to commit the fix but that is not required. Cheers, -Joe > > Thanks > Max > > On Dec 4, 2009, at 5:48 AM, Joe Darcy wrote: > >> Andrew John Hughes wrote: >>> 2009/12/3 Pavel Tisnovsky : >>> >>>> Hi, >>>> >>>> patch for regression test sun/security/tools/keytool/StartDate.java >>>> (included in OpenJDK6) is exposed at >>>> >>>> http://cr.openjdk.java.net/~ptisnovs/StartDateTest/ >>>> >>>> and prepared for review. >>>> >>>> This patch ensures, that this test does not fail on December(s) due to >>>> incorrect comparison of two months (12 != 0). >>>> >>>> Can you please review and possibly approve this patch? >>>> >>>> Pavel Tisnovsky >>>> Red Hat >>>> >>>> >>> >>> This looks sane to me, and indeed the fix has already been applied >>> in OpenJDK7: >>> >>> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/2c37083730b1 >>> >>> Joe, can we please backport this to OpenJDK6? >>> -- >>> >> >> Certainly! >> >> Thanks, >> >> -Joe > From weijun.wang at sun.com Fri Dec 4 00:56:45 2009 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Fri, 04 Dec 2009 08:56:45 +0000 Subject: hg: jdk6/jdk6/jdk: 6643094: Test on keytool -startdate forgets about December Message-ID: <20091204085728.846F141E58@hg.openjdk.java.net> Changeset: d7d0e90c9f72 Author: weijun Date: 2009-12-04 16:54 +0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/d7d0e90c9f72 6643094: Test on keytool -startdate forgets about December Reviewed-by: xuelei ! test/sun/security/tools/keytool/StartDateTest.java From ahughes at redhat.com Fri Dec 4 08:19:29 2009 From: ahughes at redhat.com (ahughes at redhat.com) Date: Fri, 04 Dec 2009 16:19:29 +0000 Subject: hg: jdk6/jdk6/jdk: 6566375: PIT : test/java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html Message-ID: <20091204162019.4326241EE1@hg.openjdk.java.net> Changeset: 495de07832ca Author: ant Date: 2009-12-02 17:26 +0300 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/495de07832ca 6566375: PIT : test/java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html Reviewed-by: art, dcherepanov, darcy ! test/java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.java From gnu_andrew at member.fsf.org Fri Dec 4 08:34:53 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 4 Dec 2009 16:34:53 +0000 Subject: Backport AWT test fix to OpenJDK6 In-Reply-To: <4B182753.8040709@sun.com> References: <17c6771e0912030754i12f210aer851f502a9bd795ba@mail.gmail.com> <4B182753.8040709@sun.com> Message-ID: <17c6771e0912040834v616a7d41kaaa409d41acc5adc@mail.gmail.com> 2009/12/3 Joseph D. Darcy : > Andrew John Hughes wrote: >> >> The test >> test/java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html >> fails consistently due to a Proxy-based workaround. ?This patch: >> >> http://hg.openjdk.java.net/jdk7/awt/jdk/rev/35d43184687d >> >> just committed to OpenJDK7 removes the workaround as discussed here: >> http://mail.openjdk.java.net/pipermail/awt-dev/2009-October/000984.html >> >> Are we ok to backport this to OpenJDK6 for b18? >> >> > > Sure; backport away :-) > > Thanks, > > -Joe > > Done: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/495de07832ca Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From ptisnovs at redhat.com Fri Dec 4 09:18:44 2009 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Fri, 04 Dec 2009 18:18:44 +0100 Subject: Regression test /java/util/logging/LoggingDeadlock2 in OpenJDK6 is not correct Message-ID: <4B194474.1000008@redhat.com> Hi, Regression test /java/util/logging/LoggingDeadlock2 in OpenJDK6 does not work correctly. As I see, the fix for this test has already been applied in OpenJDK7. Is it possible to backport this new version to OpenJDK6, please? I successfully tested this new version against OpenJDK6 without problems. Thank you in advance Pavel Tisnovsky From gnu_andrew at member.fsf.org Fri Dec 4 15:08:38 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 4 Dec 2009 23:08:38 +0000 Subject: Regression test /java/util/logging/LoggingDeadlock2 in OpenJDK6 is not correct In-Reply-To: <4B194474.1000008@redhat.com> References: <4B194474.1000008@redhat.com> Message-ID: <17c6771e0912041508n1e46bc84vaf8cc54d7692ac6e@mail.gmail.com> 2009/12/4 Pavel Tisnovsky : > Hi, > > Regression test /java/util/logging/LoggingDeadlock2 in OpenJDK6 does not > ?work correctly. As I see, the fix for this test has already been applied in > OpenJDK7. Is it possible to backport this new version to OpenJDK6, please? I > successfully tested this new version against OpenJDK6 without problems. > > Thank you in advance > Pavel Tisnovsky > There are two relevant fixes for this test in 7: changeset: 1282:7772d77bd7c2 parent: 1280:045aeb76b0ff user: mchung date: Tue May 26 17:47:57 2009 -0700 summary: 6829636: test/java/util/logging/LoggingDeadlock2.java is flaky changeset: 1163:079985c9965b user: martin date: Mon Apr 20 21:53:38 2009 -0700 summary: 6716076: test UTIL_REGRESSION/test/java/util/logging/LoggingDeadlock2.java failed with exit code 1 I guess we should backport both to stabilise this test. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Fri Dec 4 15:27:01 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 4 Dec 2009 23:27:01 +0000 Subject: Regression test /java/util/logging/LoggingDeadlock2 in OpenJDK6 is not correct In-Reply-To: <17c6771e0912041508n1e46bc84vaf8cc54d7692ac6e@mail.gmail.com> References: <4B194474.1000008@redhat.com> <17c6771e0912041508n1e46bc84vaf8cc54d7692ac6e@mail.gmail.com> Message-ID: <17c6771e0912041527v6d580988y15448875295ece93@mail.gmail.com> 2009/12/4 Andrew John Hughes : > 2009/12/4 Pavel Tisnovsky : >> Hi, >> >> Regression test /java/util/logging/LoggingDeadlock2 in OpenJDK6 does not >> ?work correctly. As I see, the fix for this test has already been applied in >> OpenJDK7. Is it possible to backport this new version to OpenJDK6, please? I >> successfully tested this new version against OpenJDK6 without problems. >> >> Thank you in advance >> Pavel Tisnovsky >> > > There are two relevant fixes for this test in 7: > > changeset: ? 1282:7772d77bd7c2 > parent: ? ? ?1280:045aeb76b0ff > user: ? ? ? ?mchung > date: ? ? ? ?Tue May 26 17:47:57 2009 -0700 > summary: ? ? 6829636: test/java/util/logging/LoggingDeadlock2.java is flaky > > changeset: ? 1163:079985c9965b > user: ? ? ? ?martin > date: ? ? ? ?Mon Apr 20 21:53:38 2009 -0700 > summary: ? ? 6716076: test > UTIL_REGRESSION/test/java/util/logging/LoggingDeadlock2.java failed > with exit code 1 > > I guess we should backport both to stabilise this test. > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > The webrev for the backport of Martin's changeset is at: http://cr.openjdk.java.net/~andrew/6716076/webrev.01/ Is this ok to push? I'm not sure how relevant the other changeset is. It only removes an ignore line from the test, which isn't present in the OpenJDK6 version (it's introduced by an earlier changeset from Kelly). It includes some other changes to URLConnection which the bug report (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6829636) doesn't explain. The bug report does however refer to another bug related to ShutdownHooks. Would someone care to shed some light on this bug? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Joe.Darcy at Sun.COM Fri Dec 4 15:30:08 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Fri, 04 Dec 2009 15:30:08 -0800 Subject: Regression test /java/util/logging/LoggingDeadlock2 in OpenJDK6 is not correct In-Reply-To: <17c6771e0912041508n1e46bc84vaf8cc54d7692ac6e@mail.gmail.com> References: <4B194474.1000008@redhat.com> <17c6771e0912041508n1e46bc84vaf8cc54d7692ac6e@mail.gmail.com> Message-ID: <4B199B80.1070200@sun.com> Andrew John Hughes wrote: > 2009/12/4 Pavel Tisnovsky : > >> Hi, >> >> Regression test /java/util/logging/LoggingDeadlock2 in OpenJDK6 does not >> work correctly. As I see, the fix for this test has already been applied in >> OpenJDK7. Is it possible to backport this new version to OpenJDK6, please? I >> successfully tested this new version against OpenJDK6 without problems. >> >> Thank you in advance >> Pavel Tisnovsky >> >> > > There are two relevant fixes for this test in 7: > > changeset: 1282:7772d77bd7c2 > parent: 1280:045aeb76b0ff > user: mchung > date: Tue May 26 17:47:57 2009 -0700 > summary: 6829636: test/java/util/logging/LoggingDeadlock2.java is flaky > > changeset: 1163:079985c9965b > user: martin > date: Mon Apr 20 21:53:38 2009 -0700 > summary: 6716076: test > UTIL_REGRESSION/test/java/util/logging/LoggingDeadlock2.java failed > with exit code 1 > > I guess we should backport both to stabilise this test. > I'm fine with these two fixes being backported to OpenJDK 6. Cheers, -Joe From ahughes at redhat.com Fri Dec 4 15:58:39 2009 From: ahughes at redhat.com (ahughes at redhat.com) Date: Fri, 04 Dec 2009 23:58:39 +0000 Subject: hg: jdk6/jdk6/jdk: 6716076: test UTIL_REGRESSION/test/java/util/logging/LoggingDeadlock2.java failed with exit code 1 Message-ID: <20091204235905.479EB41F6A@hg.openjdk.java.net> Changeset: 425882c72338 Author: martin Date: 2009-12-04 23:11 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/425882c72338 6716076: test UTIL_REGRESSION/test/java/util/logging/LoggingDeadlock2.java failed with exit code 1 Reviewed-by: swamyv, mchung ! test/java/util/logging/LoggingDeadlock2.java From Kelly.Ohair at Sun.COM Mon Dec 7 11:00:38 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 07 Dec 2009 11:00:38 -0800 Subject: Need approval, JDI updates to openjdk6 Message-ID: <4B1D50D6.2060604@sun.com> OpenJDK6 changes for JDI. I'm ready to push. I would like approvals from Joe, Jim, Alan, Dan, and Tim. In the process of trying to get good test results running the openjdk6 debugger (JDI) and jvmti tests (com/sun/jdi and demo/jvmti), I kept running into fixes made in jdk7 that were not in jdk6. Since this functionality and apis are still jdk6, I took the liberty of porting all of the openjdk7 JDI changes and JDI test changes to openjdk6. These changes have all been reviewed for jdk7, and with a few minor exceptions (i.e. -target 7 -source -7 in a few places) the resulting files in openjdk6 now match openjdk7. Please speak up if you have objections to this. The openjdk6 com/sun/jdi tests are stable now, however for some reason I am unable to run them with 'jtreg -samevm', but all indications are that this is unrelated to the JDI tests themselves (the same tests run fine with -samevm in openjdk7). The jtreg -samevm runs fail with a jtreg error: Error. Error while cleaning up threads after test and it is unpredictable as to what testcase it will happen with. I'll investigate this again after the openjdk6 version of hotspot is updated (I think it has 14.0 right now), I'm suspecting a hotspot fix in 14.2 regarding threads might solve this (6772683, but that's a guess). Here is the complete webrev: http://cr.openjdk.java.net/~ohair/openjdk6/jdk6-serviceability-update/webrev/ One changeset contains several bugs because the changes to the files overlapped so much. I tried to selectively bring in changesets from jdk7 as I needed them, only realizing toward the end that I really needed all changesets related to JDI to get it right. Here is the complete bug list: 6263966: TEST: com/sun/jdi/ClassesByName2Test.java has a race 6432567: PIT : com/sun/jdi/BadHandshakeTest.java fails due to java.net.ConnectException 6529758: JVMTI Waiters demo crashes. Double free. 6614052: jhat fails to read heap dump >2GB 6646613: ClassPrepareRequest.addSourceNameFilter() does not behave as documented 6700889: Thread resume invalidates all stack frames, even from other threads 6701700: MonitorInfo objects aren't invalidated when the owning thread is resumed 6725543: Compiler warnings in serviceability native code 6730273: TEST: JDI_REGRESSION test Solaris32AndSolaris64Test.sh fails if -XX:+UseCompressedOops is used 6737900: TEST: Some JDI regression tests timeout on slow machines 6751643: ThreadReference.ownedMonitors() can return null 6787605: OpenSolaris doesn't have /usr/ucb/ps so ShellScaffold fails 6855180: Fix classfile version check in java_crw_demo 6855551: java -Xrunhprof crashes when running with classes compiled with targed=7 6888927: Fix jdk jtreg tests to indicate which ones need othervm, allow for use of samevm option 6892742: Improve root set used by jhat 6893426: ShellScaffold.sh fails on Solaris 10 update releases: /usr/bin/id: illegal option -- u 6899444: Fix demo/jvmti tests so they can run in jtreg samevm mode, cleanup problemlist 6902323: Fix testcase sun/tools/native2ascii/NativeErrors.java 6902325: Fix testcase sun/tools/jhat/HatHeapDump1Test.java 6902667: Fix JT_HOME not working from env in jdk/test/Makefile 6903102: 3/3 fixes in nightly testing version of ShellScaffold.sh need to be committed 6904183: Fix jdk/test/com/sun/jdi tests to run with -samevm 6905705: Fix broken exit code values in jdk/test/Makefile 6906210: Fix another minor typo in test/Makefile -kto From Daniel.Daugherty at Sun.COM Mon Dec 7 12:42:23 2009 From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty) Date: Mon, 07 Dec 2009 13:42:23 -0700 Subject: Need approval, JDI updates to openjdk6 In-Reply-To: <4B1D50D6.2060604@sun.com> References: <4B1D50D6.2060604@sun.com> Message-ID: <4B1D68AF.7060808@sun.com> I'm also approving this without reviewing. Sorry, time is a little tight right now. Dan Kelly O'Hair wrote: > > OpenJDK6 changes for JDI. I'm ready to push. > > I would like approvals from Joe, Jim, Alan, Dan, and Tim. > > In the process of trying to get good test results running the openjdk6 > debugger (JDI) and jvmti tests (com/sun/jdi and demo/jvmti), I kept > running > into fixes made in jdk7 that were not in jdk6. > Since this functionality and apis are still jdk6, I took the liberty > of porting all of the openjdk7 JDI changes and JDI test changes to > openjdk6. > > These changes have all been reviewed for jdk7, and with a few minor > exceptions (i.e. -target 7 -source -7 in a few places) the resulting > files in openjdk6 now match openjdk7. > Please speak up if you have objections to this. > > The openjdk6 com/sun/jdi tests are stable now, however for some reason > I am unable to run them with 'jtreg -samevm', but all indications are > that this is unrelated to the JDI tests themselves (the same tests run > fine with -samevm in openjdk7). The jtreg -samevm runs fail with a jtreg > error: > Error. Error while cleaning up threads after test > and it is unpredictable as to what testcase it will happen with. > I'll investigate this again after the openjdk6 version of hotspot > is updated (I think it has 14.0 right now), I'm suspecting a hotspot fix > in 14.2 regarding threads might solve this (6772683, but that's a guess). > > Here is the complete webrev: > > > http://cr.openjdk.java.net/~ohair/openjdk6/jdk6-serviceability-update/webrev/ > > > One changeset contains several bugs because the changes to the files > overlapped so much. I tried to selectively bring in changesets from jdk7 > as I needed them, only realizing toward the end that I really needed all > changesets related to JDI to get it right. > > Here is the complete bug list: > > 6263966: TEST: com/sun/jdi/ClassesByName2Test.java has a race > 6432567: PIT : com/sun/jdi/BadHandshakeTest.java fails due to > java.net.ConnectException > 6529758: JVMTI Waiters demo crashes. Double free. > 6614052: jhat fails to read heap dump >2GB > 6646613: ClassPrepareRequest.addSourceNameFilter() does not behave as > documented > 6700889: Thread resume invalidates all stack frames, even from other > threads > 6701700: MonitorInfo objects aren't invalidated when the owning thread > is resumed > 6725543: Compiler warnings in serviceability native code > 6730273: TEST: JDI_REGRESSION test Solaris32AndSolaris64Test.sh fails > if -XX:+UseCompressedOops is used > 6737900: TEST: Some JDI regression tests timeout on slow machines > 6751643: ThreadReference.ownedMonitors() can return null > 6787605: OpenSolaris doesn't have /usr/ucb/ps so ShellScaffold fails > 6855180: Fix classfile version check in java_crw_demo > 6855551: java -Xrunhprof crashes when running with classes compiled > with targed=7 > 6888927: Fix jdk jtreg tests to indicate which ones need othervm, > allow for use of samevm option > 6892742: Improve root set used by jhat > 6893426: ShellScaffold.sh fails on Solaris 10 update releases: > /usr/bin/id: illegal option -- u > 6899444: Fix demo/jvmti tests so they can run in jtreg samevm mode, > cleanup problemlist > 6902323: Fix testcase sun/tools/native2ascii/NativeErrors.java > 6902325: Fix testcase sun/tools/jhat/HatHeapDump1Test.java > 6902667: Fix JT_HOME not working from env in jdk/test/Makefile > 6903102: 3/3 fixes in nightly testing version of ShellScaffold.sh need > to be committed > 6904183: Fix jdk/test/com/sun/jdi tests to run with -samevm > 6905705: Fix broken exit code values in jdk/test/Makefile > 6906210: Fix another minor typo in test/Makefile > > -kto > From gnu_andrew at member.fsf.org Mon Dec 7 13:12:29 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 7 Dec 2009 21:12:29 +0000 Subject: Need approval, JDI updates to openjdk6 In-Reply-To: <4B1D50D6.2060604@sun.com> References: <4B1D50D6.2060604@sun.com> Message-ID: <17c6771e0912071312g22ec4e70sd3a0abf81a7811af@mail.gmail.com> 2009/12/7 Kelly O'Hair : > > OpenJDK6 changes for JDI. I'm ready to push. > > I would like approvals from Joe, Jim, Alan, Dan, and Tim. > > In the process of trying to get good test results running the openjdk6 > debugger (JDI) and jvmti tests (com/sun/jdi and demo/jvmti), I kept running > into fixes made in jdk7 that were not in jdk6. > Since this functionality and apis are still jdk6, I took the liberty > of porting all of the openjdk7 JDI changes and JDI test changes to openjdk6. > > These changes have all been reviewed for jdk7, and with a few minor > exceptions (i.e. -target 7 -source -7 in a few places) the resulting > files in openjdk6 now match openjdk7. > Please speak up if you have objections to this. > > The openjdk6 com/sun/jdi tests are stable now, however for some reason > I am unable to run them with 'jtreg -samevm', but all indications are > that this is unrelated to the JDI tests themselves (the same tests run > fine with -samevm in openjdk7). The jtreg -samevm runs fail with a jtreg > error: > ? ? Error. Error while cleaning up threads after test > and it is unpredictable as to what testcase it will happen with. > I'll investigate this again after the openjdk6 version of hotspot > is updated (I think it has 14.0 right now), I'm suspecting a hotspot fix > in 14.2 regarding threads might solve this (6772683, but that's a guess). > > Here is the complete webrev: > > ?http://cr.openjdk.java.net/~ohair/openjdk6/jdk6-serviceability-update/webrev/ > > One changeset contains several bugs because the changes to the files > overlapped so much. I tried to selectively bring in changesets from jdk7 > as I needed them, only realizing toward the end that I really needed all > changesets related to JDI to get it right. > > Here is the complete bug list: > > 6263966: TEST: com/sun/jdi/ClassesByName2Test.java has a race > 6432567: PIT : com/sun/jdi/BadHandshakeTest.java fails due to > java.net.ConnectException > 6529758: JVMTI Waiters demo crashes. Double free. > 6614052: jhat fails to read heap dump >2GB > 6646613: ClassPrepareRequest.addSourceNameFilter() does not behave as > documented > 6700889: Thread resume invalidates all stack frames, even from other threads > 6701700: MonitorInfo objects aren't invalidated when the owning thread is > resumed > 6725543: Compiler warnings in serviceability native code > 6730273: TEST: JDI_REGRESSION test Solaris32AndSolaris64Test.sh fails if > -XX:+UseCompressedOops is used > 6737900: TEST: Some JDI regression tests timeout on slow machines > 6751643: ThreadReference.ownedMonitors() can return null > 6787605: OpenSolaris doesn't have /usr/ucb/ps so ShellScaffold fails > 6855180: Fix classfile version check in java_crw_demo > 6855551: java -Xrunhprof crashes when running with classes compiled with > targed=7 > 6888927: Fix jdk jtreg tests to indicate which ones need othervm, allow for > use of samevm option > 6892742: Improve root set used by jhat > 6893426: ShellScaffold.sh fails on Solaris 10 update releases: /usr/bin/id: > illegal option -- u > 6899444: Fix demo/jvmti tests so they can run in jtreg samevm mode, cleanup > problemlist > 6902323: Fix testcase sun/tools/native2ascii/NativeErrors.java > 6902325: Fix testcase sun/tools/jhat/HatHeapDump1Test.java > 6902667: Fix JT_HOME not working from env in jdk/test/Makefile > 6903102: 3/3 fixes in nightly testing version of ShellScaffold.sh need to be > committed > 6904183: Fix jdk/test/com/sun/jdi tests to run with -samevm > 6905705: Fix broken exit code values in jdk/test/Makefile > 6906210: Fix another minor typo in test/Makefile > > -kto > > Are you sure this webrev was created against OpenJDK6 correctly? There are changes to: Cdiffs Udiffs Sdiffs Frames Old New Patch Raw test/java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.java 72 lines changed: 7 ins; 57 del; 8 mod; 416 unchg Cdiffs Udiffs Sdiffs Frames Old New Patch Raw test/java/util/logging/LoggingDeadlock2.java 186 lines changed: 157 ins; 5 del; 24 mod; 60 unchg Cdiffs Udiffs Sdiffs Frames Old New Patch Raw test/sun/security/tools/keytool/StartDateTest.java which aren't part of the bug IDs above but were changed by recent pushes to OpenJDK6. Is this a merge changeset mixed in with the JDI changes? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Kelly.Ohair at Sun.COM Mon Dec 7 14:53:11 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 07 Dec 2009 14:53:11 -0800 Subject: Need approval, JDI updates to openjdk6 In-Reply-To: <17c6771e0912071312g22ec4e70sd3a0abf81a7811af@mail.gmail.com> References: <4B1D50D6.2060604@sun.com> <17c6771e0912071312g22ec4e70sd3a0abf81a7811af@mail.gmail.com> Message-ID: <4B1D8757.2030406@sun.com> Andrew John Hughes wrote: > 2009/12/7 Kelly O'Hair : >> OpenJDK6 changes for JDI. I'm ready to push. >> >> I would like approvals from Joe, Jim, Alan, Dan, and Tim. >> >> In the process of trying to get good test results running the openjdk6 >> debugger (JDI) and jvmti tests (com/sun/jdi and demo/jvmti), I kept running >> into fixes made in jdk7 that were not in jdk6. >> Since this functionality and apis are still jdk6, I took the liberty >> of porting all of the openjdk7 JDI changes and JDI test changes to openjdk6. >> >> These changes have all been reviewed for jdk7, and with a few minor >> exceptions (i.e. -target 7 -source -7 in a few places) the resulting >> files in openjdk6 now match openjdk7. >> Please speak up if you have objections to this. >> >> The openjdk6 com/sun/jdi tests are stable now, however for some reason >> I am unable to run them with 'jtreg -samevm', but all indications are >> that this is unrelated to the JDI tests themselves (the same tests run >> fine with -samevm in openjdk7). The jtreg -samevm runs fail with a jtreg >> error: >> Error. Error while cleaning up threads after test >> and it is unpredictable as to what testcase it will happen with. >> I'll investigate this again after the openjdk6 version of hotspot >> is updated (I think it has 14.0 right now), I'm suspecting a hotspot fix >> in 14.2 regarding threads might solve this (6772683, but that's a guess). >> >> Here is the complete webrev: >> >> http://cr.openjdk.java.net/~ohair/openjdk6/jdk6-serviceability-update/webrev/ >> >> One changeset contains several bugs because the changes to the files >> overlapped so much. I tried to selectively bring in changesets from jdk7 >> as I needed them, only realizing toward the end that I really needed all >> changesets related to JDI to get it right. >> >> Here is the complete bug list: >> >> 6263966: TEST: com/sun/jdi/ClassesByName2Test.java has a race >> 6432567: PIT : com/sun/jdi/BadHandshakeTest.java fails due to >> java.net.ConnectException >> 6529758: JVMTI Waiters demo crashes. Double free. >> 6614052: jhat fails to read heap dump >2GB >> 6646613: ClassPrepareRequest.addSourceNameFilter() does not behave as >> documented >> 6700889: Thread resume invalidates all stack frames, even from other threads >> 6701700: MonitorInfo objects aren't invalidated when the owning thread is >> resumed >> 6725543: Compiler warnings in serviceability native code >> 6730273: TEST: JDI_REGRESSION test Solaris32AndSolaris64Test.sh fails if >> -XX:+UseCompressedOops is used >> 6737900: TEST: Some JDI regression tests timeout on slow machines >> 6751643: ThreadReference.ownedMonitors() can return null >> 6787605: OpenSolaris doesn't have /usr/ucb/ps so ShellScaffold fails >> 6855180: Fix classfile version check in java_crw_demo >> 6855551: java -Xrunhprof crashes when running with classes compiled with >> targed=7 >> 6888927: Fix jdk jtreg tests to indicate which ones need othervm, allow for >> use of samevm option >> 6892742: Improve root set used by jhat >> 6893426: ShellScaffold.sh fails on Solaris 10 update releases: /usr/bin/id: >> illegal option -- u >> 6899444: Fix demo/jvmti tests so they can run in jtreg samevm mode, cleanup >> problemlist >> 6902323: Fix testcase sun/tools/native2ascii/NativeErrors.java >> 6902325: Fix testcase sun/tools/jhat/HatHeapDump1Test.java >> 6902667: Fix JT_HOME not working from env in jdk/test/Makefile >> 6903102: 3/3 fixes in nightly testing version of ShellScaffold.sh need to be >> committed >> 6904183: Fix jdk/test/com/sun/jdi tests to run with -samevm >> 6905705: Fix broken exit code values in jdk/test/Makefile >> 6906210: Fix another minor typo in test/Makefile >> >> -kto >> >> > > Are you sure this webrev was created against OpenJDK6 correctly? Well, I looks like I did, did a 'hg pull -u' and ran webrev. > There are changes to: > > Cdiffs Udiffs Sdiffs Frames Old New Patch Raw > test/java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.java > > 72 lines changed: 7 ins; 57 del; 8 mod; 416 unchg > > Cdiffs Udiffs Sdiffs Frames Old New Patch Raw > test/java/util/logging/LoggingDeadlock2.java > > 186 lines changed: 157 ins; 5 del; 24 mod; 60 unchg > > Cdiffs Udiffs Sdiffs Frames Old New Patch Raw > test/sun/security/tools/keytool/StartDateTest.java > > which aren't part of the bug IDs above but were changed by recent > pushes to OpenJDK6. Is this a merge changeset mixed in with the JDI > changes? It is due to a merge changeset, I did not change those files in my changesets. These come from rev 495de07832ca already in openjdk6, and also d7d0e90c9f72 (StartDateTest.java) already in openjdk. I haven't used a webrev on this many changsets before, seems like a bug to me in webrev. -kto From Tim.Bell at Sun.COM Mon Dec 7 15:34:23 2009 From: Tim.Bell at Sun.COM (Tim Bell) Date: Mon, 07 Dec 2009 15:34:23 -0800 Subject: Need approval, JDI updates to openjdk6 In-Reply-To: <4B1D8757.2030406@sun.com> References: <4B1D50D6.2060604@sun.com> <17c6771e0912071312g22ec4e70sd3a0abf81a7811af@mail.gmail.com> <4B1D8757.2030406@sun.com> Message-ID: <4B1D90FF.1070001@sun.com> Kelly O'Hair wrote: > Andrew John Hughes wrote: >> 2009/12/7 Kelly O'Hair : >>> OpenJDK6 changes for JDI. I'm ready to push. >>> >>> I would like approvals from Joe, Jim, Alan, Dan, and Tim. >>> >>> In the process of trying to get good test results running the openjdk6 >>> debugger (JDI) and jvmti tests (com/sun/jdi and demo/jvmti), I kept running >>> into fixes made in jdk7 that were not in jdk6. >>> Since this functionality and apis are still jdk6, I took the liberty >>> of porting all of the openjdk7 JDI changes and JDI test changes to openjdk6. >>> >>> These changes have all been reviewed for jdk7, and with a few minor >>> exceptions (i.e. -target 7 -source -7 in a few places) the resulting >>> files in openjdk6 now match openjdk7. >>> Please speak up if you have objections to this. >>> >>> The openjdk6 com/sun/jdi tests are stable now, however for some reason >>> I am unable to run them with 'jtreg -samevm', but all indications are >>> that this is unrelated to the JDI tests themselves (the same tests run >>> fine with -samevm in openjdk7). The jtreg -samevm runs fail with a jtreg >>> error: >>> Error. Error while cleaning up threads after test >>> and it is unpredictable as to what testcase it will happen with. >>> I'll investigate this again after the openjdk6 version of hotspot >>> is updated (I think it has 14.0 right now), I'm suspecting a hotspot fix >>> in 14.2 regarding threads might solve this (6772683, but that's a guess). >>> >>> Here is the complete webrev: >>> >>> http://cr.openjdk.java.net/~ohair/openjdk6/jdk6-serviceability-update/webrev/ >>> >>> One changeset contains several bugs because the changes to the files >>> overlapped so much. I tried to selectively bring in changesets from jdk7 >>> as I needed them, only realizing toward the end that I really needed all >>> changesets related to JDI to get it right. >>> >>> Here is the complete bug list: >>> >>> 6263966: TEST: com/sun/jdi/ClassesByName2Test.java has a race >>> 6432567: PIT : com/sun/jdi/BadHandshakeTest.java fails due to >>> java.net.ConnectException >>> 6529758: JVMTI Waiters demo crashes. Double free. >>> 6614052: jhat fails to read heap dump >2GB >>> 6646613: ClassPrepareRequest.addSourceNameFilter() does not behave as >>> documented >>> 6700889: Thread resume invalidates all stack frames, even from other threads >>> 6701700: MonitorInfo objects aren't invalidated when the owning thread is >>> resumed >>> 6725543: Compiler warnings in serviceability native code >>> 6730273: TEST: JDI_REGRESSION test Solaris32AndSolaris64Test.sh fails if >>> -XX:+UseCompressedOops is used >>> 6737900: TEST: Some JDI regression tests timeout on slow machines >>> 6751643: ThreadReference.ownedMonitors() can return null >>> 6787605: OpenSolaris doesn't have /usr/ucb/ps so ShellScaffold fails >>> 6855180: Fix classfile version check in java_crw_demo >>> 6855551: java -Xrunhprof crashes when running with classes compiled with >>> targed=7 >>> 6888927: Fix jdk jtreg tests to indicate which ones need othervm, allow for >>> use of samevm option >>> 6892742: Improve root set used by jhat >>> 6893426: ShellScaffold.sh fails on Solaris 10 update releases: /usr/bin/id: >>> illegal option -- u >>> 6899444: Fix demo/jvmti tests so they can run in jtreg samevm mode, cleanup >>> problemlist >>> 6902323: Fix testcase sun/tools/native2ascii/NativeErrors.java >>> 6902325: Fix testcase sun/tools/jhat/HatHeapDump1Test.java >>> 6902667: Fix JT_HOME not working from env in jdk/test/Makefile >>> 6903102: 3/3 fixes in nightly testing version of ShellScaffold.sh need to be >>> committed >>> 6904183: Fix jdk/test/com/sun/jdi tests to run with -samevm >>> 6905705: Fix broken exit code values in jdk/test/Makefile >>> 6906210: Fix another minor typo in test/Makefile >>> >>> -kto >>> >>> >> Are you sure this webrev was created against OpenJDK6 correctly? > > Well, I looks like I did, did a 'hg pull -u' and ran webrev. > >> There are changes to: >> >> Cdiffs Udiffs Sdiffs Frames Old New Patch Raw >> test/java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.java >> >> 72 lines changed: 7 ins; 57 del; 8 mod; 416 unchg >> >> Cdiffs Udiffs Sdiffs Frames Old New Patch Raw >> test/java/util/logging/LoggingDeadlock2.java >> >> 186 lines changed: 157 ins; 5 del; 24 mod; 60 unchg >> >> Cdiffs Udiffs Sdiffs Frames Old New Patch Raw >> test/sun/security/tools/keytool/StartDateTest.java >> >> which aren't part of the bug IDs above but were changed by recent >> pushes to OpenJDK6. Is this a merge changeset mixed in with the JDI >> changes? > > It is due to a merge changeset, I did not change those files in > my changesets. These come from rev 495de07832ca already in openjdk6, > and also d7d0e90c9f72 (StartDateTest.java) already in openjdk. If you are comfortable with the merge of these files: test/java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.java test/java/util/logging/LoggingDeadlock2.java test/sun/security/tools/keytool/StartDateTest.java I reviewed everything else, so I can approve that. Minor nit - Make this a separate test bug report: in test/sun/tools/native2ascii/NativeErrors.java.frames.html 83 f2.deleteOnExit(); Beware of Bug-ID 4171239 "File.deleteOnExit() does not work on open files (win32)" http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4171239 In general, jtreg tests should be good neighbors and close all open files (or clean up anything else they are able to) inside a finally block before finishing. There are some jtreg tests out there that create huge files in the TEMP directory, and then leave them behind. It creates a headache on nightly test machines, especially on Windows. > I haven't used a webrev on this many changsets before, seems like a bug > to me in webrev. Hmmm - puzzling. Tim From gnu_andrew at member.fsf.org Mon Dec 7 15:51:59 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 7 Dec 2009 23:51:59 +0000 Subject: Need approval, JDI updates to openjdk6 In-Reply-To: <4B1D8757.2030406@sun.com> References: <4B1D50D6.2060604@sun.com> <17c6771e0912071312g22ec4e70sd3a0abf81a7811af@mail.gmail.com> <4B1D8757.2030406@sun.com> Message-ID: <17c6771e0912071551k287854b0j9ba0ae401654ab95@mail.gmail.com> 2009/12/7 Kelly O'Hair : > > Andrew John Hughes wrote: >> >> 2009/12/7 Kelly O'Hair : >>> >>> OpenJDK6 changes for JDI. I'm ready to push. >>> >>> I would like approvals from Joe, Jim, Alan, Dan, and Tim. >>> >>> In the process of trying to get good test results running the openjdk6 >>> debugger (JDI) and jvmti tests (com/sun/jdi and demo/jvmti), I kept >>> running >>> into fixes made in jdk7 that were not in jdk6. >>> Since this functionality and apis are still jdk6, I took the liberty >>> of porting all of the openjdk7 JDI changes and JDI test changes to >>> openjdk6. >>> >>> These changes have all been reviewed for jdk7, and with a few minor >>> exceptions (i.e. -target 7 -source -7 in a few places) the resulting >>> files in openjdk6 now match openjdk7. >>> Please speak up if you have objections to this. >>> >>> The openjdk6 com/sun/jdi tests are stable now, however for some reason >>> I am unable to run them with 'jtreg -samevm', but all indications are >>> that this is unrelated to the JDI tests themselves (the same tests run >>> fine with -samevm in openjdk7). The jtreg -samevm runs fail with a jtreg >>> error: >>> ? ?Error. Error while cleaning up threads after test >>> and it is unpredictable as to what testcase it will happen with. >>> I'll investigate this again after the openjdk6 version of hotspot >>> is updated (I think it has 14.0 right now), I'm suspecting a hotspot fix >>> in 14.2 regarding threads might solve this (6772683, but that's a guess). >>> >>> Here is the complete webrev: >>> >>> >>> ?http://cr.openjdk.java.net/~ohair/openjdk6/jdk6-serviceability-update/webrev/ >>> >>> One changeset contains several bugs because the changes to the files >>> overlapped so much. I tried to selectively bring in changesets from jdk7 >>> as I needed them, only realizing toward the end that I really needed all >>> changesets related to JDI to get it right. >>> >>> Here is the complete bug list: >>> >>> 6263966: TEST: com/sun/jdi/ClassesByName2Test.java has a race >>> 6432567: PIT : com/sun/jdi/BadHandshakeTest.java fails due to >>> java.net.ConnectException >>> 6529758: JVMTI Waiters demo crashes. Double free. >>> 6614052: jhat fails to read heap dump >2GB >>> 6646613: ClassPrepareRequest.addSourceNameFilter() does not behave as >>> documented >>> 6700889: Thread resume invalidates all stack frames, even from other >>> threads >>> 6701700: MonitorInfo objects aren't invalidated when the owning thread is >>> resumed >>> 6725543: Compiler warnings in serviceability native code >>> 6730273: TEST: JDI_REGRESSION test Solaris32AndSolaris64Test.sh fails if >>> -XX:+UseCompressedOops is used >>> 6737900: TEST: Some JDI regression tests timeout on slow machines >>> 6751643: ThreadReference.ownedMonitors() can return null >>> 6787605: OpenSolaris doesn't have /usr/ucb/ps so ShellScaffold fails >>> 6855180: Fix classfile version check in java_crw_demo >>> 6855551: java -Xrunhprof crashes when running with classes compiled with >>> targed=7 >>> 6888927: Fix jdk jtreg tests to indicate which ones need othervm, allow >>> for >>> use of samevm option >>> 6892742: Improve root set used by jhat >>> 6893426: ShellScaffold.sh fails on Solaris 10 update releases: >>> /usr/bin/id: >>> illegal option -- u >>> 6899444: Fix demo/jvmti tests so they can run in jtreg samevm mode, >>> cleanup >>> problemlist >>> 6902323: Fix testcase sun/tools/native2ascii/NativeErrors.java >>> 6902325: Fix testcase sun/tools/jhat/HatHeapDump1Test.java >>> 6902667: Fix JT_HOME not working from env in jdk/test/Makefile >>> 6903102: 3/3 fixes in nightly testing version of ShellScaffold.sh need to >>> be >>> committed >>> 6904183: Fix jdk/test/com/sun/jdi tests to run with -samevm >>> 6905705: Fix broken exit code values in jdk/test/Makefile >>> 6906210: Fix another minor typo in test/Makefile >>> >>> -kto >>> >>> >> >> Are you sure this webrev was created against OpenJDK6 correctly? > > Well, I looks like I did, did a 'hg pull -u' and ran webrev. > >> There are changes to: >> >> Cdiffs Udiffs Sdiffs Frames Old New Patch Raw >> test/java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.java >> >> ? ?72 lines changed: 7 ins; 57 del; 8 mod; 416 unchg >> >> Cdiffs Udiffs Sdiffs Frames Old New Patch Raw >> test/java/util/logging/LoggingDeadlock2.java >> >> ? ?186 lines changed: 157 ins; 5 del; 24 mod; 60 unchg >> >> Cdiffs Udiffs Sdiffs Frames Old New Patch Raw >> test/sun/security/tools/keytool/StartDateTest.java >> >> which aren't part of the bug IDs above but were changed by recent >> pushes to OpenJDK6. ?Is this a merge changeset mixed in with the JDI >> changes? > > It is due to a merge changeset, I did not change those files in > my changesets. These come from rev 495de07832ca already in openjdk6, > and also d7d0e90c9f72 (StartDateTest.java) already in openjdk. > Yeah, I pushed two of the three. It's just confusing that it shows up commentless in the webrev rather than as 'Merge'. > I haven't used a webrev on this many changsets before, seems like a bug > to me in webrev. > Is there no way to tell webrev 'do these changesets'? Running webrev --help is rather unhelpful. If the rest is just backports of OpenJDK7 changesets, that seems fine to me. The closer the two are, the better. > -kto > > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Joe.Darcy at Sun.COM Mon Dec 7 18:46:35 2009 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Mon, 07 Dec 2009 18:46:35 -0800 Subject: Need approval, JDI updates to openjdk6 In-Reply-To: <4B1D50D6.2060604@sun.com> References: <4B1D50D6.2060604@sun.com> Message-ID: <4B1DBE0B.6080605@sun.com> Kelly O'Hair wrote: > > OpenJDK6 changes for JDI. I'm ready to push. > > I would like approvals from Joe, Jim, Alan, Dan, and Tim. Approved with comments. test/com/sun/jdi/StringConvertTest.sh 26 # @test @(#)StringConvertTest.sh 1.6 03/04/09 An expanded sccs keywork crept back in! Otherwise, it looks fine. Do you think a diff of the files compared to JDK 7 would be informative? -Joe From Joe.Darcy at Sun.COM Mon Dec 7 22:29:32 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Mon, 07 Dec 2009 22:29:32 -0800 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <4AFDC095.4060103@sun.com> References: <4AF4B948.5070702@sun.com> <17c6771e0911071712n1ee39648tcda8605c9682230a@mail.gmail.com> <4AF61D76.8040805@sun.com> <4AF5510B.4080309@sun.com> <17c6771e0911090821ne68ac97nc7e3e50d889b7ce9@mail.gmail.com> <4AF8D443.6080704@sun.com> <17c6771e0911100245p2cbd9d0cs5f24b00d46b89559@mail.gmail.com> <17c6771e0911110810v3fa4d6e7jb0a8cdae482300b8@mail.gmail.com> <4AFCEEA4.70009@sun.com> <17c6771e0911130845o6138d6bei1d8bb76c3fe13e4e@mail.gmail.com> <4AFDC095.4060103@sun.com> Message-ID: <4B1DF24C.9020308@sun.com> Joseph D. Darcy wrote: > Andrew John Hughes wrote: >> 2009/11/13 Joseph D. Darcy : >> >>> Andrew John Hughes wrote: >>> >>>> 2009/11/10 Andrew John Hughes : >>>> >>>> >>> [snip] >>> >>>> Still need to look at this, but was wondering what was happening with >>>> timezone data in 6? >>>> >>> It doesn't seem like much of anything is happening with timezone >>> data in >>> OpenJDK 6! [snip] >>>> >>> I'd appreciate if you could backport these timezone changes. >>> >>> -Joe >>> >>> >> >> Ok, no problem. >> >> So I make it for b18 we still have: >> >> * the issue with the X11 patch I can't apply because of jcheck >> > > I'll check in with Mark, but we're both speaking at Devoxx next week > so recognizing Latin-1 characters in jcheck may not happen immediately. > >> * Nimbus issues >> * the diff issue with HotSpot Martin pointed out >> > > Right. > >> Do we also want the timezone data changes for b18 or shall we do that >> in b19? I think b19's main feature is likely to be hs16. >> > > I think the time zone updates would be better in b18; the nature of > these changes is very well-understood. > Some time has passed, a few more fixes have come into the repos, and I'm beginning to think it would better to have OpenJDK 6 b18 be more or less what is there now and to have the timezone update and other changes go into b19. Thoughts? -Joe From Erik.Trimble at Sun.COM Mon Dec 7 22:40:30 2009 From: Erik.Trimble at Sun.COM (Erik Trimble) Date: Mon, 07 Dec 2009 22:40:30 -0800 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <4B1DF24C.9020308@sun.com> References: <4AF4B948.5070702@sun.com> <17c6771e0911071712n1ee39648tcda8605c9682230a@mail.gmail.com> <4AF61D76.8040805@sun.com> <4AF5510B.4080309@sun.com> <17c6771e0911090821ne68ac97nc7e3e50d889b7ce9@mail.gmail.com> <4AF8D443.6080704@sun.com> <17c6771e0911100245p2cbd9d0cs5f24b00d46b89559@mail.gmail.com> <17c6771e0911110810v3fa4d6e7jb0a8cdae482300b8@mail.gmail.com> <4AFCEEA4.70009@sun.com> <17c6771e0911130845o6138d6bei1d8bb76c3fe13e4e@mail.gmail.com> <4AFDC095.4060103@sun.com> <4B1DF24C.9020308@sun.com> Message-ID: <4B1DF4DE.5000402@sun.com> Joseph D. Darcy wrote: > Joseph D. Darcy wrote: >> Andrew John Hughes wrote: >>> 2009/11/13 Joseph D. Darcy : >>> >>>> Andrew John Hughes wrote: >>>> >>>>> 2009/11/10 Andrew John Hughes : >>>>> >>>>> >>>> [snip] >>>> >>>>> Still need to look at this, but was wondering what was happening with >>>>> timezone data in 6? >>>>> >>>> It doesn't seem like much of anything is happening with timezone >>>> data in >>>> OpenJDK 6! > [snip] > >>>>> >>>> I'd appreciate if you could backport these timezone changes. >>>> >>>> -Joe >>>> >>>> >>> >>> Ok, no problem. >>> >>> So I make it for b18 we still have: >>> >>> * the issue with the X11 patch I can't apply because of jcheck >>> >> >> I'll check in with Mark, but we're both speaking at Devoxx next week >> so recognizing Latin-1 characters in jcheck may not happen immediately. >> >>> * Nimbus issues >>> * the diff issue with HotSpot Martin pointed out >>> >> >> Right. >> >>> Do we also want the timezone data changes for b18 or shall we do that >>> in b19? I think b19's main feature is likely to be hs16. >>> >> >> I think the time zone updates would be better in b18; the nature of >> these changes is very well-understood. >> > > > Some time has passed, a few more fixes have come into the repos, and > I'm beginning to think it would better to have OpenJDK 6 b18 be more > or less what is there now and to have the timezone update and other > changes go into b19. > > Thoughts? > > -Joe I've got 3 more minor fixes for hs16 that are just finishing testing, which should finish hs16 as a shippable product. They should be done and integrated by Wednesday (maybe tomorrow, but no promises). It's up to you folks to decide if the should be part of b18 or not. -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) From gnu_andrew at member.fsf.org Tue Dec 8 05:29:26 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 8 Dec 2009 13:29:26 +0000 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <4B1DF24C.9020308@sun.com> References: <4AF4B948.5070702@sun.com> <4AF5510B.4080309@sun.com> <17c6771e0911090821ne68ac97nc7e3e50d889b7ce9@mail.gmail.com> <4AF8D443.6080704@sun.com> <17c6771e0911100245p2cbd9d0cs5f24b00d46b89559@mail.gmail.com> <17c6771e0911110810v3fa4d6e7jb0a8cdae482300b8@mail.gmail.com> <4AFCEEA4.70009@sun.com> <17c6771e0911130845o6138d6bei1d8bb76c3fe13e4e@mail.gmail.com> <4AFDC095.4060103@sun.com> <4B1DF24C.9020308@sun.com> Message-ID: <17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com> 2009/12/8 Joseph D. Darcy : > Joseph D. Darcy wrote: >> >> Andrew John Hughes wrote: >>> >>> 2009/11/13 Joseph D. Darcy : >>> >>>> >>>> Andrew John Hughes wrote: >>>> >>>>> >>>>> 2009/11/10 Andrew John Hughes : >>>>> >>>>> >>>> >>>> [snip] >>>> >>>>> >>>>> Still need to look at this, but was wondering what was happening with >>>>> timezone data in 6? >>>>> >>>> >>>> It doesn't seem like much of anything is happening with timezone data in >>>> OpenJDK 6! > > [snip] > >>>>> >>>> >>>> I'd appreciate if you could backport these timezone changes. >>>> >>>> -Joe >>>> >>>> >>> >>> Ok, no problem. >>> >>> So I make it for b18 we still have: >>> >>> ?* the issue with the X11 patch I can't apply because of jcheck >>> >> >> I'll check in with Mark, but we're both speaking at Devoxx next week so >> recognizing Latin-1 characters in jcheck may not happen immediately. >> >>> ?* Nimbus issues >>> ?* the diff issue with HotSpot Martin pointed out >>> >> >> Right. >> >>> Do we also want the timezone data changes for b18 or shall we do that >>> in b19? I think b19's main feature is likely to be hs16. >>> >> >> I think the time zone updates would be better in b18; the nature of these >> changes is very well-understood. >> > > > Some time has passed, a few more fixes have come into the repos, and I'm > beginning to think it would better to have OpenJDK 6 b18 be more or less > what is there now and to have the timezone update and other changes go into > b19. > > Thoughts? > > -Joe > Sorry, I've been distracted with first the OpenJDK7 release and then time off work. Backporting the timezone stuff should be fairly trivial. I'll have a try today and if it isn't, then we can consider delaying it. I think we do need to get the Nimbus fixes in. I'm trying to get IcedTea6 working against OpenJDK6 hg so I can test this, and all the JAXWS/JAXP changes don't make that a simple job. But it's in progress. Is there any news on updating jcheck? I still haven't been able to push the X11 fix. In response to Erik's e-mail, I'd be happier making HotSpot b16 part of b19 rather than b18, so we have more time for testing. So still: * Timezone fixes * Nimbus fixes * X11 fix for b18 from my side. Is there some rush to get this out? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Tue Dec 8 05:44:49 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 8 Dec 2009 13:44:49 +0000 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com> References: <4AF4B948.5070702@sun.com> <17c6771e0911090821ne68ac97nc7e3e50d889b7ce9@mail.gmail.com> <4AF8D443.6080704@sun.com> <17c6771e0911100245p2cbd9d0cs5f24b00d46b89559@mail.gmail.com> <17c6771e0911110810v3fa4d6e7jb0a8cdae482300b8@mail.gmail.com> <4AFCEEA4.70009@sun.com> <17c6771e0911130845o6138d6bei1d8bb76c3fe13e4e@mail.gmail.com> <4AFDC095.4060103@sun.com> <4B1DF24C.9020308@sun.com> <17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com> Message-ID: <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> 2009/12/8 Andrew John Hughes : > 2009/12/8 Joseph D. Darcy : >> Joseph D. Darcy wrote: >>> >>> Andrew John Hughes wrote: >>>> >>>> 2009/11/13 Joseph D. Darcy : >>>> >>>>> >>>>> Andrew John Hughes wrote: >>>>> >>>>>> >>>>>> 2009/11/10 Andrew John Hughes : >>>>>> >>>>>> >>>>> >>>>> [snip] >>>>> >>>>>> >>>>>> Still need to look at this, but was wondering what was happening with >>>>>> timezone data in 6? >>>>>> >>>>> >>>>> It doesn't seem like much of anything is happening with timezone data in >>>>> OpenJDK 6! >> >> [snip] >> >>>>>> >>>>> >>>>> I'd appreciate if you could backport these timezone changes. >>>>> >>>>> -Joe >>>>> >>>>> >>>> >>>> Ok, no problem. >>>> >>>> So I make it for b18 we still have: >>>> >>>> ?* the issue with the X11 patch I can't apply because of jcheck >>>> >>> >>> I'll check in with Mark, but we're both speaking at Devoxx next week so >>> recognizing Latin-1 characters in jcheck may not happen immediately. >>> >>>> ?* Nimbus issues >>>> ?* the diff issue with HotSpot Martin pointed out >>>> >>> >>> Right. >>> >>>> Do we also want the timezone data changes for b18 or shall we do that >>>> in b19? I think b19's main feature is likely to be hs16. >>>> >>> >>> I think the time zone updates would be better in b18; the nature of these >>> changes is very well-understood. >>> >> >> >> Some time has passed, a few more fixes have come into the repos, and I'm >> beginning to think it would better to have OpenJDK 6 b18 be more or less >> what is there now and to have the timezone update and other changes go into >> b19. >> >> Thoughts? >> >> -Joe >> > > Sorry, I've been distracted with first the OpenJDK7 release and then > time off work. ?Backporting the timezone stuff should be fairly > trivial. ?I'll have a try today and if it isn't, then we can consider > delaying it. > > I think we do need to get the Nimbus fixes in. ?I'm trying to get > IcedTea6 working against OpenJDK6 hg so I can test this, and all the > JAXWS/JAXP changes don't make that a simple job. ?But it's in > progress. > > Is there any news on updating jcheck? ?I still haven't been able to > push the X11 fix. > > In response to Erik's e-mail, I'd be happier making HotSpot b16 part > of b19 rather than b18, so we have more time for testing. > > So still: > > * Timezone fixes > * Nimbus fixes > * X11 fix > > for b18 from my side. ?Is there some rush to get this out? > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > Just remembered about Kelly's JDI work; that would be good to get in and being test-related, shouldn't break anything about the build or JDK itself. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Kelly.Ohair at Sun.COM Tue Dec 8 08:56:30 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 08 Dec 2009 08:56:30 -0800 Subject: Need approval, JDI updates to openjdk6 In-Reply-To: <4B1DBE0B.6080605@sun.com> References: <4B1D50D6.2060604@sun.com> <4B1DBE0B.6080605@sun.com> Message-ID: <4B1E853E.5050205@sun.com> Joe Darcy wrote: > Kelly O'Hair wrote: >> >> OpenJDK6 changes for JDI. I'm ready to push. >> >> I would like approvals from Joe, Jim, Alan, Dan, and Tim. > > Approved with comments. > > test/com/sun/jdi/StringConvertTest.sh > 26 # @test @(#)StringConvertTest.sh 1.6 03/04/09 > > An expanded sccs keywork crept back in! > > Otherwise, it looks fine. > > Do you think a diff of the files compared to JDK 7 would be informative? I actually did that on quite a few of the directories. Well, diff -r -w that is. Ignored whitespace differences. -kto > > -Joe > From Joe.Darcy at Sun.COM Tue Dec 8 09:05:35 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Tue, 08 Dec 2009 09:05:35 -0800 Subject: Need approval, JDI updates to openjdk6 In-Reply-To: <4B1E853E.5050205@sun.com> References: <4B1D50D6.2060604@sun.com> <4B1DBE0B.6080605@sun.com> <4B1E853E.5050205@sun.com> Message-ID: <4B1E875F.5090308@sun.com> Kelly O'Hair wrote: > > > Joe Darcy wrote: >> Kelly O'Hair wrote: >>> >>> OpenJDK6 changes for JDI. I'm ready to push. >>> >>> I would like approvals from Joe, Jim, Alan, Dan, and Tim. >> >> Approved with comments. >> >> test/com/sun/jdi/StringConvertTest.sh >> 26 # @test @(#)StringConvertTest.sh 1.6 03/04/09 >> >> An expanded sccs keywork crept back in! >> >> Otherwise, it looks fine. >> >> Do you think a diff of the files compared to JDK 7 would be informative? > > I actually did that on quite a few of the directories. > Well, diff -r -w that is. Ignored whitespace differences. > I thought you might say what the diffs were, "only non-whitespace diffs in ..." :-) -Joe From Joe.Darcy at Sun.COM Tue Dec 8 09:31:20 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Tue, 08 Dec 2009 09:31:20 -0800 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> References: <4AF4B948.5070702@sun.com> <17c6771e0911090821ne68ac97nc7e3e50d889b7ce9@mail.gmail.com> <4AF8D443.6080704@sun.com> <17c6771e0911100245p2cbd9d0cs5f24b00d46b89559@mail.gmail.com> <17c6771e0911110810v3fa4d6e7jb0a8cdae482300b8@mail.gmail.com> <4AFCEEA4.70009@sun.com> <17c6771e0911130845o6138d6bei1d8bb76c3fe13e4e@mail.gmail.com> <4AFDC095.4060103@sun.com> <4B1DF24C.9020308@sun.com> <17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> Message-ID: <4B1E8D68.3090709@sun.com> Andrew John Hughes wrote: > 2009/12/8 Andrew John Hughes : > >> 2009/12/8 Joseph D. Darcy : >> >>> Joseph D. Darcy wrote: >>> >>>> Andrew John Hughes wrote: >>>> >>>>> 2009/11/13 Joseph D. Darcy : >>>>> >>>>> >>>>>> Andrew John Hughes wrote: >>>>>> >>>>>> >>>>>>> 2009/11/10 Andrew John Hughes : >>>>>>> >>>>>>> >>>>>>> >>>>>> [snip] >>>>>> >>>>>> >>>>>>> Still need to look at this, but was wondering what was happening with >>>>>>> timezone data in 6? >>>>>>> >>>>>>> >>>>>> It doesn't seem like much of anything is happening with timezone data in >>>>>> OpenJDK 6! >>>>>> >>> [snip] >>> >>> >>>>>> I'd appreciate if you could backport these timezone changes. >>>>>> >>>>>> -Joe >>>>>> >>>>>> >>>>>> >>>>> Ok, no problem. >>>>> >>>>> So I make it for b18 we still have: >>>>> >>>>> * the issue with the X11 patch I can't apply because of jcheck >>>>> >>>>> >>>> I'll check in with Mark, but we're both speaking at Devoxx next week so >>>> recognizing Latin-1 characters in jcheck may not happen immediately. >>>> >>>> >>>>> * Nimbus issues >>>>> * the diff issue with HotSpot Martin pointed out >>>>> >>>>> >>>> Right. >>>> >>>> >>>>> Do we also want the timezone data changes for b18 or shall we do that >>>>> in b19? I think b19's main feature is likely to be hs16. >>>>> >>>>> >>>> I think the time zone updates would be better in b18; the nature of these >>>> changes is very well-understood. >>>> >>>> >>> Some time has passed, a few more fixes have come into the repos, and I'm >>> beginning to think it would better to have OpenJDK 6 b18 be more or less >>> what is there now and to have the timezone update and other changes go into >>> b19. >>> >>> Thoughts? >>> >>> -Joe >>> >>> >> Sorry, I've been distracted with first the OpenJDK7 release and then >> time off work. Backporting the timezone stuff should be fairly >> trivial. I'll have a try today and if it isn't, then we can consider >> delaying it. >> Okay. >> I think we do need to get the Nimbus fixes in. I'm trying to get >> IcedTea6 working against OpenJDK6 hg so I can test this, and all the >> JAXWS/JAXP changes don't make that a simple job. But it's in >> progress. >> >> Is there any news on updating jcheck? I still haven't been able to >> push the X11 fix. >> I've pinged Mark but haven't heard back. Unfortunately, the most expedient way to get this fix back to probably to ASCII-fy the contributor's name. >> In response to Erik's e-mail, I'd be happier making HotSpot b16 part >> of b19 rather than b18, so we have more time for testing. >> Yes, the HotSpot upgrade should occur in b19. >> So still: >> >> * Timezone fixes >> * Nimbus fixes >> Nimbus backports from JDK 7 I assume. >> * X11 fix >> >> for b18 from my side. Is there some rush to get this out? >> No rush per se, but with the holiday coming up (including my on vacation soon), if the build doesn't happen in the next week or so, it probably won't happen until January and I'd prefer to get a build with the security fixes officially out before then. > > Just remembered about Kelly's JDI work; that would be good to get in > and being test-related, shouldn't break anything about the build or > JDK itself. > There are a bunch of source changes too, but they have been in JDK 7 for a while so they should be fine for OpenJDK 6. -Joe From Kelly.Ohair at Sun.COM Tue Dec 8 10:04:02 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 08 Dec 2009 10:04:02 -0800 Subject: Need approval, JDI updates to openjdk6 In-Reply-To: <4B1E875F.5090308@sun.com> References: <4B1D50D6.2060604@sun.com> <4B1DBE0B.6080605@sun.com> <4B1E853E.5050205@sun.com> <4B1E875F.5090308@sun.com> Message-ID: <4B1E9512.2070707@sun.com> Joseph D. Darcy wrote: > Kelly O'Hair wrote: >> >> >> Joe Darcy wrote: >>> Kelly O'Hair wrote: >>>> >>>> OpenJDK6 changes for JDI. I'm ready to push. >>>> >>>> I would like approvals from Joe, Jim, Alan, Dan, and Tim. >>> >>> Approved with comments. >>> >>> test/com/sun/jdi/StringConvertTest.sh >>> 26 # @test @(#)StringConvertTest.sh 1.6 03/04/09 >>> >>> An expanded sccs keywork crept back in! >>> >>> Otherwise, it looks fine. >>> >>> Do you think a diff of the files compared to JDK 7 would be informative? >> >> I actually did that on quite a few of the directories. >> Well, diff -r -w that is. Ignored whitespace differences. >> > > I thought you might say what the diffs were, "only non-whitespace diffs > in ..." :-) > > -Joe > I went back and did another detailed diff between the latest in jdk7/tl and what I have. I did miss a few items, namely the removal of -source 1.5 on the JDI tests, Copyright year updates, and I missed a jhat source file change for the 2GB limit bug 6614052. Now when I compare these directories: src/*/classes/com/sun/tools/hat src/*/classes/com/sun/tools/jdi src/*/back src/*/transport src/*/demo/jvmti test/com/sun/jdi test/demo/jvmti test/sun/tools/jhat There are only 2 differences between the jdk7 and jdk6 files for JDI: 1. Solaris 8 stdint.h file missing change: diff -w jdk7-tl/jdk/src/solaris/back/util_md.h src/solaris/back/util_md.h 30d29 < #include /* To get uintptr_t */ 31a31,40 > /* To get uintptr_t */ > #ifdef LINUX > #include > #else > /* The file stdint.h is not on Solaris 8 machines. */ > #include > #include > #include > #endif > 2. Explicit difference for testing StackMap attributes: diff -w jdk7-tl/jdk/test/demo/jvmti/hprof/StackMapTableTest.java test/demo/jvmti/hprof/StackMapTableTest.java 30c30 < * @compile -source 7 -g:lines HelloWorld.java --- > * @compile -source 1.6 -g:lines HelloWorld.java I updated the webrev at: http://cr.openjdk.java.net/~ohair/openjdk6/jdk6-serviceability-update/webrev/ -kto From gnu_andrew at member.fsf.org Tue Dec 8 10:10:38 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 8 Dec 2009 18:10:38 +0000 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <4B1E8D68.3090709@sun.com> References: <4AF4B948.5070702@sun.com> <17c6771e0911100245p2cbd9d0cs5f24b00d46b89559@mail.gmail.com> <17c6771e0911110810v3fa4d6e7jb0a8cdae482300b8@mail.gmail.com> <4AFCEEA4.70009@sun.com> <17c6771e0911130845o6138d6bei1d8bb76c3fe13e4e@mail.gmail.com> <4AFDC095.4060103@sun.com> <4B1DF24C.9020308@sun.com> <17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> Message-ID: <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> 2009/12/8 Joseph D. Darcy : > Andrew John Hughes wrote: >> >> 2009/12/8 Andrew John Hughes : >> >>> >>> 2009/12/8 Joseph D. Darcy : >>> >>>> >>>> Joseph D. Darcy wrote: >>>> >>>>> >>>>> Andrew John Hughes wrote: >>>>> >>>>>> >>>>>> 2009/11/13 Joseph D. Darcy : >>>>>> >>>>>> >>>>>>> >>>>>>> Andrew John Hughes wrote: >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> 2009/11/10 Andrew John Hughes : >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> [snip] >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Still need to look at this, but was wondering what was happening >>>>>>>> with >>>>>>>> timezone data in 6? >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> It doesn't seem like much of anything is happening with timezone data >>>>>>> in >>>>>>> OpenJDK 6! >>>>>>> >>>> >>>> [snip] >>>> >>>> >>>>>>> >>>>>>> I'd appreciate if you could backport these timezone changes. >>>>>>> >>>>>>> -Joe >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> Ok, no problem. >>>>>> >>>>>> So I make it for b18 we still have: >>>>>> >>>>>> ?* the issue with the X11 patch I can't apply because of jcheck >>>>>> >>>>>> >>>>> >>>>> I'll check in with Mark, but we're both speaking at Devoxx next week so >>>>> recognizing Latin-1 characters in jcheck may not happen immediately. >>>>> >>>>> >>>>>> >>>>>> ?* Nimbus issues >>>>>> ?* the diff issue with HotSpot Martin pointed out >>>>>> >>>>>> >>>>> >>>>> Right. >>>>> >>>>> >>>>>> >>>>>> Do we also want the timezone data changes for b18 or shall we do that >>>>>> in b19? I think b19's main feature is likely to be hs16. >>>>>> >>>>>> >>>>> >>>>> I think the time zone updates would be better in b18; the nature of >>>>> these >>>>> changes is very well-understood. >>>>> >>>>> >>>> >>>> Some time has passed, a few more fixes have come into the repos, and I'm >>>> beginning to think it would better to have OpenJDK 6 b18 be more or less >>>> what is there now and to have the timezone update and other changes go >>>> into >>>> b19. >>>> >>>> Thoughts? >>>> >>>> -Joe >>>> >>>> >>> >>> Sorry, I've been distracted with first the OpenJDK7 release and then >>> time off work. ?Backporting the timezone stuff should be fairly >>> trivial. ?I'll have a try today and if it isn't, then we can consider >>> delaying it. >>> > > Okay. > >>> I think we do need to get the Nimbus fixes in. ?I'm trying to get >>> IcedTea6 working against OpenJDK6 hg so I can test this, and all the >>> JAXWS/JAXP changes don't make that a simple job. ?But it's in >>> progress. >>> >>> Is there any news on updating jcheck? ?I still haven't been able to >>> push the X11 fix. >>> > > I've pinged Mark but haven't heard back. > > Unfortunately, the most expedient way to get this fix back to probably to > ASCII-fy the contributor's name. > I've already tried that. Whatever jcheck is doing goes beyond ASCII as it doesn't accept a backtick either (o` is the ASCIIfied version) As with other issues with jcheck, if it was open-sourced we wouldn't have Mark as a bottleneck for fixing the inevitable issues with it. This is a fairly serious issue; I currently can't build OpenJDK6 unless I apply that patch first and no doubt others will see this too (all F12 users for a start). >>> In response to Erik's e-mail, I'd be happier making HotSpot b16 part >>> of b19 rather than b18, so we have more time for testing. >>> > > Yes, the HotSpot upgrade should occur in b19. > >>> So still: >>> >>> * Timezone fixes >>> * Nimbus fixes >>> > > Nimbus backports from JDK 7 I assume. > There is one, but I was thinking of the test issues you raised in previous emails. >>> * X11 fix >>> >>> for b18 from my side. ?Is there some rush to get this out? >>> > > No rush per se, but with the holiday coming up (including my on vacation > soon), if the build doesn't happen in the next week or so, it probably won't > happen until January and I'd prefer to get a build with the security fixes > officially out before then. > Well, I think most things can probably be sorted this week. The X11 fix is the real blocker. Can we not just turn jcheck off or something for one commit? I'm currently building OpenJDK6 with the timezone fixes applied and it looks ok so far. I'll post a webrev once it completes. There are two more tz issues worthy of consideration that I didn't include yet because they are not related to the data, but would be good to have. One adds support for old timezone IDs (I'm wary of this because it introduces a property) and the other fixes an issue with determining the timezone on GNU/Linux boxes which I believe will obsolete a different but related fix in IcedTea6. I'd also like to add a simple patch which fixes up the remaining data differences between 6 and 7 (just typos and revision headers) which seems to have occurred in the black hole between the OpenJDK6 fork and the OpenJDK7 hg repositories. Finally, during build, I just spotted another issue. The langtools build wrongly passes -Werror to javac and this has been removed in the OpenJDK7 version. It only shows up if you build OpenJDK6 with OpenJDK7, so it's minor but probably worth fixing. I doubt that is the only building-with-7 issue though. >> >> Just remembered about Kelly's JDI work; that would be good to get in >> and being test-related, shouldn't break anything about the build or >> JDK itself. >> > > There are a bunch of source changes too, but they have been in JDK 7 for a > while so they should be fine for OpenJDK 6. > > -Joe > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Tue Dec 8 10:19:52 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 8 Dec 2009 18:19:52 +0000 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> References: <4AF4B948.5070702@sun.com> <17c6771e0911110810v3fa4d6e7jb0a8cdae482300b8@mail.gmail.com> <4AFCEEA4.70009@sun.com> <17c6771e0911130845o6138d6bei1d8bb76c3fe13e4e@mail.gmail.com> <4AFDC095.4060103@sun.com> <4B1DF24C.9020308@sun.com> <17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> Message-ID: <17c6771e0912081019i234a9646pfa24ecf4551ac33b@mail.gmail.com> 2009/12/8 Andrew John Hughes : > 2009/12/8 Joseph D. Darcy : >> Andrew John Hughes wrote: >>> >>> 2009/12/8 Andrew John Hughes : >>> >>>> >>>> 2009/12/8 Joseph D. Darcy : >>>> >>>>> >>>>> Joseph D. Darcy wrote: >>>>> >>>>>> >>>>>> Andrew John Hughes wrote: >>>>>> >>>>>>> >>>>>>> 2009/11/13 Joseph D. Darcy : >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Andrew John Hughes wrote: >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> 2009/11/10 Andrew John Hughes : >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> [snip] >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Still need to look at this, but was wondering what was happening >>>>>>>>> with >>>>>>>>> timezone data in 6? >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> It doesn't seem like much of anything is happening with timezone data >>>>>>>> in >>>>>>>> OpenJDK 6! >>>>>>>> >>>>> >>>>> [snip] >>>>> >>>>> >>>>>>>> >>>>>>>> I'd appreciate if you could backport these timezone changes. >>>>>>>> >>>>>>>> -Joe >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Ok, no problem. >>>>>>> >>>>>>> So I make it for b18 we still have: >>>>>>> >>>>>>> ?* the issue with the X11 patch I can't apply because of jcheck >>>>>>> >>>>>>> >>>>>> >>>>>> I'll check in with Mark, but we're both speaking at Devoxx next week so >>>>>> recognizing Latin-1 characters in jcheck may not happen immediately. >>>>>> >>>>>> >>>>>>> >>>>>>> ?* Nimbus issues >>>>>>> ?* the diff issue with HotSpot Martin pointed out >>>>>>> >>>>>>> >>>>>> >>>>>> Right. >>>>>> >>>>>> >>>>>>> >>>>>>> Do we also want the timezone data changes for b18 or shall we do that >>>>>>> in b19? I think b19's main feature is likely to be hs16. >>>>>>> >>>>>>> >>>>>> >>>>>> I think the time zone updates would be better in b18; the nature of >>>>>> these >>>>>> changes is very well-understood. >>>>>> >>>>>> >>>>> >>>>> Some time has passed, a few more fixes have come into the repos, and I'm >>>>> beginning to think it would better to have OpenJDK 6 b18 be more or less >>>>> what is there now and to have the timezone update and other changes go >>>>> into >>>>> b19. >>>>> >>>>> Thoughts? >>>>> >>>>> -Joe >>>>> >>>>> >>>> >>>> Sorry, I've been distracted with first the OpenJDK7 release and then >>>> time off work. ?Backporting the timezone stuff should be fairly >>>> trivial. ?I'll have a try today and if it isn't, then we can consider >>>> delaying it. >>>> >> >> Okay. >> >>>> I think we do need to get the Nimbus fixes in. ?I'm trying to get >>>> IcedTea6 working against OpenJDK6 hg so I can test this, and all the >>>> JAXWS/JAXP changes don't make that a simple job. ?But it's in >>>> progress. >>>> >>>> Is there any news on updating jcheck? ?I still haven't been able to >>>> push the X11 fix. >>>> >> >> I've pinged Mark but haven't heard back. >> >> Unfortunately, the most expedient way to get this fix back to probably to >> ASCII-fy the contributor's name. >> > > I've already tried that. ?Whatever jcheck is doing goes beyond ASCII > as it doesn't accept a backtick either (o` is the ASCIIfied version) > > As with other issues with jcheck, if it was open-sourced we wouldn't > have Mark as a bottleneck for fixing the inevitable issues with it. > > This is a fairly serious issue; I currently can't build OpenJDK6 > unless I apply that patch first and no doubt others will see this too > (all F12 users for a start). > >>>> In response to Erik's e-mail, I'd be happier making HotSpot b16 part >>>> of b19 rather than b18, so we have more time for testing. >>>> >> >> Yes, the HotSpot upgrade should occur in b19. >> >>>> So still: >>>> >>>> * Timezone fixes >>>> * Nimbus fixes >>>> >> >> Nimbus backports from JDK 7 I assume. >> > > There is one, but I was thinking of the test issues you raised in > previous emails. > >>>> * X11 fix >>>> >>>> for b18 from my side. ?Is there some rush to get this out? >>>> >> >> No rush per se, but with the holiday coming up (including my on vacation >> soon), if the build doesn't happen in the next week or so, it probably won't >> happen until January and I'd prefer to get a build with the security fixes >> officially out before then. >> > > Well, I think most things can probably be sorted this week. ?The X11 > fix is the real blocker. ?Can we not just turn jcheck off or something > for one commit? > > I'm currently building OpenJDK6 with the timezone fixes applied and it > looks ok so far. ?I'll post a webrev once it completes. > > There are two more tz issues worthy of consideration that I didn't > include yet because they are not related to the data, but would be > good to have. ?One adds support for old timezone IDs (I'm wary of this > because it introduces a property) and the other fixes an issue with > determining the timezone on GNU/Linux boxes which I believe will > obsolete a different but related fix in IcedTea6. ?I'd also like to > add a simple patch which fixes up the remaining data differences > between 6 and 7 (just typos and revision headers) which seems to have > occurred in the black hole between the OpenJDK6 fork and the OpenJDK7 > hg repositories. > > Finally, during build, I just spotted another issue. ?The langtools > build wrongly passes -Werror to javac and this has been removed in the > OpenJDK7 version. ?It only shows up if you build OpenJDK6 with > OpenJDK7, so it's minor but probably worth fixing. ?I doubt that is > the only building-with-7 issue though. > >>> >>> Just remembered about Kelly's JDI work; that would be good to get in >>> and being test-related, shouldn't break anything about the build or >>> JDK itself. >>> >> >> There are a bunch of source changes too, but they have been in JDK 7 for a >> while so they should be fine for OpenJDK 6. >> >> -Joe >> > > > > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > No sooner did I write that than it built: http://cr.openjdk.java.net/~andrew/tz/webrev.01/ The remaining three tz fixes are: changeset: 639:67c41d740e6d user: peytoia date: Mon Sep 08 15:21:55 2008 +0900 summary: 6466476: (tz) Introduction of tzdata2005r can introduce incompatility issues with some JDK1.1 3-letter TZ Ids http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/67c41d740e6d changeset: 1693:92b6482e7719 user: peytoia date: Mon Aug 31 14:53:05 2009 +0900 summary: 6456628: (tz) Default timezone is incorrectly set occasionally on Linux http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/92b6482e7719 and http://cr.openjdk.java.net/~andrew/tz/webrev.02 which needs a bug ID. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Jonathan.Gibbons at Sun.COM Tue Dec 8 10:35:22 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Tue, 08 Dec 2009 10:35:22 -0800 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> References: <4AF4B948.5070702@sun.com> <17c6771e0911100245p2cbd9d0cs5f24b00d46b89559@mail.gmail.com> <17c6771e0911110810v3fa4d6e7jb0a8cdae482300b8@mail.gmail.com> <4AFCEEA4.70009@sun.com> <17c6771e0911130845o6138d6bei1d8bb76c3fe13e4e@mail.gmail.com> <4AFDC095.4060103@sun.com> <4B1DF24C.9020308@sun.com> <17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> Message-ID: <4B1E9C6A.8050704@sun.com> Andrew John Hughes wrote: > > > Finally, during build, I just spotted another issue. The langtools > build wrongly passes -Werror to javac and this has been removed in the > OpenJDK7 version. It only shows up if you build OpenJDK6 with > OpenJDK7, so it's minor but probably worth fixing. I doubt that is > the only building-with-7 issue though. > langtools is supposed to be warning free and thus is supposed to use -Werror. -- Jon From Kelly.Ohair at Sun.COM Tue Dec 8 10:43:06 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 08 Dec 2009 10:43:06 -0800 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <4B1E9C6A.8050704@sun.com> References: <4AF4B948.5070702@sun.com> <17c6771e0911100245p2cbd9d0cs5f24b00d46b89559@mail.gmail.com> <17c6771e0911110810v3fa4d6e7jb0a8cdae482300b8@mail.gmail.com> <4AFCEEA4.70009@sun.com> <17c6771e0911130845o6138d6bei1d8bb76c3fe13e4e@mail.gmail.com> <4AFDC095.4060103@sun.com> <4B1DF24C.9020308@sun.com> <17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> <4B1E9C6A.8050704@sun.com> Message-ID: <4B1E9E3A.7060008@sun.com> Jonathan Gibbons wrote: > Andrew John Hughes wrote: >> >> >> Finally, during build, I just spotted another issue. The langtools >> build wrongly passes -Werror to javac and this has been removed in the >> OpenJDK7 version. It only shows up if you build OpenJDK6 with >> OpenJDK7, so it's minor but probably worth fixing. I doubt that is >> the only building-with-7 issue though. Building OpenJDK6 "with" OpenJDK7? You mean with an ALT_BOOTDIR=jdk7? Why? -kto >> > > langtools is supposed to be warning free and thus is supposed to use > -Werror. > > -- Jon From martinrb at google.com Tue Dec 8 11:42:48 2009 From: martinrb at google.com (Martin Buchholz) Date: Tue, 8 Dec 2009 11:42:48 -0800 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <4B1E9E3A.7060008@sun.com> References: <4AF4B948.5070702@sun.com> <17c6771e0911130845o6138d6bei1d8bb76c3fe13e4e@mail.gmail.com> <4AFDC095.4060103@sun.com> <4B1DF24C.9020308@sun.com> <17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> <4B1E9C6A.8050704@sun.com> <4B1E9E3A.7060008@sun.com> Message-ID: <1ccfd1c10912081142l7f65a70cvc7531bcfe592f2bd@mail.gmail.com> > Building OpenJDK6 ?"with" ?OpenJDK7? > You mean with an ALT_BOOTDIR=jdk7? Why? Many people believe that: openjdk7 is the best implementation of java 6 From gnu_andrew at member.fsf.org Tue Dec 8 11:43:44 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 8 Dec 2009 19:43:44 +0000 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <4B1E9C6A.8050704@sun.com> References: <4AF4B948.5070702@sun.com> <4AFCEEA4.70009@sun.com> <17c6771e0911130845o6138d6bei1d8bb76c3fe13e4e@mail.gmail.com> <4AFDC095.4060103@sun.com> <4B1DF24C.9020308@sun.com> <17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> <4B1E9C6A.8050704@sun.com> Message-ID: <17c6771e0912081143pe31d4dk122c689ae003db16@mail.gmail.com> 2009/12/8 Jonathan Gibbons : > Andrew John Hughes wrote: >> >> >> Finally, during build, I just spotted another issue. ?The langtools >> build wrongly passes -Werror to javac and this has been removed in the >> OpenJDK7 version. ?It only shows up if you build OpenJDK6 with >> OpenJDK7, so it's minor but probably worth fixing. ?I doubt that is >> the only building-with-7 issue though. >> > > langtools is supposed to be warning free and thus is supposed to use > -Werror. > > -- Jon > Not according to this changeset of yours: http://hg.openjdk.java.net/jdk7/jdk7/langtools/rev/12c9e612e9e31 and OpenJDK6's version certainly fails with -Werror on and effective (using javac from 1.7). -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From martinrb at google.com Tue Dec 8 11:47:00 2009 From: martinrb at google.com (Martin Buchholz) Date: Tue, 8 Dec 2009 11:47:00 -0800 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> References: <4AF4B948.5070702@sun.com> <17c6771e0911110810v3fa4d6e7jb0a8cdae482300b8@mail.gmail.com> <4AFCEEA4.70009@sun.com> <17c6771e0911130845o6138d6bei1d8bb76c3fe13e4e@mail.gmail.com> <4AFDC095.4060103@sun.com> <4B1DF24C.9020308@sun.com> <17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> Message-ID: <1ccfd1c10912081147j5fc94f5bt3618fd05609dc031@mail.gmail.com> On Tue, Dec 8, 2009 at 10:10, Andrew John Hughes wrote: >> Unfortunately, the most expedient way to get this fix back to probably to >> ASCII-fy the contributor's name. >> > > I've already tried that. ?Whatever jcheck is doing goes beyond ASCII > as it doesn't accept a backtick either (o` is the ASCIIfied version) Probably you have to go further and [A-Za-z]ify it Martin From gnu_andrew at member.fsf.org Tue Dec 8 11:47:16 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 8 Dec 2009 19:47:16 +0000 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <4B1E9E3A.7060008@sun.com> References: <4AF4B948.5070702@sun.com> <17c6771e0911130845o6138d6bei1d8bb76c3fe13e4e@mail.gmail.com> <4AFDC095.4060103@sun.com> <4B1DF24C.9020308@sun.com> <17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> <4B1E9C6A.8050704@sun.com> <4B1E9E3A.7060008@sun.com> Message-ID: <17c6771e0912081147o69c95111m6ecd79a0b69da5ca@mail.gmail.com> 2009/12/8 Kelly O'Hair : > > > Jonathan Gibbons wrote: >> >> Andrew John Hughes wrote: >>> >>> >>> Finally, during build, I just spotted another issue. ?The langtools >>> build wrongly passes -Werror to javac and this has been removed in the >>> OpenJDK7 version. ?It only shows up if you build OpenJDK6 with >>> OpenJDK7, so it's minor but probably worth fixing. ?I doubt that is >>> the only building-with-7 issue though. > > Building OpenJDK6 ?"with" ?OpenJDK7? > You mean with an ALT_BOOTDIR=jdk7? Why? > Why not? I happen to have a system install of OpenJDK7 m5 and not OpenJDK6 at present - the reason for that is exactly because you can't install 7 and then use it to build 6. I've since been able to build OpenJDK6 using a recent build of IcedTea6 (which uses gcj to build). But surely 7 should be able to build 6? > -kto > >>> >> >> langtools is supposed to be warning free and thus is supposed to use >> -Werror. >> >> -- Jon > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Joe.Darcy at Sun.COM Tue Dec 8 11:48:06 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Tue, 08 Dec 2009 11:48:06 -0800 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <17c6771e0912081143pe31d4dk122c689ae003db16@mail.gmail.com> References: <4AF4B948.5070702@sun.com> <4AFCEEA4.70009@sun.com> <17c6771e0911130845o6138d6bei1d8bb76c3fe13e4e@mail.gmail.com> <4AFDC095.4060103@sun.com> <4B1DF24C.9020308@sun.com> <17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> <4B1E9C6A.8050704@sun.com> <17c6771e0912081143pe31d4dk122c689ae003db16@mail.gmail.com> Message-ID: <4B1EAD76.7000000@sun.com> Andrew John Hughes wrote: > 2009/12/8 Jonathan Gibbons : > >> Andrew John Hughes wrote: >> >>> Finally, during build, I just spotted another issue. The langtools >>> build wrongly passes -Werror to javac and this has been removed in the >>> OpenJDK7 version. It only shows up if you build OpenJDK6 with >>> OpenJDK7, so it's minor but probably worth fixing. I doubt that is >>> the only building-with-7 issue though. >>> >>> >> langtools is supposed to be warning free and thus is supposed to use >> -Werror. >> >> -- Jon >> >> > > Not according to this changeset of yours: > > http://hg.openjdk.java.net/jdk7/jdk7/langtools/rev/12c9e612e9e31 > The removal of Werror from langtools in JDK 7 was a transitory change; it came back as part of Jon's subsequent changset: http://hg.openjdk.java.net/jdk7/jdk7/langtools/rev/b4b1f7732289 -Joe From gnu_andrew at member.fsf.org Tue Dec 8 11:50:48 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 8 Dec 2009 19:50:48 +0000 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <4B1EAD76.7000000@sun.com> References: <4AF4B948.5070702@sun.com> <4AFDC095.4060103@sun.com> <4B1DF24C.9020308@sun.com> <17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> <4B1E9C6A.8050704@sun.com> <17c6771e0912081143pe31d4dk122c689ae003db16@mail.gmail.com> <4B1EAD76.7000000@sun.com> Message-ID: <17c6771e0912081150g23762b5dw1b7ff5aa052b8c78@mail.gmail.com> 2009/12/8 Joseph D. Darcy : > Andrew John Hughes wrote: >> >> 2009/12/8 Jonathan Gibbons : >> >>> >>> Andrew John Hughes wrote: >>> >>>> >>>> Finally, during build, I just spotted another issue. ?The langtools >>>> build wrongly passes -Werror to javac and this has been removed in the >>>> OpenJDK7 version. ?It only shows up if you build OpenJDK6 with >>>> OpenJDK7, so it's minor but probably worth fixing. ?I doubt that is >>>> the only building-with-7 issue though. >>>> >>>> >>> >>> langtools is supposed to be warning free and thus is supposed to use >>> -Werror. >>> >>> -- Jon >>> >>> >> >> Not according to this changeset of yours: >> >> http://hg.openjdk.java.net/jdk7/jdk7/langtools/rev/12c9e612e9e31 >> > > The removal of Werror from langtools in JDK 7 was a transitory change; it > came back as part of Jon's subsequent changset: > > http://hg.openjdk.java.net/jdk7/jdk7/langtools/rev/b4b1f7732289 > Ok, even better -- then we need to backport that changeset. > -Joe > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Joe.Darcy at Sun.COM Tue Dec 8 11:51:12 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Tue, 08 Dec 2009 11:51:12 -0800 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <17c6771e0912081147o69c95111m6ecd79a0b69da5ca@mail.gmail.com> References: <4AF4B948.5070702@sun.com> <17c6771e0911130845o6138d6bei1d8bb76c3fe13e4e@mail.gmail.com> <4AFDC095.4060103@sun.com> <4B1DF24C.9020308@sun.com> <17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> <4B1E9C6A.8050704@sun.com> <4B1E9E3A.7060008@sun.com> <17c6771e0912081147o69c95111m6ecd79a0b69da5ca@mail.gmail.com> Message-ID: <4B1EAE30.9080807@sun.com> Andrew John Hughes wrote: > 2009/12/8 Kelly O'Hair : > >> Jonathan Gibbons wrote: >> >>> Andrew John Hughes wrote: >>> >>>> Finally, during build, I just spotted another issue. The langtools >>>> build wrongly passes -Werror to javac and this has been removed in the >>>> OpenJDK7 version. It only shows up if you build OpenJDK6 with >>>> OpenJDK7, so it's minor but probably worth fixing. I doubt that is >>>> the only building-with-7 issue though. >>>> >> Building OpenJDK6 "with" OpenJDK7? >> You mean with an ALT_BOOTDIR=jdk7? Why? >> >> > > Why not? I happen to have a system install of OpenJDK7 m5 and not > OpenJDK6 at present - the reason for that is exactly because you can't > install 7 and then use it to build 6. I've since been able to build > OpenJDK6 using a recent build of IcedTea6 (which uses gcj to build). > But surely 7 should be able to build 6? > I suspect the build issue is that the JDK 7 Werror checking is more stringent than the OpenJDK 6 error checking and the OpenJDK 6 sources do not have the fixes necessary to build under JDK 7 using Werror although they do build under OpenJDK 6 with Werror. -Joe From gnu_andrew at member.fsf.org Tue Dec 8 11:52:14 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 8 Dec 2009 19:52:14 +0000 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <1ccfd1c10912081147j5fc94f5bt3618fd05609dc031@mail.gmail.com> References: <4AF4B948.5070702@sun.com> <4AFCEEA4.70009@sun.com> <17c6771e0911130845o6138d6bei1d8bb76c3fe13e4e@mail.gmail.com> <4AFDC095.4060103@sun.com> <4B1DF24C.9020308@sun.com> <17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> <1ccfd1c10912081147j5fc94f5bt3618fd05609dc031@mail.gmail.com> Message-ID: <17c6771e0912081152r69694377lfa2d97a536c5d901@mail.gmail.com> 2009/12/8 Martin Buchholz : > On Tue, Dec 8, 2009 at 10:10, Andrew John Hughes > wrote: > >>> Unfortunately, the most expedient way to get this fix back to probably to >>> ASCII-fy the contributor's name. >>> >> >> I've already tried that. ?Whatever jcheck is doing goes beyond ASCII >> as it doesn't accept a backtick either (o` is the ASCIIfied version) > > Probably you have to go further and [A-Za-z]ify it > At which point we credit someone else - Petteno is a different surname to Petteno` The more general question is why we have an proprietary script making arbitrary decisions about valid changesets for an open source project. > Martin > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Joe.Darcy at Sun.COM Tue Dec 8 11:52:16 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Tue, 08 Dec 2009 11:52:16 -0800 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <1ccfd1c10912081147j5fc94f5bt3618fd05609dc031@mail.gmail.com> References: <4AF4B948.5070702@sun.com> <17c6771e0911110810v3fa4d6e7jb0a8cdae482300b8@mail.gmail.com> <4AFCEEA4.70009@sun.com> <17c6771e0911130845o6138d6bei1d8bb76c3fe13e4e@mail.gmail.com> <4AFDC095.4060103@sun.com> <4B1DF24C.9020308@sun.com> <17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> <1ccfd1c10912081147j5fc94f5bt3618fd05609dc031@mail.gmail.com> Message-ID: <4B1EAE70.3040706@sun.com> Martin Buchholz wrote: > On Tue, Dec 8, 2009 at 10:10, Andrew John Hughes > wrote: > > >>> Unfortunately, the most expedient way to get this fix back to probably to >>> ASCII-fy the contributor's name. >>> >>> >> I've already tried that. Whatever jcheck is doing goes beyond ASCII >> as it doesn't accept a backtick either (o` is the ASCIIfied version) >> > > Probably you have to go further and [A-Za-z]ify it From when I looked at the code, the regex is for [A-Za-z0-9]. -Joe From gnu_andrew at member.fsf.org Tue Dec 8 11:55:45 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 8 Dec 2009 19:55:45 +0000 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <4B1EAE70.3040706@sun.com> References: <4AF4B948.5070702@sun.com> <17c6771e0911130845o6138d6bei1d8bb76c3fe13e4e@mail.gmail.com> <4AFDC095.4060103@sun.com> <4B1DF24C.9020308@sun.com> <17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> <1ccfd1c10912081147j5fc94f5bt3618fd05609dc031@mail.gmail.com> <4B1EAE70.3040706@sun.com> Message-ID: <17c6771e0912081155v78d86a19jaaafab931e0e8e50@mail.gmail.com> 2009/12/8 Joseph D. Darcy : > Martin Buchholz wrote: >> >> On Tue, Dec 8, 2009 at 10:10, Andrew John Hughes >> wrote: >> >> >>>> >>>> Unfortunately, the most expedient way to get this fix back to probably >>>> to >>>> ASCII-fy the contributor's name. >>>> >>>> >>> >>> I've already tried that. ?Whatever jcheck is doing goes beyond ASCII >>> as it doesn't accept a backtick either (o` is the ASCIIfied version) >>> >> >> Probably you have to go further and [A-Za-z]ify it > > From when I looked at the code, the regex is for [A-Za-z0-9]. > Do you know whether this was for names or e-mail addresses? It sounds more like the latter. Being able to refer to the unlikely personage of Andrew1 but not someone who happens to have an accent of some form in their name seems a bit bizarre. What language is this? Maybe we can fix it blindly. Even grep supports a locale-dependent [:alpha:] range in place of [A-Za-z0-9]. > -Joe > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Tue Dec 8 11:59:07 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 8 Dec 2009 19:59:07 +0000 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <4B1EAE30.9080807@sun.com> References: <4AF4B948.5070702@sun.com> <4B1DF24C.9020308@sun.com> <17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> <4B1E9C6A.8050704@sun.com> <4B1E9E3A.7060008@sun.com> <17c6771e0912081147o69c95111m6ecd79a0b69da5ca@mail.gmail.com> <4B1EAE30.9080807@sun.com> Message-ID: <17c6771e0912081159x32dcf3f2k572655412e921731@mail.gmail.com> 2009/12/8 Joseph D. Darcy : > Andrew John Hughes wrote: >> >> 2009/12/8 Kelly O'Hair : >> >>> >>> Jonathan Gibbons wrote: >>> >>>> >>>> Andrew John Hughes wrote: >>>> >>>>> >>>>> Finally, during build, I just spotted another issue. ?The langtools >>>>> build wrongly passes -Werror to javac and this has been removed in the >>>>> OpenJDK7 version. ?It only shows up if you build OpenJDK6 with >>>>> OpenJDK7, so it's minor but probably worth fixing. ?I doubt that is >>>>> the only building-with-7 issue though. >>>>> >>> >>> Building OpenJDK6 ?"with" ?OpenJDK7? >>> You mean with an ALT_BOOTDIR=jdk7? Why? >>> >>> >> >> Why not? I happen to have a system install of OpenJDK7 m5 and not >> OpenJDK6 at present - the reason for that is exactly because you can't >> install 7 and then use it to build 6. ?I've since been able to build >> OpenJDK6 using a recent build of IcedTea6 (which uses gcj to build). >> But surely 7 should be able to build 6? >> > > I suspect the build issue is that the JDK 7 Werror checking is more > stringent than the OpenJDK 6 error checking and the OpenJDK 6 sources do not > have the fixes necessary to build under JDK 7 using Werror although they do > build under OpenJDK 6 with Werror. > > -Joe > Indeed, the OJ7 version has this fix: changeset: 214:9d541fd2916b parent: 212:49281ea88125 user: jjg date: Fri Feb 06 10:23:57 2009 -0800 summary: 6595666: fix -Werror which includes actually documenting the option in the javac output. I missed Jonathan's later change because I was searching for Werror rather than checking that file. Can we backport the warning fixup? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Jonathan.Gibbons at Sun.COM Tue Dec 8 12:00:39 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Tue, 08 Dec 2009 12:00:39 -0800 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <4B1EAD76.7000000@sun.com> References: <4AF4B948.5070702@sun.com> <4AFCEEA4.70009@sun.com> <17c6771e0911130845o6138d6bei1d8bb76c3fe13e4e@mail.gmail.com> <4AFDC095.4060103@sun.com> <4B1DF24C.9020308@sun.com> <17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> <4B1E9C6A.8050704@sun.com> <17c6771e0912081143pe31d4dk122c689ae003db16@mail.gmail.com> <4B1EAD76.7000000@sun.com> Message-ID: <4B1EB067.9060301@sun.com> Joseph D. Darcy wrote: > Andrew John Hughes wrote: >> 2009/12/8 Jonathan Gibbons : >> >>> Andrew John Hughes wrote: >>> >>>> Finally, during build, I just spotted another issue. The langtools >>>> build wrongly passes -Werror to javac and this has been removed in the >>>> OpenJDK7 version. It only shows up if you build OpenJDK6 with >>>> OpenJDK7, so it's minor but probably worth fixing. I doubt that is >>>> the only building-with-7 issue though. >>>> >>>> >>> langtools is supposed to be warning free and thus is supposed to use >>> -Werror. >>> >>> -- Jon >>> >>> >> >> Not according to this changeset of yours: >> >> http://hg.openjdk.java.net/jdk7/jdk7/langtools/rev/12c9e612e9e31 >> > > The removal of Werror from langtools in JDK 7 was a transitory change; > it came back as part of Jon's subsequent changset: > > http://hg.openjdk.java.net/jdk7/jdk7/langtools/rev/b4b1f7732289 > > -Joe When the langtools repository was originally created, there were different coding standards for different tools, with the bar being higher for some than for others. That is why at that time we could not use -Werror for all tools. Once we finally made the entire repository warning-free, it made sense to impose -Werror as a check that we maintained that level. -- Jon From Jonathan.Gibbons at Sun.COM Tue Dec 8 12:04:25 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Tue, 08 Dec 2009 12:04:25 -0800 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <17c6771e0912081159x32dcf3f2k572655412e921731@mail.gmail.com> References: <4AF4B948.5070702@sun.com> <4B1DF24C.9020308@sun.com> <17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> <4B1E9C6A.8050704@sun.com> <4B1E9E3A.7060008@sun.com> <17c6771e0912081147o69c95111m6ecd79a0b69da5ca@mail.gmail.com> <4B1EAE30.9080807@sun.com> <17c6771e0912081159x32dcf3f2k572655412e921731@mail.gmail.com> Message-ID: <4B1EB149.9050102@sun.com> Andrew John Hughes wrote: > 2009/12/8 Joseph D. Darcy : > >> Andrew John Hughes wrote: >> >>> 2009/12/8 Kelly O'Hair : >>> >>> >>>> Jonathan Gibbons wrote: >>>> >>>> >>>>> Andrew John Hughes wrote: >>>>> >>>>> >>>>>> Finally, during build, I just spotted another issue. The langtools >>>>>> build wrongly passes -Werror to javac and this has been removed in the >>>>>> OpenJDK7 version. It only shows up if you build OpenJDK6 with >>>>>> OpenJDK7, so it's minor but probably worth fixing. I doubt that is >>>>>> the only building-with-7 issue though. >>>>>> >>>>>> >>>> Building OpenJDK6 "with" OpenJDK7? >>>> You mean with an ALT_BOOTDIR=jdk7? Why? >>>> >>>> >>>> >>> Why not? I happen to have a system install of OpenJDK7 m5 and not >>> OpenJDK6 at present - the reason for that is exactly because you can't >>> install 7 and then use it to build 6. I've since been able to build >>> OpenJDK6 using a recent build of IcedTea6 (which uses gcj to build). >>> But surely 7 should be able to build 6? >>> >>> >> I suspect the build issue is that the JDK 7 Werror checking is more >> stringent than the OpenJDK 6 error checking and the OpenJDK 6 sources do not >> have the fixes necessary to build under JDK 7 using Werror although they do >> build under OpenJDK 6 with Werror. >> >> -Joe >> >> > > Indeed, the OJ7 version has this fix: > > changeset: 214:9d541fd2916b > parent: 212:49281ea88125 > user: jjg > date: Fri Feb 06 10:23:57 2009 -0800 > summary: 6595666: fix -Werror > > which includes actually documenting the option in the javac output. > I missed Jonathan's later change because I was searching for Werror > rather than checking that file. > Can we backport the warning fixup? > Fixing warnings in OpenJDK 6 langtools is a Good Idea. However, it may not be sufficient to just backport the warning fixup, as we may need additional fixups in 6, for where the code is different between the two. -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20091208/49c1a0ba/attachment.html From gnu_andrew at member.fsf.org Tue Dec 8 12:07:36 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 8 Dec 2009 20:07:36 +0000 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <4B1EB067.9060301@sun.com> References: <4AF4B948.5070702@sun.com> <4B1DF24C.9020308@sun.com> <17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> <4B1E9C6A.8050704@sun.com> <17c6771e0912081143pe31d4dk122c689ae003db16@mail.gmail.com> <4B1EAD76.7000000@sun.com> <4B1EB067.9060301@sun.com> Message-ID: <17c6771e0912081207q4e4f99fh10d6aaa864901052@mail.gmail.com> 2009/12/8 Jonathan Gibbons : > Joseph D. Darcy wrote: >> >> Andrew John Hughes wrote: >>> >>> 2009/12/8 Jonathan Gibbons : >>> >>>> >>>> Andrew John Hughes wrote: >>>> >>>>> >>>>> Finally, during build, I just spotted another issue. ?The langtools >>>>> build wrongly passes -Werror to javac and this has been removed in the >>>>> OpenJDK7 version. ?It only shows up if you build OpenJDK6 with >>>>> OpenJDK7, so it's minor but probably worth fixing. ?I doubt that is >>>>> the only building-with-7 issue though. >>>>> >>>>> >>>> >>>> langtools is supposed to be warning free and thus is supposed to use >>>> -Werror. >>>> >>>> -- Jon >>>> >>>> >>> >>> Not according to this changeset of yours: >>> >>> http://hg.openjdk.java.net/jdk7/jdk7/langtools/rev/12c9e612e9e31 >>> >> >> The removal of Werror from langtools in JDK 7 was a transitory change; it >> came back as part of Jon's subsequent changset: >> >> http://hg.openjdk.java.net/jdk7/jdk7/langtools/rev/b4b1f7732289 >> >> -Joe > > When the langtools repository was originally created, there were different > coding standards for different tools, with the bar being higher for some > than for others. That is why at that time we could not use -Werror for all > tools. ?Once we finally made the entire repository warning-free, it made > sense to impose -Werror as a check that we maintained that level. > > -- Jon > I'm glad the code is Werror free. Those of us working on IcedTea are certainly aware that the rest of the JDK code certainly isn't; when we bootstrap with ecj some 14k warnings are thrown out from the OpenJDK code (ecj is much more noisy by default) leading to -nowarn being added. The issue here is that the -Werror bit is in OpenJDK6 but the actual fix is not. It's strange because -unchecked seems to be being passed, yet unchecked warnings are being thrown. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Kelly.Ohair at Sun.COM Tue Dec 8 12:08:09 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 08 Dec 2009 12:08:09 -0800 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <17c6771e0912081147o69c95111m6ecd79a0b69da5ca@mail.gmail.com> References: <4AF4B948.5070702@sun.com> <17c6771e0911130845o6138d6bei1d8bb76c3fe13e4e@mail.gmail.com> <4AFDC095.4060103@sun.com> <4B1DF24C.9020308@sun.com> <17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> <4B1E9C6A.8050704@sun.com> <4B1E9E3A.7060008@sun.com> <17c6771e0912081147o69c95111m6ecd79a0b69da5ca@mail.gmail.com> Message-ID: <4B1EB229.7050807@sun.com> Andrew John Hughes wrote: > 2009/12/8 Kelly O'Hair : >> >> Jonathan Gibbons wrote: >>> Andrew John Hughes wrote: >>>> >>>> Finally, during build, I just spotted another issue. The langtools >>>> build wrongly passes -Werror to javac and this has been removed in the >>>> OpenJDK7 version. It only shows up if you build OpenJDK6 with >>>> OpenJDK7, so it's minor but probably worth fixing. I doubt that is >>>> the only building-with-7 issue though. >> Building OpenJDK6 "with" OpenJDK7? >> You mean with an ALT_BOOTDIR=jdk7? Why? >> > > Why not? I happen to have a system install of OpenJDK7 m5 and not > OpenJDK6 at present - the reason for that is exactly because you can't > install 7 and then use it to build 6. I've since been able to build > OpenJDK6 using a recent build of IcedTea6 (which uses gcj to build). > But surely 7 should be able to build 6? I'm sure it can, and if told to behave like a jdk6 (e.g. -source 1.6 -target 1.6) it should work in most cases.... I'm not sure we have ALL javac compilations in the entire forest being explicit though, we should. If ALT_BOOTDIR was only used to run the openjdk6 langtools javac, then in theory it should work. But lots of other tools from ALT_BOOTDIR are used, often getting default behaviors. Hotspot might end up building the serviceability agent incorrectly (it uses ALT_BOOTDIR javac). Not something I would trust working real well. --- I'm a big fan of javac -Werror, I would hate to see that disabled anywhere. If any team manages to get their java code warning free, using -Werror is a great thing to do. -kto > >> -kto >> >>> langtools is supposed to be warning free and thus is supposed to use >>> -Werror. >>> >>> -- Jon > > > From gnu_andrew at member.fsf.org Tue Dec 8 12:10:14 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 8 Dec 2009 20:10:14 +0000 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <4B1EB149.9050102@sun.com> References: <4AF4B948.5070702@sun.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> <4B1E9C6A.8050704@sun.com> <4B1E9E3A.7060008@sun.com> <17c6771e0912081147o69c95111m6ecd79a0b69da5ca@mail.gmail.com> <4B1EAE30.9080807@sun.com> <17c6771e0912081159x32dcf3f2k572655412e921731@mail.gmail.com> <4B1EB149.9050102@sun.com> Message-ID: <17c6771e0912081210ge9f4d90i5815575b5cec807d@mail.gmail.com> 2009/12/8 Jonathan Gibbons : > Andrew John Hughes wrote: > > 2009/12/8 Joseph D. Darcy : > > > Andrew John Hughes wrote: > > > 2009/12/8 Kelly O'Hair : > > > > Jonathan Gibbons wrote: > > > > Andrew John Hughes wrote: > > > > Finally, during build, I just spotted another issue. ?The langtools > build wrongly passes -Werror to javac and this has been removed in the > OpenJDK7 version. ?It only shows up if you build OpenJDK6 with > OpenJDK7, so it's minor but probably worth fixing. ?I doubt that is > the only building-with-7 issue though. > > > > Building OpenJDK6 ?"with" ?OpenJDK7? > You mean with an ALT_BOOTDIR=jdk7? Why? > > > > > Why not? I happen to have a system install of OpenJDK7 m5 and not > OpenJDK6 at present - the reason for that is exactly because you can't > install 7 and then use it to build 6. ?I've since been able to build > OpenJDK6 using a recent build of IcedTea6 (which uses gcj to build). > But surely 7 should be able to build 6? > > > > I suspect the build issue is that the JDK 7 Werror checking is more > stringent than the OpenJDK 6 error checking and the OpenJDK 6 sources do not > have the fixes necessary to build under JDK 7 using Werror although they do > build under OpenJDK 6 with Werror. > > -Joe > > > > Indeed, the OJ7 version has this fix: > > changeset: 214:9d541fd2916b > parent: 212:49281ea88125 > user: jjg > date: Fri Feb 06 10:23:57 2009 -0800 > summary: 6595666: fix -Werror > > which includes actually documenting the option in the javac output. > I missed Jonathan's later change because I was searching for Werror > rather than checking that file. > Can we backport the warning fixup? > > > Fixing warnings in OpenJDK 6 langtools is a Good Idea.?? However, it may not > be sufficient to just backport the warning fixup, as we may need additional > fixups in 6, for where the code is different between the two. > > -- Jon > The patch doesn't apply cleanly: $ hg export -R ../../icedtea/langtools b4b1f7732289|hg import - applying patch from stdin patching file make/build.properties Hunk #1 FAILED at 65 1 out of 1 hunks FAILED -- saving rejects to file make/build.properties.rej unable to find 'src/share/classes/com/sun/tools/classfile/Annotation.java' for patching 1 out of 1 hunks FAILED -- saving rejects to file src/share/classes/com/sun/tools/classfile/Annotation.java.rej unable to find 'src/share/classes/com/sun/tools/classfile/AttributeException.java' for patching 1 out of 1 hunks FAILED -- saving rejects to file src/share/classes/com/sun/tools/classfile/AttributeException.java.rej unable to find 'src/share/classes/com/sun/tools/classfile/Code_attribute.java' for patching 1 out of 1 hunks FAILED -- saving rejects to file src/share/classes/com/sun/tools/classfile/Code_attribute.java.rej unable to find 'src/share/classes/com/sun/tools/classfile/ConstantPool.java' for patching 4 out of 4 hunks FAILED -- saving rejects to file src/share/classes/com/sun/tools/classfile/ConstantPool.java.rej unable to find 'src/share/classes/com/sun/tools/classfile/ConstantPoolException.java' for patching 1 out of 1 hunks FAILED -- saving rejects to file src/share/classes/com/sun/tools/classfile/ConstantPoolException.java.rej unable to find 'src/share/classes/com/sun/tools/classfile/Descriptor.java' for patching 1 out of 1 hunks FAILED -- saving rejects to file src/share/classes/com/sun/tools/classfile/Descriptor.java.rej unable to find 'src/share/classes/com/sun/tools/classfile/DescriptorException.java' for patching 1 out of 1 hunks FAILED -- saving rejects to file src/share/classes/com/sun/tools/classfile/DescriptorException.java.rej unable to find 'src/share/classes/com/sun/tools/classfile/StackMapTable_attribute.java' for patching 1 out of 1 hunks FAILED -- saving rejects to file src/share/classes/com/sun/tools/classfile/StackMapTable_attribute.java.rej patching file src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java Hunk #1 FAILED at 118 1 out of 1 hunks FAILED -- saving rejects to file src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java.rej patching file src/share/classes/com/sun/tools/javac/main/JavaCompiler.java Hunk #1 FAILED at 470 1 out of 1 hunks FAILED -- saving rejects to file src/share/classes/com/sun/tools/javac/main/JavaCompiler.java.rej unable to find 'src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java' for patching 1 out of 1 hunks FAILED -- saving rejects to file src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java.rej unable to find 'src/share/classes/com/sun/tools/javap/InternalError.java' for patching 1 out of 1 hunks FAILED -- saving rejects to file src/share/classes/com/sun/tools/javap/InternalError.java.rej Any pointers to the refactoring involved here before I go digging? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Tue Dec 8 12:12:44 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 8 Dec 2009 20:12:44 +0000 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <4B1EB229.7050807@sun.com> References: <4AF4B948.5070702@sun.com> <4B1DF24C.9020308@sun.com> <17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> <4B1E9C6A.8050704@sun.com> <4B1E9E3A.7060008@sun.com> <17c6771e0912081147o69c95111m6ecd79a0b69da5ca@mail.gmail.com> <4B1EB229.7050807@sun.com> Message-ID: <17c6771e0912081212m3a945757mb824b49a045ea99@mail.gmail.com> 2009/12/8 Kelly O'Hair : > > > Andrew John Hughes wrote: >> >> 2009/12/8 Kelly O'Hair : >>> >>> Jonathan Gibbons wrote: >>>> >>>> Andrew John Hughes wrote: >>>>> >>>>> Finally, during build, I just spotted another issue. ?The langtools >>>>> build wrongly passes -Werror to javac and this has been removed in the >>>>> OpenJDK7 version. ?It only shows up if you build OpenJDK6 with >>>>> OpenJDK7, so it's minor but probably worth fixing. ?I doubt that is >>>>> the only building-with-7 issue though. >>> >>> Building OpenJDK6 ?"with" ?OpenJDK7? >>> You mean with an ALT_BOOTDIR=jdk7? Why? >>> >> >> Why not? I happen to have a system install of OpenJDK7 m5 and not >> OpenJDK6 at present - the reason for that is exactly because you can't >> install 7 and then use it to build 6. ?I've since been able to build >> OpenJDK6 using a recent build of IcedTea6 (which uses gcj to build). >> But surely 7 should be able to build 6? > > I'm sure it can, and if told to behave like a jdk6 (e.g. -source 1.6 -target > 1.6) > it should work in most cases.... I'm not sure we have ALL javac > compilations in the entire forest being explicit though, we should. > > If ALT_BOOTDIR was only used to run the openjdk6 langtools javac, then > in theory it should work. But lots of other tools from ALT_BOOTDIR > are used, often getting default behaviors. Hotspot might end up building > the serviceability agent incorrectly (it uses ALT_BOOTDIR javac). > Not something I would trust working real well. > Having happened to do this by chance, it does seem to be quite a good testcase for these implicit assumptions. The serviceability agent is built with -1.4 FWIW. I did some work making things explicit in various repos. a while back but some of that might only be in 7. > --- > I'm a big fan of javac -Werror, I would hate to see that disabled anywhere. > If any team manages to get their java code warning free, using > -Werror is a great thing to do. > Same here. I only suggested that because I thought that was the fix applied to langtools thus far. My mistake. > -kto > >> >>> -kto >>> >>>> langtools is supposed to be warning free and thus is supposed to use >>>> -Werror. >>>> >>>> -- Jon >> >> >> > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From lussman1 at gmail.com Tue Dec 8 12:59:21 2009 From: lussman1 at gmail.com (Denis Lussier) Date: Tue, 8 Dec 2009 15:59:21 -0500 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <1ccfd1c10912081142l7f65a70cvc7531bcfe592f2bd@mail.gmail.com> References: <4AF4B948.5070702@sun.com> <4AFDC095.4060103@sun.com> <4B1DF24C.9020308@sun.com> <17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> <4B1E9C6A.8050704@sun.com> <4B1E9E3A.7060008@sun.com> <1ccfd1c10912081142l7f65a70cvc7531bcfe592f2bd@mail.gmail.com> Message-ID: <8fab85310912081259g4de08eb3ifd5b77f04421123f@mail.gmail.com> Perhaps, but... I assume that OpenJDK 6's primary goal is something like bug free open source stabilization AND I further suspect that lots of re-factoring and cleanup (and enhancmements and ...) are happening in OpenJDK 7. On 12/8/09, Martin Buchholz wrote: >> Building OpenJDK6 ?"with" ?OpenJDK7? >> You mean with an ALT_BOOTDIR=jdk7? Why? > > Many people believe that: > openjdk7 is the best implementation of java 6 > From Joe.Darcy at Sun.COM Tue Dec 8 13:02:52 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Tue, 08 Dec 2009 13:02:52 -0800 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> References: <4AF4B948.5070702@sun.com> <17c6771e0911100245p2cbd9d0cs5f24b00d46b89559@mail.gmail.com> <17c6771e0911110810v3fa4d6e7jb0a8cdae482300b8@mail.gmail.com> <4AFCEEA4.70009@sun.com> <17c6771e0911130845o6138d6bei1d8bb76c3fe13e4e@mail.gmail.com> <4AFDC095.4060103@sun.com> <4B1DF24C.9020308@sun.com> <17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> Message-ID: <4B1EBEFC.9040601@sun.com> Andrew John Hughes wrote: > 2009/12/8 Joseph D. Darcy : > >> Andrew John Hughes wrote: >> >>> 2009/12/8 Andrew John Hughes : >>> >>> >>>> 2009/12/8 Joseph D. Darcy : >>>> >>>> >>>>> Joseph D. Darcy wrote: >>>>> >>>>> >>>>>> Andrew John Hughes wrote: >>>>>> >>>>>> >>>>>>> 2009/11/13 Joseph D. Darcy : >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Andrew John Hughes wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> 2009/11/10 Andrew John Hughes : >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> [snip] >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Still need to look at this, but was wondering what was happening >>>>>>>>> with >>>>>>>>> timezone data in 6? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> It doesn't seem like much of anything is happening with timezone data >>>>>>>> in >>>>>>>> OpenJDK 6! >>>>>>>> >>>>>>>> >>>>> [snip] >>>>> >>>>> >>>>> >>>>>>>> I'd appreciate if you could backport these timezone changes. >>>>>>>> >>>>>>>> -Joe >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Ok, no problem. >>>>>>> >>>>>>> So I make it for b18 we still have: >>>>>>> >>>>>>> * the issue with the X11 patch I can't apply because of jcheck >>>>>>> >>>>>>> >>>>>>> >>>>>> I'll check in with Mark, but we're both speaking at Devoxx next week so >>>>>> recognizing Latin-1 characters in jcheck may not happen immediately. >>>>>> >>>>>> >>>>>> >>>>>>> * Nimbus issues >>>>>>> * the diff issue with HotSpot Martin pointed out >>>>>>> >>>>>>> >>>>>>> >>>>>> Right. >>>>>> >>>>>> >>>>>> >>>>>>> Do we also want the timezone data changes for b18 or shall we do that >>>>>>> in b19? I think b19's main feature is likely to be hs16. >>>>>>> >>>>>>> >>>>>>> >>>>>> I think the time zone updates would be better in b18; the nature of >>>>>> these >>>>>> changes is very well-understood. >>>>>> >>>>>> >>>>>> >>>>> Some time has passed, a few more fixes have come into the repos, and I'm >>>>> beginning to think it would better to have OpenJDK 6 b18 be more or less >>>>> what is there now and to have the timezone update and other changes go >>>>> into >>>>> b19. >>>>> >>>>> Thoughts? >>>>> >>>>> -Joe >>>>> >>>>> >>>>> >>>> Sorry, I've been distracted with first the OpenJDK7 release and then >>>> time off work. Backporting the timezone stuff should be fairly >>>> trivial. I'll have a try today and if it isn't, then we can consider >>>> delaying it. >>>> >>>> >> Okay. >> >> >>>> I think we do need to get the Nimbus fixes in. I'm trying to get >>>> IcedTea6 working against OpenJDK6 hg so I can test this, and all the >>>> JAXWS/JAXP changes don't make that a simple job. But it's in >>>> progress. >>>> >>>> Is there any news on updating jcheck? I still haven't been able to >>>> push the X11 fix. >>>> >>>> >> I've pinged Mark but haven't heard back. >> >> Unfortunately, the most expedient way to get this fix back to probably to >> ASCII-fy the contributor's name. >> >> > > I've already tried that. Whatever jcheck is doing goes beyond ASCII > as it doesn't accept a backtick either (o` is the ASCIIfied version) > > As with other issues with jcheck, if it was open-sourced we wouldn't > have Mark as a bottleneck for fixing the inevitable issues with it. > I agree. If I see Mark later this week, I'll discuss jcheck with him. -Joe From Joe.Darcy at Sun.COM Tue Dec 8 13:05:39 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Tue, 08 Dec 2009 13:05:39 -0800 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <17c6771e0912081159x32dcf3f2k572655412e921731@mail.gmail.com> References: <4AF4B948.5070702@sun.com> <4B1DF24C.9020308@sun.com> <17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> <4B1E9C6A.8050704@sun.com> <4B1E9E3A.7060008@sun.com> <17c6771e0912081147o69c95111m6ecd79a0b69da5ca@mail.gmail.com> <4B1EAE30.9080807@sun.com> <17c6771e0912081159x32dcf3f2k572655412e921731@mail.gmail.com> Message-ID: <4B1EBFA3.8000201@sun.com> Andrew John Hughes wrote: > 2009/12/8 Joseph D. Darcy : > >> Andrew John Hughes wrote: >> >>> 2009/12/8 Kelly O'Hair : >>> >>> >>>> Jonathan Gibbons wrote: >>>> >>>> >>>>> Andrew John Hughes wrote: >>>>> >>>>> >>>>>> Finally, during build, I just spotted another issue. The langtools >>>>>> build wrongly passes -Werror to javac and this has been removed in the >>>>>> OpenJDK7 version. It only shows up if you build OpenJDK6 with >>>>>> OpenJDK7, so it's minor but probably worth fixing. I doubt that is >>>>>> the only building-with-7 issue though. >>>>>> >>>>>> >>>> Building OpenJDK6 "with" OpenJDK7? >>>> You mean with an ALT_BOOTDIR=jdk7? Why? >>>> >>>> >>>> >>> Why not? I happen to have a system install of OpenJDK7 m5 and not >>> OpenJDK6 at present - the reason for that is exactly because you can't >>> install 7 and then use it to build 6. I've since been able to build >>> OpenJDK6 using a recent build of IcedTea6 (which uses gcj to build). >>> But surely 7 should be able to build 6? >>> >>> >> I suspect the build issue is that the JDK 7 Werror checking is more >> stringent than the OpenJDK 6 error checking and the OpenJDK 6 sources do not >> have the fixes necessary to build under JDK 7 using Werror although they do >> build under OpenJDK 6 with Werror. >> >> -Joe >> >> > > Indeed, the OJ7 version has this fix: > > changeset: 214:9d541fd2916b > parent: 212:49281ea88125 > user: jjg > date: Fri Feb 06 10:23:57 2009 -0800 > summary: 6595666: fix -Werror > > which includes actually documenting the option in the javac output. > I missed Jonathan's later change because I was searching for Werror > rather than checking that file. > Can we backport the warning fixup? > I'm open to OpenJDK 6 langtools being made Werror clean as judged by JDK 7, but backporting the fixes may be nontrivial. (The Werror checking in JDK 7's javac is more stringent than that in OpenJDK 6.) -Joe From Jonathan.Gibbons at Sun.COM Tue Dec 8 13:10:12 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Tue, 08 Dec 2009 13:10:12 -0800 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <17c6771e0912081210ge9f4d90i5815575b5cec807d@mail.gmail.com> References: <4AF4B948.5070702@sun.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> <4B1E9C6A.8050704@sun.com> <4B1E9E3A.7060008@sun.com> <17c6771e0912081147o69c95111m6ecd79a0b69da5ca@mail.gmail.com> <4B1EAE30.9080807@sun.com> <17c6771e0912081159x32dcf3f2k572655412e921731@mail.gmail.com> <4B1EB149.9050102@sun.com> <17c6771e0912081210ge9f4d90i5815575b5cec807d@mail.gmail.com> Message-ID: <4B1EC0B4.8020400@sun.com> Andrew John Hughes wrote: > 2009/12/8 Jonathan Gibbons : > >> Andrew John Hughes wrote: >> >> 2009/12/8 Joseph D. Darcy : >> >> >> Andrew John Hughes wrote: >> >> >> 2009/12/8 Kelly O'Hair : >> >> >> >> Jonathan Gibbons wrote: >> >> >> >> Andrew John Hughes wrote: >> >> >> >> Finally, during build, I just spotted another issue. The langtools >> build wrongly passes -Werror to javac and this has been removed in the >> OpenJDK7 version. It only shows up if you build OpenJDK6 with >> OpenJDK7, so it's minor but probably worth fixing. I doubt that is >> the only building-with-7 issue though. >> >> >> >> Building OpenJDK6 "with" OpenJDK7? >> You mean with an ALT_BOOTDIR=jdk7? Why? >> >> >> >> >> Why not? I happen to have a system install of OpenJDK7 m5 and not >> OpenJDK6 at present - the reason for that is exactly because you can't >> install 7 and then use it to build 6. I've since been able to build >> OpenJDK6 using a recent build of IcedTea6 (which uses gcj to build). >> But surely 7 should be able to build 6? >> >> >> >> I suspect the build issue is that the JDK 7 Werror checking is more >> stringent than the OpenJDK 6 error checking and the OpenJDK 6 sources do not >> have the fixes necessary to build under JDK 7 using Werror although they do >> build under OpenJDK 6 with Werror. >> >> -Joe >> >> >> >> Indeed, the OJ7 version has this fix: >> >> changeset: 214:9d541fd2916b >> parent: 212:49281ea88125 >> user: jjg >> date: Fri Feb 06 10:23:57 2009 -0800 >> summary: 6595666: fix -Werror >> >> which includes actually documenting the option in the javac output. >> I missed Jonathan's later change because I was searching for Werror >> rather than checking that file. >> Can we backport the warning fixup? >> >> >> Fixing warnings in OpenJDK 6 langtools is a Good Idea. However, it may not >> be sufficient to just backport the warning fixup, as we may need additional >> fixups in 6, for where the code is different between the two. >> >> -- Jon >> >> > > The patch doesn't apply cleanly: > > $ hg export -R ../../icedtea/langtools b4b1f7732289|hg import - > applying patch from stdin > patching file make/build.properties > Hunk #1 FAILED at 65 > 1 out of 1 hunks FAILED -- saving rejects to file make/build.properties.rej > unable to find 'src/share/classes/com/sun/tools/classfile/Annotation.java' > for patching > 1 out of 1 hunks FAILED -- saving rejects to file > src/share/classes/com/sun/tools/classfile/Annotation.java.rej > unable to find 'src/share/classes/com/sun/tools/classfile/AttributeException.java' > for patching > 1 out of 1 hunks FAILED -- saving rejects to file > src/share/classes/com/sun/tools/classfile/AttributeException.java.rej > unable to find 'src/share/classes/com/sun/tools/classfile/Code_attribute.java' > for patching > 1 out of 1 hunks FAILED -- saving rejects to file > src/share/classes/com/sun/tools/classfile/Code_attribute.java.rej > unable to find 'src/share/classes/com/sun/tools/classfile/ConstantPool.java' > for patching > 4 out of 4 hunks FAILED -- saving rejects to file > src/share/classes/com/sun/tools/classfile/ConstantPool.java.rej > unable to find 'src/share/classes/com/sun/tools/classfile/ConstantPoolException.java' > for patching > 1 out of 1 hunks FAILED -- saving rejects to file > src/share/classes/com/sun/tools/classfile/ConstantPoolException.java.rej > unable to find 'src/share/classes/com/sun/tools/classfile/Descriptor.java' > for patching > 1 out of 1 hunks FAILED -- saving rejects to file > src/share/classes/com/sun/tools/classfile/Descriptor.java.rej > unable to find 'src/share/classes/com/sun/tools/classfile/DescriptorException.java' > for patching > 1 out of 1 hunks FAILED -- saving rejects to file > src/share/classes/com/sun/tools/classfile/DescriptorException.java.rej > unable to find 'src/share/classes/com/sun/tools/classfile/StackMapTable_attribute.java' > for patching > 1 out of 1 hunks FAILED -- saving rejects to file > src/share/classes/com/sun/tools/classfile/StackMapTable_attribute.java.rej > patching file src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java > Hunk #1 FAILED at 118 > 1 out of 1 hunks FAILED -- saving rejects to file > src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java.rej > patching file src/share/classes/com/sun/tools/javac/main/JavaCompiler.java > Hunk #1 FAILED at 470 > 1 out of 1 hunks FAILED -- saving rejects to file > src/share/classes/com/sun/tools/javac/main/JavaCompiler.java.rej > unable to find 'src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java' > for patching > 1 out of 1 hunks FAILED -- saving rejects to file > src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java.rej > unable to find 'src/share/classes/com/sun/tools/javap/InternalError.java' > for patching > 1 out of 1 hunks FAILED -- saving rejects to file > src/share/classes/com/sun/tools/javap/InternalError.java.rej > > Any pointers to the refactoring involved here before I go digging? > These errors are due to a completely new version of javap in JDK 7. OpenJDK 6 langtools has -Werror, and builds without warnings with a recommended compiler, such as JDK 5 or JDK 6. Therefore I don't see any immediate need for any fixes. If you use a different compiler that supports different options or more warnings, it makes sense that you might need to change the options you give that compiler to build langtools. -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20091208/91f360ad/attachment.html From Jonathan.Gibbons at Sun.COM Tue Dec 8 13:17:25 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Tue, 08 Dec 2009 13:17:25 -0800 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <4B1EBFA3.8000201@sun.com> References: <4AF4B948.5070702@sun.com> <4B1DF24C.9020308@sun.com> <17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> <4B1E9C6A.8050704@sun.com> <4B1E9E3A.7060008@sun.com> <17c6771e0912081147o69c95111m6ecd79a0b69da5ca@mail.gmail.com> <4B1EAE30.9080807@sun.com> <17c6771e0912081159x32dcf3f2k572655412e921731@mail.gmail.com> <4B1EBFA3.8000201@sun.com> Message-ID: <4B1EC265.3070607@sun.com> Joseph D. Darcy wrote: > [snip] > I'm open to OpenJDK 6 langtools being made Werror clean as judged by > JDK 7, but backporting the fixes may be nontrivial. (The Werror > checking in JDK 7's javac is more stringent than that in OpenJDK 6.) > > -Joe Joe, I will look at this -- but I think the correct solution is simply to fix warnings and not try backporting anything. -- Jon From gnu_andrew at member.fsf.org Tue Dec 8 13:31:35 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 8 Dec 2009 21:31:35 +0000 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <4B1EC265.3070607@sun.com> References: <4AF4B948.5070702@sun.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> <4B1E9C6A.8050704@sun.com> <4B1E9E3A.7060008@sun.com> <17c6771e0912081147o69c95111m6ecd79a0b69da5ca@mail.gmail.com> <4B1EAE30.9080807@sun.com> <17c6771e0912081159x32dcf3f2k572655412e921731@mail.gmail.com> <4B1EBFA3.8000201@sun.com> <4B1EC265.3070607@sun.com> Message-ID: <17c6771e0912081331p4a238029k3a035057a7ed702f@mail.gmail.com> 2009/12/8 Jonathan Gibbons : > Joseph D. Darcy wrote: >> >> [snip] > >> I'm open to OpenJDK 6 langtools ?being made Werror clean as judged by JDK >> 7, but backporting the fixes may be nontrivial. ?(The Werror checking in JDK >> 7's javac is more stringent than that in OpenJDK 6.) >> >> -Joe > > Joe, > > I will look at this -- but I think the correct solution is simply to fix > warnings and not try backporting anything. > > -- Jon > > Generally speaking, I think you're right -- there seems to be a lot of refactoring going on that we don't want to risk putting into 6. The javap changeset however http://hg.openjdk.java.net/jdk7/jdk7/langtools/rev/7708bd6d800de34 seems to fix a lot of issues. How risky does backporting this seem? It applies pretty cleanly. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Jonathan.Gibbons at Sun.COM Tue Dec 8 14:03:53 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Tue, 08 Dec 2009 14:03:53 -0800 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <17c6771e0912081331p4a238029k3a035057a7ed702f@mail.gmail.com> References: <4AF4B948.5070702@sun.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> <4B1E9C6A.8050704@sun.com> <4B1E9E3A.7060008@sun.com> <17c6771e0912081147o69c95111m6ecd79a0b69da5ca@mail.gmail.com> <4B1EAE30.9080807@sun.com> <17c6771e0912081159x32dcf3f2k572655412e921731@mail.gmail.com> <4B1EBFA3.8000201@sun.com> <4B1EC265.3070607@sun.com> <17c6771e0912081331p4a238029k3a035057a7ed702f@mail.gmail.com> Message-ID: <4B1ECD49.4030206@sun.com> Andrew John Hughes wrote: > 2009/12/8 Jonathan Gibbons : > >> Joseph D. Darcy wrote: >> >>> [snip] >>> >>> I'm open to OpenJDK 6 langtools being made Werror clean as judged by JDK >>> 7, but backporting the fixes may be nontrivial. (The Werror checking in JDK >>> 7's javac is more stringent than that in OpenJDK 6.) >>> >>> -Joe >>> >> Joe, >> >> I will look at this -- but I think the correct solution is simply to fix >> warnings and not try backporting anything. >> >> -- Jon >> >> >> > > Generally speaking, I think you're right -- there seems to be a lot of > refactoring going on that we don't want to risk putting into 6. > > The javap changeset however > http://hg.openjdk.java.net/jdk7/jdk7/langtools/rev/7708bd6d800de34 > seems to fix a lot of issues. How risky does backporting this seem? > It applies pretty cleanly. > If we were to consider backporting the new javap, it would be more appropriate to take the latest javap/classfile sources as a starting point, rather than that one changeset. However, there are significant changes in the command line options, so I'm not sure that backporting it is acceptable from that point of view, and the output is different enough that it might cause problems for some folk. -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20091208/7b27841a/attachment.html From kelly.ohair at sun.com Tue Dec 8 14:03:04 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Tue, 08 Dec 2009 22:03:04 +0000 Subject: hg: jdk6/jdk6/jdk: 19 new changesets Message-ID: <20091208220719.0CF5A41613@hg.openjdk.java.net> Changeset: 981639c21fb0 Author: ohair Date: 2009-11-23 14:00 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/981639c21fb0 6888927: Fix jdk jtreg tests to indicate which ones need othervm, allow for use of samevm option Reviewed-by: tbell, jjg, alanb ! make/jprt.properties ! test/Makefile + test/ProblemList.txt + test/start-Xvfb.sh Changeset: b82155d1e1f0 Author: ohair Date: 2009-11-24 11:19 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/b82155d1e1f0 6902667: Fix JT_HOME not working from env in jdk/test/Makefile Reviewed-by: dcubed, mullan ! test/Makefile ! test/ProblemList.txt Changeset: 9fd2e11a9ae6 Author: ohair Date: 2009-11-24 16:15 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/9fd2e11a9ae6 6892742: Improve root set used by jhat Reviewed-by: tbell, dcubed Contributed-by: Keith Randall ! src/share/classes/com/sun/tools/hat/internal/model/JavaStatic.java Changeset: e8bde4be2d8d Author: ohair Date: 2009-11-24 16:16 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/e8bde4be2d8d 6902323: Fix testcase sun/tools/native2ascii/NativeErrors.java 6902325: Fix testcase sun/tools/jhat/HatHeapDump1Test.java Reviewed-by: tbell, dcubed ! test/ProblemList.txt ! test/sun/tools/jhat/HatRun.java ! test/sun/tools/native2ascii/NativeErrors.java - test/sun/tools/native2ascii/test2 Changeset: 29f53a30bb40 Author: ohair Date: 2009-11-24 16:17 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/29f53a30bb40 6899444: Fix demo/jvmti tests so they can run in jtreg samevm mode, cleanup problemlist Reviewed-by: tbell ! test/ProblemList.txt ! test/demo/jvmti/DemoRun.java Changeset: 7dfb0e3a12a8 Author: tbell Date: 2009-11-24 17:57 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/7dfb0e3a12a8 6787605: OpenSolaris doesn't have /usr/ucb/ps so ShellScaffold fails Reviewed-by: dcubed ! test/com/sun/jdi/ShellScaffold.sh Changeset: 88ace032da3f Author: tbell Date: 2009-11-24 17:57 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/88ace032da3f 6893426: ShellScaffold.sh fails on Solaris 10 update releases: /usr/bin/id: illegal option -- u Reviewed-by: ohair, dcubed ! test/com/sun/jdi/ShellScaffold.sh Changeset: 4f0c5ad5f426 Author: dcubed Date: 2009-11-24 17:58 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/4f0c5ad5f426 6903102: 3/3 fixes in nightly testing version of ShellScaffold.sh need to be committed Summary: Merge Jim's ShellScaffold.sh fixes with Tim's ShellScaffold.sh fixes. Reviewed-by: tbell ! test/com/sun/jdi/ShellScaffold.sh Changeset: 0904f859e052 Author: ohair Date: 2009-11-24 17:59 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/0904f859e052 6904183: Fix jdk/test/com/sun/jdi tests to run with -samevm Reviewed-by: dcubed ! test/Makefile ! test/ProblemList.txt ! test/com/sun/jdi/BadHandshakeTest.java ! test/com/sun/jdi/DoubleAgentTest.java ! test/com/sun/jdi/ExclusiveBind.java ! test/com/sun/jdi/JITDebug.sh ! test/com/sun/jdi/RepStep.java ! test/com/sun/jdi/RunToExit.java ! test/com/sun/jdi/Solaris32AndSolaris64Test.sh ! test/com/sun/jdi/VMConnection.java ! test/com/sun/jdi/connect/spi/DebugUsingCustomConnector.java ! test/com/sun/jdi/connect/spi/GeneratedConnectors.java ! test/com/sun/jdi/connect/spi/SimpleLaunchingConnector.java ! test/com/sun/jdi/redefine/RedefineTest.java Changeset: e22bd8959d37 Author: ohair Date: 2009-12-04 14:35 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/e22bd8959d37 Merge Changeset: 51c6d1aae201 Author: ohair Date: 2009-12-03 16:42 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/51c6d1aae201 6730273: TEST: JDI_REGRESSION test Solaris32AndSolaris64Test.sh fails if -XX:+UseCompressedOops is used Reviewed-by: jjh ! test/com/sun/jdi/Solaris32AndSolaris64Test.sh Changeset: 8bac643e7048 Author: ohair Date: 2009-12-03 16:51 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/8bac643e7048 6737900: TEST: Some JDI regression tests timeout on slow machines 6263966: TEST: com/sun/jdi/ClassesByName2Test.java has a race Reviewed-by: jjh ! test/com/sun/jdi/ClassesByName2Test.java ! test/com/sun/jdi/ConnectedVMs.java ! test/com/sun/jdi/sde/MangleStepTest.java Changeset: b23d5e7ff13e Author: ohair Date: 2009-12-04 14:25 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/b23d5e7ff13e 6905705: Fix broken exit code values in jdk/test/Makefile Reviewed-by: tbell ! test/Makefile Changeset: 8d9080b5602e Author: ohair Date: 2009-12-04 14:30 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/8d9080b5602e 6529758: JVMTI Waiters demo crashes. Double free. Reviewed-by: alanb ! src/share/demo/jvmti/waiters/Agent.cpp ! src/share/demo/jvmti/waiters/Agent.hpp ! src/share/demo/jvmti/waiters/Monitor.cpp ! src/share/demo/jvmti/waiters/Monitor.hpp Changeset: 9ecb738d662c Author: ohair Date: 2009-12-04 14:39 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/9ecb738d662c Merge Changeset: fd47b8e98801 Author: ohair Date: 2009-12-05 16:55 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/fd47b8e98801 Merge Changeset: 13fbbc4df814 Author: ohair Date: 2009-12-04 14:42 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/13fbbc4df814 6855551: java -Xrunhprof crashes when running with classes compiled with targed=7 6855180: Fix classfile version check in java_crw_demo Reviewed-by: jjg ! src/share/demo/jvmti/java_crw_demo/java_crw_demo.c ! src/share/javavm/export/classfile_constants.h Changeset: 05550e803078 Author: ohair Date: 2009-12-05 16:56 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/05550e803078 Merge Changeset: dd7969318d7a Author: ohair Date: 2009-12-08 09:53 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/dd7969318d7a 6906210: Fix another minor typo in test/Makefile 6432567: PIT : com/sun/jdi/BadHandshakeTest.java fails due to java.net.ConnectException 6725543: Compiler warnings in serviceability native code 6646613: ClassPrepareRequest.addSourceNameFilter() does not behave as documented 6751643: ThreadReference.ownedMonitors() can return null 6700889: Thread resume invalidates all stack frames, even from other threads 6701700: MonitorInfo objects aren't invalidated when the owning thread is resumed 6614052: jhat fails to read heap dump >2GB Summary: Major update to com/sun/jdi, hprof, jvmti demos, jdwp debugger backend, and associated tests from jdk7. Lots of test fixes and compiler warning message removals. Reviewer list is from original jdk7 changesets, authors and reviewers. Reviewed-by: jjg, alanb, tbell, dcubed, swamyv ! src/share/back/ThreadReferenceImpl.c ! src/share/back/debugDispatch.c ! src/share/back/error_messages.c ! src/share/back/eventFilter.c ! src/share/back/inStream.c ! src/share/back/outStream.h ! src/share/back/transport.c ! src/share/classes/com/sun/tools/hat/Main.java ! src/share/classes/com/sun/tools/hat/build.xml ! src/share/classes/com/sun/tools/hat/internal/model/AbstractJavaHeapObjectVisitor.java ! src/share/classes/com/sun/tools/hat/internal/model/ArrayTypeCodes.java ! src/share/classes/com/sun/tools/hat/internal/model/HackJavaValue.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaBoolean.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaByte.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaChar.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaClass.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaDouble.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaField.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaFloat.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaHeapObject.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaHeapObjectVisitor.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaInt.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaLazyReadObject.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaLong.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaObject.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaObjectArray.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaObjectRef.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaShort.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaStatic.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaThing.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaValue.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java ! src/share/classes/com/sun/tools/hat/internal/model/ReachableExcludes.java ! src/share/classes/com/sun/tools/hat/internal/model/ReachableExcludesImpl.java ! src/share/classes/com/sun/tools/hat/internal/model/ReachableObjects.java ! src/share/classes/com/sun/tools/hat/internal/model/ReferenceChain.java ! src/share/classes/com/sun/tools/hat/internal/model/Root.java ! src/share/classes/com/sun/tools/hat/internal/model/Snapshot.java ! src/share/classes/com/sun/tools/hat/internal/model/StackFrame.java ! src/share/classes/com/sun/tools/hat/internal/model/StackTrace.java ! src/share/classes/com/sun/tools/hat/internal/oql/OQLEngine.java ! src/share/classes/com/sun/tools/hat/internal/oql/OQLException.java ! src/share/classes/com/sun/tools/hat/internal/oql/OQLQuery.java ! src/share/classes/com/sun/tools/hat/internal/oql/ObjectVisitor.java ! src/share/classes/com/sun/tools/hat/internal/parser/FileReadBuffer.java ! src/share/classes/com/sun/tools/hat/internal/parser/HprofReader.java ! src/share/classes/com/sun/tools/hat/internal/parser/MappedReadBuffer.java ! src/share/classes/com/sun/tools/hat/internal/parser/PositionDataInputStream.java ! src/share/classes/com/sun/tools/hat/internal/parser/PositionInputStream.java ! src/share/classes/com/sun/tools/hat/internal/parser/ReadBuffer.java ! src/share/classes/com/sun/tools/hat/internal/parser/Reader.java ! src/share/classes/com/sun/tools/hat/internal/server/AllClassesQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/AllRootsQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/ClassQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/FinalizerObjectsQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/FinalizerSummaryQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/HistogramQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/HttpReader.java ! src/share/classes/com/sun/tools/hat/internal/server/InstancesCountQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/InstancesQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/OQLHelp.java ! src/share/classes/com/sun/tools/hat/internal/server/OQLQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/ObjectQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/PlatformClasses.java ! src/share/classes/com/sun/tools/hat/internal/server/QueryHandler.java ! src/share/classes/com/sun/tools/hat/internal/server/QueryListener.java ! src/share/classes/com/sun/tools/hat/internal/server/ReachableQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/RefsByTypeQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/RootStackQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/RootsQuery.java ! src/share/classes/com/sun/tools/hat/internal/util/ArraySorter.java ! src/share/classes/com/sun/tools/hat/internal/util/Comparer.java ! src/share/classes/com/sun/tools/hat/internal/util/CompositeEnumeration.java ! src/share/classes/com/sun/tools/hat/internal/util/Misc.java ! src/share/classes/com/sun/tools/hat/internal/util/VectorSorter.java ! src/share/classes/com/sun/tools/hat/resources/hat.js ! src/share/classes/com/sun/tools/jdi/AbstractLauncher.java ! src/share/classes/com/sun/tools/jdi/ClassTypeImpl.java ! src/share/classes/com/sun/tools/jdi/ConcreteMethodImpl.java ! src/share/classes/com/sun/tools/jdi/EventSetImpl.java ! src/share/classes/com/sun/tools/jdi/JNITypeParser.java ! src/share/classes/com/sun/tools/jdi/MethodImpl.java ! src/share/classes/com/sun/tools/jdi/MonitorInfoImpl.java ! src/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/PacketStream.java ! src/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java ! src/share/classes/com/sun/tools/jdi/SDE.java ! src/share/classes/com/sun/tools/jdi/StackFrameImpl.java ! src/share/classes/com/sun/tools/jdi/TargetVM.java ! src/share/classes/com/sun/tools/jdi/ThreadGroupReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/VMAction.java ! src/share/classes/com/sun/tools/jdi/VMState.java ! src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java ! src/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java ! src/share/demo/jvmti/hprof/hprof_io.c ! src/share/demo/jvmti/hprof/hprof_util.c ! src/share/transport/shmem/shmemBack.c ! src/share/transport/shmem/shmemBase.c ! src/share/transport/socket/socketTransport.c ! src/share/transport/socket/sysSocket.h ! src/solaris/back/util_md.h ! src/solaris/transport/socket/socket_md.c ! src/windows/back/util_md.h ! src/windows/transport/socket/socket_md.c ! src/windows/transport/socket/socket_md.h ! test/Makefile ! test/ProblemList.txt ! test/com/sun/jdi/BadHandshakeTest.java + test/com/sun/jdi/BreakpointWithFullGC.sh ! test/com/sun/jdi/DoubleAgentTest.java ! test/com/sun/jdi/EnumTest.java ! test/com/sun/jdi/ExclusiveBind.java ! test/com/sun/jdi/GenericsTest.java ! test/com/sun/jdi/JdbVarargsTest.sh ! test/com/sun/jdi/MonitorFrameInfo.java ! test/com/sun/jdi/NoLaunchOptionTest.java ! test/com/sun/jdi/OptionTest.java + test/com/sun/jdi/ResumeOneThreadTest.java ! test/com/sun/jdi/RunToExit.java + test/com/sun/jdi/SimulResumerTest.java ! test/com/sun/jdi/SourceNameFilterTest.java ! test/com/sun/jdi/StepTest.java ! test/com/sun/jdi/StringConvertTest.sh ! test/com/sun/jdi/UTF8Test.java ! test/com/sun/jdi/VMConnection.java ! test/com/sun/jdi/VarargsTest.java ! test/com/sun/jdi/connect/spi/SimpleLaunchingConnector.java ! test/demo/jvmti/hprof/CpuOldTest.java ! test/demo/jvmti/hprof/CpuSamplesTest.java ! test/demo/jvmti/hprof/CpuTimesDefineClassTest.java ! test/demo/jvmti/hprof/CpuTimesTest.java ! test/demo/jvmti/hprof/HeapAllTest.java ! test/demo/jvmti/hprof/HeapBinaryFormatTest.java ! test/demo/jvmti/hprof/HeapDumpTest.java ! test/demo/jvmti/hprof/HeapSitesTest.java ! test/demo/jvmti/hprof/HelloWorld.java ! test/demo/jvmti/hprof/OptionsTest.java ! test/demo/jvmti/hprof/StackMapTableTest.java ! test/sun/tools/jhat/HatRun.java From Jonathan.Gibbons at Sun.COM Tue Dec 8 14:22:57 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Tue, 08 Dec 2009 14:22:57 -0800 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <4B1EC265.3070607@sun.com> References: <4AF4B948.5070702@sun.com> <4B1DF24C.9020308@sun.com> <17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> <4B1E9C6A.8050704@sun.com> <4B1E9E3A.7060008@sun.com> <17c6771e0912081147o69c95111m6ecd79a0b69da5ca@mail.gmail.com> <4B1EAE30.9080807@sun.com> <17c6771e0912081159x32dcf3f2k572655412e921731@mail.gmail.com> <4B1EBFA3.8000201@sun.com> <4B1EC265.3070607@sun.com> Message-ID: <4B1ED1C1.1030506@sun.com> Jonathan Gibbons wrote: > Joseph D. Darcy wrote: >> [snip] > >> I'm open to OpenJDK 6 langtools being made Werror clean as judged by >> JDK 7, but backporting the fixes may be nontrivial. (The Werror >> checking in JDK 7's javac is more stringent than that in OpenJDK 6.) >> >> -Joe > > Joe, > > I will look at this -- but I think the correct solution is simply to > fix warnings and not try backporting anything. > > -- Jon > I looked at this. It is easy enough to fix the warnings that come from using an OpenJDK 7 compiler, but it is somewhat more problematic to have the build work at all. Here's what happens when you try to run ant with boot.java set to a recent OpenJDK 7: -- it compiles the bootstrap compiler OK -- the build then tries to run the bootstrap compiler on the boot JDK -- the bootstrap compiler finds version 51 class files on its bootclasspath, but it only accepts up to version 50 class files, so it starts reporting warnings -- eventually it runs over the warnings limit regarding class file versions and aborts So now we are talking about hacking the build a bunch more with fixing up bootclasspath, or we are talking about using a version of OpenJDK 7 that has been built for v50 class files. Either way, we've gone over the effort budget for what ought to be a simple fix. In my opinion, the correct solution is for those folk trying to use an OpenJDK7 compiler to disable the use of those warnings that are new in JDK7: > $ hg diff > diff -r a9008b46db24 make/build.properties > --- a/make/build.properties Sun Oct 11 12:02:03 2009 +0200 > +++ b/make/build.properties Tue Dec 08 14:21:27 2009 -0800 > @@ -68,7 +68,7 @@ > # set the following to -version to verify the versions of javac being > used > javac.version.opt = > # in time, there should be no exceptions to -Xlint:all > -javac.lint.opts = > -Xlint:all,-unchecked,-deprecation,-fallthrough,-cast,-serial -Werror > +javac.lint.opts = > -Xlint:all,-unchecked,-deprecation,-fallthrough,-cast,-serial*,-rawtypes* > -Werror > > # options for the task for javac > javadoc.jls3.url=http://java.sun.com/docs/books/jls/ -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20091208/6a310ba2/attachment-0001.html From gnu_andrew at member.fsf.org Tue Dec 8 14:29:58 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 8 Dec 2009 22:29:58 +0000 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <4B1ECD49.4030206@sun.com> References: <4AF4B948.5070702@sun.com> <4B1E9C6A.8050704@sun.com> <4B1E9E3A.7060008@sun.com> <17c6771e0912081147o69c95111m6ecd79a0b69da5ca@mail.gmail.com> <4B1EAE30.9080807@sun.com> <17c6771e0912081159x32dcf3f2k572655412e921731@mail.gmail.com> <4B1EBFA3.8000201@sun.com> <4B1EC265.3070607@sun.com> <17c6771e0912081331p4a238029k3a035057a7ed702f@mail.gmail.com> <4B1ECD49.4030206@sun.com> Message-ID: <17c6771e0912081429g5262aba1ub7e7de0f36913e53@mail.gmail.com> 2009/12/8 Jonathan Gibbons : > Andrew John Hughes wrote: > > 2009/12/8 Jonathan Gibbons : > > > Joseph D. Darcy wrote: > > > [snip] > > > I'm open to OpenJDK 6 langtools ?being made Werror clean as judged by JDK > 7, but backporting the fixes may be nontrivial. ?(The Werror checking in JDK > 7's javac is more stringent than that in OpenJDK 6.) > > -Joe > > > Joe, > > I will look at this -- but I think the correct solution is simply to fix > warnings and not try backporting anything. > > -- Jon > > > > > Generally speaking, I think you're right -- there seems to be a lot of > refactoring going on that we don't want to risk putting into 6. > > The javap changeset however > http://hg.openjdk.java.net/jdk7/jdk7/langtools/rev/7708bd6d800de34 > seems to fix a lot of issues. How risky does backporting this seem? > It applies pretty cleanly. > > > If we were to consider backporting the new javap,? it would be more > appropriate to take the latest javap/classfile sources as a starting point, > rather than that one changeset. Generally, I think that's the wrong approach; you destroy the change history which is useful for tracking down issues. However, there are significant changes in > the command line options, so I'm not sure that backporting it is acceptable > from that point of view, and the output is different enough that it might > cause problems for some folk. > Well it does seem to be a rewrite; if the bug fixes were available separately, it would be a different story but I agree in retrospect this is too big a change. It also introduces warnings which cause the OpenJDK6 javac to baulk so they would also need fixing. > -- Jon > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Tue Dec 8 14:31:08 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 8 Dec 2009 22:31:08 +0000 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <4B1EBFA3.8000201@sun.com> References: <4AF4B948.5070702@sun.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> <4B1E9C6A.8050704@sun.com> <4B1E9E3A.7060008@sun.com> <17c6771e0912081147o69c95111m6ecd79a0b69da5ca@mail.gmail.com> <4B1EAE30.9080807@sun.com> <17c6771e0912081159x32dcf3f2k572655412e921731@mail.gmail.com> <4B1EBFA3.8000201@sun.com> Message-ID: <17c6771e0912081431s27fb6826qc2f666296d968cc3@mail.gmail.com> 2009/12/8 Joseph D. Darcy : > Andrew John Hughes wrote: >> >> 2009/12/8 Joseph D. Darcy : >> >>> >>> Andrew John Hughes wrote: >>> >>>> >>>> 2009/12/8 Kelly O'Hair : >>>> >>>> >>>>> >>>>> Jonathan Gibbons wrote: >>>>> >>>>> >>>>>> >>>>>> Andrew John Hughes wrote: >>>>>> >>>>>> >>>>>>> >>>>>>> Finally, during build, I just spotted another issue. ?The langtools >>>>>>> build wrongly passes -Werror to javac and this has been removed in >>>>>>> the >>>>>>> OpenJDK7 version. ?It only shows up if you build OpenJDK6 with >>>>>>> OpenJDK7, so it's minor but probably worth fixing. ?I doubt that is >>>>>>> the only building-with-7 issue though. >>>>>>> >>>>>>> >>>>> >>>>> Building OpenJDK6 ?"with" ?OpenJDK7? >>>>> You mean with an ALT_BOOTDIR=jdk7? Why? >>>>> >>>>> >>>>> >>>> >>>> Why not? I happen to have a system install of OpenJDK7 m5 and not >>>> OpenJDK6 at present - the reason for that is exactly because you can't >>>> install 7 and then use it to build 6. ?I've since been able to build >>>> OpenJDK6 using a recent build of IcedTea6 (which uses gcj to build). >>>> But surely 7 should be able to build 6? >>>> >>>> >>> >>> I suspect the build issue is that the JDK 7 Werror checking is more >>> stringent than the OpenJDK 6 error checking and the OpenJDK 6 sources do >>> not >>> have the fixes necessary to build under JDK 7 using Werror although they >>> do >>> build under OpenJDK 6 with Werror. >>> >>> -Joe >>> >>> >> >> Indeed, the OJ7 version has this fix: >> >> changeset: ? 214:9d541fd2916b >> parent: ? ? ?212:49281ea88125 >> user: ? ? ? ?jjg >> date: ? ? ? ?Fri Feb 06 10:23:57 2009 -0800 >> summary: ? ? 6595666: fix -Werror >> >> which includes actually documenting the option in the javac output. >> I missed Jonathan's later change because I was searching for Werror >> rather than checking that file. >> Can we backport the warning fixup? >> > > I'm open to OpenJDK 6 langtools ?being made Werror clean as judged by JDK 7, > but backporting the fixes may be nontrivial. ?(The Werror checking in JDK > 7's javac is more stringent than that in OpenJDK 6.) > > -Joe > I think we got sidetracked by the minor mention I made of this. To go back a few steps -- do you have an opinion on the timezone fixes? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Tue Dec 8 14:43:21 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 8 Dec 2009 22:43:21 +0000 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <4B1ED1C1.1030506@sun.com> References: <4AF4B948.5070702@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> <4B1E9C6A.8050704@sun.com> <4B1E9E3A.7060008@sun.com> <17c6771e0912081147o69c95111m6ecd79a0b69da5ca@mail.gmail.com> <4B1EAE30.9080807@sun.com> <17c6771e0912081159x32dcf3f2k572655412e921731@mail.gmail.com> <4B1EBFA3.8000201@sun.com> <4B1EC265.3070607@sun.com> <4B1ED1C1.1030506@sun.com> Message-ID: <17c6771e0912081443w720d13aft7d2fce6b46aa6c45@mail.gmail.com> 2009/12/8 Jonathan Gibbons : > Jonathan Gibbons wrote: > > Joseph D. Darcy wrote: > > [snip] > > I'm open to OpenJDK 6 langtools? being made Werror clean as judged by JDK 7, > but backporting the fixes may be nontrivial.? (The Werror checking in JDK > 7's javac is more stringent than that in OpenJDK 6.) > > -Joe > > Joe, > > I will look at this -- but I think the correct solution is simply to fix > warnings and not try backporting anything. > > -- Jon > > > I looked at this. It is easy enough to fix the warnings that come from using > an OpenJDK 7 compiler, but it is somewhat more problematic to have the build > work at all. > > Here's what happens when you try to run ant with boot.java set to a recent > OpenJDK 7: > -- it compiles the bootstrap compiler OK > -- the build then tries to run the bootstrap compiler on the boot JDK > ?? -- the bootstrap compiler finds version 51 class files on its > bootclasspath, but it only accepts up to version 50 class files, so it > starts reporting warnings > ?? -- eventually it runs over the warnings limit regarding class file > versions and aborts > > So now we are talking about hacking the build a bunch more with fixing up > bootclasspath, or we are talking about using a version of OpenJDK 7 that has > been built for v50 class files. Either way, we've gone over the effort > budget for what ought to be a simple fix. > > In my opinion, the correct solution is for those folk trying to use an > OpenJDK7 compiler to disable the use of those warnings that are new in JDK7: > > $ hg diff > diff -r a9008b46db24 make/build.properties > --- a/make/build.properties?? ?Sun Oct 11 12:02:03 2009 +0200 > +++ b/make/build.properties?? ?Tue Dec 08 14:21:27 2009 -0800 > @@ -68,7 +68,7 @@ > ?# set the following to -version to verify the versions of javac being used > ?javac.version.opt = > ?# in time, there should be no exceptions to -Xlint:all > -javac.lint.opts = > -Xlint:all,-unchecked,-deprecation,-fallthrough,-cast,-serial -Werror > +javac.lint.opts = > -Xlint:all,-unchecked,-deprecation,-fallthrough,-cast,-serial,-rawtypes > -Werror > > ?# options for the task for javac > ?javadoc.jls3.url=http://java.sun.com/docs/books/jls/ > >From what you say, it's not going to work even with that fix because the OpenJDK6 compiler will baulk at the OpenJDK7 class files on the bootclasspath. The only way I can see around that is to point it at the source code in the JDK instead. > -- Jon > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Jonathan.Gibbons at Sun.COM Tue Dec 8 14:55:00 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Tue, 08 Dec 2009 14:55:00 -0800 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <17c6771e0912081443w720d13aft7d2fce6b46aa6c45@mail.gmail.com> References: <4AF4B948.5070702@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> <4B1E9C6A.8050704@sun.com> <4B1E9E3A.7060008@sun.com> <17c6771e0912081147o69c95111m6ecd79a0b69da5ca@mail.gmail.com> <4B1EAE30.9080807@sun.com> <17c6771e0912081159x32dcf3f2k572655412e921731@mail.gmail.com> <4B1EBFA3.8000201@sun.com> <4B1EC265.3070607@sun.com> <4B1ED1C1.1030506@sun.com> <17c6771e0912081443w720d13aft7d2fce6b46aa6c45@mail.gmail.com> Message-ID: <4B1ED944.3070506@sun.com> Andrew John Hughes wrote: > 2009/12/8 Jonathan Gibbons : > >> Jonathan Gibbons wrote: >> >> Joseph D. Darcy wrote: >> >> [snip] >> >> I'm open to OpenJDK 6 langtools being made Werror clean as judged by JDK 7, >> but backporting the fixes may be nontrivial. (The Werror checking in JDK >> 7's javac is more stringent than that in OpenJDK 6.) >> >> -Joe >> >> Joe, >> >> I will look at this -- but I think the correct solution is simply to fix >> warnings and not try backporting anything. >> >> -- Jon >> >> >> I looked at this. It is easy enough to fix the warnings that come from using >> an OpenJDK 7 compiler, but it is somewhat more problematic to have the build >> work at all. >> >> Here's what happens when you try to run ant with boot.java set to a recent >> OpenJDK 7: >> -- it compiles the bootstrap compiler OK >> -- the build then tries to run the bootstrap compiler on the boot JDK >> -- the bootstrap compiler finds version 51 class files on its >> bootclasspath, but it only accepts up to version 50 class files, so it >> starts reporting warnings >> -- eventually it runs over the warnings limit regarding class file >> versions and aborts >> >> So now we are talking about hacking the build a bunch more with fixing up >> bootclasspath, or we are talking about using a version of OpenJDK 7 that has >> been built for v50 class files. Either way, we've gone over the effort >> budget for what ought to be a simple fix. >> >> In my opinion, the correct solution is for those folk trying to use an >> OpenJDK7 compiler to disable the use of those warnings that are new in JDK7: >> >> $ hg diff >> diff -r a9008b46db24 make/build.properties >> --- a/make/build.properties Sun Oct 11 12:02:03 2009 +0200 >> +++ b/make/build.properties Tue Dec 08 14:21:27 2009 -0800 >> @@ -68,7 +68,7 @@ >> # set the following to -version to verify the versions of javac being used >> javac.version.opt = >> # in time, there should be no exceptions to -Xlint:all >> -javac.lint.opts = >> -Xlint:all,-unchecked,-deprecation,-fallthrough,-cast,-serial -Werror >> +javac.lint.opts = >> -Xlint:all,-unchecked,-deprecation,-fallthrough,-cast,-serial,-rawtypes >> -Werror >> >> # options for the task for javac >> javadoc.jls3.url=http://java.sun.com/docs/books/jls/ >> >> > > From what you say, it's not going to work even with that fix because > the OpenJDK6 compiler will baulk at the OpenJDK7 class files on the > bootclasspath. The only way I can see around that is to point it at > the source code in the JDK instead. > Oh you so do not want to do that! See my blog entry http://blogs.sun.com/jjg/entry/building_javac_for_jdk7 for some of the problems you get into when you start to compile against JDK sources! -- Jon > >> -- Jon >> >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20091208/8f5728f1/attachment.html From gnu_andrew at member.fsf.org Tue Dec 8 15:25:48 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 8 Dec 2009 23:25:48 +0000 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <4B1ED944.3070506@sun.com> References: <4AF4B948.5070702@sun.com> <4B1E9E3A.7060008@sun.com> <17c6771e0912081147o69c95111m6ecd79a0b69da5ca@mail.gmail.com> <4B1EAE30.9080807@sun.com> <17c6771e0912081159x32dcf3f2k572655412e921731@mail.gmail.com> <4B1EBFA3.8000201@sun.com> <4B1EC265.3070607@sun.com> <4B1ED1C1.1030506@sun.com> <17c6771e0912081443w720d13aft7d2fce6b46aa6c45@mail.gmail.com> <4B1ED944.3070506@sun.com> Message-ID: <17c6771e0912081525k10511b1epafa3b254f998b7a4@mail.gmail.com> 2009/12/8 Jonathan Gibbons : > Andrew John Hughes wrote: > > 2009/12/8 Jonathan Gibbons : > > > Jonathan Gibbons wrote: > > Joseph D. Darcy wrote: > > [snip] > > I'm open to OpenJDK 6 langtools? being made Werror clean as judged by JDK 7, > but backporting the fixes may be nontrivial.? (The Werror checking in JDK > 7's javac is more stringent than that in OpenJDK 6.) > > -Joe > > Joe, > > I will look at this -- but I think the correct solution is simply to fix > warnings and not try backporting anything. > > -- Jon > > > I looked at this. It is easy enough to fix the warnings that come from using > an OpenJDK 7 compiler, but it is somewhat more problematic to have the build > work at all. > > Here's what happens when you try to run ant with boot.java set to a recent > OpenJDK 7: > -- it compiles the bootstrap compiler OK > -- the build then tries to run the bootstrap compiler on the boot JDK > ?? -- the bootstrap compiler finds version 51 class files on its > bootclasspath, but it only accepts up to version 50 class files, so it > starts reporting warnings > ?? -- eventually it runs over the warnings limit regarding class file > versions and aborts > > So now we are talking about hacking the build a bunch more with fixing up > bootclasspath, or we are talking about using a version of OpenJDK 7 that has > been built for v50 class files. Either way, we've gone over the effort > budget for what ought to be a simple fix. > > In my opinion, the correct solution is for those folk trying to use an > OpenJDK7 compiler to disable the use of those warnings that are new in JDK7: > > $ hg diff > diff -r a9008b46db24 make/build.properties > --- a/make/build.properties?? ?Sun Oct 11 12:02:03 2009 +0200 > +++ b/make/build.properties?? ?Tue Dec 08 14:21:27 2009 -0800 > @@ -68,7 +68,7 @@ > ?# set the following to -version to verify the versions of javac being used > ?javac.version.opt = > ?# in time, there should be no exceptions to -Xlint:all > -javac.lint.opts = > -Xlint:all,-unchecked,-deprecation,-fallthrough,-cast,-serial -Werror > +javac.lint.opts = > -Xlint:all,-unchecked,-deprecation,-fallthrough,-cast,-serial,-rawtypes > -Werror > > ?# options for the task for javac > ?javadoc.jls3.url=http://java.sun.com/docs/books/jls/ > > > > From what you say, it's not going to work even with that fix because > the OpenJDK6 compiler will baulk at the OpenJDK7 class files on the > bootclasspath. The only way I can see around that is to point it at > the source code in the JDK instead. > > > Oh you so do not want to do that!? See my blog entry > http://blogs.sun.com/jjg/entry/building_javac_for_jdk7 for some of the > problems you get into when you start to compile against JDK sources! > > -- Jon > > > > > -- Jon > > > > > Oh believe me, I meant that as a showstopper rather than a suggestion! I have read your blog on this, and we also have plenty of experience with bootstrapping from IcedTea. The IcedTea build has to do exactly this before it can even launch the OpenJDK build process. The reason is twofold: 1. There are some methods and classes still missing from gcj which we use to bootstrap 2. There are com.sun.* and sun.* intrinsic dependencies in the OpenJDK code. Long term, I'd like both of those to go away, by additional work on gcj and fixes to OpenJDK. The current process relies on compiling a specific subset of OpenJDK to fill the holes and on pre-generated versions of the files you mention. It's fragile and breaks every so often as new build drops appear. But it's necessary because there is no OpenJDK before 6 to bootstrap with. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Jonathan.Gibbons at Sun.COM Tue Dec 8 16:04:07 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Tue, 08 Dec 2009 16:04:07 -0800 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <17c6771e0912081525k10511b1epafa3b254f998b7a4@mail.gmail.com> References: <4AF4B948.5070702@sun.com> <4B1E9E3A.7060008@sun.com> <17c6771e0912081147o69c95111m6ecd79a0b69da5ca@mail.gmail.com> <4B1EAE30.9080807@sun.com> <17c6771e0912081159x32dcf3f2k572655412e921731@mail.gmail.com> <4B1EBFA3.8000201@sun.com> <4B1EC265.3070607@sun.com> <4B1ED1C1.1030506@sun.com> <17c6771e0912081443w720d13aft7d2fce6b46aa6c45@mail.gmail.com> <4B1ED944.3070506@sun.com> <17c6771e0912081525k10511b1epafa3b254f998b7a4@mail.gmail.com> Message-ID: <4B1EE977.20703@sun.com> Andrew John Hughes wrote: > 2009/12/8 Jonathan Gibbons : > >> Andrew John Hughes wrote: >> >> 2009/12/8 Jonathan Gibbons : >> >> >> Jonathan Gibbons wrote: >> >> Joseph D. Darcy wrote: >> >> [snip] >> >> I'm open to OpenJDK 6 langtools being made Werror clean as judged by JDK 7, >> but backporting the fixes may be nontrivial. (The Werror checking in JDK >> 7's javac is more stringent than that in OpenJDK 6.) >> >> -Joe >> >> Joe, >> >> I will look at this -- but I think the correct solution is simply to fix >> warnings and not try backporting anything. >> >> -- Jon >> >> >> I looked at this. It is easy enough to fix the warnings that come from using >> an OpenJDK 7 compiler, but it is somewhat more problematic to have the build >> work at all. >> >> Here's what happens when you try to run ant with boot.java set to a recent >> OpenJDK 7: >> -- it compiles the bootstrap compiler OK >> -- the build then tries to run the bootstrap compiler on the boot JDK >> -- the bootstrap compiler finds version 51 class files on its >> bootclasspath, but it only accepts up to version 50 class files, so it >> starts reporting warnings >> -- eventually it runs over the warnings limit regarding class file >> versions and aborts >> >> So now we are talking about hacking the build a bunch more with fixing up >> bootclasspath, or we are talking about using a version of OpenJDK 7 that has >> been built for v50 class files. Either way, we've gone over the effort >> budget for what ought to be a simple fix. >> >> In my opinion, the correct solution is for those folk trying to use an >> OpenJDK7 compiler to disable the use of those warnings that are new in JDK7: >> >> $ hg diff >> diff -r a9008b46db24 make/build.properties >> --- a/make/build.properties Sun Oct 11 12:02:03 2009 +0200 >> +++ b/make/build.properties Tue Dec 08 14:21:27 2009 -0800 >> @@ -68,7 +68,7 @@ >> # set the following to -version to verify the versions of javac being used >> javac.version.opt = >> # in time, there should be no exceptions to -Xlint:all >> -javac.lint.opts = >> -Xlint:all,-unchecked,-deprecation,-fallthrough,-cast,-serial -Werror >> +javac.lint.opts = >> -Xlint:all,-unchecked,-deprecation,-fallthrough,-cast,-serial,-rawtypes >> -Werror >> >> # options for the task for javac >> javadoc.jls3.url=http://java.sun.com/docs/books/jls/ >> >> >> >> From what you say, it's not going to work even with that fix because >> the OpenJDK6 compiler will baulk at the OpenJDK7 class files on the >> bootclasspath. The only way I can see around that is to point it at >> the source code in the JDK instead. >> >> >> Oh you so do not want to do that! See my blog entry >> http://blogs.sun.com/jjg/entry/building_javac_for_jdk7 for some of the >> problems you get into when you start to compile against JDK sources! >> >> -- Jon >> >> >> >> >> -- Jon >> >> >> >> >> >> > > Oh believe me, I meant that as a showstopper rather than a suggestion! > > I have read your blog on this, and we also have plenty of experience > with bootstrapping from IcedTea. The IcedTea build has to do exactly > this before it can even launch the OpenJDK build process. The reason > is twofold: > > 1. There are some methods and classes still missing from gcj which we > use to bootstrap > 2. There are com.sun.* and sun.* intrinsic dependencies in the OpenJDK code. > > Long term, I'd like both of those to go away, by additional work on > gcj and fixes to OpenJDK. The current process relies on compiling a > specific subset of OpenJDK to fill the holes and on pre-generated > versions of the files you mention. It's fragile and breaks every so > often as new build drops appear. But it's necessary because there is > no OpenJDK before 6 to bootstrap with. > Having done this once, can you now use earlier builds of OpenJDK 6 to build newer builds? Can you now not define OpenJDK 6 to be the preferred platform for building newer versions of OpenJDK 6? -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20091208/875d8711/attachment-0001.html From gnu_andrew at member.fsf.org Wed Dec 9 03:56:55 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 9 Dec 2009 11:56:55 +0000 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <4B1EE977.20703@sun.com> References: <4AF4B948.5070702@sun.com> <4B1EAE30.9080807@sun.com> <17c6771e0912081159x32dcf3f2k572655412e921731@mail.gmail.com> <4B1EBFA3.8000201@sun.com> <4B1EC265.3070607@sun.com> <4B1ED1C1.1030506@sun.com> <17c6771e0912081443w720d13aft7d2fce6b46aa6c45@mail.gmail.com> <4B1ED944.3070506@sun.com> <17c6771e0912081525k10511b1epafa3b254f998b7a4@mail.gmail.com> <4B1EE977.20703@sun.com> Message-ID: <17c6771e0912090356j2a2dd6ber683dccee28352d49@mail.gmail.com> 2009/12/9 Jonathan Gibbons : > Andrew John Hughes wrote: > > 2009/12/8 Jonathan Gibbons : > > > Andrew John Hughes wrote: > > 2009/12/8 Jonathan Gibbons : > > > Jonathan Gibbons wrote: > > Joseph D. Darcy wrote: > > [snip] > > I'm open to OpenJDK 6 langtools? being made Werror clean as judged by JDK 7, > but backporting the fixes may be nontrivial.? (The Werror checking in JDK > 7's javac is more stringent than that in OpenJDK 6.) > > -Joe > > Joe, > > I will look at this -- but I think the correct solution is simply to fix > warnings and not try backporting anything. > > -- Jon > > > I looked at this. It is easy enough to fix the warnings that come from using > an OpenJDK 7 compiler, but it is somewhat more problematic to have the build > work at all. > > Here's what happens when you try to run ant with boot.java set to a recent > OpenJDK 7: > -- it compiles the bootstrap compiler OK > -- the build then tries to run the bootstrap compiler on the boot JDK > ?? -- the bootstrap compiler finds version 51 class files on its > bootclasspath, but it only accepts up to version 50 class files, so it > starts reporting warnings > ?? -- eventually it runs over the warnings limit regarding class file > versions and aborts > > So now we are talking about hacking the build a bunch more with fixing up > bootclasspath, or we are talking about using a version of OpenJDK 7 that has > been built for v50 class files. Either way, we've gone over the effort > budget for what ought to be a simple fix. > > In my opinion, the correct solution is for those folk trying to use an > OpenJDK7 compiler to disable the use of those warnings that are new in JDK7: > > $ hg diff > diff -r a9008b46db24 make/build.properties > --- a/make/build.properties?? ?Sun Oct 11 12:02:03 2009 +0200 > +++ b/make/build.properties?? ?Tue Dec 08 14:21:27 2009 -0800 > @@ -68,7 +68,7 @@ > ?# set the following to -version to verify the versions of javac being used > ?javac.version.opt = > ?# in time, there should be no exceptions to -Xlint:all > -javac.lint.opts = > -Xlint:all,-unchecked,-deprecation,-fallthrough,-cast,-serial -Werror > +javac.lint.opts = > -Xlint:all,-unchecked,-deprecation,-fallthrough,-cast,-serial,-rawtypes > -Werror > > ?# options for the task for javac > ?javadoc.jls3.url=http://java.sun.com/docs/books/jls/ > > > > From what you say, it's not going to work even with that fix because > the OpenJDK6 compiler will baulk at the OpenJDK7 class files on the > bootclasspath. The only way I can see around that is to point it at > the source code in the JDK instead. > > > Oh you so do not want to do that!? See my blog entry > http://blogs.sun.com/jjg/entry/building_javac_for_jdk7 for some of the > problems you get into when you start to compile against JDK sources! > > -- Jon > > > > > -- Jon > > > > > > > > Oh believe me, I meant that as a showstopper rather than a suggestion! > > I have read your blog on this, and we also have plenty of experience > with bootstrapping from IcedTea. The IcedTea build has to do exactly > this before it can even launch the OpenJDK build process. The reason > is twofold: > > 1. There are some methods and classes still missing from gcj which we > use to bootstrap > 2. There are com.sun.* and sun.* intrinsic dependencies in the OpenJDK > code. > > Long term, I'd like both of those to go away, by additional work on > gcj and fixes to OpenJDK. The current process relies on compiling a > specific subset of OpenJDK to fill the holes and on pre-generated > versions of the files you mention. It's fragile and breaks every so > often as new build drops appear. But it's necessary because there is > no OpenJDK before 6 to bootstrap with. > > > Having done this once, can you now use earlier builds of OpenJDK 6 to build > newer builds? Indeed you can. In fact IcedTea works by immediately rebuilding with the OpenJDK6 just built so as to obtain one without the hacks mentioned above for bootstrapping. It's also how all the GNU/Linux distro builds originated. > Can you now not define OpenJDK 6 to be the preferred platform for building > newer versions of OpenJDK 6? > The --with-openjdk option does just that, but full bootstrap support is still needed for platforms where there is no OpenJDK build yet available. It's this bootstrapping that has also allowed the ARM and PPC builds to happen. > -- Jon > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Joe.Darcy at Sun.COM Wed Dec 9 12:00:24 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Wed, 09 Dec 2009 12:00:24 -0800 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <17c6771e0912081019i234a9646pfa24ecf4551ac33b@mail.gmail.com> References: <4AF4B948.5070702@sun.com> <17c6771e0911110810v3fa4d6e7jb0a8cdae482300b8@mail.gmail.com> <4AFCEEA4.70009@sun.com> <17c6771e0911130845o6138d6bei1d8bb76c3fe13e4e@mail.gmail.com> <4AFDC095.4060103@sun.com> <4B1DF24C.9020308@sun.com> <17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> <17c6771e0912081019i234a9646pfa24ecf4551ac33b@mail.gmail.com> Message-ID: <4B2001D8.8020602@sun.com> Andrew John Hughes wrote: > 2009/12/8 Andrew John Hughes : > >> 2009/12/8 Joseph D. Darcy : >> >>> Andrew John Hughes wrote: >>> >>>> 2009/12/8 Andrew John Hughes : >>>> >>>> >>>>> 2009/12/8 Joseph D. Darcy : >>>>> >>>>> >>>>>> Joseph D. Darcy wrote: >>>>>> >>>>>> >>>>>>> Andrew John Hughes wrote: >>>>>>> >>>>>>> >>>>>>>> 2009/11/13 Joseph D. Darcy : >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Andrew John Hughes wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> 2009/11/10 Andrew John Hughes : >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> [snip] >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Still need to look at this, but was wondering what was happening >>>>>>>>>> with >>>>>>>>>> timezone data in 6? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> It doesn't seem like much of anything is happening with timezone data >>>>>>>>> in >>>>>>>>> OpenJDK 6! >>>>>>>>> >>>>>>>>> >>>>>> [snip] >>>>>> >>>>>> >>>>>> >>>>>>>>> I'd appreciate if you could backport these timezone changes. >>>>>>>>> >>>>>>>>> -Joe >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Ok, no problem. >>>>>>>> >>>>>>>> So I make it for b18 we still have: >>>>>>>> >>>>>>>> * the issue with the X11 patch I can't apply because of jcheck >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> I'll check in with Mark, but we're both speaking at Devoxx next week so >>>>>>> recognizing Latin-1 characters in jcheck may not happen immediately. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> * Nimbus issues >>>>>>>> * the diff issue with HotSpot Martin pointed out >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Right. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Do we also want the timezone data changes for b18 or shall we do that >>>>>>>> in b19? I think b19's main feature is likely to be hs16. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> I think the time zone updates would be better in b18; the nature of >>>>>>> these >>>>>>> changes is very well-understood. >>>>>>> >>>>>>> >>>>>>> >>>>>> Some time has passed, a few more fixes have come into the repos, and I'm >>>>>> beginning to think it would better to have OpenJDK 6 b18 be more or less >>>>>> what is there now and to have the timezone update and other changes go >>>>>> into >>>>>> b19. >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> -Joe >>>>>> >>>>>> >>>>>> >>>>> Sorry, I've been distracted with first the OpenJDK7 release and then >>>>> time off work. Backporting the timezone stuff should be fairly >>>>> trivial. I'll have a try today and if it isn't, then we can consider >>>>> delaying it. >>>>> >>>>> >>> Okay. >>> >>> >>>>> I think we do need to get the Nimbus fixes in. I'm trying to get >>>>> IcedTea6 working against OpenJDK6 hg so I can test this, and all the >>>>> JAXWS/JAXP changes don't make that a simple job. But it's in >>>>> progress. >>>>> >>>>> Is there any news on updating jcheck? I still haven't been able to >>>>> push the X11 fix. >>>>> >>>>> >>> I've pinged Mark but haven't heard back. >>> >>> Unfortunately, the most expedient way to get this fix back to probably to >>> ASCII-fy the contributor's name. >>> >>> >> I've already tried that. Whatever jcheck is doing goes beyond ASCII >> as it doesn't accept a backtick either (o` is the ASCIIfied version) >> >> As with other issues with jcheck, if it was open-sourced we wouldn't >> have Mark as a bottleneck for fixing the inevitable issues with it. >> >> This is a fairly serious issue; I currently can't build OpenJDK6 >> unless I apply that patch first and no doubt others will see this too >> (all F12 users for a start). >> >> >>>>> In response to Erik's e-mail, I'd be happier making HotSpot b16 part >>>>> of b19 rather than b18, so we have more time for testing. >>>>> >>>>> >>> Yes, the HotSpot upgrade should occur in b19. >>> >>> >>>>> So still: >>>>> >>>>> * Timezone fixes >>>>> * Nimbus fixes >>>>> >>>>> >>> Nimbus backports from JDK 7 I assume. >>> >>> >> There is one, but I was thinking of the test issues you raised in >> previous emails. >> >> >>>>> * X11 fix >>>>> >>>>> for b18 from my side. Is there some rush to get this out? >>>>> >>>>> >>> No rush per se, but with the holiday coming up (including my on vacation >>> soon), if the build doesn't happen in the next week or so, it probably won't >>> happen until January and I'd prefer to get a build with the security fixes >>> officially out before then. >>> >>> >> Well, I think most things can probably be sorted this week. The X11 >> fix is the real blocker. Can we not just turn jcheck off or something >> for one commit? >> >> I'm currently building OpenJDK6 with the timezone fixes applied and it >> looks ok so far. I'll post a webrev once it completes. >> >> There are two more tz issues worthy of consideration that I didn't >> include yet because they are not related to the data, but would be >> good to have. One adds support for old timezone IDs (I'm wary of this >> because it introduces a property) and the other fixes an issue with >> determining the timezone on GNU/Linux boxes which I believe will >> obsolete a different but related fix in IcedTea6. I'd also like to >> add a simple patch which fixes up the remaining data differences >> between 6 and 7 (just typos and revision headers) which seems to have >> occurred in the black hole between the OpenJDK6 fork and the OpenJDK7 >> hg repositories. >> >> Finally, during build, I just spotted another issue. The langtools >> build wrongly passes -Werror to javac and this has been removed in the >> OpenJDK7 version. It only shows up if you build OpenJDK6 with >> OpenJDK7, so it's minor but probably worth fixing. I doubt that is >> the only building-with-7 issue though. >> >> >>>> Just remembered about Kelly's JDI work; that would be good to get in >>>> and being test-related, shouldn't break anything about the build or >>>> JDK itself. >>>> >>>> >>> There are a bunch of source changes too, but they have been in JDK 7 for a >>> while so they should be fine for OpenJDK 6. >>> >>> -Joe >>> >>> >> >> -- >> Andrew :-) >> >> Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> Support Free Java! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net >> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >> >> > > No sooner did I write that than it built: > > http://cr.openjdk.java.net/~andrew/tz/webrev.01/ > Approved. > The remaining three tz fixes are: > > changeset: 639:67c41d740e6d > user: peytoia > date: Mon Sep 08 15:21:55 2008 +0900 > summary: 6466476: (tz) Introduction of tzdata2005r can introduce > incompatility issues with some JDK1.1 3-letter TZ Ids > http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/67c41d740e6d > > changeset: 1693:92b6482e7719 > user: peytoia > date: Mon Aug 31 14:53:05 2009 +0900 > summary: 6456628: (tz) Default timezone is incorrectly set > occasionally on Linux > http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/92b6482e7719 > > These other backports approved. > and http://cr.openjdk.java.net/~andrew/tz/webrev.02 which needs a bug ID. > Approved to use 6908946 "(tz) Sync JDK 7 tz changes into OpenJDK 6" for this change. Thanks, -Joe From Joe.Darcy at Sun.COM Wed Dec 9 12:03:04 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Wed, 09 Dec 2009 12:03:04 -0800 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <17c6771e0912081431s27fb6826qc2f666296d968cc3@mail.gmail.com> References: <4AF4B948.5070702@sun.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> <4B1E9C6A.8050704@sun.com> <4B1E9E3A.7060008@sun.com> <17c6771e0912081147o69c95111m6ecd79a0b69da5ca@mail.gmail.com> <4B1EAE30.9080807@sun.com> <17c6771e0912081159x32dcf3f2k572655412e921731@mail.gmail.com> <4B1EBFA3.8000201@sun.com> <17c6771e0912081431s27fb6826qc2f666296d968cc3@mail.gmail.com> Message-ID: <4B200278.8090108@sun.com> Andrew John Hughes wrote: > 2009/12/8 Joseph D. Darcy : > >> Andrew John Hughes wrote: >> >>> 2009/12/8 Joseph D. Darcy : >>> >>> >>>> Andrew John Hughes wrote: >>>> >>>> >>>>> 2009/12/8 Kelly O'Hair : >>>>> >>>>> >>>>> >>>>>> Jonathan Gibbons wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Andrew John Hughes wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Finally, during build, I just spotted another issue. The langtools >>>>>>>> build wrongly passes -Werror to javac and this has been removed in >>>>>>>> the >>>>>>>> OpenJDK7 version. It only shows up if you build OpenJDK6 with >>>>>>>> OpenJDK7, so it's minor but probably worth fixing. I doubt that is >>>>>>>> the only building-with-7 issue though. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> Building OpenJDK6 "with" OpenJDK7? >>>>>> You mean with an ALT_BOOTDIR=jdk7? Why? >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Why not? I happen to have a system install of OpenJDK7 m5 and not >>>>> OpenJDK6 at present - the reason for that is exactly because you can't >>>>> install 7 and then use it to build 6. I've since been able to build >>>>> OpenJDK6 using a recent build of IcedTea6 (which uses gcj to build). >>>>> But surely 7 should be able to build 6? >>>>> >>>>> >>>>> >>>> I suspect the build issue is that the JDK 7 Werror checking is more >>>> stringent than the OpenJDK 6 error checking and the OpenJDK 6 sources do >>>> not >>>> have the fixes necessary to build under JDK 7 using Werror although they >>>> do >>>> build under OpenJDK 6 with Werror. >>>> >>>> -Joe >>>> >>>> >>>> >>> Indeed, the OJ7 version has this fix: >>> >>> changeset: 214:9d541fd2916b >>> parent: 212:49281ea88125 >>> user: jjg >>> date: Fri Feb 06 10:23:57 2009 -0800 >>> summary: 6595666: fix -Werror >>> >>> which includes actually documenting the option in the javac output. >>> I missed Jonathan's later change because I was searching for Werror >>> rather than checking that file. >>> Can we backport the warning fixup? >>> >>> >> I'm open to OpenJDK 6 langtools being made Werror clean as judged by JDK 7, >> but backporting the fixes may be nontrivial. (The Werror checking in JDK >> 7's javac is more stringent than that in OpenJDK 6.) >> >> -Joe >> >> > > I think we got sidetracked by the minor mention I made of this. To go > back a few steps -- do you have an opinion on the timezone fixes? > Yes; those are approved as I've just replied to the original email. -Joe From Joe.Darcy at Sun.COM Wed Dec 9 13:42:43 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Wed, 09 Dec 2009 13:42:43 -0800 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <17c6771e0912081207q4e4f99fh10d6aaa864901052@mail.gmail.com> References: <4AF4B948.5070702@sun.com> <4B1DF24C.9020308@sun.com> <17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> <4B1E9C6A.8050704@sun.com> <17c6771e0912081143pe31d4dk122c689ae003db16@mail.gmail.com> <4B1EAD76.7000000@sun.com> <4B1EB067.9060301@sun.com> <17c6771e0912081207q4e4f99fh10d6aaa864901052@mail.gmail.com> Message-ID: <4B2019D3.7000806@sun.com> Andrew John Hughes wrote: > 2009/12/8 Jonathan Gibbons : > >> Joseph D. Darcy wrote: >> >>> Andrew John Hughes wrote: >>> >>>> 2009/12/8 Jonathan Gibbons : >>>> >>>> >>>>> Andrew John Hughes wrote: >>>>> >>>>> >>>>>> Finally, during build, I just spotted another issue. The langtools >>>>>> build wrongly passes -Werror to javac and this has been removed in the >>>>>> OpenJDK7 version. It only shows up if you build OpenJDK6 with >>>>>> OpenJDK7, so it's minor but probably worth fixing. I doubt that is >>>>>> the only building-with-7 issue though. >>>>>> >>>>>> >>>>>> >>>>> langtools is supposed to be warning free and thus is supposed to use >>>>> -Werror. >>>>> >>>>> -- Jon >>>>> >>>>> >>>>> >>>> Not according to this changeset of yours: >>>> >>>> http://hg.openjdk.java.net/jdk7/jdk7/langtools/rev/12c9e612e9e31 >>>> >>>> >>> The removal of Werror from langtools in JDK 7 was a transitory change; it >>> came back as part of Jon's subsequent changset: >>> >>> http://hg.openjdk.java.net/jdk7/jdk7/langtools/rev/b4b1f7732289 >>> >>> -Joe >>> >> When the langtools repository was originally created, there were different >> coding standards for different tools, with the bar being higher for some >> than for others. That is why at that time we could not use -Werror for all >> tools. Once we finally made the entire repository warning-free, it made >> sense to impose -Werror as a check that we maintained that level. >> >> -- Jon >> >> > > I'm glad the code is Werror free. Those of us working on IcedTea are > certainly aware that the rest of the JDK code certainly isn't; when we > bootstrap with ecj some 14k warnings are thrown out from the OpenJDK > code (ecj is much more noisy by default) leading to -nowarn being > added. > > The issue here is that the -Werror bit is in OpenJDK6 but the actual > fix is not. It's strange because -unchecked seems to be being passed, > yet unchecked warnings are being thrown. > The JDK 7 compiler does a better check of checking for unchecked problems. After the voluminous thread yesterday, my sense is that : * It is not appropriate or necessary to backport the javap rewrite to OpenJDK 6. * Having the OpenJDK 6 langtools code be able to pass through the JDK 7 compiler under Werror would at most be a "nice to have" feature. * Using the JDK 7 compiler to perform full bootstrap cycle for OpenJDK 6 is impractical because it uses a new class file format not understood by Java SE 6 compilers. -Joe From Erik.Trimble at Sun.COM Thu Dec 10 06:22:20 2009 From: Erik.Trimble at Sun.COM (Erik Trimble) Date: Thu, 10 Dec 2009 06:22:20 -0800 Subject: Supplemental Build 13 of Hotspot 16 is now promoted... Message-ID: <4B21041C.4020304@sun.com> There's been another build of Hotspot 16 B13 (I know, a bit confusing), this time including a couple of high-priority fixes for Sun 6u18. This Hotspot build will be integrated into the Sun JDK 6 Update 18 Build 06 codebase. Barring any (unknown) show-stoppers, this Build 13 should be the last build of Hotspot 16 before the release of 6u18. The latest promoted bits can be found (as usual) in: http://hg.openjdk.java.net/hsx/hsx16/master The Hg tip for this build is: http://hg.openjdk.java.net/hsx/hsx16/master/rev/62926c7f67a3 There was a PIT waiver issued for CR 6908208, as it was a one-line minor fix, related to a single test case failure. Here is the PIT certificate for the other CRs: ============= Component : VM Status : 0 major failures, 1 minor failures Date : 12/07/2009 at 14:26 Tested By : Ekaterina.Pavlova at sun.com and VMSQE Cost(total man-days): 1 Workspace : http://hg.openjdk.java.net/hsx/hsx16/master Bundles : /net/jprt-web.sfbay/jprt/archive/2009/12/2009-12-04-235107.et151817.13b/bundles/ Platforms : Solaris Sparc 11(32), -client Solaris Sparc 11(32), -server Solaris Sparc 10(32), -client Solaris Sparc 10(32), -server Solaris x86 11(32), -client Solaris x86 11(32), -server Solaris x86 10(32), -client Solaris x86 10(32), -server WinXP Prof(32), -client WinXP Prof(32), -server WinXP Home(32), -client WinXP Home(32), -server Win Server 2003(32), -client Win Server 2003(32), -server Windows Vista 32 bit, -client Windows Vista 32 bit, -server Windows Vista 64 bit, -server RH AS4.0 (32), -client RH AS4.0 (32), -server Solaris AMD64(32jdk), -server Solaris AMD64(32jdk), -client Solaris AMD64(64jdk), -d64/-server Sol Sparc 10(64OS)(32jdk), -server Sol Sparc 10(64OS)(32jdk), -client Sol Sparc 10(64OS)(64jdk), -d64/-server win server2003 AMD(64OS)(32jdk), -server win server2003 AMD(64OS)(32jdk), -client win server2003 AMD(64OS)(64jdk), -server RH AS4.0 AMD(64OS)(32jdk), -server RH AS4.0 AMD(64OS)(32jdk), -client RH AS4.0 AMD(64OS)(64jdk), -server Others Tests : /net/sqenfs-1.sfbay/export1/comp/vm/testbase/ Browsers : NA Patches : NA Logs : http://sqeweb.sfbay/nfs/tools/gtee/results/HSX/PIT/VM/16/b13b/jdk6u18b06 Number of Tests Executed : 619331 product tests, 0 unit tests, 0 tck tests Bug verification status: ====================================== Tested, Pass: 6822370: ReentrantReadWriteLock: threads hung when there are no threads holding onto the lock (Netra x4450) Tested, Pass (partial fixes): Tested, Fail: Untested bug fixes: Bugs/rfes with no unit tests: 6906727: UseCompressedOops: some card-marking fixes related to object arrays Other reasons: New bugs filed: Bugs in PIT build: Bugs in earlier promoted build: Number of PIT requested: 2 Integration target J2SE build number: 1.6.0_18-b06 Issues and Notes: This is an additional build of Hotspot 16-b13 for JDK 6u18-b06 with 2 CRs fixed. Note, 6906727 is marked as not verified. However, this CR was tested and verified by customer. ------------------------------- >From Ekaterina.Pavlova at sun.com and VMSQE -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) From ahughes at redhat.com Thu Dec 10 07:30:05 2009 From: ahughes at redhat.com (ahughes at redhat.com) Date: Thu, 10 Dec 2009 15:30:05 +0000 Subject: hg: jdk6/jdk6/jdk: 9 new changesets Message-ID: <20091210153206.D7F8D418F1@hg.openjdk.java.net> Changeset: dd7bee87435c Author: peytoia Date: 2008-10-16 14:00 +0900 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/dd7bee87435c 6758988: (tz) Support tzdata2008h Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/zone.tab Changeset: 66c5932c6e9c Author: peytoia Date: 2008-10-30 13:12 +0900 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/66c5932c6e9c 6764308: (tz) Support tzdata2008i Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: 499ee04796c9 Author: peytoia Date: 2009-01-26 09:19 +0900 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/499ee04796c9 6796489: (tz) Support tzdata2009a Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/backward ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: f80718c987df Author: peytoia Date: 2009-05-12 15:21 +0900 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/f80718c987df 6834474: (tz) Support tzdata2009g Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/leapseconds ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/southamerica ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: d029d2bdb2e7 Author: peytoia Date: 2009-12-08 17:25 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/d029d2bdb2e7 6872467: (tz) Support tzdata2009l Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/antarctica ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/backward ! make/sun/javazic/tzdata/etcetera ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/factory ! make/sun/javazic/tzdata/iso3166.tab ! make/sun/javazic/tzdata/leapseconds ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/pacificnew ! make/sun/javazic/tzdata/solar87 ! make/sun/javazic/tzdata/solar88 ! make/sun/javazic/tzdata/solar89 ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/systemv ! make/sun/javazic/tzdata/zone.tab Changeset: 616511f0ab70 Author: peytoia Date: 2009-09-01 15:42 +0900 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/616511f0ab70 6838887: (tz) Add UTC and Yerevan to tzmappings Reviewed-by: okutsu ! src/windows/lib/tzmappings Changeset: c22d5931cf56 Author: peytoia Date: 2009-12-08 17:30 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/c22d5931cf56 6899397: (tz) Support tzdata2009r Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/antarctica ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: f706306c73ab Author: andrew Date: 2009-12-10 15:27 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/f706306c73ab 6908946: (tz) Sync JDK 7 tz changes into OpenJDK 6 Summary: Remove remaining discrepancies between OpenJDK6 and 7 timezone data. Reviewed-by: darcy ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/antarctica ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata_jdk/jdk11_full_backward Changeset: daf1e86ee06e Author: andrew Date: 2009-12-10 15:29 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/daf1e86ee06e Merge - test/sun/tools/native2ascii/test2 From ahughes at redhat.com Thu Dec 10 07:44:10 2009 From: ahughes at redhat.com (ahughes at redhat.com) Date: Thu, 10 Dec 2009 15:44:10 +0000 Subject: hg: jdk6/jdk6/jdk: 2 new changesets Message-ID: <20091210154437.00BE9418F5@hg.openjdk.java.net> Changeset: a549470ddc64 Author: peytoia Date: 2008-09-08 15:21 +0900 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/a549470ddc64 6466476: (tz) Introduction of tzdata2005r can introduce incompatility issues with some JDK1.1 3-letter TZ Ids Reviewed-by: okutsu ! make/java/java/FILES_java.gmk + src/share/classes/sun/util/calendar/TzIDOldMapping.java ! src/share/classes/sun/util/calendar/ZoneInfo.java + test/java/util/TimeZone/OldIDMappingTest.java + test/java/util/TimeZone/OldIDMappingTest.sh Changeset: 1a53516ce032 Author: peytoia Date: 2009-08-31 14:53 +0900 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/1a53516ce032 6456628: (tz) Default timezone is incorrectly set occasionally on Linux Reviewed-by: okutsu ! src/solaris/native/java/util/TimeZone_md.c From gnu_andrew at member.fsf.org Thu Dec 10 10:06:09 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 10 Dec 2009 18:06:09 +0000 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <4B2001D8.8020602@sun.com> References: <4AF4B948.5070702@sun.com> <17c6771e0911130845o6138d6bei1d8bb76c3fe13e4e@mail.gmail.com> <4AFDC095.4060103@sun.com> <4B1DF24C.9020308@sun.com> <17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> <17c6771e0912081019i234a9646pfa24ecf4551ac33b@mail.gmail.com> <4B2001D8.8020602@sun.com> Message-ID: <17c6771e0912101006s7a114e46xa101460b8632019a@mail.gmail.com> 2009/12/9 Joseph D. Darcy : > Andrew John Hughes wrote: >> >> 2009/12/8 Andrew John Hughes : >> >>> >>> 2009/12/8 Joseph D. Darcy : >>> >>>> >>>> Andrew John Hughes wrote: >>>> >>>>> >>>>> 2009/12/8 Andrew John Hughes : >>>>> >>>>> >>>>>> >>>>>> 2009/12/8 Joseph D. Darcy : >>>>>> >>>>>> >>>>>>> >>>>>>> Joseph D. Darcy wrote: >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Andrew John Hughes wrote: >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> 2009/11/13 Joseph D. Darcy : >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Andrew John Hughes wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2009/11/10 Andrew John Hughes : >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> [snip] >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Still need to look at this, but was wondering what was happening >>>>>>>>>>> with >>>>>>>>>>> timezone data in 6? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> It doesn't seem like much of anything is happening with timezone >>>>>>>>>> data >>>>>>>>>> in >>>>>>>>>> OpenJDK 6! >>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>>>> [snip] >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>> >>>>>>>>>> I'd appreciate if you could backport these timezone changes. >>>>>>>>>> >>>>>>>>>> -Joe >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> Ok, no problem. >>>>>>>>> >>>>>>>>> So I make it for b18 we still have: >>>>>>>>> >>>>>>>>> ?* the issue with the X11 patch I can't apply because of jcheck >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> I'll check in with Mark, but we're both speaking at Devoxx next week >>>>>>>> so >>>>>>>> recognizing Latin-1 characters in jcheck may not happen immediately. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> ?* Nimbus issues >>>>>>>>> ?* the diff issue with HotSpot Martin pointed out >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Right. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Do we also want the timezone data changes for b18 or shall we do >>>>>>>>> that >>>>>>>>> in b19? I think b19's main feature is likely to be hs16. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> I think the time zone updates would be better in b18; the nature of >>>>>>>> these >>>>>>>> changes is very well-understood. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Some time has passed, a few more fixes have come into the repos, and >>>>>>> I'm >>>>>>> beginning to think it would better to have OpenJDK 6 b18 be more or >>>>>>> less >>>>>>> what is there now and to have the timezone update and other changes >>>>>>> go >>>>>>> into >>>>>>> b19. >>>>>>> >>>>>>> Thoughts? >>>>>>> >>>>>>> -Joe >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> Sorry, I've been distracted with first the OpenJDK7 release and then >>>>>> time off work. ?Backporting the timezone stuff should be fairly >>>>>> trivial. ?I'll have a try today and if it isn't, then we can consider >>>>>> delaying it. >>>>>> >>>>>> >>>> >>>> Okay. >>>> >>>> >>>>>> >>>>>> I think we do need to get the Nimbus fixes in. ?I'm trying to get >>>>>> IcedTea6 working against OpenJDK6 hg so I can test this, and all the >>>>>> JAXWS/JAXP changes don't make that a simple job. ?But it's in >>>>>> progress. >>>>>> >>>>>> Is there any news on updating jcheck? ?I still haven't been able to >>>>>> push the X11 fix. >>>>>> >>>>>> >>>> >>>> I've pinged Mark but haven't heard back. >>>> >>>> Unfortunately, the most expedient way to get this fix back to probably >>>> to >>>> ASCII-fy the contributor's name. >>>> >>>> >>> >>> I've already tried that. ?Whatever jcheck is doing goes beyond ASCII >>> as it doesn't accept a backtick either (o` is the ASCIIfied version) >>> >>> As with other issues with jcheck, if it was open-sourced we wouldn't >>> have Mark as a bottleneck for fixing the inevitable issues with it. >>> >>> This is a fairly serious issue; I currently can't build OpenJDK6 >>> unless I apply that patch first and no doubt others will see this too >>> (all F12 users for a start). >>> >>> >>>>>> >>>>>> In response to Erik's e-mail, I'd be happier making HotSpot b16 part >>>>>> of b19 rather than b18, so we have more time for testing. >>>>>> >>>>>> >>>> >>>> Yes, the HotSpot upgrade should occur in b19. >>>> >>>> >>>>>> >>>>>> So still: >>>>>> >>>>>> * Timezone fixes >>>>>> * Nimbus fixes >>>>>> >>>>>> >>>> >>>> Nimbus backports from JDK 7 I assume. >>>> >>>> >>> >>> There is one, but I was thinking of the test issues you raised in >>> previous emails. >>> >>> >>>>>> >>>>>> * X11 fix >>>>>> >>>>>> for b18 from my side. ?Is there some rush to get this out? >>>>>> >>>>>> >>>> >>>> No rush per se, but with the holiday coming up (including my on vacation >>>> soon), if the build doesn't happen in the next week or so, it probably >>>> won't >>>> happen until January and I'd prefer to get a build with the security >>>> fixes >>>> officially out before then. >>>> >>>> >>> >>> Well, I think most things can probably be sorted this week. ?The X11 >>> fix is the real blocker. ?Can we not just turn jcheck off or something >>> for one commit? >>> >>> I'm currently building OpenJDK6 with the timezone fixes applied and it >>> looks ok so far. ?I'll post a webrev once it completes. >>> >>> There are two more tz issues worthy of consideration that I didn't >>> include yet because they are not related to the data, but would be >>> good to have. ?One adds support for old timezone IDs (I'm wary of this >>> because it introduces a property) and the other fixes an issue with >>> determining the timezone on GNU/Linux boxes which I believe will >>> obsolete a different but related fix in IcedTea6. ?I'd also like to >>> add a simple patch which fixes up the remaining data differences >>> between 6 and 7 (just typos and revision headers) which seems to have >>> occurred in the black hole between the OpenJDK6 fork and the OpenJDK7 >>> hg repositories. >>> >>> Finally, during build, I just spotted another issue. ?The langtools >>> build wrongly passes -Werror to javac and this has been removed in the >>> OpenJDK7 version. ?It only shows up if you build OpenJDK6 with >>> OpenJDK7, so it's minor but probably worth fixing. ?I doubt that is >>> the only building-with-7 issue though. >>> >>> >>>>> >>>>> Just remembered about Kelly's JDI work; that would be good to get in >>>>> and being test-related, shouldn't break anything about the build or >>>>> JDK itself. >>>>> >>>>> >>>> >>>> There are a bunch of source changes too, but they have been in JDK 7 for >>>> a >>>> while so they should be fine for OpenJDK 6. >>>> >>>> -Joe >>>> >>>> >>> >>> -- >>> Andrew :-) >>> >>> Free Java Software Engineer >>> Red Hat, Inc. (http://www.redhat.com) >>> >>> Support Free Java! >>> Contribute to GNU Classpath and the OpenJDK >>> http://www.gnu.org/software/classpath >>> http://openjdk.java.net >>> >>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >>> >>> >> >> No sooner did I write that than it built: >> >> http://cr.openjdk.java.net/~andrew/tz/webrev.01/ >> > > Approved. > >> The remaining three tz fixes are: >> >> changeset: ? 639:67c41d740e6d >> user: ? ? ? ?peytoia >> date: ? ? ? ?Mon Sep 08 15:21:55 2008 +0900 >> summary: ? ? 6466476: (tz) Introduction of tzdata2005r can introduce >> incompatility issues with some JDK1.1 3-letter TZ Ids >> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/67c41d740e6d >> >> changeset: ? 1693:92b6482e7719 >> user: ? ? ? ?peytoia >> date: ? ? ? ?Mon Aug 31 14:53:05 2009 +0900 >> summary: ? ? 6456628: (tz) Default timezone is incorrectly set >> occasionally on Linux >> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/92b6482e7719 >> >> > > These other backports approved. > >> and http://cr.openjdk.java.net/~andrew/tz/webrev.02 which needs a bug ID. >> > > Approved to use 6908946 "(tz) Sync JDK 7 tz changes into OpenJDK 6" for this > change. > > Thanks, > > -Joe > Thanks. All of them are now in OpenJDK6. There is one more backport lurking in IcedTea6: http://cr.openjdk.java.net/~andrew/tz/webrev.03/ The actual code fix went in to OpenJDK7 in the black hole between the two (b22): http://mail.openjdk.java.net/pipermail/security-dev/2009-August/001153.html There should be a bug ID as a result -- presumably, you can discover that internally? The test case included in the webrev is from Mark Wielaard and is contributed through Red Hat's SCA. CCing i18n-dev in case they have any input; it would be nice to have the test case in 7 too as well as the fix. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Joe.Darcy at Sun.COM Thu Dec 10 11:55:01 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Thu, 10 Dec 2009 11:55:01 -0800 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <17c6771e0912101006s7a114e46xa101460b8632019a@mail.gmail.com> References: <4AF4B948.5070702@sun.com> <17c6771e0911130845o6138d6bei1d8bb76c3fe13e4e@mail.gmail.com> <4AFDC095.4060103@sun.com> <4B1DF24C.9020308@sun.com> <17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> <17c6771e0912081019i234a9646pfa24ecf4551ac33b@mail.gmail.com> <4B2001D8.8020602@sun.com> <17c6771e0912101006s7a114e46xa101460b8632019a@mail.gmail.com> Message-ID: <4B215215.5050104@sun.com> Andrew John Hughes wrote: > 2009/12/9 Joseph D. Darcy : > >> Andrew John Hughes wrote: >> >>> 2009/12/8 Andrew John Hughes : >>> >>> >>>> 2009/12/8 Joseph D. Darcy : >>>> >>>> [snip] >>>> >>>> >>>> >>> No sooner did I write that than it built: >>> >>> http://cr.openjdk.java.net/~andrew/tz/webrev.01/ >>> >>> >> Approved. >> >> >>> The remaining three tz fixes are: >>> >>> changeset: 639:67c41d740e6d >>> user: peytoia >>> date: Mon Sep 08 15:21:55 2008 +0900 >>> summary: 6466476: (tz) Introduction of tzdata2005r can introduce >>> incompatility issues with some JDK1.1 3-letter TZ Ids >>> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/67c41d740e6d >>> >>> changeset: 1693:92b6482e7719 >>> user: peytoia >>> date: Mon Aug 31 14:53:05 2009 +0900 >>> summary: 6456628: (tz) Default timezone is incorrectly set >>> occasionally on Linux >>> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/92b6482e7719 >>> >>> >>> >> These other backports approved. >> >> >>> and http://cr.openjdk.java.net/~andrew/tz/webrev.02 which needs a bug ID. >>> >>> >> Approved to use 6908946 "(tz) Sync JDK 7 tz changes into OpenJDK 6" for this >> change. >> >> Thanks, >> >> -Joe >> >> > > Thanks. All of them are now in OpenJDK6. > > There is one more backport lurking in IcedTea6: > > http://cr.openjdk.java.net/~andrew/tz/webrev.03/ > > The actual code fix went in to OpenJDK7 in the black hole between the > two (b22): http://mail.openjdk.java.net/pipermail/security-dev/2009-August/001153.html > There should be a bug ID as a result -- presumably, you can discover > that internally? > Donning my fedora and brandishing a bullwhip, the bug id for this change was 6584033 "(tz) wrong buffer length in TimeZone_md.c"; from sccsdiff: ------- TimeZone.java ------- 606,610c606 < if (hasPermission()) { < defaultTimeZone = tz; < } else { < defaultZoneTL.set(tz); < } --- > defaultTimeZone = tz; 640a637 > defaultZoneTL.set(null); There was another file involved in this change, windows/native/java/util/TimeZone_md.c: ------- TimeZone_md.c ------- 199a200 > bufSize = sizeof(val); 347c348 < valueSize = MAX_ZONE_CHAR; --- > valueSize = MAX_MAPID_LENGTH; This is also the current difference between the OpenJDK 6 and JDK 7 versions of this file. > The test case included in the webrev is from Mark Wielaard and is > contributed through Red Hat's SCA. > There appears to be some test coverage of this change in still-closed regression tests. > CCing i18n-dev in case they have any input; it would be nice to have > the test case in 7 too as well as the fix. > I'll approve this change going back if the change from the JDK 7 version of TimeZone.java and TimeZone_md.c are both applied to OpenJDK 6 and if the @bug line in the test includes 6584033. Thanks, -Joe From gnu_andrew at member.fsf.org Thu Dec 10 13:30:17 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 10 Dec 2009 21:30:17 +0000 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <4B215215.5050104@sun.com> References: <4AF4B948.5070702@sun.com> <4B1DF24C.9020308@sun.com> <17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> <17c6771e0912081019i234a9646pfa24ecf4551ac33b@mail.gmail.com> <4B2001D8.8020602@sun.com> <17c6771e0912101006s7a114e46xa101460b8632019a@mail.gmail.com> <4B215215.5050104@sun.com> Message-ID: <17c6771e0912101330q207ae49erf0583ff264ec1169@mail.gmail.com> 2009/12/10 Joseph D. Darcy : > Andrew John Hughes wrote: >> >> 2009/12/9 Joseph D. Darcy : >> >>> >>> Andrew John Hughes wrote: >>> >>>> >>>> 2009/12/8 Andrew John Hughes : >>>> >>>> >>>>> >>>>> 2009/12/8 Joseph D. Darcy : >>>>> >>>>> > > [snip] >>>>> >>>>> >>>>> >>>> >>>> No sooner did I write that than it built: >>>> >>>> http://cr.openjdk.java.net/~andrew/tz/webrev.01/ >>>> >>>> >>> >>> Approved. >>> >>> >>>> >>>> The remaining three tz fixes are: >>>> >>>> changeset: ? 639:67c41d740e6d >>>> user: ? ? ? ?peytoia >>>> date: ? ? ? ?Mon Sep 08 15:21:55 2008 +0900 >>>> summary: ? ? 6466476: (tz) Introduction of tzdata2005r can introduce >>>> incompatility issues with some JDK1.1 3-letter TZ Ids >>>> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/67c41d740e6d >>>> >>>> changeset: ? 1693:92b6482e7719 >>>> user: ? ? ? ?peytoia >>>> date: ? ? ? ?Mon Aug 31 14:53:05 2009 +0900 >>>> summary: ? ? 6456628: (tz) Default timezone is incorrectly set >>>> occasionally on Linux >>>> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/92b6482e7719 >>>> >>>> >>>> >>> >>> These other backports approved. >>> >>> >>>> >>>> and http://cr.openjdk.java.net/~andrew/tz/webrev.02 which needs a bug >>>> ID. >>>> >>>> >>> >>> Approved to use 6908946 "(tz) Sync JDK 7 tz changes into OpenJDK 6" for >>> this >>> change. >>> >>> Thanks, >>> >>> -Joe >>> >>> >> >> Thanks. All of them are now in OpenJDK6. >> >> There is one more backport lurking in IcedTea6: >> >> http://cr.openjdk.java.net/~andrew/tz/webrev.03/ >> >> The actual code fix went in to OpenJDK7 in the black hole between the >> two (b22): >> http://mail.openjdk.java.net/pipermail/security-dev/2009-August/001153.html >> ?There should be a bug ID as a result -- presumably, you can discover >> that internally? >> > > Donning my fedora and brandishing a bullwhip, the bug id for this change was > 6584033 "(tz) wrong buffer length in TimeZone_md.c"; from sccsdiff: > > ------- TimeZone.java ------- > 606,610c606 > < ? ? ? if (hasPermission()) { > < ? ? ? ? ? defaultTimeZone = tz; > < ? ? ? } else { > < ? ? ? ? ? defaultZoneTL.set(tz); > < ? ? ? } > --- >> ? ? ? defaultTimeZone = tz; > 640a637 >> ? ? ? ? ? ? ? defaultZoneTL.set(null); > > There was another file involved in this change, > windows/native/java/util/TimeZone_md.c: > > ------- TimeZone_md.c ------- > 199a200 >> ? ? ? ? bufSize = sizeof(val); > 347c348 > < ? ? valueSize = MAX_ZONE_CHAR; > --- >> ? ? valueSize = MAX_MAPID_LENGTH; > > This is also the current difference between the OpenJDK 6 and JDK 7 versions > of this file. > >> The test case included in the webrev is from Mark Wielaard and is >> contributed through Red Hat's SCA. >> > > There appears to be some test coverage of this change in still-closed > regression tests. > >> CCing i18n-dev in case they have any input; it would be nice to have >> the test case in 7 too as well as the fix. >> > > I'll approve this change going back if the change from the JDK 7 version of > TimeZone.java and TimeZone_md.c are both applied to OpenJDK 6 and if the > @bug line in the test includes 6584033. > > Thanks, > > -Joe > I added the fixes mentioned and tried to push. I was greeted with this: remote: remote: test/java/util/TimeZone/TimeZoneDatePermissionCheck.sh: Executable files not permitted remote: Funny because: $ find test -name '*.sh'|wc -l 305 And no it isn't because of the executable permission bit, I did a chmod -x to be sure and it still didn't push :( -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From martinrb at google.com Thu Dec 10 17:06:26 2009 From: martinrb at google.com (Martin Buchholz) Date: Thu, 10 Dec 2009 17:06:26 -0800 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <17c6771e0912101330q207ae49erf0583ff264ec1169@mail.gmail.com> References: <4AF4B948.5070702@sun.com> <17c6771e0912080529g48a66090o87eb118a9bff15ed@mail.gmail.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> <17c6771e0912081019i234a9646pfa24ecf4551ac33b@mail.gmail.com> <4B2001D8.8020602@sun.com> <17c6771e0912101006s7a114e46xa101460b8632019a@mail.gmail.com> <4B215215.5050104@sun.com> <17c6771e0912101330q207ae49erf0583ff264ec1169@mail.gmail.com> Message-ID: <1ccfd1c10912101706i23ff9d59ud625ca029955b057@mail.gmail.com> On Thu, Dec 10, 2009 at 13:30, Andrew John Hughes wrote: > 2009/12/10 Joseph D. Darcy : > I added the fixes mentioned and tried to push. I was greeted with this: > > remote: > remote: test/java/util/TimeZone/TimeZoneDatePermissionCheck.sh: > Executable files not permitted > remote: > > Funny because: > > $ find test -name '*.sh'|wc -l > 305 > > And no it isn't because of the executable permission bit, I did a > chmod -x to be sure and it still didn't push :( I ran into jcheck executable file refusal for .sh files, and for me, chmod -x did work. Did you forget to "hg qrefresh" after fixing up the permissions (I'm leaving out some details)? Martin From ahughes at redhat.com Fri Dec 11 07:11:41 2009 From: ahughes at redhat.com (ahughes at redhat.com) Date: Fri, 11 Dec 2009 15:11:41 +0000 Subject: hg: jdk6/jdk6/jdk: 6584033: (tz) wrong buffer length in TimeZone_md.c Message-ID: <20091211151156.151E841A72@hg.openjdk.java.net> Changeset: 126b700b2af4 Author: andrew Date: 2009-12-11 15:10 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/126b700b2af4 6584033: (tz) wrong buffer length in TimeZone_md.c Summary: Add buffer length to TimeZone and remove recursive security check Reviewed-by: darcy ! src/share/classes/java/util/TimeZone.java ! src/windows/native/java/util/TimeZone_md.c + test/java/util/TimeZone/TimeZoneDatePermissionCheck.java + test/java/util/TimeZone/TimeZoneDatePermissionCheck.sh From ahughes at redhat.com Fri Dec 11 07:27:24 2009 From: ahughes at redhat.com (ahughes at redhat.com) Date: Fri, 11 Dec 2009 15:27:24 +0000 Subject: hg: jdk6/jdk6/jdk: 6909442: Fix comments in test/sun/tools/jhat/HatRun.java Message-ID: <20091211152737.BF63541A78@hg.openjdk.java.net> Changeset: f55e0d8667cb Author: andrew Date: 2009-12-11 15:27 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/f55e0d8667cb 6909442: Fix comments in test/sun/tools/jhat/HatRun.java Summary: Update the comments in this test to match the changes in 6902325 Reviewed-by: ohair ! test/sun/tools/jhat/HatRun.java From gnu_andrew at member.fsf.org Fri Dec 11 07:30:48 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 11 Dec 2009 15:30:48 +0000 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <1ccfd1c10912101706i23ff9d59ud625ca029955b057@mail.gmail.com> References: <4AF4B948.5070702@sun.com> <17c6771e0912080544o656e886ep97b95203d3f90773@mail.gmail.com> <4B1E8D68.3090709@sun.com> <17c6771e0912081010g649f88e1l7921559fa518bf3e@mail.gmail.com> <17c6771e0912081019i234a9646pfa24ecf4551ac33b@mail.gmail.com> <4B2001D8.8020602@sun.com> <17c6771e0912101006s7a114e46xa101460b8632019a@mail.gmail.com> <4B215215.5050104@sun.com> <17c6771e0912101330q207ae49erf0583ff264ec1169@mail.gmail.com> <1ccfd1c10912101706i23ff9d59ud625ca029955b057@mail.gmail.com> Message-ID: <17c6771e0912110730x6638a86cwc399f786843fff3a@mail.gmail.com> 2009/12/11 Martin Buchholz : > On Thu, Dec 10, 2009 at 13:30, Andrew John Hughes > wrote: >> 2009/12/10 Joseph D. Darcy : >> I added the fixes mentioned and tried to push. I was greeted with this: >> >> remote: >> remote: test/java/util/TimeZone/TimeZoneDatePermissionCheck.sh: >> Executable files not permitted >> remote: >> >> Funny because: >> >> $ find test -name '*.sh'|wc -l >> 305 >> >> And no it isn't because of the executable permission bit, I did a >> chmod -x to be sure and it still didn't push :( > > I ran into jcheck executable file refusal for .sh files, and for me, > chmod -x did work. ?Did you forget to "hg qrefresh" after fixing > up the permissions (I'm leaving out some details)? > > Martin > Doh! Rolling it back and doing the chmod -x worked. Thanks Martin! -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From ahughes at redhat.com Fri Dec 11 08:02:10 2009 From: ahughes at redhat.com (ahughes at redhat.com) Date: Fri, 11 Dec 2009 16:02:10 +0000 Subject: hg: jdk6/jdk6/jdk: 2 new changesets Message-ID: <20091211160303.1D17441A85@hg.openjdk.java.net> Changeset: bd2e4488d673 Author: darcy Date: 2009-12-10 13:28 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/bd2e4488d673 4891262: API spec, javax/accessibility: few invalid javadoc tags Reviewed-by: jjg ! src/share/classes/javax/accessibility/AccessibleContext.java ! src/share/classes/javax/accessibility/AccessibleExtendedText.java ! src/share/classes/javax/accessibility/AccessibleKeyBinding.java Changeset: b202c79afde3 Author: darcy Date: 2009-12-10 13:04 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/b202c79afde3 6909070: Missing package statements in java.text.Bidi @see links Reviewed-by: anthony ! src/share/classes/java/text/Bidi.java From gnu_andrew at member.fsf.org Sun Dec 13 05:46:15 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Sun, 13 Dec 2009 13:46:15 +0000 Subject: hg: hsx/hsx16/baseline: 6909480: Disable Escape Analysis in jdk6u18 In-Reply-To: <4B21E924.9000701@sun.com> References: <20091211031351.A0521419B3@hg.openjdk.java.net> <4B21E924.9000701@sun.com> Message-ID: <17c6771e0912130546u7759e2c0k4a4485074524bb83@mail.gmail.com> 2009/12/11 Vladimir Kozlov : > Yes, users will not be able to switch it on in jdk6u18. > > Currently it is still experimental optimization > and it could produce incorrect results. > > Use early access jdk7 if you want to try it. > > Vladimir > > On 12/10/09 10:14 PM, Ismael Juma wrote: >> >> Hey Vladimir, >> >> ? ?writes: >>> >>> 6909480: Disable Escape Analysis in jdk 6u18 >>> Summary: Disable Escape Analysis in jdk 6u18. >> >> Does this mean that escape analysis will be disabled in 6u18 even if a >> user >> explicitly enables it? If so, is it a stability issue? Sorry if this has >> been >> discussed already (I looked for a previous discussion, but did not find >> it). >> >> Thanks, >> Ismael >> > I don't think this is the appropriate place for such a patch. By all means, disable escape analysis in Sun's builds but I don't think this is appropriate for being pulled into OpenJDK6 as well. It obviously shouldn't be the default, but if users want to turn on a feature that's there in the codebase, they should be able to. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Daniel.Daugherty at Sun.COM Mon Dec 14 14:25:01 2009 From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty) Date: Mon, 14 Dec 2009 15:25:01 -0700 Subject: [Fwd: code review round 0 for JVM/TI version fix (6849968) and phase assertion (6648438)] Message-ID: <4B26BB3D.2000908@sun.com> Joe, These fixes are ready to be pushed in OpenJDK6. I've already done the pushed into HSX-16.1 and HSX-17 (RT_Baseline). Please let me know if I can push these... Dan -------- Original Message -------- Subject: code review round 0 for JVM/TI version fix (6849968) and phase assertion (6648438) Date: Fri, 11 Dec 2009 15:52:38 -0700 From: Daniel D. Daugherty Reply-To: Daniel.Daugherty at Sun.COM To: serviceability-dev at openjdk.java.net , serviceability-dev-confidential at sun.com Greetings, I have fixes for the following two JVM/TI bugs ready to go: 6648438 4/4 src/share/vm/prims/jvmtiEnv.cpp:457 assert(phase == JVMTI_PHASE_LIVE,"sanity check") 6849968 3/3 JVMTI tests fails on jdk5.0 with hs14 6849968 fixes a problem where JVM/TI version 1.0 semantics were not being used when that version was explicitly requested. I fixed 6648438 because it happened to be in the same place that I already had to tweak for 6849968. It also gets rid of an annoying intermittent fastdebug failure. Here is the webrev URL: http://cr.openjdk.java.net/~dcubed/batch-20091211-webrev/0/ This webrev is relative to the OpenJDK6 version of the code. Once approved, these fixes will be pushed to: - OpenJDK6 (HSX-14-??) - JDK6-Update train (HSX-16-??) - OpenJDK7 (HSX-17-??) Comments, questions and suggestions are always welcome! Dan From Joe.Darcy at Sun.COM Mon Dec 14 15:07:00 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Mon, 14 Dec 2009 15:07:00 -0800 Subject: [Fwd: code review round 0 for JVM/TI version fix (6849968) and phase assertion (6648438)] In-Reply-To: <4B26BB3D.2000908@sun.com> References: <4B26BB3D.2000908@sun.com> Message-ID: <4B26C514.3000704@sun.com> Dan, Assuming this has been reviewed and approved by the serviceability team, you're free to push this into the OpenJDK 6 repo. The current build number to use is b18. Thanks, -Joe Daniel D. Daugherty wrote: > Joe, > > These fixes are ready to be pushed in OpenJDK6. I've already > done the pushed into HSX-16.1 and HSX-17 (RT_Baseline). > > Please let me know if I can push these... > > Dan > > > -------- Original Message -------- > Subject: code review round 0 for JVM/TI version fix (6849968) and > phase assertion (6648438) > Date: Fri, 11 Dec 2009 15:52:38 -0700 > From: Daniel D. Daugherty > Reply-To: Daniel.Daugherty at Sun.COM > To: serviceability-dev at openjdk.java.net > , > serviceability-dev-confidential at sun.com > > > > Greetings, > > I have fixes for the following two JVM/TI bugs ready to go: > > 6648438 4/4 src/share/vm/prims/jvmtiEnv.cpp:457 > assert(phase == JVMTI_PHASE_LIVE,"sanity check") > 6849968 3/3 JVMTI tests fails on jdk5.0 with hs14 > > 6849968 fixes a problem where JVM/TI version 1.0 semantics > were not being used when that version was explicitly > requested. I fixed 6648438 because it happened to be in the > same place that I already had to tweak for 6849968. It also > gets rid of an annoying intermittent fastdebug failure. > > Here is the webrev URL: > > http://cr.openjdk.java.net/~dcubed/batch-20091211-webrev/0/ > > This webrev is relative to the OpenJDK6 version of the code. > Once approved, these fixes will be pushed to: > > - OpenJDK6 (HSX-14-??) > - JDK6-Update train (HSX-16-??) > - OpenJDK7 (HSX-17-??) > > Comments, questions and suggestions are always welcome! > > Dan > > From Daniel.Daugherty at Sun.COM Mon Dec 14 15:10:57 2009 From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty) Date: Mon, 14 Dec 2009 16:10:57 -0700 Subject: [Fwd: code review round 0 for JVM/TI version fix (6849968) and phase assertion (6648438)] In-Reply-To: <4B26C514.3000704@sun.com> References: <4B26BB3D.2000908@sun.com> <4B26C514.3000704@sun.com> Message-ID: <4B26C601.2020005@sun.com> Joseph D. Darcy wrote: > Dan, > > Assuming this has been reviewed and approved by the serviceability team, Since I'm the only one on Serviceability right now, I went for a more general review. :-) David Holmes and Kelly O'Hair both reviewed and approved. Dan > you're free to push this into the OpenJDK 6 repo. The current build > number to use is b18. Thanks. It will be in the JPRT-HotSpotWest queue shortly... Dan > > Thanks, > > -Joe > > Daniel D. Daugherty wrote: >> Joe, >> >> These fixes are ready to be pushed in OpenJDK6. I've already >> done the pushed into HSX-16.1 and HSX-17 (RT_Baseline). >> >> Please let me know if I can push these... >> >> Dan >> >> >> -------- Original Message -------- >> Subject: code review round 0 for JVM/TI version fix (6849968) and >> phase assertion (6648438) >> Date: Fri, 11 Dec 2009 15:52:38 -0700 >> From: Daniel D. Daugherty >> Reply-To: Daniel.Daugherty at Sun.COM >> To: serviceability-dev at openjdk.java.net >> , >> serviceability-dev-confidential at sun.com >> >> >> >> Greetings, >> >> I have fixes for the following two JVM/TI bugs ready to go: >> >> 6648438 4/4 src/share/vm/prims/jvmtiEnv.cpp:457 >> assert(phase == JVMTI_PHASE_LIVE,"sanity check") >> 6849968 3/3 JVMTI tests fails on jdk5.0 with hs14 >> >> 6849968 fixes a problem where JVM/TI version 1.0 semantics >> were not being used when that version was explicitly >> requested. I fixed 6648438 because it happened to be in the >> same place that I already had to tweak for 6849968. It also >> gets rid of an annoying intermittent fastdebug failure. >> >> Here is the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/batch-20091211-webrev/0/ >> >> This webrev is relative to the OpenJDK6 version of the code. >> Once approved, these fixes will be pushed to: >> >> - OpenJDK6 (HSX-14-??) >> - JDK6-Update train (HSX-16-??) >> - OpenJDK7 (HSX-17-??) >> >> Comments, questions and suggestions are always welcome! >> >> Dan >> >> > From Daniel.Daugherty at Sun.COM Mon Dec 14 15:31:53 2009 From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty) Date: Mon, 14 Dec 2009 16:31:53 -0700 Subject: [Fwd: code review round 0 for JVM/TI version fix (6849968) and phase assertion (6648438)] In-Reply-To: <4B26C601.2020005@sun.com> References: <4B26BB3D.2000908@sun.com> <4B26C514.3000704@sun.com> <4B26C601.2020005@sun.com> Message-ID: <4B26CAE9.6090504@sun.com> I put the job in the JPRT-sfbay queue instead. There was a job in the JPRT-HotSpotWest queue already... :-) Dan Daniel D. Daugherty wrote: > Joseph D. Darcy wrote: >> Dan, >> >> Assuming this has been reviewed and approved by the serviceability team, > > Since I'm the only one on Serviceability right now, I > went for a more general review. :-) > > David Holmes and Kelly O'Hair both reviewed and approved. > > Dan > >> you're free to push this into the OpenJDK 6 repo. The current build >> number to use is b18. > > Thanks. It will be in the JPRT-HotSpotWest queue shortly... > > Dan > >> >> Thanks, >> >> -Joe >> >> Daniel D. Daugherty wrote: >>> Joe, >>> >>> These fixes are ready to be pushed in OpenJDK6. I've already >>> done the pushed into HSX-16.1 and HSX-17 (RT_Baseline). >>> >>> Please let me know if I can push these... >>> >>> Dan >>> >>> >>> -------- Original Message -------- >>> Subject: code review round 0 for JVM/TI version fix (6849968) >>> and phase assertion (6648438) >>> Date: Fri, 11 Dec 2009 15:52:38 -0700 >>> From: Daniel D. Daugherty >>> Reply-To: Daniel.Daugherty at Sun.COM >>> To: serviceability-dev at openjdk.java.net >>> , >>> serviceability-dev-confidential at sun.com >>> >>> >>> >>> Greetings, >>> >>> I have fixes for the following two JVM/TI bugs ready to go: >>> >>> 6648438 4/4 src/share/vm/prims/jvmtiEnv.cpp:457 >>> assert(phase == JVMTI_PHASE_LIVE,"sanity check") >>> 6849968 3/3 JVMTI tests fails on jdk5.0 with hs14 >>> >>> 6849968 fixes a problem where JVM/TI version 1.0 semantics >>> were not being used when that version was explicitly >>> requested. I fixed 6648438 because it happened to be in the >>> same place that I already had to tweak for 6849968. It also >>> gets rid of an annoying intermittent fastdebug failure. >>> >>> Here is the webrev URL: >>> >>> http://cr.openjdk.java.net/~dcubed/batch-20091211-webrev/0/ >>> >>> This webrev is relative to the OpenJDK6 version of the code. >>> Once approved, these fixes will be pushed to: >>> >>> - OpenJDK6 (HSX-14-??) >>> - JDK6-Update train (HSX-16-??) >>> - OpenJDK7 (HSX-17-??) >>> >>> Comments, questions and suggestions are always welcome! >>> >>> Dan >>> >>> >> From daniel.daugherty at sun.com Mon Dec 14 17:47:01 2009 From: daniel.daugherty at sun.com (daniel.daugherty at sun.com) Date: Tue, 15 Dec 2009 01:47:01 +0000 Subject: hg: jdk6/jdk6/hotspot: 3 new changesets Message-ID: <20091215014713.D57FE41FC1@hg.openjdk.java.net> Changeset: 9127aa69352e Author: dcubed Date: 2009-12-14 09:51 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/9127aa69352e 6648438: 4/4 src/share/vm/prims/jvmtiEnv.cpp:457 assert(phase == JVMTI_PHASE_LIVE,"sanity check") Summary: Return error on invalid JVMTI_PHASE instead of asserting. Reviewed-by: dholmes, ohair ! src/share/vm/prims/jvmtiEnv.cpp Changeset: 98cd9901c161 Author: dcubed Date: 2009-12-14 10:05 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/98cd9901c161 6849968: 3/2 JVMTI tests fails on jdk5.0 with hs14 Summary: If a JVMTI agent asks for version 1.0, then it should get version 1.0 semantics. Reviewed-by: dholmes, ohair ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiHpp.xsl Changeset: 14f7b2425c86 Author: dcubed Date: 2009-12-14 15:19 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/14f7b2425c86 Merge ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp From gnu_andrew at member.fsf.org Tue Dec 15 12:58:38 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 15 Dec 2009 20:58:38 +0000 Subject: Code review request for 4891262 "API spec, javax/accessibility: few invalid javadoc tags" In-Reply-To: <4B217892.3000006@sun.com> References: <4B20662F.6070805@sun.com> <17c6771e0912101307y36419d26lb6553131af02bb95@mail.gmail.com> <4B216A19.10909@sun.com> <17c6771e0912101358i6654222y636cc1a30fe95e66@mail.gmail.com> <4B217892.3000006@sun.com> Message-ID: <17c6771e0912151258vef342bbo388e23813493080f@mail.gmail.com> 2009/12/10 Joseph D. Darcy : > Andrew John Hughes wrote: >> >> 2009/12/10 Joseph D. Darcy : >> >>> >>> Andrew John Hughes wrote: >>> >>>> >>>> 2009/12/10 Joe Darcy : >>>> >>>> >>>>> >>>>> Hello. >>>>> >>>>> While doing a coredocs build, I noticed once again some javadoc >>>>> warnings >>>>> coming out of the javax.accessibility package and I decided to fix >>>>> them; >>>>> the >>>>> patch is below and the full webrev is at >>>>> >>>>> http://cr.openjdk.java.net/~darcy/4891262.0/ >>>>> >>>>> >>>>> >>>> >>>> Again, good to see these being fixed. ?What do you think to the idea >>>> of backporting these fixes to OpenJDK6 for the next release (b19)? >>>> It's not a major issue, but would improve the documentation packages >>>> being installed by GNU/Linux distros. >>>> >>>> >>> >>> Andrew, if you wish, you have my approval to apply the fix for 4891262 >>> (just >>> pushed into JDK 7 TL) and also >>> >>> 6909070 "Missing package statements in java.text.Bidi @see links" >>> >>> to OpenJDK 6 build 18, the current build. >>> >>> -Joe >>> >>> >> >> Thanks. ?I'll do that once I get the current timezone patch off my >> stack. ?I suggest we leave a full blitz of such warnings until b19 >> though, otherwise b18 has the potential to go on for ever :) >> > > Build 19 would be fine too, but at least for now there will be at most one > or two more doc warnings patches from me in the near future :-) > > -Joe > Moving discussion to jdk6-dev as it concerns OpenJDK6 primarily. My hesitation was because I didn't think the baseline was as good for OpenJDK6 as OpenJDK7 because a number of earlier patches were never backported. I did a build and that is the case; there are a lot of javadoc warnings that are fixed in 7 and thus there are changesets to backport. The first fix is 6810915: Sun proprietary warnings in JDK build Reviewed-by: ohair http://cr.openjdk.java.net/~andrew/6810915/webrev.01/ which cuts down significantly on the 1789 warnings currently produced by turning off the 'warning: sun.a\ wt.SunHints is Sun proprietary API and may be removed in a future release; style warnings. Ok to push? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Joe.Darcy at Sun.COM Tue Dec 15 13:03:44 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Tue, 15 Dec 2009 13:03:44 -0800 Subject: Code review request for 4891262 "API spec, javax/accessibility: few invalid javadoc tags" In-Reply-To: <17c6771e0912151258vef342bbo388e23813493080f@mail.gmail.com> References: <4B20662F.6070805@sun.com> <17c6771e0912101307y36419d26lb6553131af02bb95@mail.gmail.com> <4B216A19.10909@sun.com> <17c6771e0912101358i6654222y636cc1a30fe95e66@mail.gmail.com> <4B217892.3000006@sun.com> <17c6771e0912151258vef342bbo388e23813493080f@mail.gmail.com> Message-ID: <4B27F9B0.2050204@sun.com> Andrew John Hughes wrote: > 2009/12/10 Joseph D. Darcy : > >> Andrew John Hughes wrote: >> >>> 2009/12/10 Joseph D. Darcy : >>> >>> >>>> Andrew John Hughes wrote: >>>> >>>> >>>>> 2009/12/10 Joe Darcy : >>>>> >>>>> >>>>> >>>>>> Hello. >>>>>> >>>>>> While doing a coredocs build, I noticed once again some javadoc >>>>>> warnings >>>>>> coming out of the javax.accessibility package and I decided to fix >>>>>> them; >>>>>> the >>>>>> patch is below and the full webrev is at >>>>>> >>>>>> http://cr.openjdk.java.net/~darcy/4891262.0/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Again, good to see these being fixed. What do you think to the idea >>>>> of backporting these fixes to OpenJDK6 for the next release (b19)? >>>>> It's not a major issue, but would improve the documentation packages >>>>> being installed by GNU/Linux distros. >>>>> >>>>> >>>>> >>>> Andrew, if you wish, you have my approval to apply the fix for 4891262 >>>> (just >>>> pushed into JDK 7 TL) and also >>>> >>>> 6909070 "Missing package statements in java.text.Bidi @see links" >>>> >>>> to OpenJDK 6 build 18, the current build. >>>> >>>> -Joe >>>> >>>> >>>> >>> Thanks. I'll do that once I get the current timezone patch off my >>> stack. I suggest we leave a full blitz of such warnings until b19 >>> though, otherwise b18 has the potential to go on for ever :) >>> >>> >> Build 19 would be fine too, but at least for now there will be at most one >> or two more doc warnings patches from me in the near future :-) >> >> -Joe >> >> > > Moving discussion to jdk6-dev as it concerns OpenJDK6 primarily. > > My hesitation was because I didn't think the baseline was as good for > OpenJDK6 as OpenJDK7 because a number of earlier patches were never > backported. > > I did a build and that is the case; there are a lot of javadoc > warnings that are fixed in 7 and thus there are changesets to > backport. > > The first fix is > > 6810915: Sun proprietary warnings in JDK build > Reviewed-by: ohair > http://cr.openjdk.java.net/~andrew/6810915/webrev.01/ > > which cuts down significantly on the 1789 warnings currently produced > by turning off the 'warning: sun.a\ > wt.SunHints is Sun proprietary API and may be removed in a future > release; style warnings. > > Ok to push? > Yes; approved to go back. -Joe From ahughes at redhat.com Tue Dec 15 13:31:31 2009 From: ahughes at redhat.com (ahughes at redhat.com) Date: Tue, 15 Dec 2009 21:31:31 +0000 Subject: hg: jdk6/jdk6/jdk: 6810915: Sun proprietary warnings in JDK build Message-ID: <20091215213144.A20B2420FF@hg.openjdk.java.net> Changeset: 08bb2ce6b1ab Author: jjg Date: 2009-02-26 18:51 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/08bb2ce6b1ab 6810915: Sun proprietary warnings in JDK build Reviewed-by: ohair ! make/common/shared/Defs-java.gmk ! make/docs/Makefile ! make/javax/swing/beaninfo/SwingBeans.gmk From Erik.Trimble at Sun.COM Tue Dec 15 16:56:02 2009 From: Erik.Trimble at Sun.COM (Erik Trimble) Date: Tue, 15 Dec 2009 16:56:02 -0800 Subject: It's probably OK to pull HS16 into OpenJDK 6 now... Message-ID: <1260924962.25256.4.camel@ghostbox.sfbay.sun.com> Naturally, it's up to you folks, but we (Sun) seems to be finished with Hotspot 16, so it can be pulled into OpenJDK6 anytime now. Really. I mean it. This time, for sure. ;-) As for Vladimir's patch to disable Escape Analysis: I'd recommend pulling the changeset over, for consistency's sake. It's a real simple fix to re-enable it, if that's what people want. I'll try to re-tag everything in HS16 with the build numbers no later than the end of the week. -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) From Kelly.Ohair at Sun.COM Tue Dec 15 17:42:40 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 15 Dec 2009 17:42:40 -0800 Subject: Testing your jdk builds, both jdk7/tl/jdk and jdk6/jdk6/jdk Message-ID: <4B283B10.9000008@sun.com> The jdk/test/Makefile should be in both jdk7/tl and jdk6/jdk6 repositories now. The jtreg tool is needed, so to download and install the latest jtreg tool do the following: wget http://www.java.net/download/openjdk/jtreg/promoted/b03/jtreg-4_0-bin-b03-31_mar_2009.zip unzip jtreg-4_0-bin-b03-31_mar_2009.zip export JT_HOME=`pwd`/jtreg Build your jdk image, e.g. cd jdk/make && gnumake all images Then run all the stable jdk tests: cd jdk/test && gnumake -k jdk_all If you have a 2 CPU machine and are feeling brave, try: cd jdk/test && gnumake -k -j 4 jdk_all If you do try this out, please let me know how it went. I'm still refining what tests are considered "stable" and I haven't completed my testing of Windows&CYGWIN, so I know the set of tests run will be changing a little. -kto From Joe.Darcy at Sun.COM Tue Dec 15 20:19:03 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Tue, 15 Dec 2009 20:19:03 -0800 Subject: It's probably OK to pull HS16 into OpenJDK 6 now... In-Reply-To: <1260924962.25256.4.camel@ghostbox.sfbay.sun.com> References: <1260924962.25256.4.camel@ghostbox.sfbay.sun.com> Message-ID: <4B285FB7.5030304@sun.com> Erik Trimble wrote: > Naturally, it's up to you folks, but we (Sun) seems to be finished with > Hotspot 16, so it can be pulled into OpenJDK6 anytime now. > > Really. I mean it. This time, for sure. > > ;-) > > > As for Vladimir's patch to disable Escape Analysis: I'd recommend > pulling the changeset over, for consistency's sake. It's a real simple > fix to re-enable it, if that's what people want. > > > I'll try to re-tag everything in HS16 with the build numbers no later > than the end of the week. > Hi Eric. Thanks for the heads up. For OpenJDK 6, I think we should finish up the current build, b18, and then HS16 could be brought over early in b19. -Joe From ml at logemann.org Wed Dec 16 04:37:48 2009 From: ml at logemann.org (Marc Logemann) Date: Wed, 16 Dec 2009 13:37:48 +0100 Subject: "collated" printing with OpenJDK on Linux/CUPS Message-ID: Hi, recently we ported our product to linux and used OpenJDK for our tests. We encountered a strange problem with printing document with multiple copies. When printing a document with 2 pages and 2 copies (A and B), we get A1, B1, A2, B2. So, we get a uncollated order. On Windows with SUN JDK, it was enough to write: printRequestAttributeSet.add(SheetCollate.COLLATED); now with OpenJDK on Linux/CUPS we also placed: printRequestAttributeSet.add(MultipleDocumentHandling.SEPARATE_DOCUMENTS_COLLATED_COPIES); to our print job without any difference. It just stays uncollated. Does anyone have an idea whats going on there? if there is a different subproject maillist for this kind of topic, please tell me. I ve not found anything. thx --- regards Marc Logemann http://www.logemann.org http://www.logentis.de From ptisnovs at redhat.com Thu Dec 17 15:02:49 2009 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Fri, 18 Dec 2009 00:02:49 +0100 Subject: Regression test java/util/jar/JarFile/TurkCert.java incorrectly changes Locale settings Message-ID: <4B2AB899.8050606@redhat.com> Hi, the first statement (Locale.setDefault(new Locale("TR", "tr"));) in regression test java/util/jar/JarFile/TurkCert.java changes locale settings on global level (i.e. in currently running JTreg/JVM) which causes that other test fails, for example sun/java2d/cmm/ColorConvertOp/ConstructorsNullTest/ConstructorsNullTest I'm able to do patch for this test. Should I post webrev here or to another OpenJDK mailing list? regards Pavel Tisnovsky From Alan.Bateman at Sun.COM Thu Dec 17 15:14:23 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Thu, 17 Dec 2009 23:14:23 +0000 Subject: Regression test java/util/jar/JarFile/TurkCert.java incorrectly changes Locale settings In-Reply-To: <4B2AB899.8050606@redhat.com> References: <4B2AB899.8050606@redhat.com> Message-ID: <4B2ABB4F.7030508@sun.com> Pavel Tisnovsky wrote: > Hi, > > the first statement (Locale.setDefault(new Locale("TR", "tr"));) in > regression test > java/util/jar/JarFile/TurkCert.java > > changes locale settings on global level (i.e. in currently running > JTreg/JVM) which causes that other test fails, for example > sun/java2d/cmm/ColorConvertOp/ConstructorsNullTest/ConstructorsNullTest > > I'm able to do patch for this test. Should I post webrev here or to > another OpenJDK mailing list? > > regards > Pavel Tisnovsky core-libs-dev is probably the best place. It's only recently that we've been running these tests in samevm mode and this is one that should probably run in othervm mode. -Alan. From Jonathan.Gibbons at Sun.COM Thu Dec 17 15:22:01 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Thu, 17 Dec 2009 15:22:01 -0800 Subject: Regression test java/util/jar/JarFile/TurkCert.java incorrectly changes Locale settings In-Reply-To: <4B2ABB4F.7030508@sun.com> References: <4B2AB899.8050606@redhat.com> <4B2ABB4F.7030508@sun.com> Message-ID: <4B2ABD19.2030502@sun.com> Alan Bateman wrote: > Pavel Tisnovsky wrote: >> Hi, >> >> the first statement (Locale.setDefault(new Locale("TR", "tr"));) in >> regression test >> java/util/jar/JarFile/TurkCert.java >> >> changes locale settings on global level (i.e. in currently running >> JTreg/JVM) which causes that other test fails, for example >> sun/java2d/cmm/ColorConvertOp/ConstructorsNullTest/ConstructorsNullTest >> >> I'm able to do patch for this test. Should I post webrev here or to >> another OpenJDK mailing list? >> >> regards >> Pavel Tisnovsky > core-libs-dev is probably the best place. It's only recently that > we've been running these tests in samevm mode and this is one that > should probably run in othervm mode. > > -Alan. Alan, An alternative solution is to remember the locale before changing it and resetting it when done. -- Jon From Jonathan.Gibbons at Sun.COM Thu Dec 17 15:22:47 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Thu, 17 Dec 2009 15:22:47 -0800 Subject: Regression test java/util/jar/JarFile/TurkCert.java incorrectly changes Locale settings In-Reply-To: <4B2ABB4F.7030508@sun.com> References: <4B2AB899.8050606@redhat.com> <4B2ABB4F.7030508@sun.com> Message-ID: <4B2ABD47.6010008@sun.com> Alan Bateman wrote: > Pavel Tisnovsky wrote: >> Hi, >> >> the first statement (Locale.setDefault(new Locale("TR", "tr"));) in >> regression test >> java/util/jar/JarFile/TurkCert.java >> >> changes locale settings on global level (i.e. in currently running >> JTreg/JVM) which causes that other test fails, for example >> sun/java2d/cmm/ColorConvertOp/ConstructorsNullTest/ConstructorsNullTest >> >> I'm able to do patch for this test. Should I post webrev here or to >> another OpenJDK mailing list? >> >> regards >> Pavel Tisnovsky > core-libs-dev is probably the best place. It's only recently that > we've been running these tests in samevm mode and this is one that > should probably run in othervm mode. > > -Alan. Pavel, You could also file a bug against jtreg that it should try and guard against this in samevm mode. -- Jon From ptisnovs at redhat.com Thu Dec 17 15:40:04 2009 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Fri, 18 Dec 2009 00:40:04 +0100 Subject: Regression test java/util/jar/JarFile/TurkCert.java incorrectly changes Locale settings In-Reply-To: <4B2ABD47.6010008@sun.com> References: <4B2AB899.8050606@redhat.com> <4B2ABB4F.7030508@sun.com> <4B2ABD47.6010008@sun.com> Message-ID: <4B2AC154.3010008@redhat.com> Hi Jon, ok, I'll do both actions - patch the test (either to restore locale or add /othervm tag) and file a bug. Thanks Pavel Jonathan Gibbons wrote: > Pavel, > > You could also file a bug against jtreg that it should try and guard > against this in samevm mode. > > -- Jon From Daniel.Daugherty at Sun.COM Thu Dec 17 15:46:57 2009 From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty) Date: Thu, 17 Dec 2009 16:46:57 -0700 Subject: Regression test java/util/jar/JarFile/TurkCert.java incorrectly changes Locale settings In-Reply-To: <4B2ABD19.2030502@sun.com> References: <4B2AB899.8050606@redhat.com> <4B2ABB4F.7030508@sun.com> <4B2ABD19.2030502@sun.com> Message-ID: <4B2AC2F1.9020100@sun.com> Jonathan Gibbons wrote: > Alan Bateman wrote: >> Pavel Tisnovsky wrote: >>> Hi, >>> >>> the first statement (Locale.setDefault(new Locale("TR", "tr"));) in >>> regression test >>> java/util/jar/JarFile/TurkCert.java >>> >>> changes locale settings on global level (i.e. in currently running >>> JTreg/JVM) which causes that other test fails, for example >>> sun/java2d/cmm/ColorConvertOp/ConstructorsNullTest/ConstructorsNullTest >>> >>> I'm able to do patch for this test. Should I post webrev here or to >>> another OpenJDK mailing list? >>> >>> regards >>> Pavel Tisnovsky >> core-libs-dev is probably the best place. It's only recently that >> we've been running these tests in samevm mode and this is one that >> should probably run in othervm mode. >> >> -Alan. > Alan, > > An alternative solution is to remember the locale before changing it > and resetting it when done. > > -- Jon Does that work when executing tests in parallel? Dan From Jonathan.Gibbons at Sun.COM Thu Dec 17 16:36:03 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Thu, 17 Dec 2009 16:36:03 -0800 Subject: Regression test java/util/jar/JarFile/TurkCert.java incorrectly changes Locale settings In-Reply-To: <4B2AC2F1.9020100@sun.com> References: <4B2AB899.8050606@redhat.com> <4B2ABB4F.7030508@sun.com> <4B2ABD19.2030502@sun.com> <4B2AC2F1.9020100@sun.com> Message-ID: <4B2ACE73.7020706@sun.com> Daniel D. Daugherty wrote: > > > Jonathan Gibbons wrote: >> Alan Bateman wrote: >>> Pavel Tisnovsky wrote: >>>> Hi, >>>> >>>> the first statement (Locale.setDefault(new Locale("TR", "tr"));) in >>>> regression test >>>> java/util/jar/JarFile/TurkCert.java >>>> >>>> changes locale settings on global level (i.e. in currently running >>>> JTreg/JVM) which causes that other test fails, for example >>>> sun/java2d/cmm/ColorConvertOp/ConstructorsNullTest/ConstructorsNullTest >>>> >>>> >>>> I'm able to do patch for this test. Should I post webrev here or to >>>> another OpenJDK mailing list? >>>> >>>> regards >>>> Pavel Tisnovsky >>> core-libs-dev is probably the best place. It's only recently that >>> we've been running these tests in samevm mode and this is one that >>> should probably run in othervm mode. >>> >>> -Alan. >> Alan, >> >> An alternative solution is to remember the locale before changing it >> and resetting it when done. >> >> -- Jon > > Does that work when executing tests in parallel? > > Dan > jtreg does not support running tests in parallel for exactly this sort of reason -- certainly not in samevm mode, where stdout/stderr are already multiplexed between tests. -- Jon From Kelly.Ohair at Sun.COM Thu Dec 17 16:59:22 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Thu, 17 Dec 2009 16:59:22 -0800 Subject: Regression test java/util/jar/JarFile/TurkCert.java incorrectly changes Locale settings In-Reply-To: <4B2ACE73.7020706@sun.com> References: <4B2AB899.8050606@redhat.com> <4B2ABB4F.7030508@sun.com> <4B2ABD19.2030502@sun.com> <4B2AC2F1.9020100@sun.com> <4B2ACE73.7020706@sun.com> Message-ID: <4B2AD3EA.5040407@sun.com> Jonathan Gibbons wrote: > Daniel D. Daugherty wrote: >> >> >> Jonathan Gibbons wrote: >>> Alan Bateman wrote: >>>> Pavel Tisnovsky wrote: >>>>> Hi, >>>>> >>>>> the first statement (Locale.setDefault(new Locale("TR", "tr"));) in >>>>> regression test >>>>> java/util/jar/JarFile/TurkCert.java >>>>> >>>>> changes locale settings on global level (i.e. in currently running >>>>> JTreg/JVM) which causes that other test fails, for example >>>>> sun/java2d/cmm/ColorConvertOp/ConstructorsNullTest/ConstructorsNullTest >>>>> >>>>> >>>>> I'm able to do patch for this test. Should I post webrev here or to >>>>> another OpenJDK mailing list? >>>>> >>>>> regards >>>>> Pavel Tisnovsky >>>> core-libs-dev is probably the best place. It's only recently that >>>> we've been running these tests in samevm mode and this is one that >>>> should probably run in othervm mode. >>>> >>>> -Alan. >>> Alan, >>> >>> An alternative solution is to remember the locale before changing it >>> and resetting it when done. >>> >>> -- Jon >> >> Does that work when executing tests in parallel? >> >> Dan >> > jtreg does not support running tests in parallel for exactly this sort > of reason -- certainly not in samevm mode, where stdout/stderr are > already multiplexed between tests. > > -- Jon But will changing the locale impact the samevm testing? Should any testcase that sets the locale be othervm? I assume that if completely separate jtreg processes are running at the same time that this locale setting has no impact. It's not a system wide locale change is it? -kto From Daniel.Daugherty at Sun.COM Thu Dec 17 17:00:32 2009 From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty) Date: Thu, 17 Dec 2009 18:00:32 -0700 Subject: Regression test java/util/jar/JarFile/TurkCert.java incorrectly changes Locale settings In-Reply-To: <4B2ACE73.7020706@sun.com> References: <4B2AB899.8050606@redhat.com> <4B2ABB4F.7030508@sun.com> <4B2ABD19.2030502@sun.com> <4B2AC2F1.9020100@sun.com> <4B2ACE73.7020706@sun.com> Message-ID: <4B2AD430.4010507@sun.com> >> Does that work when executing tests in parallel? >> >> Dan >> > jtreg does not support running tests in parallel for exactly this sort > of reason -- certainly not in samevm mode, where stdout/stderr are > already multiplexed between tests. OK. So in Kelly's recent postings about running tests in parallel, he's referring to "othervm" tests... Do I have this right? Dan From Kelly.Ohair at Sun.COM Thu Dec 17 17:05:29 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Thu, 17 Dec 2009 17:05:29 -0800 Subject: Regression test java/util/jar/JarFile/TurkCert.java incorrectly changes Locale settings In-Reply-To: <4B2AD430.4010507@sun.com> References: <4B2AB899.8050606@redhat.com> <4B2ABB4F.7030508@sun.com> <4B2ABD19.2030502@sun.com> <4B2AC2F1.9020100@sun.com> <4B2ACE73.7020706@sun.com> <4B2AD430.4010507@sun.com> Message-ID: <4B2AD559.3060606@sun.com> Daniel D. Daugherty wrote: > >>> Does that work when executing tests in parallel? >>> >>> Dan >>> >> jtreg does not support running tests in parallel for exactly this sort >> of reason -- certainly not in samevm mode, where stdout/stderr are >> already multiplexed between tests. > > OK. So in Kelly's recent postings about running tests in > parallel, he's referring to "othervm" tests... Do I have > this right? > The othervm and samevm is a mode for jtreg, nothing parallel, just the way the vm is used. It's using 'gnumake -j 4' that does the parallel runs of jtreg, each jtreg is a separate process, using different output directories. If the testcases themselves don't allow for this, then you can't use 'gnumake -j 4', but those same testcases are probably the ones that cannot be run by two people on the same system because they want to use some fixed port or some baked in file path. -kto > Dan > From Jonathan.Gibbons at Sun.COM Thu Dec 17 17:38:40 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Thu, 17 Dec 2009 17:38:40 -0800 Subject: Regression test java/util/jar/JarFile/TurkCert.java incorrectly changes Locale settings In-Reply-To: <4B2AD430.4010507@sun.com> References: <4B2AB899.8050606@redhat.com> <4B2ABB4F.7030508@sun.com> <4B2ABD19.2030502@sun.com> <4B2AC2F1.9020100@sun.com> <4B2ACE73.7020706@sun.com> <4B2AD430.4010507@sun.com> Message-ID: <4B2ADD20.4000807@sun.com> Daniel D. Daugherty wrote: > >>> Does that work when executing tests in parallel? >>> >>> Dan >>> >> jtreg does not support running tests in parallel for exactly this >> sort of reason -- certainly not in samevm mode, where stdout/stderr >> are already multiplexed between tests. > > OK. So in Kelly's recent postings about running tests in > parallel, he's referring to "othervm" tests... Do I have > this right? > > Dan > Kelly was talking about separate processes running separate copies of jtreg for disjoint segments of the test suite. That is safe, and can use samevm/othervm as long as the tests themselves don't interfere with each other on shared system-wide resources such as port numbers. For my part, I was talking about the basic JavaTest facility to run tests concurrently using multiple threads in the same JavaTest VM (using either the -concurrency command line option or the "concurrency:" field in the GUI). That works for JCK, subject to the inherent test-interference rule -- for example it works for JCK compiler tests. jtreg does not support this level of concurrency. Sorry for the confusion. -- Jon From gnu_andrew at member.fsf.org Mon Dec 21 09:53:42 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 21 Dec 2009 17:53:42 +0000 Subject: Code review request for 4891262 "API spec, javax/accessibility: few invalid javadoc tags" In-Reply-To: <4B27F9B0.2050204@sun.com> References: <4B20662F.6070805@sun.com> <17c6771e0912101307y36419d26lb6553131af02bb95@mail.gmail.com> <4B216A19.10909@sun.com> <17c6771e0912101358i6654222y636cc1a30fe95e66@mail.gmail.com> <4B217892.3000006@sun.com> <17c6771e0912151258vef342bbo388e23813493080f@mail.gmail.com> <4B27F9B0.2050204@sun.com> Message-ID: <17c6771e0912210953i66a30e46nc958ed99165769d6@mail.gmail.com> 2009/12/15 Joseph D. Darcy : > Andrew John Hughes wrote: >> >> 2009/12/10 Joseph D. Darcy : >> >>> >>> Andrew John Hughes wrote: >>> >>>> >>>> 2009/12/10 Joseph D. Darcy : >>>> >>>> >>>>> >>>>> Andrew John Hughes wrote: >>>>> >>>>> >>>>>> >>>>>> 2009/12/10 Joe Darcy : >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Hello. >>>>>>> >>>>>>> While doing a coredocs build, I noticed once again some javadoc >>>>>>> warnings >>>>>>> coming out of the javax.accessibility package and I decided to fix >>>>>>> them; >>>>>>> the >>>>>>> patch is below and the full webrev is at >>>>>>> >>>>>>> http://cr.openjdk.java.net/~darcy/4891262.0/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> Again, good to see these being fixed. ?What do you think to the idea >>>>>> of backporting these fixes to OpenJDK6 for the next release (b19)? >>>>>> It's not a major issue, but would improve the documentation packages >>>>>> being installed by GNU/Linux distros. >>>>>> >>>>>> >>>>>> >>>>> >>>>> Andrew, if you wish, you have my approval to apply the fix for 4891262 >>>>> (just >>>>> pushed into JDK 7 TL) and also >>>>> >>>>> 6909070 "Missing package statements in java.text.Bidi @see links" >>>>> >>>>> to OpenJDK 6 build 18, the current build. >>>>> >>>>> -Joe >>>>> >>>>> >>>>> >>>> >>>> Thanks. ?I'll do that once I get the current timezone patch off my >>>> stack. ?I suggest we leave a full blitz of such warnings until b19 >>>> though, otherwise b18 has the potential to go on for ever :) >>>> >>>> >>> >>> Build 19 would be fine too, but at least for now there will be at most >>> one >>> or two more doc warnings patches from me in the near future :-) >>> >>> -Joe >>> >>> >> >> Moving discussion to jdk6-dev as it concerns OpenJDK6 primarily. >> >> My hesitation was because I didn't think the baseline was as good for >> OpenJDK6 as OpenJDK7 because a number of earlier patches were never >> backported. >> >> I did a build and that is the case; there are a lot of javadoc >> warnings that are fixed in 7 and thus there are changesets to >> backport. >> >> The first fix is >> >> 6810915: Sun proprietary warnings in JDK build >> Reviewed-by: ohair >> http://cr.openjdk.java.net/~andrew/6810915/webrev.01/ >> >> which cuts down significantly on the 1789 warnings currently produced >> by turning off the 'warning: sun.a\ >> wt.SunHints is Sun proprietary API and may be removed in a future >> release; style warnings. >> >> Ok to push? >> > > Yes; approved to go back. > > -Joe > Two more: changeset: 1624:f1eb4c28b313 user: lancea date: Wed Sep 09 20:15:22 2009 -0400 summary: 6737212: Fixed javadoc warning messages in RowSet classes http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f1eb4c28b313 changeset: 1969:3267ca7afe95 user: darcy date: Fri Dec 11 10:40:14 2009 -0800 summary: 6909563: Javadoc build warnings in rmi, security, management http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3267ca7afe95 Ok to go back? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Joe.Darcy at Sun.COM Mon Dec 21 10:01:23 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Mon, 21 Dec 2009 10:01:23 -0800 Subject: Code review request for 4891262 "API spec, javax/accessibility: few invalid javadoc tags" In-Reply-To: <17c6771e0912210953i66a30e46nc958ed99165769d6@mail.gmail.com> References: <4B20662F.6070805@sun.com> <17c6771e0912101307y36419d26lb6553131af02bb95@mail.gmail.com> <4B216A19.10909@sun.com> <17c6771e0912101358i6654222y636cc1a30fe95e66@mail.gmail.com> <4B217892.3000006@sun.com> <17c6771e0912151258vef342bbo388e23813493080f@mail.gmail.com> <4B27F9B0.2050204@sun.com> <17c6771e0912210953i66a30e46nc958ed99165769d6@mail.gmail.com> Message-ID: <4B2FB7F3.4090508@sun.com> Andrew John Hughes wrote: > 2009/12/15 Joseph D. Darcy : > >> Andrew John Hughes wrote: >> >>> 2009/12/10 Joseph D. Darcy : >>> >>> >>>> Andrew John Hughes wrote: >>>> >>>> >>>>> 2009/12/10 Joseph D. Darcy : >>>>> >>>>> >>>>> >>>>>> Andrew John Hughes wrote: >>>>>> >>>>>> >>>>>> >>>>>>> 2009/12/10 Joe Darcy : >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hello. >>>>>>>> >>>>>>>> While doing a coredocs build, I noticed once again some javadoc >>>>>>>> warnings >>>>>>>> coming out of the javax.accessibility package and I decided to fix >>>>>>>> them; >>>>>>>> the >>>>>>>> patch is below and the full webrev is at >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~darcy/4891262.0/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Again, good to see these being fixed. What do you think to the idea >>>>>>> of backporting these fixes to OpenJDK6 for the next release (b19)? >>>>>>> It's not a major issue, but would improve the documentation packages >>>>>>> being installed by GNU/Linux distros. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Andrew, if you wish, you have my approval to apply the fix for 4891262 >>>>>> (just >>>>>> pushed into JDK 7 TL) and also >>>>>> >>>>>> 6909070 "Missing package statements in java.text.Bidi @see links" >>>>>> >>>>>> to OpenJDK 6 build 18, the current build. >>>>>> >>>>>> -Joe >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Thanks. I'll do that once I get the current timezone patch off my >>>>> stack. I suggest we leave a full blitz of such warnings until b19 >>>>> though, otherwise b18 has the potential to go on for ever :) >>>>> >>>>> >>>>> >>>> Build 19 would be fine too, but at least for now there will be at most >>>> one >>>> or two more doc warnings patches from me in the near future :-) >>>> >>>> -Joe >>>> >>>> >>>> >>> Moving discussion to jdk6-dev as it concerns OpenJDK6 primarily. >>> >>> My hesitation was because I didn't think the baseline was as good for >>> OpenJDK6 as OpenJDK7 because a number of earlier patches were never >>> backported. >>> >>> I did a build and that is the case; there are a lot of javadoc >>> warnings that are fixed in 7 and thus there are changesets to >>> backport. >>> >>> The first fix is >>> >>> 6810915: Sun proprietary warnings in JDK build >>> Reviewed-by: ohair >>> http://cr.openjdk.java.net/~andrew/6810915/webrev.01/ >>> >>> which cuts down significantly on the 1789 warnings currently produced >>> by turning off the 'warning: sun.a\ >>> wt.SunHints is Sun proprietary API and may be removed in a future >>> release; style warnings. >>> >>> Ok to push? >>> >>> >> Yes; approved to go back. >> >> -Joe >> >> > > Two more: > > changeset: 1624:f1eb4c28b313 > user: lancea > date: Wed Sep 09 20:15:22 2009 -0400 > summary: 6737212: Fixed javadoc warning messages in RowSet classes > http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f1eb4c28b313 > Approved to be pushed. > changeset: 1969:3267ca7afe95 > user: darcy > date: Fri Dec 11 10:40:14 2009 -0800 > summary: 6909563: Javadoc build warnings in rmi, security, management > http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3267ca7afe95 > > Ok to go back? > I also approve this one going back with the condition that any unneeded changes to JDK 7-only files are removed. Cheers, -Joe From ahughes at redhat.com Mon Dec 21 10:18:14 2009 From: ahughes at redhat.com (ahughes at redhat.com) Date: Mon, 21 Dec 2009 18:18:14 +0000 Subject: hg: jdk6/jdk6/jdk: 2 new changesets Message-ID: <20091221181831.6ADBE42A4B@hg.openjdk.java.net> Changeset: e321afbdc366 Author: lancea Date: 2009-09-09 20:15 -0400 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/e321afbdc366 6737212: Fixed javadoc warning messages in RowSet classes Reviewed-by: darcy ! src/share/classes/com/sun/rowset/JdbcRowSetResourceBundle.java ! src/share/classes/com/sun/rowset/JoinRowSetImpl.java ! src/share/classes/com/sun/rowset/internal/WebRowSetXmlReader.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java Changeset: 88557649e47f Author: darcy Date: 2009-12-21 18:16 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/88557649e47f 6909563: Javadoc build warnings in rmi, security, management Reviewed-by: mchung, mullan ! src/share/classes/java/rmi/activation/Activatable.java ! src/share/classes/java/rmi/registry/LocateRegistry.java ! src/share/classes/java/rmi/server/RemoteObjectInvocationHandler.java From gnu_andrew at member.fsf.org Mon Dec 21 11:02:58 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 21 Dec 2009 19:02:58 +0000 Subject: Code review request for 4891262 "API spec, javax/accessibility: few invalid javadoc tags" In-Reply-To: <4B2FB7F3.4090508@sun.com> References: <4B20662F.6070805@sun.com> <17c6771e0912101307y36419d26lb6553131af02bb95@mail.gmail.com> <4B216A19.10909@sun.com> <17c6771e0912101358i6654222y636cc1a30fe95e66@mail.gmail.com> <4B217892.3000006@sun.com> <17c6771e0912151258vef342bbo388e23813493080f@mail.gmail.com> <4B27F9B0.2050204@sun.com> <17c6771e0912210953i66a30e46nc958ed99165769d6@mail.gmail.com> <4B2FB7F3.4090508@sun.com> Message-ID: <17c6771e0912211102x6147b025r1f384da0128bf2cb@mail.gmail.com> 2009/12/21 Joseph D. Darcy : > Andrew John Hughes wrote: >> >> 2009/12/15 Joseph D. Darcy : >> >>> >>> Andrew John Hughes wrote: >>> >>>> >>>> 2009/12/10 Joseph D. Darcy : >>>> >>>> >>>>> >>>>> Andrew John Hughes wrote: >>>>> >>>>> >>>>>> >>>>>> 2009/12/10 Joseph D. Darcy : >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Andrew John Hughes wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> 2009/12/10 Joe Darcy : >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Hello. >>>>>>>>> >>>>>>>>> While doing a coredocs build, I noticed once again some javadoc >>>>>>>>> warnings >>>>>>>>> coming out of the javax.accessibility package and I decided to fix >>>>>>>>> them; >>>>>>>>> the >>>>>>>>> patch is below and the full webrev is at >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~darcy/4891262.0/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Again, good to see these being fixed. ?What do you think to the idea >>>>>>>> of backporting these fixes to OpenJDK6 for the next release (b19)? >>>>>>>> It's not a major issue, but would improve the documentation packages >>>>>>>> being installed by GNU/Linux distros. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Andrew, if you wish, you have my approval to apply the fix for >>>>>>> 4891262 >>>>>>> (just >>>>>>> pushed into JDK 7 TL) and also >>>>>>> >>>>>>> 6909070 "Missing package statements in java.text.Bidi @see links" >>>>>>> >>>>>>> to OpenJDK 6 build 18, the current build. >>>>>>> >>>>>>> -Joe >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> Thanks. ?I'll do that once I get the current timezone patch off my >>>>>> stack. ?I suggest we leave a full blitz of such warnings until b19 >>>>>> though, otherwise b18 has the potential to go on for ever :) >>>>>> >>>>>> >>>>>> >>>>> >>>>> Build 19 would be fine too, but at least for now there will be at most >>>>> one >>>>> or two more doc warnings patches from me in the near future :-) >>>>> >>>>> -Joe >>>>> >>>>> >>>>> >>>> >>>> Moving discussion to jdk6-dev as it concerns OpenJDK6 primarily. >>>> >>>> My hesitation was because I didn't think the baseline was as good for >>>> OpenJDK6 as OpenJDK7 because a number of earlier patches were never >>>> backported. >>>> >>>> I did a build and that is the case; there are a lot of javadoc >>>> warnings that are fixed in 7 and thus there are changesets to >>>> backport. >>>> >>>> The first fix is >>>> >>>> 6810915: Sun proprietary warnings in JDK build >>>> Reviewed-by: ohair >>>> http://cr.openjdk.java.net/~andrew/6810915/webrev.01/ >>>> >>>> which cuts down significantly on the 1789 warnings currently produced >>>> by turning off the 'warning: sun.a\ >>>> wt.SunHints is Sun proprietary API and may be removed in a future >>>> release; style warnings. >>>> >>>> Ok to push? >>>> >>>> >>> >>> Yes; approved to go back. >>> >>> -Joe >>> >>> >> >> Two more: >> >> changeset: ? 1624:f1eb4c28b313 >> user: ? ? ? ?lancea >> date: ? ? ? ?Wed Sep 09 20:15:22 2009 -0400 >> summary: ? ? 6737212: Fixed javadoc warning messages in RowSet classes >> http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f1eb4c28b313 >> > > Approved to be pushed. > >> changeset: ? 1969:3267ca7afe95 >> user: ? ? ? ?darcy >> date: ? ? ? ?Fri Dec 11 10:40:14 2009 -0800 >> summary: ? ? 6909563: Javadoc build warnings in rmi, security, management >> http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3267ca7afe95 >> >> Ok to go back? >> > > I also approve this one going back with the condition that any unneeded > changes to JDK 7-only files are removed. > > Cheers, > > -Joe > > Both done. The changes that were to JDK7-only classes simply didn't apply. Next one: changeset: 1572:196c7bb551e7 user: darcy date: Tue Aug 25 18:58:26 2009 -0700 summary: 6875861: javadoc build warning on java.util.Properites from unconventional @see ordering http://hg.openjdk.java.net/jdk7/tl/jdk/rev/196c7bb551e7 -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Joe.Darcy at Sun.COM Mon Dec 21 17:37:56 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Mon, 21 Dec 2009 17:37:56 -0800 Subject: Code review request for 4891262 "API spec, javax/accessibility: few invalid javadoc tags" In-Reply-To: <17c6771e0912211102x6147b025r1f384da0128bf2cb@mail.gmail.com> References: <4B20662F.6070805@sun.com> <17c6771e0912101307y36419d26lb6553131af02bb95@mail.gmail.com> <4B216A19.10909@sun.com> <17c6771e0912101358i6654222y636cc1a30fe95e66@mail.gmail.com> <4B217892.3000006@sun.com> <17c6771e0912151258vef342bbo388e23813493080f@mail.gmail.com> <4B27F9B0.2050204@sun.com> <17c6771e0912210953i66a30e46nc958ed99165769d6@mail.gmail.com> <4B2FB7F3.4090508@sun.com> <17c6771e0912211102x6147b025r1f384da0128bf2cb@mail.gmail.com> Message-ID: <4B3022F4.1080503@sun.com> Andrew John Hughes wrote: > 2009/12/21 Joseph D. Darcy : > >> Andrew John Hughes wrote: >> >>> 2009/12/15 Joseph D. Darcy : >>> >>> >>> [snip] >>>> >>>> >>>> >>> Two more: >>> >>> changeset: 1624:f1eb4c28b313 >>> user: lancea >>> date: Wed Sep 09 20:15:22 2009 -0400 >>> summary: 6737212: Fixed javadoc warning messages in RowSet classes >>> http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f1eb4c28b313 >>> >>> >> Approved to be pushed. >> >> >>> changeset: 1969:3267ca7afe95 >>> user: darcy >>> date: Fri Dec 11 10:40:14 2009 -0800 >>> summary: 6909563: Javadoc build warnings in rmi, security, management >>> http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3267ca7afe95 >>> >>> Ok to go back? >>> >>> >> I also approve this one going back with the condition that any unneeded >> changes to JDK 7-only files are removed. >> >> Cheers, >> >> -Joe >> >> >> > > Both done. The changes that were to JDK7-only classes simply didn't apply. > Next one: > > changeset: 1572:196c7bb551e7 > user: darcy > date: Tue Aug 25 18:58:26 2009 -0700 > summary: 6875861: javadoc build warning on java.util.Properites > from unconventional @see ordering > http://hg.openjdk.java.net/jdk7/tl/jdk/rev/196c7bb551e7 > Approved to go back. Thanks, -Joe From ahughes at redhat.com Mon Dec 21 17:52:11 2009 From: ahughes at redhat.com (ahughes at redhat.com) Date: Tue, 22 Dec 2009 01:52:11 +0000 Subject: hg: jdk6/jdk6/jdk: 6875861: javadoc build warning on java.util.Properites from unconventional @see ordering Message-ID: <20091222015220.28E4B42AC6@hg.openjdk.java.net> Changeset: f2172f732eb3 Author: darcy Date: 2009-08-25 18:58 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/f2172f732eb3 6875861: javadoc build warning on java.util.Properites from unconventional @see ordering Reviewed-by: martin ! src/share/classes/java/util/Properties.java From ptisnovs at redhat.com Tue Dec 22 10:20:49 2009 From: ptisnovs at redhat.com (ptisnovs at redhat.com) Date: Tue, 22 Dec 2009 18:20:49 +0000 Subject: hg: jdk6/jdk6/jdk: 6912628: test/java/util/jar/JarFile/TurkCert.java cannot be run in samevm mode Message-ID: <20091222182059.296DA42BD2@hg.openjdk.java.net> Changeset: e334dfb326b1 Author: ptisnovs Date: 2009-12-22 19:15 +0100 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/e334dfb326b1 6912628: test/java/util/jar/JarFile/TurkCert.java cannot be run in samevm mode Summary: Added tag to run this test in othervm Reviewed-by: chegar ! test/java/util/jar/JarFile/TurkCert.java From gnu_andrew at member.fsf.org Tue Dec 22 13:00:53 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 22 Dec 2009 21:00:53 +0000 Subject: make/java/nio/FILES_java.gmk does not list Unicode.java Message-ID: <17c6771e0912221300l612e10cw8bdaf58f6960bcf9@mail.gmail.com> On building OpenJDK6 from the Mercurial forest with IcedTea, I found that the class sun.nio.cs.Unicode is not built as it is not listed in FILES_java.gmk. Presumably, it was being pulled in before by some dependency which has changed since b17. The failure only occurs when bootstrapping with ecj but I don't think we should be relying on the dependency resolution of compilers to pull in essential classes (the lack of this one causes the VM to fail to even print the help output). This webrev http://cr.openjdk.java.net/~andrew/build/webrev.01/ fixes the issue and should probably go into 7 as well. Does this look ok? If so, can I have a bug ID to push it? Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Alan.Bateman at Sun.COM Wed Dec 23 02:08:27 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Wed, 23 Dec 2009 10:08:27 +0000 Subject: make/java/nio/FILES_java.gmk does not list Unicode.java In-Reply-To: <17c6771e0912221300l612e10cw8bdaf58f6960bcf9@mail.gmail.com> References: <17c6771e0912221300l612e10cw8bdaf58f6960bcf9@mail.gmail.com> Message-ID: <4B31EC1B.4010706@sun.com> Andrew John Hughes wrote: > On building OpenJDK6 from the Mercurial forest with IcedTea, I found > that the class sun.nio.cs.Unicode is not built as it is not listed in > FILES_java.gmk. Presumably, it was being pulled in before by some > dependency which has changed since b17. The failure only occurs when > bootstrapping with ecj but I don't think we should be relying on the > dependency resolution of compilers to pull in essential classes (the > lack of this one causes the VM to fail to even print the help output). > > This webrev http://cr.openjdk.java.net/~andrew/build/webrev.01/ fixes > the issue and should probably go into 7 as well. > > Does this look ok? If so, can I have a bug ID to push it? > > Thanks, > Looks okay to me. I've created a bug to track this: 6912893: (build) make/java/nio/FILES_java.gmk doesn't list sun.nio.cs.Unicode I agree on pushing this to jdk7 too (jdk7/jdk7/jdk would be best). -Alan. From Alan.Bateman at Sun.COM Wed Dec 23 02:11:13 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Wed, 23 Dec 2009 10:11:13 +0000 Subject: make/java/nio/FILES_java.gmk does not list Unicode.java In-Reply-To: <4B31EC1B.4010706@sun.com> References: <17c6771e0912221300l612e10cw8bdaf58f6960bcf9@mail.gmail.com> <4B31EC1B.4010706@sun.com> Message-ID: <4B31ECC1.3010006@sun.com> Alan Bateman wrote: > : > > I agree on pushing this to jdk7 too (jdk7/jdk7/jdk would be best). Ah, I meant jdk7/tl/jdk as that is where the any fixes in the nio area are pushed. -Alan. From ahughes at redhat.com Wed Dec 23 09:18:42 2009 From: ahughes at redhat.com (ahughes at redhat.com) Date: Wed, 23 Dec 2009 17:18:42 +0000 Subject: hg: jdk6/jdk6/jdk: 2 new changesets Message-ID: <20091223171900.112FE42D48@hg.openjdk.java.net> Changeset: ab9fdb59d707 Author: andrew Date: 2009-12-23 17:17 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/ab9fdb59d707 6912893: (build) make/java/nio/FILES_java.gmk doesn't list sun.nio.cs.Unicode Summary: Add missing Java source file Reviewed-by: alanb ! make/java/nio/FILES_java.gmk Changeset: ec7495b36f90 Author: andrew Date: 2009-12-23 17:18 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/ec7495b36f90 Merge From gnu_andrew at member.fsf.org Wed Dec 23 10:11:13 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 23 Dec 2009 18:11:13 +0000 Subject: make/java/nio/FILES_java.gmk does not list Unicode.java In-Reply-To: <4B31EC1B.4010706@sun.com> References: <17c6771e0912221300l612e10cw8bdaf58f6960bcf9@mail.gmail.com> <4B31EC1B.4010706@sun.com> Message-ID: <17c6771e0912231011s2482be77u9faa0cb3bb69daf4@mail.gmail.com> 2009/12/23 Alan Bateman : > Andrew John Hughes wrote: >> >> On building OpenJDK6 from the Mercurial forest with IcedTea, I found >> that the class sun.nio.cs.Unicode is not built as it is not listed in >> FILES_java.gmk. ?Presumably, it was being pulled in before by some >> dependency which has changed since b17. ?The failure only occurs when >> bootstrapping with ecj but I don't think we should be relying on the >> dependency resolution of compilers to pull in essential classes (the >> lack of this one causes the VM to fail to even print the help output). >> >> This webrev http://cr.openjdk.java.net/~andrew/build/webrev.01/ fixes >> the issue and should probably go into 7 as well. >> >> Does this look ok? If so, can I have a bug ID to push it? >> >> Thanks, >> > > Looks okay to me. I've created a bug to track this: > > 6912893: (build) make/java/nio/FILES_java.gmk doesn't list > sun.nio.cs.Unicode > > I agree on pushing this to jdk7 too (jdk7/jdk7/jdk would be best). > > -Alan. > Done: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/ab9fdb59d707 http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4a062158d2c5 Thanks Alan, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From martinrb at google.com Wed Dec 23 15:47:55 2009 From: martinrb at google.com (Martin Buchholz) Date: Wed, 23 Dec 2009 15:47:55 -0800 Subject: 6712755: jarsigner fails to sign itextasian.jar since 1.5.0_b14, it works with 1.5.0_13 Message-ID: <1ccfd1c10912231547u83018bbx8f6336afb5acfde4@mail.gmail.com> Hi, We've found that the fix for 6712755: jarsigner fails to sign itextasian.jar since 1.5.0_b14, it works with 1.5.0_13 is a good thing to have in openjdk6. Permission to do the trivial backport? jarsigner chokes on empty lines in MANIFEST.MF files. Backport from openjdk7 of: # HG changeset patch # User weijun # Date 1245294733 -28800 # Node ID 863351d5d244ad4077a9b8db87bb9f186ce76f76 # Parent bc2c9dbdcc704deab9466581d32f5fc011c5b8d1 6712755: jarsigner fails to sign itextasian.jar since 1.5.0_b14, it works with 1.5.0_13 Reviewed-by: mullan http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/863351d5d244 http://bugs.sun.com/view_bug.do?bug_id=6712755 From Joe.Darcy at Sun.COM Wed Dec 23 16:10:50 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Wed, 23 Dec 2009 16:10:50 -0800 Subject: 6712755: jarsigner fails to sign itextasian.jar since 1.5.0_b14, it works with 1.5.0_13 In-Reply-To: <1ccfd1c10912231547u83018bbx8f6336afb5acfde4@mail.gmail.com> References: <1ccfd1c10912231547u83018bbx8f6336afb5acfde4@mail.gmail.com> Message-ID: <4B32B18A.60803@sun.com> Martin Buchholz wrote: > Hi, > > We've found that the fix for > 6712755: jarsigner fails to sign itextasian.jar since 1.5.0_b14, it > works with 1.5.0_13 > is a good thing to have in openjdk6. > Permission to do the trivial backport? > Approved for backport :-) Cheers, -Joe From Weijun.Wang at Sun.COM Wed Dec 23 16:10:56 2009 From: Weijun.Wang at Sun.COM (Max (Weijun) Wang) Date: Thu, 24 Dec 2009 08:10:56 +0800 Subject: Backport request (was Re: 6712755: jarsigner fails to sign itextasian.jar since 1.5.0_b14, it works with 1.5.0_13) In-Reply-To: <1ccfd1c10912231547u83018bbx8f6336afb5acfde4@mail.gmail.com> References: <1ccfd1c10912231547u83018bbx8f6336afb5acfde4@mail.gmail.com> Message-ID: <2BFE04C2-75CC-4A05-B9FD-00391327B7A6@Sun.COM> Joe 6712755 is a regression made by 6543940. openjdk-7 openjdk-6 6712755 b16 included 6543940 b64 not included Martin, do you want to do the backport yourself? Thanks Max On Dec 24, 2009, at 7:47 AM, Martin Buchholz wrote: > Hi, > > We've found that the fix for > 6712755: jarsigner fails to sign itextasian.jar since 1.5.0_b14, it > works with 1.5.0_13 > is a good thing to have in openjdk6. > Permission to do the trivial backport? > > jarsigner chokes on empty lines in MANIFEST.MF files. > > Backport from openjdk7 of: > # HG changeset patch > # User weijun > # Date 1245294733 -28800 > # Node ID 863351d5d244ad4077a9b8db87bb9f186ce76f76 > # Parent bc2c9dbdcc704deab9466581d32f5fc011c5b8d1 > 6712755: jarsigner fails to sign itextasian.jar since > 1.5.0_b14, it > works with 1.5.0_13 > Reviewed-by: mullan > > http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/863351d5d244 > > http://bugs.sun.com/view_bug.do?bug_id=6712755 From martinrb at google.com Wed Dec 23 16:45:13 2009 From: martinrb at google.com (Martin Buchholz) Date: Wed, 23 Dec 2009 16:45:13 -0800 Subject: Backport request (was Re: 6712755: jarsigner fails to sign itextasian.jar since 1.5.0_b14, it works with 1.5.0_13) In-Reply-To: <2BFE04C2-75CC-4A05-B9FD-00391327B7A6@Sun.COM> References: <1ccfd1c10912231547u83018bbx8f6336afb5acfde4@mail.gmail.com> <2BFE04C2-75CC-4A05-B9FD-00391327B7A6@Sun.COM> Message-ID: <1ccfd1c10912231645rf860f55j8504e754c1536364@mail.gmail.com> On Wed, Dec 23, 2009 at 16:10, Max (Weijun) Wang wrote: > Joe > > 6712755 is a regression made by 6543940. > > ? ? ? ? ? ? ? openjdk-7 ? ? openjdk-6 > ? 6712755 ? ? b16 ? ? ? ? ? included > ? 6543940 ? ? b64 ? ? ? ? ? not included > > Martin, do you want to do the backport yourself? It's already "done". All I did was (cd jdk7/jdk && hg export ...) | (cd jdk6/jdk && hg qimport -n jarsigner -) Martin > Thanks > Max > > On Dec 24, 2009, at 7:47 AM, Martin Buchholz wrote: > >> Hi, >> >> We've found that the fix for >> 6712755: jarsigner fails to sign itextasian.jar since 1.5.0_b14, it >> works with 1.5.0_13 >> is a good thing to have in openjdk6. >> Permission to do the trivial backport? >> >> ? ? ?jarsigner chokes on empty lines in MANIFEST.MF files. >> >> ? ? ?Backport from openjdk7 of: >> ? ? ?# HG changeset patch >> ? ? ?# User weijun >> ? ? ?# Date 1245294733 -28800 >> ? ? ?# Node ID 863351d5d244ad4077a9b8db87bb9f186ce76f76 >> ? ? ?# Parent bc2c9dbdcc704deab9466581d32f5fc011c5b8d1 >> ? ? ?6712755: jarsigner fails to sign itextasian.jar since 1.5.0_b14, it >> ? ? ?works with 1.5.0_13 >> ? ? ?Reviewed-by: mullan >> >> ? ? ?http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/863351d5d244 >> >> ? ? ?http://bugs.sun.com/view_bug.do?bug_id=6712755 > > From martinrb at google.com Wed Dec 23 16:54:47 2009 From: martinrb at google.com (Martin Buchholz) Date: Wed, 23 Dec 2009 16:54:47 -0800 Subject: Backport request (was Re: 6712755: jarsigner fails to sign itextasian.jar since 1.5.0_b14, it works with 1.5.0_13) In-Reply-To: <1ccfd1c10912231645rf860f55j8504e754c1536364@mail.gmail.com> References: <1ccfd1c10912231547u83018bbx8f6336afb5acfde4@mail.gmail.com> <2BFE04C2-75CC-4A05-B9FD-00391327B7A6@Sun.COM> <1ccfd1c10912231645rf860f55j8504e754c1536364@mail.gmail.com> Message-ID: <1ccfd1c10912231654o5b798f14x78d7fdcd6df2dff2@mail.gmail.com> On Wed, Dec 23, 2009 at 16:45, Martin Buchholz wrote: > On Wed, Dec 23, 2009 at 16:10, Max (Weijun) Wang wrote: >> Joe >> >> 6712755 is a regression made by 6543940. >> >> ? ? ? ? ? ? ? openjdk-7 ? ? openjdk-6 >> ? 6712755 ? ? b16 ? ? ? ? ? included >> ? 6543940 ? ? b64 ? ? ? ? ? not included >> >> Martin, do you want to do the backport yourself? > > It's already "done". > All I did was > (cd jdk7/jdk && hg export ...) | (cd jdk6/jdk && hg qimport -n jarsigner -) Hmmmm..... I have to retract that. The new test didn't pass, because the jdk6 jarsigner doesn't recognize the jdk7 option "-strict" Removing "-strict" make the test pass. Martin > Martin > >> Thanks >> Max >> >> On Dec 24, 2009, at 7:47 AM, Martin Buchholz wrote: >> >>> Hi, >>> >>> We've found that the fix for >>> 6712755: jarsigner fails to sign itextasian.jar since 1.5.0_b14, it >>> works with 1.5.0_13 >>> is a good thing to have in openjdk6. >>> Permission to do the trivial backport? >>> >>> ? ? ?jarsigner chokes on empty lines in MANIFEST.MF files. >>> >>> ? ? ?Backport from openjdk7 of: >>> ? ? ?# HG changeset patch >>> ? ? ?# User weijun >>> ? ? ?# Date 1245294733 -28800 >>> ? ? ?# Node ID 863351d5d244ad4077a9b8db87bb9f186ce76f76 >>> ? ? ?# Parent bc2c9dbdcc704deab9466581d32f5fc011c5b8d1 >>> ? ? ?6712755: jarsigner fails to sign itextasian.jar since 1.5.0_b14, it >>> ? ? ?works with 1.5.0_13 >>> ? ? ?Reviewed-by: mullan >>> >>> ? ? ?http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/863351d5d244 >>> >>> ? ? ?http://bugs.sun.com/view_bug.do?bug_id=6712755 >> >> > From Weijun.Wang at Sun.COM Wed Dec 23 16:59:32 2009 From: Weijun.Wang at Sun.COM (Max (Weijun) Wang) Date: Thu, 24 Dec 2009 08:59:32 +0800 Subject: Backport request (was Re: 6712755: jarsigner fails to sign itextasian.jar since 1.5.0_b14, it works with 1.5.0_13) In-Reply-To: <1ccfd1c10912231654o5b798f14x78d7fdcd6df2dff2@mail.gmail.com> References: <1ccfd1c10912231547u83018bbx8f6336afb5acfde4@mail.gmail.com> <2BFE04C2-75CC-4A05-B9FD-00391327B7A6@Sun.COM> <1ccfd1c10912231645rf860f55j8504e754c1536364@mail.gmail.com> <1ccfd1c10912231654o5b798f14x78d7fdcd6df2dff2@mail.gmail.com> Message-ID: <5787ECF3-8F0A-42BC-9F39-A0F31CF7D148@Sun.COM> Well, without the -strict option, warning is not error, and the test cannot prove the fix. Max On Dec 24, 2009, at 8:54 AM, Martin Buchholz wrote: > On Wed, Dec 23, 2009 at 16:45, Martin Buchholz > wrote: >> On Wed, Dec 23, 2009 at 16:10, Max (Weijun) Wang >> wrote: >>> Joe >>> >>> 6712755 is a regression made by 6543940. >>> >>> openjdk-7 openjdk-6 >>> 6712755 b16 included >>> 6543940 b64 not included >>> >>> Martin, do you want to do the backport yourself? >> >> It's already "done". >> All I did was >> (cd jdk7/jdk && hg export ...) | (cd jdk6/jdk && hg qimport -n >> jarsigner -) > > Hmmmm..... I have to retract that. > > The new test didn't pass, because > the jdk6 jarsigner doesn't recognize the jdk7 option "-strict" > Removing "-strict" make the test pass. > > Martin > >> Martin >> >>> Thanks >>> Max >>> >>> On Dec 24, 2009, at 7:47 AM, Martin Buchholz wrote: >>> >>>> Hi, >>>> >>>> We've found that the fix for >>>> 6712755: jarsigner fails to sign itextasian.jar since 1.5.0_b14, it >>>> works with 1.5.0_13 >>>> is a good thing to have in openjdk6. >>>> Permission to do the trivial backport? >>>> >>>> jarsigner chokes on empty lines in MANIFEST.MF files. >>>> >>>> Backport from openjdk7 of: >>>> # HG changeset patch >>>> # User weijun >>>> # Date 1245294733 -28800 >>>> # Node ID 863351d5d244ad4077a9b8db87bb9f186ce76f76 >>>> # Parent bc2c9dbdcc704deab9466581d32f5fc011c5b8d1 >>>> 6712755: jarsigner fails to sign itextasian.jar since >>>> 1.5.0_b14, it >>>> works with 1.5.0_13 >>>> Reviewed-by: mullan >>>> >>>> http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/863351d5d244 >>>> >>>> http://bugs.sun.com/view_bug.do?bug_id=6712755 >>> >>> >> From martinrb at google.com Wed Dec 23 17:13:43 2009 From: martinrb at google.com (Martin Buchholz) Date: Wed, 23 Dec 2009 17:13:43 -0800 Subject: Backport request (was Re: 6712755: jarsigner fails to sign itextasian.jar since 1.5.0_b14, it works with 1.5.0_13) In-Reply-To: <5787ECF3-8F0A-42BC-9F39-A0F31CF7D148@Sun.COM> References: <1ccfd1c10912231547u83018bbx8f6336afb5acfde4@mail.gmail.com> <2BFE04C2-75CC-4A05-B9FD-00391327B7A6@Sun.COM> <1ccfd1c10912231645rf860f55j8504e754c1536364@mail.gmail.com> <1ccfd1c10912231654o5b798f14x78d7fdcd6df2dff2@mail.gmail.com> <5787ECF3-8F0A-42BC-9F39-A0F31CF7D148@Sun.COM> Message-ID: <1ccfd1c10912231713w125786cck52d48cefea92156@mail.gmail.com> On Wed, Dec 23, 2009 at 16:59, Max (Weijun) Wang wrote: > Well, without the -strict option, warning is not error, and the test cannot > prove the fix. Hmmm... yes. It appears that the warning is only written to stdout, not stderr, so can't use that to test for failure. Here's another attempt, that I have tested to ensure it fails without and passes with, the fix, which should be good enough at least for this backport. $JARSIGNER -keystore $KS -verify -debug $JFILE 2>&1 | grep Warning && exit 2 Martin > Max > > On Dec 24, 2009, at 8:54 AM, Martin Buchholz wrote: > >> On Wed, Dec 23, 2009 at 16:45, Martin Buchholz >> wrote: >>> >>> On Wed, Dec 23, 2009 at 16:10, Max (Weijun) Wang >>> wrote: >>>> >>>> Joe >>>> >>>> 6712755 is a regression made by 6543940. >>>> >>>> ? ? ? ? ? ? ?openjdk-7 ? ? openjdk-6 >>>> ?6712755 ? ? b16 ? ? ? ? ? included >>>> ?6543940 ? ? b64 ? ? ? ? ? not included >>>> >>>> Martin, do you want to do the backport yourself? >>> >>> It's already "done". >>> All I did was >>> (cd jdk7/jdk && hg export ...) | (cd jdk6/jdk && hg qimport -n jarsigner >>> -) >> >> Hmmmm..... I have to retract that. >> >> The new test didn't pass, because >> the jdk6 jarsigner doesn't recognize the jdk7 option "-strict" >> Removing "-strict" make the test pass. >> >> Martin >> >>> Martin >>> >>>> Thanks >>>> Max >>>> >>>> On Dec 24, 2009, at 7:47 AM, Martin Buchholz wrote: >>>> >>>>> Hi, >>>>> >>>>> We've found that the fix for >>>>> 6712755: jarsigner fails to sign itextasian.jar since 1.5.0_b14, it >>>>> works with 1.5.0_13 >>>>> is a good thing to have in openjdk6. >>>>> Permission to do the trivial backport? >>>>> >>>>> ? ? jarsigner chokes on empty lines in MANIFEST.MF files. >>>>> >>>>> ? ? Backport from openjdk7 of: >>>>> ? ? # HG changeset patch >>>>> ? ? # User weijun >>>>> ? ? # Date 1245294733 -28800 >>>>> ? ? # Node ID 863351d5d244ad4077a9b8db87bb9f186ce76f76 >>>>> ? ? # Parent bc2c9dbdcc704deab9466581d32f5fc011c5b8d1 >>>>> ? ? 6712755: jarsigner fails to sign itextasian.jar since 1.5.0_b14, it >>>>> ? ? works with 1.5.0_13 >>>>> ? ? Reviewed-by: mullan >>>>> >>>>> ? ? http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/863351d5d244 >>>>> >>>>> ? ? http://bugs.sun.com/view_bug.do?bug_id=6712755 >>>> >>>> >>> > > From Weijun.Wang at Sun.COM Wed Dec 23 17:15:28 2009 From: Weijun.Wang at Sun.COM (Max (Weijun) Wang) Date: Thu, 24 Dec 2009 09:15:28 +0800 Subject: Backport request (was Re: 6712755: jarsigner fails to sign itextasian.jar since 1.5.0_b14, it works with 1.5.0_13) In-Reply-To: <1ccfd1c10912231713w125786cck52d48cefea92156@mail.gmail.com> References: <1ccfd1c10912231547u83018bbx8f6336afb5acfde4@mail.gmail.com> <2BFE04C2-75CC-4A05-B9FD-00391327B7A6@Sun.COM> <1ccfd1c10912231645rf860f55j8504e754c1536364@mail.gmail.com> <1ccfd1c10912231654o5b798f14x78d7fdcd6df2dff2@mail.gmail.com> <5787ECF3-8F0A-42BC-9F39-A0F31CF7D148@Sun.COM> <1ccfd1c10912231713w125786cck52d48cefea92156@mail.gmail.com> Message-ID: <24A43AA0-5B7B-4559-A503-97FDAB466EEA@Sun.COM> On Dec 24, 2009, at 9:13 AM, Martin Buchholz wrote: > On Wed, Dec 23, 2009 at 16:59, Max (Weijun) Wang > wrote: >> Well, without the -strict option, warning is not error, and the >> test cannot >> prove the fix. > > Hmmm... yes. > > It appears that the warning is only written to stdout, not stderr, > so can't use that to test for failure. > > Here's another attempt, that I have tested to ensure it > fails without and passes with, the fix, which should be good enough > at least for this backport. > > $JARSIGNER -keystore $KS -verify -debug $JFILE 2>&1 | grep Warning > && exit 2 This should be fine. Max > > Martin > >> Max >> >> On Dec 24, 2009, at 8:54 AM, Martin Buchholz wrote: >> >>> On Wed, Dec 23, 2009 at 16:45, Martin Buchholz >>> wrote: >>>> >>>> On Wed, Dec 23, 2009 at 16:10, Max (Weijun) Wang >>> > >>>> wrote: >>>>> >>>>> Joe >>>>> >>>>> 6712755 is a regression made by 6543940. >>>>> >>>>> openjdk-7 openjdk-6 >>>>> 6712755 b16 included >>>>> 6543940 b64 not included >>>>> >>>>> Martin, do you want to do the backport yourself? >>>> >>>> It's already "done". >>>> All I did was >>>> (cd jdk7/jdk && hg export ...) | (cd jdk6/jdk && hg qimport -n >>>> jarsigner >>>> -) >>> >>> Hmmmm..... I have to retract that. >>> >>> The new test didn't pass, because >>> the jdk6 jarsigner doesn't recognize the jdk7 option "-strict" >>> Removing "-strict" make the test pass. >>> >>> Martin >>> >>>> Martin >>>> >>>>> Thanks >>>>> Max >>>>> >>>>> On Dec 24, 2009, at 7:47 AM, Martin Buchholz wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> We've found that the fix for >>>>>> 6712755: jarsigner fails to sign itextasian.jar since >>>>>> 1.5.0_b14, it >>>>>> works with 1.5.0_13 >>>>>> is a good thing to have in openjdk6. >>>>>> Permission to do the trivial backport? >>>>>> >>>>>> jarsigner chokes on empty lines in MANIFEST.MF files. >>>>>> >>>>>> Backport from openjdk7 of: >>>>>> # HG changeset patch >>>>>> # User weijun >>>>>> # Date 1245294733 -28800 >>>>>> # Node ID 863351d5d244ad4077a9b8db87bb9f186ce76f76 >>>>>> # Parent bc2c9dbdcc704deab9466581d32f5fc011c5b8d1 >>>>>> 6712755: jarsigner fails to sign itextasian.jar since >>>>>> 1.5.0_b14, it >>>>>> works with 1.5.0_13 >>>>>> Reviewed-by: mullan >>>>>> >>>>>> http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/863351d5d244 >>>>>> >>>>>> http://bugs.sun.com/view_bug.do?bug_id=6712755 >>>>> >>>>> >>>> >> >> From martinrb at google.com Wed Dec 23 17:22:13 2009 From: martinrb at google.com (martinrb at google.com) Date: Thu, 24 Dec 2009 01:22:13 +0000 Subject: hg: jdk6/jdk6/jdk: 6712755: jarsigner fails to sign itextasian.jar since 1.5.0_b14, it works with 1.5.0_13 Message-ID: <20091224012221.88C4D42DCF@hg.openjdk.java.net> Changeset: 134c345baf84 Author: weijun Date: 2009-06-18 11:12 +0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/134c345baf84 6712755: jarsigner fails to sign itextasian.jar since 1.5.0_b14, it works with 1.5.0_13 Summary: Easy backport (just needed to remove jdk7-ism "-strict" from test) Reviewed-by: mullan ! src/share/classes/sun/security/tools/JarSigner.java + test/sun/security/tools/jarsigner/emptymanifest.sh From martinrb at google.com Wed Dec 23 17:26:00 2009 From: martinrb at google.com (Martin Buchholz) Date: Wed, 23 Dec 2009 17:26:00 -0800 Subject: Backport request (was Re: 6712755: jarsigner fails to sign itextasian.jar since 1.5.0_b14, it works with 1.5.0_13) In-Reply-To: <24A43AA0-5B7B-4559-A503-97FDAB466EEA@Sun.COM> References: <1ccfd1c10912231547u83018bbx8f6336afb5acfde4@mail.gmail.com> <2BFE04C2-75CC-4A05-B9FD-00391327B7A6@Sun.COM> <1ccfd1c10912231645rf860f55j8504e754c1536364@mail.gmail.com> <1ccfd1c10912231654o5b798f14x78d7fdcd6df2dff2@mail.gmail.com> <5787ECF3-8F0A-42BC-9F39-A0F31CF7D148@Sun.COM> <1ccfd1c10912231713w125786cck52d48cefea92156@mail.gmail.com> <24A43AA0-5B7B-4559-A503-97FDAB466EEA@Sun.COM> Message-ID: <1ccfd1c10912231726r45b03962n1f513cd82f33b968@mail.gmail.com> Thanks for the speedy review cycle. Fix pushed to jdk6. Martin On Wed, Dec 23, 2009 at 17:15, Max (Weijun) Wang wrote: > > On Dec 24, 2009, at 9:13 AM, Martin Buchholz wrote: > >> On Wed, Dec 23, 2009 at 16:59, Max (Weijun) Wang >> wrote: >>> >>> Well, without the -strict option, warning is not error, and the test >>> cannot >>> prove the fix. >> >> Hmmm... yes. >> >> It appears that the warning is only written to stdout, not stderr, >> so can't use that to test for failure. >> >> Here's another attempt, that I have tested to ensure it >> fails without and passes with, the fix, which should be good enough >> at least for this backport. >> >> $JARSIGNER -keystore $KS -verify -debug $JFILE 2>&1 | grep Warning && exit >> 2 > > This should be fine. > > Max > >> >> Martin >> >>> Max >>> >>> On Dec 24, 2009, at 8:54 AM, Martin Buchholz wrote: >>> >>>> On Wed, Dec 23, 2009 at 16:45, Martin Buchholz >>>> wrote: >>>>> >>>>> On Wed, Dec 23, 2009 at 16:10, Max (Weijun) Wang >>>>> wrote: >>>>>> >>>>>> Joe >>>>>> >>>>>> 6712755 is a regression made by 6543940. >>>>>> >>>>>> ? ? ? ? ? ? openjdk-7 ? ? openjdk-6 >>>>>> ?6712755 ? ? b16 ? ? ? ? ? included >>>>>> ?6543940 ? ? b64 ? ? ? ? ? not included >>>>>> >>>>>> Martin, do you want to do the backport yourself? >>>>> >>>>> It's already "done". >>>>> All I did was >>>>> (cd jdk7/jdk && hg export ...) | (cd jdk6/jdk && hg qimport -n >>>>> jarsigner >>>>> -) >>>> >>>> Hmmmm..... I have to retract that. >>>> >>>> The new test didn't pass, because >>>> the jdk6 jarsigner doesn't recognize the jdk7 option "-strict" >>>> Removing "-strict" make the test pass. >>>> >>>> Martin >>>> >>>>> Martin >>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>> On Dec 24, 2009, at 7:47 AM, Martin Buchholz wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> We've found that the fix for >>>>>>> 6712755: jarsigner fails to sign itextasian.jar since 1.5.0_b14, it >>>>>>> works with 1.5.0_13 >>>>>>> is a good thing to have in openjdk6. >>>>>>> Permission to do the trivial backport? >>>>>>> >>>>>>> ? ?jarsigner chokes on empty lines in MANIFEST.MF files. >>>>>>> >>>>>>> ? ?Backport from openjdk7 of: >>>>>>> ? ?# HG changeset patch >>>>>>> ? ?# User weijun >>>>>>> ? ?# Date 1245294733 -28800 >>>>>>> ? ?# Node ID 863351d5d244ad4077a9b8db87bb9f186ce76f76 >>>>>>> ? ?# Parent bc2c9dbdcc704deab9466581d32f5fc011c5b8d1 >>>>>>> ? ?6712755: jarsigner fails to sign itextasian.jar since 1.5.0_b14, >>>>>>> it >>>>>>> ? ?works with 1.5.0_13 >>>>>>> ? ?Reviewed-by: mullan >>>>>>> >>>>>>> ? ?http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/863351d5d244 >>>>>>> >>>>>>> ? ?http://bugs.sun.com/view_bug.do?bug_id=6712755 >>>>>> >>>>>> >>>>> >>> >>> > > From gnu_andrew at member.fsf.org Wed Dec 23 18:31:05 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 24 Dec 2009 02:31:05 +0000 Subject: Backport request (was Re: 6712755: jarsigner fails to sign itextasian.jar since 1.5.0_b14, it works with 1.5.0_13) In-Reply-To: <1ccfd1c10912231645rf860f55j8504e754c1536364@mail.gmail.com> References: <1ccfd1c10912231547u83018bbx8f6336afb5acfde4@mail.gmail.com> <2BFE04C2-75CC-4A05-B9FD-00391327B7A6@Sun.COM> <1ccfd1c10912231645rf860f55j8504e754c1536364@mail.gmail.com> Message-ID: <17c6771e0912231831j4a1266dvc8874dee7847d1a9@mail.gmail.com> 2009/12/24 Martin Buchholz : > On Wed, Dec 23, 2009 at 16:10, Max (Weijun) Wang wrote: >> Joe >> >> 6712755 is a regression made by 6543940. >> >> ? ? ? ? ? ? ? openjdk-7 ? ? openjdk-6 >> ? 6712755 ? ? b16 ? ? ? ? ? included >> ? 6543940 ? ? b64 ? ? ? ? ? not included >> >> Martin, do you want to do the backport yourself? > > It's already "done". > All I did was > (cd jdk7/jdk && hg export ...) | (cd jdk6/jdk && hg qimport -n jarsigner -) > hg -R jdk7/jdk export ... | hg -R jdk6/jdk qimport -n jarsigner - is even easier... ;) > Martin > >> Thanks >> Max >> >> On Dec 24, 2009, at 7:47 AM, Martin Buchholz wrote: >> >>> Hi, >>> >>> We've found that the fix for >>> 6712755: jarsigner fails to sign itextasian.jar since 1.5.0_b14, it >>> works with 1.5.0_13 >>> is a good thing to have in openjdk6. >>> Permission to do the trivial backport? >>> >>> ? ? ?jarsigner chokes on empty lines in MANIFEST.MF files. >>> >>> ? ? ?Backport from openjdk7 of: >>> ? ? ?# HG changeset patch >>> ? ? ?# User weijun >>> ? ? ?# Date 1245294733 -28800 >>> ? ? ?# Node ID 863351d5d244ad4077a9b8db87bb9f186ce76f76 >>> ? ? ?# Parent bc2c9dbdcc704deab9466581d32f5fc011c5b8d1 >>> ? ? ?6712755: jarsigner fails to sign itextasian.jar since 1.5.0_b14, it >>> ? ? ?works with 1.5.0_13 >>> ? ? ?Reviewed-by: mullan >>> >>> ? ? ?http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/863351d5d244 >>> >>> ? ? ?http://bugs.sun.com/view_bug.do?bug_id=6712755 >> >> > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Thu Dec 24 07:23:51 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 24 Dec 2009 15:23:51 +0000 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <4AF8D443.6080704@sun.com> References: <4AF4B948.5070702@sun.com> <17c6771e0911071712n1ee39648tcda8605c9682230a@mail.gmail.com> <4AF61D76.8040805@sun.com> <4AF5510B.4080309@sun.com> <17c6771e0911090821ne68ac97nc7e3e50d889b7ce9@mail.gmail.com> <4AF8D443.6080704@sun.com> Message-ID: <17c6771e0912240723o6acdc97fj7ae02521c1e1730a@mail.gmail.com> 2009/11/10 Joseph D. Darcy : > Andrew John Hughes wrote: >> >> 2009/11/7 Joseph D. Darcy : >> >>> >>> Jonathan Gibbons wrote: >>> >>>> >>>> Andrew John Hughes wrote: >>>> >>>>> >>>>> 2009/11/7 Joseph D. Darcy : >>>>> >>>>> >>>>>> >>>>>> Hello. >>>>>> >>>>>> The latest batch of security fixes have been pushed into OpenJDK 6. >>>>>> >>>>>> Martin and Andrew, you're clear to push your other fixes back. >>>>>> >>>>>> >>>>>> >>>>> >>>>> Thanks, I'll get onto that tomorrow or Monday. >>>>> >>>>> >>>>> >>>>>> >>>>>> Now that OpenJDK 6 has the latest security fixes, Andrew's backport of >>>>>> Nimbus, and the new delivery model for jaxp and jaxws, that might be a >>>>>> good >>>>>> amount of change to be a new build, b18. >>>>>> >>>>>> Is there any other work that should go back into b18? >>>>>> >>>>>> >>>>>> >>>>> >>>>> I'd like to get a backport of >>>>> http://hg.openjdk.java.net/jdk7/jdk7/rev/d6b08bdb9a54 in. ?It's a >>>>> minor fix that Kelly found that gets rid of the superfluous -fastdebug >>>>> build directory currently being produced by OpenJDK6 builds. >>>>> >>>>> Otherwise I think it's good to go. >>>>> >>>>> The list has been silent on the matter, but I discussed hs16 and >>>>> OpenJDK6 with Dalibor on IRC and we agreed that it would be better to >>>>> wait until this is more stable before bumping up OpenJDK6 to it. >>>>> IcedTea is currently supporting it as a build option, but it isn't >>>>> turned on by default. ?One advantage to hs16 going into OpenJDK6 is >>>>> that the Zero assembler port changeset which was recently promoted >>>>> into b75 could be backported. ?Otherwise, it needs a few things >>>>> ripping out to work with hs14 (and then putting back when we do go to >>>>> hs16). >>>>> >>>>> >>>>> >>>>>> >>>>>> -Joe >>>>>> >>>>>> >>>>>> >>>>> >>>>> Thanks, >>>>> >>>>> >>>> >>>> Joe and I have also discussed the possibility of backporting the JDK7 >>>> javac filemanager back to OpenJDK 6, now that we have completed a number >>>> of >>>> significant bug fixes. ?However, this should now probably wait until >>>> after >>>> b18. >>>> >>>> >>> >>> Yes, I think the javac file manager fixes would be good for b19. >>> >>> -Joe >>> >>> >> >> I've pushed two of the approved fixes: >> >> JAXWS/JAXP ALT_DROPS_DIR sync: >> http://hg.openjdk.java.net/jdk6/jdk6/jaxws/rev/53012f905520 >> http://hg.openjdk.java.net/jdk6/jdk6/jaxp/rev/e69b78c54335 >> >> fastdebug directory fix: >> http://hg.openjdk.java.net/jdk6/jdk6/rev/3307d11b8026 >> >> but having an issue with jcheck and the X11 fix: >> >> remote: adding changesets >> remote: adding manifests >> remote: adding file changes >> remote: added 2 changesets with 1 changes to 1 files >> remote: >> remote: > Changeset: 240:318875d8173c >> remote: > Author: ? ?andrew >> remote: > Date: ? ? ?2009-11-09 06:17 >> remote: > >> remote: > 6897844: Fix broken build on newer versions of X11 (libXext >= >> 1.1.0) >> remote: > Summary: Recent changes to X11's header structure break the >> build >> remote: > Reviewed-by: prr, flar >> remote: > Contributed-by: Diego Petten? >> remote: >> remote: Invalid contributor attribution >> >> Does jcheck not like UTF-8? >> > > From a quick look at the source, yes, it seems jcheck only wants ASCII alpha > numeric characters for the contributed by names and addresses. > > In other news on b18, I've done some building and testing on the current > repo without the X11 fix above. ?With a different network and graphics > configuration than used by my published test results, the results look > mostly consist with the new tests usually passing: > > 0: summary.txt ?pass: 3,118; fail: 26 > 1: JTreport/text/summary.txt ?pass: 3,135; fail: 25; error: 2 > > 0 ? ? ?1 ? ? ?Test > --- ? ?fail ? com/sun/java/swing/plaf/nimbus/Test6741426.java > --- ? ?fail ? com/sun/java/swing/plaf/nimbus/Test6849805.java > pass ? fail ? com/sun/jdi/BadHandshakeTest.java > fail ? pass ? java/awt/Frame/DynamicLayout/DynamicLayout.java > fail ? pass ? java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java > fail ? pass > java/awt/Frame/ShownOffScreenOnWin98/ShownOffScreenOnWin98Test.java > fail ? pass > java/awt/Frame/UnfocusableMaximizedFrameResizablity/UnfocusableMaximizedFrameResizablity.java > --- ? ?pass ? java/awt/GraphicsDevice/CloneConfigsTest.java > fail ? pass ? java/awt/GridLayout/LayoutExtraGaps/LayoutExtraGaps.java > fail ? pass ? java/awt/Insets/CombinedTestApp1.java > fail ? pass > java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.html > fail ? pass > java/awt/KeyboardFocusmanager/TypeAhead/MenuItemActivatedTest/MenuItemActivatedTest.html > fail ? pass > java/awt/KeyboardFocusmanager/TypeAhead/SubMenuShowTest/SubMenuShowTest.html > pass ? fail > java/awt/Multiscreen/LocationRelativeToTest/LocationRelativeToTest.java > fail ? pass ? java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java > pass ? --- ? ?java/awt/Window/AlwaysOnTop/AlwaysOnTopEvenOfWindow.java > pass ? fail ? java/awt/Window/GrabSequence/GrabSequence.java > fail ? pass ? java/awt/event/KeyEvent/CorrectTime/CorrectTime.java > fail ? pass ? java/awt/grab/EmbeddedFrameTest1/EmbeddedFrameTest1.java > pass ? fail ? java/awt/print/PrinterJob/ExceptionTest.java > --- ? ?pass ? java/lang/ClassLoader/UninitializedParent.java > pass ? fail ? java/net/ipv6tests/TcpTest.java > pass ? fail ? java/nio/channels/SocketChannel/AdaptSocket.java > pass ? fail ? java/nio/channels/SocketChannel/LocalAddress.java > pass ? fail ? java/nio/channels/SocketChannel/Shutdown.java > pass ? fail ? java/util/logging/LoggingDeadlock2.java > --- ? ?pass ? javax/swing/JButton/6604281/bug6604281.java > fail ? pass ? javax/swing/JTextArea/Test6593649.java > --- ? ?pass ? javax/swing/Security/6657138/ComponentTest.java > --- ? ?pass ? javax/swing/Security/6657138/bug6657138.java > --- ? ?pass ? javax/swing/ToolTipManager/Test6657026.java > --- ? ?pass ? javax/swing/UIManager/Test6657026.java > --- ? ?pass ? javax/swing/plaf/basic/BasicSplitPaneUI/Test6657026.java > --- ? ?pass ? javax/swing/plaf/metal/MetalBorders/Test6657026.java > --- ? ?pass ? javax/swing/plaf/metal/MetalBumps/Test6657026.java > --- ? ?pass ? javax/swing/plaf/metal/MetalInternalFrameUI/Test6657026.java > --- ? ?pass ? javax/swing/plaf/metal/MetalSliderUI/Test6657026.java > pass ? error ?sun/java2d/OpenGL/GradientPaints.java > pass ? fail ? sun/rmi/transport/proxy/EagerHttpFallback.java > --- ? ?pass > sun/security/provider/certpath/DisabledAlgorithms/CPBuilder.java > --- ? ?pass > sun/security/provider/certpath/DisabledAlgorithms/CPValidatorEndEntity.java > --- ? ?pass > sun/security/provider/certpath/DisabledAlgorithms/CPValidatorIntermediate.java > --- ? ?pass > sun/security/provider/certpath/DisabledAlgorithms/CPValidatorTrustAnchor.java > pass ? error > ?sun/security/ssl/javax/net/ssl/NewAPIs/SessionTimeOutTests.java > --- ? ?pass ? sun/security/util/DerValue/BadValue.java > > 45 differences > > Those two Nimbus tests fail with compilation errors like this: > > test/com/sun/java/swing/plaf/nimbus/Test6741426.java:31: package > com.sun.java.swing.plaf.nimbus does not exist > import com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel; > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^ > test/com/sun/java/swing/plaf/nimbus/Test6741426.java:52: cannot find symbol > symbol ?: class NimbusLookAndFeel > location: class Test6741426 > ? ? ? UIManager.setLookAndFeel(new NimbusLookAndFeel()); > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^ > 2 errors > > > test/com/sun/java/swing/plaf/nimbus/Test6849805.java:38: package > javax.swing.plaf.nimbus does not exist > ? static class Minimbus extends javax.swing.plaf.nimbus.NimbusLookAndFeel { > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^ > test/com/sun/java/swing/plaf/nimbus/Test6849805.java:41: cannot find symbol > symbol ?: method getDerivedColor(java.awt.Color,java.awt.Color,float) > location: class Test6849805.Minimbus > ? ? ? ? ? Color r = getDerivedColor(c1, c2, f); > ? ? ? ? ? ? ? ? ? ? ^ > 2 errors > > > In the first case, "com.sun.java.swing" is referred to instead of > "com.sun.javax.swing" and in the second case the non-existent on OpenJDK 6 > javax.swing...nimbus is referenced. ?Changing both of these to > com.sun.javax.swing.plaf.nimbus doesn't cause the code to compile. ?I > haven't looked into this very deeply, but ignoring the symbol file doesn't > resolve the problem. > > Since nimbus is going into this build, I'd either like the tests be modified > to pass if that is possible or removed if it is infeasible to have them > pass. > > -Joe > Finally had a chance to look at this Nimbus issue, and it appears it is the symbol file that's to blame: $ /home/andrew/build/icedtea6-hg/bin/javac openjdk/jdk/test/com/sun/java/swing/plaf/nimbus/Test6741426.java openjdk/jdk/test/com/sun/java/swing/plaf/nimbus/Test6741426.java:31: package com.sun.java.swing.plaf.nimbus does not exist import com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel; ^ openjdk/jdk/test/com/sun/java/swing/plaf/nimbus/Test6741426.java:52: cannot find symbol symbol : class NimbusLookAndFeel location: class Test6741426 UIManager.setLookAndFeel(new NimbusLookAndFeel()); ^ 2 errors andrew at rivendell /mnt/builder/icedtea6-hg $ /home/andrew/build/icedtea6-hg/bin/javac -XDignore.symbol.file=true openjdk/jdk/test/com/sun/java/swing/plaf/nimbus/Test6741426.java andrew at rivendell /mnt/builder/icedtea6-hg $ I guess we need to add com.sun.java.swing.plaf.nimbus to the symbol file, but what exactly is the purpose of this in the first place? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Joe.Darcy at Sun.COM Thu Dec 24 07:49:05 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Thu, 24 Dec 2009 07:49:05 -0800 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <17c6771e0912240723o6acdc97fj7ae02521c1e1730a@mail.gmail.com> References: <4AF4B948.5070702@sun.com> <17c6771e0911071712n1ee39648tcda8605c9682230a@mail.gmail.com> <4AF61D76.8040805@sun.com> <4AF5510B.4080309@sun.com> <17c6771e0911090821ne68ac97nc7e3e50d889b7ce9@mail.gmail.com> <4AF8D443.6080704@sun.com> <17c6771e0912240723o6acdc97fj7ae02521c1e1730a@mail.gmail.com> Message-ID: <4B338D71.3030306@sun.com> Andrew John Hughes wrote: > 2009/11/10 Joseph D. Darcy : > >> Andrew John Hughes wrote: >> >>> 2009/11/7 Joseph D. Darcy : >>> >>> >>>> Jonathan Gibbons wrote: >>>> >>>> >>>>> Andrew John Hughes wrote: >>>>> >>>>> >>>>>> 2009/11/7 Joseph D. Darcy : >>>>>> >>>>>> >>>>>> >>>>>>> Hello. >>>>>>> >>>>>>> The latest batch of security fixes have been pushed into OpenJDK 6. >>>>>>> >>>>>>> Martin and Andrew, you're clear to push your other fixes back. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Thanks, I'll get onto that tomorrow or Monday. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Now that OpenJDK 6 has the latest security fixes, Andrew's backport of >>>>>>> Nimbus, and the new delivery model for jaxp and jaxws, that might be a >>>>>>> good >>>>>>> amount of change to be a new build, b18. >>>>>>> >>>>>>> Is there any other work that should go back into b18? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> I'd like to get a backport of >>>>>> http://hg.openjdk.java.net/jdk7/jdk7/rev/d6b08bdb9a54 in. It's a >>>>>> minor fix that Kelly found that gets rid of the superfluous -fastdebug >>>>>> build directory currently being produced by OpenJDK6 builds. >>>>>> >>>>>> Otherwise I think it's good to go. >>>>>> >>>>>> The list has been silent on the matter, but I discussed hs16 and >>>>>> OpenJDK6 with Dalibor on IRC and we agreed that it would be better to >>>>>> wait until this is more stable before bumping up OpenJDK6 to it. >>>>>> IcedTea is currently supporting it as a build option, but it isn't >>>>>> turned on by default. One advantage to hs16 going into OpenJDK6 is >>>>>> that the Zero assembler port changeset which was recently promoted >>>>>> into b75 could be backported. Otherwise, it needs a few things >>>>>> ripping out to work with hs14 (and then putting back when we do go to >>>>>> hs16). >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -Joe >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Thanks, >>>>>> >>>>>> >>>>>> >>>>> Joe and I have also discussed the possibility of backporting the JDK7 >>>>> javac filemanager back to OpenJDK 6, now that we have completed a number >>>>> of >>>>> significant bug fixes. However, this should now probably wait until >>>>> after >>>>> b18. >>>>> >>>>> >>>>> >>>> Yes, I think the javac file manager fixes would be good for b19. >>>> >>>> -Joe >>>> >>>> >>>> >>> I've pushed two of the approved fixes: >>> >>> JAXWS/JAXP ALT_DROPS_DIR sync: >>> http://hg.openjdk.java.net/jdk6/jdk6/jaxws/rev/53012f905520 >>> http://hg.openjdk.java.net/jdk6/jdk6/jaxp/rev/e69b78c54335 >>> >>> fastdebug directory fix: >>> http://hg.openjdk.java.net/jdk6/jdk6/rev/3307d11b8026 >>> >>> but having an issue with jcheck and the X11 fix: >>> >>> remote: adding changesets >>> remote: adding manifests >>> remote: adding file changes >>> remote: added 2 changesets with 1 changes to 1 files >>> remote: >>> remote: > Changeset: 240:318875d8173c >>> remote: > Author: andrew >>> remote: > Date: 2009-11-09 06:17 >>> remote: > >>> remote: > 6897844: Fix broken build on newer versions of X11 (libXext >= >>> 1.1.0) >>> remote: > Summary: Recent changes to X11's header structure break the >>> build >>> remote: > Reviewed-by: prr, flar >>> remote: > Contributed-by: Diego Petten? >>> remote: >>> remote: Invalid contributor attribution >>> >>> Does jcheck not like UTF-8? >>> >>> >> From a quick look at the source, yes, it seems jcheck only wants ASCII alpha >> numeric characters for the contributed by names and addresses. >> >> In other news on b18, I've done some building and testing on the current >> repo without the X11 fix above. With a different network and graphics >> configuration than used by my published test results, the results look >> mostly consist with the new tests usually passing: >> >> 0: summary.txt pass: 3,118; fail: 26 >> 1: JTreport/text/summary.txt pass: 3,135; fail: 25; error: 2 >> >> 0 1 Test >> --- fail com/sun/java/swing/plaf/nimbus/Test6741426.java >> --- fail com/sun/java/swing/plaf/nimbus/Test6849805.java >> pass fail com/sun/jdi/BadHandshakeTest.java >> fail pass java/awt/Frame/DynamicLayout/DynamicLayout.java >> fail pass java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java >> fail pass >> java/awt/Frame/ShownOffScreenOnWin98/ShownOffScreenOnWin98Test.java >> fail pass >> java/awt/Frame/UnfocusableMaximizedFrameResizablity/UnfocusableMaximizedFrameResizablity.java >> --- pass java/awt/GraphicsDevice/CloneConfigsTest.java >> fail pass java/awt/GridLayout/LayoutExtraGaps/LayoutExtraGaps.java >> fail pass java/awt/Insets/CombinedTestApp1.java >> fail pass >> java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.html >> fail pass >> java/awt/KeyboardFocusmanager/TypeAhead/MenuItemActivatedTest/MenuItemActivatedTest.html >> fail pass >> java/awt/KeyboardFocusmanager/TypeAhead/SubMenuShowTest/SubMenuShowTest.html >> pass fail >> java/awt/Multiscreen/LocationRelativeToTest/LocationRelativeToTest.java >> fail pass java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java >> pass --- java/awt/Window/AlwaysOnTop/AlwaysOnTopEvenOfWindow.java >> pass fail java/awt/Window/GrabSequence/GrabSequence.java >> fail pass java/awt/event/KeyEvent/CorrectTime/CorrectTime.java >> fail pass java/awt/grab/EmbeddedFrameTest1/EmbeddedFrameTest1.java >> pass fail java/awt/print/PrinterJob/ExceptionTest.java >> --- pass java/lang/ClassLoader/UninitializedParent.java >> pass fail java/net/ipv6tests/TcpTest.java >> pass fail java/nio/channels/SocketChannel/AdaptSocket.java >> pass fail java/nio/channels/SocketChannel/LocalAddress.java >> pass fail java/nio/channels/SocketChannel/Shutdown.java >> pass fail java/util/logging/LoggingDeadlock2.java >> --- pass javax/swing/JButton/6604281/bug6604281.java >> fail pass javax/swing/JTextArea/Test6593649.java >> --- pass javax/swing/Security/6657138/ComponentTest.java >> --- pass javax/swing/Security/6657138/bug6657138.java >> --- pass javax/swing/ToolTipManager/Test6657026.java >> --- pass javax/swing/UIManager/Test6657026.java >> --- pass javax/swing/plaf/basic/BasicSplitPaneUI/Test6657026.java >> --- pass javax/swing/plaf/metal/MetalBorders/Test6657026.java >> --- pass javax/swing/plaf/metal/MetalBumps/Test6657026.java >> --- pass javax/swing/plaf/metal/MetalInternalFrameUI/Test6657026.java >> --- pass javax/swing/plaf/metal/MetalSliderUI/Test6657026.java >> pass error sun/java2d/OpenGL/GradientPaints.java >> pass fail sun/rmi/transport/proxy/EagerHttpFallback.java >> --- pass >> sun/security/provider/certpath/DisabledAlgorithms/CPBuilder.java >> --- pass >> sun/security/provider/certpath/DisabledAlgorithms/CPValidatorEndEntity.java >> --- pass >> sun/security/provider/certpath/DisabledAlgorithms/CPValidatorIntermediate.java >> --- pass >> sun/security/provider/certpath/DisabledAlgorithms/CPValidatorTrustAnchor.java >> pass error >> sun/security/ssl/javax/net/ssl/NewAPIs/SessionTimeOutTests.java >> --- pass sun/security/util/DerValue/BadValue.java >> >> 45 differences >> >> Those two Nimbus tests fail with compilation errors like this: >> >> test/com/sun/java/swing/plaf/nimbus/Test6741426.java:31: package >> com.sun.java.swing.plaf.nimbus does not exist >> import com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel; >> ^ >> test/com/sun/java/swing/plaf/nimbus/Test6741426.java:52: cannot find symbol >> symbol : class NimbusLookAndFeel >> location: class Test6741426 >> UIManager.setLookAndFeel(new NimbusLookAndFeel()); >> ^ >> 2 errors >> >> >> test/com/sun/java/swing/plaf/nimbus/Test6849805.java:38: package >> javax.swing.plaf.nimbus does not exist >> static class Minimbus extends javax.swing.plaf.nimbus.NimbusLookAndFeel { >> ^ >> test/com/sun/java/swing/plaf/nimbus/Test6849805.java:41: cannot find symbol >> symbol : method getDerivedColor(java.awt.Color,java.awt.Color,float) >> location: class Test6849805.Minimbus >> Color r = getDerivedColor(c1, c2, f); >> ^ >> 2 errors >> >> >> In the first case, "com.sun.java.swing" is referred to instead of >> "com.sun.javax.swing" and in the second case the non-existent on OpenJDK 6 >> javax.swing...nimbus is referenced. Changing both of these to >> com.sun.javax.swing.plaf.nimbus doesn't cause the code to compile. I >> haven't looked into this very deeply, but ignoring the symbol file doesn't >> resolve the problem. >> >> Since nimbus is going into this build, I'd either like the tests be modified >> to pass if that is possible or removed if it is infeasible to have them >> pass. >> >> -Joe >> >> > > Finally had a chance to look at this Nimbus issue, and it appears it > is the symbol file that's to blame: > > $ /home/andrew/build/icedtea6-hg/bin/javac > openjdk/jdk/test/com/sun/java/swing/plaf/nimbus/Test6741426.java > openjdk/jdk/test/com/sun/java/swing/plaf/nimbus/Test6741426.java:31: > package com.sun.java.swing.plaf.nimbus does not exist > import com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel; > ^ > openjdk/jdk/test/com/sun/java/swing/plaf/nimbus/Test6741426.java:52: > cannot find symbol > symbol : class NimbusLookAndFeel > location: class Test6741426 > UIManager.setLookAndFeel(new NimbusLookAndFeel()); > ^ > 2 errors > andrew at rivendell /mnt/builder/icedtea6-hg $ > /home/andrew/build/icedtea6-hg/bin/javac -XDignore.symbol.file=true > openjdk/jdk/test/com/sun/java/swing/plaf/nimbus/Test6741426.java > andrew at rivendell /mnt/builder/icedtea6-hg $ > > I guess we need to add com.sun.java.swing.plaf.nimbus to the symbol > file, but what exactly is the purpose of this in the first place? > The symbol file is used to implement a proto module system in JDK 6 so that non-JDK programs get used to not being able to access JDK-internal implementation classes, like most of com.sun.*. Since the JDK regression tests are logically part of the JDK, they are justified in using the -XDignore.symbol.file=true option to get around the symbol file restrictions. Unless NimbusLookAndFeel should be a publicly usable class in OpenJDK 6, which I think is unlikely, the right solution here seems to be having the test use -XDignore.symbol.file=true in its @compile directive. -Joe From gnu_andrew at member.fsf.org Thu Dec 24 08:43:42 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 24 Dec 2009 16:43:42 +0000 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <4B338D71.3030306@sun.com> References: <4AF4B948.5070702@sun.com> <17c6771e0911071712n1ee39648tcda8605c9682230a@mail.gmail.com> <4AF61D76.8040805@sun.com> <4AF5510B.4080309@sun.com> <17c6771e0911090821ne68ac97nc7e3e50d889b7ce9@mail.gmail.com> <4AF8D443.6080704@sun.com> <17c6771e0912240723o6acdc97fj7ae02521c1e1730a@mail.gmail.com> <4B338D71.3030306@sun.com> Message-ID: <17c6771e0912240843g6d1918dah8472bb3f20449c7e@mail.gmail.com> 2009/12/24 Joseph D. Darcy : > Andrew John Hughes wrote: >> >> 2009/11/10 Joseph D. Darcy : >> >>> >>> Andrew John Hughes wrote: >>> >>>> >>>> 2009/11/7 Joseph D. Darcy : >>>> >>>> >>>>> >>>>> Jonathan Gibbons wrote: >>>>> >>>>> >>>>>> >>>>>> Andrew John Hughes wrote: >>>>>> >>>>>> >>>>>>> >>>>>>> 2009/11/7 Joseph D. Darcy : >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Hello. >>>>>>>> >>>>>>>> The latest batch of security fixes have been pushed into OpenJDK 6. >>>>>>>> >>>>>>>> Martin and Andrew, you're clear to push your other fixes back. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Thanks, I'll get onto that tomorrow or Monday. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Now that OpenJDK 6 has the latest security fixes, Andrew's backport >>>>>>>> of >>>>>>>> Nimbus, and the new delivery model for jaxp and jaxws, that might be >>>>>>>> a >>>>>>>> good >>>>>>>> amount of change to be a new build, b18. >>>>>>>> >>>>>>>> Is there any other work that should go back into b18? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> I'd like to get a backport of >>>>>>> http://hg.openjdk.java.net/jdk7/jdk7/rev/d6b08bdb9a54 in. ?It's a >>>>>>> minor fix that Kelly found that gets rid of the superfluous >>>>>>> -fastdebug >>>>>>> build directory currently being produced by OpenJDK6 builds. >>>>>>> >>>>>>> Otherwise I think it's good to go. >>>>>>> >>>>>>> The list has been silent on the matter, but I discussed hs16 and >>>>>>> OpenJDK6 with Dalibor on IRC and we agreed that it would be better to >>>>>>> wait until this is more stable before bumping up OpenJDK6 to it. >>>>>>> IcedTea is currently supporting it as a build option, but it isn't >>>>>>> turned on by default. ?One advantage to hs16 going into OpenJDK6 is >>>>>>> that the Zero assembler port changeset which was recently promoted >>>>>>> into b75 could be backported. ?Otherwise, it needs a few things >>>>>>> ripping out to work with hs14 (and then putting back when we do go to >>>>>>> hs16). >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> -Joe >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> Joe and I have also discussed the possibility of backporting the JDK7 >>>>>> javac filemanager back to OpenJDK 6, now that we have completed a >>>>>> number >>>>>> of >>>>>> significant bug fixes. ?However, this should now probably wait until >>>>>> after >>>>>> b18. >>>>>> >>>>>> >>>>>> >>>>> >>>>> Yes, I think the javac file manager fixes would be good for b19. >>>>> >>>>> -Joe >>>>> >>>>> >>>>> >>>> >>>> I've pushed two of the approved fixes: >>>> >>>> JAXWS/JAXP ALT_DROPS_DIR sync: >>>> http://hg.openjdk.java.net/jdk6/jdk6/jaxws/rev/53012f905520 >>>> http://hg.openjdk.java.net/jdk6/jdk6/jaxp/rev/e69b78c54335 >>>> >>>> fastdebug directory fix: >>>> http://hg.openjdk.java.net/jdk6/jdk6/rev/3307d11b8026 >>>> >>>> but having an issue with jcheck and the X11 fix: >>>> >>>> remote: adding changesets >>>> remote: adding manifests >>>> remote: adding file changes >>>> remote: added 2 changesets with 1 changes to 1 files >>>> remote: >>>> remote: > Changeset: 240:318875d8173c >>>> remote: > Author: ? ?andrew >>>> remote: > Date: ? ? ?2009-11-09 06:17 >>>> remote: > >>>> remote: > 6897844: Fix broken build on newer versions of X11 (libXext >= >>>> 1.1.0) >>>> remote: > Summary: Recent changes to X11's header structure break the >>>> build >>>> remote: > Reviewed-by: prr, flar >>>> remote: > Contributed-by: Diego Petten? >>>> remote: >>>> remote: Invalid contributor attribution >>>> >>>> Does jcheck not like UTF-8? >>>> >>>> >>> >>> From a quick look at the source, yes, it seems jcheck only wants ASCII >>> alpha >>> numeric characters for the contributed by names and addresses. >>> >>> In other news on b18, I've done some building and testing on the current >>> repo without the X11 fix above. ?With a different network and graphics >>> configuration than used by my published test results, the results look >>> mostly consist with the new tests usually passing: >>> >>> 0: summary.txt ?pass: 3,118; fail: 26 >>> 1: JTreport/text/summary.txt ?pass: 3,135; fail: 25; error: 2 >>> >>> 0 ? ? ?1 ? ? ?Test >>> --- ? ?fail ? com/sun/java/swing/plaf/nimbus/Test6741426.java >>> --- ? ?fail ? com/sun/java/swing/plaf/nimbus/Test6849805.java >>> pass ? fail ? com/sun/jdi/BadHandshakeTest.java >>> fail ? pass ? java/awt/Frame/DynamicLayout/DynamicLayout.java >>> fail ? pass >>> java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java >>> fail ? pass >>> java/awt/Frame/ShownOffScreenOnWin98/ShownOffScreenOnWin98Test.java >>> fail ? pass >>> >>> java/awt/Frame/UnfocusableMaximizedFrameResizablity/UnfocusableMaximizedFrameResizablity.java >>> --- ? ?pass ? java/awt/GraphicsDevice/CloneConfigsTest.java >>> fail ? pass ? java/awt/GridLayout/LayoutExtraGaps/LayoutExtraGaps.java >>> fail ? pass ? java/awt/Insets/CombinedTestApp1.java >>> fail ? pass >>> >>> java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.html >>> fail ? pass >>> >>> java/awt/KeyboardFocusmanager/TypeAhead/MenuItemActivatedTest/MenuItemActivatedTest.html >>> fail ? pass >>> >>> java/awt/KeyboardFocusmanager/TypeAhead/SubMenuShowTest/SubMenuShowTest.html >>> pass ? fail >>> java/awt/Multiscreen/LocationRelativeToTest/LocationRelativeToTest.java >>> fail ? pass ? java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java >>> pass ? --- ? ?java/awt/Window/AlwaysOnTop/AlwaysOnTopEvenOfWindow.java >>> pass ? fail ? java/awt/Window/GrabSequence/GrabSequence.java >>> fail ? pass ? java/awt/event/KeyEvent/CorrectTime/CorrectTime.java >>> fail ? pass ? java/awt/grab/EmbeddedFrameTest1/EmbeddedFrameTest1.java >>> pass ? fail ? java/awt/print/PrinterJob/ExceptionTest.java >>> --- ? ?pass ? java/lang/ClassLoader/UninitializedParent.java >>> pass ? fail ? java/net/ipv6tests/TcpTest.java >>> pass ? fail ? java/nio/channels/SocketChannel/AdaptSocket.java >>> pass ? fail ? java/nio/channels/SocketChannel/LocalAddress.java >>> pass ? fail ? java/nio/channels/SocketChannel/Shutdown.java >>> pass ? fail ? java/util/logging/LoggingDeadlock2.java >>> --- ? ?pass ? javax/swing/JButton/6604281/bug6604281.java >>> fail ? pass ? javax/swing/JTextArea/Test6593649.java >>> --- ? ?pass ? javax/swing/Security/6657138/ComponentTest.java >>> --- ? ?pass ? javax/swing/Security/6657138/bug6657138.java >>> --- ? ?pass ? javax/swing/ToolTipManager/Test6657026.java >>> --- ? ?pass ? javax/swing/UIManager/Test6657026.java >>> --- ? ?pass ? javax/swing/plaf/basic/BasicSplitPaneUI/Test6657026.java >>> --- ? ?pass ? javax/swing/plaf/metal/MetalBorders/Test6657026.java >>> --- ? ?pass ? javax/swing/plaf/metal/MetalBumps/Test6657026.java >>> --- ? ?pass >>> javax/swing/plaf/metal/MetalInternalFrameUI/Test6657026.java >>> --- ? ?pass ? javax/swing/plaf/metal/MetalSliderUI/Test6657026.java >>> pass ? error ?sun/java2d/OpenGL/GradientPaints.java >>> pass ? fail ? sun/rmi/transport/proxy/EagerHttpFallback.java >>> --- ? ?pass >>> sun/security/provider/certpath/DisabledAlgorithms/CPBuilder.java >>> --- ? ?pass >>> >>> sun/security/provider/certpath/DisabledAlgorithms/CPValidatorEndEntity.java >>> --- ? ?pass >>> >>> sun/security/provider/certpath/DisabledAlgorithms/CPValidatorIntermediate.java >>> --- ? ?pass >>> >>> sun/security/provider/certpath/DisabledAlgorithms/CPValidatorTrustAnchor.java >>> pass ? error >>> ?sun/security/ssl/javax/net/ssl/NewAPIs/SessionTimeOutTests.java >>> --- ? ?pass ? sun/security/util/DerValue/BadValue.java >>> >>> 45 differences >>> >>> Those two Nimbus tests fail with compilation errors like this: >>> >>> test/com/sun/java/swing/plaf/nimbus/Test6741426.java:31: package >>> com.sun.java.swing.plaf.nimbus does not exist >>> import com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel; >>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^ >>> test/com/sun/java/swing/plaf/nimbus/Test6741426.java:52: cannot find >>> symbol >>> symbol ?: class NimbusLookAndFeel >>> location: class Test6741426 >>> ? ? ?UIManager.setLookAndFeel(new NimbusLookAndFeel()); >>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^ >>> 2 errors >>> >>> >>> test/com/sun/java/swing/plaf/nimbus/Test6849805.java:38: package >>> javax.swing.plaf.nimbus does not exist >>> ?static class Minimbus extends javax.swing.plaf.nimbus.NimbusLookAndFeel >>> { >>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^ >>> test/com/sun/java/swing/plaf/nimbus/Test6849805.java:41: cannot find >>> symbol >>> symbol ?: method getDerivedColor(java.awt.Color,java.awt.Color,float) >>> location: class Test6849805.Minimbus >>> ? ? ? ? ?Color r = getDerivedColor(c1, c2, f); >>> ? ? ? ? ? ? ? ? ? ?^ >>> 2 errors >>> >>> >>> In the first case, "com.sun.java.swing" is referred to instead of >>> "com.sun.javax.swing" and in the second case the non-existent on OpenJDK >>> 6 >>> javax.swing...nimbus is referenced. ?Changing both of these to >>> com.sun.javax.swing.plaf.nimbus doesn't cause the code to compile. ?I >>> haven't looked into this very deeply, but ignoring the symbol file >>> doesn't >>> resolve the problem. >>> >>> Since nimbus is going into this build, I'd either like the tests be >>> modified >>> to pass if that is possible or removed if it is infeasible to have them >>> pass. >>> >>> -Joe >>> >>> >> >> Finally had a chance to look at this Nimbus issue, and it appears it >> is the symbol file that's to blame: >> >> $ /home/andrew/build/icedtea6-hg/bin/javac >> openjdk/jdk/test/com/sun/java/swing/plaf/nimbus/Test6741426.java >> openjdk/jdk/test/com/sun/java/swing/plaf/nimbus/Test6741426.java:31: >> package com.sun.java.swing.plaf.nimbus does not exist >> import com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel; >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^ >> openjdk/jdk/test/com/sun/java/swing/plaf/nimbus/Test6741426.java:52: >> cannot find symbol >> symbol ?: class NimbusLookAndFeel >> location: class Test6741426 >> ? ? ? ?UIManager.setLookAndFeel(new NimbusLookAndFeel()); >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^ >> 2 errors >> andrew at rivendell /mnt/builder/icedtea6-hg $ >> /home/andrew/build/icedtea6-hg/bin/javac -XDignore.symbol.file=true >> openjdk/jdk/test/com/sun/java/swing/plaf/nimbus/Test6741426.java >> andrew at rivendell /mnt/builder/icedtea6-hg $ >> >> I guess we need to add com.sun.java.swing.plaf.nimbus to the symbol >> file, but what exactly is the purpose of this in the first place? >> > > The symbol file is used to implement a proto module system in JDK 6 so that > non-JDK programs get used to not being able to access JDK-internal > implementation classes, like most of com.sun.*. ?Since the JDK regression > tests are logically part of the JDK, they are justified in using the > -XDignore.symbol.file=true option to get around the symbol file > restrictions. > It seems more like a hack which confuses people to me. It baffled me just now when I could see the NimbusLookAndFeel class was in rt.jar but javac wouldn't see it. Setting bootclasspath explicitly works too so the symbol file clearly only works if you rely on the default bootclasspath. I think in reality most people will get annoyed by it and then just set -XDignore.symbol.file=true to make their existing code work. I strongly dislike the use of these com.sun classes (they cause huge problems when using non-Sun implementations) but I don't think this helps. Sun code is just as much an offender; JAXWS should be independent but relies on com.sun.net.httpserver which is given an opt-out from the symbol scheme in NON_CORE_PKGS.gmk. I thought the idea was to produce a warning, not just make the class appear to be missing? > Unless NimbusLookAndFeel should be a publicly usable class in OpenJDK 6, > which I think is unlikely, the right solution here seems to be having the > test use -XDignore.symbol.file=true in its @compile directive. > The other com.sun.java.swing.plaf packages are excluded (see make/common/Release.gmk in the jdk) and presumably NimbusLookAndFeel needs to be available so it can be selected from code or extended. I would expect the tests to be indicative of the use of the code by users in this way. Note that it's a public javax.swing.plaf class in 7 so having it blocked in 6 contradicts that. http://cr.openjdk.java.net/~andrew/nimbus/webrev.04/jdk.patch makes both tests pass. Can I have a bug ID to push this? > -Joe > Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Joe.Darcy at Sun.COM Thu Dec 24 15:04:12 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Thu, 24 Dec 2009 15:04:12 -0800 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <17c6771e0912240843g6d1918dah8472bb3f20449c7e@mail.gmail.com> References: <4AF4B948.5070702@sun.com> <17c6771e0911071712n1ee39648tcda8605c9682230a@mail.gmail.com> <4AF61D76.8040805@sun.com> <4AF5510B.4080309@sun.com> <17c6771e0911090821ne68ac97nc7e3e50d889b7ce9@mail.gmail.com> <4AF8D443.6080704@sun.com> <17c6771e0912240723o6acdc97fj7ae02521c1e1730a@mail.gmail.com> <4B338D71.3030306@sun.com> <17c6771e0912240843g6d1918dah8472bb3f20449c7e@mail.gmail.com> Message-ID: <4B33F36C.1030005@sun.com> Andrew John Hughes wrote: > 2009/12/24 Joseph D. Darcy : > >> Andrew John Hughes wrote: >> >>> 2009/11/10 Joseph D. Darcy : >>> >>> >>>> Andrew John Hughes wrote: >>>> >>>> >>>>> 2009/11/7 Joseph D. Darcy : >>>>> >>>>> >>>>> >>>>>> Jonathan Gibbons wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Andrew John Hughes wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> 2009/11/7 Joseph D. Darcy : >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Hello. >>>>>>>>> >>>>>>>>> The latest batch of security fixes have been pushed into OpenJDK 6. >>>>>>>>> >>>>>>>>> Martin and Andrew, you're clear to push your other fixes back. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Thanks, I'll get onto that tomorrow or Monday. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Now that OpenJDK 6 has the latest security fixes, Andrew's backport >>>>>>>>> of >>>>>>>>> Nimbus, and the new delivery model for jaxp and jaxws, that might be >>>>>>>>> a >>>>>>>>> good >>>>>>>>> amount of change to be a new build, b18. >>>>>>>>> >>>>>>>>> Is there any other work that should go back into b18? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> I'd like to get a backport of >>>>>>>> http://hg.openjdk.java.net/jdk7/jdk7/rev/d6b08bdb9a54 in. It's a >>>>>>>> minor fix that Kelly found that gets rid of the superfluous >>>>>>>> -fastdebug >>>>>>>> build directory currently being produced by OpenJDK6 builds. >>>>>>>> >>>>>>>> Otherwise I think it's good to go. >>>>>>>> >>>>>>>> The list has been silent on the matter, but I discussed hs16 and >>>>>>>> OpenJDK6 with Dalibor on IRC and we agreed that it would be better to >>>>>>>> wait until this is more stable before bumping up OpenJDK6 to it. >>>>>>>> IcedTea is currently supporting it as a build option, but it isn't >>>>>>>> turned on by default. One advantage to hs16 going into OpenJDK6 is >>>>>>>> that the Zero assembler port changeset which was recently promoted >>>>>>>> into b75 could be backported. Otherwise, it needs a few things >>>>>>>> ripping out to work with hs14 (and then putting back when we do go to >>>>>>>> hs16). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -Joe >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Joe and I have also discussed the possibility of backporting the JDK7 >>>>>>> javac filemanager back to OpenJDK 6, now that we have completed a >>>>>>> number >>>>>>> of >>>>>>> significant bug fixes. However, this should now probably wait until >>>>>>> after >>>>>>> b18. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Yes, I think the javac file manager fixes would be good for b19. >>>>>> >>>>>> -Joe >>>>>> >>>>>> >>>>>> >>>>>> >>>>> I've pushed two of the approved fixes: >>>>> >>>>> JAXWS/JAXP ALT_DROPS_DIR sync: >>>>> http://hg.openjdk.java.net/jdk6/jdk6/jaxws/rev/53012f905520 >>>>> http://hg.openjdk.java.net/jdk6/jdk6/jaxp/rev/e69b78c54335 >>>>> >>>>> fastdebug directory fix: >>>>> http://hg.openjdk.java.net/jdk6/jdk6/rev/3307d11b8026 >>>>> >>>>> but having an issue with jcheck and the X11 fix: >>>>> >>>>> remote: adding changesets >>>>> remote: adding manifests >>>>> remote: adding file changes >>>>> remote: added 2 changesets with 1 changes to 1 files >>>>> remote: >>>>> remote: > Changeset: 240:318875d8173c >>>>> remote: > Author: andrew >>>>> remote: > Date: 2009-11-09 06:17 >>>>> remote: > >>>>> remote: > 6897844: Fix broken build on newer versions of X11 (libXext >= >>>>> 1.1.0) >>>>> remote: > Summary: Recent changes to X11's header structure break the >>>>> build >>>>> remote: > Reviewed-by: prr, flar >>>>> remote: > Contributed-by: Diego Petten? >>>>> remote: >>>>> remote: Invalid contributor attribution >>>>> >>>>> Does jcheck not like UTF-8? >>>>> >>>>> >>>>> >>>> From a quick look at the source, yes, it seems jcheck only wants ASCII >>>> alpha >>>> numeric characters for the contributed by names and addresses. >>>> >>>> In other news on b18, I've done some building and testing on the current >>>> repo without the X11 fix above. With a different network and graphics >>>> configuration than used by my published test results, the results look >>>> mostly consist with the new tests usually passing: >>>> >>>> 0: summary.txt pass: 3,118; fail: 26 >>>> 1: JTreport/text/summary.txt pass: 3,135; fail: 25; error: 2 >>>> >>>> 0 1 Test >>>> --- fail com/sun/java/swing/plaf/nimbus/Test6741426.java >>>> --- fail com/sun/java/swing/plaf/nimbus/Test6849805.java >>>> pass fail com/sun/jdi/BadHandshakeTest.java >>>> fail pass java/awt/Frame/DynamicLayout/DynamicLayout.java >>>> fail pass >>>> java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java >>>> fail pass >>>> java/awt/Frame/ShownOffScreenOnWin98/ShownOffScreenOnWin98Test.java >>>> fail pass >>>> >>>> java/awt/Frame/UnfocusableMaximizedFrameResizablity/UnfocusableMaximizedFrameResizablity.java >>>> --- pass java/awt/GraphicsDevice/CloneConfigsTest.java >>>> fail pass java/awt/GridLayout/LayoutExtraGaps/LayoutExtraGaps.java >>>> fail pass java/awt/Insets/CombinedTestApp1.java >>>> fail pass >>>> >>>> java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.html >>>> fail pass >>>> >>>> java/awt/KeyboardFocusmanager/TypeAhead/MenuItemActivatedTest/MenuItemActivatedTest.html >>>> fail pass >>>> >>>> java/awt/KeyboardFocusmanager/TypeAhead/SubMenuShowTest/SubMenuShowTest.html >>>> pass fail >>>> java/awt/Multiscreen/LocationRelativeToTest/LocationRelativeToTest.java >>>> fail pass java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java >>>> pass --- java/awt/Window/AlwaysOnTop/AlwaysOnTopEvenOfWindow.java >>>> pass fail java/awt/Window/GrabSequence/GrabSequence.java >>>> fail pass java/awt/event/KeyEvent/CorrectTime/CorrectTime.java >>>> fail pass java/awt/grab/EmbeddedFrameTest1/EmbeddedFrameTest1.java >>>> pass fail java/awt/print/PrinterJob/ExceptionTest.java >>>> --- pass java/lang/ClassLoader/UninitializedParent.java >>>> pass fail java/net/ipv6tests/TcpTest.java >>>> pass fail java/nio/channels/SocketChannel/AdaptSocket.java >>>> pass fail java/nio/channels/SocketChannel/LocalAddress.java >>>> pass fail java/nio/channels/SocketChannel/Shutdown.java >>>> pass fail java/util/logging/LoggingDeadlock2.java >>>> --- pass javax/swing/JButton/6604281/bug6604281.java >>>> fail pass javax/swing/JTextArea/Test6593649.java >>>> --- pass javax/swing/Security/6657138/ComponentTest.java >>>> --- pass javax/swing/Security/6657138/bug6657138.java >>>> --- pass javax/swing/ToolTipManager/Test6657026.java >>>> --- pass javax/swing/UIManager/Test6657026.java >>>> --- pass javax/swing/plaf/basic/BasicSplitPaneUI/Test6657026.java >>>> --- pass javax/swing/plaf/metal/MetalBorders/Test6657026.java >>>> --- pass javax/swing/plaf/metal/MetalBumps/Test6657026.java >>>> --- pass >>>> javax/swing/plaf/metal/MetalInternalFrameUI/Test6657026.java >>>> --- pass javax/swing/plaf/metal/MetalSliderUI/Test6657026.java >>>> pass error sun/java2d/OpenGL/GradientPaints.java >>>> pass fail sun/rmi/transport/proxy/EagerHttpFallback.java >>>> --- pass >>>> sun/security/provider/certpath/DisabledAlgorithms/CPBuilder.java >>>> --- pass >>>> >>>> sun/security/provider/certpath/DisabledAlgorithms/CPValidatorEndEntity.java >>>> --- pass >>>> >>>> sun/security/provider/certpath/DisabledAlgorithms/CPValidatorIntermediate.java >>>> --- pass >>>> >>>> sun/security/provider/certpath/DisabledAlgorithms/CPValidatorTrustAnchor.java >>>> pass error >>>> sun/security/ssl/javax/net/ssl/NewAPIs/SessionTimeOutTests.java >>>> --- pass sun/security/util/DerValue/BadValue.java >>>> >>>> 45 differences >>>> >>>> Those two Nimbus tests fail with compilation errors like this: >>>> >>>> test/com/sun/java/swing/plaf/nimbus/Test6741426.java:31: package >>>> com.sun.java.swing.plaf.nimbus does not exist >>>> import com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel; >>>> ^ >>>> test/com/sun/java/swing/plaf/nimbus/Test6741426.java:52: cannot find >>>> symbol >>>> symbol : class NimbusLookAndFeel >>>> location: class Test6741426 >>>> UIManager.setLookAndFeel(new NimbusLookAndFeel()); >>>> ^ >>>> 2 errors >>>> >>>> >>>> test/com/sun/java/swing/plaf/nimbus/Test6849805.java:38: package >>>> javax.swing.plaf.nimbus does not exist >>>> static class Minimbus extends javax.swing.plaf.nimbus.NimbusLookAndFeel >>>> { >>>> ^ >>>> test/com/sun/java/swing/plaf/nimbus/Test6849805.java:41: cannot find >>>> symbol >>>> symbol : method getDerivedColor(java.awt.Color,java.awt.Color,float) >>>> location: class Test6849805.Minimbus >>>> Color r = getDerivedColor(c1, c2, f); >>>> ^ >>>> 2 errors >>>> >>>> >>>> In the first case, "com.sun.java.swing" is referred to instead of >>>> "com.sun.javax.swing" and in the second case the non-existent on OpenJDK >>>> 6 >>>> javax.swing...nimbus is referenced. Changing both of these to >>>> com.sun.javax.swing.plaf.nimbus doesn't cause the code to compile. I >>>> haven't looked into this very deeply, but ignoring the symbol file >>>> doesn't >>>> resolve the problem. >>>> >>>> Since nimbus is going into this build, I'd either like the tests be >>>> modified >>>> to pass if that is possible or removed if it is infeasible to have them >>>> pass. >>>> >>>> -Joe >>>> >>>> >>>> >>> Finally had a chance to look at this Nimbus issue, and it appears it >>> is the symbol file that's to blame: >>> >>> $ /home/andrew/build/icedtea6-hg/bin/javac >>> openjdk/jdk/test/com/sun/java/swing/plaf/nimbus/Test6741426.java >>> openjdk/jdk/test/com/sun/java/swing/plaf/nimbus/Test6741426.java:31: >>> package com.sun.java.swing.plaf.nimbus does not exist >>> import com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel; >>> ^ >>> openjdk/jdk/test/com/sun/java/swing/plaf/nimbus/Test6741426.java:52: >>> cannot find symbol >>> symbol : class NimbusLookAndFeel >>> location: class Test6741426 >>> UIManager.setLookAndFeel(new NimbusLookAndFeel()); >>> ^ >>> 2 errors >>> andrew at rivendell /mnt/builder/icedtea6-hg $ >>> /home/andrew/build/icedtea6-hg/bin/javac -XDignore.symbol.file=true >>> openjdk/jdk/test/com/sun/java/swing/plaf/nimbus/Test6741426.java >>> andrew at rivendell /mnt/builder/icedtea6-hg $ >>> >>> I guess we need to add com.sun.java.swing.plaf.nimbus to the symbol >>> file, but what exactly is the purpose of this in the first place? >>> >>> >> The symbol file is used to implement a proto module system in JDK 6 so that >> non-JDK programs get used to not being able to access JDK-internal >> implementation classes, like most of com.sun.*. Since the JDK regression >> tests are logically part of the JDK, they are justified in using the >> -XDignore.symbol.file=true option to get around the symbol file >> restrictions. >> >> > > It seems more like a hack which confuses people to me. It baffled me > just now when I could see the NimbusLookAndFeel class was in rt.jar > but javac wouldn't see it. Setting bootclasspath explicitly works too > so the symbol file clearly only works if you rely on the default > bootclasspath. > That is correct; the default bootclasspath must be used. > I think in reality most people will get annoyed by it and then just > set -XDignore.symbol.file=true to make their existing code work. People weren't "supposed" to know about -XDignore.symbol.file=true, but word has gotten out. The old situation was problematic that bad behavior could occur without any warning or error from the system. > I > strongly dislike the use of these com.sun classes (they cause huge > problems when using non-Sun implementations) but I don't think this > helps. Sun code is just as much an offender; JAXWS should be > independent but relies on com.sun.net.httpserver which is given an > opt-out from the symbol scheme in NON_CORE_PKGS.gmk. > > I thought the idea was to produce a warning, not just make the class > appear to be missing? > There are multiple settings of the visibility knob for ct.sym, including not there at all. Classes added in JDK 6 that are not supposed to be generally used are not visible; legacy classes visible in JDK 5 or earlier are visible with a warning. > >> Unless NimbusLookAndFeel should be a publicly usable class in OpenJDK 6, >> which I think is unlikely, the right solution here seems to be having the >> test use -XDignore.symbol.file=true in its @compile directive. >> >> > > The other com.sun.java.swing.plaf packages are excluded (see > make/common/Release.gmk in the jdk) and presumably NimbusLookAndFeel > needs to be available so it can be selected from code or extended. I > would expect the tests to be indicative of the use of the code by > users in this way. Note that it's a public javax.swing.plaf class in > 7 so having it blocked in 6 contradicts that. > No it does not; com.sun.com.foo.java.swing.Foo != javax.swing.Foo. > http://cr.openjdk.java.net/~andrew/nimbus/webrev.04/jdk.patch makes > both tests pass. Can I have a bug ID to push this? > The com.sun.java.swing package in OpenJDK should have the same effective compile-time visibility as in Sun JDK. I'm going to start taking my vacation in earnest now so we can finish working through this issue early in 2010. Happy holidays, -Joe From gnu_andrew at member.fsf.org Fri Dec 25 04:49:44 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 25 Dec 2009 12:49:44 +0000 Subject: Security fixes are back; other fixes can go in. Time for build 18? In-Reply-To: <4B33F36C.1030005@sun.com> References: <4AF4B948.5070702@sun.com> <17c6771e0911071712n1ee39648tcda8605c9682230a@mail.gmail.com> <4AF61D76.8040805@sun.com> <4AF5510B.4080309@sun.com> <17c6771e0911090821ne68ac97nc7e3e50d889b7ce9@mail.gmail.com> <4AF8D443.6080704@sun.com> <17c6771e0912240723o6acdc97fj7ae02521c1e1730a@mail.gmail.com> <4B338D71.3030306@sun.com> <17c6771e0912240843g6d1918dah8472bb3f20449c7e@mail.gmail.com> <4B33F36C.1030005@sun.com> Message-ID: <17c6771e0912250449q537123ecl1fe4440f8b270d0a@mail.gmail.com> 2009/12/24 Joseph D. Darcy : > Andrew John Hughes wrote: >> >> 2009/12/24 Joseph D. Darcy : >> >>> >>> Andrew John Hughes wrote: >>> >>>> >>>> 2009/11/10 Joseph D. Darcy : >>>> >>>> >>>>> >>>>> Andrew John Hughes wrote: >>>>> >>>>> >>>>>> >>>>>> 2009/11/7 Joseph D. Darcy : >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Jonathan Gibbons wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Andrew John Hughes wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> 2009/11/7 Joseph D. Darcy : >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hello. >>>>>>>>>> >>>>>>>>>> The latest batch of security fixes have been pushed into OpenJDK >>>>>>>>>> 6. >>>>>>>>>> >>>>>>>>>> Martin and Andrew, you're clear to push your other fixes back. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, I'll get onto that tomorrow or Monday. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Now that OpenJDK 6 has the latest security fixes, Andrew's >>>>>>>>>> backport >>>>>>>>>> of >>>>>>>>>> Nimbus, and the new delivery model for jaxp and jaxws, that might >>>>>>>>>> be >>>>>>>>>> a >>>>>>>>>> good >>>>>>>>>> amount of change to be a new build, b18. >>>>>>>>>> >>>>>>>>>> Is there any other work that should go back into b18? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> I'd like to get a backport of >>>>>>>>> http://hg.openjdk.java.net/jdk7/jdk7/rev/d6b08bdb9a54 in. ?It's a >>>>>>>>> minor fix that Kelly found that gets rid of the superfluous >>>>>>>>> -fastdebug >>>>>>>>> build directory currently being produced by OpenJDK6 builds. >>>>>>>>> >>>>>>>>> Otherwise I think it's good to go. >>>>>>>>> >>>>>>>>> The list has been silent on the matter, but I discussed hs16 and >>>>>>>>> OpenJDK6 with Dalibor on IRC and we agreed that it would be better >>>>>>>>> to >>>>>>>>> wait until this is more stable before bumping up OpenJDK6 to it. >>>>>>>>> IcedTea is currently supporting it as a build option, but it isn't >>>>>>>>> turned on by default. ?One advantage to hs16 going into OpenJDK6 is >>>>>>>>> that the Zero assembler port changeset which was recently promoted >>>>>>>>> into b75 could be backported. ?Otherwise, it needs a few things >>>>>>>>> ripping out to work with hs14 (and then putting back when we do go >>>>>>>>> to >>>>>>>>> hs16). >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> -Joe >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Joe and I have also discussed the possibility of backporting the >>>>>>>> JDK7 >>>>>>>> javac filemanager back to OpenJDK 6, now that we have completed a >>>>>>>> number >>>>>>>> of >>>>>>>> significant bug fixes. ?However, this should now probably wait until >>>>>>>> after >>>>>>>> b18. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Yes, I think the javac file manager fixes would be good for b19. >>>>>>> >>>>>>> -Joe >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> I've pushed two of the approved fixes: >>>>>> >>>>>> JAXWS/JAXP ALT_DROPS_DIR sync: >>>>>> http://hg.openjdk.java.net/jdk6/jdk6/jaxws/rev/53012f905520 >>>>>> http://hg.openjdk.java.net/jdk6/jdk6/jaxp/rev/e69b78c54335 >>>>>> >>>>>> fastdebug directory fix: >>>>>> http://hg.openjdk.java.net/jdk6/jdk6/rev/3307d11b8026 >>>>>> >>>>>> but having an issue with jcheck and the X11 fix: >>>>>> >>>>>> remote: adding changesets >>>>>> remote: adding manifests >>>>>> remote: adding file changes >>>>>> remote: added 2 changesets with 1 changes to 1 files >>>>>> remote: >>>>>> remote: > Changeset: 240:318875d8173c >>>>>> remote: > Author: ? ?andrew >>>>>> remote: > Date: ? ? ?2009-11-09 06:17 >>>>>> remote: > >>>>>> remote: > 6897844: Fix broken build on newer versions of X11 (libXext >>>>>> >= >>>>>> 1.1.0) >>>>>> remote: > Summary: Recent changes to X11's header structure break the >>>>>> build >>>>>> remote: > Reviewed-by: prr, flar >>>>>> remote: > Contributed-by: Diego Petten? >>>>>> remote: >>>>>> remote: Invalid contributor attribution >>>>>> >>>>>> Does jcheck not like UTF-8? >>>>>> >>>>>> >>>>>> >>>>> >>>>> From a quick look at the source, yes, it seems jcheck only wants ASCII >>>>> alpha >>>>> numeric characters for the contributed by names and addresses. >>>>> >>>>> In other news on b18, I've done some building and testing on the >>>>> current >>>>> repo without the X11 fix above. ?With a different network and graphics >>>>> configuration than used by my published test results, the results look >>>>> mostly consist with the new tests usually passing: >>>>> >>>>> 0: summary.txt ?pass: 3,118; fail: 26 >>>>> 1: JTreport/text/summary.txt ?pass: 3,135; fail: 25; error: 2 >>>>> >>>>> 0 ? ? ?1 ? ? ?Test >>>>> --- ? ?fail ? com/sun/java/swing/plaf/nimbus/Test6741426.java >>>>> --- ? ?fail ? com/sun/java/swing/plaf/nimbus/Test6849805.java >>>>> pass ? fail ? com/sun/jdi/BadHandshakeTest.java >>>>> fail ? pass ? java/awt/Frame/DynamicLayout/DynamicLayout.java >>>>> fail ? pass >>>>> java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java >>>>> fail ? pass >>>>> java/awt/Frame/ShownOffScreenOnWin98/ShownOffScreenOnWin98Test.java >>>>> fail ? pass >>>>> >>>>> >>>>> java/awt/Frame/UnfocusableMaximizedFrameResizablity/UnfocusableMaximizedFrameResizablity.java >>>>> --- ? ?pass ? java/awt/GraphicsDevice/CloneConfigsTest.java >>>>> fail ? pass ? java/awt/GridLayout/LayoutExtraGaps/LayoutExtraGaps.java >>>>> fail ? pass ? java/awt/Insets/CombinedTestApp1.java >>>>> fail ? pass >>>>> >>>>> >>>>> java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.html >>>>> fail ? pass >>>>> >>>>> >>>>> java/awt/KeyboardFocusmanager/TypeAhead/MenuItemActivatedTest/MenuItemActivatedTest.html >>>>> fail ? pass >>>>> >>>>> >>>>> java/awt/KeyboardFocusmanager/TypeAhead/SubMenuShowTest/SubMenuShowTest.html >>>>> pass ? fail >>>>> java/awt/Multiscreen/LocationRelativeToTest/LocationRelativeToTest.java >>>>> fail ? pass ? java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java >>>>> pass ? --- ? ?java/awt/Window/AlwaysOnTop/AlwaysOnTopEvenOfWindow.java >>>>> pass ? fail ? java/awt/Window/GrabSequence/GrabSequence.java >>>>> fail ? pass ? java/awt/event/KeyEvent/CorrectTime/CorrectTime.java >>>>> fail ? pass ? java/awt/grab/EmbeddedFrameTest1/EmbeddedFrameTest1.java >>>>> pass ? fail ? java/awt/print/PrinterJob/ExceptionTest.java >>>>> --- ? ?pass ? java/lang/ClassLoader/UninitializedParent.java >>>>> pass ? fail ? java/net/ipv6tests/TcpTest.java >>>>> pass ? fail ? java/nio/channels/SocketChannel/AdaptSocket.java >>>>> pass ? fail ? java/nio/channels/SocketChannel/LocalAddress.java >>>>> pass ? fail ? java/nio/channels/SocketChannel/Shutdown.java >>>>> pass ? fail ? java/util/logging/LoggingDeadlock2.java >>>>> --- ? ?pass ? javax/swing/JButton/6604281/bug6604281.java >>>>> fail ? pass ? javax/swing/JTextArea/Test6593649.java >>>>> --- ? ?pass ? javax/swing/Security/6657138/ComponentTest.java >>>>> --- ? ?pass ? javax/swing/Security/6657138/bug6657138.java >>>>> --- ? ?pass ? javax/swing/ToolTipManager/Test6657026.java >>>>> --- ? ?pass ? javax/swing/UIManager/Test6657026.java >>>>> --- ? ?pass ? javax/swing/plaf/basic/BasicSplitPaneUI/Test6657026.java >>>>> --- ? ?pass ? javax/swing/plaf/metal/MetalBorders/Test6657026.java >>>>> --- ? ?pass ? javax/swing/plaf/metal/MetalBumps/Test6657026.java >>>>> --- ? ?pass >>>>> javax/swing/plaf/metal/MetalInternalFrameUI/Test6657026.java >>>>> --- ? ?pass ? javax/swing/plaf/metal/MetalSliderUI/Test6657026.java >>>>> pass ? error ?sun/java2d/OpenGL/GradientPaints.java >>>>> pass ? fail ? sun/rmi/transport/proxy/EagerHttpFallback.java >>>>> --- ? ?pass >>>>> sun/security/provider/certpath/DisabledAlgorithms/CPBuilder.java >>>>> --- ? ?pass >>>>> >>>>> >>>>> sun/security/provider/certpath/DisabledAlgorithms/CPValidatorEndEntity.java >>>>> --- ? ?pass >>>>> >>>>> >>>>> sun/security/provider/certpath/DisabledAlgorithms/CPValidatorIntermediate.java >>>>> --- ? ?pass >>>>> >>>>> >>>>> sun/security/provider/certpath/DisabledAlgorithms/CPValidatorTrustAnchor.java >>>>> pass ? error >>>>> ?sun/security/ssl/javax/net/ssl/NewAPIs/SessionTimeOutTests.java >>>>> --- ? ?pass ? sun/security/util/DerValue/BadValue.java >>>>> >>>>> 45 differences >>>>> >>>>> Those two Nimbus tests fail with compilation errors like this: >>>>> >>>>> test/com/sun/java/swing/plaf/nimbus/Test6741426.java:31: package >>>>> com.sun.java.swing.plaf.nimbus does not exist >>>>> import com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel; >>>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^ >>>>> test/com/sun/java/swing/plaf/nimbus/Test6741426.java:52: cannot find >>>>> symbol >>>>> symbol ?: class NimbusLookAndFeel >>>>> location: class Test6741426 >>>>> ? ? UIManager.setLookAndFeel(new NimbusLookAndFeel()); >>>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^ >>>>> 2 errors >>>>> >>>>> >>>>> test/com/sun/java/swing/plaf/nimbus/Test6849805.java:38: package >>>>> javax.swing.plaf.nimbus does not exist >>>>> ?static class Minimbus extends >>>>> javax.swing.plaf.nimbus.NimbusLookAndFeel >>>>> { >>>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^ >>>>> test/com/sun/java/swing/plaf/nimbus/Test6849805.java:41: cannot find >>>>> symbol >>>>> symbol ?: method getDerivedColor(java.awt.Color,java.awt.Color,float) >>>>> location: class Test6849805.Minimbus >>>>> ? ? ? ? Color r = getDerivedColor(c1, c2, f); >>>>> ? ? ? ? ? ? ? ? ? ^ >>>>> 2 errors >>>>> >>>>> >>>>> In the first case, "com.sun.java.swing" is referred to instead of >>>>> "com.sun.javax.swing" and in the second case the non-existent on >>>>> OpenJDK >>>>> 6 >>>>> javax.swing...nimbus is referenced. ?Changing both of these to >>>>> com.sun.javax.swing.plaf.nimbus doesn't cause the code to compile. ?I >>>>> haven't looked into this very deeply, but ignoring the symbol file >>>>> doesn't >>>>> resolve the problem. >>>>> >>>>> Since nimbus is going into this build, I'd either like the tests be >>>>> modified >>>>> to pass if that is possible or removed if it is infeasible to have them >>>>> pass. >>>>> >>>>> -Joe >>>>> >>>>> >>>>> >>>> >>>> Finally had a chance to look at this Nimbus issue, and it appears it >>>> is the symbol file that's to blame: >>>> >>>> $ /home/andrew/build/icedtea6-hg/bin/javac >>>> openjdk/jdk/test/com/sun/java/swing/plaf/nimbus/Test6741426.java >>>> openjdk/jdk/test/com/sun/java/swing/plaf/nimbus/Test6741426.java:31: >>>> package com.sun.java.swing.plaf.nimbus does not exist >>>> import com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel; >>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^ >>>> openjdk/jdk/test/com/sun/java/swing/plaf/nimbus/Test6741426.java:52: >>>> cannot find symbol >>>> symbol ?: class NimbusLookAndFeel >>>> location: class Test6741426 >>>> ? ? ? UIManager.setLookAndFeel(new NimbusLookAndFeel()); >>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^ >>>> 2 errors >>>> andrew at rivendell /mnt/builder/icedtea6-hg $ >>>> /home/andrew/build/icedtea6-hg/bin/javac -XDignore.symbol.file=true >>>> openjdk/jdk/test/com/sun/java/swing/plaf/nimbus/Test6741426.java >>>> andrew at rivendell /mnt/builder/icedtea6-hg $ >>>> >>>> I guess we need to add com.sun.java.swing.plaf.nimbus to the symbol >>>> file, but what exactly is the purpose of this in the first place? >>>> >>>> >>> >>> The symbol file is used to implement a proto module system in JDK 6 so >>> that >>> non-JDK programs get used to not being able to access JDK-internal >>> implementation classes, like most of com.sun.*. ?Since the JDK regression >>> tests are logically part of the JDK, they are justified in using the >>> -XDignore.symbol.file=true option to get around the symbol file >>> restrictions. >>> >>> >> >> It seems more like a hack which confuses people to me. ?It baffled me >> just now when I could see the NimbusLookAndFeel class was in rt.jar >> but javac wouldn't see it. ?Setting bootclasspath explicitly works too >> so the symbol file clearly only works if you rely on the default >> bootclasspath. >> > > That is correct; the default bootclasspath must be used. > >> I think in reality most people will get annoyed by it and then just >> set -XDignore.symbol.file=true to make their existing code work. > > People weren't "supposed" to know about ?-XDignore.symbol.file=true, but > word has gotten out. > > The old situation was problematic that bad behavior could occur without any > warning or error from the system. > >> I >> strongly dislike the use of these com.sun classes (they cause huge >> problems when using non-Sun implementations) but I don't think this >> helps. ?Sun code is just as much an offender; JAXWS should be >> independent but relies on com.sun.net.httpserver which is given an >> opt-out from the symbol scheme in NON_CORE_PKGS.gmk. >> >> I thought the idea was to produce a warning, not just make the class >> appear to be missing? >> > > There are multiple settings of the visibility knob for ct.sym, including not > there at all. ?Classes added in JDK 6 that are not supposed to be generally > used are not visible; legacy classes visible in JDK 5 or earlier are visible > with a warning. > >> >>> >>> Unless NimbusLookAndFeel should be a publicly usable class in OpenJDK 6, >>> which I think is unlikely, the right solution here seems to be having the >>> test use -XDignore.symbol.file=true in its @compile directive. >>> >>> >> >> The other com.sun.java.swing.plaf packages are excluded (see >> make/common/Release.gmk in the jdk) and presumably NimbusLookAndFeel >> needs to be available so it can be selected from code or extended. ?I >> would expect the tests to be indicative of the use of the code by >> users in this way. ?Note that it's a public javax.swing.plaf class in >> 7 so having it blocked in 6 contradicts that. >> > > No it does not; com.sun.com.foo.java.swing.Foo != javax.swing.Foo. > >> http://cr.openjdk.java.net/~andrew/nimbus/webrev.04/jdk.patch makes >> both tests pass. ?Can I have a bug ID to push this? >> > > The com.sun.java.swing package in OpenJDK should have the same effective > compile-time visibility as in Sun JDK. > I don't know what that is; does this mean com.sun.java.swing.plaf.nimbus is hidden in the proprietary JDK6? I don't mind either way, it just seems that the other plaf packages are visible. > I'm going to start taking my vacation in earnest now so we can finish > working through this issue early in 2010. > > Happy holidays, > > -Joe > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8