From Kelly.Ohair at Sun.COM Mon May 4 08:37:23 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 04 May 2009 08:37:23 -0700 Subject: OpenJDK6 Fedora 9 changes Message-ID: <49FF0BB3.8050709@sun.com> I'm sure IcedTea6 has the hotspot changes, and the hotspot changes will eventually be completely displaced when hotspot gets updated... But here are the Fedora 9 changes I made to OpenJDK6 to get it to build and also shutup about the ant version and stop looking for findbugs. http://cr.openjdk.java.net/~ohair/openjdk6-fedora9/webrev/ -kto From gnu_andrew at member.fsf.org Tue May 5 08:04:00 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 5 May 2009 16:04:00 +0100 Subject: OpenJDK6 Fedora 9 changes In-Reply-To: <49FF0BB3.8050709@sun.com> References: <49FF0BB3.8050709@sun.com> Message-ID: <17c6771e0905050804w4e96c475oefb0bea47d74aaef@mail.gmail.com> 2009/5/4 Kelly O'Hair : > > I'm sure IcedTea6 has the hotspot changes, and the hotspot > changes will eventually be completely displaced when hotspot > gets updated... ?But here are the Fedora 9 changes I made to > OpenJDK6 to get it to build and also shutup about the ant > version and stop looking for findbugs. > > http://cr.openjdk.java.net/~ohair/openjdk6-fedora9/webrev/ > > -kto > We do have most of these in IcedTea (I don't think we bother with the FindBugs warnings but I may be wrong). A lot of the stuff related to HotSpot is stuck in IcedTea, because we are working against hs14 and there still seems to be no progress in getting a stable HotSpot branch for hs14 and the use of this in 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 Dalibor.Topic at Sun.COM Tue May 5 11:30:47 2009 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Tue, 05 May 2009 11:30:47 -0700 Subject: OpenJDK6 Fedora 9 changes In-Reply-To: <49FF0BB3.8050709@sun.com> References: <49FF0BB3.8050709@sun.com> Message-ID: <4A0085D7.3010903@sun.com> Kelly O'Hair wrote: > > I'm sure IcedTea6 has the hotspot changes, and the hotspot > changes will eventually be completely displaced when hotspot > gets updated... But here are the Fedora 9 changes I made to > OpenJDK6 to get it to build and also shutup about the ant > version and stop looking for findbugs. > > http://cr.openjdk.java.net/~ohair/openjdk6-fedora9/webrev/ The build changes look good to me, Kelly. Thank you for backporting the HotSpot changes along the way, too! cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin H?ring From kelly.ohair at sun.com Tue May 5 20:44:51 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Wed, 06 May 2009 03:44:51 +0000 Subject: hg: jdk6/jdk6/corba: 6746424: Remove build dependency on findbugs and FINDBUGS_HOME Message-ID: <20090506034453.5D68CE09A@hg.openjdk.java.net> Changeset: 452dfe027c41 Author: ohair Date: 2009-05-05 16:58 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/corba/rev/452dfe027c41 6746424: Remove build dependency on findbugs and FINDBUGS_HOME Reviewed-by: robilad ! make/common/shared/Defs-utils.gmk From Anthony.Petrov at Sun.COM Wed May 6 05:59:59 2009 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Wed, 06 May 2009 16:59:59 +0400 Subject: Request for review: 6832386 Fix JTreg test: java/awt/Graphics/DrawImageBG/SystemBgColorTest.java Message-ID: <4A0189CF.2030109@sun.com> awt-dev: please review the fix for 6open and 7 at: http://cr.openjdk.java.net/~anthony/6open-1-systemExitNotNeeded-6832386.0/ and http://cr.openjdk.java.net/~anthony/7-10-systemExitNotNeeded-6832386.0/ (should admit the webrevs are quite identical :) ) The corresponding Bugzilla bug entry is at https://bugs.openjdk.java.net/show_bug.cgi?id=100033 jdk6-dev: what build number should the fix be targeted for? -- best regards, Anthony From Artem.Ananiev at Sun.COM Wed May 6 08:53:45 2009 From: Artem.Ananiev at Sun.COM (Artem Ananiev) Date: Wed, 06 May 2009 19:53:45 +0400 Subject: Request for review: 6832386 Fix JTreg test: java/awt/Graphics/DrawImageBG/SystemBgColorTest.java In-Reply-To: <4A0189CF.2030109@sun.com> References: <4A0189CF.2030109@sun.com> Message-ID: <4A01B289.7000403@sun.com> I personally don't see any problems with the fix. Thanks, Artem Anthony Petrov wrote: > awt-dev: please review the fix for 6open and 7 at: > http://cr.openjdk.java.net/~anthony/6open-1-systemExitNotNeeded-6832386.0/ > and > http://cr.openjdk.java.net/~anthony/7-10-systemExitNotNeeded-6832386.0/ > > (should admit the webrevs are quite identical :) ) > > The corresponding Bugzilla bug entry is at > https://bugs.openjdk.java.net/show_bug.cgi?id=100033 > > > jdk6-dev: what build number should the fix be targeted for? > > -- > best regards, > Anthony From Joe.Darcy at Sun.COM Wed May 6 09:21:19 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Wed, 06 May 2009 09:21:19 -0700 Subject: Request for review: 6832386 Fix JTreg test: java/awt/Graphics/DrawImageBG/SystemBgColorTest.java In-Reply-To: <4A0189CF.2030109@sun.com> References: <4A0189CF.2030109@sun.com> Message-ID: <4A01B8FF.5000501@sun.com> Anthony Petrov wrote: > awt-dev: please review the fix for 6open and 7 at: > http://cr.openjdk.java.net/~anthony/6open-1-systemExitNotNeeded-6832386.0/ > > and > http://cr.openjdk.java.net/~anthony/7-10-systemExitNotNeeded-6832386.0/ > > (should admit the webrevs are quite identical :) ) > > The corresponding Bugzilla bug entry is at > https://bugs.openjdk.java.net/show_bug.cgi?id=100033 > > > jdk6-dev: what build number should the fix be targeted for? > OpenJDK 6 is on Build 17. Thanks, -Joe From Kelly.Ohair at Sun.COM Wed May 6 09:36:12 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Wed, 06 May 2009 09:36:12 -0700 Subject: Request for review: 6832386 Fix JTreg test: java/awt/Graphics/DrawImageBG/SystemBgColorTest.java In-Reply-To: <4A0189CF.2030109@sun.com> References: <4A0189CF.2030109@sun.com> Message-ID: <4A01BC7C.2050204@sun.com> Looks fine to me. -kto Anthony Petrov wrote: > awt-dev: please review the fix for 6open and 7 at: > http://cr.openjdk.java.net/~anthony/6open-1-systemExitNotNeeded-6832386.0/ > and > http://cr.openjdk.java.net/~anthony/7-10-systemExitNotNeeded-6832386.0/ > > (should admit the webrevs are quite identical :) ) > > The corresponding Bugzilla bug entry is at > https://bugs.openjdk.java.net/show_bug.cgi?id=100033 > > > jdk6-dev: what build number should the fix be targeted for? > > -- > best regards, > Anthony From david.katleman at sun.com Wed May 6 10:50:43 2009 From: david.katleman at sun.com (david.katleman at sun.com) Date: Wed, 06 May 2009 17:50:43 +0000 Subject: hg: jdk6/jdk6: 7 new changesets Message-ID: <20090506175044.11CC5E210@hg.openjdk.java.net> Changeset: 9c1855604249 Author: xdono Date: 2009-05-05 18:59 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/rev/9c1855604249 Added tag jdk6-b16 for changeset a78885a02070 ! .hgtags Changeset: fc236a5a08b5 Author: xdono Date: 2009-05-05 21:21 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/rev/fc236a5a08b5 Added tag jdk6-b16 for changeset 9c1855604249 ! .hgtags Changeset: 20298c2d6e0a Author: xdono Date: 2009-05-05 21:21 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/rev/20298c2d6e0a Added tag jdk6-b16 for changeset fc236a5a08b5 ! .hgtags Changeset: 82d0520aab79 Author: xdono Date: 2009-05-05 21:21 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/rev/82d0520aab79 Added tag jdk6-b16 for changeset 20298c2d6e0a ! .hgtags Changeset: a94cac60d59a Author: xdono Date: 2009-05-05 21:21 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/rev/a94cac60d59a Added tag jdk6-b16 for changeset 82d0520aab79 ! .hgtags Changeset: 464e457062ac Author: xdono Date: 2009-05-05 21:21 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/rev/464e457062ac Added tag jdk6-b16 for changeset a94cac60d59a ! .hgtags Changeset: a8349e210031 Author: xdono Date: 2009-05-05 21:21 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/rev/a8349e210031 Added tag jdk6-b16 for changeset 464e457062ac ! .hgtags From david.katleman at sun.com Wed May 6 11:01:24 2009 From: david.katleman at sun.com (david.katleman at sun.com) Date: Wed, 06 May 2009 18:01:24 +0000 Subject: hg: jdk6/jdk6/hotspot: Added tag jdk6-b16 for changeset 2e1fb22869c0 Message-ID: <20090506180127.65774E24F@hg.openjdk.java.net> Changeset: a9a44fcf704c Author: xdono Date: 2009-05-05 21:31 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/a9a44fcf704c Added tag jdk6-b16 for changeset 2e1fb22869c0 ! .hgtags From david.katleman at sun.com Wed May 6 11:08:43 2009 From: david.katleman at sun.com (david.katleman at sun.com) Date: Wed, 06 May 2009 18:08:43 +0000 Subject: hg: jdk6/jdk6/jaxp: Added tag jdk6-b16 for changeset b974a2a72ff1 Message-ID: <20090506180845.AC33CE255@hg.openjdk.java.net> Changeset: 3117b0251ad7 Author: xdono Date: 2009-05-05 21:31 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/jaxp/rev/3117b0251ad7 Added tag jdk6-b16 for changeset b974a2a72ff1 ! .hgtags From david.katleman at sun.com Wed May 6 11:12:39 2009 From: david.katleman at sun.com (david.katleman at sun.com) Date: Wed, 06 May 2009 18:12:39 +0000 Subject: hg: jdk6/jdk6/jaxws: Added tag jdk6-b16 for changeset dcd5e14744cf Message-ID: <20090506181241.B8DB2E25C@hg.openjdk.java.net> Changeset: 51f92de5b10c Author: xdono Date: 2009-05-05 21:31 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/jaxws/rev/51f92de5b10c Added tag jdk6-b16 for changeset dcd5e14744cf ! .hgtags From david.katleman at sun.com Wed May 6 11:16:59 2009 From: david.katleman at sun.com (david.katleman at sun.com) Date: Wed, 06 May 2009 18:16:59 +0000 Subject: hg: jdk6/jdk6/langtools: Added tag jdk6-b16 for changeset 1fe711e6bce6 Message-ID: <20090506181702.27155E265@hg.openjdk.java.net> Changeset: b4bc7fcaab3e Author: xdono Date: 2009-05-05 21:31 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/langtools/rev/b4bc7fcaab3e Added tag jdk6-b16 for changeset 1fe711e6bce6 ! .hgtags From david.katleman at sun.com Wed May 6 12:48:14 2009 From: david.katleman at sun.com (david.katleman at sun.com) Date: Wed, 06 May 2009 19:48:14 +0000 Subject: hg: jdk6/jdk6/jdk: 2 new changesets Message-ID: <20090506194846.A9687E2E8@hg.openjdk.java.net> Changeset: 0eb682de0f20 Author: xdono Date: 2009-05-05 21:31 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/0eb682de0f20 Added tag jdk6-b16 for changeset 536cbf2d9d0e ! .hgtags Changeset: 150ff38dab78 Author: katleman Date: 2009-05-06 12:34 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/150ff38dab78 Merge From kelly.ohair at sun.com Wed May 6 13:17:37 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Wed, 06 May 2009 20:17:37 +0000 Subject: hg: jdk6/jdk6/jaxp: 6831225: Upgrade JPRT jobs to use newer Linux 2.6 (e.g. Fedora 9) Message-ID: <20090506201740.4C6DEE30D@hg.openjdk.java.net> Changeset: c8cc3d6bedb3 Author: ohair Date: 2009-05-06 12:02 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/jaxp/rev/c8cc3d6bedb3 6831225: Upgrade JPRT jobs to use newer Linux 2.6 (e.g. Fedora 9) Reviewed-by: tbell ! make/jprt.properties From kelly.ohair at sun.com Wed May 6 13:28:21 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Wed, 06 May 2009 20:28:21 +0000 Subject: hg: jdk6/jdk6/jaxws: 6831225: Upgrade JPRT jobs to use newer Linux 2.6 (e.g. Fedora 9) Message-ID: <20090506202823.71B96E317@hg.openjdk.java.net> Changeset: 18aa9b2d3295 Author: ohair Date: 2009-05-06 12:03 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/jaxws/rev/18aa9b2d3295 6831225: Upgrade JPRT jobs to use newer Linux 2.6 (e.g. Fedora 9) Reviewed-by: tbell ! make/jprt.properties From kelly.ohair at sun.com Wed May 6 13:40:46 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Wed, 06 May 2009 20:40:46 +0000 Subject: hg: jdk6/jdk6/langtools: 6831225: Upgrade JPRT jobs to use newer Linux 2.6 (e.g. Fedora 9) Message-ID: <20090506204049.56417E340@hg.openjdk.java.net> Changeset: 9820754525dd Author: ohair Date: 2009-05-06 12:01 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/langtools/rev/9820754525dd 6831225: Upgrade JPRT jobs to use newer Linux 2.6 (e.g. Fedora 9) Reviewed-by: tbell ! make/jprt.properties From kelly.ohair at sun.com Wed May 6 17:28:21 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Thu, 07 May 2009 00:28:21 +0000 Subject: hg: jdk6/jdk6/corba: 6831225: Upgrade JPRT jobs to use newer Linux 2.6 (e.g. Fedora 9) Message-ID: <20090507002823.8474EE39F@hg.openjdk.java.net> Changeset: b43c38e9b64b Author: ohair Date: 2009-05-06 13:05 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/corba/rev/b43c38e9b64b 6831225: Upgrade JPRT jobs to use newer Linux 2.6 (e.g. Fedora 9) Reviewed-by: tbell ! make/jprt.properties From dalibor.topic at sun.com Thu May 7 00:37:02 2009 From: dalibor.topic at sun.com (dalibor.topic at sun.com) Date: Thu, 07 May 2009 07:37:02 +0000 Subject: hg: jdk6/jdk6/corba: Added tag jdk6-b16 for changeset 04ef8357f30e Message-ID: <20090507073704.515D1E408@hg.openjdk.java.net> Changeset: f05913eb2474 Author: robilad Date: 2009-05-07 01:27 +0200 URL: http://hg.openjdk.java.net/jdk6/jdk6/corba/rev/f05913eb2474 Added tag jdk6-b16 for changeset 04ef8357f30e ! .hgtags From Dalibor.Topic at Sun.COM Thu May 7 01:57:57 2009 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Thu, 07 May 2009 01:57:57 -0700 Subject: hg: jdk6/jdk6/corba: 6746424: Remove build dependency on findbugs and FINDBUGS_HOME In-Reply-To: <20090506034453.5D68CE09A@hg.openjdk.java.net> References: <20090506034453.5D68CE09A@hg.openjdk.java.net> Message-ID: <4A02A295.4040507@sun.com> Kelly.Ohair at Sun.COM wrote: > Changeset: 452dfe027c41 > Author: ohair > Date: 2009-05-05 16:58 -0700 > URL: http://hg.openjdk.java.net/jdk6/jdk6/corba/rev/452dfe027c41 > > 6746424: Remove build dependency on findbugs and FINDBUGS_HOME > Reviewed-by: robilad > > ! make/common/shared/Defs-utils.gmk > Hi Kelly, the corba change works fine, ant is detected now. There were further build changes in the webrev for other trees, and it doesn't seem that those were pushed: jdk/make/common/Sanity.gmk jdk/make/common/shared/Defs-utils.gmk jdk/make/common/shared/Sanity-Settings.gmk jdk/make/common/shared/Sanity.gmk cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin H?ring From gnu_andrew at member.fsf.org Thu May 7 03:56:12 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 7 May 2009 11:56:12 +0100 Subject: hg: jdk6/jdk6/corba: 6746424: Remove build dependency on findbugs and FINDBUGS_HOME In-Reply-To: <20090506034453.5D68CE09A@hg.openjdk.java.net> References: <20090506034453.5D68CE09A@hg.openjdk.java.net> Message-ID: <17c6771e0905070356m4274d181j8bdb89a196e1028f@mail.gmail.com> 2009/5/6 : > Changeset: 452dfe027c41 > Author: ? ?ohair > Date: ? ? ?2009-05-05 16:58 -0700 > URL: ? ? ? http://hg.openjdk.java.net/jdk6/jdk6/corba/rev/452dfe027c41 > > 6746424: Remove build dependency on findbugs and FINDBUGS_HOME > Reviewed-by: robilad > > ! make/common/shared/Defs-utils.gmk > > Why the removal of the lines regarding Ant? This doesn't seem to be mentioned in this bug. Note that last time I looked, you could just run FindBugs directly from its website via jaxws and that worked fine on GNU Classpath using IcedTea's jaxws implementation. -- 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 anthony.petrov at sun.com Thu May 7 05:31:03 2009 From: anthony.petrov at sun.com (anthony.petrov at sun.com) Date: Thu, 07 May 2009 12:31:03 +0000 Subject: hg: jdk6/jdk6/jdk: 6832386: Fix JTreg test: java/awt/Graphics/DrawImageBG/SystemBgColorTest.java Message-ID: <20090507123118.26751E462@hg.openjdk.java.net> Changeset: 1da40f56a3a9 Author: anthony Date: 2009-05-07 16:27 +0400 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/1da40f56a3a9 6832386: Fix JTreg test: java/awt/Graphics/DrawImageBG/SystemBgColorTest.java Summary: Removed unneeded System.exit(0) call. Reviewed-by: art, ohair, anthony Contributed-by: Omair Majid ! test/java/awt/Graphics/DrawImageBG/SystemBgColorTest.java From Anthony.Petrov at Sun.COM Thu May 7 05:49:48 2009 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Thu, 07 May 2009 16:49:48 +0400 Subject: Request for review: 6832386 Fix JTreg test: java/awt/Graphics/DrawImageBG/SystemBgColorTest.java In-Reply-To: <4A01B289.7000403@sun.com> References: <4A0189CF.2030109@sun.com> <4A01B289.7000403@sun.com> Message-ID: <4A02D8EC.3070405@sun.com> Thanks for the approval and information. The fix has just been pushed to the OpenJDK 6 repository. It's going to be pushed to JDK7 as soon as M3 freeze is complete. -- best regards, Anthony On 05/06/2009 07:53 PM, Artem Ananiev wrote: > I personally don't see any problems with the fix. On 05/06/2009 08:36 PM, Kelly O'Hair wrote: > Looks fine to me. On 05/06/2009 08:21 PM, Joseph D. Darcy wrote: > OpenJDK 6 is on Build 17. From Kelly.Ohair at Sun.COM Thu May 7 09:03:20 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Thu, 07 May 2009 09:03:20 -0700 Subject: hg: jdk6/jdk6/corba: 6746424: Remove build dependency on findbugs and FINDBUGS_HOME In-Reply-To: <17c6771e0905070356m4274d181j8bdb89a196e1028f@mail.gmail.com> References: <20090506034453.5D68CE09A@hg.openjdk.java.net> <17c6771e0905070356m4274d181j8bdb89a196e1028f@mail.gmail.com> Message-ID: <4A030648.9090702@sun.com> Andrew John Hughes wrote: > 2009/5/6 : >> Changeset: 452dfe027c41 >> Author: ohair >> Date: 2009-05-05 16:58 -0700 >> URL: http://hg.openjdk.java.net/jdk6/jdk6/corba/rev/452dfe027c41 >> >> 6746424: Remove build dependency on findbugs and FINDBUGS_HOME >> Reviewed-by: robilad >> >> ! make/common/shared/Defs-utils.gmk >> >> > > Why the removal of the lines regarding Ant? This doesn't seem to be > mentioned in this bug. The corba builds never used ant, this was just carry over from these files being copied from the jdk repository. Ultimately these makefiles in corba will go away, or the whole thing will change. So these lines being deleted in corba is just clean up. > > Note that last time I looked, you could just run FindBugs directly > from its website via jaxws and that worked fine on GNU Classpath using > IcedTea's jaxws implementation. The removal of findbugs from the makefile and the build dependencies is just a build simplification issue. Initially I had hoped that running findbugs during the build would be just part of the build, but it just isn't practical. It takes too long to run on every build. Don't get me wrong, I love findbugs, and want to use it regularly, it just doesn't make sense to burden the build system with it. I need a better way to get it run regularly, maybe with a separate continuous job run on a regular basis, separate from the building. -kto From Kelly.Ohair at Sun.COM Thu May 7 09:14:54 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Thu, 07 May 2009 09:14:54 -0700 Subject: hg: jdk6/jdk6/corba: 6746424: Remove build dependency on findbugs and FINDBUGS_HOME In-Reply-To: <4A02A295.4040507@sun.com> References: <20090506034453.5D68CE09A@hg.openjdk.java.net> <4A02A295.4040507@sun.com> Message-ID: <4A0308FE.1000309@sun.com> I'm having problems doing the push, some of my machines can't seem to access the servers.... I'll push soon... -kto Dalibor Topic wrote: > Kelly.Ohair at Sun.COM wrote: >> Changeset: 452dfe027c41 >> Author: ohair >> Date: 2009-05-05 16:58 -0700 >> URL: http://hg.openjdk.java.net/jdk6/jdk6/corba/rev/452dfe027c41 >> >> 6746424: Remove build dependency on findbugs and FINDBUGS_HOME >> Reviewed-by: robilad >> >> ! make/common/shared/Defs-utils.gmk >> > > Hi Kelly, > > the corba change works fine, ant is detected now. There were > further build changes in the webrev for other trees, and it doesn't > seem that those were pushed: > > jdk/make/common/Sanity.gmk > jdk/make/common/shared/Defs-utils.gmk > jdk/make/common/shared/Sanity-Settings.gmk > jdk/make/common/shared/Sanity.gmk > > cheers, > dalibor topic > From gnu_andrew at member.fsf.org Thu May 7 09:16:00 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 7 May 2009 17:16:00 +0100 Subject: hg: jdk6/jdk6/corba: 6746424: Remove build dependency on findbugs and FINDBUGS_HOME In-Reply-To: <4A030648.9090702@sun.com> References: <20090506034453.5D68CE09A@hg.openjdk.java.net> <17c6771e0905070356m4274d181j8bdb89a196e1028f@mail.gmail.com> <4A030648.9090702@sun.com> Message-ID: <17c6771e0905070916g29368a5apb4c0c77ade85e53d@mail.gmail.com> 2009/5/7 Kelly O'Hair : > > Andrew John Hughes wrote: >> >> 2009/5/6 ?: >>> >>> Changeset: 452dfe027c41 >>> Author: ? ?ohair >>> Date: ? ? ?2009-05-05 16:58 -0700 >>> URL: ? ? ? http://hg.openjdk.java.net/jdk6/jdk6/corba/rev/452dfe027c41 >>> >>> 6746424: Remove build dependency on findbugs and FINDBUGS_HOME >>> Reviewed-by: robilad >>> >>> ! make/common/shared/Defs-utils.gmk >>> >>> >> >> Why the removal of the lines regarding Ant? This doesn't seem to be >> mentioned in this bug. > > The corba builds never used ant, this was just carry over from these files > being copied from the jdk repository. > Ultimately these makefiles in corba will go away, or the whole thing > will change. So these lines being deleted in corba is just clean up. > Seeing the CORBA build cleanup would be very nice :) At least we got rid of the whole Scheme dependency nonsense. However, if these makefiles going away means replacing them with an Ant build, then that sounds even worse... >> >> Note that last time I looked, you could just run FindBugs directly >> from its website via jaxws and that worked fine on GNU Classpath using >> IcedTea's jaxws implementation. > > The removal of findbugs from the makefile and the build dependencies > is just a build simplification issue. > Initially I had hoped that running findbugs during the build would be > just part of the build, but it just isn't practical. It takes too long > to run on every build. > > Don't get me wrong, I love findbugs, and want to use it regularly, it > just doesn't make sense to burden the build system with it. > I need a better way to get it run regularly, maybe with a separate > continuous job run on a regular basis, separate from the building. > I agree; the build is already long enough. It's even longer if you also run the JTReg and Mauve tests as I believe the distros do. It's really the wrong place for FindBugs IMO anyway; it works best as a motivation to clean up a particular bit of code, spotting bugs you wouldn't otherwise notice on long forgotten bits of the tree. Having it nag every time you build for a completely unrelated reason is enough to probably drive people insane ;) Plus, there's probably people who build OpenJDK with no intention of going into the code to fix such bugs (or who even have a clue what they mean for that matter). On the contrary, having it run regularly as you suggest AND posting the results publicly would be a great motivation for hackers to get involved and fix some low-hanging fruit. > -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 kelly.ohair at sun.com Thu May 7 09:21:20 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Thu, 07 May 2009 16:21:20 +0000 Subject: hg: jdk6/jdk6/jdk: 4 new changesets Message-ID: <20090507162220.8B5B5E4B3@hg.openjdk.java.net> Changeset: 6376a28ce5be Author: ohair Date: 2009-05-05 17:01 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/6376a28ce5be 6746424: Remove build dependency on findbugs and FINDBUGS_HOME Reviewed-by: robilad ! make/common/Sanity.gmk ! make/common/shared/Defs-utils.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk Changeset: ab216ebbb28d Author: ohair Date: 2009-05-06 13:07 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/ab216ebbb28d Merge Changeset: 458656fc0382 Author: ohair Date: 2009-05-06 13:07 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/458656fc0382 6831225: Upgrade JPRT jobs to use newer Linux 2.6 (e.g. Fedora 9) Reviewed-by: tbell ! make/jprt.properties Changeset: e0ab6e5ef9eb Author: ohair Date: 2009-05-07 09:15 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/e0ab6e5ef9eb Merge From guanxia.zhuang at sycamorenet.com Thu May 7 19:03:40 2009 From: guanxia.zhuang at sycamorenet.com (Zhuang, Guanxia (Robin)) Date: Thu, 7 May 2009 22:03:40 -0400 Subject: a bug of JDK 1.6.0_11 ? Message-ID: Hi folks I am trying to launch an application with java web start, but it fails. It seams that it is a bug of jdk 1.6.0_11 and afterwards, but 1.6.0_07 works ok. Test Environment: bash-3.00$ uname -a SunOS himalayashan 5.10 Generic_118833-17 sun4u sparc SUNW,A70 bash-3.00$ which java /opt/sycamore/java/bin/java bash-3.00$ java -version java version "1.6.0_11" Java(TM) SE Runtime Environment (build 1.6.0_11-b03) Java HotSpot(TM) Client VM (build 11.0-b16, mixed mode, sharing) bash-3.00$ javaws -verbose http://172.21.1.15/demo.jnlp Java(TM) Web Start 1.6.0_11 Launching: /opt/sycamore/java/bin/java /opt/sycamore/java/bin/java -Xbootclasspath/a:/opt/sycamore/java/lib/javaws.jar:/opt/sycamore/java/lib/deploy.jar -classpath /opt/sycamore/java/lib/deploy.jar -Djava.security.policy=file:/opt/sycamore/java/lib/security/javaws.policy -DtrustProxy=true -Xverify:remote -Djnlpx.home=/opt/sycamore/java/bin -Djnlpx.remove=false -Djnlpx.splashport=57758 -Djnlpx.jvm=/opt/sycamore/java/bin/java com.sun.javaws.Main http://172.21.1.15/demo.jnlp Exception is throwed: NOTE: * if the version is 1.6.0_07 or lower, no issue, but for 1.6.0_11 and 1.6.0_12, the issue exists. * If the JRE is not installed in /opt/sycamore/java, no problem. But if the path end with java, it does not work, another example is?? /opt/java. I look at the code, from 1.6.0_11, JDK assume that jre should not be installed in such a path. But jdk should make a such assumption, right? com.sun.deploy.config.Config.java public static String getJavaCommand(String path) { if(null==path) return null; /*This section is added in 1.6.1_11, but it seams unreasonal*/ if(path.endsWith(Config.getInstance().getPlatformSpecificJavaName())) { return path; } if (!path.endsWith(File.separator)) { path = path + File.separator; } path = path + "bin" + File.separator + Config.getInstance().getPlatformSpecificJavaName(); return path; } I attach the jnlp file and jar file for reference. If you can not reproduce the problem, please contact me. thanks -- Robin Sycamore Networks http://www.sycamorenet.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20090507/2a50bf88/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 16002 bytes Desc: image001.jpg Url : http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20090507/2a50bf88/attachment.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 45988 bytes Desc: image002.jpg Url : http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20090507/2a50bf88/attachment-0001.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 54665 bytes Desc: image006.jpg Url : http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20090507/2a50bf88/attachment-0002.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: demo.jnlp Type: application/octet-stream Size: 847 bytes Desc: demo.jnlp Url : http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20090507/2a50bf88/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: demo.jar Type: application/octet-stream Size: 4997 bytes Desc: demo.jar Url : http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20090507/2a50bf88/attachment-0001.obj From Joe.Darcy at Sun.COM Thu May 7 23:07:19 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Thu, 07 May 2009 23:07:19 -0700 Subject: a bug of JDK 1.6.0_11 ? In-Reply-To: References: Message-ID: <4A03CC17.90801@sun.com> You are using Sun's production JDK, not OpenJDK 6. This alias is for discussion of OpenJDK 6. To file a bug on Sun's production JDK, go to: http://bugreport.sun.com/bugreport/ -Joe Zhuang, Guanxia (Robin) wrote: > > Hi folks > > I am trying to launch an application with java web start, but it > fails. It seams that it is a bug of jdk 1.6.0_11 and afterwards, but > 1.6.0_07 works ok. > > Test Environment: > > *bash-3.00$ uname -a* > > SunOS himalayashan 5.10 Generic_118833-17 sun4u sparc SUNW,A70 > > *bash-3.00$ which java * > > /opt/sycamore/java/bin/java > > *bash-3.00$ java -version* > > java version "1.6.0_11" > > Java(TM) SE Runtime Environment (build 1.6.0_11-b03) > > Java HotSpot(TM) Client VM (build 11.0-b16, mixed mode, sharing) > > *bash-3.00$ javaws -verbose http://172.21.1.15/demo.jnlp* > > Java(TM) Web Start 1.6.0_11 Launching: /opt/sycamore/java/bin/java > > /opt/sycamore/java/bin/java > > -Xbootclasspath/a:/opt/sycamore/java/lib/javaws.jar:/opt/sycamore/java/lib/deploy.jar > > -classpath > > /opt/sycamore/java/lib/deploy.jar > > -Djava.security.policy=file:/opt/sycamore/java/lib/security/javaws.policy > > -DtrustProxy=true > > -Xverify:remote > > -Djnlpx.home=/opt/sycamore/java/bin > > -Djnlpx.remove=false > > -Djnlpx.splashport=57758 > > -Djnlpx.jvm=/opt/sycamore/java/bin/java > > com.sun.javaws.Main > > http://172.21.1.15/demo.jnlp > > Exception is throwed: > > NOTE: > > l if the version is 1.6.0_07 or lower, no issue, but for 1.6.0_11 and > 1.6.0_12, the issue exists. > > l If the JRE is not installed in */opt/sycamore/java*, no problem. But > if the path end with java, it does not work, another example is?? > /opt/java. I look at the code, from 1.6.0_11, JDK assume that jre > should not be installed in such a path. But jdk should make a such > assumption, right? > > com.sun.deploy.config.Config.java > > *public* *static* String getJavaCommand(String path) > > { > > *if*(*null*==path) *return* *null*; > > /*This section is added in 1.6.1_11, but it seams unreasonal*/ > > * > **if**(path.endsWith(Config./getInstance/().getPlatformSpecificJavaName())) > *** > > * {*** > > * **return** path;*** > > * }*** > > *if* (!path.endsWith(File./separator/)) { > > path = path + File./separator/; > > } > > path = path + "bin" + File./separator/ + > > Config./getInstance/().getPlatformSpecificJavaName(); > > *return* path; > > } > > I attach the jnlp file and jar file for reference. > > If you can not reproduce the problem, please contact me. > > thanks > > -- > > Robin > > Sycamore Networks > > http://www.sycamorenet.com > From jennifer.godinez at sun.com Fri May 8 11:12:33 2009 From: jennifer.godinez at sun.com (jennifer.godinez at sun.com) Date: Fri, 08 May 2009 18:12:33 +0000 Subject: hg: jdk6/jdk6/jdk: 6821495: test/java/awt/print/PrinterJob/PrtException.java fails Message-ID: <20090508181250.2C3AFE703@hg.openjdk.java.net> Changeset: b5a80ffe4a92 Author: jgodinez Date: 2009-05-08 10:55 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/b5a80ffe4a92 6821495: test/java/awt/print/PrinterJob/PrtException.java fails Reviewed-by: avu, prr ! test/java/awt/PrintJob/EdgeTest/EdgeTest.java ! test/java/awt/PrintJob/MultipleEnd/MultipleEnd.java From Kelly.Ohair at Sun.COM Fri May 8 11:49:55 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 08 May 2009 11:49:55 -0700 Subject: Need reviewers - minor openjdk6 changes dealing with builds on Fedora 9 Message-ID: <4A047ED3.8020906@sun.com> Annoying typo in the declaration of main(), GCC 4.3 nagged me. ;^) 6839117: freetype sanity checker has incorrect main() declaration http://cr.openjdk.java.net/~ohair/jdk6/6839117-freetype-main/webrev/ --- Hotspot (may need to apply 'const char' change to jdk7 too): 6838823: Definitions of arrays of strings triggers errors in gcc 4.3 on Fedora 9 http://cr.openjdk.java.net/~ohair/jdk6/6838823-hotspot-const-char/webrev/ This includes a change for our JPRT system that is only for jdk6. 6831225: Upgrade JPRT jobs to use newer Linux 2.6 (e.g. Fedora 9) By default anyone using this JPRT system would get builds done on Fedora 9 (2.6 kernel) machines rather than the old antique Linux systems used with the Sun jdk6update releases. Again, this hotspot source base could be swapped out for a much newer version soon, I'll make sure these changes are in both, or more importantly, we will make sure the hotspot in OpenJDK6 builds cleanly on Fedora 9 (which is the whole point of my exercise here :^). --- -kto From Joe.Darcy at Sun.COM Fri May 8 12:31:14 2009 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Fri, 08 May 2009 12:31:14 -0700 Subject: Need reviewers - minor openjdk6 changes dealing with builds on Fedora 9 In-Reply-To: <4A047ED3.8020906@sun.com> References: <4A047ED3.8020906@sun.com> Message-ID: <4A048882.5070704@sun.com> On 05/08/09 11:49 AM, Kelly O'Hair wrote: > > Annoying typo in the declaration of main(), GCC 4.3 nagged me. ;^) > > 6839117: freetype sanity checker has incorrect main() declaration > http://cr.openjdk.java.net/~ohair/jdk6/6839117-freetype-main/webrev/ Approved! > > --- > > Hotspot (may need to apply 'const char' change to jdk7 too): > > 6838823: Definitions of arrays of strings triggers errors in gcc 4.3 > on Fedora 9 > http://cr.openjdk.java.net/~ohair/jdk6/6838823-hotspot-const-char/webrev/ > > This includes a change for our JPRT system that is only for jdk6. > 6831225: Upgrade JPRT jobs to use newer Linux 2.6 (e.g. Fedora 9) > By default anyone using this JPRT system would get builds done on > Fedora 9 > (2.6 kernel) machines rather than the old antique Linux systems used with > the Sun jdk6update releases. > Again, this hotspot source base could be swapped out for a much newer > version soon, I'll make sure these changes are in both, or more > importantly, > we will make sure the hotspot in OpenJDK6 builds cleanly on Fedora 9 > (which is the whole point of my exercise here :^). Sounds good; approved. -Joe From kelly.ohair at sun.com Fri May 8 16:35:20 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Fri, 08 May 2009 23:35:20 +0000 Subject: hg: jdk6/jdk6/jdk: 6839117: freetype sanity checker has incorrect main() declaration Message-ID: <20090508233535.EF40AE803@hg.openjdk.java.net> Changeset: 5d554775cfa8 Author: ohair Date: 2009-05-08 12:37 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/5d554775cfa8 6839117: freetype sanity checker has incorrect main() declaration Reviewed-by: darcy ! make/tools/freetypecheck/freetypecheck.c From aph at redhat.com Sat May 9 03:43:37 2009 From: aph at redhat.com (aph at redhat.com) Date: Sat, 09 May 2009 10:43:37 +0000 Subject: hg: jdk6/jdk6/jdk: 2 new changesets Message-ID: <20090509104402.86708E924@hg.openjdk.java.net> Changeset: 16b125539df4 Author: aph Date: 2009-05-09 11:35 +0100 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/16b125539df4 6812600: The miter line join decoration isn't rendered properly Reviewed-by: avu, flar, darcy Contributed-by: Google ! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java + test/sun/pisces/JoinMiterTest.java Changeset: 6a7ad6179c01 Author: aph Date: 2009-05-09 11:36 +0100 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/6a7ad6179c01 6728542: (se) epoll based SelectorProvider should be portable to platforms other than x86 and x64 Reviewed-by: sherman, darcy ! make/java/nio/mapfile-linux ! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java ! src/solaris/native/sun/nio/ch/EPollArrayWrapper.c From kelly.ohair at sun.com Sat May 9 05:05:03 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Sat, 09 May 2009 12:05:03 +0000 Subject: hg: jdk6/jdk6/hotspot: 5 new changesets Message-ID: <20090509120512.5A2F8E92F@hg.openjdk.java.net> Changeset: 564269902fe3 Author: xlu Date: 2008-06-26 14:15 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/564269902fe3 6718830: Hotspot fails to build with gcc 4.3 Summary: Fixed linux make file and couple adlc code to meet the changes of gcc 4.3 Reviewed-by: kamg, igor ! build/linux/makefiles/gcc.make ! src/share/vm/adlc/adlc.hpp ! src/share/vm/adlc/filebuff.hpp Changeset: d963c0960505 Author: ohair Date: 2009-05-07 13:20 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/d963c0960505 Merge Changeset: b574442ec617 Author: ohair Date: 2009-05-08 12:39 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/b574442ec617 6838823: Definitions of arrays of strings triggers errors in gcc 4.3 on Fedora 9 Reviewed-by: darcy ! src/share/vm/ci/ciMethodBlocks.cpp ! src/share/vm/opto/escape.cpp Changeset: 7f08cedd3b1e Author: ohair Date: 2009-05-08 12:39 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/7f08cedd3b1e 6831225: Upgrade JPRT jobs to use newer Linux 2.6 (e.g. Fedora 9) Reviewed-by: darcy ! make/jprt.properties Changeset: 29de573539a6 Author: ohair Date: 2009-05-08 18:12 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/29de573539a6 6835796: Fedora 9 linux_i586-fastdebug-c2-runThese_Xcomp times out Summary: Switch off GCC 4.3.0 optimized compilation for mulnode.o. (from jdk7) Reviewed-by: johnc ! build/linux/makefiles/gcc.make From keith at app2you.com Mon May 11 14:33:29 2009 From: keith at app2you.com (Keith Kowalczykowski) Date: Mon, 11 May 2009 14:33:29 -0700 Subject: OpenJDK vs Sun JDK Versions Message-ID: Hi Everyone, I'm a little bit confused about the version numbering of openjdk 6 vs the current JDK provided by Sun. Looking at an install of openjdk from debian (lenny), it lists itself as: java version "1.6.0_0" OpenJDK Runtime Environment (build 1.6.0_0-b11) Now, if I'm reading this correctly, this is essentially "update 0" or the initial release of the jdk. Therefore, I have two questions: 1) Am I reading this correctly? In the sun jdk, the _X would be the update number, so I'm assuming this is update 0. 2) Assuming I'm reading this correctly, why aren't any of the updates in the open JDK? Thanks in advance for you help. -Keith From Erik.Trimble at Sun.COM Mon May 11 15:20:42 2009 From: Erik.Trimble at Sun.COM (Erik Trimble) Date: Mon, 11 May 2009 15:20:42 -0700 Subject: OpenJDK vs Sun JDK Versions In-Reply-To: References: Message-ID: <1242080442.28906.46.camel@ghostbox.sfbay.sun.com> OpenJDK version numbering seems to be disjoint from Sun JDK numbering. Here on my Ubuntu 8.04 32-bit machine (openjdk-6-jre-6b11-2ubuntu2.1) , I get this: % java -version java version "1.6.0_0" OpenJDK Runtime Environment (build 1.6.0_0-b11) OpenJDK Client VM (build 1.6.0_0-b11, mixed mode, sharing) In theory, the second line (the VM version string), should report the current contents shown in http://hg.openjdk.java.net/jdk6/jdk6/hotspot/make/hotspot_version which _should_ show "build 11.0-b17", as the current OpenJDK-6 Hotspot VM source is based on Hotspot 11 Build 17. I suspect the packagers have provided their own version numbering; how they've chosen what number to use is unknown to me. I can't remember which drop of the JDK 6 Update series was the basis for OpenJDK-6. I _know_ it is at least Update 5, but I can't be certain which. Also, there have considerable incremental updates included, so a direct mapping of the OpenJDK6 to Sun JDK 6 Update projects isn't really possible NOW. As is being discussed here on this list, the synchronization of OpenJDK6 and the Sun JDK 6 Update trains is moving forward: that is, they shortly _may_ be virtually identical, in that Sun is looking to move the 6 Update development out in the open, in the same way that the Sun JDK 7 vs. OpenJDK 7 development is done now. Note that I _DO_NOT_ speak for Sun on this issue, and people should NOT take what I just said as any commitment or statement of intent on Sun's part. That information is forthcoming in various Official Statements. I'm just the Hotspot VM Gatekeeper. -Erik On Mon, 2009-05-11 at 14:33 -0700, Keith Kowalczykowski wrote: > Hi Everyone, > > I'm a little bit confused about the version numbering of openjdk 6 vs > the current JDK provided by Sun. Looking at an install of openjdk from > debian (lenny), it lists itself as: > > java version "1.6.0_0" > OpenJDK Runtime Environment (build 1.6.0_0-b11) > > Now, if I'm reading this correctly, this is essentially "update 0" or the > initial release of the jdk. Therefore, I have two questions: > > 1) Am I reading this correctly? In the sun jdk, the _X would be the update > number, so I'm assuming this is update 0. > > 2) Assuming I'm reading this correctly, why aren't any of the updates in the > open JDK? > > Thanks in advance for you help. > > -Keith > > -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) From david at davidherron.com Mon May 11 15:24:35 2009 From: david at davidherron.com (David Herron) Date: Mon, 11 May 2009 15:24:35 -0700 Subject: OpenJDK vs Sun JDK Versions In-Reply-To: References: Message-ID: <44ca3ad70905111524h3a369c43hc9bcf5067b895938@mail.gmail.com> I posted a decoder ring about this a few months ago. http://weblogs.java.net/blog/robogeek/archive/2009/01/it_will_be_open.html It doesn't answer your precise question but should give you a hint or two. Specifically OpenJDK 6 != JDK 6. - David Herron http://davidherron.com On Mon, May 11, 2009 at 2:33 PM, Keith Kowalczykowski wrote: > Hi Everyone, > > I'm a little bit confused about the version numbering of openjdk 6 vs > the current JDK provided by Sun. Looking at an install of openjdk from > debian (lenny), it lists itself as: > > java version "1.6.0_0" > OpenJDK Runtime Environment (build 1.6.0_0-b11) > > Now, if I'm reading this correctly, this is essentially "update 0" or the > initial release of the jdk. Therefore, I have two questions: > > 1) Am I reading this correctly? In the sun jdk, the _X would be the update > number, so I'm assuming this is update 0. > > 2) Assuming I'm reading this correctly, why aren't any of the updates in > the > open JDK? > > Thanks in advance for you help. > > -Keith > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20090511/8e9e1359/attachment.html From gnu_andrew at member.fsf.org Mon May 11 15:25:52 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 11 May 2009 23:25:52 +0100 Subject: OpenJDK vs Sun JDK Versions In-Reply-To: References: Message-ID: <17c6771e0905111525i2cdbb575kfd21079dec4fa897@mail.gmail.com> 2009/5/11 Keith Kowalczykowski : > Hi Everyone, > > ? ?I'm a little bit confused about the version numbering of openjdk 6 vs > the current JDK provided by Sun. Looking at an install of openjdk from > debian (lenny), it lists itself as: > > java version "1.6.0_0" > OpenJDK ?Runtime Environment (build 1.6.0_0-b11) > > Now, if I'm reading this correctly, this is essentially "update 0" or the > initial release of the jdk. Therefore, I have two questions: > > 1) Am I reading this correctly? In the sun jdk, the _X would be the update > number, so I'm assuming this is update 0. > The _0 is only there to appease (broken) Java applications that expect it to exist. There are no such 'update' releases for OpenJDK, just build drops (b11 in your example). Newer versions should also give the version of IcedTea which was used to build OpenJDK. > 2) Assuming I'm reading this correctly, why aren't any of the updates in the > open JDK? It's a different codebase. What is now OpenJDK6 was derived from OpenJDK7, which itself came from some point along the JDK6 update process. OpenJDK6 has some of the updates in u10 I believe, but not all. > > Thanks in advance for you help. > > ? ?-Keith > > > -- 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 keith at app2you.com Mon May 11 16:59:20 2009 From: keith at app2you.com (Keith Kowalczykowski) Date: Mon, 11 May 2009 16:59:20 -0700 Subject: OpenJDK vs Sun JDK Versions In-Reply-To: <17c6771e0905111525i2cdbb575kfd21079dec4fa897@mail.gmail.com> Message-ID: Hi Everyone, Thanks for the prompt responses, and helping me better undersand the OpenJDK/SunJDK ecosystem. The real issue I am trying to solve is why bug #6701268 ( http://bugs.sun.com/bugdatabase/view_bug.do%3Bjsessionid=c68647757f5376e418b 1b1b8e31?bug_id=6701268) is present in my current build (1.6.0_0-b11) of OpenJDK. Looking at the comments, it regressed in 6u10-b23 and was supposed to be "resolved in JDK 6u10-b25 with the fix for 6698652". Therefore its unclear to me how it wound up in OpenJDK, unless a source drop was made between b23 and b25 (or potentially the reported point of regession is wrong). Either way, its somewhat disconcerting that OpenJDK is being pushed by all of the major distros, but does not have the same set of patches/bugfixes as Sun's own JDK. Furthermore, there is no easy way of telling what comparable Sun JDK that OpenJDK is currently targeting, or whether a bug in the Sun JDK has even been fixed in OpenJDK. As the adoption of OpenJDK has accelerated in the major distros, I think Sun should strongly reconsider this forked-approach, as it causes major headaches for developers/sysadmins. -Keith On 5/11/09 3:25 PM, "Andrew John Hughes" wrote: > 2009/5/11 Keith Kowalczykowski : >> Hi Everyone, >> >> ? ?I'm a little bit confused about the version numbering of openjdk 6 vs >> the current JDK provided by Sun. Looking at an install of openjdk from >> debian (lenny), it lists itself as: >> >> java version "1.6.0_0" >> OpenJDK ?Runtime Environment (build 1.6.0_0-b11) >> >> Now, if I'm reading this correctly, this is essentially "update 0" or the >> initial release of the jdk. Therefore, I have two questions: >> >> 1) Am I reading this correctly? In the sun jdk, the _X would be the update >> number, so I'm assuming this is update 0. >> > > The _0 is only there to appease (broken) Java applications that expect > it to exist. There are no such 'update' releases for OpenJDK, just > build drops (b11 in your example). Newer versions should also give > the version of IcedTea which was used to build OpenJDK. > >> 2) Assuming I'm reading this correctly, why aren't any of the updates in the >> open JDK? > > It's a different codebase. What is now OpenJDK6 was derived from > OpenJDK7, which itself came from some point along the JDK6 update > process. OpenJDK6 has some of the updates in u10 I believe, but not > all. > >> >> Thanks in advance for you help. >> >> ? ?-Keith >> >> >> > > From gnu_andrew at member.fsf.org Mon May 11 17:04:05 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 12 May 2009 01:04:05 +0100 Subject: OpenJDK vs Sun JDK Versions In-Reply-To: References: <17c6771e0905111525i2cdbb575kfd21079dec4fa897@mail.gmail.com> Message-ID: <17c6771e0905111704o345b9530u48345f2d4981046b@mail.gmail.com> 2009/5/12 Keith Kowalczykowski : > Hi Everyone, > > Thanks for the prompt responses, and helping me better undersand the > OpenJDK/SunJDK ecosystem. The real issue I am trying to solve is why bug > #6701268 ( > http://bugs.sun.com/bugdatabase/view_bug.do%3Bjsessionid=c68647757f5376e418b > 1b1b8e31?bug_id=6701268) is present in my current build (1.6.0_0-b11) of > OpenJDK. > > Looking at the comments, it regressed in 6u10-b23 and was supposed to be > "resolved in JDK 6u10-b25 with the fix for 6698652". Therefore its unclear > to me how it wound up in OpenJDK, unless a source drop was made between b23 > and b25 (or potentially the reported point of regession is wrong). > The bug report states that the fix is in OpenJDK7 b27. I don't know whether or not it has been backported to OpenJDK6. > Either way, its somewhat disconcerting that OpenJDK is being pushed by all > of the major distros, but does not have the same set of patches/bugfixes as > Sun's own JDK. Furthermore, there is no easy way of telling what comparable > Sun JDK that OpenJDK is currently targeting, or whether a bug in the Sun JDK > has even been fixed in OpenJDK. As the adoption of OpenJDK has accelerated > in the major distros, I think Sun should strongly reconsider this > forked-approach, as it causes major headaches for developers/sysadmins. > > ? ?-Keith > > > On 5/11/09 3:25 PM, "Andrew John Hughes" wrote: > >> 2009/5/11 Keith Kowalczykowski : >>> Hi Everyone, >>> >>> ? ?I'm a little bit confused about the version numbering of openjdk 6 vs >>> the current JDK provided by Sun. Looking at an install of openjdk from >>> debian (lenny), it lists itself as: >>> >>> java version "1.6.0_0" >>> OpenJDK ?Runtime Environment (build 1.6.0_0-b11) >>> >>> Now, if I'm reading this correctly, this is essentially "update 0" or the >>> initial release of the jdk. Therefore, I have two questions: >>> >>> 1) Am I reading this correctly? In the sun jdk, the _X would be the update >>> number, so I'm assuming this is update 0. >>> >> >> The _0 is only there to appease (broken) Java applications that expect >> it to exist. ?There are no such 'update' releases for OpenJDK, just >> build drops (b11 in your example). ?Newer versions should also give >> the version of IcedTea which was used to build OpenJDK. >> >>> 2) Assuming I'm reading this correctly, why aren't any of the updates in the >>> open JDK? >> >> It's a different codebase. ?What is now OpenJDK6 was derived from >> OpenJDK7, which itself came from some point along the JDK6 update >> process. ?OpenJDK6 has some of the updates in u10 I believe, but not >> all. >> >>> >>> Thanks in advance for you help. >>> >>> ? ?-Keith >>> >>> >>> >> >> > > > -- 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 Dalibor.Topic at Sun.COM Mon May 11 17:52:58 2009 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Tue, 12 May 2009 02:52:58 +0200 Subject: OpenJDK vs Sun JDK Versions In-Reply-To: References: Message-ID: <4A08C86A.9060400@sun.com> Keith Kowalczykowski wrote: > Either way, its somewhat disconcerting that OpenJDK is being pushed by all > of the major distros, but does not have the same set of patches/bugfixes as > Sun's own JDK. Fwiw, next to no software in any distribution has precisely the same set of patches/bugfixes as the same software in another distribution. That's a feature of the Linux distribution model - different distributions release on different cycles and therefore they will most likely include different patches. In addition, they tend to focus on different niches, as well, which gives additional incentive to include some patches and not to include others. > Furthermore, there is no easy way of telling what comparable > Sun JDK that OpenJDK is currently targeting, or whether a bug in the Sun JDK > has even been fixed in OpenJDK. Actually, there is - OpenJDK 6 is targeting JDK 6. OpenJDK is targeting JDK 7. Beyond that, a simple way to figure out whether a change has been included in one of the two is to for i in `hg ftrees`; do echo "checking " $i ; hg -R $i log -k $bug_id ; done in a checked out repo. > As the adoption of OpenJDK has accelerated > in the major distros, I think Sun should strongly reconsider this > forked-approach, as it causes major headaches for developers/sysadmins. If you're interested in helping out with the backporting work, I think it may be possible to write a script that looks at the OpenJDK 7 changesets automatically and tries to apply them, if the changeset applies cleanly proceeds to build OpenJDK 6 from scratch, if it builds with no new warnings or errors then proceeds to run the regression test suite and to compare the regression test results with the known ones for the previous good status, and if there are no newly introduced regressions then checks if the publicly visible API has been changed, and if it hasn't proceeds to notify our bugzilla of a backporting candidate changeset. Whether a changeset gets applied depends on other factors, too, of course - given the stability goals of OpenJDK 6, we'll likely be a lot more conservative then a script's results would allow for, but it would be a good first pass to weed out trivial backporting candidates. Interested? cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin H?ring From keith at app2you.com Mon May 11 18:35:12 2009 From: keith at app2you.com (Keith Kowalczykowski) Date: Mon, 11 May 2009 18:35:12 -0700 Subject: OpenJDK vs Sun JDK Versions In-Reply-To: <4A08C86A.9060400@sun.com> Message-ID: Guys, Here's what I find unacceptable about the nature of this bug: It was an issue that was found during the beta-testing period of the Sun JDK, was fixed, and never release publically; yet, however, somehow it mananaged to make its way into a publically available OpenJDK release. This is highly disconcerting, as it means that there is no guarantee about the stability of OpenJDK, and furthermore, it means that developers are potentially exposed to any bug that ever existed in some "transient" version of the JDK, not just those bugs that were (acidentially) released publicly. I find this concerning, as the OpenJDK is increasingly being used on many linux-based production systems, where stability is of utmost importance. Just to veryify that I am not completely crazy with what I'm saying, I would appreciate if someone can verify what I'm seeing. Looking at the public source snapshot of Sun JDK 6u12 ( http://download.java.net/jdk6/6u12/promoted/b04/index.html) we see that java.awt.Component has the new lock object outlined in #6701268 (the variable is named "objectLock" instead of "changeSupportLock"). Furthermore, the readObject method property re-initializes objectLock, so the issue outlined in the bug never occurred in a public release. However, looking at OpenJDK 1.6.0-b11 ( http://download.java.net/openjdk/jdk6/promoted/b11/), the "changeSupportLock" variable exists, but it is not properly restored in readObject. This means that OpenJDK build 11 was branched off of some internal/intermediate codebase not necessarially associated with any vetted java version. By no means am I trying to jerk anyone's chain over this, and I appreciate all of the work everyone has done to get OpenJDK off the ground. However, if OpenJDK is going to be the primary JVM on opensource production systems (and it seems like both sun and the community at large is pushing for this), then there need to be some higher standards for matching the same stability and bug-freeness as the Sun JDK itself. I suggest we begin a dialog about this in order to figure out a way to fix these issues, and provide a higher gaurantee about the stability of OpenJDK. I would be happy to help-out/contribute as necessary. -Keith On 5/11/09 5:52 PM, "Dalibor Topic" wrote: > Keith Kowalczykowski wrote: >> Either way, its somewhat disconcerting that OpenJDK is being pushed by all >> of the major distros, but does not have the same set of patches/bugfixes as >> Sun's own JDK. > > Fwiw, next to no software in any distribution has precisely the same set of > patches/bugfixes as the same software in another distribution. > > That's a feature of the Linux distribution model - different distributions > release on different cycles and therefore they will most likely include > different patches. In addition, they tend to focus on different niches, > as well, which gives additional incentive to include some patches and not > to include others. > >> Furthermore, there is no easy way of telling what comparable >> Sun JDK that OpenJDK is currently targeting, or whether a bug in the Sun JDK >> has even been fixed in OpenJDK. > > Actually, there is - OpenJDK 6 is targeting JDK 6. OpenJDK is targeting JDK 7. > > Beyond that, a simple way to figure out whether a change has been included in > one of the two is to > > for i in `hg ftrees`; do echo "checking " $i ; hg -R $i log -k $bug_id ; done > > in a checked out repo. > >> As the adoption of OpenJDK has accelerated >> in the major distros, I think Sun should strongly reconsider this >> forked-approach, as it causes major headaches for developers/sysadmins. > > If you're interested in helping out with the backporting work, > I think it may be possible to write a script that looks at the > OpenJDK 7 changesets automatically and tries to apply them, if the > changeset applies cleanly proceeds to build OpenJDK 6 from scratch, if > it builds with no new warnings or errors then proceeds to run the regression > test > suite and to compare the regression test results with the known ones for > the previous good status, and if there are no newly introduced regressions > then checks if the publicly visible API has been changed, and if it hasn't > proceeds to notify our bugzilla of a backporting candidate changeset. > > Whether a changeset gets applied depends on other factors, too, > of course - given the stability goals of OpenJDK 6, we'll likely be a lot > more conservative then a script's results would allow for, but it would > be a good first pass to weed out trivial backporting candidates. > > Interested? > > cheers, > dalibor topic From david at davidherron.com Mon May 11 20:48:21 2009 From: david at davidherron.com (David Herron) Date: Mon, 11 May 2009 20:48:21 -0700 Subject: OpenJDK vs Sun JDK Versions In-Reply-To: References: <4A08C86A.9060400@sun.com> Message-ID: <44ca3ad70905112048m62e93dbbm2939cce517f3b97b@mail.gmail.com> I can say the situation you describe is a concern. When I was employed at Sun my responsibility included openjdk quality. Let me explain the reasoning & QA work which occurred for JDK6 versus OpenJDK6. First remember that OpenJDK 6 != JDK 6 because of the screwy history of how OpenJDK 6 came into being. For OpenJDK 7 and beyond the QA status is different. OpenJDK 7 is approximately the same as JDK 7 hence the QA work done by the SQE team almost 100% applies to OpenJDK 7. Very little in the way of QA had been done on OpenJDK 6 (this was true in January when I was last there, and I can't imagine that the situation has changed since then). The regular JDK's get exhaustive testing on multiple levels by a large team who has over 10 years history testing Sun's JDK. The regular JDK's undergo far more testing than the JCK and unit+regression tests. The team I formerly worked in has a large pile of other tests (non public and likely incapable of being open sourced before someone asks). The resourcing available for OpenJDK specific testing was essentially zero. JCK and unit+regression runs were done, and that's about it. The Hotspot in OpenJDK 6 is the same hotspot as in other releases hence undergoes all the testing done by VM Engineering+SQE. I agree completely and share your concern (for a very long time) about how OpenJDK6 is being used by distros as their default JDK, and that it's seeing very little QA. I can't imagine that anything has changed at Sun about resources available for Sun to test OpenJDK. Hence to have some QA of OpenJDK likely requires the community would have to step up and do that QA. About the difference you note ... OpenJDK6 was derived from a build of OpenJDK7 (read Joe Darcy's blog about making reverse progress) and IIRC that was very early in the 6u train. It's likely the fix you mention occurred long afterward and cross porting fixes to OpenJDK6 is not automatic. - David Herron http://davidherron.com On Mon, May 11, 2009 at 6:35 PM, Keith Kowalczykowski wrote: > Guys, > > Here's what I find unacceptable about the nature of this bug: It was an > issue that was found during the beta-testing period of the Sun JDK, was > fixed, and never release publically; yet, however, somehow it mananaged to > make its way into a publically available OpenJDK release. This is highly > disconcerting, as it means that there is no guarantee about the stability > of > OpenJDK, and furthermore, it means that developers are potentially exposed > to any bug that ever existed in some "transient" version of the JDK, not > just those bugs that were (acidentially) released publicly. I find this > concerning, as the OpenJDK is increasingly being used on many linux-based > production systems, where stability is of utmost importance. > > Just to veryify that I am not completely crazy with what I'm saying, I > would appreciate if someone can verify what I'm seeing. Looking at the > public source snapshot of Sun JDK 6u12 ( > http://download.java.net/jdk6/6u12/promoted/b04/index.html) we see that > java.awt.Component has the new lock object outlined in #6701268 (the > variable is named "objectLock" instead of "changeSupportLock"). > Furthermore, > the readObject method property re-initializes objectLock, so the issue > outlined in the bug never occurred in a public release. However, looking at > OpenJDK 1.6.0-b11 ( http://download.java.net/openjdk/jdk6/promoted/b11/), > the "changeSupportLock" variable exists, but it is not properly restored in > readObject. This means that OpenJDK build 11 was branched off of some > internal/intermediate codebase not necessarially associated with any vetted > java version. > > By no means am I trying to jerk anyone's chain over this, and I > appreciate all of the work everyone has done to get OpenJDK off the ground. > However, if OpenJDK is going to be the primary JVM on opensource production > systems (and it seems like both sun and the community at large is pushing > for this), then there need to be some higher standards for matching the > same > stability and bug-freeness as the Sun JDK itself. I suggest we begin a > dialog about this in order to figure out a way to fix these issues, and > provide a higher gaurantee about the stability of OpenJDK. I would be happy > to help-out/contribute as necessary. > > -Keith > > > > > On 5/11/09 5:52 PM, "Dalibor Topic" wrote: > > > Keith Kowalczykowski wrote: > >> Either way, its somewhat disconcerting that OpenJDK is being pushed by > all > >> of the major distros, but does not have the same set of patches/bugfixes > as > >> Sun's own JDK. > > > > Fwiw, next to no software in any distribution has precisely the same set > of > > patches/bugfixes as the same software in another distribution. > > > > That's a feature of the Linux distribution model - different > distributions > > release on different cycles and therefore they will most likely include > > different patches. In addition, they tend to focus on different niches, > > as well, which gives additional incentive to include some patches and not > > to include others. > > > >> Furthermore, there is no easy way of telling what comparable > >> Sun JDK that OpenJDK is currently targeting, or whether a bug in the Sun > JDK > >> has even been fixed in OpenJDK. > > > > Actually, there is - OpenJDK 6 is targeting JDK 6. OpenJDK is targeting > JDK 7. > > > > Beyond that, a simple way to figure out whether a change has been > included in > > one of the two is to > > > > for i in `hg ftrees`; do echo "checking " $i ; hg -R $i log -k $bug_id ; > done > > > > in a checked out repo. > > > >> As the adoption of OpenJDK has accelerated > >> in the major distros, I think Sun should strongly reconsider this > >> forked-approach, as it causes major headaches for developers/sysadmins. > > > > If you're interested in helping out with the backporting work, > > I think it may be possible to write a script that looks at the > > OpenJDK 7 changesets automatically and tries to apply them, if the > > changeset applies cleanly proceeds to build OpenJDK 6 from scratch, if > > it builds with no new warnings or errors then proceeds to run the > regression > > test > > suite and to compare the regression test results with the known ones for > > the previous good status, and if there are no newly introduced > regressions > > then checks if the publicly visible API has been changed, and if it > hasn't > > proceeds to notify our bugzilla of a backporting candidate changeset. > > > > Whether a changeset gets applied depends on other factors, too, > > of course - given the stability goals of OpenJDK 6, we'll likely be a lot > > more conservative then a script's results would allow for, but it would > > be a good first pass to weed out trivial backporting candidates. > > > > Interested? > > > > cheers, > > dalibor topic > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20090511/52b63afe/attachment.html From Joe.Darcy at Sun.COM Mon May 11 21:26:30 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Mon, 11 May 2009 21:26:30 -0700 Subject: OpenJDK vs Sun JDK Versions In-Reply-To: <44ca3ad70905111524h3a369c43hc9bcf5067b895938@mail.gmail.com> References: <44ca3ad70905111524h3a369c43hc9bcf5067b895938@mail.gmail.com> Message-ID: <4A08FA76.7030100@sun.com> The genealogy of the JDK 6 update train, (Open)JDK 7, and OpenJDK 6 is a bit intricate; for details see http://blogs.sun.com/darcy/entry/openjdk_6_genealogy Some parts of the code base are essentially identical between the three releases; other parts differ. The corba, jaxp, and jaxws areas are basically the same. The langtools in OpenJDK 6 has a superset of the fixes in the 6 update train; extra fixes were inherited from JDK 7. The general policy on HotSpot in OpenJDK 6 is that we use the same HotSpot as in the shipping 6 update release, modulo implementation latencies. There are the most differences in the "jdk" area of the code base, but for some time binary builds based on OpenJDK 6, with the help of patches contributed by IcedTea, have been able to pass JCK 6: http://blog.softwhere.org/archives/196 All areas of OpenJDK 6 are kept current on security fixes. -Joe David Herron wrote: > I posted a decoder ring about this a few months ago. > > http://weblogs.java.net/blog/robogeek/archive/2009/01/it_will_be_open.html > > It doesn't answer your precise question but should give you a hint or > two. Specifically OpenJDK 6 != JDK 6. > > - David Herron > http://davidherron.com > > > On Mon, May 11, 2009 at 2:33 PM, Keith Kowalczykowski > > wrote: > > Hi Everyone, > > I'm a little bit confused about the version numbering of > openjdk 6 vs > the current JDK provided by Sun. Looking at an install of openjdk from > debian (lenny), it lists itself as: > > java version "1.6.0_0" > OpenJDK Runtime Environment (build 1.6.0_0-b11) > > Now, if I'm reading this correctly, this is essentially "update 0" > or the > initial release of the jdk. Therefore, I have two questions: > > 1) Am I reading this correctly? In the sun jdk, the _X would be > the update > number, so I'm assuming this is update 0. > > 2) Assuming I'm reading this correctly, why aren't any of the > updates in the > open JDK? > > Thanks in advance for you help. > > -Keith > > > From Joe.Darcy at Sun.COM Mon May 11 22:27:30 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Mon, 11 May 2009 22:27:30 -0700 Subject: OpenJDK vs Sun JDK Versions In-Reply-To: References: Message-ID: <4A0908C2.7010608@sun.com> Amongst the tasks I've accomplished in my time as OpenJDK 6 release manager are numerous quality related tasks, including but not limited to: * Arranging for JCK test runs on OpenJDK 6 builds. * Working with engineers to review and integrate fixes to JCK failures. * Initiating an engineering effort and integrating fixes to reduce spurious regression test failures on openjdk=true builds. * Moving dozens of additional regression tests from the closed sources to the open. * Working with the langtools teams to have *all* regression tests pass on that workspace/repository and for those tests to be runnable in the much faster "samevm" mode. * For the last ten months, for each OpenJDK 6 promoted build I've run the regression tests, posted the result to my blog, and also posted a build-versus-build analysis of the results. Over time, these efforts have led to upstream OpenJDK 6 sources that have more regression tests published with fewer test failures as well as better conformance properties (http://blogs.sun.com/darcy/entry/openjdk_6_b13_and_jck). As with all endeavors, with OpenJDK 6 there is a balance between stability and progress. OpenJDK 6 general favors stability. As noted in the evaluation of bug 6698652, the problem discussed in bug 6701268 is not applicable to OpenJDK 6 because the base refactoring which caused the problem was not applied there (stability). The JCK tests which fail with this problem do not fail under OpenJDK 6. Introducing regressions is possible of course; this can happen in OpenJDK 6 and even occasionally the 6 update train. When such regressions do slip through, after they are are found we like to fix them :-) Note that the b11 sources are from July 2008; b16 is the latest build and there have been numerous improvements in the interim, including the fruits of many of the quality initiatives listed above. -Joe Keith Kowalczykowski wrote: > Guys, > > Here's what I find unacceptable about the nature of this bug: It was an > issue that was found during the beta-testing period of the Sun JDK, was > fixed, and never release publically; yet, however, somehow it mananaged to > make its way into a publically available OpenJDK release. This is highly > disconcerting, as it means that there is no guarantee about the stability of > OpenJDK, and furthermore, it means that developers are potentially exposed > to any bug that ever existed in some "transient" version of the JDK, not > just those bugs that were (acidentially) released publicly. I find this > concerning, as the OpenJDK is increasingly being used on many linux-based > production systems, where stability is of utmost importance. > > Just to veryify that I am not completely crazy with what I'm saying, I > would appreciate if someone can verify what I'm seeing. Looking at the > public source snapshot of Sun JDK 6u12 ( > http://download.java.net/jdk6/6u12/promoted/b04/index.html) we see that > java.awt.Component has the new lock object outlined in #6701268 (the > variable is named "objectLock" instead of "changeSupportLock"). Furthermore, > the readObject method property re-initializes objectLock, so the issue > outlined in the bug never occurred in a public release. However, looking at > OpenJDK 1.6.0-b11 ( http://download.java.net/openjdk/jdk6/promoted/b11/), > the "changeSupportLock" variable exists, but it is not properly restored in > readObject. This means that OpenJDK build 11 was branched off of some > internal/intermediate codebase not necessarially associated with any vetted > java version. > > By no means am I trying to jerk anyone's chain over this, and I > appreciate all of the work everyone has done to get OpenJDK off the ground. > However, if OpenJDK is going to be the primary JVM on opensource production > systems (and it seems like both sun and the community at large is pushing > for this), then there need to be some higher standards for matching the same > stability and bug-freeness as the Sun JDK itself. I suggest we begin a > dialog about this in order to figure out a way to fix these issues, and > provide a higher gaurantee about the stability of OpenJDK. I would be happy > to help-out/contribute as necessary. > > -Keith > > > > > On 5/11/09 5:52 PM, "Dalibor Topic" wrote: > > >> Keith Kowalczykowski wrote: >> >>> Either way, its somewhat disconcerting that OpenJDK is being pushed by all >>> of the major distros, but does not have the same set of patches/bugfixes as >>> Sun's own JDK. >>> >> Fwiw, next to no software in any distribution has precisely the same set of >> patches/bugfixes as the same software in another distribution. >> >> That's a feature of the Linux distribution model - different distributions >> release on different cycles and therefore they will most likely include >> different patches. In addition, they tend to focus on different niches, >> as well, which gives additional incentive to include some patches and not >> to include others. >> >> >>> Furthermore, there is no easy way of telling what comparable >>> Sun JDK that OpenJDK is currently targeting, or whether a bug in the Sun JDK >>> has even been fixed in OpenJDK. >>> >> Actually, there is - OpenJDK 6 is targeting JDK 6. OpenJDK is targeting JDK 7. >> >> Beyond that, a simple way to figure out whether a change has been included in >> one of the two is to >> >> for i in `hg ftrees`; do echo "checking " $i ; hg -R $i log -k $bug_id ; done >> >> in a checked out repo. >> >> >>> As the adoption of OpenJDK has accelerated >>> in the major distros, I think Sun should strongly reconsider this >>> forked-approach, as it causes major headaches for developers/sysadmins. >>> >> If you're interested in helping out with the backporting work, >> I think it may be possible to write a script that looks at the >> OpenJDK 7 changesets automatically and tries to apply them, if the >> changeset applies cleanly proceeds to build OpenJDK 6 from scratch, if >> it builds with no new warnings or errors then proceeds to run the regression >> test >> suite and to compare the regression test results with the known ones for >> the previous good status, and if there are no newly introduced regressions >> then checks if the publicly visible API has been changed, and if it hasn't >> proceeds to notify our bugzilla of a backporting candidate changeset. >> >> Whether a changeset gets applied depends on other factors, too, >> of course - given the stability goals of OpenJDK 6, we'll likely be a lot >> more conservative then a script's results would allow for, but it would >> be a good first pass to weed out trivial backporting candidates. >> >> Interested? >> >> cheers, >> dalibor topic >> > > > From mark at klomp.org Tue May 12 00:36:55 2009 From: mark at klomp.org (Mark Wielaard) Date: Tue, 12 May 2009 09:36:55 +0200 Subject: OpenJDK vs Sun JDK Versions In-Reply-To: References: Message-ID: <1242113816.3588.27.camel@hermans.wildebeest.org> Hi Keith, On Mon, 2009-05-11 at 18:35 -0700, Keith Kowalczykowski wrote: > Just to veryify that I am not completely crazy with what I'm saying, I > would appreciate if someone can verify what I'm seeing. Looking at the > public source snapshot of Sun JDK 6u12 ( > http://download.java.net/jdk6/6u12/promoted/b04/index.html) we see that > java.awt.Component has the new lock object outlined in #6701268 (the > variable is named "objectLock" instead of "changeSupportLock"). Furthermore, > the readObject method property re-initializes objectLock, so the issue > outlined in the bug never occurred in a public release. However, looking at > OpenJDK 1.6.0-b11 ( http://download.java.net/openjdk/jdk6/promoted/b11/), > the "changeSupportLock" variable exists, but it is not properly restored in > readObject. This means that OpenJDK build 11 was branched off of some > internal/intermediate codebase not necessarially associated with any vetted > java version. You are not crazy, and you conclusion is right. Especially the AWT code has been somewhat troublesome, with needing a lot of fixes. Most of them are in IcedTea already and are being pushed to openjdk6 for inclusion to keep the needed fixes to a minimum. The distros work together through IcedTea to do precisely what you want, making sure bugs are fixed and push them upstream if they are missing. Which is what happened in this case also (almost a year ago): http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=159 http://icedtea.classpath.org/hg/icedtea?cmd=changeset;node=c9c356cd3adf Which was then eventually incorporated into into some openjdk6 drop after b11. > By no means am I trying to jerk anyone's chain over this, and I > appreciate all of the work everyone has done to get OpenJDK off the ground. > However, if OpenJDK is going to be the primary JVM on opensource production > systems (and it seems like both sun and the community at large is pushing > for this), then there need to be some higher standards for matching the same > stability and bug-freeness as the Sun JDK itself. I suggest we begin a > dialog about this in order to figure out a way to fix these issues, and > provide a higher gaurantee about the stability of OpenJDK. I would be happy > to help-out/contribute as necessary. You are welcome. Obviously Sun doesn't have the resources to do all this alone. A lot of testing and bugs now come through the various GNU/Linux distros. If you find a bug please do report it to the distro you got your got your packages from. They will forward appropriately and/or immediately create a fix and push it upstream. You do seem to be using a rather old release, please try to get at least IcedTea 1.4 (o6 b14). 1.5 (o6 b16) is currently being prepared as a follow up release. Thanks, Mark From aph at redhat.com Tue May 12 03:03:31 2009 From: aph at redhat.com (Andrew Haley) Date: Tue, 12 May 2009 11:03:31 +0100 Subject: OpenJDK vs Sun JDK Versions In-Reply-To: References: Message-ID: <4A094973.3080608@redhat.com> Keith Kowalczykowski wrote: > Here's what I find unacceptable about the nature of this bug: It was an > issue that was found during the beta-testing period of the Sun JDK, was > fixed, and never release publically; yet, however, somehow it mananaged to > make its way into a publically available OpenJDK release. This is highly > disconcerting, as it means that there is no guarantee about the stability of > OpenJDK, and furthermore, it means that developers are potentially exposed > to any bug that ever existed in some "transient" version of the JDK, not > just those bugs that were (acidentially) released publicly. I find this > concerning, as the OpenJDK is increasingly being used on many linux-based > production systems, where stability is of utmost importance. > > Just to veryify that I am not completely crazy with what I'm saying, I > would appreciate if someone can verify what I'm seeing. Looking at the > public source snapshot of Sun JDK 6u12 ( > http://download.java.net/jdk6/6u12/promoted/b04/index.html) we see that > java.awt.Component has the new lock object outlined in #6701268 (the > variable is named "objectLock" instead of "changeSupportLock"). Furthermore, > the readObject method property re-initializes objectLock, so the issue > outlined in the bug never occurred in a public release. However, looking at > OpenJDK 1.6.0-b11 ( http://download.java.net/openjdk/jdk6/promoted/b11/), > the "changeSupportLock" variable exists, but it is not properly restored in > readObject. The OpenJDK 6 Source Release there is openjdk-6-src-b11-10_jul_2008.tar.gz. This was while OpenJDK 6 was being stabilized. There were compatibility bugs in OpenJDK 6 that we had to fix, we know that. The first (unpatched) OpenJDK 6 to pass JCK testing was b13, Dec 3 2008. > This means that OpenJDK build 11 was branched off of some > internal/intermediate codebase not necessarially associated with any vetted > java version. I'm looking at the current OpenJDK 6 tree [*], and I see private void readObject(ObjectInputStream s) throws ClassNotFoundException, IOException { changeSupportLock = new Object(); so I presume that this specific problem is of historical interest only. I also note that this bug caused a JCK failure, and IcedTea, which is used for all the GNU/Linux distro builds, is tested regularly against the JCK by Red Hat. Andrew. [*] changeset: 58:014da9cee8f1 tag: jdk6-b12 user: ohair date: Fri Jan 30 17:09:45 2009 -0800 summary: 6755917: Changes for openjdk6 build 12 From keith at app2you.com Tue May 12 11:03:52 2009 From: keith at app2you.com (Keith Kowalczykowski) Date: Tue, 12 May 2009 11:03:52 -0700 Subject: OpenJDK vs Sun JDK Versions In-Reply-To: <4A094973.3080608@redhat.com> Message-ID: Hi Everyone, Thanks for all of your responses. For the most part, this seems like a historical issue, as Joe et al have been working to improve stability and conformance of the OpenJDK. I do have a couple of comments about the topic, however: 1. In general, there seems to be a communication issue between what you guys obviously know quite well, and the general community at large. A lot of the information/links that you provided in the previous emails were quite useful, however there is no easy way for the average person to find this information without going through a similar email exchange as we just had. Right now the OpenJDK 6 website ( http://openjdk.java.net/projects/jdk6/ ) is exceedingly sparse. I think it would be helpful if we could minimally update the website to contain links to some of the most prominent articles about OpenJDK 6. Making information such as the OpenJDK genealogy and JCK conformance status more easily accessible I thing would go a long way. From there, it would be nice to build out additional FAQ information, and move some of the more important information contained on some of the blog postings into the site directly; however, this can be done on a more lazy basis. 2. I am still kind of confused about how IcedTea fits into the picture. My basic understanding is that it provides a build system for all of the distros, as well as some more secondary components, such as webstart. But I don't understand how it fits into the picture with respect to patching OpenJDK 6. 3. To answer the question of why I'm still on build 11, this is mainly an issue with my distro. It looks like Debian decided to ship build 11 as their "stable" version with the recent release of lenny. Therefore, the default install of OpenJDK on Debian uses build 11. I can always move to the "testing" repository to pull in build 14, but most people don't do this, especially on production systems. This is an issue I'm going to raise with the Debian package maintainers, as I don't believe that a version of the JDK that does not pass the JCK should be considered stable. 4. As far as ensuring that Sun JDK 6 fixes make it into OpenJDK 6, I presume you can not do a diff/patch using Sun JDK source bundles because 1) licensing issues and 2) enough has changed between the Sun JDK and the funky history of OpenJDK 6. Therefore, I'm am guessing that changes are applied to both Sun JDK 6 internally and OpenJDK 7, and then backported to OpenJDK 6, correct? Are there procedures in place to make sure that things don't fall through the cracks? -Keith On 5/12/09 3:03 AM, "Andrew Haley" wrote: > Keith Kowalczykowski wrote: > >> Here's what I find unacceptable about the nature of this bug: It was an >> issue that was found during the beta-testing period of the Sun JDK, was >> fixed, and never release publically; yet, however, somehow it mananaged to >> make its way into a publically available OpenJDK release. This is highly >> disconcerting, as it means that there is no guarantee about the stability of >> OpenJDK, and furthermore, it means that developers are potentially exposed >> to any bug that ever existed in some "transient" version of the JDK, not >> just those bugs that were (acidentially) released publicly. I find this >> concerning, as the OpenJDK is increasingly being used on many linux-based >> production systems, where stability is of utmost importance. >> >> Just to veryify that I am not completely crazy with what I'm saying, I >> would appreciate if someone can verify what I'm seeing. Looking at the >> public source snapshot of Sun JDK 6u12 ( >> http://download.java.net/jdk6/6u12/promoted/b04/index.html) we see that >> java.awt.Component has the new lock object outlined in #6701268 (the >> variable is named "objectLock" instead of "changeSupportLock"). Furthermore, >> the readObject method property re-initializes objectLock, so the issue >> outlined in the bug never occurred in a public release. However, looking at >> OpenJDK 1.6.0-b11 ( http://download.java.net/openjdk/jdk6/promoted/b11/), >> the "changeSupportLock" variable exists, but it is not properly restored in >> readObject. > > The OpenJDK 6 Source Release there is openjdk-6-src-b11-10_jul_2008.tar.gz. > This was while OpenJDK 6 was being stabilized. There were compatibility > bugs in OpenJDK 6 that we had to fix, we know that. > > The first (unpatched) OpenJDK 6 to pass JCK testing was b13, Dec 3 2008. > >> This means that OpenJDK build 11 was branched off of some >> internal/intermediate codebase not necessarially associated with any vetted >> java version. > > I'm looking at the current OpenJDK 6 tree [*], and I see > > private void readObject(ObjectInputStream s) > throws ClassNotFoundException, IOException > { > changeSupportLock = new Object(); > > so I presume that this specific problem is of historical interest only. > > I also note that this bug caused a JCK failure, and IcedTea, which is used > for all the GNU/Linux distro builds, is tested regularly against the JCK > by Red Hat. > > Andrew. > > > [*] changeset: 58:014da9cee8f1 > tag: jdk6-b12 > user: ohair > date: Fri Jan 30 17:09:45 2009 -0800 > summary: 6755917: Changes for openjdk6 build 12 From aph at redhat.com Tue May 12 12:11:56 2009 From: aph at redhat.com (Andrew Haley) Date: Tue, 12 May 2009 20:11:56 +0100 Subject: OpenJDK vs Sun JDK Versions In-Reply-To: References: Message-ID: <4A09C9FC.6020706@redhat.com> Keith Kowalczykowski wrote: > 2. I am still kind of confused about how IcedTea fits into the picture. My > basic understanding is that it provides a build system for all of the > distros, as well as some more secondary components, such as webstart. But I > don't understand how it fits into the picture with respect to patching > OpenJDK 6. We patch JDK6 for a number of reasons: * Patches that are in OpenJDK7 but not yet the official OpenJDK6 * Linux-specific changes such as using system libraries and resources * Build system extensions to allow building with other tools e.g. gcj * Ports to non-86 architectures that have not yet been merged into OpenJDK6 * Bug fixes not yet accepted into OpenJDK6 http://icedtea.classpath.org/wiki/IcedTea_JDK6_Patches > 4. As far as ensuring that Sun JDK 6 fixes make it into OpenJDK 6, I presume > you can not do a diff/patch using Sun JDK source bundles because 1) > licensing issues and 2) enough has changed between the Sun JDK and the funky > history of OpenJDK 6. Indeed, because OpenJDK 6 is based on JDK 7. Andrew. From Kelly.Ohair at Sun.COM Tue May 12 13:27:50 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 12 May 2009 13:27:50 -0700 Subject: OpenJDK vs Sun JDK Versions In-Reply-To: References: Message-ID: <4A09DBC6.1040501@sun.com> Keith Kowalczykowski wrote: > Hi Everyone, [snip] > 4. As far as ensuring that Sun JDK 6 fixes make it into OpenJDK 6, I presume > you can not do a diff/patch using Sun JDK source bundles because 1) > licensing issues and 2) enough has changed between the Sun JDK and the funky > history of OpenJDK 6. Therefore, I'm am guessing that changes are applied to > both Sun JDK 6 internally and OpenJDK 7, and then backported to OpenJDK 6, > correct? Are there procedures in place to make sure that things don't fall > through the cracks? The reasons that Sun JDK 6 update changes cannot or are not just applied to OpenJDK6 is numerous, some technical, some legal, some business. From my perspective, I only change OpenJDK6 when it's somehow deemed necessary. It would be unrealistic to expect all the Sun JDK 6 fixes to show up in OpenJDK6, it just ain't gonna happen. Having said that, if it's a critical fix, it probably will be done, determining what 'critical' means is another story. Initially both Sun JDK 6 and Sun JDK 7 were in TeamWare workspaces, so part of the technical issues are that the Sun JDK 6 sources have remained in TeamWare, JDK 7 has converted to Mercurial, and OpenJDK6 started out as TeamWare then was converted to Mercurial. So in the middle of all this was two large conversion projects. The changeset you refered to was: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/014da9cee8f1 this was a changeset created by the scripting I created to convert OpenJDK6 from TeamWare to Mercurial. So it's a bit of a Frankenstein creature changeset, fair warning it could be dangerous. :^( The Sun JDK 7 restructuring to become the "open" OpenJDK7 was extensive and this did not happen to the Sun JDK 6 sources, that was a big project. The fact that OpenJDK6 and OpenJDK7 share the similar "open" structure makes it easier to apply changesets as patches between them, but that only stays easy as long as the basic structure remains the same. The point being that applying patches between these creatures is not trivial, and over time will get more difficult. Hope that helps explain things a bit, from my perspective anyway. -kto From gnu_andrew at member.fsf.org Tue May 12 13:28:01 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 12 May 2009 21:28:01 +0100 Subject: OpenJDK vs Sun JDK Versions In-Reply-To: References: <4A094973.3080608@redhat.com> Message-ID: <17c6771e0905121328n47716dabp7a676136df694370@mail.gmail.com> 2009/5/12 Keith Kowalczykowski : > Hi Everyone, > > ? ?Thanks for all of your responses. For the most part, this seems like a > historical issue, as Joe et al have been working to improve stability and > conformance of the OpenJDK. I do have a couple of comments about the topic, > however: > > 1. In general, there seems to be a communication issue between what you guys > obviously know quite well, and the general community at large. A lot of the > information/links that you provided in the previous emails were quite > useful, however there is no easy way for the average person to find this > information without going through a similar email exchange as we just had. > Right now the OpenJDK 6 website ( http://openjdk.java.net/projects/jdk6/ ) > is exceedingly sparse. I think it would be helpful if we could minimally > update the website to contain links to some of the most prominent articles > about OpenJDK 6. Making information such as the OpenJDK genealogy and JCK > conformance status more easily accessible I thing would go a long way. From > there, it would be nice to build out additional FAQ information, and move > some of the more important information contained on some of the blog > postings into the site directly; however, this can be done on a more lazy > basis. > As far as I know, only a few people at Sun working on the OpenJDK project have the necessary privileges to alter that page. So most information is going to turn up elsewhere e.g. in blogs. I'm not saying it wouldn't be nice to have a lot more information there, but that I can see why the current situation exists. This is especially true with regard to IcedTea because it's not really part of OpenJDK6 at all but a project in its own right - see http://icedtea.classpath.org. > 2. I am still kind of confused about how IcedTea fits into the picture. My > basic understanding is that it provides a build system for all of the > distros, as well as some more secondary components, such as webstart. But I > don't understand how it fits into the picture with respect to patching > OpenJDK 6. > Andrew already explained this well. All I'd like to add is to make it clear that it's IcedTea that you'll find in all the distros. I don't know of many people building 'raw' OpenJDK6 on a regular basis, and I don't know of anyone distributing such builds (including Sun). The existence of IcedTea is largely a result of the OpenJDK infrastructure not being in place early enough (and even now it's too slow in many respects to match the pace required by distros). Once the source was available from Sun, it needed to be made distributable and as quickly as possible, a process which involved providing replacement for the binary plugs it required at the time (now all history thankfully, barring the optional SNMP extension) and fixing the build to allow it to work using the existing Free tools (gcj/ecj). Distributions need to be able to build from a completely Free source code base using Free tools, neither of which was possible with the original build drop from Sun. There was no way to contribute these changes back at the time (there was no source code repository then, let alone a contribution process) so IcedTea was born and has to continue to serve the needs of packaging OpenJDK for distributions. > 3. To answer the question of why I'm still on build 11, this is mainly an > issue with my distro. It looks like Debian decided to ship build 11 as their > "stable" version with the recent release of lenny. Therefore, the default > install of OpenJDK on Debian uses build 11. I can always move to the > "testing" repository to pull in build 14, but most people don't do this, > especially on production systems. This is an issue I'm going to raise with > the Debian package maintainers, as I don't believe that a version of the JDK > that does not pass the JCK should be considered stable. > As far as I'm aware, Debian have made no commitment to running the TCK. Those who have signed the necessary paperwork and been approved are listed here: http://openjdk.java.net/groups/conformance/JckAccess/jck-access.html Also, from my reading of the bug you mentioned, JCK tests had to be altered as a result of the bug. So it wouldn't have solved the issue. What I'm saying is there is no way of knowing whether or not that build passes the JCK without signing the necessary paperwork and running it yourself. Only a particular binary can pass and no-one has tested the build used by Debian. The builds in RHEL and Fedora have passed, and I believe the one in RHEL is b11-based. RHEL has similar stability constraints to Debian and you won't see updates to every new build drop there either. I presume security updates are backported, as is usual with Debian packages. > 4. As far as ensuring that Sun JDK 6 fixes make it into OpenJDK 6, I presume > you can not do a diff/patch using Sun JDK source bundles because 1) > licensing issues and 2) enough has changed between the Sun JDK and the funky > history of OpenJDK 6. Therefore, I'm am guessing that changes are applied to > both Sun JDK 6 internally and OpenJDK 7, and then backported to OpenJDK 6, > correct? Are there procedures in place to make sure that things don't fall > through the cracks? > Only Sun can do the whole proprietary JDK-->OpenJDK7 process. Most has now come across (Nimbus just appeared in b57 IIRC). 7 to 6 ports are slower as there are just fewer people working in that space. I don't know about the internal processes within Sun, but IcedTea developers tend to backport bug fixes from 7 to 6 as needed within IcedTea, and also try to get them pushed into the upstream 6 repository. Until it's in 7, there's nothing anyone outside Sun can do. When 7 is released next year, things will be different because we'll be starting from an open code base without the legacy of a proprietary release and updates. OpenJDK6 is a stop-gap to provide a JDK which can pass the OpenJDK6 JCK in the meantime. > > ? ?-Keith > > > On 5/12/09 3:03 AM, "Andrew Haley" wrote: > >> Keith Kowalczykowski wrote: >> >>> ? ? Here's what I find unacceptable about the nature of this bug: It was an >>> issue that was found during the beta-testing period of the Sun JDK, was >>> fixed, and never release publically; yet, however, somehow it mananaged to >>> make its way into a publically available OpenJDK release. This is highly >>> disconcerting, as it means that there is no guarantee about the stability of >>> OpenJDK, and furthermore, it means that developers are potentially exposed >>> to any bug that ever existed in some "transient" version of the JDK, not >>> just those bugs that were (acidentially) released publicly. I find this >>> concerning, as the OpenJDK is increasingly being used on many linux-based >>> production systems, where stability is of utmost importance. >>> >>> ? ? Just to veryify that I am not completely crazy with what I'm saying, I >>> would appreciate if someone can verify what I'm seeing. Looking at the >>> public source snapshot of Sun JDK 6u12 ( >>> http://download.java.net/jdk6/6u12/promoted/b04/index.html) we see that >>> java.awt.Component has the new lock object outlined in #6701268 (the >>> variable is named "objectLock" instead of "changeSupportLock"). Furthermore, >>> the readObject method property re-initializes objectLock, so the issue >>> outlined in the bug never occurred in a public release. However, looking at >>> OpenJDK 1.6.0-b11 ( http://download.java.net/openjdk/jdk6/promoted/b11/), >>> the "changeSupportLock" variable exists, but it is not properly restored in >>> readObject. >> >> The OpenJDK 6 Source Release there is openjdk-6-src-b11-10_jul_2008.tar.gz. >> This was while OpenJDK 6 was being stabilized. ?There were compatibility >> bugs in OpenJDK 6 that we had to fix, we know that. >> >> The first (unpatched) OpenJDK 6 to pass JCK testing was b13, Dec 3 2008. >> >>> This means that OpenJDK build 11 was branched off of some >>> internal/intermediate codebase not necessarially associated with any vetted >>> java version. >> >> I'm looking at the current OpenJDK 6 tree [*], and I see >> >> ? ? private void readObject(ObjectInputStream s) >> ? ? ? throws ClassNotFoundException, IOException >> ? ? { >> ? ? ? ? changeSupportLock = new Object(); >> >> so I presume that this specific problem is of historical interest only. >> >> I also note that this bug caused a JCK failure, and IcedTea, which is used >> for all the GNU/Linux distro builds, is tested regularly against the JCK >> by Red Hat. >> >> Andrew. >> >> >> [*] changeset: ? 58:014da9cee8f1 >> tag: ? ? ? ? jdk6-b12 >> user: ? ? ? ?ohair >> date: ? ? ? ?Fri Jan 30 17:09:45 2009 -0800 >> summary: ? ? 6755917: Changes for openjdk6 build 12 > > > -- 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 alex.menkov at sun.com Wed May 13 08:23:01 2009 From: alex.menkov at sun.com (alex.menkov at sun.com) Date: Wed, 13 May 2009 15:23:01 +0000 Subject: hg: jdk6/jdk6/jdk: 6832063: OpenJDK fails to open the default ALSA device when PulseAudio is enabled Message-ID: <20090513152321.ABAFAECE1@hg.openjdk.java.net> Changeset: 078e8d627f0f Author: amenkov Date: 2009-05-13 19:12 +0400 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/078e8d627f0f 6832063: OpenJDK fails to open the default ALSA device when PulseAudio is enabled Reviewed-by: amenkov Contributed-by: omajid at redhat.com ! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_PCM.c From gnu_andrew at member.fsf.org Fri May 15 11:01:46 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 15 May 2009 19:01:46 +0100 Subject: HotSpot 14 Message-ID: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> Hi all (especially Joe), Now that the HotSpot Express repositories are available, what is the plan for including hs14 in OpenJDK6? I did a pull of the base changeset from HS express (0) into OpenJDK6's hotspot repo. yesterday as a test, and it seems to apply fairly well. The conflicts all seem to be whitespace changes (though there's a lot of them -- ~210 files are affected). Do we still plan to maintain a version of HotSpot in OpenJDK6 or will HS Express just be used directly? 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 Erik.Trimble at Sun.COM Fri May 15 11:20:35 2009 From: Erik.Trimble at Sun.COM (Erik Trimble) Date: Fri, 15 May 2009 11:20:35 -0700 Subject: HotSpot 14 In-Reply-To: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> References: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> Message-ID: <4A0DB273.9060908@sun.com> Andrew John Hughes wrote: > Hi all (especially Joe), > > Now that the HotSpot Express repositories are available, what is the > plan for including hs14 in OpenJDK6? > > I did a pull of the base changeset from HS express (0) into OpenJDK6's > hotspot repo. yesterday as a test, and it seems to apply fairly well. > The conflicts all seem to be whitespace changes (though there's a lot > of them -- ~210 files are affected). > > Do we still plan to maintain a version of HotSpot in OpenJDK6 or will > HS Express just be used directly? > > Thanks, > Frankly, I think this is up to the Community. I'm still not 100% sure of the complete list of who has write access to the OpenJDK6 stuff, but I /think/ the proper way to do this is not move any HSX release into the main OpenJDK6 forest until there is consensus that It's Time. Now, that said, maybe It's Time Right Now. Given that the HSX repos are going to be almost exclusively Sun-only writable (in practice, not necessarily by design), I think that the VM in OpenJDK6 should be pulled from an HSX repo, and then have various community-desired patches applied there, rather than try to work directly on an HSX repo. That is, I expect the various HSX repos to be a reflection of what Sun is doing, and the VM in OpenJDK6 should be a reflection of what the Community chooses to do with the HSX work from Sun. As such, going forward, I _hope_ there is less and less of a requirement to maintain IceTea, and that everything there can get moved over into the appropriate OpenJDK repo. Not that I have anything against IceTea, it just would be nice to cut down on the amount of work needed to maintain all these separate codebases. -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) From aph at redhat.com Fri May 15 11:25:07 2009 From: aph at redhat.com (Andrew Haley) Date: Fri, 15 May 2009 19:25:07 +0100 Subject: HotSpot 14 In-Reply-To: <4A0DB273.9060908@sun.com> References: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> <4A0DB273.9060908@sun.com> Message-ID: <4A0DB383.9090502@redhat.com> Erik Trimble wrote: > Andrew John Hughes wrote: >> Hi all (especially Joe), >> >> Now that the HotSpot Express repositories are available, what is the >> plan for including hs14 in OpenJDK6? >> >> I did a pull of the base changeset from HS express (0) into OpenJDK6's >> hotspot repo. yesterday as a test, and it seems to apply fairly well. >> The conflicts all seem to be whitespace changes (though there's a lot >> of them -- ~210 files are affected). >> >> Do we still plan to maintain a version of HotSpot in OpenJDK6 or will >> HS Express just be used directly? > Frankly, I think this is up to the Community. > > I'm still not 100% sure of the complete list of who has write access to > the OpenJDK6 stuff, but I /think/ the proper way to do this is not move > any HSX release into the main OpenJDK6 forest until there is consensus > that It's Time. > > Now, that said, maybe It's Time Right Now. Yes, it is. It has been for some time. > Given that the HSX repos are going to be almost exclusively Sun-only > writable (in practice, not necessarily by design), I think that the VM > in OpenJDK6 should be pulled from an HSX repo, and then have various > community-desired patches applied there, rather than try to work > directly on an HSX repo. That is, I expect the various HSX repos to be > a reflection of what Sun is doing, and the VM in OpenJDK6 should be a > reflection of what the Community chooses to do with the HSX work from Sun. > > As such, going forward, I _hope_ there is less and less of a requirement > to maintain IceTea, and that everything there can get moved over into > the appropriate OpenJDK repo. We're working on that. > Not that I have anything against IceTea, it just would be nice to cut down > on the amount of work needed to maintain all these separate codebases. Sure, but from what I've seen many (most?) of the community patches to the VM are changes that need to go upstream (i.e. to HSX) anyway. Keeping them as OpenJDK6-only makes little sense. Andrew. From gnu_andrew at member.fsf.org Fri May 15 11:29:08 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 15 May 2009 19:29:08 +0100 Subject: HotSpot 14 In-Reply-To: <4A0DB273.9060908@sun.com> References: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> <4A0DB273.9060908@sun.com> Message-ID: <17c6771e0905151129r46a63069tab22c6b39901a6ec@mail.gmail.com> 2009/5/15 Erik Trimble : > Andrew John Hughes wrote: >> >> Hi all (especially Joe), >> >> Now that the HotSpot Express repositories are available, what is the >> plan for including hs14 in OpenJDK6? >> >> I did a pull of the base changeset from HS express (0) into OpenJDK6's >> hotspot repo. yesterday as a test, and it seems to apply fairly well. >> The conflicts all seem to be whitespace changes (though there's a lot >> of them -- ~210 files are affected). >> >> Do we still plan to maintain a version of HotSpot in OpenJDK6 or will >> HS Express just be used directly? >> >> Thanks, >> > > Frankly, I think this is up to the Community. > > I'm still not 100% sure of the complete list of who has write access to the > OpenJDK6 stuff, but I /think/ the proper way to do this is not move any HSX > release into the main OpenJDK6 forest until there is ?consensus that It's > Time. > The list is here: http://db.openjdk.java.net/people for your delectation and delight. > Now, that said, maybe It's Time Right Now. > IcedTea (i.e. the version of OpenJDK6 people are actually using on their distros today) has already been shipping HotSpot 14 for some time. So I think not only is the time right for OpenJDK6 upstream to also upgrade, but that it's perhaps long overdue. > > Given that the HSX repos are going to be almost exclusively Sun-only > writable (in practice, not necessarily by design), I think that the VM in > OpenJDK6 should be pulled from an HSX repo, and then have various > community-desired patches applied there, rather than try to work directly on > an HSX repo. ?That is, I expect the various HSX repos to be a reflection of > what Sun is doing, and the VM in OpenJDK6 should be a reflection of what the > Community chooses to do with the HSX work from Sun. > My preference would be for patches to go into HotSpot Express and then OpenJDK6 just pull a stable version regularly. I've already had patches committed to HotSpot as have others working on IcedTea, so I don't see an issue there. > As such, going forward, I _hope_ there is less and less of a requirement to > maintain IceTea, and that everything there can get moved over into the > appropriate OpenJDK repo. ?Not that I have anything against IceTea, it just > would be nice to cut down on the amount of work needed to maintain all these > separate codebases. > We agree. Most of IcedTea is there by necessity, not design. See http://icedtea.classpath.org/wiki/IcedTea_JDK6_Patches for our progress on getting everything upstream where we can. > -- > Erik Trimble > Java System Support > Mailstop: ?usca22-123 > Phone: ?x17195 > Santa Clara, CA > Timezone: US/Pacific (GMT-0800) > > -- 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 Erik.Trimble at Sun.COM Fri May 15 11:42:26 2009 From: Erik.Trimble at Sun.COM (Erik Trimble) Date: Fri, 15 May 2009 11:42:26 -0700 Subject: HotSpot 14 In-Reply-To: <17c6771e0905151129r46a63069tab22c6b39901a6ec@mail.gmail.com> References: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> <4A0DB273.9060908@sun.com> <17c6771e0905151129r46a63069tab22c6b39901a6ec@mail.gmail.com> Message-ID: <4A0DB792.4020701@sun.com> Andrew John Hughes wrote: > 2009/5/15 Erik Trimble : > >> Andrew John Hughes wrote: >> >>> Hi all (especially Joe), >>> >>> Now that the HotSpot Express repositories are available, what is the >>> plan for including hs14 in OpenJDK6? >>> >>> I did a pull of the base changeset from HS express (0) into OpenJDK6's >>> hotspot repo. yesterday as a test, and it seems to apply fairly well. >>> The conflicts all seem to be whitespace changes (though there's a lot >>> of them -- ~210 files are affected). >>> >>> Do we still plan to maintain a version of HotSpot in OpenJDK6 or will >>> HS Express just be used directly? >>> >>> Thanks, >>> >>> >> Frankly, I think this is up to the Community. >> >> I'm still not 100% sure of the complete list of who has write access to the >> OpenJDK6 stuff, but I /think/ the proper way to do this is not move any HSX >> release into the main OpenJDK6 forest until there is consensus that It's >> Time. >> >> > > The list is here: http://db.openjdk.java.net/people for your > delectation and delight. > > Thanks! >> Now, that said, maybe It's Time Right Now. >> >> > > IcedTea (i.e. the version of OpenJDK6 people are actually using on > their distros today) has already been shipping HotSpot 14 for some > time. So I think not only is the time right for OpenJDK6 upstream to > also upgrade, but that it's perhaps long overdue. > > I'll check with Joe, but I think it's on my to-do list to push HSX14 to OpenJDK sometime before JavaOne. >> Given that the HSX repos are going to be almost exclusively Sun-only >> writable (in practice, not necessarily by design), I think that the VM in >> OpenJDK6 should be pulled from an HSX repo, and then have various >> community-desired patches applied there, rather than try to work directly on >> an HSX repo. That is, I expect the various HSX repos to be a reflection of >> what Sun is doing, and the VM in OpenJDK6 should be a reflection of what the >> Community chooses to do with the HSX work from Sun. >> >> > > My preference would be for patches to go into HotSpot Express and then > OpenJDK6 just pull a stable version regularly. I've already had > patches committed to HotSpot as have others working on IcedTea, so I > don't see an issue there. > Well, this needs further discussion. There's still some conflict here as to whether or not we're going to ship the Sun JDK 6 Update release train as a superset of the OpenJDK6 + HSX repositories, or if there will be things in those open repos that we exclude from the Sun JDK6 Updates. If the first case is what is happening (i.e. Sun's JDK is a superset of OpenJDK6+HSX), then, yes, we (that is, the entire Community+Sun) should just patch the appropriate HSX repo, and periodically pull it over into the OpenJDK6 forest after stabilization. If, on the other hand, the second case is what is To Be, then only certain community-submitted patches will be integrated into HSX, which means that the actual development of Hotspot for OpenJDK6 will have to happen in the OpenJDK6 forest directly. In essence, if we chose the 2nd case, there will need to be 3 VM repositories: HSX for the stuff that's going to be the Sun JDK6 release, IceTea for the patches to the HSX repository that aren't going into Sun's JDK, and OpenJDK6, which is HSX+IceTea (stabilized). -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) From Joe.Darcy at Sun.COM Fri May 15 21:58:05 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Fri, 15 May 2009 21:58:05 -0700 Subject: HotSpot 14 In-Reply-To: <4A0DB792.4020701@sun.com> References: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> <4A0DB273.9060908@sun.com> <17c6771e0905151129r46a63069tab22c6b39901a6ec@mail.gmail.com> <4A0DB792.4020701@sun.com> Message-ID: <4A0E47DD.6000804@sun.com> Hello. Erik Trimble wrote: > Andrew John Hughes wrote: >> 2009/5/15 Erik Trimble : >> >>> Andrew John Hughes wrote: >>> >>>> Hi all (especially Joe), >>>> >>>> Now that the HotSpot Express repositories are available, what is the >>>> plan for including hs14 in OpenJDK6? >>>> >>>> I did a pull of the base changeset from HS express (0) into OpenJDK6's >>>> hotspot repo. yesterday as a test, and it seems to apply fairly well. >>>> The conflicts all seem to be whitespace changes (though there's a lot >>>> of them -- ~210 files are affected). >>>> >>>> Do we still plan to maintain a version of HotSpot in OpenJDK6 or will >>>> HS Express just be used directly? >>>> >>>> Thanks, >>>> >>>> >>> Frankly, I think this is up to the Community. >>> >>> I'm still not 100% sure of the complete list of who has write access >>> to the >>> OpenJDK6 stuff, but I /think/ the proper way to do this is not move >>> any HSX >>> release into the main OpenJDK6 forest until there is consensus that >>> It's >>> Time. >>> >>> >> >> The list is here: http://db.openjdk.java.net/people for your >> delectation and delight. >> >> > Thanks! > > >>> Now, that said, maybe It's Time Right Now. >>> >>> >> >> IcedTea (i.e. the version of OpenJDK6 people are actually using on >> their distros today) has already been shipping HotSpot 14 for some >> time. So I think not only is the time right for OpenJDK6 upstream to >> also upgrade, but that it's perhaps long overdue. >> >> > I'll check with Joe, but I think it's on my to-do list to push HSX14 > to OpenJDK sometime before JavaOne. That sounds good to me, modulo my preferences below... >>> Given that the HSX repos are going to be almost exclusively Sun-only >>> writable (in practice, not necessarily by design), I think that the >>> VM in >>> OpenJDK6 should be pulled from an HSX repo, and then have various >>> community-desired patches applied there, rather than try to work >>> directly on >>> an HSX repo. That is, I expect the various HSX repos to be a >>> reflection of >>> what Sun is doing, and the VM in OpenJDK6 should be a reflection of >>> what the >>> Community chooses to do with the HSX work from Sun. >>> >>> >> >> My preference would be for patches to go into HotSpot Express and then >> OpenJDK6 just pull a stable version regularly. I've already had >> patches committed to HotSpot as have others working on IcedTea, so I >> don't see an issue there. >> > > Well, this needs further discussion. There's still some conflict here > as to whether or not we're going to ship the Sun JDK 6 Update release > train as a superset of the OpenJDK6 + HSX repositories, or if there > will be things in those open repos that we exclude from the Sun JDK6 > Updates. > > If the first case is what is happening (i.e. Sun's JDK is a superset > of OpenJDK6+HSX), then, yes, we (that is, the entire Community+Sun) > should just patch the appropriate HSX repo, and periodically pull it > over into the OpenJDK6 forest after stabilization. If, on the other > hand, the second case is what is To Be, then only certain > community-submitted patches will be integrated into HSX, which means > that the actual development of Hotspot for OpenJDK6 will have to > happen in the OpenJDK6 forest directly. In essence, if we chose the > 2nd case, there will need to be 3 VM repositories: HSX for the stuff > that's going to be the Sun JDK6 release, IceTea for the patches to the > HSX repository that aren't going into Sun's JDK, and OpenJDK6, which > is HSX+IceTea (stabilized). > In my estimation, the fixes desirable in a HS repository being used for Sun JDK stabilization and the fixes desirable for a HS repository being used for OpenJDK 6 and for IcedTea 6 are fundamentally the same in all cases: a stable HotSpot that runs fast enough. Around the margins, there may be some issues around if a particular patch is appropriate for the upstream sources, but the IcedTea HotSpot patches I've seen to fix things like build issues seem innocuous and appropriate for upstream to me. My preference is essentially combining the HSX and OpenJDK 6 HS repositories; i.e. the OpenJDK 6 HS repository is the HSX stabilization repo. The alternative of periodically syncing HSX into OpenJDK 6 is possible too, but strikes me as a little extra work when we could just as easily tag or otherwise publicize "we think this version of the repo is good." The IcedTea HS patches could continue as needed, especially timing wise when release deadlines don't line up, but I think we should be able to get much less skew between the HotSpot in IcedTea and the stabilized HS in OpenJDK 6/HSX, which should bring benefits all around by getting more testing on (nearly) the same code base. -Joe From Jonathan.Gibbons at Sun.COM Sat May 16 07:19:40 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Sat, 16 May 2009 07:19:40 -0700 Subject: HotSpot 14 In-Reply-To: <4A0E47DD.6000804@sun.com> References: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> <4A0DB273.9060908@sun.com> <17c6771e0905151129r46a63069tab22c6b39901a6ec@mail.gmail.com> <4A0DB792.4020701@sun.com> <4A0E47DD.6000804@sun.com> Message-ID: On May 15, 2009, at 9:58 PM, Joseph D. Darcy wrote: > Hello. > > Erik Trimble wrote: >> Andrew John Hughes wrote: >>> 2009/5/15 Erik Trimble : >>> >>>> Andrew John Hughes wrote: >>>> >>>>> Hi all (especially Joe), >>>>> >>>>> Now that the HotSpot Express repositories are available, what is >>>>> the >>>>> plan for including hs14 in OpenJDK6? >>>>> >>>>> I did a pull of the base changeset from HS express (0) into >>>>> OpenJDK6's >>>>> hotspot repo. yesterday as a test, and it seems to apply fairly >>>>> well. >>>>> The conflicts all seem to be whitespace changes (though there's >>>>> a lot >>>>> of them -- ~210 files are affected). >>>>> >>>>> Do we still plan to maintain a version of HotSpot in OpenJDK6 or >>>>> will >>>>> HS Express just be used directly? >>>>> >>>>> Thanks, >>>>> >>>>> >>>> Frankly, I think this is up to the Community. >>>> >>>> I'm still not 100% sure of the complete list of who has write >>>> access to the >>>> OpenJDK6 stuff, but I /think/ the proper way to do this is not >>>> move any HSX >>>> release into the main OpenJDK6 forest until there is consensus >>>> that It's >>>> Time. >>>> >>>> >>> >>> The list is here: http://db.openjdk.java.net/people for your >>> delectation and delight. >>> >>> >> Thanks! >> >> >>>> Now, that said, maybe It's Time Right Now. >>>> >>>> >>> >>> IcedTea (i.e. the version of OpenJDK6 people are actually using on >>> their distros today) has already been shipping HotSpot 14 for some >>> time. So I think not only is the time right for OpenJDK6 upstream >>> to >>> also upgrade, but that it's perhaps long overdue. >>> >>> >> I'll check with Joe, but I think it's on my to-do list to push >> HSX14 to OpenJDK sometime before JavaOne. > > That sounds good to me, modulo my preferences below... > >>>> Given that the HSX repos are going to be almost exclusively Sun- >>>> only >>>> writable (in practice, not necessarily by design), I think that >>>> the VM in >>>> OpenJDK6 should be pulled from an HSX repo, and then have various >>>> community-desired patches applied there, rather than try to work >>>> directly on >>>> an HSX repo. That is, I expect the various HSX repos to be a >>>> reflection of >>>> what Sun is doing, and the VM in OpenJDK6 should be a reflection >>>> of what the >>>> Community chooses to do with the HSX work from Sun. >>>> >>>> >>> >>> My preference would be for patches to go into HotSpot Express and >>> then >>> OpenJDK6 just pull a stable version regularly. I've already had >>> patches committed to HotSpot as have others working on IcedTea, so I >>> don't see an issue there. >>> >> >> Well, this needs further discussion. There's still some conflict >> here as to whether or not we're going to ship the Sun JDK 6 Update >> release train as a superset of the OpenJDK6 + HSX repositories, or >> if there will be things in those open repos that we exclude from >> the Sun JDK6 Updates. >> >> If the first case is what is happening (i.e. Sun's JDK is a >> superset of OpenJDK6+HSX), then, yes, we (that is, the entire >> Community+Sun) should just patch the appropriate HSX repo, and >> periodically pull it over into the OpenJDK6 forest after >> stabilization. If, on the other hand, the second case is what is >> To Be, then only certain community-submitted patches will be >> integrated into HSX, which means that the actual development of >> Hotspot for OpenJDK6 will have to happen in the OpenJDK6 forest >> directly. In essence, if we chose the 2nd case, there will need to >> be 3 VM repositories: HSX for the stuff that's going to be the >> Sun JDK6 release, IceTea for the patches to the HSX repository that >> aren't going into Sun's JDK, and OpenJDK6, which is HSX+IceTea >> (stabilized). >> > > In my estimation, the fixes desirable in a HS repository being used > for Sun JDK stabilization and the fixes desirable for a HS > repository being used for OpenJDK 6 and for IcedTea 6 are > fundamentally the same in all cases: a stable HotSpot that runs fast > enough. Around the margins, there may be some issues around if a > particular patch is appropriate for the upstream sources, but the > IcedTea HotSpot patches I've seen to fix things like build issues > seem innocuous and appropriate for upstream to me. > > My preference is essentially combining the HSX and OpenJDK 6 HS > repositories; i.e. the OpenJDK 6 HS repository is the HSX > stabilization repo. The alternative of periodically syncing HSX > into OpenJDK 6 is possible too, but strikes me as a little extra > work when we could just as easily tag or otherwise publicize "we > think this version of the repo is good." The IcedTea HS patches > could continue as needed, especially timing wise when release > deadlines don't line up, but I think we should be able to get much > less skew between the HotSpot in IcedTea and the stabilized HS in > OpenJDK 6/HSX, which should bring benefits all around by getting > more testing on (nearly) the same code base. > > -Joe Joe, Architecturally, this seems to bring up an interesting point. Currently we build a set of "co-located" repositories -- i.e. a Mercurial forest. You are somewhat suggesting we break this paradigm, by using a tree (HotSpot) which is not directly within the forest. If we can figure out how to do that, then maybe we would also be able to use the same mechanism to handle corba/jaxws, jaxp, etc, which do not naturally live within our forests. Maybe the top level repo could have optional Makefile targets to get copies of the latest preferred copies of these "imported" repositories. They would be "optional" in that they would be available for a user to invoke if they wanted to access and build using the imported repository, as compared to using the existing mechanism for importing built bits from an earlier build. -- Jon From Joe.Darcy at Sun.COM Sat May 16 08:13:00 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Sat, 16 May 2009 08:13:00 -0700 Subject: HotSpot 14 In-Reply-To: References: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> <4A0DB273.9060908@sun.com> <17c6771e0905151129r46a63069tab22c6b39901a6ec@mail.gmail.com> <4A0DB792.4020701@sun.com> <4A0E47DD.6000804@sun.com> Message-ID: <4A0ED7FC.9060007@sun.com> Jonathan Gibbons wrote: > On May 15, 2009, at 9:58 PM, Joseph D. Darcy wrote: > >> Hello. >> >> Erik Trimble wrote: >>> Andrew John Hughes wrote: >>>> 2009/5/15 Erik Trimble : >>>> >>>>> Andrew John Hughes wrote: >>>>> >>>>>> Hi all (especially Joe), >>>>>> >>>>>> Now that the HotSpot Express repositories are available, what is the >>>>>> plan for including hs14 in OpenJDK6? >>>>>> >>>>>> I did a pull of the base changeset from HS express (0) into >>>>>> OpenJDK6's >>>>>> hotspot repo. yesterday as a test, and it seems to apply fairly >>>>>> well. >>>>>> The conflicts all seem to be whitespace changes (though there's a >>>>>> lot >>>>>> of them -- ~210 files are affected). >>>>>> >>>>>> Do we still plan to maintain a version of HotSpot in OpenJDK6 or >>>>>> will >>>>>> HS Express just be used directly? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> >>>>> Frankly, I think this is up to the Community. >>>>> >>>>> I'm still not 100% sure of the complete list of who has write >>>>> access to the >>>>> OpenJDK6 stuff, but I /think/ the proper way to do this is not >>>>> move any HSX >>>>> release into the main OpenJDK6 forest until there is consensus >>>>> that It's >>>>> Time. >>>>> >>>>> >>>> >>>> The list is here: http://db.openjdk.java.net/people for your >>>> delectation and delight. >>>> >>>> >>> Thanks! >>> >>> >>>>> Now, that said, maybe It's Time Right Now. >>>>> >>>>> >>>> >>>> IcedTea (i.e. the version of OpenJDK6 people are actually using on >>>> their distros today) has already been shipping HotSpot 14 for some >>>> time. So I think not only is the time right for OpenJDK6 upstream to >>>> also upgrade, but that it's perhaps long overdue. >>>> >>>> >>> I'll check with Joe, but I think it's on my to-do list to push HSX14 >>> to OpenJDK sometime before JavaOne. >> >> That sounds good to me, modulo my preferences below... >> >>>>> Given that the HSX repos are going to be almost exclusively Sun-only >>>>> writable (in practice, not necessarily by design), I think that >>>>> the VM in >>>>> OpenJDK6 should be pulled from an HSX repo, and then have various >>>>> community-desired patches applied there, rather than try to work >>>>> directly on >>>>> an HSX repo. That is, I expect the various HSX repos to be a >>>>> reflection of >>>>> what Sun is doing, and the VM in OpenJDK6 should be a reflection >>>>> of what the >>>>> Community chooses to do with the HSX work from Sun. >>>>> >>>>> >>>> >>>> My preference would be for patches to go into HotSpot Express and then >>>> OpenJDK6 just pull a stable version regularly. I've already had >>>> patches committed to HotSpot as have others working on IcedTea, so I >>>> don't see an issue there. >>>> >>> >>> Well, this needs further discussion. There's still some conflict >>> here as to whether or not we're going to ship the Sun JDK 6 Update >>> release train as a superset of the OpenJDK6 + HSX repositories, or >>> if there will be things in those open repos that we exclude from the >>> Sun JDK6 Updates. >>> >>> If the first case is what is happening (i.e. Sun's JDK is a superset >>> of OpenJDK6+HSX), then, yes, we (that is, the entire Community+Sun) >>> should just patch the appropriate HSX repo, and periodically pull it >>> over into the OpenJDK6 forest after stabilization. If, on the >>> other hand, the second case is what is To Be, then only certain >>> community-submitted patches will be integrated into HSX, which means >>> that the actual development of Hotspot for OpenJDK6 will have to >>> happen in the OpenJDK6 forest directly. In essence, if we chose the >>> 2nd case, there will need to be 3 VM repositories: HSX for the >>> stuff that's going to be the Sun JDK6 release, IceTea for the >>> patches to the HSX repository that aren't going into Sun's JDK, and >>> OpenJDK6, which is HSX+IceTea (stabilized). >>> >> >> In my estimation, the fixes desirable in a HS repository being used >> for Sun JDK stabilization and the fixes desirable for a HS repository >> being used for OpenJDK 6 and for IcedTea 6 are fundamentally the same >> in all cases: a stable HotSpot that runs fast enough. Around the >> margins, there may be some issues around if a particular patch is >> appropriate for the upstream sources, but the IcedTea HotSpot patches >> I've seen to fix things like build issues seem innocuous and >> appropriate for upstream to me. >> >> My preference is essentially combining the HSX and OpenJDK 6 HS >> repositories; i.e. the OpenJDK 6 HS repository is the HSX >> stabilization repo. The alternative of periodically syncing HSX into >> OpenJDK 6 is possible too, but strikes me as a little extra work when >> we could just as easily tag or otherwise publicize "we think this >> version of the repo is good." The IcedTea HS patches could continue >> as needed, especially timing wise when release deadlines don't line >> up, but I think we should be able to get much less skew between the >> HotSpot in IcedTea and the stabilized HS in OpenJDK 6/HSX, which >> should bring benefits all around by getting more testing on (nearly) >> the same code base. >> >> -Joe > > > Joe, > > Architecturally, this seems to bring up an interesting point. > Currently we build a set of "co-located" repositories -- i.e. a > Mercurial forest. You are somewhat suggesting we break this paradigm, > by using a tree (HotSpot) which is not directly within the forest. If > we can figure out how to do that, then maybe we would also be able to > use the same mechanism to handle corba/jaxws, jaxp, etc, which do not > naturally live within our forests. For HotSpot, another way to implement this approach is to sync HS 14 into OpenJDK 6 and then do whatever would have been done in the new HSX repo in the existing OpenJDK 6 repo. For corba, jaxp, and jaxws which are effectively maintained elsewhere, later this year I want to explore going to a model where those files are *not* tracked under version control in the JDK, rather the teams in question would periodically sent us known-good source tar-balls, or some equivalent bundle of code. Any JDK-specific changes could be tracked under version control and applied locally as patches until the changes go upstream. Given how well this model works for IcedTea working with OpenJDK, I'm confident it can also work for the JDK's incorporation of corba, jaxp, and jaxws :-) -Joe From Dalibor.Topic at Sun.COM Mon May 18 09:11:16 2009 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Mon, 18 May 2009 18:11:16 +0200 Subject: Request for review: 6641691 6-open: Bring build readme's up-to-date Message-ID: <4A1188A4.6050809@sun.com> Hi Joe, hi Kelly, here's a build doc update for review. I copied the updated README & README-build.html files over to the jdk and jdk/make subdirectories, as well. Having the same files over there, too, seems a bit redundant, though, so it may make sense to slash at least the jdk/make/README* copies. cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin H?ring From Dalibor.Topic at Sun.COM Mon May 18 09:12:52 2009 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Mon, 18 May 2009 18:12:52 +0200 Subject: Request for review: 6641691 6-open: Bring build readme's up-to-date In-Reply-To: <4A1188A4.6050809@sun.com> References: <4A1188A4.6050809@sun.com> Message-ID: <4A118904.9090904@sun.com> Dalibor Topic wrote: > Hi Joe, hi Kelly, > > here's a build doc update for review. http://cr.openjdk.java.net/~robilad/6641691/webrev.00/ > > I copied the updated README & README-build.html files over > to the jdk and jdk/make subdirectories, as well. Having the same > files over there, too, seems a bit redundant, though, so it > may make sense to slash at least the jdk/make/README* copies. > > cheers, > dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin H?ring From Kelly.Ohair at Sun.COM Mon May 18 09:20:48 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 18 May 2009 09:20:48 -0700 Subject: Request for review: 6641691 6-open: Bring build readme's up-to-date In-Reply-To: <4A1188A4.6050809@sun.com> References: <4A1188A4.6050809@sun.com> Message-ID: <4A118AE0.5060206@sun.com> Yeah. It was an oversight on my part to leave the README-builds.html file in the jdk6/jdk repository, my intent was to put it at the top of the jdk6 or top repository, and not leave it in the jdk6/jdk repository at all. No need to duplicate the file either. -kto Dalibor Topic wrote: > Hi Joe, hi Kelly, > > here's a build doc update for review. > > I copied the updated README & README-build.html files over > to the jdk and jdk/make subdirectories, as well. Having the same > files over there, too, seems a bit redundant, though, so it > may make sense to slash at least the jdk/make/README* copies. > > cheers, > dalibor topic From Dalibor.Topic at Sun.COM Mon May 18 09:22:08 2009 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Mon, 18 May 2009 18:22:08 +0200 Subject: Request for review: 6641691 6-open: Bring build readme's up-to-date In-Reply-To: <4A118AE0.5060206@sun.com> References: <4A1188A4.6050809@sun.com> <4A118AE0.5060206@sun.com> Message-ID: <4A118B30.7060608@sun.com> Kelly O'Hair wrote: > Yeah. It was an oversight on my part to leave the README-builds.html file > in the jdk6/jdk repository, my intent was to put it at the top of the > jdk6 or top repository, and not leave it in the jdk6/jdk repository at all. > No need to duplicate the file either. Ah, cool - should I remove all instances of it from the jdk6/jdk repository? cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin H?ring From Kelly.Ohair at Sun.COM Mon May 18 09:27:35 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 18 May 2009 09:27:35 -0700 Subject: Request for review: 6641691 6-open: Bring build readme's up-to-date In-Reply-To: <4A118904.9090904@sun.com> References: <4A1188A4.6050809@sun.com> <4A118904.9090904@sun.com> Message-ID: <4A118C77.9000206@sun.com> Can we just have one README-builds.html file, the one at the top of the forest? And delete all the others? I assume they are all the same. -kto Dalibor Topic wrote: > Dalibor Topic wrote: >> Hi Joe, hi Kelly, >> >> here's a build doc update for review. > > http://cr.openjdk.java.net/~robilad/6641691/webrev.00/ > >> I copied the updated README & README-build.html files over >> to the jdk and jdk/make subdirectories, as well. Having the same >> files over there, too, seems a bit redundant, though, so it >> may make sense to slash at least the jdk/make/README* copies. >> >> cheers, >> dalibor topic > > From Kelly.Ohair at Sun.COM Mon May 18 09:27:59 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 18 May 2009 09:27:59 -0700 Subject: Request for review: 6641691 6-open: Bring build readme's up-to-date In-Reply-To: <4A118B30.7060608@sun.com> References: <4A1188A4.6050809@sun.com> <4A118AE0.5060206@sun.com> <4A118B30.7060608@sun.com> Message-ID: <4A118C8F.7040103@sun.com> Dalibor Topic wrote: > Kelly O'Hair wrote: >> Yeah. It was an oversight on my part to leave the README-builds.html file >> in the jdk6/jdk repository, my intent was to put it at the top of the >> jdk6 or top repository, and not leave it in the jdk6/jdk repository at all. >> No need to duplicate the file either. > > Ah, cool - should I remove all instances of it from the jdk6/jdk > repository? > Yes. -kto > cheers, > dalibor topic From Dalibor.Topic at Sun.COM Mon May 18 09:41:52 2009 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Mon, 18 May 2009 18:41:52 +0200 Subject: Request for review: 6641691 6-open: Bring build readme's up-to-date In-Reply-To: <4A118C8F.7040103@sun.com> References: <4A1188A4.6050809@sun.com> <4A118AE0.5060206@sun.com> <4A118B30.7060608@sun.com> <4A118C8F.7040103@sun.com> Message-ID: <4A118FD0.5010500@sun.com> Kelly O'Hair wrote: > > > Dalibor Topic wrote: >> Kelly O'Hair wrote: >>> Yeah. It was an oversight on my part to leave the README-builds.html >>> file >>> in the jdk6/jdk repository, my intent was to put it at the top of the >>> jdk6 or top repository, and not leave it in the jdk6/jdk repository >>> at all. >>> No need to duplicate the file either. >> >> Ah, cool - should I remove all instances of it from the jdk6/jdk >> repository? >> > > Yes. Cool, will do. cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin H?ring From Kelly.Ohair at Sun.COM Mon May 18 10:31:11 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 18 May 2009 10:31:11 -0700 Subject: Request for review: 6641691 6-open: Bring build readme's up-to-date In-Reply-To: <4A118FD0.5010500@sun.com> References: <4A1188A4.6050809@sun.com> <4A118AE0.5060206@sun.com> <4A118B30.7060608@sun.com> <4A118C8F.7040103@sun.com> <4A118FD0.5010500@sun.com> Message-ID: <4A119B5F.1030607@sun.com> Changes look fine by the way, consider them reviewed. -kto Dalibor Topic wrote: > Kelly O'Hair wrote: >> >> Dalibor Topic wrote: >>> Kelly O'Hair wrote: >>>> Yeah. It was an oversight on my part to leave the README-builds.html >>>> file >>>> in the jdk6/jdk repository, my intent was to put it at the top of the >>>> jdk6 or top repository, and not leave it in the jdk6/jdk repository >>>> at all. >>>> No need to duplicate the file either. >>> Ah, cool - should I remove all instances of it from the jdk6/jdk >>> repository? >>> >> Yes. > > Cool, will do. > > cheers, > dalibor topic From gnu_andrew at member.fsf.org Mon May 18 10:36:12 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 18 May 2009 18:36:12 +0100 Subject: HotSpot 14 In-Reply-To: <4A0ED7FC.9060007@sun.com> References: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> <4A0DB273.9060908@sun.com> <17c6771e0905151129r46a63069tab22c6b39901a6ec@mail.gmail.com> <4A0DB792.4020701@sun.com> <4A0E47DD.6000804@sun.com> <4A0ED7FC.9060007@sun.com> Message-ID: <17c6771e0905181036v58e2477ctd26a7d0b6fa2ff5b@mail.gmail.com> > snip... > Given how well this model works for IcedTea working with OpenJDK, I'm > confident it can also work for the JDK's incorporation of corba, jaxp, and > jaxws :-) > Indeed, IcedTea already downloads a tarball of the HSX repository and deletes the OpenJDK6 version. Having to sync between HSX and OpenJDK6 just seems to create unnecessary work. The big question is what would be in the build drops -- would these be a complete amalgamation of all the tarballs from their various sources or just upstream OpenJDK6 (i.e. jdk and langtools by the sound of it)? > -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 Dalibor.Topic at Sun.COM Mon May 18 11:30:22 2009 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Mon, 18 May 2009 20:30:22 +0200 Subject: Request for review: 6641691 6-open: Bring build readme's up-to-date In-Reply-To: <4A119B5F.1030607@sun.com> References: <4A1188A4.6050809@sun.com> <4A118AE0.5060206@sun.com> <4A118B30.7060608@sun.com> <4A118C8F.7040103@sun.com> <4A118FD0.5010500@sun.com> <4A119B5F.1030607@sun.com> Message-ID: <4A11A93E.7090603@sun.com> Kelly O'Hair wrote: > Changes look fine by the way, consider them reviewed. Great, thank you very much! Do you mind if I remove the jdk6/jdk/README.html and jdk6/jdk/make/README.html files while I'm at it? cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin H?ring From Kelly.Ohair at Sun.COM Mon May 18 12:31:51 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 18 May 2009 12:31:51 -0700 Subject: Request for review: 6641691 6-open: Bring build readme's up-to-date In-Reply-To: <4A11A93E.7090603@sun.com> References: <4A1188A4.6050809@sun.com> <4A118AE0.5060206@sun.com> <4A118B30.7060608@sun.com> <4A118C8F.7040103@sun.com> <4A118FD0.5010500@sun.com> <4A119B5F.1030607@sun.com> <4A11A93E.7090603@sun.com> Message-ID: <4A11B7A7.2070501@sun.com> Dalibor Topic wrote: > Kelly O'Hair wrote: >> Changes look fine by the way, consider them reviewed. > > Great, thank you very much! Do you mind if I remove the > jdk6/jdk/README.html and jdk6/jdk/make/README.html files > while I'm at it? Ok with me. -kto > > cheers, > dalibor topic From Joe.Darcy at Sun.COM Mon May 18 14:53:44 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Mon, 18 May 2009 14:53:44 -0700 Subject: HotSpot 14 In-Reply-To: <17c6771e0905181036v58e2477ctd26a7d0b6fa2ff5b@mail.gmail.com> References: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> <4A0DB273.9060908@sun.com> <17c6771e0905151129r46a63069tab22c6b39901a6ec@mail.gmail.com> <4A0DB792.4020701@sun.com> <4A0E47DD.6000804@sun.com> <4A0ED7FC.9060007@sun.com> <17c6771e0905181036v58e2477ctd26a7d0b6fa2ff5b@mail.gmail.com> Message-ID: <4A11D8E8.70004@sun.com> Andrew John Hughes wrote: >> snip... >> Given how well this model works for IcedTea working with OpenJDK, I'm >> confident it can also work for the JDK's incorporation of corba, jaxp, and >> jaxws :-) >> >> > > Indeed, IcedTea already downloads a tarball of the HSX repository and > deletes the OpenJDK6 version. Having to sync between HSX and OpenJDK6 > just seems to create unnecessary work. > > The big question is what would be in the build drops -- would these be > a complete amalgamation of all the tarballs from their various sources > or just upstream OpenJDK6 (i.e. jdk and langtools by the sound of it)? > That is a detail that remains to be worked out. Would you prefer one big tarball? -Joe From gnu_andrew at member.fsf.org Mon May 18 14:57:42 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 18 May 2009 22:57:42 +0100 Subject: HotSpot 14 In-Reply-To: <4A11D8E8.70004@sun.com> References: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> <4A0DB273.9060908@sun.com> <17c6771e0905151129r46a63069tab22c6b39901a6ec@mail.gmail.com> <4A0DB792.4020701@sun.com> <4A0E47DD.6000804@sun.com> <4A0ED7FC.9060007@sun.com> <17c6771e0905181036v58e2477ctd26a7d0b6fa2ff5b@mail.gmail.com> <4A11D8E8.70004@sun.com> Message-ID: <17c6771e0905181457q5229a695j3779d88cd52af12d@mail.gmail.com> 2009/5/18 Joseph D. Darcy : > Andrew John Hughes wrote: >>> >>> snip... >>> Given how well this model works for IcedTea working with OpenJDK, I'm >>> confident it can also work for the JDK's incorporation of corba, jaxp, >>> and >>> jaxws :-) >>> >>> >> >> Indeed, IcedTea already downloads a tarball of the HSX repository and >> deletes the OpenJDK6 version. ?Having to sync between HSX and OpenJDK6 >> just seems to create unnecessary work. >> >> The big question is what would be in the build drops -- would these be >> a complete amalgamation of all the tarballs from their various sources >> or just upstream OpenJDK6 (i.e. jdk and langtools by the sound of it)? >> > > That is a detail that remains to be worked out. ?Would you prefer one big > tarball? > > -Joe > I think it would be easier and we then also know we are using exactly the same sources as Sun, and can compare e.g. test results. -- 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 aph at redhat.com Tue May 19 10:51:45 2009 From: aph at redhat.com (Andrew Haley) Date: Tue, 19 May 2009 18:51:45 +0100 Subject: [Fwd: Re: Request for approval: Bugs 6837665 and 6829575] Message-ID: <4A12F1B1.4050700@redhat.com> I think I sent it to the wrong list. Forwarding to jdk6-dev instead of build-dev. Andrew. -------------- next part -------------- An embedded message was scrubbed... From: Andrew Haley Subject: Re: Request for approval: Bugs 6837665 and 6829575 Date: Tue, 19 May 2009 18:26:57 +0100 Size: 4397 Url: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20090519/168fc657/attachment.eml From Jonathan.Gibbons at Sun.COM Tue May 19 11:20:26 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Tue, 19 May 2009 11:20:26 -0700 Subject: [Fwd: Re: Request for approval: Bugs 6837665 and 6829575] In-Reply-To: <4A12F1B1.4050700@redhat.com> References: <4A12F1B1.4050700@redhat.com> Message-ID: <4A12F86A.6010209@sun.com> Andrew, This changeset from JDK7 needs to be backported to 6. I'll take care of it. changeset: 12:6beca695cfae user: jjg date: Thu Mar 13 13:42:38 2008 -0700 -- Jon Andrew Haley wrote: > I think I sent it to the wrong list. > > Forwarding to jdk6-dev instead of build-dev. > > Andrew. > > > ------------------------------------------------------------------------ > > Subject: > Re: Request for approval: Bugs 6837665 and 6829575 > From: > Andrew Haley > Date: > Tue, 19 May 2009 18:26:57 +0100 > To: > Jonathan Gibbons > > To: > Jonathan Gibbons > CC: > "build-dev at openjdk.java.net" > > > Jonathan Gibbons wrote: > >> That's an exceedingly old file you have there -- langtools >> src/share/opensource/* should have disappered a long time ago. >> > > Hmm, I checked it out of the repository an hour or so ago. > > `hg parents' says > > changeset: 43:9820754525dd > tag: tip > user: ohair > date: Wed May 06 12:01:57 2009 -0700 > summary: 6831225: Upgrade JPRT jobs to use newer Linux 2.6 (e.g. Fedora 9) > > Andrew. > > > >> On May 19, 2009, at 9:58 AM, Andrew Haley wrote: >> >> >>> This is for the OpenJDK 6 trees. >>> >>> The patch is very similar to that now committed to OpenJDK 7, but it >>> touches a few more places that control debuginfo. >>> >>> http://cr.openjdk.java.net/~aph/6829575-jdk6-webrev/ >>> >>> Andrew. >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20090519/3c5be745/attachment.html From aph at redhat.com Tue May 19 11:38:23 2009 From: aph at redhat.com (Andrew Haley) Date: Tue, 19 May 2009 19:38:23 +0100 Subject: [Fwd: Re: Request for approval: Bugs 6837665 and 6829575] In-Reply-To: <4A12F86A.6010209@sun.com> References: <4A12F1B1.4050700@redhat.com> <4A12F86A.6010209@sun.com> Message-ID: <4A12FC9F.70909@redhat.com> Jonathan Gibbons wrote: > Andrew, > > This changeset from JDK7 needs to be backported to 6. I'll take care of > it. > > changeset: 12:6beca695cfae > user: jjg > date: Thu Mar 13 13:42:38 2008 -0700 OK, thanks. Let me know when you've done and I'll make a new webrev. Andrew. From Jonathan.Gibbons at Sun.COM Tue May 19 11:41:07 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Tue, 19 May 2009 11:41:07 -0700 Subject: [Fwd: Re: Request for approval: Bugs 6837665 and 6829575] In-Reply-To: <4A12FC9F.70909@redhat.com> References: <4A12F1B1.4050700@redhat.com> <4A12F86A.6010209@sun.com> <4A12FC9F.70909@redhat.com> Message-ID: <4A12FD43.5040407@sun.com> You can proceed independently. All I'll be doing is deleting langtools src/share/opensource/*. Consider any changes to those files approved ;-) -- Jon Andrew Haley wrote: > Jonathan Gibbons wrote: > >> Andrew, >> >> This changeset from JDK7 needs to be backported to 6. I'll take care of >> it. >> >> changeset: 12:6beca695cfae >> user: jjg >> date: Thu Mar 13 13:42:38 2008 -0700 >> > > OK, thanks. Let me know when you've done and I'll make a new webrev. > > Andrew. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20090519/6a676887/attachment.html From kelly.ohair at sun.com Tue May 19 11:58:33 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Tue, 19 May 2009 11:58:33 -0700 Subject: hg: jdk6/jdk6: 6831225: Upgrade JPRT jobs to use newer Linux 2.6 (e.g. Fedora 9) Message-ID: <20090519185833.3AD28E3DA@hg.openjdk.java.net> Changeset: 71ec0e8ab08b Author: ohair Date: 2009-05-07 09:17 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/rev/71ec0e8ab08b 6831225: Upgrade JPRT jobs to use newer Linux 2.6 (e.g. Fedora 9) Reviewed-by: tbell ! make/jprt.properties From dalibor.topic at sun.com Tue May 19 12:19:03 2009 From: dalibor.topic at sun.com (dalibor.topic at sun.com) Date: Tue, 19 May 2009 19:19:03 +0000 Subject: hg: jdk6/jdk6: 6641691: 6-open: Bring build readme's up-to-date Message-ID: <20090519191903.D4365E3DF@hg.openjdk.java.net> Changeset: 073cdf699427 Author: robilad Date: 2009-05-19 02:30 +0200 URL: http://hg.openjdk.java.net/jdk6/jdk6/rev/073cdf699427 6641691: 6-open: Bring build readme's up-to-date Summary: Updated build documentation. Reviewed-by: ohair ! README ! README-builds.html From dalibor.topic at sun.com Tue May 19 12:23:26 2009 From: dalibor.topic at sun.com (dalibor.topic at sun.com) Date: Tue, 19 May 2009 19:23:26 +0000 Subject: hg: jdk6/jdk6/jdk: 6641691: 6-open: Bring build readme's up-to-date Message-ID: <20090519192334.2D0DEE3ED@hg.openjdk.java.net> Changeset: 86f52477d472 Author: robilad Date: 2009-05-19 02:31 +0200 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/86f52477d472 6641691: 6-open: Bring build readme's up-to-date Summary: Updated build documentation. Reviewed-by: ohair ! README - README-builds.html - README.html ! make/README - make/README-builds.html - make/README.html From Kelly.Ohair at Sun.COM Tue May 19 14:55:15 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 19 May 2009 14:55:15 -0700 Subject: Need reviewer - removing duplicate README files Message-ID: <4A132AC3.2080301@sun.com> Minor cleanup issue. 6843041: Remove duplicate README files in repositories (make/README) jdk7: http://cr.openjdk.java.net/~ohair/jdk7/6843041-dup-READMEs/webrev/ jdk6: http://cr.openjdk.java.net/~ohair/jdk6/6843041-dup-READMEs/webrev/ -kto From Jonathan.Gibbons at Sun.COM Tue May 19 15:00:58 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Tue, 19 May 2009 15:00:58 -0700 Subject: Need reviewer - removing duplicate README files In-Reply-To: <4A132AC3.2080301@sun.com> References: <4A132AC3.2080301@sun.com> Message-ID: <9C196D43-CC99-471D-B24D-BA88F29A902E@sun.com> The langtools README you're thinking of deleting is not a duplicate of anything and is specific to the langtools repository and contains useful info. -- Jon On May 19, 2009, at 2:55 PM, Kelly O'Hair wrote: > > Minor cleanup issue. > > 6843041: Remove duplicate README files in repositories (make/README) > > jdk7: http://cr.openjdk.java.net/~ohair/jdk7/6843041-dup-READMEs/webrev/ > > jdk6: http://cr.openjdk.java.net/~ohair/jdk6/6843041-dup-READMEs/webrev/ > > -kto > From Kelly.Ohair at Sun.COM Tue May 19 15:04:37 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 19 May 2009 15:04:37 -0700 Subject: Need reviewer - removing duplicate README files In-Reply-To: <9C196D43-CC99-471D-B24D-BA88F29A902E@sun.com> References: <4A132AC3.2080301@sun.com> <9C196D43-CC99-471D-B24D-BA88F29A902E@sun.com> Message-ID: <4A132CF5.3010601@sun.com> There is a langtools/README and a langtools/make/README, they were almost identical (NetBeans 6.0 vs. NetBeans 5.0 reference). I was deleting the langtools/make/README one. -kto Jonathan Gibbons wrote: > The langtools README you're thinking of deleting is not a duplicate of > anything and is specific > to the langtools repository and contains useful info. > > -- Jon > > > On May 19, 2009, at 2:55 PM, Kelly O'Hair wrote: > >> >> Minor cleanup issue. >> >> 6843041: Remove duplicate README files in repositories (make/README) >> >> jdk7: http://cr.openjdk.java.net/~ohair/jdk7/6843041-dup-READMEs/webrev/ >> >> jdk6: http://cr.openjdk.java.net/~ohair/jdk6/6843041-dup-READMEs/webrev/ >> >> -kto >> > From Jonathan.Gibbons at Sun.COM Tue May 19 15:11:17 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Tue, 19 May 2009 15:11:17 -0700 Subject: Need reviewer - removing duplicate README files In-Reply-To: <4A132CF5.3010601@sun.com> References: <4A132AC3.2080301@sun.com> <9C196D43-CC99-471D-B24D-BA88F29A902E@sun.com> <4A132CF5.3010601@sun.com> Message-ID: <50224124-F52F-4815-B238-B26F598D6D84@Sun.COM> Whoops yes, I see that -- and I will fix the langtools/README to refer to NetBeans 6. -- Jon On May 19, 2009, at 3:04 PM, Kelly O'Hair wrote: > There is a langtools/README and a langtools/make/README, they were > almost identical (NetBeans 6.0 vs. NetBeans 5.0 reference). > I was deleting the langtools/make/README one. > > -kto > > > Jonathan Gibbons wrote: >> The langtools README you're thinking of deleting is not a duplicate >> of anything and is specific >> to the langtools repository and contains useful info. >> -- Jon >> On May 19, 2009, at 2:55 PM, Kelly O'Hair wrote: >>> >>> Minor cleanup issue. >>> >>> 6843041: Remove duplicate README files in repositories (make/README) >>> >>> jdk7: http://cr.openjdk.java.net/~ohair/jdk7/6843041-dup-READMEs/webrev/ >>> >>> jdk6: http://cr.openjdk.java.net/~ohair/jdk6/6843041-dup-READMEs/webrev/ >>> >>> -kto >>> From Dalibor.Topic at Sun.COM Tue May 19 17:16:27 2009 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Wed, 20 May 2009 02:16:27 +0200 Subject: Need reviewer - removing duplicate README files In-Reply-To: <4A132AC3.2080301@sun.com> References: <4A132AC3.2080301@sun.com> Message-ID: <4A134BDB.6050703@sun.com> Kelly O'Hair wrote: > > Minor cleanup issue. > > 6843041: Remove duplicate README files in repositories (make/README) > > jdk7: http://cr.openjdk.java.net/~ohair/jdk7/6843041-dup-READMEs/webrev/ > > jdk6: http://cr.openjdk.java.net/~ohair/jdk6/6843041-dup-READMEs/webrev/ Both are fine, thanks for cleaning them up, Kelly. Should jdk/make/README go as well? cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin H?ring From kelly.ohair at sun.com Tue May 19 17:40:25 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Wed, 20 May 2009 00:40:25 +0000 Subject: hg: jdk6/jdk6/corba: 6843041: Remove duplicate README files in repositories (make/README) Message-ID: <20090520004026.607A2E45B@hg.openjdk.java.net> Changeset: 8439eb84807b Author: ohair Date: 2009-05-19 17:30 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/corba/rev/8439eb84807b 6843041: Remove duplicate README files in repositories (make/README) Reviewed-by: robilad - make/README From kelly.ohair at sun.com Tue May 19 17:44:36 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Wed, 20 May 2009 00:44:36 +0000 Subject: hg: jdk6/jdk6/jaxp: 6843041: Remove duplicate README files in repositories (make/README) Message-ID: <20090520004437.BECADE471@hg.openjdk.java.net> Changeset: 5c6c1e6dfce9 Author: ohair Date: 2009-05-19 17:31 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/jaxp/rev/5c6c1e6dfce9 6843041: Remove duplicate README files in repositories (make/README) Reviewed-by: robilad - make/README From kelly.ohair at sun.com Tue May 19 17:48:39 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Wed, 20 May 2009 00:48:39 +0000 Subject: hg: jdk6/jdk6/jaxws: 6843041: Remove duplicate README files in repositories (make/README) Message-ID: <20090520004840.DF9B2E477@hg.openjdk.java.net> Changeset: 28a5b20dc295 Author: ohair Date: 2009-05-19 17:31 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/jaxws/rev/28a5b20dc295 6843041: Remove duplicate README files in repositories (make/README) Reviewed-by: robilad - make/README From kelly.ohair at sun.com Tue May 19 17:52:58 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Wed, 20 May 2009 00:52:58 +0000 Subject: hg: jdk6/jdk6/jdk: 6843041: Remove duplicate README files in repositories (make/README) Message-ID: <20090520005306.12942E483@hg.openjdk.java.net> Changeset: c3f267b32c3b Author: ohair Date: 2009-05-19 17:29 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/c3f267b32c3b 6843041: Remove duplicate README files in repositories (make/README) Reviewed-by: robilad - make/README From kelly.ohair at sun.com Tue May 19 17:58:07 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Wed, 20 May 2009 00:58:07 +0000 Subject: hg: jdk6/jdk6/langtools: 6843041: Remove duplicate README files in repositories (make/README) Message-ID: <20090520005808.48930E48A@hg.openjdk.java.net> Changeset: 893f9fda8e01 Author: ohair Date: 2009-05-19 17:32 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/langtools/rev/893f9fda8e01 6843041: Remove duplicate README files in repositories (make/README) Reviewed-by: robilad - make/README From kelly.ohair at sun.com Tue May 19 18:28:28 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Wed, 20 May 2009 01:28:28 +0000 Subject: hg: jdk6/jdk6/corba: 6733313: corba build warnings: /bin/sh: gcc: not found Message-ID: <20090520012829.72B6EE4D8@hg.openjdk.java.net> Changeset: 69067d7c878d Author: ohair Date: 2009-05-19 18:08 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/corba/rev/69067d7c878d 6733313: corba build warnings: /bin/sh: gcc: not found Reviewed-by: tbell ! make/common/shared/Compiler-gcc.gmk ! make/common/shared/Compiler-sun.gmk From aph at redhat.com Thu May 21 06:54:09 2009 From: aph at redhat.com (aph at redhat.com) Date: Thu, 21 May 2009 13:54:09 +0000 Subject: hg: jdk6/jdk6/jdk: 6839133: lcms 1.18 update breaks ICC_ProfileRGB Tests Message-ID: <20090521135423.C6BE3E69D@hg.openjdk.java.net> Changeset: 9b0f73e7a137 Author: aph Date: 2009-05-21 14:48 +0100 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/9b0f73e7a137 6839133: lcms 1.18 update breaks ICC_ProfileRGB Tests Reviewed-by: avu, prr ! src/share/native/sun/java2d/cmm/lcms/LCMS.c From Kelly.Ohair at Sun.COM Thu May 21 09:17:22 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Thu, 21 May 2009 09:17:22 -0700 Subject: Build problems regarding missing README.html Message-ID: <4A157E92.6060300@sun.com> Already reviewed... but just for the record... 6843925: Fix broken images target, no README.html file found, wrong source dir for files http://cr.openjdk.java.net/~ohair/jdk6/6843925-LICENSE/webrev/ This change is on it's way, being test built now. --- FYI... The jdk6 (OpenJDK6) Makefiles still have the concept of OPENJDK=false or the idea of building a Sun JDK, this logic is not being used but in general it is left in the makefiles to better match up with jdk7 makefiles. -kto From kelly.ohair at sun.com Thu May 21 11:19:49 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Thu, 21 May 2009 18:19:49 +0000 Subject: hg: jdk6/jdk6/jdk: 6843925: Fix broken images target, no README.html file found, wrong source dir for files Message-ID: <20090521182003.BFE22E779@hg.openjdk.java.net> Changeset: c00f461c45bc Author: ohair Date: 2009-05-21 09:11 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/c00f461c45bc 6843925: Fix broken images target, no README.html file found, wrong source dir for files Reviewed-by: darcy - make/ASSEMBLY_EXCEPTION - make/LICENSE - make/THIRD_PARTY_README - make/TRADEMARK ! make/common/Release.gmk From doko at ubuntu.com Tue May 26 03:12:31 2009 From: doko at ubuntu.com (Matthias Klose) Date: Tue, 26 May 2009 12:12:31 +0200 Subject: OpenJDK7 b59 still contains licenses which hinder inclusion in linux distributions Message-ID: <4A1BC08F.5020700@ubuntu.com> While updating packages for OpenJDK7, I see that there are unfortunately still some license issues pending. These files are removed when running the fsg.sh script, but still included in the jdk tarball downloaded during the icedtea build. However I don't see any bug reports filed for these as a dependency of IcedTea report #138. Did we address license issues with binary files which don't carry license/copyright notives itself, like jdk/test/sun/net/idn/*.spp ? Matthias rm -f \ openjdk/jdk/test/java/util/ResourceBundle/Bug4168625Resource3.java \ openjdk/jdk/test/java/util/ResourceBundle/Bug4168625Resource3_en_IE.java \ openjdk/jdk/test/java/util/ResourceBundle/Bug4165815Test.java \ openjdk/jdk/test/java/util/ResourceBundle/Bug4177489_Resource_jf.java \ openjdk/jdk/test/java/util/ResourceBundle/Bug4168625Resource3_en_CA.java \ openjdk/jdk/test/java/util/ResourceBundle/Bug4168625Getter.java \ openjdk/jdk/test/java/util/ResourceBundle/Bug4177489Test.java \ openjdk/jdk/test/java/util/ResourceBundle/Bug4168625Resource.java \ openjdk/jdk/test/java/util/ResourceBundle/Bug4168625Resource2.java \ openjdk/jdk/test/java/util/ResourceBundle/Bug4168625Resource3_en_US.java \ openjdk/jdk/test/java/util/ResourceBundle/Bug4083270Test.java \ openjdk/jdk/test/java/util/ResourceBundle/Bug4168625Resource3_en.java \ openjdk/jdk/test/java/util/ResourceBundle/Bug4177489_Resource.java \ openjdk/jdk/test/java/util/ResourceBundle/Bug4168625Test.java \ openjdk/jdk/test/java/util/ResourceBundle/Bug4168625Resource2_en_US.java \ openjdk/jdk/test/java/util/ResourceBundle/Bug4168625Class.java \ openjdk/jdk/test/java/util/Locale/Bug4175998Test.java \ openjdk/jdk/test/java/util/ResourceBundle/RBTestFmwk.java \ openjdk/jdk/test/java/util/ResourceBundle/TestResource_fr.java \ openjdk/jdk/test/java/util/ResourceBundle/Bug4179766Resource.java \ openjdk/jdk/test/java/util/ResourceBundle/Bug4179766Getter.java \ openjdk/jdk/test/java/util/ResourceBundle/Bug4179766Class.java \ openjdk/jdk/test/java/util/ResourceBundle/TestResource.java \ openjdk/jdk/test/java/util/ResourceBundle/FakeTestResource.java \ openjdk/jdk/test/java/util/ResourceBundle/TestResource_de.java \ openjdk/jdk/test/java/util/ResourceBundle/TestBug4179766.java \ openjdk/jdk/test/java/util/ResourceBundle/TestResource_fr_CH.java \ openjdk/jdk/test/java/util/ResourceBundle/ResourceBundleTest.java \ openjdk/jdk/test/java/util/ResourceBundle/TestResource_it.java \ openjdk/jdk/test/java/util/Locale/PrintDefaultLocale.java \ openjdk/jdk/test/java/util/Locale/LocaleTest.java \ openjdk/jdk/test/java/util/Locale/LocaleTestFmwk.java \ openjdk/jdk/test/java/util/Locale/Bug4184873Test.java \ openjdk/jdk/test/sun/text/resources/LocaleDataTest.java # Remove J2DBench sources, some of which have questionable license # headers. rm -rf \ openjdk/jdk/src/share/demo/java2d/J2DBench From gnu_andrew at member.fsf.org Tue May 26 03:25:26 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 26 May 2009 11:25:26 +0100 Subject: OpenJDK7 b59 still contains licenses which hinder inclusion in linux distributions In-Reply-To: <4A1BC08F.5020700@ubuntu.com> References: <4A1BC08F.5020700@ubuntu.com> Message-ID: <17c6771e0905260325q550876eem25513cb3ca4c7bac@mail.gmail.com> 2009/5/26 Matthias Klose : > While updating packages for OpenJDK7, I see that there are unfortunately still > some license issues pending. These files are removed when running the fsg.sh > script, but still included in the jdk tarball downloaded during the icedtea > build. However I don't see any bug reports filed for these as a dependency of > IcedTea report #138. > > Did we address license issues with binary files which don't carry > license/copyright notives itself, like jdk/test/sun/net/idn/*.spp ? > > ?Matthias > > > rm -f \ > ? openjdk/jdk/test/java/util/ResourceBundle/Bug4168625Resource3.java \ > ? openjdk/jdk/test/java/util/ResourceBundle/Bug4168625Resource3_en_IE.java \ > ? openjdk/jdk/test/java/util/ResourceBundle/Bug4165815Test.java \ > ? openjdk/jdk/test/java/util/ResourceBundle/Bug4177489_Resource_jf.java \ > ? openjdk/jdk/test/java/util/ResourceBundle/Bug4168625Resource3_en_CA.java \ > ? openjdk/jdk/test/java/util/ResourceBundle/Bug4168625Getter.java \ > ? openjdk/jdk/test/java/util/ResourceBundle/Bug4177489Test.java \ > ? openjdk/jdk/test/java/util/ResourceBundle/Bug4168625Resource.java \ > ? openjdk/jdk/test/java/util/ResourceBundle/Bug4168625Resource2.java \ > ? openjdk/jdk/test/java/util/ResourceBundle/Bug4168625Resource3_en_US.java \ > ? openjdk/jdk/test/java/util/ResourceBundle/Bug4083270Test.java \ > ? openjdk/jdk/test/java/util/ResourceBundle/Bug4168625Resource3_en.java \ > ? openjdk/jdk/test/java/util/ResourceBundle/Bug4177489_Resource.java \ > ? openjdk/jdk/test/java/util/ResourceBundle/Bug4168625Test.java \ > ? openjdk/jdk/test/java/util/ResourceBundle/Bug4168625Resource2_en_US.java \ > ? openjdk/jdk/test/java/util/ResourceBundle/Bug4168625Class.java \ > ? openjdk/jdk/test/java/util/Locale/Bug4175998Test.java \ > ? openjdk/jdk/test/java/util/ResourceBundle/RBTestFmwk.java \ > ? openjdk/jdk/test/java/util/ResourceBundle/TestResource_fr.java \ > ? openjdk/jdk/test/java/util/ResourceBundle/Bug4179766Resource.java \ > ? openjdk/jdk/test/java/util/ResourceBundle/Bug4179766Getter.java \ > ? openjdk/jdk/test/java/util/ResourceBundle/Bug4179766Class.java \ > ? openjdk/jdk/test/java/util/ResourceBundle/TestResource.java \ > ? openjdk/jdk/test/java/util/ResourceBundle/FakeTestResource.java \ > ? openjdk/jdk/test/java/util/ResourceBundle/TestResource_de.java \ > ? openjdk/jdk/test/java/util/ResourceBundle/TestBug4179766.java \ > ? openjdk/jdk/test/java/util/ResourceBundle/TestResource_fr_CH.java \ > ? openjdk/jdk/test/java/util/ResourceBundle/ResourceBundleTest.java \ > ? openjdk/jdk/test/java/util/ResourceBundle/TestResource_it.java \ > ? openjdk/jdk/test/java/util/Locale/PrintDefaultLocale.java \ > ? openjdk/jdk/test/java/util/Locale/LocaleTest.java \ > ? openjdk/jdk/test/java/util/Locale/LocaleTestFmwk.java \ > ? openjdk/jdk/test/java/util/Locale/Bug4184873Test.java \ > ? openjdk/jdk/test/sun/text/resources/LocaleDataTest.java > > # Remove J2DBench sources, some of which have questionable license > # headers. > rm -rf \ > ?openjdk/jdk/src/share/demo/java2d/J2DBench > Please file a bug or bugs for these. I don't recall seeing this discussed at all, but the script has been in IcedTea{6,7} for about a year. -- 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 May 26 15:43:56 2009 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Tue, 26 May 2009 15:43:56 -0700 Subject: [Fwd: Re: Request for approval: Bugs 6837665 and 6829575] In-Reply-To: <4A12F1B1.4050700@redhat.com> References: <4A12F1B1.4050700@redhat.com> Message-ID: <4A1C70AC.5070605@sun.com> Hi Andrew. On 05/19/09 10:51 AM, Andrew Haley wrote: > I think I sent it to the wrong list. > > Forwarding to jdk6-dev instead of build-dev. > > Andrew. > > > ------------------------------------------------------------------------ > > Subject: > Re: Request for approval: Bugs 6837665 and 6829575 > From: > Andrew Haley > Date: > Tue, 19 May 2009 18:26:57 +0100 > To: > Jonathan Gibbons > > To: > Jonathan Gibbons > CC: > "build-dev at openjdk.java.net" > > > Jonathan Gibbons wrote: > >> That's an exceedingly old file you have there -- langtools >> src/share/opensource/* should have disappered a long time ago. >> > > Hmm, I checked it out of the repository an hour or so ago. > > `hg parents' says > > changeset: 43:9820754525dd > tag: tip > user: ohair > date: Wed May 06 12:01:57 2009 -0700 > summary: 6831225: Upgrade JPRT jobs to use newer Linux 2.6 (e.g. Fedora 9) > > Andrew. > > > >> On May 19, 2009, at 9:58 AM, Andrew Haley wrote: >> >> >>> This is for the OpenJDK 6 trees. >>> >>> The patch is very similar to that now committed to OpenJDK 7, but it >>> touches a few more places that control debuginfo. >>> >>> http://cr.openjdk.java.net/~aph/6829575-jdk6-webrev/ >>> >>> Andrew. >>> Catching up on email, I approve this going back into OpenJDK 6 assuming successful builds on the plain OpenJDK 6 forest have been done. What is the difference between the OpenJDK 6 patch and the JDK 7 patch? Thanks, -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20090526/c92242a2/attachment.html From aph at redhat.com Wed May 27 01:20:46 2009 From: aph at redhat.com (Andrew Haley) Date: Wed, 27 May 2009 09:20:46 +0100 Subject: [Fwd: Re: Request for approval: Bugs 6837665 and 6829575] In-Reply-To: <4A1C70AC.5070605@sun.com> References: <4A12F1B1.4050700@redhat.com> <4A1C70AC.5070605@sun.com> Message-ID: <4A1CF7DE.5030805@redhat.com> Joe Darcy wrote: >>> On May 19, 2009, at 9:58 AM, Andrew Haley wrote: >>> >>> >>>> This is for the OpenJDK 6 trees. >>>> >>>> The patch is very similar to that now committed to OpenJDK 7, but it >>>> touches a few more places that control debuginfo. >>>> >>>> http://cr.openjdk.java.net/~aph/6829575-jdk6-webrev/ >>>> >>>> Andrew. >>>> > > Catching up on email, I approve this going back into OpenJDK 6 assuming > successful builds on the plain OpenJDK 6 forest have been done. > > What is the difference between the OpenJDK 6 patch and the JDK 7 patch? Reviewing it again, there is nothing of any significance. The 7 patch doesn't apply because the surrounding text is different, but the changes are identical. Andrew. From Joe.Darcy at Sun.COM Wed May 27 02:13:34 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Wed, 27 May 2009 02:13:34 -0700 Subject: [Fwd: Re: Request for approval: Bugs 6837665 and 6829575] In-Reply-To: <4A1CF7DE.5030805@redhat.com> References: <4A12F1B1.4050700@redhat.com> <4A1C70AC.5070605@sun.com> <4A1CF7DE.5030805@redhat.com> Message-ID: <4A1D043E.2050706@sun.com> Andrew Haley wrote: > Joe Darcy wrote: > > >>>> On May 19, 2009, at 9:58 AM, Andrew Haley wrote: >>>> >>>> >>>> >>>>> This is for the OpenJDK 6 trees. >>>>> >>>>> The patch is very similar to that now committed to OpenJDK 7, but it >>>>> touches a few more places that control debuginfo. >>>>> >>>>> http://cr.openjdk.java.net/~aph/6829575-jdk6-webrev/ >>>>> >>>>> Andrew. >>>>> >>>>> >> Catching up on email, I approve this going back into OpenJDK 6 assuming >> successful builds on the plain OpenJDK 6 forest have been done. >> >> What is the difference between the OpenJDK 6 patch and the JDK 7 patch? >> > > Reviewing it again, there is nothing of any significance. The 7 patch > doesn't apply because the surrounding text is different, but the changes > are identical. > > > Ah, good to know; approved with known-good build results :-) -Joe From Kelly.Ohair at Sun.COM Wed May 27 09:17:02 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Wed, 27 May 2009 09:17:02 -0700 Subject: [Fwd: Re: Request for approval: Bugs 6837665 and 6829575] In-Reply-To: <4A1CF7DE.5030805@redhat.com> References: <4A12F1B1.4050700@redhat.com> <4A1C70AC.5070605@sun.com> <4A1CF7DE.5030805@redhat.com> Message-ID: <4A1D677E.20304@sun.com> Andrew Haley wrote: > Joe Darcy wrote: > >>>> On May 19, 2009, at 9:58 AM, Andrew Haley wrote: >>>> >>>> >>>>> This is for the OpenJDK 6 trees. >>>>> >>>>> The patch is very similar to that now committed to OpenJDK 7, but it >>>>> touches a few more places that control debuginfo. >>>>> >>>>> http://cr.openjdk.java.net/~aph/6829575-jdk6-webrev/ >>>>> >>>>> Andrew. >>>>> >> Catching up on email, I approve this going back into OpenJDK 6 assuming >> successful builds on the plain OpenJDK 6 forest have been done. >> >> What is the difference between the OpenJDK 6 patch and the JDK 7 patch? > > Reviewing it again, there is nothing of any significance. The 7 patch > doesn't apply because the surrounding text is different, but the changes > are identical. > > Andrew. I think there is that annoying hotspot/make -> hotspot/build file movement issue too. :^( I'll be glad when that goes away. -kto From aph at redhat.com Thu May 28 09:42:29 2009 From: aph at redhat.com (aph at redhat.com) Date: Thu, 28 May 2009 16:42:29 +0000 Subject: hg: jdk6/jdk6: 6829575: 100028: Debug information is incomplete or missing Message-ID: <20090528164229.C7EB1EC9B@hg.openjdk.java.net> Changeset: 87ef479db131 Author: aph Date: 2009-05-28 17:38 +0100 URL: http://hg.openjdk.java.net/jdk6/jdk6/rev/87ef479db131 6829575: 100028: Debug information is incomplete or missing Summary: Enable debugging in many places Reviewed-by: ohair, darcy ! make/sanity-rules.gmk From aph at redhat.com Thu May 28 09:49:38 2009 From: aph at redhat.com (aph at redhat.com) Date: Thu, 28 May 2009 16:49:38 +0000 Subject: hg: jdk6/jdk6/langtools: 6829575: 100028: Debug information is incomplete or missing Message-ID: <20090528164939.8C598ECAF@hg.openjdk.java.net> Changeset: 820cfad51358 Author: aph Date: 2009-05-28 17:43 +0100 URL: http://hg.openjdk.java.net/jdk6/jdk6/langtools/rev/820cfad51358 6829575: 100028: Debug information is incomplete or missing Summary: Enable debugging in many places Reviewed-by: ohair, darcy ! make/Makefile ! make/build.xml ! src/share/opensource/javac/build.xml From aph at redhat.com Thu May 28 09:50:23 2009 From: aph at redhat.com (aph at redhat.com) Date: Thu, 28 May 2009 16:50:23 +0000 Subject: hg: jdk6/jdk6/jaxws: 6829575: 100028: Debug information is incomplete or missing Message-ID: <20090528165025.146A7ECB1@hg.openjdk.java.net> Changeset: 1ff1b8b0ee57 Author: aph Date: 2009-05-28 17:45 +0100 URL: http://hg.openjdk.java.net/jdk6/jdk6/jaxws/rev/1ff1b8b0ee57 6829575: 100028: Debug information is incomplete or missing Summary: Enable debugging in many places Reviewed-by: ohair, darcy ! make/Makefile ! make/build.properties ! make/build.xml From aph at redhat.com Thu May 28 09:57:38 2009 From: aph at redhat.com (aph at redhat.com) Date: Thu, 28 May 2009 16:57:38 +0000 Subject: hg: jdk6/jdk6/hotspot: 6829575: 100028: Debug information is incomplete or missing Message-ID: <20090528165740.15321ECCE@hg.openjdk.java.net> Changeset: fc30e742f2fc Author: aph Date: 2009-05-28 17:52 +0100 URL: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/fc30e742f2fc 6829575: 100028: Debug information is incomplete or missing Summary: Enable debugging in many places Reviewed-by: ohair, darcy ! build/linux/makefiles/gcc.make ! build/linux/makefiles/jsig.make ! build/linux/makefiles/saproc.make From aph at redhat.com Thu May 28 09:59:30 2009 From: aph at redhat.com (aph at redhat.com) Date: Thu, 28 May 2009 16:59:30 +0000 Subject: hg: jdk6/jdk6/jaxp: 6829575: 100028: Debug information is incomplete or missing Message-ID: <20090528165931.79262ECE0@hg.openjdk.java.net> Changeset: 5061aedfdebd Author: aph Date: 2009-05-28 17:53 +0100 URL: http://hg.openjdk.java.net/jdk6/jdk6/jaxp/rev/5061aedfdebd 6829575: 100028: Debug information is incomplete or missing Summary: Enable debugging in many places Reviewed-by: ohair, darcy ! make/Makefile ! make/build.properties ! make/build.xml From aph at redhat.com Thu May 28 10:03:45 2009 From: aph at redhat.com (aph at redhat.com) Date: Thu, 28 May 2009 17:03:45 +0000 Subject: hg: jdk6/jdk6/jdk: 6829575: 100028: Debug information is incomplete or missing Message-ID: <20090528170353.164ACECE2@hg.openjdk.java.net> Changeset: 5545eacf4264 Author: aph Date: 2009-05-28 17:58 +0100 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/5545eacf4264 6829575: 100028: Debug information is incomplete or missing Summary: Enable debugging in many places Reviewed-by: ohair, darcy ! make/common/Defs-linux.gmk ! make/sun/awt/mawt.gmk From gnu_andrew at member.fsf.org Thu May 28 17:52:36 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 29 May 2009 01:52:36 +0100 Subject: HotSpot 14 In-Reply-To: <4A0DB273.9060908@sun.com> References: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> <4A0DB273.9060908@sun.com> Message-ID: <17c6771e0905281752v5f925e7cm9390a2eac4a6d600@mail.gmail.com> 2009/5/15 Erik Trimble : > Andrew John Hughes wrote: >> >> Hi all (especially Joe), >> >> Now that the HotSpot Express repositories are available, what is the >> plan for including hs14 in OpenJDK6? >> >> I did a pull of the base changeset from HS express (0) into OpenJDK6's >> hotspot repo. yesterday as a test, and it seems to apply fairly well. >> The conflicts all seem to be whitespace changes (though there's a lot >> of them -- ~210 files are affected). >> >> Do we still plan to maintain a version of HotSpot in OpenJDK6 or will >> HS Express just be used directly? >> >> Thanks, >> > > Frankly, I think this is up to the Community. > > I'm still not 100% sure of the complete list of who has write access to the > OpenJDK6 stuff, but I /think/ the proper way to do this is not move any HSX > release into the main OpenJDK6 forest until there is ?consensus that It's > Time. > > Now, that said, maybe It's Time Right Now. > > > Given that the HSX repos are going to be almost exclusively Sun-only > writable (in practice, not necessarily by design), I think that the VM in > OpenJDK6 should be pulled from an HSX repo, and then have various > community-desired patches applied there, rather than try to work directly on > an HSX repo. ?That is, I expect the various HSX repos to be a reflection of > what Sun is doing, and the VM in OpenJDK6 should be a reflection of what the > Community chooses to do with the HSX work from Sun. > > As such, going forward, I _hope_ there is less and less of a requirement to > maintain IceTea, and that everything there can get moved over into the > appropriate OpenJDK repo. ?Not that I have anything against IceTea, it just > would be nice to cut down on the amount of work needed to maintain all these > separate codebases. > > -- > Erik Trimble > Java System Support > Mailstop: ?usca22-123 > Phone: ?x17195 > Santa Clara, CA > Timezone: US/Pacific (GMT-0800) > > I haven't seen any further movement on this; what's the progress on getting HotSpot updated/removed from OpenJDK6? It seems Sun just shipped a 6u14 release, and this included hs14b16. Strange then, that the new HotSpot Express repositories only have up to hs14b15. Deja vu? -- 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 Erik.Trimble at Sun.COM Thu May 28 17:59:14 2009 From: Erik.Trimble at Sun.COM (Erik Trimble) Date: Thu, 28 May 2009 17:59:14 -0700 Subject: HotSpot 14 In-Reply-To: <17c6771e0905281752v5f925e7cm9390a2eac4a6d600@mail.gmail.com> References: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> <4A0DB273.9060908@sun.com> <17c6771e0905281752v5f925e7cm9390a2eac4a6d600@mail.gmail.com> Message-ID: <4A1F3362.90509@sun.com> Andrew John Hughes wrote: > 2009/5/15 Erik Trimble : > >> Andrew John Hughes wrote: >> >>> Hi all (especially Joe), >>> >>> Now that the HotSpot Express repositories are available, what is the >>> plan for including hs14 in OpenJDK6? >>> >>> I did a pull of the base changeset from HS express (0) into OpenJDK6's >>> hotspot repo. yesterday as a test, and it seems to apply fairly well. >>> The conflicts all seem to be whitespace changes (though there's a lot >>> of them -- ~210 files are affected). >>> >>> Do we still plan to maintain a version of HotSpot in OpenJDK6 or will >>> HS Express just be used directly? >>> >>> Thanks, >>> >>> >> Frankly, I think this is up to the Community. >> >> I'm still not 100% sure of the complete list of who has write access to the >> OpenJDK6 stuff, but I /think/ the proper way to do this is not move any HSX >> release into the main OpenJDK6 forest until there is consensus that It's >> Time. >> >> Now, that said, maybe It's Time Right Now. >> >> >> Given that the HSX repos are going to be almost exclusively Sun-only >> writable (in practice, not necessarily by design), I think that the VM in >> OpenJDK6 should be pulled from an HSX repo, and then have various >> community-desired patches applied there, rather than try to work directly on >> an HSX repo. That is, I expect the various HSX repos to be a reflection of >> what Sun is doing, and the VM in OpenJDK6 should be a reflection of what the >> Community chooses to do with the HSX work from Sun. >> >> As such, going forward, I _hope_ there is less and less of a requirement to >> maintain IceTea, and that everything there can get moved over into the >> appropriate OpenJDK repo. Not that I have anything against IceTea, it just >> would be nice to cut down on the amount of work needed to maintain all these >> separate codebases. >> >> -- >> Erik Trimble >> Java System Support >> Mailstop: usca22-123 >> Phone: x17195 >> Santa Clara, CA >> Timezone: US/Pacific (GMT-0800) >> >> >> > > I haven't seen any further movement on this; what's the progress on > getting HotSpot updated/removed from OpenJDK6? > > It seems Sun just shipped a 6u14 release, and this included hs14b16. > Strange then, that the new HotSpot Express repositories only have up > to hs14b15. Deja vu? > I've been distracted with the JavaOne stuff and some internal work. I'll push the latest hs14b16 work (it's one patch) into the HSX14 repo now. We still need to have a discussion again about where future (external) work on HS14 goes, and if we want to push HSX14 to the Open6 repo now. -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) From Kelly.Ohair at Sun.COM Thu May 28 18:12:14 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Thu, 28 May 2009 18:12:14 -0700 Subject: Hotspot shell games In-Reply-To: <17c6771e0905281752v5f925e7cm9390a2eac4a6d600@mail.gmail.com> References: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> <4A0DB273.9060908@sun.com> <17c6771e0905281752v5f925e7cm9390a2eac4a6d600@mail.gmail.com> Message-ID: <4A1F366E.9010801@sun.com> Erik, If this information is publicly out there already, point me at it. Otherwise, it would be really nice to know what Hotspot is in what jdk6 or jdk7 release, where the repo is available at, and maybe a flow diagram as to how changes get from one to the other. Between the odd situation with openjdk6, the hsx repos, the jdk7 hotspot forests, and the built hotspots delivered into jdk6uNN releases, it's quite confusing. The page at http://openjdk.java.net/groups/hotspot/ would be an ideal place to put it, which is so old it still refers to svn access. :^( Let me know if you need the magic formula to update the webpages. -kto From Erik.Trimble at Sun.COM Thu May 28 18:21:38 2009 From: Erik.Trimble at Sun.COM (Erik Trimble) Date: Thu, 28 May 2009 18:21:38 -0700 Subject: Hotspot shell games In-Reply-To: <4A1F366E.9010801@sun.com> References: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> <4A0DB273.9060908@sun.com> <17c6771e0905281752v5f925e7cm9390a2eac4a6d600@mail.gmail.com> <4A1F366E.9010801@sun.com> Message-ID: <4A1F38A2.2090505@sun.com> Kelly O'Hair wrote: > Erik, > > If this information is publicly out there already, point me at it. > Otherwise, it would be really nice to know what Hotspot is in what > jdk6 or jdk7 release, where the repo is available at, and maybe > a flow diagram as to how changes get from one to the other. > > Between the odd situation with openjdk6, the hsx repos, the jdk7 > hotspot forests, and the built hotspots delivered into jdk6uNN releases, > it's quite confusing. > > The page at http://openjdk.java.net/groups/hotspot/ > would be an ideal place to put it, which is so old it still refers > to svn access. :^( > Let me know if you need the magic formula to update the webpages. > > -kto That's eminently rational. What are you doing, injecting reason into this? I'll talk to you offline about getting that page updated with all the relevant info. For now, though, we need to decide how to handle HSX vs Open6 vs. IceTea. -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) From mark at klomp.org Fri May 29 01:02:56 2009 From: mark at klomp.org (Mark Wielaard) Date: Fri, 29 May 2009 10:02:56 +0200 Subject: Hotspot shell games In-Reply-To: <4A1F38A2.2090505@sun.com> References: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> <4A0DB273.9060908@sun.com> <17c6771e0905281752v5f925e7cm9390a2eac4a6d600@mail.gmail.com> <4A1F366E.9010801@sun.com> <4A1F38A2.2090505@sun.com> Message-ID: <1243584176.4800.30.camel@hermans.wildebeest.org> Hi, On Thu, 2009-05-28 at 18:21 -0700, Erik Trimble wrote: > For now, though, we need to decide how to handle HSX vs Open6 vs. IceTea. For IcedTea the requirements are pretty simple. We want one baseline Hotspot for doing i586/x86_64/sparc builds and other zero/shark platform builds (there is also the cacao build, but that is not really relevant here, since that just totally replaces hotspot with a cacao based libjvm.so). This wasn't possible with the older hotspot releases, and keeping all the patches up to date across hotspot hs11 (old openjdk6), hs12 (new openjdk6) and hs14 just was too much work (and somewhat fragile), also hs14 is much closer to what is in openjdk7 and icedtea7, which makes forward porting the icedtea6 patches to icedtea7 much easier. So what IcedTea does now is by default just pick off the tip (well actually explicitly defined hg rev, that has to be updated by hand, to make sure someone double checks all changes are sane and all patches apply cleanly) of hsx14 master archive (you can configure with alternative hotspot releases if you like though). Cheers, Mark From David.Cox at Sun.COM Fri May 29 01:54:37 2009 From: David.Cox at Sun.COM (David Cox) Date: Fri, 29 May 2009 01:54:37 -0700 Subject: HotSpot 14 In-Reply-To: <4A1F3362.90509@sun.com> References: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> <4A0DB273.9060908@sun.com> <17c6771e0905281752v5f925e7cm9390a2eac4a6d600@mail.gmail.com> <4A1F3362.90509@sun.com> Message-ID: <4A1FA2CD.9040603@sun.com> Hi, Erik Trimble wrote: > Andrew John Hughes wrote: >> 2009/5/15 Erik Trimble : >> >>> Andrew John Hughes wrote: >>> >>>> Hi all (especially Joe), >>>> >>>> Now that the HotSpot Express repositories are available, what is the >>>> plan for including hs14 in OpenJDK6? >>>> >>>> I did a pull of the base changeset from HS express (0) into OpenJDK6's >>>> hotspot repo. yesterday as a test, and it seems to apply fairly well. >>>> The conflicts all seem to be whitespace changes (though there's a lot >>>> of them -- ~210 files are affected). >>>> >>>> Do we still plan to maintain a version of HotSpot in OpenJDK6 or will >>>> HS Express just be used directly? >>>> >>>> Thanks, >>>> >>>> >>> Frankly, I think this is up to the Community. >>> >>> I'm still not 100% sure of the complete list of who has write access >>> to the >>> OpenJDK6 stuff, but I /think/ the proper way to do this is not move >>> any HSX >>> release into the main OpenJDK6 forest until there is consensus that >>> It's >>> Time. >>> >>> Now, that said, maybe It's Time Right Now. >>> >>> >>> Given that the HSX repos are going to be almost exclusively Sun-only >>> writable (in practice, not necessarily by design), I think that the >>> VM in >>> OpenJDK6 should be pulled from an HSX repo, and then have various >>> community-desired patches applied there, rather than try to work >>> directly on >>> an HSX repo. That is, I expect the various HSX repos to be a >>> reflection of >>> what Sun is doing, and the VM in OpenJDK6 should be a reflection of >>> what the >>> Community chooses to do with the HSX work from Sun. >>> >>> As such, going forward, I _hope_ there is less and less of a >>> requirement to >>> maintain IceTea, and that everything there can get moved over into the >>> appropriate OpenJDK repo. Not that I have anything against IceTea, >>> it just >>> would be nice to cut down on the amount of work needed to maintain >>> all these >>> separate codebases. >>> >>> -- >>> Erik Trimble >>> Java System Support >>> Mailstop: usca22-123 >>> Phone: x17195 >>> Santa Clara, CA >>> Timezone: US/Pacific (GMT-0800) >>> >>> >>> >> >> I haven't seen any further movement on this; what's the progress on >> getting HotSpot updated/removed from OpenJDK6? >> >> It seems Sun just shipped a 6u14 release, and this included hs14b16. >> Strange then, that the new HotSpot Express repositories only have up >> to hs14b15. Deja vu? >> > > I've been distracted with the JavaOne stuff and some internal work. > > I'll push the latest hs14b16 work (it's one patch) into the HSX14 repo > now. > > We still need to have a discussion again about where future (external) > work on HS14 goes, and if we want to push HSX14 to the Open6 repo now. After pushing the late-breaking fix to the Serviceability Agent in Sun's hs14-b16 to OpenJDK's hsx/hsx14, I think hsx14 should be merged into OpenJDK 6. If the HotSpot Express Project is to host the "tip" of open HotSpot development, then the changeset that was recently made to HotSpot make files in OpenJDK 6 (http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/fc30e742f2fc) should also be applied to hsx/hsx14. However, that presents a problem. Sun is now supporting HotSpot 14.0 with our Java SE for Business product. Given that Sun will create its own branches (builds) of HotSpot 14.n, how should the VM in hsx/hsx14 be identified? What constitutes a build of hsx14? Dave From gnu_andrew at member.fsf.org Fri May 29 04:56:55 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 29 May 2009 12:56:55 +0100 Subject: Hotspot shell games In-Reply-To: <4A1F38A2.2090505@sun.com> References: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> <4A0DB273.9060908@sun.com> <17c6771e0905281752v5f925e7cm9390a2eac4a6d600@mail.gmail.com> <4A1F366E.9010801@sun.com> <4A1F38A2.2090505@sun.com> Message-ID: <17c6771e0905290456j7c3b62f8xee36460943abe374@mail.gmail.com> 2009/5/29 Erik Trimble : > Kelly O'Hair wrote: >> >> Erik, >> >> If this information is publicly out there already, point me at it. >> Otherwise, it would be really nice to know what Hotspot is in what >> jdk6 or jdk7 release, where the repo is available at, and maybe >> a flow diagram as to how changes get from one to the other. >> >> Between the odd situation with openjdk6, the hsx repos, the jdk7 >> hotspot forests, and the built hotspots delivered into jdk6uNN releases, >> it's quite confusing. >> >> The page at http://openjdk.java.net/groups/hotspot/ >> would be an ideal place to put it, which is so old it still refers >> to svn access. :^( >> Let me know if you need the magic formula to update the webpages. >> >> -kto > > That's eminently rational. What are you doing, injecting reason into this? > > > > I'll talk to you offline about getting that page updated with all the > relevant info. > > For now, though, we need to decide how to handle HSX vs Open6 vs. IceTea. > > -- > Erik Trimble > Java System Support > Mailstop: ?usca22-123 > Phone: ?x17195 > Santa Clara, CA > Timezone: US/Pacific (GMT-0800) > > Simplest solution would be to just remove it from OpenJDK6 and use HSX as the upstream. I don't see an advantage to pulling in to OpenJDK6, given there is already a 'stable' branch of HSX. -- 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 May 29 05:06:39 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 29 May 2009 13:06:39 +0100 Subject: HotSpot 14 In-Reply-To: <4A1FA2CD.9040603@sun.com> References: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> <4A0DB273.9060908@sun.com> <17c6771e0905281752v5f925e7cm9390a2eac4a6d600@mail.gmail.com> <4A1F3362.90509@sun.com> <4A1FA2CD.9040603@sun.com> Message-ID: <17c6771e0905290506i49ecdb2dt62e92f90a67bd89b@mail.gmail.com> 2009/5/29 David Cox : > Hi, > > Erik Trimble wrote: >> >> Andrew John Hughes wrote: >>> >>> 2009/5/15 Erik Trimble : >>> >>>> >>>> Andrew John Hughes wrote: >>>> >>>>> >>>>> Hi all (especially Joe), >>>>> >>>>> Now that the HotSpot Express repositories are available, what is the >>>>> plan for including hs14 in OpenJDK6? >>>>> >>>>> I did a pull of the base changeset from HS express (0) into OpenJDK6's >>>>> hotspot repo. yesterday as a test, and it seems to apply fairly well. >>>>> The conflicts all seem to be whitespace changes (though there's a lot >>>>> of them -- ~210 files are affected). >>>>> >>>>> Do we still plan to maintain a version of HotSpot in OpenJDK6 or will >>>>> HS Express just be used directly? >>>>> >>>>> Thanks, >>>>> >>>>> >>>> >>>> Frankly, I think this is up to the Community. >>>> >>>> I'm still not 100% sure of the complete list of who has write access to >>>> the >>>> OpenJDK6 stuff, but I /think/ the proper way to do this is not move any >>>> HSX >>>> release into the main OpenJDK6 forest until there is ?consensus that >>>> It's >>>> Time. >>>> >>>> Now, that said, maybe It's Time Right Now. >>>> >>>> >>>> Given that the HSX repos are going to be almost exclusively Sun-only >>>> writable (in practice, not necessarily by design), I think that the VM >>>> in >>>> OpenJDK6 should be pulled from an HSX repo, and then have various >>>> community-desired patches applied there, rather than try to work >>>> directly on >>>> an HSX repo. ?That is, I expect the various HSX repos to be a reflection >>>> of >>>> what Sun is doing, and the VM in OpenJDK6 should be a reflection of what >>>> the >>>> Community chooses to do with the HSX work from Sun. >>>> >>>> As such, going forward, I _hope_ there is less and less of a requirement >>>> to >>>> maintain IceTea, and that everything there can get moved over into the >>>> appropriate OpenJDK repo. ?Not that I have anything against IceTea, it >>>> just >>>> would be nice to cut down on the amount of work needed to maintain all >>>> these >>>> separate codebases. >>>> >>>> -- >>>> Erik Trimble >>>> Java System Support >>>> Mailstop: ?usca22-123 >>>> Phone: ?x17195 >>>> Santa Clara, CA >>>> Timezone: US/Pacific (GMT-0800) >>>> >>>> >>>> >>> >>> I haven't seen any further movement on this; what's the progress on >>> getting HotSpot updated/removed from OpenJDK6? >>> >>> It seems Sun just shipped a 6u14 release, and this included hs14b16. >>> Strange then, that the new HotSpot Express repositories only have up >>> to hs14b15. ?Deja vu? >>> >> >> I've been distracted with the JavaOne stuff and some internal work. >> >> I'll push the latest hs14b16 work (it's one patch) into the HSX14 repo >> now. >> >> We still need to have a discussion again about where future (external) >> work on HS14 goes, and if we want to push HSX14 to the Open6 repo now. > > After pushing the late-breaking fix to the Serviceability Agent in Sun's > hs14-b16 to OpenJDK's hsx/hsx14, I think hsx14 should be merged into OpenJDK > 6. > > If the HotSpot Express Project is to host the "tip" of open HotSpot > development, then the changeset that was recently made to HotSpot make files > in ?OpenJDK 6 > (http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/fc30e742f2fc) should also > be applied to hsx/hsx14. ?However, that presents a problem. ?Sun is now > supporting HotSpot 14.0 with our Java SE for Business product. ?Given that > Sun will create its own branches (builds) of HotSpot 14.n, how should the VM > in hsx/hsx14 be identified? ?What constitutes a build of hsx14? > > Dave > Porting that changeset to hsx and getting rid of a local OpenJDK6 copy would seem the simplest solution long term. There doesn't seem to be an advantage in maintaining an OpenJDK6 copy. I don't really follow your other comments. I thought the intention with HotSpot Express is that it would be the branch of HotSpot 14.n that Sun ships. That was the whole point from my perspective, so we were all working on the same page. -- 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 volker.simonis at gmail.com Fri May 29 06:07:19 2009 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 29 May 2009 15:07:19 +0200 Subject: HotSpot 14 In-Reply-To: <17c6771e0905290506i49ecdb2dt62e92f90a67bd89b@mail.gmail.com> References: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> <4A0DB273.9060908@sun.com> <17c6771e0905281752v5f925e7cm9390a2eac4a6d600@mail.gmail.com> <4A1F3362.90509@sun.com> <4A1FA2CD.9040603@sun.com> <17c6771e0905290506i49ecdb2dt62e92f90a67bd89b@mail.gmail.com> Message-ID: Hi Andrew, nfortunately, things are not so easy as it may look like. Sun still has to keep a version for its licensees which (among other things) has the GPL license replaced by a Sun commercial licence. Moreover, that licensee repository may contain additional files which are not in the "open" version (like for example the ia64 port) and it may as well has some files removed, which are GPL only. My understanding until now was, that the HSX14 repository will be the main ("golden") repository, from which the others (e.g. the Sun internal licensee repository) will be branched off. And I agree with you that that would be the only reasonable configuration to allow collaboration in the "open". But after 6u14 was released with hs14-b16 and after Eriks mail where he mentioned that he will now "upgrade" the HSX14 repo to b16, this assumption seems to prove wrong (which is sad). The SE for Business stuff makes the things even more complicated. If I got that right, it means that Sun provides further updates and patches to its business clients for each update release (so they may build a 6u14u1 for one customer and perhaps a 6u14u1'u2' for another). If I understand David right, this means that they have to keep a lot of other "HSX14" repos in parallel, which are hard to keep in sync. Regards, Volker On 5/29/09, Andrew John Hughes wrote: > 2009/5/29 David Cox : > > > Hi, > > > > Erik Trimble wrote: > >> > >> Andrew John Hughes wrote: > >>> > >>> 2009/5/15 Erik Trimble : > >>> > >>>> > >>>> Andrew John Hughes wrote: > >>>> > >>>>> > >>>>> Hi all (especially Joe), > >>>>> > >>>>> Now that the HotSpot Express repositories are available, what is the > >>>>> plan for including hs14 in OpenJDK6? > >>>>> > >>>>> I did a pull of the base changeset from HS express (0) into OpenJDK6's > >>>>> hotspot repo. yesterday as a test, and it seems to apply fairly well. > >>>>> The conflicts all seem to be whitespace changes (though there's a lot > >>>>> of them -- ~210 files are affected). > >>>>> > >>>>> Do we still plan to maintain a version of HotSpot in OpenJDK6 or will > >>>>> HS Express just be used directly? > >>>>> > >>>>> Thanks, > >>>>> > >>>>> > >>>> > >>>> Frankly, I think this is up to the Community. > >>>> > >>>> I'm still not 100% sure of the complete list of who has write access to > >>>> the > >>>> OpenJDK6 stuff, but I /think/ the proper way to do this is not move any > >>>> HSX > >>>> release into the main OpenJDK6 forest until there is consensus that > >>>> It's > >>>> Time. > >>>> > >>>> Now, that said, maybe It's Time Right Now. > >>>> > >>>> > >>>> Given that the HSX repos are going to be almost exclusively Sun-only > >>>> writable (in practice, not necessarily by design), I think that the VM > >>>> in > >>>> OpenJDK6 should be pulled from an HSX repo, and then have various > >>>> community-desired patches applied there, rather than try to work > >>>> directly on > >>>> an HSX repo. That is, I expect the various HSX repos to be a reflection > >>>> of > >>>> what Sun is doing, and the VM in OpenJDK6 should be a reflection of what > >>>> the > >>>> Community chooses to do with the HSX work from Sun. > >>>> > >>>> As such, going forward, I _hope_ there is less and less of a requirement > >>>> to > >>>> maintain IceTea, and that everything there can get moved over into the > >>>> appropriate OpenJDK repo. Not that I have anything against IceTea, it > >>>> just > >>>> would be nice to cut down on the amount of work needed to maintain all > >>>> these > >>>> separate codebases. > >>>> > >>>> -- > >>>> Erik Trimble > >>>> Java System Support > >>>> Mailstop: usca22-123 > >>>> Phone: x17195 > >>>> Santa Clara, CA > >>>> Timezone: US/Pacific (GMT-0800) > >>>> > >>>> > >>>> > >>> > >>> I haven't seen any further movement on this; what's the progress on > >>> getting HotSpot updated/removed from OpenJDK6? > >>> > >>> It seems Sun just shipped a 6u14 release, and this included hs14b16. > >>> Strange then, that the new HotSpot Express repositories only have up > >>> to hs14b15. Deja vu? > >>> > >> > >> I've been distracted with the JavaOne stuff and some internal work. > >> > >> I'll push the latest hs14b16 work (it's one patch) into the HSX14 repo > >> now. > >> > >> We still need to have a discussion again about where future (external) > >> work on HS14 goes, and if we want to push HSX14 to the Open6 repo now. > > > > After pushing the late-breaking fix to the Serviceability Agent in Sun's > > hs14-b16 to OpenJDK's hsx/hsx14, I think hsx14 should be merged into OpenJDK > > 6. > > > > If the HotSpot Express Project is to host the "tip" of open HotSpot > > development, then the changeset that was recently made to HotSpot make files > > in OpenJDK 6 > > (http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/fc30e742f2fc) should also > > be applied to hsx/hsx14. However, that presents a problem. Sun is now > > supporting HotSpot 14.0 with our Java SE for Business product. Given that > > Sun will create its own branches (builds) of HotSpot 14.n, how should the VM > > in hsx/hsx14 be identified? What constitutes a build of hsx14? > > > > Dave > > > > > Porting that changeset to hsx and getting rid of a local OpenJDK6 copy > would seem the simplest solution long term. There doesn't seem to be > an advantage in maintaining an OpenJDK6 copy. > > I don't really follow your other comments. I thought the intention > with HotSpot Express is that it would be the branch of HotSpot 14.n > that Sun ships. That was the whole point from my perspective, so we > were all working on the same page. > > -- > 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 Fri May 29 09:18:50 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 29 May 2009 09:18:50 -0700 Subject: Hotspot shell games In-Reply-To: <17c6771e0905290456j7c3b62f8xee36460943abe374@mail.gmail.com> References: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> <4A0DB273.9060908@sun.com> <17c6771e0905281752v5f925e7cm9390a2eac4a6d600@mail.gmail.com> <4A1F366E.9010801@sun.com> <4A1F38A2.2090505@sun.com> <17c6771e0905290456j7c3b62f8xee36460943abe374@mail.gmail.com> Message-ID: <4A200AEA.3050809@sun.com> (removed jdk7-dev from this discussion) Andrew John Hughes wrote: > 2009/5/29 Erik Trimble : [snip] >> For now, though, we need to decide how to handle HSX vs Open6 vs. IceTea. > > Simplest solution would be to just remove it from OpenJDK6 and use HSX > as the upstream. I don't see an advantage to pulling in to OpenJDK6, > given there is already a 'stable' branch of HSX. I would prefer to keep a hotspot repository in the openjdk6 forest, just for the sake of having a buildable and complete source base. I would also like to have some level of confidence as to which hotspot is the default one for the openjdk6 project. Let's not leave a partial jdk6 forest sitting out there. To me the decision that needs to be made is whether you want the openjdk6 hotspot repository (jdk6/hotspot) 'related' to the other hotspot repositories, like hsx/hsx14/master is related to jdk7/hotspot. It doesn't have to be, and there are advantages and disadvantages to both approaches. None of the non-hotspot repositories in the openjdk6 forest are related to the jdk7 repositories, making them pretty independent from jdk7, but hotspot is somewhat special, and the express model I support, so... My suggestions... * Ignore hsx/hsx14, it's a drop not a development tree * Decide to make the jdk6 and jdk7 repositories 'related' * Tag the rev in the jdk7/hotspot repo with a name jdk6-b17, the rev that matches what is in the hsx14 repo * Toss the existing jdk6/hotspot repo and replace it with a repo created with: hg clone -r jdk6-b17 http://hg.openjdk.java.net/jdk7/hotspot jdk6/hotspot Changes going into jdk6/hotspot should be rare, critical, and should eventually be pushed back into jdk7/hotspot, indeed some critical fixes may get transplanted from jdk7/hotspot to jdk6/hotspot. If at some point it's decided to upgrade jdk6/hotspot to a newer rev, so be it, easy to do. And for heavens sake, start adding some hsx-* tags to the hotspot repository so we can easily clone hsx versions from the tag name, you could also use the hsx tag to hold the build number, I can help with that. -kto From Joe.Darcy at Sun.COM Fri May 29 09:30:06 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Fri, 29 May 2009 09:30:06 -0700 Subject: Hotspot shell games In-Reply-To: <17c6771e0905290456j7c3b62f8xee36460943abe374@mail.gmail.com> References: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> <4A0DB273.9060908@sun.com> <17c6771e0905281752v5f925e7cm9390a2eac4a6d600@mail.gmail.com> <4A1F366E.9010801@sun.com> <4A1F38A2.2090505@sun.com> <17c6771e0905290456j7c3b62f8xee36460943abe374@mail.gmail.com> Message-ID: <4A200D8E.6090008@sun.com> Andrew John Hughes wrote: > 2009/5/29 Erik Trimble : > >> Kelly O'Hair wrote: >> >>> Erik, >>> >>> If this information is publicly out there already, point me at it. >>> Otherwise, it would be really nice to know what Hotspot is in what >>> jdk6 or jdk7 release, where the repo is available at, and maybe >>> a flow diagram as to how changes get from one to the other. >>> >>> Between the odd situation with openjdk6, the hsx repos, the jdk7 >>> hotspot forests, and the built hotspots delivered into jdk6uNN releases, >>> it's quite confusing. >>> >>> The page at http://openjdk.java.net/groups/hotspot/ >>> would be an ideal place to put it, which is so old it still refers >>> to svn access. :^( >>> Let me know if you need the magic formula to update the webpages. >>> >>> -kto >>> >> That's eminently rational. What are you doing, injecting reason into this? >> >> >> >> I'll talk to you offline about getting that page updated with all the >> relevant info. >> >> For now, though, we need to decide how to handle HSX vs Open6 vs. IceTea. >> >> -- >> Erik Trimble >> Java System Support >> Mailstop: usca22-123 >> Phone: x17195 >> Santa Clara, CA >> Timezone: US/Pacific (GMT-0800) >> >> >> > > Simplest solution would be to just remove it from OpenJDK6 and use HSX > as the upstream. I don't see an advantage to pulling in to OpenJDK6, > given there is already a 'stable' branch of HSX. > Or, as I previously suggested, do a one-time sync to get the HotSpot in OpenJDK 6 current to HS 14 and then do whatever would have been done in the public HSX stabilization repo in the OpenJDK 6 repo. If IcedTea wants fewer or more fixes than in the OpenJDK 6 repo, I'm confident the IcedTea folks will be able to manage them :-) -Joe From volker.simonis at gmail.com Fri May 29 09:41:37 2009 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 29 May 2009 18:41:37 +0200 Subject: Hotspot shell games In-Reply-To: <4A200AEA.3050809@sun.com> References: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> <4A0DB273.9060908@sun.com> <17c6771e0905281752v5f925e7cm9390a2eac4a6d600@mail.gmail.com> <4A1F366E.9010801@sun.com> <4A1F38A2.2090505@sun.com> <17c6771e0905290456j7c3b62f8xee36460943abe374@mail.gmail.com> <4A200AEA.3050809@sun.com> Message-ID: > * Tag the rev in the jdk7/hotspot repo with a name jdk6-b17, the > rev that matches what is in the hsx14 repo Is this really possible? I thought the HS which is now in 6u14 (and in HSX14) was branched from the jdk7/hotspot sometimes around hotspot build 9/10 of the jdk7/hotspot. Afterwards, the hotspot version was incremented to 15 in jdk7/hotspot while there have been about six more builds of HS 14 in the HSX14 repository. From my understanding, the change history in jdk7/hotspot and HSX14 is different after HSX has been branched off from jdk7/hotspot and I can't imagine how one can now find a changeset in jdk7/hotspot which matches the hotspot version in HSX14. After all, the whole purpose of branching HSX14 is to stabilize it while the development can proceed in jdk7/hotspot. Or am I missing something here? Regards, Volker From Kelly.Ohair at Sun.COM Fri May 29 11:01:35 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 29 May 2009 11:01:35 -0700 Subject: Hotspot shell games In-Reply-To: References: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> <4A0DB273.9060908@sun.com> <17c6771e0905281752v5f925e7cm9390a2eac4a6d600@mail.gmail.com> <4A1F366E.9010801@sun.com> <4A1F38A2.2090505@sun.com> <17c6771e0905290456j7c3b62f8xee36460943abe374@mail.gmail.com> <4A200AEA.3050809@sun.com> Message-ID: <4A2022FF.8040303@sun.com> Volker Simonis wrote: >> * Tag the rev in the jdk7/hotspot repo with a name jdk6-b17, the >> rev that matches what is in the hsx14 repo > > Is this really possible? I thought the HS which is now in 6u14 (and in > HSX14) was branched from the jdk7/hotspot sometimes around hotspot > build 9/10 of the jdk7/hotspot. Afterwards, the hotspot version was > incremented to 15 in jdk7/hotspot while there have been about six more > builds of HS 14 in the HSX14 repository. From my understanding, the > change history in jdk7/hotspot and HSX14 is different after HSX has > been branched off from jdk7/hotspot and I can't imagine how one can > now find a changeset in jdk7/hotspot which matches the hotspot version > in HSX14. After all, the whole purpose of branching HSX14 is to > stabilize it while the development can proceed in jdk7/hotspot. Or am > I missing something here? Mercurial tags can be created after the fact. A tag is just a reference or name to a changeset ID, they can also be updated or changed later. They are very simple things. I'll ignore "HSX14", and call it "jdk6/hotspot", but if you like, you can replace the names as you read this. ;^) If jdk6/hotspot work is done in a jdk6/hotspot repository, and new changesets are added or new tags created, you should be able to pull those changesets into jdk7/hotspot, merge and commit them there too. The end result is that all the jdk6/hotspot changesets are in jdk7/hotspot, then you could 'hg clone -r jdk6-bNN' from either repository and get the exact same thing. The trick is to create jdk6/hotspot changesets in an jdk6/hotspot repository so that the graph of changesets for jdk6/hotspot are all connected together. The sync to jdk7/hotspot effectively adds any jdk6/hotspot changesets and merges with the current jdk7/hotspot tip, creating a new jdk7/hotspot tip. The jdk6/hotspot repository acts as a branch, yet no hg branches are used. Someone would occasionally need to make sure the jdk6/hotspot changes that are not in jdk7/hotspot get pulled over (a sync). The tricky part is transplanting or cherry picking 1 changeset from jdk7/hotspot back to jdk6/hotspot without accepting the whole graph of changesets above it. Unless we relax the jcheck rules around this, two changesets with the same bugid cannot exist in one repository, so a new bugid is needed to do any transplants (where a new changeset is created for the same patch or code change). -kto > > Regards, > Volker From Erik.Trimble at Sun.COM Fri May 29 20:48:39 2009 From: Erik.Trimble at Sun.COM (Erik Trimble) Date: Fri, 29 May 2009 20:48:39 -0700 Subject: Sync'd HSX14 with latest shipping Sun HSX bits... Message-ID: <4A20AC97.9050607@sun.com> OK, I just sync'd the HSX14 repos with the final source for Hotspot 14 as shipped in Sun JDK 6 Update 14. -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) From volker.simonis at gmail.com Sat May 30 00:20:59 2009 From: volker.simonis at gmail.com (Volker Simonis) Date: Sat, 30 May 2009 09:20:59 +0200 Subject: Hotspot shell games In-Reply-To: <4A2022FF.8040303@sun.com> References: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> <4A0DB273.9060908@sun.com> <17c6771e0905281752v5f925e7cm9390a2eac4a6d600@mail.gmail.com> <4A1F366E.9010801@sun.com> <4A1F38A2.2090505@sun.com> <17c6771e0905290456j7c3b62f8xee36460943abe374@mail.gmail.com> <4A200AEA.3050809@sun.com> <4A2022FF.8040303@sun.com> Message-ID: Thank you for the detailed explanation. It was indeed the situation with the same changesets beeing applied in parallel to both repositories that worried me. But aren't there already different BugIds for the same change in the Bug database (those strange "shadow" bugids starting with 2***) for exactly this purpose? Volker On Fri, May 29, 2009 at 8:01 PM, Kelly O'Hair wrote: > > > Volker Simonis wrote: >>> >>> ?* Tag the rev in the jdk7/hotspot repo with a name jdk6-b17, the >>> ? ?rev that matches what is in the hsx14 repo >> >> Is this really possible? I thought the HS which is now in 6u14 (and in >> HSX14) was branched from the jdk7/hotspot sometimes around hotspot >> build 9/10 of the jdk7/hotspot. Afterwards, the hotspot version was >> incremented to 15 in jdk7/hotspot while there have been about six more >> builds of HS 14 in the HSX14 repository. From my understanding, the >> change history in jdk7/hotspot and HSX14 is different after HSX has >> been branched off from jdk7/hotspot and I can't imagine how one can >> now find a changeset in jdk7/hotspot which matches the hotspot version >> in HSX14. After all, the whole purpose of branching HSX14 is to >> stabilize it while the development can proceed in jdk7/hotspot. Or am >> I missing something here? > > Mercurial tags can be created after the fact. A tag is just a reference > or name to a changeset ID, they can also be updated or changed later. > They are very simple things. > > I'll ignore "HSX14", and call it "jdk6/hotspot", but if you like, you can > replace the names as you read this. ;^) > > If jdk6/hotspot work is done in a jdk6/hotspot repository, and new > changesets are > added or new tags created, you should be able to pull those changesets > into jdk7/hotspot, merge and commit them there too. > The end result is that all the jdk6/hotspot changesets are in jdk7/hotspot, > then you could 'hg clone -r jdk6-bNN' from either repository and get the > exact same thing. > > The trick is to create jdk6/hotspot changesets in an jdk6/hotspot repository > so that the graph of changesets for jdk6/hotspot are all connected together. > The sync to jdk7/hotspot effectively adds any jdk6/hotspot changesets and > merges > with the current jdk7/hotspot tip, creating a new jdk7/hotspot tip. > > The jdk6/hotspot repository acts as a branch, yet no hg branches are used. > Someone would occasionally need to make sure the jdk6/hotspot changes that > are not in jdk7/hotspot get pulled over (a sync). > > The tricky part is transplanting or cherry picking 1 changeset from > jdk7/hotspot back to jdk6/hotspot without accepting the whole graph > of changesets above it. Unless we relax the jcheck rules around this, > two changesets with the same bugid cannot exist in one repository, so > a new bugid is needed to do any transplants (where a new changeset is > created for the same patch or code change). > > -kto > >> >> Regards, >> Volker > From Kelly.Ohair at Sun.COM Sat May 30 11:34:46 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Sat, 30 May 2009 11:34:46 -0700 Subject: Hotspot shell games In-Reply-To: References: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> <4A0DB273.9060908@sun.com> <17c6771e0905281752v5f925e7cm9390a2eac4a6d600@mail.gmail.com> <4A1F366E.9010801@sun.com> <4A1F38A2.2090505@sun.com> <17c6771e0905290456j7c3b62f8xee36460943abe374@mail.gmail.com> <4A200AEA.3050809@sun.com> <4A2022FF.8040303@sun.com> Message-ID: <4A217C46.2050101@sun.com> Sigh... our home grown bug system does have these strange shadow bugs, but in general people are told to not refer to them directly. So whether it's jdk5, jdk6, or jdk7 people usually use the 6NNNNNN number, or are told to. Not that your suggestion of using the 2NNNNNN bugs would not work. I was kind of wishing we could just start using bugzilla numbers. :^( --- I'm thinking about proposing a change to the jcheck rule on a single bugid being used once in a repository. What if we could allow an optional '-N' or '-text' after the bugid, e.g. allow additional changesets that look like (just examples) 6123456-1: Synopsis ... Summary: Additional change needed due to ... 6123456-workaround: Synopsis ... Summary: Temporary workaround until more formal fix ... 6123456-transplant: Synopsis ... Summary: Transplant of fix from jdk7 repository 6123456-testcase: Synopsis ... Summary: Temporarily ignore testcase until bug fixed... 6123456-phase88: Synopsis ... Summary: Phase 88 of doc changes for milestone 9,564 ;^) Where the pattern would be either a 6 or 7 digit number with an optional set of characters. The rule then changes to that pattern (up to the ':') cannot be repeated in any other changeset. Transplants are then allowed, but some changes to the changeset comment to identify them as such would be needed. Just ideas.... All to avoid having to file extra and needless bugs. Comments? -kto Volker Simonis wrote: > Thank you for the detailed explanation. It was indeed the situation > with the same changesets beeing applied in parallel to both > repositories that worried me. But aren't there already different > BugIds for the same change in the Bug database (those strange "shadow" > bugids starting with 2***) for exactly this purpose? > > Volker > > On Fri, May 29, 2009 at 8:01 PM, Kelly O'Hair wrote: >> >> Volker Simonis wrote: >>>> * Tag the rev in the jdk7/hotspot repo with a name jdk6-b17, the >>>> rev that matches what is in the hsx14 repo >>> Is this really possible? I thought the HS which is now in 6u14 (and in >>> HSX14) was branched from the jdk7/hotspot sometimes around hotspot >>> build 9/10 of the jdk7/hotspot. Afterwards, the hotspot version was >>> incremented to 15 in jdk7/hotspot while there have been about six more >>> builds of HS 14 in the HSX14 repository. From my understanding, the >>> change history in jdk7/hotspot and HSX14 is different after HSX has >>> been branched off from jdk7/hotspot and I can't imagine how one can >>> now find a changeset in jdk7/hotspot which matches the hotspot version >>> in HSX14. After all, the whole purpose of branching HSX14 is to >>> stabilize it while the development can proceed in jdk7/hotspot. Or am >>> I missing something here? >> Mercurial tags can be created after the fact. A tag is just a reference >> or name to a changeset ID, they can also be updated or changed later. >> They are very simple things. >> >> I'll ignore "HSX14", and call it "jdk6/hotspot", but if you like, you can >> replace the names as you read this. ;^) >> >> If jdk6/hotspot work is done in a jdk6/hotspot repository, and new >> changesets are >> added or new tags created, you should be able to pull those changesets >> into jdk7/hotspot, merge and commit them there too. >> The end result is that all the jdk6/hotspot changesets are in jdk7/hotspot, >> then you could 'hg clone -r jdk6-bNN' from either repository and get the >> exact same thing. >> >> The trick is to create jdk6/hotspot changesets in an jdk6/hotspot repository >> so that the graph of changesets for jdk6/hotspot are all connected together. >> The sync to jdk7/hotspot effectively adds any jdk6/hotspot changesets and >> merges >> with the current jdk7/hotspot tip, creating a new jdk7/hotspot tip. >> >> The jdk6/hotspot repository acts as a branch, yet no hg branches are used. >> Someone would occasionally need to make sure the jdk6/hotspot changes that >> are not in jdk7/hotspot get pulled over (a sync). >> >> The tricky part is transplanting or cherry picking 1 changeset from >> jdk7/hotspot back to jdk6/hotspot without accepting the whole graph >> of changesets above it. Unless we relax the jcheck rules around this, >> two changesets with the same bugid cannot exist in one repository, so >> a new bugid is needed to do any transplants (where a new changeset is >> created for the same patch or code change). >> >> -kto >> >>> Regards, >>> Volker From gnu_andrew at member.fsf.org Sat May 30 17:32:52 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Sun, 31 May 2009 01:32:52 +0100 Subject: Hotspot shell games In-Reply-To: <4A200AEA.3050809@sun.com> References: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> <4A0DB273.9060908@sun.com> <17c6771e0905281752v5f925e7cm9390a2eac4a6d600@mail.gmail.com> <4A1F366E.9010801@sun.com> <4A1F38A2.2090505@sun.com> <17c6771e0905290456j7c3b62f8xee36460943abe374@mail.gmail.com> <4A200AEA.3050809@sun.com> Message-ID: <17c6771e0905301732n1b87d8b6we0efe1af83f6a794@mail.gmail.com> 2009/5/29 Kelly O'Hair : > > (removed jdk7-dev from this discussion) > > Andrew John Hughes wrote: >> >> 2009/5/29 Erik Trimble : > > [snip] >>> >>> For now, though, we need to decide how to handle HSX vs Open6 vs. IceTea. >> >> Simplest solution would be to just remove it from OpenJDK6 and use HSX >> as the upstream. ?I don't see an advantage to pulling in to OpenJDK6, >> given there is already a 'stable' branch of HSX. > > I would prefer to keep a hotspot repository in the openjdk6 forest, just > for the sake of having a buildable and complete source base. I can see the advantage, though I would guess the number of people doing OpenJDK6 builds is far smaller than those doing IcedTea builds which has been deleting the OpenJDK6 repo and replacing it for months now. If the OpenJDK6 repo is again allowed to bit-rot, then we're likely to have to do this again. We'd obviously prefer to be working on a common upstream rather than having effectively two communities. > I would also like to have some level of confidence as to which hotspot > is the default one for the openjdk6 project. > Let's not leave a partial jdk6 forest sitting out there. > My main concern is maintenance. If what is there is maintained regularly, I don't care too much either way. That said, I'd prefer to see less duplication though, and this also extends to CORBA, JAXP and JAXWS as Joe already mentioned. > To me the decision that needs to be made is whether you want the > openjdk6 hotspot repository (jdk6/hotspot) 'related' to the other > hotspot repositories, like hsx/hsx14/master is related to jdk7/hotspot. It isn't related; hsx includes several build drops that were never in the public HotSpot repositories and which we had to wait over three months for. > It doesn't have to be, and there are advantages and disadvantages to > both approaches. > None of the non-hotspot repositories in the openjdk6 forest are related > to the jdk7 repositories, making them pretty independent from jdk7, Which is sensible, given 6 has to be stable. It being based off jdk7 is merely an issue of when things were released under the GPL, as I believe you or Joe have blogged about before. > but hotspot is somewhat special, and the express model I support, so... > > My suggestions... > ?* Ignore hsx/hsx14, it's a drop not a development tree What??? I don't believe any discussions around HSX ever being about it being just a drop. It's meant to be a stability branch of hs14 for use in OpenJDK6 and Sun's JDK6 releases. If it was a drop, why do a forest at all and not just update OpenJDK6? > ?* Decide to make the jdk6 and jdk7 repositories 'related' Impossible, unless I misunderstand what you mean by 'related'. > ?* Tag the rev in the jdk7/hotspot repo with a name jdk6-b17, the > ? ?rev that matches what is in the hsx14 repo Again there is no hs14b11...hs14b16 in the public HotSpot repository. That's what sparked the whole discussion that lead to HSX in the first place. Sun took HotSpot 14 'underground' and out of the public eye as regards further stability work. With hsx, we finally seem to have reversed this process by the release of hs14b11...hs14b16 and I'd expect to see further releases appear there too. > ?* Toss the existing jdk6/hotspot repo and replace it with a repo > ? ?created with: > ? ? ? ?hg clone -r jdk6-b17 http://hg.openjdk.java.net/jdk7/hotspot > jdk6/hotspot > I think the only options are to pull in changeset 0 from hsx to rebase the HotSpot repo on that, or (simpler) replace it with a clone of hsx. The former would preserve the commit history and would be more useful over time IMO. > Changes going into jdk6/hotspot should be rare, critical, and should > eventually be pushed back into jdk7/hotspot, indeed some critical fixes > may get transplanted from jdk7/hotspot to jdk6/hotspot. > If at some point it's decided to upgrade jdk6/hotspot to a newer rev, > so be it, easy to do. > I think changes should just go to hsx and then feed into OpenJDK6 through regular pulls, if we plan to maintain a repo. there. > And for heavens sake, start adding some hsx-* tags to the hotspot repository > so we can easily clone hsx versions from the tag name, you could also use > the hsx tag to hold the build number, I can help with that. > Now this I agree on :) > -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 Kelly.Ohair at Sun.COM Sun May 31 11:31:52 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Sun, 31 May 2009 11:31:52 -0700 Subject: Hotspot shell games In-Reply-To: <17c6771e0905301732n1b87d8b6we0efe1af83f6a794@mail.gmail.com> References: <17c6771e0905151101g7413db57lcbcba7640af658c@mail.gmail.com> <4A0DB273.9060908@sun.com> <17c6771e0905281752v5f925e7cm9390a2eac4a6d600@mail.gmail.com> <4A1F366E.9010801@sun.com> <4A1F38A2.2090505@sun.com> <17c6771e0905290456j7c3b62f8xee36460943abe374@mail.gmail.com> <4A200AEA.3050809@sun.com> <17c6771e0905301732n1b87d8b6we0efe1af83f6a794@mail.gmail.com> Message-ID: <4A22CD18.9020002@sun.com> Andrew John Hughes wrote: > 2009/5/29 Kelly O'Hair : >> (removed jdk7-dev from this discussion) >> >> Andrew John Hughes wrote: >>> 2009/5/29 Erik Trimble : >> [snip] >>>> For now, though, we need to decide how to handle HSX vs Open6 vs. IceTea. >>> Simplest solution would be to just remove it from OpenJDK6 and use HSX >>> as the upstream. I don't see an advantage to pulling in to OpenJDK6, >>> given there is already a 'stable' branch of HSX. >> I would prefer to keep a hotspot repository in the openjdk6 forest, just >> for the sake of having a buildable and complete source base. > > I can see the advantage, though I would guess the number of people > doing OpenJDK6 builds is far smaller than those doing IcedTea builds > which has been deleting the OpenJDK6 repo and replacing it for months > now. If the OpenJDK6 repo is again allowed to bit-rot, then we're > likely to have to do this again. We'd obviously prefer to be working > on a common upstream rather than having effectively two communities. It doesn't matter to me which is being built more or less, I just want to make sure that OpenJDK6 is complete and does build, and work. I also want to open it up as much as possible in terms of others pushing changes in. I'm sure we can work this out in an acceptable way for all concerned... read on... > >> I would also like to have some level of confidence as to which hotspot >> is the default one for the openjdk6 project. >> Let's not leave a partial jdk6 forest sitting out there. >> > > My main concern is maintenance. If what is there is maintained > regularly, I don't care too much either way. That said, I'd prefer to > see less duplication though, and this also extends to CORBA, JAXP and > JAXWS as Joe already mentioned. I agree, and I'm all in favor. But having a complete OpenJDK6 tree, including hotspot doesn't change that, it's just a clone of a repository that represents what we know works. If the IcedTea team said that they tried Hotspot version 3,246 and it worked for them and looked solid, then hey, great, push those changesets into the openjdk6 hotspot repository. Or we work out some other way to update it, I'm open to suggestions, I just would like to see 'a clone' of 'a hotspot' repository available with the openjdk6 forest of repositories. > >> To me the decision that needs to be made is whether you want the >> openjdk6 hotspot repository (jdk6/hotspot) 'related' to the other >> hotspot repositories, like hsx/hsx14/master is related to jdk7/hotspot. > > It isn't related; hsx includes several build drops that were never in > the public HotSpot repositories and which we had to wait over three > months for. When I say 'related' I'm referring to the ability to pull/push mercurial changesets between the repositories without transplanting or reapplying patches. And the hsx repository is related to the public repositories, they just might not ne in sync or be proper subsets of each other at times. > >> It doesn't have to be, and there are advantages and disadvantages to >> both approaches. >> None of the non-hotspot repositories in the openjdk6 forest are related >> to the jdk7 repositories, making them pretty independent from jdk7, > > Which is sensible, given 6 has to be stable. It being based off jdk7 > is merely an issue of when things were released under the GPL, as I > believe you or Joe have blogged about before. No it's more than that, the sources themselves have a relationship between openjdk6 and openjdk7, but the repositories themselves are not related, you cannot pull/push changesets between these repositories. You can reapply patches and re-create new changesets that match from one to the other, and Mercurial makes that easy, but they are not the same changesets. I'm thinking that they should be related, and most of the time be proper subsets of each other in terms of what changesets are in them. This gives us a degree of exactness you don't get when changesets are re-created frpm patches. Assuming we can do it or even agree to it. > >> but hotspot is somewhat special, and the express model I support, so... >> >> My suggestions... >> * Ignore hsx/hsx14, it's a drop not a development tree > > What??? I don't believe any discussions around HSX ever being about it > being just a drop. It's meant to be a stability branch of hs14 for > use in OpenJDK6 and Sun's JDK6 releases. If it was a drop, why do a > forest at all and not just update OpenJDK6? My definition of 'drop' here was that it is not intended to be a two-way open street as I understood the purpose. A simple source tarball could have worked, but since there was always a chance of last minute hs14 changes, a repository makes things easier, granted it sounds like it was updated a little slowly with the last few changes. My point in the comment is that, as I understand it, hs14 is for all intents and purposes, done. Maybe I have that wrong, but my assumption is that the team is and has moved on to the next hotspot express release, and hs14 is no longer a priority. > >> * Decide to make the jdk6 and jdk7 repositories 'related' > > Impossible, unless I misunderstand what you mean by 'related'. Related to me means that both repositories have the same "changeset 0". What I am suggesting is that occasionally, after a sync, the jdk6 repo would be a proper subset of the jdk7 repo. > >> * Tag the rev in the jdk7/hotspot repo with a name jdk6-b17, the >> rev that matches what is in the hsx14 repo > > Again there is no hs14b11...hs14b16 in the public HotSpot repository. Actually I think there is, we just are not recording it in the changeset tags. > That's what sparked the whole discussion that lead to HSX in the first > place. Sun took HotSpot 14 'underground' and out of the public eye as > regards further stability work. With hsx, we finally seem to have > reversed this process by the release of hs14b11...hs14b16 and I'd > expect to see further releases appear there too. I'm just not sure you will be getting what you are expecting with this, again, I thought hsx14 was a done deal for the most part. > >> * Toss the existing jdk6/hotspot repo and replace it with a repo >> created with: >> hg clone -r jdk6-b17 http://hg.openjdk.java.net/jdk7/hotspot >> jdk6/hotspot >> > > I think the only options are to pull in changeset 0 from hsx to rebase > the HotSpot repo on that, or (simpler) replace it with a clone of hsx. > The former would preserve the commit history and would be more useful > over time IMO. I'm very confused now, I think we just said the same thing, or something extremely similar. > >> Changes going into jdk6/hotspot should be rare, critical, and should >> eventually be pushed back into jdk7/hotspot, indeed some critical fixes >> may get transplanted from jdk7/hotspot to jdk6/hotspot. >> If at some point it's decided to upgrade jdk6/hotspot to a newer rev, >> so be it, easy to do. >> > > I think changes should just go to hsx and then feed into OpenJDK6 > through regular pulls, if we plan to maintain a repo. there. EXACTLY! That is what I am suggesting for OpenJDK6, just a clone. Except you say "hsx" I say "jdk7/hotspot", to me they are the same, or "the latest hotspot express where all the latest work is done". > >> And for heavens sake, start adding some hsx-* tags to the hotspot repository >> so we can easily clone hsx versions from the tag name, you could also use >> the hsx tag to hold the build number, I can help with that. >> > > Now this I agree on :) Good... I'll keep pushing on this then. --- Erik, Let's start looking into hsx-* tags!!! ;^) -kto > >> -kto >> >> >> > > >